Grundlagen Public Key Infrastrukturen (PKI)

Autor Uwe GradeneggerVeröffentlicht am Kategorien GrundlagenSchlagwörter , , ,

Eine Public Key Infrastruktur umfasst alle Komponenten (Hardware, Software, Personen und Prozesse), welche für die Verwendung digitaler Zertifikate benötigt werden. Eine PKI besteht aus einer oder mehreren Zertifizierungsstellen (engl. Certification Authority, CA). Die Aufgaben einer PKI sind unter Anderem:

  • Sicherstellung der Authentizität der Schlüssel, d.h. das Herstellen einer nachvollziehbaren Verbindung zwischen einem Schlüssel und seiner Herkunft, um Missbrauch zu unterbinden.
  • Sperrung von Zertifikaten, d.h. sicherzustellen, dass außer Betrieb genommene oder kompromittierte (z.B. gestohlene) Schlüssel nicht mehr verwendet werden können.
  • Gewährleistung der Verbindlichkeit (Nichtabstreitbarkeit), d.h. z.B. dass der Besitzer eines Schlüssels nicht abstreiten kann, dass er ihm gehört.
  • Durchsetzen von Richtlinien (engl. Policies), d.h. standardisierter Vorgehensweisen für die Verwendung von Zertifikaten.

Zum Einstieg in das Thema bitte auch Artikel "Grundlagen Kryptographie" berücksichtigen.

Wichtig ist hierbei zu erwähnen, dass sich eine Zertifizierungsstelle im Regelfall nur um die Verwaltung der öffentlichen Schlüssel kümmert, (mit wenigen Ausnahmen) aber nicht um die der privaten Schlüssel.

Eine Zertifizierungsstelle besteht in der Regel aus einem oder mehreren Computern mit einer entsprechend installierten Software, dazugehörigen Prozessen und Dokumenten. Zertifizierungsstellen sind Komponenten einer Public Key Infrastruktur (PKI). Ihre Hauptaufgaben bestehen darin…

  1. Die Identität von Antragstellern zu überprüfen und sicherzustellen, dass Zertifikate nur an berechtigte Antragsteller ausgegeben werden.
  2. Zertifikate auszustellen (d.h. zu signieren) und somit die überprüfte Identität zu bestätigen.
  3. Den Sperrstatus der ausgestellten Zertifikate zu verwalten und bekanntzugeben.

In Unternehmensnetzwerken ist es üblich, dass man eine Hierarchie aus mehreren Zertifizierungsstellen etabliert. Dies erhöht zum einen die Sicherheit, zum anderen die Skalierbarkeit. Am häufigsten ist ein Modell mit zwei Ebenen vorzufinden: An der Spitze einer solchen Hierarchie steht eine einzelne Stammzertifizierungsstelle (engl. Root CA), welcher mehrere Zwischenzertifizierungsstellen (engl. Intermediate CA), und ausstellende Zertifizierungsstellen (engl. Issuing CA genannt), untergeordnet sind.

Auf diese Weise kann beispielsweise die Stammzertifizierungsstelle effektiv vor Angriffen aus dem Netzwerk geschützt werden, indem sie niemals mit einem Netzwerk verbunden wird (daher wird auch der Begriff "Offline Root CA" verwendet). In seltenen Fällen kommt eine Hierarchie aus drei Ebenen zum Einsatz, hierbei wird zwischen der Root CA und den ausstellenden CAs eine weitere Ebene an Zwischenzertifizierungsstellen eingesetzt, die z.B. für die Erzwingung organisatorischer Richtlinien eingesetzt werden (engl. Policy CA) kann.

Die kritischste technische Komponente einer Zertifizierungsstelle ist ihr privater Schlüssel. Gelingt es einem Angreifer, den privaten Schlüssel zu ver- oder entwenden, ist die gesamte Vertrauenskette abwärts (d.h. inklusive aller von ihr in der Vergangenheit und in Zukunft ausgestellten Zertifikate) kompromittiert. Aus diesem Grund muss der private Schlüssel jeder einzelnen Zertifizierungsstelle besonders sensibel behandelt und durch entsprechende Maßnahmen geschützt werden. Ohne besondere Schutzmaßnahmen befindet er sich sowohl auf der Festplatte als auch im Arbeitsspeicher des Zertifizierungsstellen-Computers, während die Zertifizierungsstellen-Software ausgeführt wird, und kann potentiell von dort entwendet werden.

Um diesem Problem entgegen zu wirken, sollten die folgenden Sicherheitsmaßnahmen ergriffen werden:

  • Root CAs und Policy CAs sollten niemals (d.h. tatsächlich zu keinem Zeitpunkt, auch nicht während der Installation oder Wartung) mit einem Netzwerk verbunden werden, um zu verhindern, dass sie über dieses angegriffen und kompromittiert werden können. Im Gegensatz zu allen anderen Zertifikaten in einer PKI kann das der Root CA in den meisten Fällen nicht widerrufen werden, da es durch sich selbst signiert ist (engl. self-signed).
  • Eine CA sollte, wenn überhaupt, nur unter Anwendung gesonderter Sicherheitsmaßnahmen in einer virtuellen Umgebung (z.B. VMware, Xen, Hyper-V) ausgeführt werden. Neben der Gefahr des Diebstahls sensibler Daten besteht durch die in den meisten Virtualisierungsumgebungen vorhandene Schnappschussfunktion ein hohes Risiko unerkannter Manipulation. Die Virtualisierungs-Hosts sollten vor dem Zugriff unbefugter gesondert gesichert werden, etwa durch einen zusätzlich abschließbaren Serverschrank, erweiterte Zutrittskontrollen und die Verwendung einer Festplattenvollverschlüsselung.
  • Der private Schlüssel einer CA sollte mit einem Hardwaresicherheitsmodul (engl. Hardware Security Module, HSM) gesichert werden. Hierbei handelt es sich um dedizierte Geräte, welche den privaten Schlüssel unter Verschluss halten (Nichtexportierbarkeit) und über ein abgestuftes Rechtemodell sicherstellen können, dass nur befugte Personen und Computer den privaten Schlüssel verwenden können. Kryptographische Operationen können nur über das HSM ausgeführt werden.

Verwendung von Zertifikaten mit Microsoft Windows

Anwendungen, die auf dem Betriebssystem Microsoft Windows arbeiten, haben grundsätzlich zwei Möglichkeiten, Zertifikate zu verwenden:

  1. Microsoft Windows beinhaltet die Microsoft CryptoAPI, eine Programmierschnittstelle, welche kryptographische Operationen im Auftrag der aufrufenden Anwendung durchführen kann. Ein wesentlicher Vorteil hierbei ist, dass Zertifikate von den Anwendungen gemeinsam verwendet und zentral verwaltet werden können.
  2. Die Anwendung kann ihre eigenen kryptographischen Operationen implementieren, und somit die Microsoft CryptoAPI umgehen. Ein populäres Beispiel hierfür ist der Browser Mozilla Firefox, welcher eine eigene Kryptographie-Implementierung verwendet.

Bei der nachfolgenden Betrachtung wird angenommen, dass die verwendeten Anwendungen auf die Microsoft CryptoAPI zurückgreifen.

Validierung von Zertifikaten

Die Validierung von Zertifikaten lässt sich in mehrere miteinander verbundene Prozesse aufteilen, die nachfolgend näher beschrieben werden:

  • Das Auffinden von Zertifikaten beschreibt den Prozess, alle Zertifizierungsstellenzertifikate, die zur Überprüfung eines Zertifikats benötigt werden, zu ermitteln.
  • Die Validierung des Zertifizierungspfades beschreibt den Prozess, die Vertrauenskette herzustellen, indem alle Zertifikate innerhalb der Kette überprüft werden, bis sie bei einem als vertrauenswürdig eingestuften Zertifikat einer Root CA endet. Beide Prozesse sind im Artikel "Grundlagen: Auffinden von Zertifikaten und Validierung des Zertifizierungspfades" beschrieben.
  • Die Überprüfung des Sperrstatus beschreibt den Prozess, den Sperrstatus für alle Zertifikate innerhalb einer Vertrauenskette zu überprüfen. Er ist im Artikel "Grundlagen: Überprüfung des Sperrstatus von Zertifikaten" beschrieben.
  • Die Zertifikatvalidierung beschreibt den Prozess, den Inhalt aller Zertifikate der Kette auf Gültigkeit zu überprüfen.

Überprüfung der Gültigkeit von Zertifikaten

Die Vertrauenswürdigkeit eines digitalen Zertifikates bemisst sich unter Anderem nach den folgenden Kriterien:

  • Liegt das Zertifikat in einem gültigen Format vor (d.h. entspricht seine Kodierung den gängigen Standards und kann vom Empfänger fehlerfrei maschinell verarbeitet gelesen)?
  • Ist die durch das Zertifikat bestätigte Identität (engl. Subject Name, bzw. Subject Alternative Name) gültig?
  • Ist die Zertifikatkette vollständig?
  • Endet die Zertifikatkette bei einem als vertrauenswürdig eingestuften Stammzertifizierungsstellen-Zertifikat?
  • Befindet sich das Zertifikat innerhalb seines Gültigkeitszeitraums?
  • Stimmt der signierte Hashwert des Zertifikats mit seinem tatsächlichen (im Zuge der Zertifikatprüfung errechneten) Hashwert überein?
  • Wurde das Zertifikat von der Zertifizierungsstelle widerrufen oder ist es im Speicher für nicht vertrauenswürdige Zertifikate abgespeichert?
  • Ist das Zertifikat für den vorgesehenen Einsatzzweck freigegeben worden ("Key Usage" und/oder "Extended Key Usage" Attribute)?
  • Unterliegt das Zertifikat bestimmten Einschränkungen (engl. Constraints), z.B. auf bestimmte Domänennamen oder Hierarchieebenen?
  • Werden alle als kritisch markierten Erweiterungen des Zertifikats von der das Zertifkat prüfenden Anwendungen verstanden?

Dieser Prozess wird für jedes Zertifikat einer zu überprüfenden Zertifikatkette durchgeführt. Nur wenn alle Zertifikate innerhalb einer Kette diesen Prozess erfolgreich durchlaufen haben und folglich als vertrauenswürdig anerkannt werden, wird auch das eigentliche zu überprüfende Zertifikat letztendlich als vertrauenswürdig anerkannt.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish de_DEDeutsch