Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten

Eine sinnvolle Härtungsmaßnahme für Zertifizierungsstellen ist das Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten erweiterten Schlüsselverwendungen (Extended Key Usage) vertraut wird.

Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann (immerhin) auf die definierten Extended Key Usages beschränkt.

Das für viele Angriffe interessante Smart Card Logon Extended Key Usage (in Verbindung mit der Mitgliedschaft der Zertifizierungsstelle in NTAuthCertificates) wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Funktionsweise und Hintergründe

End-Entitätszertifikate weisen eine Erweiterung "Enhanced Key Usage" auf, in welcher definiert wird, für welche Zwecke das Zertifikat eingesetzt werden darf (z.B. Transport Layer Security (TLS)).

Microsoft verwendet den Terminus "Enhanced Key Usage", die korrekte Bezeichnung gemäß RFC 5280 ist allerdings "Extended Key Usage".

Das Extended Key Usage legt fest, für welche Zwecke das Zertifikat verwendet werden darf. Im Zertifikat-Dialog von Microsoft-Windows wird dies im Beispiel durch "Ensures the Identity of a Remote Computer" angezeigt und entspricht dem Extended Key Usage für "Server Authentication", wie es für ein Webserver-Zertifikat typisch ist.

Der Karteireiter "General" im Windows-Zertifikatdialog zeigt das Ergebnis der Richtlinien-Überprüfung des Zertifikats an, nicht den tatsächlichen Inhalt des Zertifikats. Dieser kann im "Details"-Karteireiter eingesehen werden und kann durchaus abweichen.

In der Standard-Konfiguration ist ein Zertifizierungsstellen-Zertifikat in Hinsicht auf die Zertifikattypen nicht eingeschränkt. Dem Zertifikat fehlt eine "Enhanced Key Usage" Erweiterung, somit ist das Zertifikat für alle Zwecke nutzbar. Im Zertifikat-Dialog von Microsoft-Windows wird dies durch "All Application Policies" angezeigt.

Eine Zertifizierungsstelle kann durch Hinzufügen einer "Extended Key Usage" Erweiterung in ihrer Verwendbarkeit eingeschränkt werden. Sie kann dann nur noch Zertifikate für die definierten EKUs ausstellen.

Arten der Einschränkungen

Diese grundlegende Vorgehensweise der technischen Einschränkung der Zertifizierungsstelle ist unter dem Begriff Qualifizierte Subordinierung oder Anwenden von Einschränkungen (engl. Constraints) bekannt.

KomponenteBeschreibung
Einschränkung der Pfadlänge
(Path Length Constraint)
Hiermit lässt sich festlegen, wie viele Hierarchie-Ebenen (also untergeordnete Zertifizierungsstellen) nach der betreffenden Zertifizierungsstelle folgen dürfen.
Einschränkungen der erweiterten Schlüsselverwendung (Extended Key Usage Constraints)Hiermit lässt sich festlegen, welche erweiterten Schlüsselverwendungen in von der Zertifizierungsstelle ausgestellten Zertifikaten akzeptiert werden dürfen.
Einschränkungen der Ausstellungsrichtlinien (Issuance Policies)Hiermit lässt sich festlegen, für welche Zertifikatrichtlinien die Zertifizierungsstelle deren Konformiität in ausgestellten Zertifikaten bestätigen darf.
Namenseinschränkungen (Name Constraints)Hiermit lässt sich festlegen, für welche Namensräume die Zertifizierungsstelle Zertifikate ausstellen darf.

Einschränken der Extended Key Usages

Das Verfahren, die Extended Key Usages einzuschränken wurde erstmals von Microsoft unter dem Namen "nested EKU enforcement" eingesetzt.

In addition Microsoft introduced another mechanism to restrict the scope in which a CA is trusted for, they did this by treating the Extended Key Usage (see section 4.2.1.13) extension as a means to delegate only certain issuance capabilities to a Certificate Authority

Least Privilege and Subordinate Certificate Authorities (Ryan Hurst)

Es ist somit nicht Teil des RFC 5280. Dieses weist lediglich darauf hin, dass die Extended Key Usage Erweiterung nur in Endentitätszertifikaten zu erwarten ist.

In general, this extension will appear only in end entity certificates.

RFC 5280

Die Funktion geht aber über die Anforderungen des RFC 5280 hinaus und ist (wenn die entsprechende Zertifikaterweiterung als nicht kritisch markiert wird) auch kompatibel zu Implementierungen, welche sie nicht unterstützen.

Ein populärer Sicherheitsvorfall, dessen Folgen durch diese Implementierung immerhin reduziert werden konnten war der "Flame" Incident. Hier kam es durch ein mit einer Hashkollision erzeugtes gefälschtes Codesignaturzertifikat dazu, dass Malware mit gültigen Zertifikaten signiert werden konnte. Der Schaden war immerhin auf "nur" diesen Zweck (Codesignatur) begrenzt.

Die Praxis

Mittlerweile haben populäre Anwendungen wie Mozilla Firefox und OpenSSL das Verhalten der Microsoft-Implementierung übernommen. Browser, welche auf Windows eingesetzt werden und die CryptoAPI verwenden (Google Chrome, Microsot Edge und Internet Explorer) nutzen die entsprechende Windows-Systembibliothek und verhalten sich entsprechend.

Die Adaption durch Dritte geht in der Praxis mittlerweile sogar noch weiter: Im Bereich der Internet-PKI um die Browser- und Zertifizierungsstellen-Anbieter herum wird der Einsatz mittlerweile teils sogar eingefordert oder zumidnest empfohlen:

We encourage CAs to technically constrain all intermediate certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for.

Mozilla Root Store Policy

Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide.

CA/Browser (CAB) Forum V1.1.8

If present, this extension SHOULD be marked non-critical.

CA/Browser (CAB) Forum V1.1.8

For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.
If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:

CA/Browser (CAB) Forum V1.7.3

Ein Kuriosum hierbei ist, dass sich Let’s Encrypt nicht an die eigene Certificate Policy (die an das CAB Forum angelehnt ist) hält: Zwar sind Extended Key Usage Einschränkungen definiert, aber nicht die geforderten damit einhergehenden Namenseischränkungen (Anmerkung: wie denn auch, schließlich möchte Let’s Encrsypt grundsätzlich alle DNS-Namensräume bedienen können).

If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName […]

Internet Security Research Group (ISRG) Certificate Policy, Version 2.2

Bewertung zur Verwendbarkeit in der Praxis

Der Einsatz ist gefahrlos möglich und auch sinnvoll, erfordert allerdings eine gründliche Planung, die auch mögliche Anwendungsfälle für die kommenden Jahre beinhalten sollte.

Ein solches Konstrukt kann den durch die Kompromittierung einer Zertifizierungsstelle entstehenden Schaden (in Verbindung mit weiteren Härtungsmaßnahmen) drastisch reduzieren, erhöht andererseits aber auch die zu handhabende Komplexität. Komplexität wiederum ist der Feind von Sicherheit, sodass die Entscheidung wohlüberlegt sein will.

Umsetzung

Bevor eine Zertifizierungsstelle in Betrieb genommen wird ist üblicherweise bereits definiert, welche Zertifikattypen sie ausstellen wird. Somit können aus diesen die entsprechenden Extended Key Usages herausgearbeitet werden.

Die Microsoft Zertifizierungsstelle wird in der Standardeinstellung die Ausstellung von Zertifikaten mit abweichender Policy verweigern. Signaturen, die direkt gegen den Key Storage Provider vorgenommen werden, würden jedoch weiterhin ausgeführt. Ein solches Zertifikat sollte dann als ungültig betrachtet werden.

Diese Überprüfung obligt jedoch der jeweiligen Anwendung, die das Zertifikat verarbeitet, sodas hier keine allgemeingültige Ausssage getroffen werden kann. Die Einschränkungen werden von der übergeordneten Zertifizierungsstelle in das Zertifizierungsstellen-Zertifikat geschrieben. Sie sollten daher auch von dieser definiert werden.

In der Praxis wird man aus Gründen der Vereinfachung die Extended Key Usages jedoch von der betreffenden Zertifizierungsstelle beantragen und durch die übergeordnete Zertifizierungsstelle signieren lassen. Um den Zertifikatantrag einer Zertifizierungsstelle für die Beantragung von Extended Key Usages vorzubereiten, wird die Datei capolicy.inf im Systemverzeichnis (üblicherweise C:\Windows) um eine entsprechende Passage erweitert.

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.9 ; OCSP Signing
OID=1.3.6.1.4.1.311.21.5 ; Private Key Archival
Critical=FALSE

Aus Kompatibilitätsgründen sollte die "Enhanced Key Usage" Erweiterung als nicht kritisch konfiguriert werden. Anwendungen, welche diese Erweiterung nicht interpretieren, würden das Zertifizierungsstellen-Zertifikat ansonsten nicht verstehen und die Zertifikatverarbeitung abbrechen.

Nachfolgend eine Liste der am häufigsten verwendeten Extended Key Usages:

OIDBeschreibung
1.3.6.1.4.1.311.20.2.1Certificate Request Agent
1.3.6.1.5.5.7.3.2Client Authentication
1.3.6.1.5.5.7.3.3Code Signing
1.3.6.1.4.1.311.10.3.13Lifetime Signing
1.3.6.1.4.1.311.10.3.12Document Signing
1.3.6.1.4.1.311.80.1Document Encryption
1.3.6.1.4.1.311.10.3.4Encrypting file system
1.3.6.1.4.1.311.10.3.4.1File Recovery
1.3.6.1.5.5.7.3.5IP Security End System
1.3.6.1.5.5.8.2.2IP Security IKE Intermediate
1.3.6.1.5.5.7.3.6IP Security Tunnel Endpoint
1.3.6.1.5.5.7.3.7IP Security User
1.3.6.1.4.1.311.10.3.11Key Recovery
1.3.6.1.5.2.3.5KDC Authentication
1.3.6.1.4.1.311.10.3.1Microsoft Trust List Signing
1.3.6.1.4.1.311.10.3.10Qualified Subordination
1.3.6.1.4.1.311.10.3.9Root List Signer
1.3.6.1.5.5.7.3.4Secure E-mail
1.3.6.1.5.5.7.3.1Server Authentication
1.3.6.1.4.1.311.20.2.2Smartcard Logon
1.3.6.1.5.5.7.3.8Time Stamping gemäß RFC 3161
1.3.6.1.5.5.7.3.9OCSP Signing
1.3.6.1.4.1.311.54.1.2Remote Desktop Authentication
1.3.6.1.4.1.311.21.5Private Key Archival
2.16.840.1.113741.1.2.3Intel Advanced Management Technology (AMT) Provisioning

Unter Umständen empfiehlt es sich, die folgenden Extended Key Usages mit in die Liste aufzunehmen:

Das resultierende Zertifizierungsstellen-Zertifikat wird dann eine entsprechende "Enhanced Key Usage" Erweiterung aufweisen.

Die nutzbaren Zertifikattypen werden dann in der "General" Karteikarte des Zertifikat-Dialogs entsprechend angewendet.

Ein (potentiell böswillig erzeugtes) Zertifikat, das nicht den konfigurierten Richtlinien entspricht, kann von der Anwendung entsprechen erkannt werden. Im Fall einer Windows-Anwendung wird eine entsprechende Warnung angezeigt.

Nochmals muss darauf hingewiesen werden, dass die Prüfung des Zertifikats der verwendenden Anwendung obliegt und sich die Ergebnisse je nach Implementierung stark unterscheiden können. Beispielsweise sind alle gängigen Browser in dieser Hinsicht sehr strikt, wohingegen einem Domänencontroller die Extended Key Usages im Zertifikat in der Standardeinstellung komplett egal sind.

Weiterführende Links:

Externe Quellen

14 Gedanken zu „Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten“

Kommentare sind geschlossen.