Principes de base : limiter l'utilisation de la clé étendue (Extended Key Usage, EKU) dans les certificats d'autorité de certification

Une mesure de durcissement judicieuse pour les organismes de certification consiste à limiter les certificats d'organismes de certification, de sorte qu'ils ne puissent être utilisés que pour les certificats effectivement délivrés. utilisation étendue des clés (Extended Key Usage) devient familier.

En cas de compromission de l'autorité de certification, le dommage est alors (tout de même) limité aux Extended Key Usages définis.

Le Smart Card Logon Extended Key Usage, intéressant pour de nombreuses attaques (en relation avec l'adhésion de l'autorité de certification à NTAuthCertificates) ne serait alors présent que dans le certificat d'autorité de certification de l'autorité de certification qui délivre effectivement de tels certificats.

Fonctionnement et contexte

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Les certificats d'entité finale présentent une extension "Extended Key Usage" dans laquelle est définie la finalité pour laquelle le certificat peut être utilisé (p. ex. Transport Layer Security (TLS)).

Microsoft utilise le terme "Enhanced Key Usage" (utilisation améliorée des clés), mais la désignation correcte selon le RFC 5280 est "Extended Key Usage"..

L'Extended Key Usage détermine à quelles fins le certificat peut être utilisé. Dans la boîte de dialogue du certificat de Microsoft-Windows, cela est indiqué dans l'exemple par " ".Assure l'identité d'un ordinateur distant"Il correspond à l'utilisation de la clé étendue pour l'authentification du serveur, comme c'est le cas pour un certificat de serveur web.

L'onglet "Général" de la boîte de dialogue des certificats Windows affiche le résultat de la vérification de la politique du certificat, et non le contenu réel du certificat. Celui-ci peut être consulté dans l'onglet "Détails" et peut très bien être différent.

Dans la configuration standard, un certificat d'autorité de certification n'est pas limité en ce qui concerne les types de certificats. Il manque au certificat une extension "Extended Key Usage", ce qui permet d'utiliser le certificat à toutes fins. Dans la boîte de dialogue des certificats de Microsoft-Windows, cela est indiqué par " ".Toutes les politiques d'application" s'affiche.

Une autorité de certification peut être limitée dans son utilisation en ajoutant une extension "Extended Key Usage". Elle ne peut alors plus délivrer de certificats que pour les UCE définies.

Types de restrictions

Cette procédure de base de restriction technique de l'autorité de certification est connue sous le nom de subordination qualifiée ou d'application de contraintes (en anglais : constraints).

Composant	Description
Limitation de la longueur du chemin (Contrainte de longueur de chemin)	Cela permet de définir combien de niveaux hiérarchiques (donc d'autorités de certification subordonnées) peuvent suivre l'autorité de certification concernée.
Limitations de l'utilisation étendue des clés (Extended Key Usage Constraints)	Il permet de définir les utilisations de clés étendues qui peuvent être acceptées dans les certificats délivrés par l'autorité de certification.
Restrictions des politiques d'exposition (Issuance Policies)	Cela permet de définir les directives de certification pour lesquelles l'organisme de certification peut confirmer la conformité dans les certificats délivrés.
Restrictions de nom (Contraintes de nom)	Cette option permet de définir les espaces de noms pour lesquels l'autorité de certification peut émettre des certificats.

Limiter les utilisations de clés étendues

La procédure visant à restreindre les Extended Key Usages a été utilisée pour la première fois par Microsoft sous le nom de "nested EKU enforcement".

En outre, Microsoft a introduit un autre mécanisme pour restreindre le champ d'application de la confiance accordée à une autorité de certification, en considérant l'extension Extended Key Usage (voir section 4.2.1.13) comme un moyen de déléguer uniquement certaines capacités d'émission à une autorité de certification.
Autorités de certification de dernier recours et subordonnées (Ryan Hurst)

Il est donc pas Partie du RFC 5280. Celui-ci indique simplement que l'extension Extended Key Usage ne doit être attendue que dans les certificats d'identité de fin.

En général, cette extension n'apparaîtra que dans les certificats d'entité finale.
RFC 5280

Cette fonction va toutefois au-delà des exigences du RFC 5280 et est également compatible (si l'extension de certificat correspondante est marquée comme non critique) avec les implémentations qui ne la supportent pas.

Un incident de sécurité populaire dont les conséquences ont tout de même pu être réduites grâce à cette implémentation a été le "Flamme" Incident. Ici, c'est un homme équipé d'une Collision de hachage a permis de signer des logiciels malveillants avec des certificats valables. Le dommage était tout de même limité à "seulement" cette fin (signature de code).

La pratique

Entre-temps, des applications populaires comme Mozilla Firefox et OpenSSL ont adopté le comportement de l'implémentation de Microsoft. Les navigateurs utilisés sur Windows et qui utilisent la CryptoAPI (Google Chrome, Microsot Edge et Internet Explorer) utilisent la bibliothèque système Windows correspondante et se comportent en conséquence.

L'adaptation par des tiers va désormais encore plus loin dans la pratique : dans le domaine des ICP Internet, autour des fournisseurs de navigateurs et d'autorités de certification, l'utilisation est même parfois exigée ou du moins recommandée :

Nous encourageons les AC à imposer des contraintes techniques à tous les certificats intermédiaires. Pour qu'un certificat soit considéré comme techniquement contraint, le certificat DOIT inclure une extension Extended Key Usage (EKU) spécifiant tous les usages de clés étendus pour lesquels l'AC subordonnée est autorisée à émettre des certificats.
Politique du magasin de racines de Mozilla

En général, l'utilisation étendue des clés n'apparaîtra que dans les certificats d'entité finale (comme indiqué dans le RFC 5280 (4.2.1.12)), mais les AC subordonnées peuvent inclure l'extension pour protéger davantage les parties liées jusqu'à ce que l'utilisation de l'extension soit cohérente entre les fournisseurs de logiciels d'application dont les logiciels sont utilisés par une partie substantielle des parties liées dans le monde entier.
CA/Browser (CAB) Forum V1.1.8

Si elle est présente, cette extension DOIT être marquée comme non critique.
CA/Browser (CAB) Forum V1.1.8

Pour qu'un certificat CA subordonné soit considéré comme techniquement contraint, le certificat DOIT inclure une extension Extended Key Usage (EKU) spécifiant tous les usages de clés étendus pour lesquels le certificat CA subordonné est autorisé à émettre des certificats. L'identifiant anyExtendedKeyUsage KeyPurposeId NE DOIT PAS apparaître dans cette extension.
Si le certificat d'autorité de certification subordonnée inclut l'utilisation étendue de la clé id-kp-serverAuth, alors le certificat d'autorité de certification subordonnée DOIT inclure l'extension X.509v3 Name Constraints avec des contraintes sur dNSName, iPAddress et DirectoryName comme suit :
CA/Browser (CAB) Forum V1.7.3

Une curiosité à cet égard est que Let's Encrypt ne respecte pas sa propre politique de certification (qui s'inspire du forum CAB) : Certes, des restrictions d'utilisation de clés étendues sont définies, mais pas les restrictions d'utilisation de clés qui en découlent. Restrictions de nom (Remarque : comment pourrait-il en être autrement, puisque Let's Encrsypt souhaite en principe pouvoir servir tous les espaces de noms DNS).

Si le certificat CA subordonné inclut l'utilisation étendue de la clé id-kp-serverAuth, alors le certificat CA subordonné DOIT inclure l'extension X.509v3 de contraintes de nom avec des contraintes sur dNSName, iPAddress et DirectoryName [...].
Internet Security Research Group (ISRG) Certificate Policy, version 2.2

Évaluation de l'utilisabilité dans la pratique

L'utilisation est possible et judicieuse sans danger, mais elle nécessite une planification approfondie qui devrait également inclure les cas d'application possibles pour les années à venir.

Une telle construction peut réduire considérablement les dommages causés par la compromission d'une autorité de certification (en combinaison avec d'autres mesures de durcissement), mais elle augmente également la complexité à gérer. La complexité étant l'ennemi de la sécurité, la décision doit être mûrement réfléchie.

Mise en œuvre

Avant qu'une autorité de certification ne soit mise en service, les types de certificats qu'elle délivrera sont généralement déjà définis. Ainsi, les Extended Key Usages correspondants peuvent être élaborés à partir de ces certificats.

Par défaut, Microsoft Active Directory Certificate Services refusera d'émettre des certificats dont la politique est différente. Les signatures qui vont directement à l'encontre Fournisseur de stockage de clés continueraient toutefois à être exécutées. Un tel certificat devrait alors être considéré comme non valide.

Cette vérification incombe toutefois à l'application qui traite le certificat, de sorte qu'il n'est pas possible de faire une déclaration générale à ce sujet. Les restrictions sont écrites dans le certificat d'autorité de certification par l'autorité de certification supérieure. Elles doivent donc également être définies par cette dernière.

Dans la pratique, pour des raisons de simplification, les Extended Key Usages seront toutefois demandés par l'autorité de certification concernée et signés par l'autorité de certification supérieure. Afin de préparer la demande de certificat d'une autorité de certification pour la demande d'extended key usages, le fichier capolicy.inf dans le répertoire système (généralement C:\NWindows) est complété par un passage correspondant.

[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

Pour des raisons de compatibilité, l'extension "Extended Key Usage" doit être configurée comme non critique. Les applications qui n'interprètent pas cette extension ne comprendraient sinon pas le certificat de l'autorité de certification et interrompraient le traitement du certificat.

Ci-dessous, une liste des utilisations de clés étendues les plus courantes :

OID	Description
1.3.6.1.4.1.311.20.2.1	Agent de demande de certificat
1.3.6.1.5.5.7.3.2	Authentification du client
1.3.6.1.5.5.7.3.3	Code Signing
1.3.6.1.4.1.311.10.3.13	Signature à vie
1.3.6.1.4.1.311.10.3.12	Signature du document
1.3.6.1.4.1.311.80.1	Cryptage de documents
1.3.6.1.4.1.311.10.3.4	Système de fichiers cryptés
1.3.6.1.4.1.311.10.3.4.1	Récupération de fichiers
1.3.6.1.5.5.7.3.5	Système terminal de sécurité IP
1.3.6.1.5.5.8.2.2	IP Security IKE intermédiaire
1.3.6.1.5.5.7.3.6	Tunnel de sécurité IP Endpoint
1.3.6.1.5.5.7.3.7	Utilisateur de sécurité IP
1.3.6.1.4.1.311.21.6	Agent de récupération des clés
1.3.6.1.4.1.311.10.3.11	Récupération de clés
1.3.6.1.5.2.3.5	Authentification KDC
1.3.6.1.4.1.311.10.3.1	Signature de la liste de confiance Microsoft
1.3.6.1.4.1.311.10.3.10	Subordination qualifiée
1.3.6.1.4.1.311.10.3.9	Signataire de la liste des racines
1.3.6.1.5.5.7.3.4	E-mail sécurisé
1.3.6.1.5.5.7.3.1	Authentification du serveur
1.3.6.1.4.1.311.20.2.2	Connexion par carte à puce
1.3.6.1.5.5.7.3.8	Time Stamping selon RFC 3161
1.3.6.1.5.5.7.3.9	Signature de l'OCSP
1.3.6.1.4.1.311.54.1.2	Authentification du bureau à distance
1.3.6.1.4.1.311.21.5	Archives de clés privées

Dans certaines circonstances, il est recommandé d'inclure les Extended Key Usages suivants dans la liste :

"Signature OCSP" (1.3.6.1..5.5.7.3.9) est nécessaire pour les certificats de signature OCSP. Si l'autorité de certification obtient une entrée OCSP dans l'extension Authority Information Access (AIA), ou si cela pourrait être le cas à l'avenir, cette EKU devrait être incluse, sinon aucun certificat de signature OCSP ne pourra être délivré par cette autorité de certification.
"Private Key Archival" (1.3.6.1.4.1.311.21.5) est utilisé par les Échange d'autorités de certification ("CA Exchange") de l'autorité de certification. Outre la tâche proprement dite d'archivage des clés privées, ce type de certificat est également demandé par la console Enterprise PKI (pkiview.msc). Si cet Extended Key Usage manque dans le certificat de l'autorité de certification, aucun certificat d'échange d'autorités de certification (CA Exchange) ne peut être délivré et l'autorité de certification enregistrera l'échec de la demande de certificat.. L'utilisation étendue des clés devrait donc en principe être incluse dans la liste.
"Agent de demande de certificat" (1.3.6.1.4.1.311.20.2.1) est utilisé pour Inscription à la demande de (EOBO) opérations, mais aussi pour l'installation d'un Service d'enregistrement des équipements de réseau (NDES) est utilisé. Si l'autorité de certification doit servir l'un de ces cas maintenant ou éventuellement plus tard, cette utilisation étendue de la clé devrait être incluse. Lors de l'évaluation, il est important de garder à l'esprit que les clients "modernes" peuvent potentiellement utiliser des clés USB. Microsoft Intune sont gérés, qui nécessitera à son tour une ou plusieurs instances NDES.

Le certificat d'autorité de certification qui en résulte aura alors une extension "Extended Key Usage" correspondante.

Les types de certificats utilisables sont ensuite appliqués en conséquence dans l'onglet "General" de la boîte de dialogue des certificats.

Un certificat (potentiellement généré de manière malveillante) qui ne correspond pas aux directives configurées peut être détecté par l'application. Dans le cas d'une application Windows, un avertissement correspondant s'affiche.

Une fois de plus, il convient de souligner que la vérification du certificat incombe à l'application utilisée et que les résultats peuvent varier considérablement selon l'implémentation. Par exemple, tous les navigateurs courants sont très stricts à cet égard, alors que un contrôleur de domaine ne se soucie pas des utilisations de clés étendues dans le certificat par défaut.

Liens complémentaires :

Sources externes

RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
Constraining Extended Key Usages dans Microsoft Windows (Vadims Podans)
CA racine avec champs d'utilisation de clé étendus (security.stackexchange.com)
Comprendre les contraintes / la politique d'application (Microsoft)
Exigences de base pour l'émission et la gestion de certificats garantis par le public, versions 1.7.3, 1.1.8 (CA/Browser Forum)
Politique du magasin de racines de Mozilla (Mozilla)
CA/Subordinate CA Liste de contrôle (Mozilla)
Annonce de la version 2.1 de la politique de certification CA de Mozilla (Mozilla)
Internet Security Research Group (ISRG) Certificate Policy, version 2.2 (Internet Security Research Group)
Support enforcing nested EKU constraints, do so by default. (Bugtracker Mozilla)
MSRC 2718704 et Nested EKU enforcement (Ryan Hurst, "Unmitigated Risk", ancien employé de Microsoft et représentant de l'IETF pour Microsoft)