Grundlagen einer Public Key Infrastructure - PKI

Zum praktikablen Umgang mit asymmetrischer Verschlüsselung bzw. den öffentlichen Schlüsseln bedarf es einer entsprechenden Infrastruktur - der PKI. Eine Public Key Infrastructure entspricht einem umfassenden Sicherheitsmodell. Dazu gehören Software, Richtlinien und Methoden um digitale Zertifikate zu erstellen, speichern, verwalten, verteilen und widerrufen zu können.

=

Digitale Zertifikate

Mittels Digitaler Zertifikate wird ein öffentlicher Schlüssel an eine Identität gebunden. Sie entsprechen sozusagen einem digitalen Ausweis. Dieser Ausweis kann in unterschiedlichen Zertifikatsformaten vorliegen. Während Zertifikat und öffentlicher Schlüssel bedenkenlos weitergegeben werden können, muss ein privater Schlüssel immer sicher aufbewahrt, bzw. gespeichert werden!

Der X.509 Standard der ITU definiert unter anderem ein Zertifikatsformat für Public-Key-Zertifikate, sowie für Attributzertifikate und Widerrufslisten.

Als Container für den Import und Export von Zertifikaten sind die PKCS-Formate PKCS #1, und PKCS #12 gebräuchlich. PKCS #10 ist ein Sonderfall und wird für die sichere Übermittlung des öffentlichen Schlüssels an eine CA bei einem Zertifizierungsrequest eingesetzt.

=

In einer PKI können unterschiedliche Zertifikate existieren.

  • End Entity Zertifikate: oder Endzertifikate, Benutzerzertifikate, Teilnehmerzertifikate sind von der CA an eine bestimmte Entität ausgestellt, die ihrerseits KEINE weiteren Zertifikate damit ausstellt.
  • CA- Zertifikate: sind von einer CA an eine Entität ausgestellt, die Ihrerseits eine CA ist und weitere End Entity oder andere Zertifikate ausstellt. CA-Zertifikate können an der Basic Constraints - Erweiterung erkannt werden. Bei CA-Zertifikaten können wiederum mehrere Zertifikate unterschieden werden.
  • Self-signed Zertifikate: Ein Stammzertifikat und Angelpunkt einer Vertrauenshierarchie ist für gewöhnlich ein selbstsigniertes Zertifikat. Der zertifizierte öffentliche Schlüssel gehört dabei zum privaten Schlüssel, mit dem das Zertifikat signiert wurde.
  • Cross Zertifikat: In diesen Zertifikaten sind Aussteller und Antragsteller unterschiedliche CAs. Sie werden benutzt um zwischen CAs Vertrauensstellungen zu kreieren. 
  • Self-issued Zertifikate: In diesen Zertifikaten sind Aussteller und Antragstellernahme von derselben CA. Diese speziellen Zertifikate können benutzt werden, um die Validierung eines neuen öffentlichen Schlüssels der CA zu ermöglichen, wenn ein neues Schlüsselpaar zum Einsatz kommt. Der alte private Schlüssel wird dabei verwendet um den neuen öffentlichen Schlüssel zu signieren und damit erlaubt diesem zu Vertrauen
  • Attributszertifikate: Bei Attributszertifikate wird nicht ein öffentlicher Schlüssel an die Identität des Inhabers durch einen Dritten gebunden und bestätigt, sondern nur bestimmte Rechte bzw. Privilegien an einen Inhaber gebunden. Attributszertifikate sind deshalb mit einem "Identitätszertifikat" verbunden, d.h. im Attributszertifikat wird das zugehörige Public-Key-Zertifikat referenziert. Natürlich kann in X.509 Zertifikaten über die Erweiterung "Subject Directory Attributes" so etwas definiert werden, doch sind Public-Key-Zertifikate sinnvollerweise über längere Zeiträume gültig - während z.B. zusätzliche Sonderrechte wahrscheinlich nur kürzere Zeit Gültigkeit besitzen. Attribute sind üblicherweise Gruppenmitgliedschaften, Rollen, Transaktionslimits, eingeschränkte Zeiten für Zugriffe,... wobei es kein Problem darstellt mehrere Attributszertifikate dem Inhaber eines Identitätszertifikates auszustellen.

=

PGP Zertifikate weisen aufgrund des praktisch gleichen Inhalts Ähnlichkeiten zu X.509 auf, sind aber nicht mit X.509 kompatibel! Obgleich PGP grundsätzlich auf einem Web of Trust aufbaut existieren auch PGP-Zertifizierungsstellen womit das Trusted Third Party Konzept für PGP eingeführt wurde.

In den verschiedenen Viewern für Zertifikate werden Eigenschaften des Zertifikates angezeigt, nämlich Fingerabdruck und der dazugehörige Fingerabdruckalgorithmus. Je nach Viewer wird ein MD5 oder ein SHA-1 Hash-Wert des Zertifikates angezeigt. Vor allem beim Import von selbstsignierten Zertifikaten einer Zertifizierungsstelle kann so die Integrität des Zertifikates überprüft werden.

=

Zertifikatsprüfung

Die Prüfung eines Zertifikates besteht aus der "Signaturprüfung" und der Gültigkeitsprüfung. Ein Zertifikat beinhaltet ja auch eine Signatur über die Daten des Zertifikats, die bei der Ausstellung von der Zertifizierungsstelle erstellt wurde. Deshalb ist der erste Teil eine Prüfung eine Signaturprüfung mit der Integrität und Authentizität geprüft festgestellt werden kann.

Das Zertifikat muss danach mit dem Widerrufsdienst des Zertifizierungsdiensteanbieters auf seine Gültigkeit geprüft werden. Es sind auch die Zertifikatserweiterungen zu prüfen, vor allem die Critical Extensions müssen von der prüfenden Applikation erkannt und richtig darauf reagiert werden. Meist sind nur die Schlüsselverwendung und Anzeige der Qualifizierungseigenschaft als kritisch markiert, dies geschieht aus Kompatibilitätsgründen und besagt nicht, dass andere Extensions unwichtig sind. Beispielsweise ist sind die Basic Constraints nicht unbedingt als unwichtig zu bezeichnen - sie zeigen an, ob dieses Zertifikat ein Endzertifikat oder ein CA-Zertifikat ist. Damit kann erkannt werden, ob nicht ein Endzertifikat als CA-Zertifikat "missbraucht" wurde.

Danach muss der Zertifizierungspfad bis zu einem Stammzertifikat erstellt werden und mit jedem Zertifikat in diesem Pfad dieselbe Prüfung durchgeführt werden. Die Validierung des Zertifizierungspfads besteht also aus einer weiteren Kaskade von Signaturprüfungen und Gültigkeitsprüfungen.

=

Berücksichtigung des Gültigkeitsmodell 

Bei der Prüfung eines Zertifizierungspfades muss das zugrunde liegende Gültikeitsmodell der Hierarchie berücksichtigt werden. Problem ist, dass die prüfende Anwendung das Modell kennen muss, es aber keine Zertifikatserweiterung gibt, die diese Eigenschaft anzeigt. Lediglich anhand der Certificate Policy könnte dies implizit erkannt werden. Zudem müsste bei einem Kettenmodell die Widerrufsinformation von CA-Zertifikaten nach deren Ablauf im Widerrufsdienst vorhanden sein und der Grund eines etwaigen Widerrufs berücksichtigt werden

  • Schalenmodell: Zur Gültigkeitsprüfung wird der Zeitpunkt der Prüfung herangezogen, die Signatur ist gültig, wenn der Zertifizierungspfad, d.h. jedes Zertifikat im Pfad, zu diesem Zeitpunkt gültig ist. Langzeitsignaturen sind damit problematisch.
  • Kettenmodell: Zur Gültigkeitsprüfung wird der Erstellungszeitpunkt der Signatur herangezogen. Langzeitsignaturen sind damit leichter möglich.

Die meisten Anwendungen im Internet prüfen nach dem Schalenmodell, man ist mit Nutzung dieses Modells im Moment beim Interoperabilitätsaspekt auf der sichereren Seite und kauft sich das Problem der langen Laufzeiten von CA-Zertifikaten ein. Im Bereich qualifizierter Signaturen wird mehr auf das Kettenmodell gesetzt, die Anwendungen die mit diesen Zertifikaten arbeiten wollen müssen sowieso auch die "kritische" Erweiterung, welche die Qualifizierungseigenschaft anzeigt, erkennen und müssen richtig darauf reagieren - also auch das richtige Gültigkeitsmodell verwenden.

Zertifizierungsstelle

Zertifikate für Personen, Rechner oder Dienste werden von einer vertrauenswürdigen Autorität herausgegeben, verwaltet und Dritten gegenüber bestätigt. Jedes ausgestellte Zertifikat wird mit dem privaten Schlüssel der Zertifizierungsstelle (certification authority) signiert.

=

Zertifikatsmanagement

Das Zertifikatsmanagement muss sich mit Zertifikaten über die gesamte Lebensdauer hinweg befassen. Eine Zertifizierungsstelle kümmert sich um die Ausstellung, Erneuerung und den Widerruf von Zertifikaten.

Der Vorgang der Registrierung, der Erzeugung des Schlüsselpaares, der Zertifizierung, der Auslieferung, der Veröffentlichung und des Backups vom privaten Schlüssel wird als Gesamtes oft Enrollment genannt.

Die Zertifizierung nimmt die Zertifizierungsstelle (CA) vor, während Registrierungsstellen diesen Vorgang initialisieren können. Je nach Einsatzgebiet können die Anforderungen für die Ausstellung sehr verschieden sein, und Ausstellungsvorgänge dementsprechend unterschiedlich ausfallen.

Wie wird das initiale Vertrauen hergestellt oder der Beweis der Identität gegenüber der CA erbracht?Je nach Schlüsselgenerierungsvariante (wo und wann) kann auch der Beweis des Besitzes, des, zu zertifizierenden öffentlichen Schlüssels zugehörigen, privaten Schlüssel notwendig sein, siehe dazu PKCS #10 . Vor allem bei Verschlüsselungsschlüssel kann es sinnvoll sein, wenn der private Schlüssel hinterlegt wird.

=

Erneuerung und Wechsel

Die Erneuerung eines Zertifikates wird wohl meist mit dem Ablauf der angegebenen Gültigkeitsdauer begründet sein. Wenn bis dato keine Kompromittierung erfolgte und die Schlüssellänge für eine weitere Gültigkeitsperiode ausreichend erscheint, sollte einer erneuten Ausstellung nichts im Weg stehen - eine Signierung eines solchen Antrags mit dem bestehenden Schlüssel wird hiefür ausreichen. Je nach Policy kann dieser Vorgang aber auch anders gestaltet werden.

Ein Wechsel des Schlüssels wird mit einer normalen Neuausstellung abgewickelt werden. Zu beachten ist eine etwaige Archivierung des alten Schlüssels, damit auf verschlüsselte Dinge weiter zugegriffen werden kann. Besser ist es eine Umschlüsselung vorzusehen.

Die Erneuerung oder ein Schlüsselwechsel ist bei einem CA Zertifikats einiges aufwendiger, da, abhängig vom Gültigkeitsmodell unterschiedlich, auch untergeordnete Zertifikate und Benutzer der PKI betroffen sind.

=

Ablauf, Sperre, Widerruf

Zertifikate können widerrufen oder gesperrt werden. Eine Sperre kann man als einen vorläufigen Widerruf betrachten, z.B. wenn man seine Karte nicht findet, der wieder rückgängig gemacht werden kann.

Beide Begebenheiten müssen veröffentlicht werden, da eine korrekte Prüfung eines Zertifikats nur mit einer Prüfung auf Sperre oder Widerruf vollständig ist. Die Veröffentlichung erfolgt meist über Listen (Certificate Revocation Lists - CRL) im Verzeichnisdienst. Da diese CRLs oft benötigt werden und schnell groß werden können sind können auch "delta CRLs" und "distribution point CRLs", oder Onlineabfragen mit dafür bestimmten Protokollen zum Einsatz kommen. 

Mit Ablauf eines Zertifikats muss nicht die Lebensdauer eines Schlüsselpaares ablaufen, es kann aber sinnvoll sein, eine Key History, oder Key Archiv zu führen. Auch Widerrufsinformationen können nach Ablauf der normalen Lebenszeit eines Zertifikates sinnvoll sein, um zu einem späteren Zeitpunkt eine Prüfung einer Signatur vornehmen zu können.

=

Registrierungsstelle

Eine Registrierungsstelle, welche von einer Zertifizierungsstelle getrennt sein kann, nimmt die Registrierung vor. Die Identität wird überprüft und der Zertifizierungsvorgang mit der Zertifizierungsstelle wird initiiert.

=

weitere Bestandteile einer PKI

  •  Zertifikatsvorlagen - Zertifikatsprofile: Anhand des Verwendungszweckes definiert eine Vorlage das Format und Inhalt eines auszustellenden Zertifikats.
  • Verzeichnisdienst - Zentrales Verzeichnis: Ein allen beteiligten zugängliches zentrales Verzeichnis, wo die Zertifikate hinterlegt werden, ist erforderlich, damit die öffentlichen Schlüssel verteilt oder abgefragt werden können. Praktischerweise können auch Widerrufe so veröffentlicht werden.
  • Widerrufsdienst - Zertifikatssperrliste: Nachdem die Schlüssel auch widerrufbar sind ( Keymanagement ) ist zu definieren, wie Widerrufe ablaufen und veröffentlicht werden.
  • Zertifizierungsrichtlinien: Sie definieren, wie Zertifikate angefordert, ausgestellt, widerrufen werden, was beim Ablauf geschieht, wie die Speicherung der privaten Schlüssel aussieht, Sicherungen durchgeführt werden. In Certificate Policies (CP) und Certificate Practice Statements (CPS) wird die Basis, das organisatorische Regelwerk einer PKI formuliert. Eine Certificate Policy enthält ein Regelwerk, das den Einsatzbereich eines Zertifikats für eine bestimmte Benutzergruppe und/oder Anwendungsklasse mit gemeinsamen Sicherheitsanforderungen definiert. Ein Certification Practice Statement (Zertifizierungsrichtlinie) erläutert die Vorgehensweise bei der Ausgabe von Zertifikaten und beschreibt vorhandene Sicherheitsmaßstäbe.
  • PKI-fähige Anwendungen und Dienste: Eine PKI macht keinen Sinn wenn es keine Nutzungsmöglichkeit gibt. PKI basierende Dienste und Services, sind die Authentifizierung, Digitale Signatur, Zeitstempel, Transaktionen, Notariatsdienste, SSO, sichere E-Mail, VPN, WLAN, EFS, Remote Desktop etc. Protokolle die PKI nutzen sind z.B. SSL/TLS, WTLS, S/MIME, Time Stamp Protokolle etc.

=

Time-Stamping Authority

Eine Timestamp-Authority bestätigt die Existenz von bestimmten Daten zu einer bestimmten Zeit - und stellt zu diesem Zweck Time-Stamp-Tokens aus, die einen Hash-Wert der bestätigten Daten enthalten. Die Time-Stamping-Authority benötigt eine entsprechend exakte "Zeitquelle".

Die Langfristigkeit solcher Time-Stamps impliziert die hohe erforderliche Länge des Schlüsselpaares des Time - Stamp - Services. Auch "Nachstempelung" muss vorgesehen werden.

Die Konsequenzen einer Kompromittierung des privaten Schlüssels müssen betrachtet werden und entsprechend hohe Sicherheitsmaßnahmen vorgesehen werden. 

=