CryptoAPI – Uwe Gradenegger

Grundlagen: Cryptographic Service Provider (CSP) und Key Storage Provider (KSP)

Seit Windows NT 4.0 gibt es im Rahmen der CryptoAPI die Cryptographic Service Provider (CSP).

Sinn ist, dass sich eine Anwendung nicht um die konkrete Implementierung der Schlüsselverwaltung kümmern muss, sondern dies generischen Betriebssystem-Schnittstellen überlassen kann. Ebenso soll hiermit vermieden werden, dass kryptographische Schlüssel im Sicherheitskontext des Benutzers/der verwendenen Anwendung in den Arbeitsspeicher geladen werden (ein fataler Sicherheitsvorfall, der genau auf diesem Problem basierte war der Heartbleed Vorfall).

Beispielsweise spielt es für die Zertifizierungsstellen-Software technisch keine Rolle, wie ihr privater Schlüssel geschützt ist – ob in Software oder beispielsweise mit einem Hardware Security Modul (HSM). Der Aufruf des privaten Schlüssel ist für die Zertifizierungsstelle immer identisch.

Mit Windows Vista und der Einführung der Cryptography Next Generation (CNG) als Ablöser für die CryptoAPI wurden die Key Storage Provider (KSP) eingeführt.

Grundlagen Onlineresponder (Online Certificate Status Protocol, OCSP)

Zertifikate verfügen in der Regel über die Erweiterung "CRL Distribution Points", anhand derer einer Anwendung mitgeteilt wird, wo die zum Zertifikat zugehörige Zertifikatsperrliste (Certificate Revocation List, CRL) zu finden ist.

Diese gleicht einem Telefonbuch: In ihr finden sich alle Seriennummern von von der Zertifizierungsstelle zurückgerufenen (und noch zeitgültigen) Zertifikaten. Jede Anwendung, die den Sperrstatus überprüft, muss die gesamte Sperrliste herunterladen und auswerten.

Mit zunehmender Größe wird dieses Verfahren immer ineffizienter. Als Faustregel gilt, dass 100.000 zurückgerufene Zertifikate bereits ca. 5 MB Dateigröße für die Sperrliste entsprechen.

Hierfür wurde (federführend von der Firma ValiCert) das Online Certificate Status Protocol (OCSP) entwickelt: Es gleicht einer Auskunft, bei der Anwendungen den Sperrstatus für einzelne Zertifikate anfragen können, und somit der Bedarf entfällt, die gesamte CRL herunterladen zu müssen. OCSP ist im RFC 6960 spezifiziert.

Google Chrome und Microsoft Edge prüfen Sperrstatus von Zertifikaten nicht

Immer mehr Unternehmen setzen als Standardbrowser auf der Windows-Plattform den Google Chrome Browser oder den neuen auf Chromium basierenden Microsoft Edge (Codename Anaheim) ein.

Bei der Verteilung eines dieser beiden Browser sollte beachtet werden, dass sie sich in Hinsicht auf Zertifikate teils abweichend zu andere Browsern verhalten.

Nebst der Tatsache, dass Chromium im Gegensatz zum Internet Explorer und dem vorigen Edge (Codename Spartan) das RFC 2818 erzwingt, verhält er sich auch bei der Prüfung von Sperrinformationen anders.

Grundlagen: Auffinden von Zertifikaten und Validierung des Zertifizierungspfades

Um feststellen zu können, ob ein Zertifikat von einer als vertrauenswürdig eingestuften Zertifizierungsstelle ausgestellt wurde, muss eine Vertrauenskette (engl. Trust Chain) gebildet werden. Hierfür müssen alle Zertifikate in der Kette ermittelt und überprüft werden. Die Microsoft CryptoAPI bildet alle möglichen Zertifikatketten und liefert diejenigen mit der höchsten Qualität an die anfragende Anwendung zurück.

Grundlagen: Überprüfung des Sperrstatus von Zertifikaten

Soll ein gültiges, noch nicht abgelaufenes Zertifikat aus dem Verkehr gezogen werden, muss es widerrufen werden. Hierfür pflegen die Zertifizierungsstellen entsprechende Sperrlisten, in welchen die digitalen Fingerabdrücke der widerrufenen Zertifikate aufgelistet sind. Sie müssen bei der Gültigkeitsprüfung abgefragt werden.

Kombination Onlineresponder (OCSP) mit Delta CRL und Sperrlistenverteilpunkt (CDP) ohne Deltasperrliste für gesteigerte Resilienz

OCSP Antworten eines Microsoft OCSP Resonders sind genau so lange gültig wie die zugrunde liegende Sperrliste. In manchen Szenarien möchte man die Gültigkeitszeiten von OCSP verringern, indem man Delta CRLs verwendet. Gleichzeitig soll aber bei den in den CDP Pfaden eingetragenen Sperrlisten keine Delta CRL verwendet werden, um einen Fallback auf eine länger gültige CRL zu ermöglichen.

Auswirkungen des Ausfalls des Onlineresponders (OCSP) auf die Überprüfung des Sperrstatus eines Zertifikats

Nachfolgend wird untersucht, wie sich die Überprüfung des Sperrstatus verhält, wenn der Onlineresponder ausfallen sollte. Je nach Konfiguration der ausgestellten Zertifikate kann es hier zu stark abweichendem Verhalten kommen.

Welchen Einfluss hat der Ablauf der Sperrliste einer der übergeordneten Zertifizierungsstellen auf die Zertifizierungsstelle?

Leider kommt es in der Praxis hin und wieder vor, dass die Sperrliste einer übergeordneten Zertifizierungsstelle abläuft und eine Erneuerung ausbleibt. Auch kann dies planmäßig, etwa bei Außerbetriebnahme einer alten Hierarchie geschehen.

Den Adress-Zwischenspeicher für Sperrlisten (CRL URL Cache) einsehen und löschen

Alle Anwendungen, die das Microsoft Cryptographic Application Programming Interface Version 2 (Crypto API Version 2, CAPI2) verwenden, haben einen Mechanismus für die Zwischenspeicherung von Sperrinformationen für Zertifikate (Zertifikatsperrlisten und OCSP-Antworten).

Es kann somit nicht garantiert werden, dass beispielsweise eine neu veröffentlichte Sperrliste von den Teilnehmern verwendet wird, bevor die vorige Sperrliste, die sich noch im Cache befindet, abgelaufen ist.

Nachfolgend wird beschrieben, wie man den Sperrlisten-Cache einsehen und beeinflussen kann.

Grundlagen Public Key Infrastrukturen (PKI)

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.

Domänencontroller überprüfen erweiterte Schlüsselverwendung (Extended Key Usage) bei Smartcard Anmeldung nicht

Wer die Smartcard Logon Funktion im Unternehmen verwenden möchte, ist gut beraten, für eine möglichst starke Sicherheitshärtung seiner Zertifizierungsstelle zu sorgen. Hierzu zählen einige essentielle Maßnahmen:

Entfernen aller nicht notwendigen Zertifizierungsstellen-Zertifikate aus dem NTAuthCertificates Objekt im Active Directory: Jede Zertifizierungsstelle, welche sich in diesem Speicher befindet, ist im Active Directory für die komplette Gesamtstruktur für die Ausstellung von Smartcard Logon Zertifikaten berechtigt.
Verwenden von qualifizierter Subordinierung: Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten Extended Key Usages vertraut wird. Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann auf diese Extended Key Usages beschränkt. Das "Smart Card Logon" Extended Key Usage wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Interessant bei diesen Gedanken ist jedoch, dass die Domänencontroller bei der Anmeldung via Smartcard die Extended Key Usages überhaupt nicht überprüfen.