Renforcement cryptographique des transactions SCEP pour le service d'inscription des périphériques réseau (Network Device Enrollment Service, NDES)

Le site Protocole simple d'inscription de certificats (SCEP) Il s'agit d'un protocole très ancien datant du début des années 2000. Il ne fait pas appel au protocole TLS (Transport Layer Security). Les messages du protocole sont donc chiffrés au niveau de la couche de transport.

Lors de l'envoi de la demande de certificat au serveur NDES, le client effectuera cette demande à l'aide du certificat de chiffrement CEP du serveur NDES (qui lui a été communiqué auparavant via le message GetCACert).

À la réception du certificat émis, le serveur NDES chiffrera la réponse à l'aide d'un certificat auto-signé généré temporairement par le client SCEP.

Dans les deux cas, on utilise un algorithme de chiffrement symétrique.

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 capacités possibles sont répertoriées dans RFC 8894 sont définies pour le SCEP et sont communiquées au client SCEP via l'opération „ GetCACaps “.

Capacité	Description
AES	Prise en charge de la norme AES (AES128-CBC).
DES3	Prise en charge de la norme 3DES-CBC (Triple Data Encryption Standard).
GetNextCACert	Pour le renouvellement des certificats des autorités de certification. Non pris en charge par NDES.
Opération post-PKI	Effectuer les opérations via une requête HTTP POST plutôt que GET.
Renouvellement	Renouvellement d'un certificat à l'aide d'un certificat existant.
SHA-1	Prise en charge de l'algorithme de hachage SHA-1.
SHA-256	Prise en charge de l'algorithme de hachage SHA-256.
SHA-512	Prise en charge de l'algorithme de hachage SHA-512.
Norme SCEP	Indique que le serveur a traité tous les dont la mise en œuvre est obligatoire Prise en charge des opérations standard SCEP conformément à la RFC. Parmi celles-ci figurent notamment „ AES “, „ POSTPKIOperation “ et „ SHA-256 “.

Paramètres par défaut de NDES

À sa sortie d'usine, NDES communique les capacités suivantes aux clients SCEP :

Opération post-PKI
Renouvellement
SHA-512
SHA-256
SHA-1
DES3

Les capacités peuvent être consultées depuis le serveur NDES via un navigateur ou PowerShell.

Invoke-WebRequest -Uri "http://localhost/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACaps"

Comme on peut le constater, l'algorithme AES, plus moderne, fait ici défaut. Nous allons voir ci-après comment faire en sorte que NDES propose également cet algorithme.

La norme SCEP ne spécifie que l'algorithme AES-CBC à 128 bits. En théorie, les clients SCEP pourraient également utiliser d'autres algorithmes. Il n'existe toutefois pas de capacités normalisées correspondantes.

Modification des paramètres par défaut

Il est important de comprendre que les « capacités » ne servent qu'à indiquer quels algorithmes le serveur NDES comprend dans tous les cas. Les clients ne sont pas tenus de respecter les capacités propagées. Dès sa sortie d'usine, NDES accepte tous les algorithmes, de RC2 à AES. En supposant que les clients comprennent et appliquent les capacités propagées, nous pouvons tout de même faire en sorte qu’ils utilisent AES à la place de 3DES. Nous ne pouvons toutefois rien imposer.

Les capacités propagées peuvent être configurées à l'aide de la clé de registre suivante sur le serveur NDES :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\CACapabilitiesAlgorithms

Dans la configuration d'usine de NDES, cette clé de registre n'existe pas. Elle peut être créée à l'aide de la commande suivante (avec les paramètres par défaut) :

certutil -f -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms "SHA-512\nSHA-256\nSHA-1\nDES3"

Les opérations „ POSTPKI “ et „ Renewal “ ne sont pas configurables ; elles ne doivent donc pas et ne peuvent pas être définies via le Registre.

Par exemple, pour ajouter la prise en charge de la norme AES (Advanced Encryption Standard) :

certutil -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms +AES

Les valeurs sont enregistrées dans le registre sous forme de chaînes de caractères simples et sont également affichées sous cette forme. Il est donc impératif de veiller à l'orthographe correcte (tel que défini dans la RFC 8894) tenir compte de.

Par exemple, pour désactiver la prise en charge de Triple DES et de SHA-1 :

certutil -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms -DES3
certutil -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms -"SHA-1"

La suppression de 3DES et de SHA-1 doit être mûrement réfléchie, car ces algorithmes peuvent servir de solution de repli pour les clients qui ne prennent pas en charge l'AES. Si l'on supprime ces fonctionnalités, les clients pourraient alors utiliser des algorithmes encore moins sûrs. Il est préférable de les placer en dessous d'algorithmes plus puissants.

Une fois la modification effectuée, le service NDES doit être redémarré. Le moyen le plus simple consiste à redémarrer le service IIS.

iisreset

Comportement côté client

Le comportement des clients SCEP dépend de l'implémentation concrète.

Avec certains clients SCEP (par exemple, BlackBerry Enterprise Mobility Suite), il est possible de configurer l'utilisation de certains algorithmes (les capacités proposées par le serveur NDES sont alors généralement ignorées).

Les clients SCEP qui utilisent les API Windows (par exemple Microsoft Intune, certutil ou PSCertificateEnrollment) évaluent les capacités proposées par le serveur NDES de haut en bas et utilisent le premier algorithme de hachage ainsi que le premier algorithme de chiffrement de la liste pris en charge par la clé publique du client. Le choix de ces algorithmes dépend de l'algorithme et du CSP/KSP qui a été utilisé pour la demande de certificat.

Mais attention ! Si un client ne prend en charge aucun des algorithmes proposés, il se rabat sur un algorithme compris par le CSP/KSP sous-jacent ! Nous y reviendrons plus en détail ci-dessous.

Test de fonctionnement

Une fois nos modifications effectuées, nous devons vérifier le bon fonctionnement du service NDES. Vous trouverez ici des instructions détaillées dans l'article „Effectuer un test de fonctionnement pour le service d'enregistrement des périphériques réseau (NDES)„ .

Nous allons nous concentrer sur la procédure concrète de demande d'un certificat via SCEP. Nous pouvons effectuer cette opération facilement à l'aide du module PowerShell PSCertificateEnrollment. Celui-ci interroge le serveur NDES pour connaître ses capacités et les utilise en conséquence lors de la demande de certificat.

Il est important de comprendre ici que, par défaut, PSCertificateEnrollment utilise le „ Microsoft Software Key Storage Provider “ pour la paire de clés de la demande de certificat, ce dernier prenant en charge à la fois le 3DES et l'AES.

$otp = Get-NDESOTP -ComputerName NDES01.intra.adcslabor.de
Get-NDESCertificate `
  -Subject "CN=hello" `
  -ChallengePassword $otp `
  -ComputerName "NDES01.intra.adcslabor.de"

Comme le protocole SCEP utilise par défaut le protocole HTTP non chiffré, nous pouvons analyser la communication à l'aide de Wireshark et extraire le message SCEP.

Nous pouvons désormais les utiliser avec le Éditeur ASN.1 par Vadims Podans l'ouvrir et consulter le message PKCS7 qu'il contient.

Avec les paramètres par défaut de NDES, nous identifierons ici „ 3des “ comme algorithme de chiffrement pour les données encapsulées PKCS7.

Une fois les capacités modifiées, nous devrions constater que la valeur affichée est désormais „ aes128-CBC “.

Pièges à éviter

Le type de chiffrement effectivement utilisé dépend de plusieurs facteurs.

Le fournisseur de stockage de clés du client demandeur doit correspondre

NDES n'impose aucun algorithme particulier. Les clients parviennent à se connecter même avec des algorithmes complètement obsolètes.

À des fins de test, nous générons notre paire de clés sur le client à l'aide de la commande (non recommandée !) Microsoft Base Cryptographic Provider v1.0, qui ne prend en charge ni le 3DES ni l'AES.

$otp = Get-NDESOTP -ComputerName NDES01.intra.adcslabor.de
Get-NDESCertificate `
  -Subject "CN=hello" `
  -ChallengePassword $otp `
  -ComputerName "NDES01.intra.adcslabor.de" `
  -Ksp "Microsoft Base Cryptographic Provider v1.0"

Nous constatons maintenant que le message a été chiffré à l'aide de l'algorithme RC2. NDES prend ce message en charge et le traite sans difficulté.

Le fournisseur du magasin de clés du serveur NDES doit être compatible

La mémoire de clés du serveur NDES (plus précisément, celle du certificat de chiffrement CEP utilisé) doit également contenir les algorithmes utilisés.

À première vue, cela semble paradoxal, car NDES ne prend en charge que les fournisseurs de services cryptographiques (CSP), dont très peu prennent en charge 3DES, et encore moins AES.

Toutefois, si un CSP Microsoft est utilisé, la CryptoAPI (CAPI2) du serveur NDES ouvrira de manière transparente la clé du certificat de chiffrement CEP en tant que clé NCrypt afin d'effectuer l'opération.

En revanche, si l'on utilise le fournisseur de services cryptographiques (CSP) d'un tiers (par exemple, lorsqu'un module de sécurité matériel est utilisé pour NDES), cela n'est pas possible. Si le CSP tiers n'a pas implémenté les algorithmes correspondants, ceux-ci ne peuvent pas être utilisés avec NDES.

Si une demande de certificat SCEP fait défaut pour cette raison, NDES va Événement d'ID 18 provenant de la source Microsoft-Windows-NetworkDeviceEnrollmentService enregistrer. Côté client, le code d'erreur 0x80090005 (-2146893819 NTE_BAD_DATA) sera renvoyé par le serveur NDES.

Conclusion

En modifiant les capacités communiquées aux clients par NDES, nous pouvons, dans certaines circonstances, les amener à utiliser AES plutôt que 3DES comme algorithme de chiffrement par défaut.

Même si nous ne le faisons pas, NDES accepte déjà, dans sa configuration par défaut, les messages SCEP chiffrés en AES.

De plus, il est désormais courant de, HTTPS pour NDES à configurer, de sorte que toute cette discussion prend de toute façon une dimension purement théorique, puisqu'il existe dans ce cas une couche TLS supplémentaire qui rend finalement l'algorithme de chiffrement interne moins pertinent.