Zusammenfassung
Das Grundproblem
Wer einer Person eine verschlüsselte Nachricht schicken oder ihre digitale Signatur prüfen möchte, braucht ihren public-key. Meist erhält man ihn über einen unsicheren Weg, z. B. per E-Mail, aus einem gemeinsamen Verzeichnis oder von einem Schlüsselserver. Name und E-Mail-Adresse in einem Schlüssel kann jede Person beliebig eintragen. Deshalb muss man klären, ob ein Schlüssel echt ist, also wirklich zu der angegebenen Person gehört.
Machine-in-the-Middle-Angriff
Bei einem Machine-in-the-Middle-Angriff schiebt sich ein Angreifer (Mr X) unbemerkt zwischen zwei Kommunizierende. Er gibt beiden Seiten seinen eigenen public-key als den des Gegenübers aus. So kann er alle Nachrichten entschlüsseln, lesen, verändern und neu verschlüsselt weiterleiten. Verschlüsselung allein schützt also nicht. Man muss zusätzlich sicherstellen, dass die verwendeten Schlüssel echt sind.
Schlüssel prüfen und zertifizieren
Der Fingerabdruck (Fingerprint) ist ein kurzer Prüfwert (Hashwert), der aus dem Schlüssel berechnet wird. Schon die kleinste Änderung am Schlüssel ergibt einen völlig anderen Fingerabdruck. Um einen Schlüssel zu prüfen, vergleicht man den Fingerabdruck Zeichen für Zeichen auf einem sicheren Weg mit der Person, z. B. bei einem Treffen.
Ist man sicher, dass ein Schlüssel echt ist, kann man ihn zertifizieren: Man signiert den Schlüssel zusammen mit den Angaben zur Person mit dem eigenen private-key. Damit bestätigt man: Dieser Schlüssel gehört zu dieser Person.
Web of Trust
Zertifizieren sich viele Personen gegenseitig ihre Schlüssel, entsteht ein Vertrauensnetz, das Web of Trust. Es gibt keine zentrale Stelle. Jede Person entscheidet selbst, welchen Schlüsseln sie vertraut.
Dabei muss man zwei Dinge unterscheiden:
- Ist der Schlüssel einer Person echt?
- Vertraut man dieser Person als Prüferin bzw. Prüfer, prüft sie also Schlüssel sorgfältig, bevor sie sie zertifiziert?
Ein fremder Schlüssel ist für mich nur dann gültig, wenn ihn eine Person zertifiziert hat, deren Schlüssel echt ist und der ich als Prüferin bzw. Prüfer vertraue.
Weil öffentliche Schlüssel und Zertifizierungen auch persönliche Daten verraten (Name, E-Mail-Adresse, wer wen kennt), verteilen heutige Schlüsselserver wie keys.openpgp.org Zertifizierungen durch andere standardmäßig nicht mehr. Das Web of Trust spielt deshalb heute kaum noch eine Rolle.
Public-Key-Zertifikat
Ein Public-Key-Zertifikat bestätigt, dass ein public-key zu einer bestimmten Person, Organisation oder Website gehört. Ausgestellt wird es von einer Zertifizierungsstelle (Certification Authority, kurz CA). Sie prüft vorher, ob die beantragende Stelle die angegebene Identität oder Domain wirklich nutzen darf.
Ein Zertifikat enthält u. a.:
- den public-key, der bestätigt wird,
- Angaben dazu, wem der Schlüssel gehört (Inhaber),
- Angaben dazu, wer das Zertifikat ausgestellt hat (Aussteller),
- die benutzten Verfahren und die Gültigkeitsdauer,
- die digitale Signatur der Zertifizierungsstelle, die alle Angaben bestätigt.
Das übliche Format ist X.509. Als Datei wird ein Zertifikat oft Base64-kodiert gespeichert (PEM-Format). Base64 ist nur eine Kodierung, keine Verschlüsselung.
Public-Key-Infrastruktur
Eine Public-Key-Infrastruktur (PKI) umfasst alles, was nötig ist, um Zertifikate auszustellen, zu verteilen und zu prüfen: Zertifizierungsstellen, Zertifikate, Regeln und Vertrauensspeicher.
Den public-key einer Zertifizierungsstelle bestätigt wiederum eine übergeordnete Zertifizierungsstelle. So entsteht eine Zertifizierungskette. An ihrer Spitze steht eine Root-CA mit einem selbstsignierten Wurzelzertifikat. Vertrauenswürdig ist dieses Zertifikat, weil es im Trust Store des Browsers oder Betriebssystems hinterlegt ist. Welche Wurzelzertifikate dort aufgenommen werden, entscheiden vor allem die Hersteller von Browsern und Betriebssystemen.
Beim Prüfen eines Zertifikats kontrolliert man,
- ob die Signatur gültig ist und sich die Kette bis zu einem Wurzelzertifikat im Trust Store zurückverfolgen lässt,
- ob der Name im Zertifikat zum gewünschten Gegenüber passt,
- ob das Zertifikat noch gültig und nicht widerrufen ist.
Schlägt eine dieser Prüfungen fehl, zeigt der Browser eine Warnung, z. B. NET::ERR_CERT_AUTHORITY_INVALID oder NET::ERR_CERT_DATE_INVALID.
Eine solche Warnung sollte man ernst nehmen und auf der Seite keine persönlichen Daten eingeben.
Web of Trust und PKI im Vergleich
| Web of Trust | Public-Key-Infrastruktur | |
|---|---|---|
| Wer bestätigt Schlüssel? | die Teilnehmenden gegenseitig | Zertifizierungsstellen |
| Aufbau | Netz ohne zentrale Stelle | Kette mit einer Root-CA an der Spitze |
| Grundlage des Vertrauens | eigene Prüfung und eigene Entscheidung, wem man als Prüferin bzw. Prüfer vertraut | Wurzelzertifikate, die im Trust Store vorinstalliert sind |
| typischer Einsatz | früher bei verschlüsselten E-Mails (OpenPGP) | Websites (HTTPS), aber auch E-Mail und Software |
HTTPS
HTTPS bedeutet: Webseiten werden wie bei HTTP übertragen, aber über eine Verbindung, die mit dem Protokoll TLS (Transport Layer Security, früher SSL) gesichert ist.
Beim Verbindungsaufbau schickt der Server sein Zertifikat. Der Browser prüft es mithilfe seines Trust Stores. Danach vereinbaren Browser und Server einen gemeinsamen Session-Key für ein schnelles symmetrisches Verfahren, mit dem alle weiteren Daten verschlüsselt werden. Das Zertifikat dient dazu, dass sich der Server ausweist (Authentifizierung). So kann sich kein Mr X unbemerkt dazwischenschieben.
Auch bei HTTPS bleibt sichtbar, mit welchem Server man verbunden ist. Unterseiten, Inhalte und eingegebene Daten wie Passwörter sind dagegen geschützt.