Public-Key-Infrastruktur

Grundidee und Zertifikatsketten

Eine Public-Key-Infrastruktur (PKI, englisch public key infrastructure) ist in der Kryptologie ein System zum Ausstellen, Verteilen und Prüfen digitaler Zertifikate. Sie dient dazu, rechnergestützte Kommunikation abzusichern.

Sie baut auf asymmetrischen Kryptosystemen auf. Damit können Nachrichten digital signiert und verschlüsselt werden. Für eine verschlüsselte Nachricht benötigt der Sender den öffentlichen Schlüssel des Empfängers. Dieser Schlüssel kann zwar etwa per E-Mail oder von einer Webseite übermittelt werden, dabei muss aber sicher sein, dass er wirklich zum angegebenen Empfänger gehört und nicht von einem Betrüger stammt.

Diese Zuordnung bestätigt ein digitales Zertifikat. Es beglaubigt die Authentizität eines öffentlichen Schlüssels sowie dessen zulässigen Anwendungs- und Geltungsbereich. Das Zertifikat selbst ist durch eine digitale Signatur geschützt; deren Echtheit lässt sich mit dem öffentlichen Schlüssel des Ausstellers prüfen. Auch dieser Ausstellerschlüssel wird normalerweise durch ein Zertifikat abgesichert. So entsteht eine Kette von Zertifikaten, ein Validierungspfad oder Zertifizierungspfad. Das letzte Zertifikat beziehungsweise der dadurch bestätigte Schlüssel muss als Vertrauensanker ohne weiteres Zertifikat akzeptiert werden.

Bestandteile und Regeln einer PKI

Zentrale Bestandteile sind digitale Zertifikate, also digital signierte elektronische Daten zum Nachweis der Echtheit von Objekten. Die Zertifizierungsstelle (Certificate Authority, CA) stellt das CA-Zertifikat bereit und signiert Zertifikatsanträge.

Anträge werden bei der Registrierungsstelle (Registration Authority, RA) gestellt. Sie prüft Daten von Personen, Maschinen oder untergeordneten Zertifizierungsstellen und genehmigt den Antrag gegebenenfalls. Bei manueller Prüfung übernimmt dies ein Registration Authority Officer. Die CA kann die Informationen des genehmigten Antrags signieren; dadurch entsteht das gewünschte Zertifikat.

Eine Zertifikatsperrliste (Certificate Revocation List, CRL) enthält Zertifikate, die vor Ablauf ihrer Gültigkeit zurückgezogen wurden, etwa bei kompromittiertem Schlüsselmaterial, ungültigen Zertifikatsdaten oder beim Verlassen einer Organisation. Sie hat eine festgelegte Laufzeit und wird danach aktualisiert. Als Alternative kann eine White-List verwendet werden, die nur aktuell gültige Zertifikate enthält. Eine PKI muss grundsätzlich eine Zertifikatsstatusprüfung anbieten: offline durch CRL oder White-List oder online, beispielsweise durch OCSP oder SCVP. Online-Prüfungen sind besonders wichtig, wenn der genaue Zeitpunkt zählt, etwa bei finanziellen Transfers.

Ein Verzeichnisdienst ist ein durchsuchbares Verzeichnis ausgestellter Zertifikate, meist ein LDAP-Server, seltener ein X.500-Server. Ein Validierungsdienst (Validation Authority, VA) ermöglicht Echtzeitprüfungen, etwa mit OCSP oder SCVP. Subscriber sind Zertifikatsinhaber, beispielsweise Personen, Services, Server oder Router; Participants sind Nutzer, die Zertifikaten vertrauen.

Dokumentationen legen Arbeitsprinzipien fest, etwa Registrierung, Umgang mit privaten Schlüsseln, zentrale oder dezentrale Schlüsselerzeugung, technischen Schutz und rechtliche Zusicherungen. Die Certificate Policy (CP) beschreibt die Anforderungen an die Arbeitsweise und erlaubt Dritten, Vertrauenswürdigkeit zu bewerten. Das Certification Practice Statement (CPS) beschreibt die konkrete Umsetzung der CP; ein Policy Disclosure Statement (PDS) ist ein Auszug daraus. Für CP und CPS bestehen Vorgaben nach RFC 3647.

Hierarchisches Vertrauen und Schutz der Root-CA

In einer streng hierarchischen PKI vertrauen alle Beteiligten einer obersten Zertifizierungsstelle, der Root-CA. Eine globale Root-CA gibt es in der Praxis nicht: Länder und multinationale Unternehmen betreiben eigene hierarchische PKIs, vor allem um ihre Regeln vollständig selbst zu kontrollieren.

Die Zertifikate der Root-CA heißen Stamm- oder Wurzelzertifikate (root certificates) und bilden die Vertrauensanker. Wichtige Stammzertifikate sind oft in Software integriert. Welche Anforderungen bei der Zertifikatsausstellung gelten und wofür Zertifikate vertrauenswürdig sind, lässt sich jedoch nur aus der jeweiligen PKI-Dokumentation ableiten.

Der private Schlüssel der Root-CA muss ausschließlich der ausstellenden Partei bekannt sein. Deshalb wird die Root-CA physisch geschützt, etwa durch Zugang nur für Berechtigte nach dem Vier- oder Mehr-Augen-Prinzip, und üblicherweise offline ohne externen Netzwerkzugang betrieben. Schlüssel der nächsten Ebene werden in einer Schlüsselzeremonie nach festem Protokoll erzeugt oder signiert. Teilweise löschen Systeme Schlüssel bei Öffnung oder Erschütterung automatisch. Weil bei Verlust eines privaten Root-Schlüssels die gesamte Hierarchie neue Zertifikate bräuchte, müssen Stammzertifikate sicher wiederherstellbar sein; dafür werden Schlüssel oft aufgeteilt und mehreren Personen zur Verwahrung gegeben.

Die laufende Verarbeitung von Signatur- und Verschlüsselungsanforderungen übernehmen Unterzertifikate, die vom Stammzertifikat signiert sind. Sie gelten meist wenige Monate bis Jahre, während Stammzertifikate in der Regel mehrere Jahre oder Jahrzehnte gelten. Die Zertifikatskette wird meist mitgeliefert, damit Vertrauenswürdigkeit, Gültigkeit und möglicher Widerruf entlang der ganzen Kette geprüft werden können. SSL-Zertifikatsketten für Browser-Server-Kommunikation können durch HTTP Public Key Pinning gegen Man-in-the-Middle-Angriffe abgesichert werden.

Vertrauen zwischen verschiedenen PKIs

Zertifikate sind digitale Beglaubigungen. Entscheidend ist daher das Vertrauen zwischen dem Prüfer und dem Aussteller sowie die Art, wie dieses Vertrauen entsteht. Vertrauensmodelle werden in der Regel erst durch Zertifikate technisch umsetzbar.

Bei der Cross-Zertifizierung stellen zwei Zertifizierungsstellen, meist Stamminstanzen, einander Cross-Zertifikate aus. Sie drücken das Vertrauen gleichberechtigter Parteien aus. Regeln einer Stammzertifizierungsstelle sind für die andere PKI nicht verbindlich oder nur, soweit sie nicht deren eigenen Regeln widersprechen. Die Bedeutung dieser Vertrauensbeziehung kann deshalb schwierig oder nicht eindeutig sein.

Die Zahl bilateraler Cross-Zertifikate wächst quadratisch mit der Zahl der Zertifizierungsstellen: Bei 20 Stamminstanzen wären 380 Cross-Zertifikate nötig (20*19=380). Eine neutrale Bridge-CA kann dies vereinfachen, indem alle Stamminstanzen mit ihr Cross-Zertifikate austauschen. Über die Bridge-CA lassen sich Zertifikate der beteiligten PKIs aufeinander zurückführen. Dieses Modell heißt auch Hub and Spoke.

Das Web of Trust ist das Gegenmodell zur Zertifizierungshierarchie. PGP und GNU Privacy Guard nutzen es auf Grundlage von OpenPGP und sind zueinander kompatibel. Jedes Mitglied kann ein Zertifikat erzeugen und den öffentlichen Schlüssel einer Person signieren, wenn es dessen Zuordnung für richtig hält. Andere entscheiden anhand dieser Signatur selbst, ob sie dem Schlüssel vertrauen. Je mehr Zertifikate an einem Schlüssel hängen, desto sicherer kann seine Zuordnung zum angegebenen Eigentümer erscheinen. Erzeugt eine Zertifizierungsstelle Zertifikate im Web of Trust und gibt Regeln vor, wird es teilweise hierarchisch.

Einsatz und Sicherheitsrisiken

Für größere Unternehmen oder Behörden kann sich der Aufbau einer eigenen PKI lohnen; kleinere Organisationen beziehen Zertifikate häufig von PKI-Dienstleistern. Im Mittelpunkt steht Software zum Betrieb der CA. Mitarbeiterzertifikate werden meist auf Chipkarten ausgegeben. Diese können zugleich Unternehmensausweis und Grundlage eines Single-Sign-on-Systems sein. Für Ersatzkarten sowie Widerruf von Karten und Zertifikaten reichen integrierte Verwaltungsfunktionen in mittelgroßen und großen Netzen oft nicht aus. Dafür gibt es kommerzielle Kartenmanagementsysteme, die managed Private Key Infrastructure (mPKI oder MPKI). Anwendungsfälle sind Windows-Anmeldung, Netzwerkzugriffskontrollrichtlinien sowie S/Mime-Signatur und -Verschlüsselung für gesicherte E-Mails.

Besonders kritisch ist der Schutz einer Zertifizierungsstelle gegen Angriffe. Anfang September 2011 wurde bekannt, dass Angreifer bei DigiNotar BV in den Niederlanden unbefugt Zertifikate für verschiedene Domains, unter anderem google.com, ausgestellt hatten. Diese Zertifikate wurden nachweislich für Man-in-the-Middle-Abhörangriffe auf iranische Bürger verwendet. Browser- und Betriebssystemhersteller entfernten die betroffenen CAs aus ihren Systemen. Dadurch galten auch legitime DigiNotar-Zertifikate nicht mehr als gültig, was wegen ihrer Nutzung in der staatlichen niederländischen Public-Key-Infrastructure ernste Folgen hatte.

Ein weiterer Angriffsvektor sind Hash-Kollisionen. Die Signatur eines Zertifikats beruht auf einem Hashwert über dessen Inhalt, der mit dem privaten Schlüssel der CA verschlüsselt wird. Hat ein zweites Zertifikat denselben Hashwert wie ein bereits signiertes Zertifikat, könnte dessen Signatur kopiert werden und auch das zweite Zertifikat beglaubigen. Da Hashfunktionen eine begrenzte Ausgabelänge haben, treten bei beliebigen Eingaben zwangsläufig Kollisionen auf. Je nach Algorithmus der CA können sie mehr oder weniger gezielt herbeigeführt werden.