Public-Key-Infrastruktur

Aus Kryptowiki - Die freie Enzyklopädie der Kryptowährungen
Wechseln zu: Navigation, Suche
Schema einer Public-Key-Infrastruktur
CA: certification authority
RA: registration authority
VA: validation authority

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.

Konzept[Bearbeiten]

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.

Bestandteile einer PKI[Bearbeiten]

  • 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 gewünschten Zertifikat und genehmigt den Zertifikatsantrag, der dann durch die Zertifizierungsstelle signiert wird. Bei einer manuellen Prüfung wird diese durch den Registration Authority Officer durchgeführt.
  • 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 Zertifikatssperrliste 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 in 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).

Vertrauensmodelle in Public-Key-Infrastrukturen[Bearbeiten]

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.

Streng hierarchische PKI[Bearbeiten]

Oft werden Zertifikate innerhalb einer komplett hierarchischen PKI eingesetzt. Dieses Vertrauensmodell setzt die Existenz einer Wurzelzertifizierungsinstanz (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 Wurzelzertifizierungsinstanzen. Die Ursache dafür liegt weniger in mangelndem Vertrauen in andere PKIs oder Wurzelzertifizierungsinstanzen, als vielmehr im Wunsch nach vollständiger Kontrolle der Regeln innerhalb der eigenen PKI.

Die Zertifikate einer Wurzelzertifizierungsinstanz werden als Wurzelzertifikate oder Stammzertifikate bezeichnet, und stellen die Vertrauensanker der PKI dar. Wurzelzertifikate 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.

Anzeige einer Zertifikatskette in Windows

Da das Wurzelzertifikat 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 berechtige Personen bzw. Personengruppen im Vier- oder Mehr-Augen-Prinzip[2]) 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.[3] Häufig ist der RootCA-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 Root-Zertifikate 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 Root-Zertifikats durch die entsprechenden Personen beigebracht und erneut eingegeben werden.[4]

Aufgrund des hohen Schutzbedürfnisses der Root-CA erfolgt die automatische Verarbeitung von Signatur- oder Verschlüsselungsanforderungen mit Unterzertifikaten, die mit dem Rootzertifikat signiert wurden und eine kürzere Gültigkeit (meist wenige Monate bis Jahre) als das Root-Zertifikat (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.

Cross-Zertifizierung[Bearbeiten]

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 Wurzelinstanzen) 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 Wurzelinstanz sind für die PKI der anderen Wurzelinstanz 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 Wurzelinstanzen 380 Cross-Zertifikate zwischen diesen Wurzelinstanzen notwendig (20*19=380). Eine Lösung dafür wäre die Cross-Zertifizierung aller Wurzelinstanzen mit einer neutralen Bridge-CA. Diese tauscht mit allen beteiligten Wurzelinstanzen 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 Wurzelinstanzen dar. Aus diesem Grund wird das durch eine Bridge-CA induzierte Vertrauensmodell im englischen Sprachraum auch als Hub and Spoke bezeichnet.

Web of Trust[Bearbeiten]

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.

Implementierung einer PKI und Kartenmanagement[Bearbeiten]

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).

Sicherheitsaspekte[Bearbeiten]

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.[5] Diese wurden nachweislich für Abhörangriffe (mittels Man-in-the-Middle-Angriff) auf iranische Bürger benutzt.[6][7] 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.[8]

Literatur[Bearbeiten]

  • 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.

Externe Links[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Sönke Maseberg: Fail-Safe-Konzept für PKIs. 1. Februar 2003. Abgerufen am 24. Oktober 2015.
  2. IANA Root KSK Ceremonies. Abgerufen am 24. Oktober 2015.
  3. DNSSEC KSK Ceremony 22. Abgerufen am 24. Oktober 2015.
  4. Zertifizierungsrichtlinie für die T-Systems Trust Center Public Key Infrastrukturen. 30. März 2015. Abgerufen am 24. Oktober 2015.
  5. L. Aaron Kaplan, Otmar Lendl: Zwischenbericht DigiNotar Certificate Authority Hack und Relevanz für Österreich (PDF, 120kb) CERT.at. S. 5. 8. September 2011. Abgerufen am 28. September 2011.
  6. Neuer SSL-Gau: Falsches Google-Zertifikat blieb fünf Wochen unentdeckt. heise.de. 30. August 2011. Abgerufen am 28. September 2011.
  7. Gmail.com SSL MITM ATTACK BY Iranian Government. pastebin.com. 27. August 2011. Abgerufen am 28. September 2011.
  8. Niederländische Regierung übernimmt Kontrolle über DigiNotar. heise.de. 5. September 2011. Abgerufen am 28. September 2011.

Spenden-Adressen:
Bitcoin Icon BTC: 1EoecgUZnAjamUYaKstqwbremQqbucTaoZ
Ethereum Icon ETH: 0x0D2Ab63dfe70a7fA12f9d66eCfEA9dDc8F5173A8
XEM Icon XEM: NBZPMU-XES6ST-ITEBR3-IHAPTR-APGI3Y-RAAMHV-VZFJ
Verge Icon XVG: DGYmzxoe3ryK6MnsR13GqR9r1NThpxPcKs