Public-Key-Infrastruktur

Aus besserwiki.de
Diagramm einer Public-Key-Infrastruktur ⓘ

Eine Public-Key-Infrastruktur (PKI) besteht aus einer Reihe von Rollen, Richtlinien, Hardware, Software und Verfahren, die zum Erstellen, Verwalten, Verteilen, Verwenden, Speichern und Widerrufen von digitalen Zertifikaten und zur Verwaltung der Verschlüsselung mit öffentlichen Schlüsseln erforderlich sind. Der Zweck einer PKI besteht darin, die sichere elektronische Übertragung von Informationen für eine Reihe von Netzaktivitäten wie E-Commerce, Internet-Banking und vertrauliche E-Mails zu erleichtern. Sie wird für Aktivitäten benötigt, bei denen einfache Passwörter eine unzureichende Authentifizierungsmethode darstellen und ein strengerer Nachweis erforderlich ist, um die Identität der an der Kommunikation beteiligten Parteien zu bestätigen und die übertragenen Informationen zu validieren. ⓘ

In der Kryptografie ist eine PKI eine Einrichtung, die öffentliche Schlüssel mit den jeweiligen Identitäten von Einheiten (wie Personen und Organisationen) verbindet. Die Bindung wird durch einen Prozess der Registrierung und Ausstellung von Zertifikaten bei und durch eine Zertifizierungsstelle (CA) hergestellt. Je nach dem Sicherheitsniveau der Bindung kann dies durch einen automatisierten Prozess oder unter menschlicher Aufsicht erfolgen. Wenn dies über ein Netzwerk erfolgt, muss ein sicheres Protokoll zur Zertifikatsregistrierung oder Zertifikatsverwaltung wie CMP verwendet werden. ⓘ

Die PKI-Rolle, die von einer CA delegiert werden kann, um eine gültige und korrekte Registrierung zu gewährleisten, wird als Registrierungsstelle (RA) bezeichnet. Grundsätzlich ist eine RA für die Annahme von Anträgen auf digitale Zertifikate und die Authentifizierung der antragstellenden Einheit verantwortlich. Im RFC 3647 der Internet Engineering Task Force wird eine RA wie folgt definiert: "Eine Instanz, die für eine oder mehrere der folgenden Funktionen verantwortlich ist: die Identifizierung und Authentifizierung von Zertifikatsantragstellern, die Genehmigung oder Ablehnung von Zertifikatsanträgen, die Einleitung von Zertifikatswiderrufen oder -sperrungen unter bestimmten Umständen, die Bearbeitung von Abonnentenanträgen auf Widerruf oder Sperrung ihrer Zertifikate und die Genehmigung oder Ablehnung von Abonnentenanträgen auf Erneuerung oder Neuverschlüsselung ihrer Zertifikate. RAs signieren oder stellen jedoch keine Zertifikate aus (d. h. eine RA wird mit bestimmten Aufgaben im Namen einer CA betraut)." Auch wenn Microsoft eine untergeordnete CA als RA bezeichnet hat, ist dies nach den X.509 PKI-Standards nicht korrekt. RAs haben nicht die Signierbefugnis einer CA und verwalten nur die Überprüfung und Bereitstellung von Zertifikaten. Im Falle der Microsoft PKI wird die RA-Funktionalität also entweder von der Microsoft Certificate Services-Website oder von den Active Directory Certificate Services bereitgestellt, die die Microsoft Enterprise CA- und Zertifikatsrichtlinien über Zertifikatsvorlagen durchsetzen und die Zertifikatsregistrierung (manuell oder automatisch) verwalten. Bei eigenständigen Microsoft-Zertifizierungsstellen gibt es keine RA-Funktion, da alle Verfahren zur Steuerung der Zertifizierungsstelle auf dem Verwaltungs- und Zugriffsverfahren basieren, das mit dem System, das die Zertifizierungsstelle beherbergt, und der Zertifizierungsstelle selbst und nicht mit Active Directory verbunden ist. Die meisten kommerziellen PKI-Lösungen, die nicht von Microsoft stammen, bieten eine eigenständige RA-Komponente. ⓘ

Eine Entität muss innerhalb jeder CA-Domäne auf der Grundlage von Informationen über diese Entität eindeutig identifizierbar sein. Eine dritte Validierungsinstanz (VA) kann diese Entitätsinformationen im Namen der CA bereitstellen. ⓘ

Der X.509-Standard definiert das am häufigsten verwendete Format für Public-Key-Zertifikate. ⓘ

Schema einer Public-Key-Infrastruktur
CA: certification authority
RA: registration authority
VA: validation authority ⓘ

Fähigkeiten

PKI bietet "Vertrauensdienste" an - im Klartext: Vertrauen in die Aktionen oder Ergebnisse von Entitäten, seien es Menschen oder Computer. Die Ziele der Vertrauensdienste beziehen sich auf eine oder mehrere der folgenden Fähigkeiten: Vertraulichkeit, Integrität und Authentizität (CIA). ⓘ

Vertraulichkeit: Die Gewissheit, dass keine Entität böswillig oder unwissentlich eine Nutzinformation im Klartext einsehen kann. Die Daten werden verschlüsselt, um sie geheim zu halten, so dass sie, selbst wenn sie gelesen würden, als Kauderwelsch erscheinen. Die vielleicht häufigste Verwendung von PKI für Vertraulichkeitszwecke ist im Zusammenhang mit der Transport Layer Security (TLS) zu sehen. TLS ist eine Funktion, die die Sicherheit von Daten während der Übertragung gewährleistet. Ein klassisches Beispiel für den Einsatz von TLS für die Vertraulichkeit ist die Verwendung eines Internet-Browsers zur Anmeldung bei einem Dienst, der auf einer internetbasierten Website gehostet wird, durch Eingabe eines Passworts. ⓘ

Integrität: Die Gewissheit, dass, wenn eine Einrichtung die übertragenen Daten auch nur im Geringsten verändert (manipuliert), dies offensichtlich wäre, da die Integrität der Daten beeinträchtigt wäre. Oft ist es nicht von größter Wichtigkeit, eine Beeinträchtigung der Integrität zu verhindern (manipulationssicher), jedoch ist es von größter Wichtigkeit, dass im Falle einer Beeinträchtigung der Integrität ein eindeutiger Beweis dafür vorliegt (manipulationssicher). ⓘ

Authentizität: Die Gewissheit, dass Sie sicher sind, zu welchem Dienst Sie eine Verbindung herstellen, oder der Nachweis Ihrer Legitimität, wenn Sie eine Verbindung zu einem geschützten Dienst herstellen. Ersteres wird als serverseitige Authentifizierung bezeichnet, die typischerweise bei der Authentifizierung gegenüber einem Webserver mit einem Passwort verwendet wird. Letztere wird als clientseitige Authentifizierung bezeichnet und manchmal bei der Authentifizierung mit einer Smartcard (die ein digitales Zertifikat und einen privaten Schlüssel enthält) verwendet. ⓘ

Entwurf

Die Public-Key-Kryptografie ist eine kryptografische Technik, die es Entitäten ermöglicht, über ein unsicheres öffentliches Netz sicher zu kommunizieren und die Identität einer Entität über digitale Signaturen zuverlässig zu überprüfen. ⓘ

Eine Public-Key-Infrastruktur (PKI) ist ein System für die Erstellung, Speicherung und Verteilung von digitalen Zertifikaten, mit denen überprüft werden kann, ob ein bestimmter öffentlicher Schlüssel zu einer bestimmten Einheit gehört. Die PKI erstellt digitale Zertifikate, die öffentliche Schlüssel auf Entitäten abbilden, speichert diese Zertifikate sicher in einem zentralen Repository und widerruft sie bei Bedarf. ⓘ

Eine PKI besteht aus:

  • Einer Zertifizierungsstelle (CA), die die digitalen Zertifikate speichert, ausstellt und signiert;
  • einer Registrierungsstelle (Registration Authority, RA), die die Identität von Einrichtungen überprüft, die die Speicherung ihrer digitalen Zertifikate bei der CA beantragen;
  • Ein zentrales Verzeichnis, d. h. ein sicherer Ort, an dem die Schlüssel gespeichert und indiziert werden;
  • Ein Zertifikatsverwaltungssystem, das z. B. den Zugriff auf gespeicherte Zertifikate oder die Zustellung der auszustellenden Zertifikate verwaltet;
  • eine Zertifikatsrichtlinie, in der die Anforderungen der PKI an ihre Verfahren festgelegt sind. Sie soll es Außenstehenden ermöglichen, die Vertrauenswürdigkeit der PKI zu analysieren. ⓘ

Methoden der Zertifizierung

Im Großen und Ganzen gibt es traditionell drei Ansätze, um dieses Vertrauen zu erhalten: Zertifizierungsstellen (CAs), Web of Trust (WoT) und Simple Public Key Infrastructure (SPKI). ⓘ

Zertifizierungsstellen

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

Anzeige einer Zertifikatskette in Windows ⓘ

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

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

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

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

Der Begriff "vertrauenswürdige dritte Partei" (Trusted Third Party, TTP) kann auch für die Zertifizierungsstelle (CA) verwendet werden. Außerdem wird PKI selbst oft als Synonym für eine CA-Implementierung verwendet. ⓘ

Widerruf von Zertifikaten

Autoritäten in der WebPKI bieten Widerrufsdienste an, um die Ungültigmachung von zuvor ausgestellten Zertifikaten zu ermöglichen. Gemäß den grundlegenden Anforderungen des CA/Browser-Forums müssen die CAs den Sperrstatus bis zum Ablauf des Zertifikats aufrechterhalten. Der Status muss über das Online Certificate Status Protocol übermittelt werden. Die meisten Widerrufsstatus im Internet verschwinden bald nach Ablauf der Gültigkeit der Zertifikate. ⓘ

Marktanteil des Ausstellers

In diesem Modell der Vertrauensbeziehungen ist eine Zertifizierungsstelle eine vertrauenswürdige dritte Partei, der sowohl das Subjekt (der Eigentümer) des Zertifikats als auch die Partei, die sich auf das Zertifikat verlässt, vertrauen. ⓘ

In einem Bericht von NetCraft aus dem Jahr 2015, dem Branchenstandard für die Überwachung aktiver TLS-Zertifikate (Transport Layer Security), heißt es: "Obwohl das globale [TLS]-Ökosystem wettbewerbsfähig ist, wird es von einer Handvoll großer Zertifizierungsstellen dominiert - drei Zertifizierungsstellen (Symantec, Sectigo, GoDaddy) sind für drei Viertel aller ausgestellten [TLS]-Zertifikate auf öffentlich zugänglichen Webservern verantwortlich. Den Spitzenplatz hat Symantec (bzw. VeriSign, bevor es von Symantec aufgekauft wurde) seit Beginn [unserer] Erhebung inne, auf das derzeit knapp ein Drittel aller Zertifikate entfällt. Zur Veranschaulichung der Auswirkung unterschiedlicher Methoden hat Symantec unter der Million der meistgenutzten Websites 44 % der gültigen, vertrauenswürdigen Zertifikate ausgestellt - deutlich mehr als sein Gesamtmarktanteil." ⓘ

Nach größeren Problemen bei der Verwaltung der Zertifikatsausstellung misstrauten alle großen Akteure ab 2017 schrittweise den von Symantec ausgestellten Zertifikaten. ⓘ

Temporäre Zertifikate und Single Sign-On

Bei diesem Ansatz fungiert ein Server als Offline-Zertifizierungsstelle innerhalb eines Single-Sign-On-Systems. Ein Single-Sign-On-Server stellt digitale Zertifikate für das Client-System aus, speichert sie aber nicht. Die Benutzer können Programme usw. mit dem temporären Zertifikat ausführen. Diese Lösungsvariante ist häufig bei X.509-basierten Zertifikaten zu finden. ⓘ

Ab September 2020 wird die Gültigkeitsdauer von TLS-Zertifikaten auf 13 Monate reduziert. ⓘ

Netz des Vertrauens

Ein alternativer Ansatz für das Problem der öffentlichen Authentifizierung von Informationen mit öffentlichen Schlüsseln ist das Web-of-Trust-Schema, bei dem selbstsignierte Zertifikate und Bescheinigungen Dritter für diese Zertifikate verwendet werden. Der Begriff "Web of Trust" impliziert nicht das Vorhandensein eines einzigen "Web of Trust" oder eines gemeinsamen Vertrauenspunktes, sondern eher eines von einer beliebigen Anzahl potenziell disjunkter "Webs of Trust". Beispiele für Implementierungen dieses Ansatzes sind PGP (Pretty Good Privacy) und GnuPG (eine Implementierung von OpenPGP, der standardisierten Spezifikation von PGP). Da PGP und seine Implementierungen die Verwendung digitaler E-Mail-Signaturen zur Selbstveröffentlichung von Informationen über öffentliche Schlüssel erlauben, ist es relativ einfach, ein eigenes Netz des Vertrauens zu schaffen. ⓘ

Einer der Vorteile des "Web of Trust", wie bei PGP, besteht darin, dass es mit einer PKI-Zertifizierungsstelle zusammenarbeiten kann, der alle Parteien in einer Domäne voll vertrauen (z. B. eine interne Zertifizierungsstelle in einem Unternehmen) und die bereit ist, als vertrauenswürdiger Introducer Zertifikate zu garantieren. Wenn das "Netz des Vertrauens" vollständig vertrauenswürdig ist, dann bedeutet das Vertrauen in ein Zertifikat, dass allen Zertifikaten in diesem Netz Vertrauen entgegengebracht wird, was in der Natur eines solchen Netzes liegt. Eine PKI ist nur so wertvoll wie die Standards und Praktiken, die die Ausstellung von Zertifikaten steuern, und die Einbeziehung von PGP oder eines persönlich eingerichteten "Web of Trust" könnte die Vertrauenswürdigkeit der PKI-Implementierung eines Unternehmens oder einer Domäne erheblich beeinträchtigen. ⓘ

Das Konzept des Web of Trust wurde erstmals 1992 vom PGP-Erfinder Phil Zimmermann im Handbuch für PGP Version 2.0 vorgestellt:

Im Laufe der Zeit werden Sie Schlüssel von anderen Personen sammeln, die Sie als vertrauenswürdige Introducer bezeichnen möchten. Alle anderen werden jeweils ihre eigenen vertrauenswürdigen Introducer wählen. Und jeder wird nach und nach eine Sammlung von Zertifizierungssignaturen von anderen Personen sammeln und mit seinem Schlüssel verteilen, in der Erwartung, dass jeder, der sie erhält, mindestens einer oder zwei der Signaturen vertraut. So entsteht ein dezentralisiertes, fehlertolerantes Netz des Vertrauens für alle öffentlichen Schlüssel. ⓘ

Einfache Infrastruktur für öffentliche Schlüssel

Eine weitere Alternative, die sich nicht mit der öffentlichen Authentifizierung von Informationen über öffentliche Schlüssel befasst, ist die einfache Infrastruktur für öffentliche Schlüssel (SPKI), die aus drei unabhängigen Bemühungen hervorgegangen ist, die Komplexität von X.509 und dem Vertrauensnetz von PGP zu überwinden. SPKI verbindet Benutzer nicht mit Personen, da der Schlüssel vertrauenswürdig ist und nicht die Person. SPKI verwendet keinen Begriff des Vertrauens, da der Prüfer auch der Aussteller ist. In der SPKI-Terminologie wird dies als "Autorisierungsschleife" bezeichnet, bei der die Autorisierung integraler Bestandteil des Designs ist. Diese Art von PKI ist besonders nützlich für die Integration von PKI, die sich nicht auf Dritte für die Autorisierung von Zertifikaten, Zertifikatsinformationen usw. stützen; ein gutes Beispiel hierfür ist ein Air-Gapped-Netzwerk in einem Büro. ⓘ

Dezentralisierte PKI

Dezentrale Identifikatoren (DIDs) beseitigen die Abhängigkeit von zentralen Registern für Identifikatoren sowie von zentralen Zertifizierungsstellen für die Schlüsselverwaltung, die bei hierarchischen PKI der Standard ist. In Fällen, in denen das DID-Register ein verteiltes Hauptbuch ist, kann jede Einheit als ihre eigene Stammautorität fungieren. Diese Architektur wird als dezentralisierte PKI (DPKI) bezeichnet. ⓘ

Geschichte

Die Entwicklung der PKI begann in den frühen 1970er Jahren beim britischen Geheimdienst GCHQ, wo James Ellis, Clifford Cocks und andere wichtige Entdeckungen in Bezug auf Verschlüsselungsalgorithmen und Schlüsselverteilung machten. Da die Entwicklungen beim GCHQ streng geheim sind, wurden die Ergebnisse dieser Arbeit bis Mitte der 1990er Jahre geheim gehalten und nicht öffentlich bekannt gegeben. ⓘ

Die Veröffentlichung des sicheren Schlüsselaustauschs und der asymmetrischen Schlüsselalgorithmen im Jahr 1976 durch Diffie, Hellman, Rivest, Shamir und Adleman veränderte die sichere Kommunikation völlig. Mit der weiteren Entwicklung der digitalen elektronischen Hochgeschwindigkeitskommunikation (Internet und seine Vorläufer) wurde die Notwendigkeit deutlich, Wege zu finden, mit denen die Benutzer sicher miteinander kommunizieren konnten, und als weitere Folge davon, Wege zu finden, mit denen die Benutzer sicher sein konnten, mit wem sie tatsächlich interagierten. ⓘ

Es wurden verschiedene kryptografische Protokolle erfunden und analysiert, in denen die neuen kryptografischen Primitive wirksam eingesetzt werden konnten. Mit der Erfindung des World Wide Web und seiner raschen Verbreitung wurde der Bedarf an Authentifizierung und sicherer Kommunikation noch größer. Kommerzielle Gründe allein (z. B. elektronischer Geschäftsverkehr, Online-Zugang zu geschützten Datenbanken über Webbrowser) waren ausreichend. Taher Elgamal und andere bei Netscape entwickelten das SSL-Protokoll ("https" in Web-URLs); es umfasste die Erstellung von Schlüsseln, die Server-Authentifizierung (vor v3 nur in einer Richtung) usw. Auf diese Weise wurde eine PKI-Struktur für Web-Benutzer/Sites geschaffen, die eine sichere Kommunikation wünschen. ⓘ

Anbieter und Unternehmer sahen die Möglichkeit eines großen Marktes, gründeten Unternehmen (oder neue Projekte in bestehenden Unternehmen) und begannen, sich für die rechtliche Anerkennung und den Schutz vor Haftung einzusetzen. Ein Technologieprojekt der American Bar Association veröffentlichte eine ausführliche Analyse einiger vorhersehbarer rechtlicher Aspekte des PKI-Betriebs (siehe ABA-Richtlinien für digitale Signaturen), und kurz darauf begannen mehrere US-Bundesstaaten (Utah war 1995 der erste) und andere Gerichtsbarkeiten in der ganzen Welt, Gesetze zu erlassen und Vorschriften zu erlassen. Verbrauchergruppen warfen Fragen zum Datenschutz, zum Zugang und zu Haftungsfragen auf, die in einigen Ländern stärker berücksichtigt wurden als in anderen. ⓘ

Die erlassenen Gesetze und Vorschriften unterschieden sich, es gab technische und betriebliche Probleme bei der Umwandlung von PKI-Systemen in einen erfolgreichen kommerziellen Betrieb, und die Fortschritte waren viel langsamer, als die Pioniere es sich vorgestellt hatten. ⓘ

In den ersten Jahren des 21. Jahrhunderts war die zugrundeliegende kryptografische Technik eindeutig nicht einfach richtig einzusetzen. Es war nicht einfach, (manuelle oder automatische) Betriebsverfahren korrekt zu entwerfen (und selbst wenn man sie entworfen hatte, sie perfekt auszuführen, was die Technik erforderte). Die vorhandenen Standards waren unzureichend. ⓘ

PKI-Anbieter haben einen Markt gefunden, aber es ist nicht ganz der Markt, den man sich Mitte der 90er Jahre vorgestellt hatte, und er ist sowohl langsamer als auch auf etwas andere Weise gewachsen als man erwartet hatte. PKI haben einige der erwarteten Probleme nicht gelöst, und mehrere große Anbieter haben ihr Geschäft aufgegeben oder wurden von anderen übernommen. Die größte PKI-Implementierung ist bis heute die PKI-Infrastruktur der Defense Information Systems Agency (DISA) für das Common Access Cards-Programm. ⓘ

Verwendet

PKIs des einen oder anderen Typs und von verschiedenen Anbietern haben viele Verwendungszwecke, einschließlich der Bereitstellung von öffentlichen Schlüsseln und Bindungen zu Benutzeridentitäten, die für Folgendes verwendet werden:

  • Verschlüsselung und/oder Absenderauthentifizierung von E-Mail-Nachrichten (z. B. mit OpenPGP oder S/MIME);
  • Verschlüsselung und/oder Authentifizierung von Dokumenten (z. B. die XML-Signatur- oder XML-Verschlüsselungsstandards, wenn die Dokumente als XML kodiert sind);
  • Authentifizierung von Benutzern gegenüber Anwendungen (z. B. Anmeldung mit Smartcard, Client-Authentifizierung mit SSL/TLS). Es gibt experimentelle Verwendung für digital signierte HTTP-Authentifizierung in den Projekten Enigform und mod_openpgp;
  • Bootstrapping von sicheren Kommunikationsprotokollen, wie Internet Key Exchange (IKE) und SSL/TLS. In beiden Fällen werden für den anfänglichen Aufbau eines sicheren Kanals (einer "Sicherheitsassoziation") asymmetrische Schlüssel, d.h. öffentliche Schlüssel, verwendet, während die eigentliche Kommunikation schneller mit symmetrischen Schlüsseln, d.h. geheimen Schlüsseln, erfolgt;
  • Mobile Signaturen sind elektronische Signaturen, die mit einem mobilen Gerät erstellt werden und sich auf Signatur- oder Zertifizierungsdienste in einer ortsunabhängigen Telekommunikationsumgebung stützen;
  • Das Internet der Dinge erfordert eine sichere Kommunikation zwischen Geräten, die sich gegenseitig vertrauen. Eine Public-Key-Infrastruktur ermöglicht es Geräten, X.509-Zertifikate zu erhalten und zu erneuern, die verwendet werden, um Vertrauen zwischen Geräten herzustellen und die Kommunikation mit TLS zu verschlüsseln. ⓘ

Open-Source-Implementierungen

  • OpenSSL ist die einfachste Form einer Zertifizierungsstelle und eines Werkzeugs für die PKI. Es handelt sich um ein in C entwickeltes Toolkit, das in allen wichtigen Linux-Distributionen enthalten ist und sowohl für den Aufbau einer eigenen (einfachen) CA als auch für PKI-fähige Anwendungen verwendet werden kann. (Apache lizenziert)
  • EJBCA ist eine in Java entwickelte CA-Implementierung mit vollem Funktionsumfang und für Unternehmen geeignet. Sie kann zur Einrichtung einer CA sowohl für den internen Gebrauch als auch als Dienst verwendet werden. (LGPL lizenziert)
  • XiPKI, CA und OCSP-Responder. Mit SHA-3-Unterstützung, implementiert in Java. (Apache lizenziert)
  • XCA ist eine grafische Schnittstelle und eine Datenbank. XCA verwendet OpenSSL für die zugrunde liegenden PKI-Operationen.
  • DogTag ist eine voll funktionsfähige CA, die als Teil des Fedora-Projekts entwickelt und gepflegt wird.
  • CFSSL ist ein von CloudFlare entwickeltes Open-Source-Toolkit zum Signieren, Überprüfen und Bündeln von TLS-Zertifikaten. (BSD 2-Klausel lizenziert)
  • Vault-Tool zur sicheren Verwaltung von Geheimnissen (einschließlich TLS-Zertifikaten), entwickelt von HashiCorp (Mozilla Public License 2.0 lizenziert)
  • Boulder, eine ACME-basierte CA, die in Go geschrieben wurde. Boulder ist die Software, die Let's Encrypt betreibt. ⓘ

Kritik

Einige argumentieren, dass der Kauf von Zertifikaten für die Sicherung von Websites durch SSL/TLS und die Sicherung von Software durch Code Signing ein kostspieliges Unterfangen für kleine Unternehmen ist. Das Aufkommen von kostenlosen Alternativen wie Let's Encrypt hat dies jedoch geändert. HTTP/2, die neueste Version des HTTP-Protokolls, erlaubt in der Theorie ungesicherte Verbindungen; in der Praxis haben die großen Browserhersteller klargestellt, dass sie dieses Protokoll nur über eine PKI-gesicherte TLS-Verbindung unterstützen würden. Die Webbrowser, die HTTP/2 implementieren, darunter Chrome, Firefox, Opera und Edge, unterstützen HTTP/2 nur über TLS, indem sie die ALPN-Erweiterung des TLS-Protokolls verwenden. Um die Geschwindigkeitsvorteile von HTTP/2 nutzen zu können, wären Website-Betreiber also gezwungen, von Unternehmen kontrollierte SSL/TLS-Zertifikate zu erwerben. ⓘ

Derzeit werden die meisten Webbrowser mit vorinstallierten Zwischenzertifikaten ausgeliefert, die von einer Zertifizierungsstelle mit öffentlichen Schlüsseln ausgestellt und signiert werden, die von so genannten Stammzertifikaten zertifiziert sind. Dies bedeutet, dass die Browser eine große Anzahl von verschiedenen Zertifikatsanbietern mit sich führen müssen, was das Risiko einer Schlüsselkompromittierung erhöht. ⓘ

Wenn bekannt ist, dass ein Schlüssel kompromittiert wurde, könnte dies durch Widerruf des Zertifikats behoben werden, aber eine solche Kompromittierung ist nicht leicht zu erkennen und kann eine große Sicherheitslücke darstellen. Browser müssen einen Sicherheitspatch herausgeben, um Zwischenzertifikate zu widerrufen, die von einer kompromittierten Stammzertifizierungsstelle ausgestellt wurden. ⓘ

Bestandteile einer PKI

  • 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. (englisch). ⓘ

Vertrauensmodelle in Public-Key-Infrastrukturen

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

Cross-Zertifizierung

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

Implementierung einer PKI und Kartenmanagement

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

Abgerufen von „http://besserwiki.de/index.php?title=Public-Key-Infrastruktur&oldid=44732“