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.

Komponente	Beschreibung
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 zumindest 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.

Microsoft Active Directory Certificate Services 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:

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

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

"OCSP Signing" (1.3.6.1..5.5.7.3.9) wird für OCSP Signaturzertifikate benötigt. Sollte die Zertifizierungsstelle einen OCSP Eintrag in der Authority Information Access (AIA) Erweiterung erhalten, oder könnte dies in Zukunft der Fall sein, sollte dieses EKU mit aufgenommen werden, da andernfalls keine OCSP-Signaturzertifikate von dieser Zertifizierungsstelle ausgestellt werden können.
"Private Key Archival" (1.3.6.1.4.1.311.21.5) wird von den Zertifizierungsstellen-Austausch ("CA Exchange") Zertifikaten der Zertifizierungsstelle benötigt. Neben der eigentlichen Aufgabe der Archivierung privater Schlüssel wird dieser Zertifikattyp auch von der Enterprise PKI (pkiview.msc) Konsole angefordert. Fehlt dieser Enhanced Key Usage im Zertifizierungsstellen-Zertifikat, können keine Zertifizierungsstellenaustausch (CA Exchange) Zertifikate ausgestellt werden und die Zertifizierungsstelle wird eine fehlgeschlagene Zertifikatanforderung protokollieren. Das Extended Key Usage sollte darum grundsätzlich mit in die Liste aufgenommen werden.
"Certificate Request Agent" (1.3.6.1.4.1.311.20.2.1) wird für Enroll on Behalf of (EOBO) Operationen, aber auch für die Installation eines Registrierungsdienstes für Netzwerkgeräte (NDES) eingesetzt. Sollte die Zertifizierungsstelle einen dieser Fälle jetzt oder auch eventuell später bedienen sollen, sollte dieses Enhanced Key Usage mit aufgenommen werden. Bei der Bewertung unbedingt bedenken, dass "moderne" Clients potentiell mit Microsoft Intune verwaltet werden, welches wiederum einen oder mehrere NDES-Instanzen benötigen wird.

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

RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
Constraining Extended Key Usages in Microsoft Windows (Vadims Podans)
Root CA with Extended Key Usage fields (security.stackexchange.com)
Understanding Constraints / Application Policy (Microsoft)
Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Versionen 1.7.3, 1.1.8 (CA/Browser Forum)
Mozilla Root Store Policy (Mozilla)
CA/Subordinate CA Checklist (Mozilla)
Announcing Version 2.1 of Mozilla CA Certificate Policy (Mozilla)
Internet Security Research Group (ISRG) Certificate Policy, Version 2.2 (Internet Security Research Group)
Support enforcing nested EKU constraints, do so by default. (Mozilla Bugtracker)
MSRC 2718704 and Nested EKU enforcement (Ryan Hurst, "Unmitigated Risk", ehemaliger Microsoft Mitarbeiter und IETF-Vertreter für Microsoft)