Signataires de noyau personnalisés pour App Control for Business

À compter d’avril 2026, les autorités de certification croisées ne sont plus approuvées par défaut pour la signature du pilote en mode noyau. Le chemin d’accès standard pour la signature du pilote du noyau passe par le biais du Centre de développement matériel (HDC), qui nécessite l’envoi de fichiers binaires de pilotes à Microsoft pour la certification WHCP (Programme de compatibilité matérielle Windows ). Toutefois, les organisations avec des environnements classifiés, sensibles ou aérés peuvent ne pas être en mesure de soumettre des pilotes à Microsoft pour certification. En outre, les organisations qui écrivent des pilotes pour un usage interne uniquement peuvent ne pas vouloir certifier des pilotes pour l’écosystème Windows.

Les signataires de noyau personnalisés résolvent ce problème en étendant App Control for Business pour permettre aux organisations d’approuver les pilotes de noyau signés avec leur propre infrastructure à clé publique (PKI), sans nécessiter de signatures WHCP. La fonctionnalité utilise une stratégie De contrôle d’application signée par une autorité de signature dans la hiérarchie de démarrage sécurisé pour définir les certificats de signature autorisés pour le code en mode noyau. Cette fonctionnalité vous donne un contrôle granulaire et auditable sur votre limite d’approbation de noyau et supprime l’exigence de certification WHCP de vos pilotes.

Fonctionnement des signataires de noyau personnalisés

La fonctionnalité signataires de noyau personnalisé utilise une chaîne d’approbation en couches et une stratégie De contrôle d’application pour remplacer les exigences de signature par défaut intégrées au noyau Windows. Voici comment fonctionne la chaîne d’approbation :

Seul le détenteur de la plateforme (propriétaire PK ou KEK) peut autoriser la stratégie. Ce processus d’inscription à friction élevée est intentionnel. Le processus empêche toute utilisation incorrecte sur les appareils grand public et garantit que seules les organisations disposant d’un accès physique au microprogramme peuvent activer la fonctionnalité.

Garanties de sécurité

Les signataires de noyau personnalisés fournissent les garanties de sécurité suivantes :

• Intégrité du démarrage sécurisé : Les signataires de noyau personnalisés fonctionnent uniquement lorsque le démarrage sécurisé est activé. La stratégie doit être signée par le propriétaire PK ou KEK de démarrage sécurisé et ne peut pas être usurpée sans accès physique au microprogramme.
• Protection contre les falsifications : Une fois déployée, la stratégie signée ne peut pas être supprimée sans une stratégie de remplacement signée par la même autorité.
• Approbation granulaire : La stratégie App Control autorise les règles d’approbation par certificat et par hachage. Vous contrôlez exactement les pilotes qui s’exécutent dans votre noyau.
• Non-répudiation : Toutes les signatures de stratégie et de pilote sont vérifiables par chiffrement. Les journaux des événements d’intégrité du code capturent toutes les décisions de chargement et de blocage pour l’audit.

Plateformes et éditions prises en charge

La fonctionnalité signataires de noyau personnalisé est disponible sur les plateformes Windows suivantes avec la mise à jour non liée à la sécurité d’avril 2026 :

• Windows 11 (version 24H2 et ultérieures)

La fonctionnalité est disponible sur toutes les éditions de Windows, à l’exception de la version Familiale.

Déploiement de signataires de noyau personnalisés

Avant de commencer, vérifiez que les conditions suivantes sont remplies :

• Nouvelle installation de Windows sur une édition prise en charge. Les signataires de noyau personnalisés doivent être activés lors de la configuration initiale de l’appareil. La fonctionnalité ne s’active pas sur les systèmes en cours d’exécution.
• Microprogramme UEFI (version 2.3 ou ultérieure) avec démarrage sécurisé activé.
• Infrastructure PKI appartenant au client. Une solution de stockage de clés HSM est recommandée pour les environnements de production.
• Accès administratif aux variables de microprogramme UEFI (PK, KEK, DB).
• SignTool.exe du SDK Windows.
• Connaissance de la conception de stratégie App Control pour Entreprise, de la stratégie signée et des règles de stratégie.

Étape 1 : Générer les clés de démarrage sécurisé

Générez la paire de clés PKI qui sert de racine de confiance dans le démarrage sécurisé et qui sera utilisée pour signer votre stratégie De contrôle d’application. La clé PK ou KEK peut être utilisée comme racine de confiance pour signer la stratégie De contrôle d’application. Les conseils de Microsoft sont d’ajouter la clé PKI à la clé KEK afin que le propriétaire de PK puisse continuer à traiter la clé KEK à l’avenir.

Les certificats PK et KEK doivent être des certificats racines ou des certificats intermédiaires (PCA) émis directement à partir de la racine. Le document Conseils de création et de gestion de la clé de démarrage sécurisé Windows contient plus d’informations et de conseils sur la création de certificats compatibles avec le démarrage sécurisé. Vous pouvez également utiliser la clé KEK Microsoft comme modèle de référence pour les propriétés de clé et les extensions.

Étape 2 : Configurer les variables UEFI de démarrage sécurisé avec accès au PK

Si vous êtes propriétaire du PK sur les appareils, vous pouvez signer l’inscription KEK pour ajouter votre clé publique KEK au microprogramme UEFI. Si vous ne possédez pas le PK, vous pouvez passer à l’étape 3.

Générer le contenu d’inscription kek

# Generate KEK content file
# Replace the SignatureOwner GUID with your organization's GUID
Format-SecureBootUEFI `
    -Name KEK `
    -SignatureOwner "55555555-5555-5555-5555-555555555555" `
    -ContentFilePath C:\KEK\KEK_SigList.bin `
    -FormatWithCert `
    -Certificate C:\KEK\policy_signer.cer `
    -SignableFilePath C:\KEK\KEK_Signable_SigList.bin `
    -Time 2025-01-01T00:00:00Z `
    -AppendWrite:$true

Signer le fichier d’inscription KEK avec votre PK

signtool.exe sign /fd sha256 
    /p7 .\ 
    /p7co 1.2.840.113549.1.7.1 `
    /p7ce DetachedSignedData `
    /a `
    /f PK.pfx`
    C:\KEK\KEK_Signable_SigList.bin

Étape 3. Configurer les variables UEFI de démarrage sécurisé sans accès au PK

Pour définir les variables de démarrage sécurisé UEFI, commencez par désactiver le démarrage sécurisé dans le menu UEFI pour placer le microprogramme en mode d’installation. En mode d’installation, les variables peuvent être définies sans mises à jour signées.

Définissez les variables dans l’ordre suivant :

1. Base de données : ajoutez le certificat OEM et Windows UEFI CA 2023.
2. KEK : ajoutez la clé de certification Microsoft KEK 2K 2023 et le certificat de signataire de la stratégie de votre organization.
3. PK : définissez la clé de plateforme de votre organization (ou laissez la clé PK OEM en place si vous utilisez l’inscription KEK).

Étape 4 : Créer la stratégie De contrôle d’application

Commencez par la stratégie Windows appliquée par défaut comme modèle de base, puis analysez l’appareil à la recherche d’autres signataires qui doivent être approuvés.

Rechercher le modèle de stratégie par défaut

Le modèle de stratégie par défaut est disponible à l’adresse suivante :

%WINDIR%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml

Analyser l’appareil à la recherche de signataires de noyau existants

New-CIPolicy -ScanPath 'C:\' -UserPEs -NoScript `
    -FilePath '.\ScannedPolicy.xml' `
    -Level PCACertificate -Fallback Hash

Fusionner la stratégie par défaut avec les résultats de l’analyse

Merge-CIPolicy `
    -PolicyPaths 'C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml', '.\ScannedPolicy.xml' `
    -OutputFilePath '.\CustomKernelSignersPolicy.xml'

Préparer votre stratégie pour la signature

La fonctionnalité signataires de noyau personnalisé nécessite que la stratégie soit signée et protégée par le démarrage sécurisé et les composants de démarrage windows précoces. Consultez plus d’informations sur les stratégies App Control signées. Pour activer la stratégie signée, supprimez l’option 6 (stratégie non signée) :

Set-RuleOption -Option 6 -FilePath .\CustomKernelSignersPolicy.xml -Delete

(Facultatif) Supprimer l’intégrité du code en mode utilisateur

Si vous souhaitez que la stratégie s’applique uniquement aux pilotes en mode noyau, supprimez l’option 0 (UMCI) :

Set-RuleOption -Option 0 -FilePath .\CustomKernelSignersPolicy.xml -Delete

Bonnes pratiques pour la stratégie de base

• Personnalisez d’abord l’image. Supprimez les logiciels non approuvés avant d’analyser l’appareil.
• Utiliser -Level PCACertificate pour le meilleur équilibre entre spécificité et couverture.
• L’analyse capture tous les signataires existants sur l’appareil, garantissant ainsi que les composants Windows et les pilotes matériels restent approuvés. Envisagez plutôt d’analyser uniquement vos pilotes confidentiels.
• Testez minutieusement en mode Audit avant de déployer en mode appliqué.

Étape 5 : Ajouter des signataires de noyau personnalisés à la stratégie

Ajoutez le hachage TBS (To Be Signed) de chaque certificat approuvé aux sections suivantes de votre code XML de stratégie. Vous avez besoin d’entrées pour :

# Policy signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Update

# Custom kernel signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Kernel

Étape 6 : Convertir et signer la stratégie

Convertir la stratégie XML au format binaire

Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\CustomKernelSignersPolicy.xml
$PolicyId = ([xml](Get-Content .\CustomKernelSignersPolicy.xml)).SiPolicy.PolicyId
ConvertFrom-CIPolicy .\CustomKernelSignersPolicy.xml -BinaryFilePath ("./" + $PolicyId + ".cip")

Signer la stratégie avec votre certificat de signature de stratégie

signtool.exe sign /fd sha256 `
    /p7 .\ `
    /p7co 1.3.6.1.4.1.311.79.1 `
    /p7ce Embedded`
    /a `
    /f policy_signer.pfx `
    ("./" + $PolicyId + ".cip")

Étape 7 : Déployer la stratégie

Vous pouvez déployer le fichier binaire de stratégie signé à l’aide de l’une des méthodes suivantes :

• Solution GPM telle que Microsoft Intune
• CiTool (disponible sur Windows 11)
• stratégie de groupe (déployer via un objet de stratégie de groupe)
• Déploiement basé sur un script (déploiement via script)

Déploiement basé sur un script sur la partition système EFI

Toutes les solutions ci-dessus, en plus du déploiement basé sur des scripts, déploient automatiquement le binaire de stratégie sur la partition système EFI (ESP). Si vous effectuez un déploiement via un script, vous devez copier manuellement le fichier binaire de stratégie signé dans la partition EFI :

# Mount the EFI System Partition
mountvol s: /s

# Copy the signed policy to the active policies directory
copy ("./" + $PolicyId + ".cip") s:\EFI\Microsoft\Boot\CiPolicies\Active\

Étape 8 : Réinitialiser Windows

Une réinitialisation de Windows est nécessaire pour activer la fonctionnalité. Une fois la stratégie présente sur la partition EFI, vous devez réinitialiser l’appareil à l’aide d’une méthode de réinitialisation telle que la réinitialisation par bouton. La stratégie ne sera pas approuvée par Windows si aucune réinitialisation n’est effectuée.

Étape 9 : Désactiver la stratégie de pilote Windows

À compter de la mise à jour non liée à la sécurité d’avril 2026, Windows 11 (24H2 et versions ultérieures) et Windows Server 2025 appliquent une stratégie de noyau restreignant l’approbation pour le programme de pilote entre signés. Si la stratégie est active, vous devez la désactiver, sinon la stratégie de pilote bloquera vos pilotes personnalisés signés par une infrastructure à clé publique.

# Mount the EFI System Partition
mountvol s: /s

# Remove the default Windows kernel policy if present
del s:\EFI\Microsoft\Boot\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip

Étape 10 : Valider le déploiement

Tester d’abord en mode Audit

Avant d’appliquer la stratégie, déployez avec le mode Audit activé pour journaliser les violations de stratégie sans bloquer les pilotes :

1. Vérifiez que Enabled:Audit Mode est défini dans la section stratégie <Rules> .
2. Déployez la stratégie et redémarrez l’appareil.
3. Passez en revue les journaux des événements d’intégrité du code dansJournaux >des applications et des servicesMicrosoft >Windows>CodeIntegrity.

Liste de contrôle de validation

• Les pilotes signés personnalisés se chargent correctement.
• Les pilotes non signés ou non autorisés sont bloqués (en mode Appliquer).
• Windows Update et les flux de maintenance du système d’exploitation continuent de fonctionner.
• Les journaux des événements d’intégrité du code affichent uniquement les événements de bloc attendus.
• La stratégie est validée sur toutes les configurations matérielles cibles avant le déploiement à l’échelle de la flotte.

Une fois la validation terminée, supprimez l’option Enabled:Audit Mode de règle de la stratégie, reconnectez-vous et déployez-la sur des appareils de production. Une installation propre de Windows n’est pas nécessaire pour les mises à jour de stratégie.

Contenu associé

• Guide de conception d’App Control for Business
• Règles de stratégie de contrôle d’application et règles de fichier
• Déployer des stratégies App Control avec un script
• Utiliser des stratégies signées pour protéger App Control contre la falsification
• Signature de mise en production WHCP
• Vue d’ensemble du démarrage sécurisé