Public-Key-Infrastruktur

Mit Public-Key-Infrastruktur (PKI, englisch public key infrastructure) bezeichnet man in der Kryptologie ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung rechnergestützter Kommunikation verwendet.

Mit Hilfe eines asymmetrischen Kryptosystems können Nachrichten in einem Netzwerk digital signiert und verschlüsselt werden. Sichere Kryptosysteme können bei geeigneter Wahl der Parameter (z. B. der Schlüssellänge) auch bei Kenntnis des Verfahrens (vgl. Kerckhoffs’ Prinzip) zumindest nach heutigem Kenntnisstand^[1] nicht in überschaubarer Zeit gebrochen werden.

In asymmetrischen Kryptosystemen benötigt der Sender für eine verschlüsselte Übermittlung den öffentlichen Schlüssel (public key) des Empfängers. Dieser könnte z. B. per E-Mail versandt oder von einer Web-Seite heruntergeladen werden. Dabei muss sichergestellt sein, dass es sich tatsächlich um den Schlüssel des Empfängers handelt und nicht um eine Fälschung eines Betrügers.

Hierzu dienen nun digitale Zertifikate, die die Authentizität eines öffentlichen Schlüssels und seinen zulässigen Anwendungs- und Geltungsbereich bestätigen. Das digitale Zertifikat ist selbst durch eine digitale Signatur geschützt, deren Echtheit mit dem öffentlichen Schlüssel des Ausstellers des Zertifikates geprüft werden kann.

Um die Authentizität des Ausstellerschlüssels zu prüfen, wird wiederum ein digitales Zertifikat benötigt. Auf diese Weise lässt sich eine Kette von digitalen Zertifikaten aufbauen, die jeweils die Authentizität des öffentlichen Schlüssels bestätigen, mit dem das vorhergehende Zertifikat geprüft werden kann. Eine solche Kette von Zertifikaten wird Validierungspfad oder Zertifizierungspfad genannt. Auf die Echtheit des letzten Zertifikates (und des durch dieses zertifizierten Schlüssels) müssen sich die Kommunikationspartner ohne ein weiteres Zertifikat verlassen können.

• Digitale Zertifikate: Digital signierte elektronische Daten, die sich zum Nachweis der Echtheit von Objekten verwenden lassen.
• Zertifizierungsstelle (Certificate Authority, CA): Organisation, die das CA-Zertifikat bereitstellt und die Signatur von Zertifikatsanträgen übernimmt.
• Registrierungsstelle (Registration Authority, RA): Organisation, bei der Personen, Maschinen oder auch untergeordnete Zertifizierungsstellen Zertifikate beantragen können. Diese prüft die Richtigkeit der Daten im Zertifikatsantrag und genehmigt diesen gegebenenfalls. Bei einer manuellen Prüfung wird diese durch den Registration Authority Officer durchgeführt. Die Informationen aus dem genehmigten Antrag können dann durch die Zertifizierungsstelle signiert werden, wobei das gewünschte Zertifikat entsteht.
• Zertifikatsperrliste (Certificate Revocation List, CRL): Eine Liste mit Zertifikaten, die vor Ablauf der Gültigkeit zurückgezogen wurden. Gründe sind die Kompromittierung des Schlüsselmaterials, aber auch Ungültigkeit der Zertifikatsdaten (z. B. E-Mail) oder Verlassen der Organisation. Eine Zertifikatsperrliste hat eine definierte Laufzeit, nach deren Ablauf sie erneut aktualisiert erzeugt wird. Anstatt der CRL kann auch eine Positivliste, die sogenannte White-List verwendet werden, in die nur alle zum aktuellen Zeitpunkt gültigen Zertifikate eingetragen werden. Prinzipiell muss eine PKI immer eine Zertifikatsstatusprüfung anbieten. Hierbei können jedoch neben der CRL (oder der White-List) als Offline-Statusprüfung auch sogenannte Online-Statusprüfungen wie OCSP oder SCVP zum Einsatz kommen (siehe Validierungsdienst). Online-Statusprüfungen werden üblicherweise dort eingesetzt, wo die zeitgenaue Prüfung des Zertifikates wichtig ist z. B. bei finanziellen Transfers etc.
• Verzeichnisdienst (Directory Service): ein durchsuchbares Verzeichnis, das ausgestellte Zertifikate enthält, meist ein LDAP-Server, seltener ein X.500-Server.
• Validierungsdienst (Validation Authority, VA): Ein Dienst, der die Überprüfung von Zertifikaten in Echtzeit ermöglicht wie OCSP oder SCVP.
• Dokumentationen: Eine PKI führt eines oder mehrere Dokumente, in denen die Arbeitsprinzipien der PKI beschrieben sind. Kernpunkte sind der Registrierungsprozess, Handhabung des privaten Schlüssels, zentrale oder dezentrale Schlüsselerzeugung, technischer Schutz der PKI-Systeme sowie eventuell rechtliche Zusicherungen. In X.509-Zertifikaten kann das CPS in den Extensions eines Zertifikates verlinkt werden. Die nachfolgend aufgeführten Dokumente sind teilweise üblich.
  • CP (Certificate Policy): In diesem Dokument beschreibt die PKI ihr Anforderungsprofil an ihre eigene Arbeitsweise. Es dient Dritten zur Analyse der Vertrauenswürdigkeit und damit zur Aufnahme in den Browser.
  • CPS (Certification Practice Statement): Hier wird die konkrete Umsetzung der Anforderungen an die PKI beschrieben. Dieses Dokument beschreibt die Umsetzung der CP.
  • PDS (Policy Disclosure Statement): Dieses Dokument ist ein Auszug aus dem CPS, falls das CPS nicht veröffentlicht werden soll.

Weitere:

• Subscriber: Der Inhaber eines Zertifikates. Dies können Services, Personen, Server, Router oder ähnliche sein.
• Participant: Nutzer der Zertifikate (diejenigen, die diesen vertrauen).

Für die Dokumente CP und CPS existieren standardisierte Vorgaben zum Inhalt und Umfang, siehe RFC= 3647.^[2]

Zertifikate stellen im Wesentlichen digitale Beglaubigungen dar. Somit stellt das Vertrauen zwischen dem Prüfer und dem Aussteller eines Zertifikates sowie die Art und Weise, wie dieses Vertrauen zustande kommt, die wesentliche Basis für die Verwendung digitaler Zertifikate dar. Umgekehrt lassen sich solche Vertrauensmodelle in der Regel erst durch Zertifikate technisch umsetzen.

Oft werden Zertifikate innerhalb einer komplett hierarchischen PKI eingesetzt. Dieses Vertrauensmodell setzt die Existenz einer Stammzertifizierungsinstanz (Root-CA) voraus: einer obersten Zertifizierungsstelle, der alle teilnehmenden Parteien vertrauen. In der Praxis gibt es jedoch auf globaler Ebene eine solche Instanz nicht. So betreiben etwa verschiedene Länder und multinationale Unternehmen jeweils eigene hierarchische PKIs mit eigenen Stammzertifizierungsinstanzen. Die Ursache dafür liegt weniger in mangelndem Vertrauen in andere PKIs oder Stammzertifizierungsinstanzen, als vielmehr im Wunsch nach vollständiger Kontrolle der Regeln innerhalb der eigenen PKI.

Die Zertifikate einer Stammzertifizierungsinstanz werden als Stammzertifikate oder Wurzelzertifikate (englisch root certificates) bezeichnet und stellen die Vertrauensanker der PKI dar. Stammzertifikate von wichtigen Root-CAs sind oft in die verarbeitende Software integriert. Problematisch dabei ist jedoch, dass Aussagen über die Anforderungen für die Ausstellung der Zertifikate – und damit über ihre Vertrauenswürdigkeit und zulässige Anwendungsbereiche – nur über die jeweilige PKI-Dokumentation (siehe oben) getroffen werden können.

Da das Stammzertifikat und damit die gesamte Zertifikatshierarchie nur vertrauenswürdig bleibt, solange dessen privater Schlüssel (der auf der Root-CA gespeichert ist) ausschließlich der ausstellenden Partei bekannt ist, kommt dem Schutz der Root-CA höchste Bedeutung zu. Sie wird deshalb in der Regel sowohl physisch geschützt (durch Sicherung des Zugangs und Zugang nur durch berechtigte Personen bzw. Personengruppen im Vier- oder Mehr-Augen-Prinzip^[3]) wie auch ausschließlich „offline“ betrieben, d. h. ohne Zugang über ein Netzwerk von außen. Schlüssel der nächsten Ebene werden im Rahmen einer sogenannten Schlüsselzeremonie nach genau definiertem Protokoll erzeugt bzw. signiert.^[4] Häufig ist der Root-CA-Rechner auch gegen physische Manipulationen von außen geschützt, z. B. werden oft bei Öffnung oder Erschütterung die Schlüssel automatisch gelöscht. Da mit dem Verlust der privaten Schlüssel (z. B. durch Hardwaredefekt) die gesamte hierarchische PKI mit neuen Zertifikaten versehen werden müsste, ist es daneben erforderlich, ein sicheres Verfahren zur Wiederherstellung der Stammzertifikate zu etablieren. Dazu werden die Schlüssel oft aufgeteilt und an mehrere Personen zur Verwahrung verteilt. Die Schlüsselteile müssen im Falle der Wiederherstellung des Stammzertifikats durch die entsprechenden Personen beigebracht und erneut eingegeben werden.^[5]

Aufgrund des hohen Schutzbedürfnisses der Root-CA erfolgt die automatische Verarbeitung von Signatur- oder Verschlüsselungsanforderungen mit Unterzertifikaten, die mit dem Stammzertifikat signiert wurden und eine kürzere Gültigkeit (meist wenige Monate bis Jahre) als das Stammzertifikat (das in der Regel mehrere Jahre oder Jahrzehnte gilt) aufweisen. Die Gültigkeit der Unterzertifikate wird so gewählt, dass es als unwahrscheinlich angesehen werden kann, dass die zum Zertifikat gehörenden privaten Schlüssel innerhalb des gewählten Gültigkeitszeitraums mit derzeit verfügbarer Rechenkapazität berechnet werden können. Auf diese Weise entsteht eine Zertifikatskette, bei der jeweils auf das unterzeichnende Zertifikat als ausgebende Stelle verwiesen wird. Diese Kette wird in der Regel als Teil eines Zertifikats mitgeliefert, um eine Prüfung bezüglich Vertrauenswürdigkeit, Gültigkeit und ggf. vorhandenem Zertifikatswiderruf entlang der gesamten Zertifikatskette zu ermöglichen. SSL-Zertifikatsketten, die zur Absicherung der Browser-Server-Kommunikation eingesetzt werden, können durch HTTP Public Key Pinning geprüft und gegen Man-in-the-middle Angriffen abgesichert werden.

Eine Möglichkeit, die Anwendung von Zertifikaten über die Grenzen verschiedener hierarchischer PKIs hinweg zu ermöglichen, ist die Cross-Zertifizierung. Dabei stellen sich zwei Zertifizierungsstellen (meist Stamminstanzen) gegenseitig ein (Cross-)Zertifikat aus. Im Unterschied zu normalen Zertifikaten in einer hierarchischen PKI drücken Cross-Zertifikate das Vertrauen zweier gleichberechtigter Parteien aus, d. h. die Regelungen der einen Stamminstanz sind für die PKI der anderen Stamminstanz nicht verbindlich, oder nur insoweit verbindlich, als sie deren eigenen Regelungen nicht widersprechen. Die Interpretation der durch ein Cross-Zertifikat ausgedrückten Vertrauensbeziehung ist daher manchmal nicht einfach und in vielen Fällen nicht einmal eindeutig.

Ein weiteres Problem der bilateralen Cross-Zertifizierung ist, dass die Anzahl der Cross-Zertifikate quadratisch mit der Anzahl von Zertifizierungsstellen steigt. So wären z. B. bei 20 Stamminstanzen 380 Cross-Zertifikate zwischen diesen Stamminstanzen notwendig (20*19=380). Eine Lösung dafür wäre die Cross-Zertifizierung aller Stamminstanzen mit einer neutralen Bridge-CA. Diese tauscht mit allen beteiligten Stamminstanzen Cross-Zertifikate aus, so dass sich die Zertifikate jeder PKI über die Cross-Zertifikate der Bridge-CA auf die Zertifikate jeder anderen beteiligten PKI zurückführen lassen. Die Bridge-CA stellt also einen Mittelpunkt der Vertrauensbeziehungen der Stamminstanzen dar. Aus diesem Grund wird das durch eine Bridge-CA induzierte Vertrauensmodell im englischen Sprachraum auch als Hub and Spoke bezeichnet.

Ein zur Zertifizierungshierarchie komplett konträres Vertrauensmodell wird durch die Verschlüsselungssoftware PGP und die Open-Source-Variante GNU Privacy Guard genutzt. Beide basieren auf OpenPGP und sind zueinander kompatibel. Ein Zertifikat kann von jedem Benutzer (Web-of-Trust-Mitglied) erzeugt werden. Glaubt ein Benutzer daran, dass ein öffentlicher Schlüssel tatsächlich zu der Person gehört, die ihn veröffentlicht, so erstellt er ein Zertifikat, indem er diesen öffentlichen Schlüssel signiert. Andere Benutzer können aufgrund dieses Zertifikates entscheiden, ob auch sie darauf vertrauen wollen, dass der Schlüssel zum angegebenen Benutzer gehört oder nicht. Je mehr Zertifikate an einem Schlüssel hängen, desto sicherer kann man sein, dass dieser Schlüssel tatsächlich dem angegebenen Eigentümer gehört.

Ein Zertifikat kann auch im Web of Trust von einer Zertifizierungsstelle erzeugt werden. Da eine Zertifizierungsstelle fast immer die Regeln für die Ausstellung und Nutzung der Zertifikate vorgibt, geht in diesem Fall das Web of Trust in ein teilweise hierarchisches Vertrauensmodell über.

Der Aufbau einer PKI kann sich für ein größeres Unternehmen oder eine größere Behörde lohnen. Kleinere Organisationen verzichten dagegen oft auf eine solche Maßnahme und beziehen ihre Zertifikate dafür von speziellen PKI-Dienstleistern. Im Mittelpunkt eines PKI-Aufbaus steht stets eine Software zum Betrieb der Zertifizierungsstelle (CA).

Zertifikate für Mitarbeiter werden zumeist gespeichert auf Chipkarten ausgegeben, die dadurch zum Unternehmensausweis werden und für verschiedene Anmeldeprozesse verwendet werden können. Sie werden damit die Basis für ein Single-Sign-on-System.

Die integrierten Möglichkeiten zur Verwaltung der ausgegebenen Chipkarten sind in Organisationen mit mittelgroßen und großen Netzwerken oftmals nicht ausreichend, so zum Beispiel bei der Ausstellung von Ersatzkarten oder dem Widerruf von Karten und Zertifikaten. Für die vereinfachte Verwaltung einer solchen Infrastruktur werden deshalb kommerzielle Kartenmanagementsysteme angeboten (sog. managed Private Key Infrastructure, kurz: mPKI oder MPKI).

Einige der wichtigsten Anwendungsfälle für die Implementierung von PKI-Lösungen sind Windows-Anmeldung, Netzwerkzugriffskontrollrichtlinien, gesicherte E-Mails (S/Mime-Signatur und -Verschlüsselung) und vieles mehr.

Kritisch ist der Schutz der Zertifizierungsstelle selbst gegen Hacker-Angriffe von außen. So wurde Anfang September 2011 bekannt, dass sich Angreifer bei der niederländischen Firma DigiNotar BV unbefugt Zertifikate für diverse Domains (u. a. google.com) ausgestellt hatten.^[6] Diese wurden nachweislich für Abhörangriffe (mittels Man-in-the-Middle-Angriff) auf iranische Bürger benutzt.^[7][8] Die betroffenen CAs wurden daraufhin von den wichtigsten Browser- und Betriebssystemherstellern aus deren Systemen gestrichen. Dadurch werden auch legitime Zertifikate von DigiNotar nicht mehr als gültig anerkannt, was ernste Folgen für die IT-Infrastruktur hat, da Zertifikate von DigiNotar in den Niederlanden auch für die staatliche Public-Key-Infrastructure benutzt werden.^[9]

Ein weiterer Angriffsvektor ist die Verwendung von Hash-Kollisionen auf von der PKI ausgestellte Zertifikate. Die Signatur eines Zertifikats stellt einen Hashwert über den Inhalt dar, welcher anschließend mit dem Private Key der CA verschlüsselt wird und somit die Echtheit des Zertifikats bestätigt. Daraus folgt: besäße man ein Zertifikat, welches den gleichen Hashwert besitzt wie ein bereits von einer CA signiertes, so kann die Signatur kopiert werden und beglaubigt damit ein zweites Zertifikat. Da Hashfunktionen immer auf eine gewisse Ausgabelänge beschränkt sind, folgt zudem, dass bei beliebiger Eingabe zwangsläufig Kollisionen auftreten können. Abhängig von dem verwendeten Algorithmus der CA können diese mehr oder weniger zielgerichtet herbeigeführt werden.

• Norbert Pohlmann: Cyber-Sicherheit: Das Lehrbuch für Konzepte, Prinzipien, Mechanismen, Architekturen und Eigenschaften von Cyber-Sicherheitssystemen in der Digitalisierung. Springer Vieweg, 2019, ISBN 3-658-25397-5 (Seiten 115–149)
• Klaus Schmeh: Kryptografie. Verfahren, Protokolle, Infrastrukturen. dpunkt, Heidelberg 2007, ISBN 978-3-89864-435-8.
• Brian Komar: Microsoft Windows Server 2008 PKI- und Zertifikat-Sicherheit. Microsoft Press Deutschland, 2008, ISBN 978-3-86645-648-8.
• Patrick Huber: Aufbau und Funktion von Public Key Infrastrukturen. GRIN Verlag, München 2018, ISBN 978-3-668-80088-5.

• Open-source PKI Book

1. ↑ Sönke Maseberg: Fail-Safe-Konzept für PKIs. (PDF) 1. Februar 2003, archiviert vom Original (nicht mehr online verfügbar) am 4. März 2016; abgerufen am 24. Oktober 2015. 
2. ↑ RFC 3647 – Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. November 2003 (englisch).
3. ↑ IANA Root KSK Ceremonies. Abgerufen am 24. Oktober 2015. 
4. ↑ DNSSEC KSK Ceremony 22. Abgerufen am 24. Oktober 2015. 
5. ↑ Zertifizierungsrichtlinie für die T-Systems Trust Center Public Key Infrastrukturen. 30. März 2015, archiviert vom Original (nicht mehr online verfügbar) am 22. November 2015; abgerufen am 24. Oktober 2015.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.telesec.de 
6. ↑ L. Aaron Kaplan, Otmar Lendl: Zwischenbericht DigiNotar Certificate Authority Hack und Relevanz für Österreich. (PDF; 120 kB) In: CERT.at. 8. September 2011, S. 5, archiviert vom Original (nicht mehr online verfügbar) am 6. Oktober 2011; abgerufen am 28. September 2011.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.cert.at 
7. ↑ Neuer SSL-Gau: Falsches Google-Zertifikat blieb fünf Wochen unentdeckt. heise.de, 30. August 2011, abgerufen am 28. September 2011. 
8. ↑ Gmail.com SSL MITM ATTACK BY Iranian Government. pastebin.com, 27. August 2011, abgerufen am 28. September 2011. 
9. ↑ Niederländische Regierung übernimmt Kontrolle über DigiNotar. heise.de, 5. September 2011, abgerufen am 28. September 2011.