Asymmetrische Kryptosysteme

Eine Public-Key-Infrastruktur (PKI) beruht auf asymmetrischen kryptografischen Verfahren. Dabei hat jede beteiligte Person oder Organisation ein Schlüsselpaar: einen öffentlichen Schlüssel (public-key), den alle kennen dürfen, und einen privaten Schlüssel (private-key), der geheim bleiben muss. Mit diesen Schlüsseln kann man Nachrichten verschlüsseln sowie digitale Signaturen erstellen und überprüfen.

Zertifikate

Wer jemandem eine verschlüsselte Nachricht schicken oder eine digitale Signatur überprüfen möchte, braucht den öffentlichen Schlüssel des Gegenübers. Genau hier liegt ein Grundproblem asymmetrischer Verfahren, das eine PKI lösen soll: Meist kann man sich den Schlüssel nicht persönlich übergeben. Er wird deshalb über ein unsicheres Netz wie das Internet übertragen oder öffentlich bereitgestellt.

Dann muss sichergestellt werden, dass der öffentliche Schlüssel wirklich zu der Person gehört, die ihn als ihren eigenen ausgibt. Sonst könnte jemand anderes unbemerkt einen eigenen Schlüssel unterschieben.

Dafür gibt es Zertifikate. Ein Zertifikat enthält einen öffentlichen Schlüssel und Angaben dazu, wem dieser Schlüssel gehört. Eine Zertifizierungsstelle bestätigt diese Zuordnung mit ihrer digitalen Signatur. Wer der Zertifizierungsstelle vertraut, kann so prüfen, ob der Schlüssel wirklich zur angegebenen Person oder Organisation gehört.

Wer ein Zertifikat erhält, prüft die Signatur der Zertifizierungsstelle. Ist sie gültig, stammen die Angaben im Zertifikat von der Zertifizierungsstelle und wurden nicht verändert – vorausgesetzt, man verwendet den richtigen öffentlichen Schlüssel der Zertifizierungsstelle.

Ausstellung von Zertifikaten

Zertifikate werden von Zertifizierungsstellen (Certification Authorities, kurz CA) ausgestellt. Vorher prüft die CA, ob die beantragende Person oder Organisation die angegebene Identität oder Domain (zum Beispiel einen Website-Namen wie inf-schule.de) wirklich nutzen darf. Danach signiert die CA die Zertifikatsdaten mit ihrem privaten Schlüssel. Zertifizierungsstellen müssen strenge Sicherheitsanforderungen erfüllen. Welche Zertifizierungsstellen ein Browser standardmäßig als vertrauenswürdig anerkennt, bestimmen vor allem die Hersteller von Browsern und Betriebssystemen.

Überprüfung von Zertifikaten

Um ein Zertifikat zu überprüfen, kontrolliert man vor allem, ob die digitale Signatur der Zertifizierungsstelle gültig ist. Dafür braucht man den öffentlichen Schlüssel der Zertifizierungsstelle. Außerdem prüft man, ob das Zertifikat zum gewünschten Gegenüber gehört, ob es noch nicht abgelaufen ist und ob die ausstellende Zertifizierungsstelle vertrauenswürdig ist.

Doch wer garantiert, dass der öffentliche Schlüssel der Zertifizierungsstelle wirklich zu ihr gehört? Auch dafür verwendet man Zertifikate: Eine übergeordnete Zertifizierungsstelle bestätigt diesen Schlüssel.

So entsteht eine Kette von Zertifizierungsstellen. An der Spitze dieser Kette steht eine oberste Zertifizierungsstelle (Root-CA). Ihr eigenes Zertifikat heißt Wurzelzertifikat (Root-Zertifikat). Es ist selbstsigniert, die Root-CA hat es also mit ihrem eigenen privaten Schlüssel signiert. Dadurch allein ist es aber noch nicht vertrauenswürdig. Vertrauenswürdig wird es erst, weil es in einem Vertrauensspeicher (Trust Store) des Browsers oder Betriebssystems hinterlegt ist. Welche Wurzelzertifikate dort aufgenommen werden, entscheiden die Hersteller von Browsern und Betriebssystemen.

Zusammenspiel der Beteiligten

In der folgenden Abbildung wird das Zusammenspiel aller Beteiligten nochmal verdeutlicht. Dargestellt ist ein vereinfachtes Beispiel mit einer Root-CA, deren Root-Zertifikat im Trust Store hinterlegt ist. Die Abbildung und der folgende Text verwenden die Begriffe public-key (öffentlicher Schlüssel) und private-key (privater Schlüssel).

Alice möchte dem Online-Händler Bob eine vertrauliche Nachricht schicken. Dafür braucht sie Bobs public-key. Bekommt sie ihn einfach über das Internet, könnte ihr jemand unbemerkt einen falschen public-key unterschieben. Ein überprüftes Zertifikat schützt vor diesem Angriff: Eine vertrauenswürdige Zertifizierungsstelle (CA) bestätigt mit ihrer digitalen Signatur, dass der public-key zu Bob gehört.

Die Abbildung zeigt den Ablauf in folgenden Schritten:

0. Vertrauensanker hinterlegen: Die Hersteller von Browsern und Betriebssystemen legen die Root-Zertifikate vertrauenswürdiger Zertifizierungsstellen im Trust Store ab. Das geschieht schon vorher, zum Beispiel bei der Installation oder bei Updates.
1. Zertifikat beantragen: Bob erzeugt ein Schlüsselpaar und beantragt bei der CA ein Zertifikat für seinen public-key. Die CA prüft Bobs Identität.
2. Zertifikat signieren: Die CA signiert die Zertifikatsdaten (Aussteller, Identität, public-key, Gültigkeit) mit ihrem private-key. Bob erhält das fertige Zertifikat.
3. Zertifikat senden: Bob sendet sein Zertifikat an Alice.
4. CA public-key bereitstellen: Alice sucht in ihrem Trust Store das Root-Zertifikat der CA, die Bobs Zertifikat ausgestellt hat. Daraus nimmt sie den CA public-key. Die CA muss ihn ihr also nicht schicken.
5. Zertifikat prüfen: Alice prüft die Signatur mit dem CA public-key. Außerdem kontrolliert sie, ob der Name im Zertifikat zum gewünschten Gegenüber passt, ob das Zertifikat noch nicht abgelaufen ist und ob es zurückgezogen (widerrufen) wurde.
6. Nachricht verschlüsseln: Nur wenn das Zertifikat gültig ist, verschlüsselt Alice ihre Nachricht mit Bobs public-key und sendet sie an Bob.
7. Nachricht entschlüsseln: Bob entschlüsselt die Nachricht mit seinem private-key. Dieser bleibt geheim und wird nicht übertragen.

Entscheidend ist Schritt 4: Alice vertraut dem CA public-key nicht, weil die CA ihn ihr schickt, sondern weil das Root-Zertifikat schon in ihrem Trust Store liegt. Das Vertrauen in eine PKI beginnt also beim Trust Store. Daraus ergibt sich eine wichtige Frage: Wer entscheidet eigentlich, welchen Zertifizierungsstellen mein Browser vertraut?

Vereinfachungen in der Abbildung:

• In der Praxis signieren meist Zwischenzertifizierungsstellen die Zertifikate. Alice prüft dann eine ganze Zertifikatskette bis zu einem Root-Zertifikat im Trust Store.
• Bei modernem TLS (z. B. TLS 1.3) dient das Zertifikat zur Authentifizierung. Die Kommunikationsschlüssel werden durch ein separates Schlüsselaustauschverfahren vereinbart. Anschließend werden die Daten symmetrisch verschlüsselt.
• Bei den verbreiteten Domain-Validated-Zertifikaten (DV) prüft die CA nur, ob die beantragende Stelle den Domainnamen kontrolliert. Wer hinter der Website steht, wird dabei nicht geprüft.