Web of Trust oder "Wie funktioniert das Netz des Vetrauens ?"
Wenn jemand Public Keys dazu benutzen will, um verschlüsselte Kommunikation zu betreiben, muss er zwei Dinge voraussetzen können: 1. die Public Keys seiner Kommunikationspartner
sind echt.
2. sein Public Key kann nicht gefälscht werden.
Deshalb fängt das Web of Trust schon bei der Schlüsselerzeugung an.
Fälschung
Bei der Keyerzeugung wird der eigene Public Key mit dem eigenen
Secret Key signiert.
Wenn man unter PGPkeys nachsieht, befinden sich unter dem Keysymbol
zwei weitere Einträge, dem ersten Eintrag ist ein symbolisierter
Briefumschlag vorangestellt und steht für die User-ID, dem zweiten
Eintrag ist eine Feder oder eine Stiftspitze vorangestellt ist
und steht für die Signatur.
Sieht man sich mal die "Key Properties (Eigenschaften)"
des eigenen Public Keys an, fällt eines auf:
Sowohl die "Key-ID" als auch der "Key-Fingerprint"
sind bei dem Keypaar, der User-ID und der Signatur gleich.
Kontrollieren wir den Public Key eines Kommunikationspartners
(was immer der Fall sein muss), muss das Ergebnis
genauso aussehen, ansonsten ist der Public Key gefälscht.
PGP unterschreibt also selbst unseren eigenen Public Key, um
damit auszuweisen, dass der Public Key mit dieser speziellen
Key-ID und User-ID mit dem richtigen Secret Key unterschrieben
wurde, der Verbreiter des Public Key mit User-ID wx und Key-ID
yz im Besitz des passenden Secret Keys und der passenden Passphrase
ist.
Ausserdem beinhaltet die eigene Signatur weitere Merkmale des
Schlüssels wie z. B. die Gültigkeitsdauer, die im Fingerprint
des Schlüssels nicht enthalten sind und bestätigt die Zugehörigkeit
des Keyinhabernamens in der User-ID wx zum Schlüssel mit der
Key-ID "yz".
Die ID's der Signatur sind nicht zu editieren, wie es beim Public
Key möglich ist, so dass der Key durch die Eigensignatur auch
vor Veränderungen (mit Ausnahme weiterer Signaturen anderer
User, die ich nicht verhindern oder nochmals signieren kann)
geschützt wird.
Fälschungswege
A.
Der Fälscher versieht den ursprünglichen Public Key mit seiner
User-ID/E-mail Adresse und um nicht aufzufallen, entfernt
er alle Signaturen.
Da die Keyserver nur einmal einen Key mit einer spezifischen
Key-ID speichern können, kann der Fälscher versuchen, den
Key vor dem ursprünglichen Key des Erstellers auf dem Keyserver
abzulegen, so dass der Ersteller nicht mehr in der Lage ist
den ursprünglichen, erzeugten Key zu hinterlegen.
Die Fälschung fällt auf, da der Key keine Signatur hat.
Denkbar ist, dass der Fälscher eine Signatur erstellt und
deren Fingerprint fälscht, dann aber unterscheidet sich der
gefälschte Key vom originalen, signierten Key in der Länge.
B.
Der Fälscher erstellt einen neuen Public Key, der die User-ID
und die Key-ID des ursprünglichen Keys des Angegriffenen trägt
und versieht den Key mit seiner Signatur und zusätzlich eventuell
noch mit seiner E-mail Adresse.
Aus der Sicht des Fälschers hofft dieser, dass Personen
annehmen werden, dieser Key gehoere dem originalen User und
diesen Key benutzen um E-mails an den eigentlichen Empfänger
verschlüsseln.
Der Fälscher kann sich nun zwischen dem gutgläubigen Absender
und den eigentlichen Empfänger schalten, die Korrespondenz
abfangen und entschlüsseln.
Ist die E-mail Adresse des Keys durch die Adresse des Fälschers
ersetzt worden, kann er sich diesen Schritt sogar sparen und
bekommt die E-mails direkt zugeschickt.
Andernfalls erhält der ursprüngliche Empfänger zwar die E-mails,
kann diese aber nicht mehr entschlüsseln.
Wurde der Fingerprint nicht gefälscht, ist die Fälschung am
unterschiedlichen Fingerprint von Key und Signatur zu erkennen.
Weitere Informationen, welche Gefahren durch Fälschungsmöglichkeiten entstehen können, finden sich in der:
Was deutlich wird, ist, dass man nur dann ziemlich sicher von der Echtheit eines Keys ausgehen kann, wenn die Kombination aus Keylänge, die ID's, die Fingerprints und die Signatur stimmt und diese Kombination persönlich beim Keybesitzer überprüft wurde.Somit kann zwar nicht ausgeschlossen werden, dass jemand einen Public Key fälscht, aber, dass er dies unentdeckt tun kann.
Validity
Die Echtheit ("Validity")eines Public Keys wird
durch die Signatur anderer User "bezeugt".
Wir können einen anderen Public Key mit unserer eigenen Signatur
versehen.
In PGP 5/6 wird dieser Key sogleich "valid", d.h.
"gültig" oder "authentisch".
Solange er nicht von uns signiert ist, bleibt der Key grundsätzlich
gesehen "ungültig" oder "nicht authentisch".
Als Folge bleibt der Besitzer des Keys auch als "untrusted"
oder "nicht vertrauenswürdig" eingestuft. Mit der
Signierung bezeugen wir, dass wir uns überzeugt haben, dass
dieser Public Key wirklich zum angegebenen User gehört oder
anders:
Wir wissen mit 100% Sicherheit, dass der Public Key echt ist,
unabhängig davon, ob unter diesem Key bereits Signaturen von
Leuten stehen, denen wir vertrauen oder die uns bekannt sind.
Zu diesem Zweck überprüfen wir schon mal, wie oben angegeben,
den bereits vorliegenden Public Key auf Unstimmigkeiten.
Dann überprüfen wir persönlich oder telefonisch die Angaben,
die uns der Key liefert (User-ID, Key-ID, Fingerprint, Keylänge,
Keytyp) anhand der Angaben, die uns der Kontaktierte auf Anfrage
liefert.
Zusätzlich können auf die gleiche Weise eine oder mehrere
der unter dem Key befindlichen Signaturen gegengeprüft werden.
Wenn im Idealfall, davon ausgegangen wird, dass jeder
PGP-Benutzer so verfährt, wären idealerweise alle
Public Keys echt.
Da wir die Realität kennen, kann sich jeder PGP-Benutzer
ausrechnen, welche Kontrollen er durchführen muss und wie
verantwortlich er zu handeln hat.
Neben den Signaturen anderer User spielen die Zertifikate
von CA's eine weit wichtigere Rolle.
Trust
Neben der "Validity" hat PGP 5/6 auch eine weitere interne "Trust"-Skala zu bieten, die sich auf unsere Einschätzung des Keybesitzers bezieht. Der "Trust" oder "Vertrauensgrad" gibt in drei Stufen von "untrusted-nicht vertrauenswürdig" über "marginal-begrenzt vertrauenswürdig" bis zu "complete-voll vertrauenswürdig" an, inwieweit das Vertrauen in das verantwortliche Handeln und die Fähigkeit eines Keybesitzer vorhanden ist, selbst wiederum für die "Validity" eines anderen Public Keys zeugen zu können.Bekommt man irgendwann einen Public Key, der mit der Signatur einer Person versehen ist, die man selbst eines von Dir nach "Trust" eingestuften PGP-Benutzers signiert ist, wird dieser Public Key entsprechend als gültig eingestuft, auch wenn Du diesen neuen Key selbst noch nicht signiert hast.
Beachte: Der Trustlevel eines PGP-Benutzers kann erst höher als "untrusted" eingestuft werden, wenn Du den Key dieses Benutzers selbst signiert hast. So hängt also das Vetrauen in einen User von der Gültigkeit seines Keys ab.
Oder anders formuliert: Ein Key kann zwar "gültig", der Benutzer aber "nicht vertrauenswürdig" sein.
Die Konfiguration des "Web of Trust" bei
PGP 2.6.3: wird durch die Vergabe der eigenen Signatur
und/oder der Vergabe eines von vier Trustlevels bestimmt.
PGP 2.6.3 kennt zur eigenen Kennzeichnung des Vertrauens in
die Aufrichtigkeit der Person und in die Kompetenz einer Person,
verantwortlich sowohl mit den eigenen, wie mit anderen PGP-Keys
umzugehen, folgende Stufen:
- 1 = ich weiss nicht
- 2 = Nein
- 3 = in der Regel
- 4 = Ja, immer
- Completes_Needed = X
PGP sieht dann einen Public Key als echt an, wenn er X Signaturen trägt,
deren User die Vertrauensstufe 4 besitzen - Marginals_Needed = Y
PGP sieht dann einen Public Key als echt an, wenn er Y Signaturen trägt,
deren User die Vertrauensstufe 3 besitzen
PGP 2.6.3> pgp -ke User-ID |
Daneben muss für die Sicherheit
des Public Keys, Secret Keys und der Passphrase gesorgt werden.
Eine sichere Verwahrung von Pubring, Secring und Passphrase
gehören dazu.
Ein zusätzlicher Sicherheitsgewinn kann die wöchentliche oder
monatliche Änderung der Passphrase sein, was ein Errechnen/Erraten
der Passphrase zusätzlich erschwert, wenn man davon ausgeht,
dass dieser Vorgang einige Zeit und einige Rechnerkapazitäten
voraussetzt.
Es ist auch sinnvoll, sofort nach der Erstellung von Public
und Secret Key, die Schlüsselrückzugsurkunde ("Key Revocation")
für den Public Key zu erzeugen und gesichert abzulegen. Das
hat den Vorteil, dass sofort die Key Revocation an einen Keyserver
gesendet und die Kommunikationspartner informiert werden können,
wenn Secret Key und/oder die Passphrase in die Hände anderer
gelangt ist (was immer geschehen muss, wenn dieser Fall eintreten
sollte).
Was noch wichtiger ist:
Wenn der Keybesitzer aus irgendeinem Grund nicht mehr im Besitz
des Secret Keys und der Passphrase ist, kann er seinen Public
Key zurückziehen.
Key Revocation
Zertifizierungsstellen ("Certification Authorities")
Einen weiteren Ansatz stellen die sogenannten Zertifizierungsstellen
("Certification Authorities"/CA) dar, also anerkannte
Institutionen, Organisationen, Firmen oder Vereine, die die
Zugehörigkeit zwischen der Identität einer Person und einem
Public Key nach bestimmten Prüf- und Kontrollverfahren durch
ein Zertifikat zertifizieren.
Damit entfällt der doch etwas aufwendige und mit Unsicherheiten
belastete Weg der Sammlung von Signaturen unter den eigenen
Public Key und die Notwendigkeit der persönlichen Kontaktaufnahme
mit dem Keybesitzer, wenn man einen anderen Public Key zertifizieren
will.
Das bedeutet andererseits, daß mein Vertrauen in die
Gültigkeit eines CA-Zertifikats an das Vertrauen in die
CA selbst gekoppelt ist.
Anders ausgedrückt: Der Anwender muss sich sicher sein
können, dass die CA auf verlässlichem, nachvollziehbarem
und korrektem Wege Schlüssel übeprüft und zertifiziert.
Ein wichtiges Kriterium dazu bieten die Arbeitsgrundlagen
einer CA.
Policys und Rechtsgrundlagen
Bei den Rechtsgrundlagen sind zwei Gesetzeswerke ausschlaggebend:
Die Richtlinie 1999/93/EG des Europäischen Parlaments
und des Rates über gemeinschaftliche Rahmenbedingungen
für elektronische Signaturen und die Umsetzung der Richtlinie
in das deutsche Gesetz über Rahmenbedingungen für
elektronische Signaturen (Signaturgesetz - SigG).
Das SigG legt f
Aber auch bei den CA's ist es meistens notwendig, persönlich
mit dem Personalausweis oder gar einer notariellen Bestätigung
zu erscheinen, damit diese den eigenen Public Key zertifizieren
oder das Keypaar muß in einem abgesicherten Verfahren direkt
in der CA vom Keybesitzer erzeugt werden.
Es gibt aber auch Zertifikate, die dann ausgestellt werden,
wenn der Keyinhaber einen verschlüsselten Prüfsatz, den ihm
die CA nach Antrag zusendet, entschlüsseln kann und dann wieder
per E-Mail an die CA zurücksendet (E-Mail Zertifikat) oder
die CA verlangt zusätzlich die Ausweisung gegenüber einer
bekannten öffentlichen Stelle wie einem Postamt (Post-Ident-Zertifikat).
Es gibt also unterschiedliche "Qualitätsstufen"
bei Zertifikaten, die aber auch aus der Bezeichnung eines
Zertifikats ersichtlich sind.
Der Vorteil der CA-Signatur liegt trotzdem im allgemeinen
Bekanntsheits- und Vertauensgrad, der es leichter macht, einem
Public Key zu vertrauen, der mit einer CA-Signatur versehen
ist, als einem Public Key, der zwar von einer Person signiert
wurde, deren Name mir aber nicht bekannt ist.
Die Bedeutung der CA's wird deshalb mit einer steigenden Anzahl
von PGP Benutzern zunehmen.
Beispiele für CA's
- die PGP-CA der Zeitschrift c't
- die PGP 2.6.3in-CA des Individual Networks
- die DFN-CA des Deutschen Forschungsnetzes
- die Firma TC TrustCenter
for Security
TrustCenter bietet eine für Privatpersonen kostenlose Zertifizierung per E-mail ("EMail Certificate") oder in Kombination mit einer Überprüfung per Einschreiben ("Certified Mail-Certificate") an.
Zum Ende des Jahres können auch Keys mit Pseudonym User-ID's zertifiziert werden. - die CA des GeFoekoM e.V. / AK Datenschutz
Trustcenter
Auch die Bundesregierung und die Europäische Union haben
mit dem Deutschen
Signaturgesetz und der europäischen
Signaturverordnung den Weg frei gemacht für staatlich
anerkannte Zertifizierungsstellen ("Trustcenter"),
die in eigener Regie und durch staatliche Lizenzvergabe für
die Verwaltung und Herstellung digitaler Signatur- und Verschlüsselungskeys
zuständig sind.
Die mit diesen Keys erzeugten Signaturen werden zukünftig
rechtlich der schriftlichen Unterschrift gleichgestellt sein.
Das betrifft nicht mit PGP erzeugte Keys und deren Signaturen,
da diese nicht in staatlich anerkannten TrustCentern erzeugt
werden, bzw. keine "qualifizierten" Signaturen erzeugen
- in gerichtlichen Verfahren ist hier der Anwendern stärker
dazu gezwungen, die Gültigkeit oder Ungültigkeit von PGP Signaturen
zu beweisen.
In einigen Staaten ist diese Idee oft mit
der Hinterlegung eines "Generalschlüssels" bei staatlichen
Stellen oder "Trusted Third Parties" (TTP),
dem sogenannten "Key
Escrow" (im Falle von PGP könnte man auch
sagen: Hinterlegung von Secret Key und Passphrase) verbunden,
mit dessen Hilfe staatliche Organe, wie die Geheimdienste,
nach einem juristischen Genehmigungsverfahren verschlüsselte
Dateien oder E-Mails bei Verdacht wieder entschlüsseln können
oder mit der Zulassung von Verschlüsselungsprogrammen, die
es erlauben, den Verschlüsselungskey, der bei der Verschlüsselung
benutzt wurde, wiederherstellen zu können, sogenanntes "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 Public Key wird in ein öffentliches Verzeichnis
eingestellt, aber der private Schlüssel verbleibt ebenfalls
in der Zertifizierungsstelle und macht sie so zur TTP.
Bei dieser Form aus Trustcenter und TTP kommt mir persönlich
ein ganz anderer Verdacht...und Carl Ellison von der Firma
CyberCash nennt diese Vorstellungen beim Namen: "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 anschliessend 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, da das
Schlüsselpaar nicht beim Anwender in dessen SmartCard(lese)gerät
erzeugt wird.
Dies stellt, trotz Vernichtung des Private Keys und der räumlichen
Absicherung, weiterhin ein Sicherheitsrisiko dar: Geheimdienste
könnten sich theoretisch Zugriff auf den Private Key während
der Schlüsselerzeugung verschaffen, andere Personen theoretisch
durch Bestechung oder Erpressung von Angestellten, die Zutritt
zu den Sicherheitsbereichen im Trustcenter haben.
Trotzdem werden die nach diesen gesetzlich vorgeschriebenen Verfahren erzeugten Schlüssel und Signaturen und der Einsatz auf Krypto-SmartCards größte Bedeutung im Geschäfts- und Rechtsverkehr erlangen - spätestens dann, wenn Geld/Kreditkarten- und Ausweisfunktionen damit auf einer einheitlichen SmartCard zusammengeführt werden und eventuell auch im elektronischen Kommunikationsverkehr PGP zur Bedeutungslosigkeit "verdammen".
S/MIME, PKCS und X.509
Der große Konkurrent um den Standard zur E-Mail Verschlüsselung zu OpenPGP - PGP/MIME ist das S/MIME-X.509 System nach Standard RFC 1847/1848.
S/MIME (Secure MIME) basiert auf Standards, die einerseits
Vorschriften für Public-Key Verschlüsselung, andererseits
die Struktur von E-Mail Nachrichten beschreiben.
MIME (Multipurpose Internet Mail Extensions)
erweitert den Standard für Nachrichten im Internet nach
RFC
822 um den MIME Standard nach RFC 2045/2046/2047/2048/2049.
Nach RFC 822 besteht eine Nachricht nur aus Text, der aus
7-Bit Zeichen des US-ASCII Zeichensatzes besteht. Eine Nachricht
enthält danach weder Umlaute, bzw. sprachspezifische
Zeichen noch andere 8-Bit Zeichen, wie sie in multimedialen,
binären Inhalten wie Audio- oder Videodaten vorkommen.
Um diese Beschränkungen aufzuheben, wurden Codierungsanweisungen
für verschiedene Nachrichteninhalte festgelegt, die im
Header einer E-Mail in mehreren Feldern festgehalten werden:
Ein Feld gibt die MIME-Version an, das Content-Type Feld die
Art des Inhalts und das Content-Transfer-Encoding Feld das
verwendete Kodierungsverfahren. Über den Content-Type:
Multipart kann der Nachrichtenbody in mehrere Abschnitte verschiedenen
Inhalts unterteilt werden. Es ist auch möglich, eigene
Nachrichteninhaltstypen zu definieren.
Um MIME codierte Nachrichten lesen zu können, muss der
Empfänger auch über einen E-Mail Reader mit MIME
Implemetierung verfügen.
S/MIME führt die drei neuen Content-Type Typen application/pkcs7-mime
für binär verschlüsselte/signierte Daten, multipart/signed
- application/pkcs7-signatur für Klartextsignaturen und
application/pkcs10 für Zertifizierungsanfragen ein.
Mit S/MIME ist es also auch möglich, in die E-Mail eingebetette
Objekte zu verschlüsseln und/oder zu signieren.
Die MIME Funktionalität von S/MIME besitzt auch die PGP/MIME Erweiterung nach Standard RFC 2015 des OpenPGP Standards nach RFC 2440.
PKCS (Public Key Cryptography Standards)
Die PKCS (mittlerweile PKCS #1 bis #13) wurden von den RSA
Laboratories in Kooperation mit mehreren IT-Unternehmen, darunter
Apple, Microsoft, DEC, Lotus, Sun und dem MIT, entwickelt.
Die Standards legen fest, welche kryptografischen Algorithmen
wie zu implementieren sind (darunter RSA und Diffie-Hellmann)
und wie die algorithmusunabhängige Syntax für digitale
Signaturen, verschlüsselte Datenhüllen und Zertifikate
strukturiert ist.
Algorithmen
der S/MIME Standard schreibt vor, dass bestimmte Algorithmen
implemtiert sein müssen.
Darüberhinaus besitzen einzelne Anwendungen zusätzliche
Implementierungen.
Beispiel anhand von Biodata's SecureDesk und Utimaco's SafeGuard
Sign & Crypt:
Algorithmen
|
||
symmetrisch | IDEA,DES,3DES, RC2 |
DES,3DES,RC2 |
asymmetrisch | RSA | RSA |
Signatur | DSA/DSS | |
Hashing | SHA-1,MD2-MD5, RIPEMD-160 |
SHA-1,MD5,RIPEMD-160 |
Der PKCS #7 Standard "Cryptographic Message Syntax Standard" enthält sechs verschiedene, kryptografische Inhaltstypen:
- data (unverschlüsselte 8-Bit-Daten)
- signedData (signierte Daten),
- envelopedData (verschlüsselte Daten mit chiffriertem
- Sitzungsschlüssel)
- signedAndEnvelopedData (signierte und verschlüsselte
Daten)
- digestData (Signatur)
- encrypted Data (verschlüsselte Daten ohne Schlüssel).
Zusammengefasst wird also festgelegt, wie kryptografische Daten in E-Mails zu codieren, zu formatieren und zu transportieren sind und wie die Daten kryptografisch erzeugt werden.
X.500/509
Der X.500 Standard beschreibt die Struktur eines globalen,
verteilten und hierarchisch aufgebauten Verzeichnissystems.
Verteilt, weil an jedem beliebigen Ort, an dem Informationen
zu einem bestimmten Objekt anfallen, diese dort in einem lokalen
Verzeichnis abgelegt werden können.
Global, weil z. B. im Falle eines E-Mail Adressverzeichnisses
die dezentral angefallenen Objektdaten durch die Verbindung
der lokalen Verzeichnisse zu einem einzigen, großen
Gesamtverzeichnis zusammengeführt werden.
Die Einzelinformationen zum Objekt beschreiben dabei als Attribute
die Eigenschaften des Objekts.
Theoretisch kann in dem Verzeichnis jede Art von Objekt (von
einer Person bis zu einem bestimmten Schriftstück) erfasst
werden.
Die Methode des Eintrags wird durch eine Anweisung, die Bestandteil
des Standards ist und als das Schema bezeichnet
wird, festgelegt. In ihm werden die Klassen (Objekte gemeinsamen
Typs) und die dazugehörigen Attribute definiert.
Die Anordnung und Nennung der Attribute und einem Objekt übergeordneter
Objekte im Eintragsnamen eines Objekts spiegeln dabei die
Hierarchie wieder, in der sich ein Objekt befindet.
Im Verzeichnis selbst lassen sich dazu die Objekte in einer
baumartigen Struktur anordnen.
In unserem Fall wäre das einzelne Objekt der Anwender
als Person, die mit einzelnen Merkmalen ausgestattet ist (Name,
Adresse, E-Mail-Adresse usw.), sein Public Key und sein Zertifikat.
Der Public Key wird zusammen mit den Daten des Besitzers in
das Verzeichnis nach obigem Schemata eingestellt.
Der Key wiederum ist einer Zertifizierungsinstanz (CA) untergeordnet,
die als übergeordnetes Objekt die Einheit Person/Anwender-Public-Key
zertifiziert hat.
Über einzelnen Zertifizierungsstellen kann im Verzeichnis
wiederum eine einzelne Haupt-CA als oberste Zertifizierungsinstanz
angesiedelt sein, die die untergeordneten CA's zertifiziert
hat.
Ein Verzeichnis (sei es ein E-mail Adressverzeichnis oder ein Verzeichnis aus CA's, Anwendern und ihren Schlüsseln) wird heute meistens über das LDAP (Leightweight Directory Access Protocol) durchsucht und abgefragt (wie es auch bei PGP und den meisten E-mail Readern der Fall ist).
Die Zertifikate werden nach dem X.509 Standard erstellt.
X.509 spezifiziert den Authentifizierungsdienst für Verzeichnisse,
die nach Standard X.500 aufgebaut sind und beruht auf kryptografischen
Methoden nach PKCS. Gleichzeitig legt X.500 die Syntax eines
Zertifikats fest, die der Namensstruktur eines Objekteintrages
in einem X.500 Verzeichnis folgt. Zusätzlich beinhaltet
der Standard die Vorschriften, wie die Syntax der Certificate
Revocation Lists (CRL) aussieht, also die Listen der Keys,
die als ungültig erklärt, zurückgerifen wurden.
Beides zusammengenommen bezeichnet man auch als Public-Key Infrastructure (PKI).
Zusammengefasst liegt also bei einem S/MIME-Key der Schlüssel
in Form eines Zertifikats vor, der den Standards nach X.500
und 509 entspricht.
Er enthält sowohl die einzelnen Daten zur Person des
Keybesitzers, den Public Key selbst und (bei Zertifizierung
durch eine CA) das Zertifikat der Zertifizierungsstelle.
Auch bei einem S/MIME-Key besteht der Schlüssel aus einem
Schlüsselpaar aus privatem und öffentlichen Schlüssel,
beide Keys werden auch auf dem gleichen Weg der asymmetrischen
Verschlüsselung angewendet (wie zu Anfang der Anleitung
erwähnt).
Das Schlüsselpaar kann entweder vom Anwender selbst erzeugt
werden, oder wie bei den staatlich anerkannten Trustcentern
in und durch die Zertifizierungsstelle.
Bei S/MIME Keys können in einer PKI, die auf Direct-Trust
beruht, die Anwender die Keys anderer Anwender zertifizieren
(analog zum PGP Web-of-Trust). Bei einer PKI, die auf Trust-Chaining
beruht, steht im Vordergrund die Hierarchie aus Stamm-CA und
Unter-CA's, von denen eine CA die "Echtheit" eines
Keys zertifiziert.
D. h. das Vertrauen des Anwenders in die Stamm-CA wird über
die Unter-CA zum letztendlichen Key "durchgereicht"
oder "vererbt" (analog zu den PGP CA's, die PGP-Keys
zertifiziert haben).
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 OpenPGPs PKI is better than an X.509 PKI" von P. Zimmermann auf der Site der OpenPGP Allianz.
Schlüsselzertifikate oder "Wie signiere ich die Public Keys anderer Personen ?"
Voraussetzung für das Signieren anderer Public Keys ist das Lesen des Kapitels "Web of Trust".Vorgehensweise
- Aufruf von PGPkeys
- a) Menü "Keys - Sign" oder
b) 1xMKrT auf den betreffenden Key und im Kontextmenü "Sign" wählen - Button "More Choices" anklicken
Signiermöglichkeiten (Signature Type)
- Non-Exportable
bei der nicht exportierbaren Signatur verbleibt die Signatur nur im eigenen Pubring, sie wird nicht mit übertragen, wenn man den Key abspeichert, in eine E-mail Nachricht einfügt oder an einen Keyserver sendet.
Diese Signatur sollte man wählen, wenn man z.B. schon einen dauerhaften E-mailverkehr mit einer Person pflegt und sich daraufhin ziemlich sicher ist, dass der Key dem Keybesitzer gehört und deshalb im PGPkeys Window und den Bestätigungsfenstern den Key als echt ausgewiesen sehen möchte. - Exportable
die exportierbare Signatur ist die eigentliche Signatur im herkömmlichen Sinne, wie wir sie auch von PGP 2.6.3 kennen.
Sie wird beim Abspeichern eines Keys, beim Versenden des Keys per E-mail oder an einen Keyserver mit übertragen und bestätigt somit gegenüber der Öffentlichkeit, dass der Key wirklich dem Keybesitzer gehört und nicht gefälscht ist.
Aus diesem Grund sind bei Wahl der exportierbaren Signatur die Prinzipien des "Web of Trust" unbedingt zu beachten und anzuwenden ! - Meta-Introducer Non-Exportable und
Trusted Introducer Exportabledurch unsere Signatur wird der Key eines Meta-Introducers (oberster, vertrauenswürdiger Bürge) voll vertrauenswürdig (trusted) und gültig (valid).
Public Keys, die mit dem Key des Meta-Introducers signiert sind, werden automatisch voll gültig (valid).
Die Signatur des Meta-Introducers ist nicht exportierbar, da er eine herrausragende Stellung besitzt und seine Funktion innerhalb eines geschlossenen Rahmens (wie dem Netzwerk einer Firma oder unserem Pubring) verbleiben muss.Seine Auszeichnung (und damit seine Eigenschaften) durch unsere Signatur kann der Meta-Introducer quasi an weitere Personen, bzw. Keys (die Trusted-Introducer) durch dessen Signierung "vererben".
Public Keys, die mit dem Key des Meta-Introducers als Trusted-Introducer signiert sind, werden automatisch voll gültig (valid) und vertrauenswürdig (trusted), die Signatur des Trusted-Introducer ist exportierbar.
D. h. er kann auch ausserhalb unseres geschlossenen Rahmens für die Gültigkeit anderer Public Keys bürgen, allerdings kann man den Domainbereich einschränken, in dem er für Keys bürgen kann, in dem man unter "Domain restriction" die E-mail Domains der Keys eingibt.
Public Keys, die mit dem Key des Trusted-Introducers signiert sind, werden also automatisch voll gültig (valid) aber nicht vertrauenswürdig (trusted), d. h. diese Keys werden als gültig anerkannt, können aber nicht weitere Public Keys als gültig oder vertrauenswürdig auszeichnen.
Die Trusted-Introducer können diese Eigenschaft also nicht weiter vererben.
Der Meta-Introducer und die ihn stellvertretenden Trusted-Introducer "signieren" also quasi "stellvertetend" für uns selbst.Im PGPkeys Fenster findet sich unter dem Key des Meta-Introducers als Ausweis unsere Signatur mit der Beschreibung: "RSA,DH/DSS meta-introducer signature", bei dem Trusted-Introducer "RSA,DH/DSS trusted-introducer signature".
In der Desktop Security Version von PGP mit PGPadmin Funktion kann der Corporate Signing Key (der oberste Signaturschlüssel eines Unternehmens) als Meta-Introducer konfiguriert werden. Der Besitzer des Corporate Signing Keys übernimmt damit als Meta-Introducer die Funktion einer Certification Authority (CA).
- Non-Exportable
- Expiration (Verfallsdatum)
hier kann noch angegeben werden, ob unsere Signatur immer gültig (never) oder zu einem bestimmten Datum ungültig werden soll.
- Eingabe der Passphrase
Zu den Begriffen Vertrauen in einen Keybesitzer (Trust) und Gültigkeit des Keys des Keybesitzers (Validity) siehe Web of Trust
Es ist mit PGP 5/6 möglich, einen RSA Public Key mit einer
DSS Signatur zu versehen.
Aus Gründen der Kompatibilität sollte man aber einen RSA Public
Key auch mit einem RSA Key signieren.
Nach dem Signieren kann der unterschriebene Key an den Besitzer und/oder die Keyserver versendet werden, je nach Typ wie in den Erklärungen der vorhergehenden Kapitel.
Das Konzept der Hierarchie von Meta-Introducer und Trusted-Introducer
zielt auf Bereiche ab, in dem grosse Mengen an Public Keys
und verschiedene Bereiche (Domains), aus dem diese Keys stammen,
verwaltet werden müssen.
So wäre es denkbar, dass der Personalleiter oder Prokurist
einer Firma von der Geschäftsführung, die im Besitz des Corporate
Signing Keys mit Meta-Introducer Merkmal ist, zum Trusted-Introducer
ernannt wird, der wiederum durch die Signierung der Keys seiner
ihm Untergebenen dessen Keys unternehmensweit als gültig auszeichnet.
Oder der Hauptverkaufsleiter ernennt als Meta-Introducer die
Gebietsverkaufsleiter zu Trusted-Introducern, die wiederum
die Keys der einzelnen Aussendienstmitarbeiter signieren,
um sie im Unternehmen als gültig zu kennzeichnen.
Für einen lokalen Pubring auf einem Einzelplatz-PC ist dieses
Konzept überdimensioniert, da man ja selbst quasi der Meta-Introducer
ist.
Es kann aber sinnvoll sein, die Root-Keys von anerkannten
oder bekannten Zertifizierungsstellen
(Certification Authorities), deren Gültigkeit man nach
den Prinzipien des Web of Trust überprüft hat und deren Zertifizierungstechnik
man vertraut, mit einer Meta-Introducer Signatur und die Zertifizierungs-Keys
der CA's ab einer bestimmten Stufe (z. B. bei TC TrustCenter
ab Class 3) mit einer Trusted-Introducer Signatur auszustatten,
wodurch alle aktuellen und zukünftigen Public Keys, die von
diesen Stellen zertifiziert wurden, sogleich gültig sind und
von uns nicht mehr überprüft werden müssen.
Signieren eines Public Keys bei PGP 2.6.3:
PGP 2.6.3> pgp -ks User-ID-des-Keys Eigene-User-ID LW:\pubring.pgp |