Exigences des pilotes ELAM

L’installation du pilote doit utiliser des outils existants pour l’installation en ligne et hors connexion, en inscrivant un pilote via un traitement INF classique. Pour obtenir un exemple de code de pilote ELAM, consultez les rubriques suivantes : https://github.com/Microsoft/Windows-driver-samples/tree/main/security/elam

Installation du pilote AM

Pour garantir la compatibilité du pilote, un pilote ELAM s’affiche comme pilote de démarrage similaire à tous les autres pilotes de démarrage. L’inf définit le type de démarrage sur SERVICE_BOOT_START (0), ce qui indique que le pilote doit être chargé par le chargeur de démarrage et initialisé pendant l’initialisation du noyau. Un pilote ELAM annonce son groupe comme « Early-Launch ». Le comportement de lancement précoce pour les pilotes de ce groupe sera implémenté dans Windows, comme décrit dans la section suivante.

Voici un exemple de section d’installation de pilote d’un pilote ELAM INF.

[SampleAV.Service]
DisplayName    = %SampleAVServiceName%
Description    = %SampleAVServiceDescription%
ServiceType    = 1       ; SERVICE_KERNEL_DRIVER
StartType      = 0       ; SERVICE_BOOT_START
ErrorControl   = 3       ; SERVICE_ERROR_CRITICAL
LoadOrderGroup = “Early-Launch”

Étant donné qu’un pilote AM ne possède aucun appareil, il est nécessaire d’installer le pilote AM en tant que pilote hérité afin que le pilote soit uniquement ajouté en tant que service dans le Registre. (Si le pilote AM est installé comme pilote PNP normal, il sera ajouté à la section d'énumération du Registre et aura donc une référence PDO, ce qui entraînera un comportement indésirable lorsque le pilote est déchargé.)

Vous devez également inclure une section SignatureAttributes dans le fichier INF du pilote ELAM.

Installation du pilote de sauvegarde

Pour fournir un mécanisme de récupération si le pilote ELAM est endommagé par inadvertance, le programme d’installation ELAM installe également une copie du pilote dans un emplacement de sauvegarde. Cela permet à WinRE de récupérer la copie propre et de récupérer l’installation.

Le programme d’installation lit l’emplacement du fichier de sauvegarde à partir de la clé BackupPath stockée dans

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EarlyLaunch

Le programme d’installation place ensuite la copie de sauvegarde dans le dossier spécifié dans la clé de registre.

Initialisation du pilote AM

Le chargeur de démarrage Windows, Winload, charge tous les pilotes de démarrage et leurs DLL dépendantes en mémoire avant la transition vers le noyau Windows. Les pilotes de démarrage représentent les pilotes de périphérique qui doivent être initialisés avant l’initialisation de la pile de disques. Ces pilotes incluent, entre autres, la pile de disques et le gestionnaire de volumes, ainsi que les pilotes pour le système de fichiers et de bus du système d'exploitation.

Interface de rappel du pilote AM

Les pilotes ELAM utilisent des rappels pour fournir au Gestionnaire PnP une description de chaque pilote de démarrage et de chaque DLL dépendante, et ils peuvent classifier chaque image de démarrage comme un binaire correct connu, un binaire incorrect connu ou un binaire inconnu.

La stratégie par défaut du système d'exploitation consiste à ne pas initialiser les pilotes et DLL connus pour être mauvais. La stratégie peut être configurée et mesurée par Winload dans le cadre de l’attestation de démarrage.

PnP utilise la stratégie et la classification fournie par le pilote AM pour décider s’il faut initialiser chaque image de démarrage.

Rappels du Registre

Les pilotes de lancement anticipé peuvent utiliser des rappels de registre ou de pilote de démarrage pour surveiller et valider les données de configuration utilisées comme entrée pour chaque pilote de démarrage. Les données de configuration sont stockées dans la ruche du Registre système, qui est chargée par Winload et est disponible au moment de l’initialisation du pilote de démarrage.

Ces rappels sont valides pendant toute la durée de vie du pilote ELAM et seront désinscrits lorsque le pilote est déchargé. Si vous souhaitez obtenir plus d’informations, voir :

• CmRegisterCallbackEx
• CmRegisterCallback
• CmUnRegisterCallback

Rappels du pilote de démarrage

Utilisez IoRegisterBootDriverCallback et IoUnRegisterBootDriverCallback pour inscrire et annuler l’inscription d’un BOOT_DRIVER_CALLBACK_FUNCTION.

Ce rappel fournit des mises à jour d’état de Windows vers un pilote ELAM, notamment lorsque tous les pilotes de démarrage ont été initialisés et que la fonctionnalité de rappel n’est plus fonctionnelle.

Type de rappel

L’énumération BDCB_CALLBACK_TYPE décrit deux types de rappels :

• Rappels qui fournissent des mises à jour d’état d’un pilote ELAM (BdCbStatusUpdate)
• Rappels utilisés par le pilote AM pour classifier les pilotes de démarrage et les DLL dépendantes avant d’initialiser leurs images (BdCbInitializeImage)

Les deux types de rappel ont des structures de contexte uniques qui fournissent des informations supplémentaires spécifiques au rappel.

La structure de contexte du rappel de mise à jour d’état contient un type énuméré unique décrivant le point d’invocation Windows.

La structure de contexte du rappel d’image initialisé est plus complexe, contenant des informations de hachage et de certificat pour chaque image chargée. La structure contient également un champ qui est un paramètre de sortie où le pilote AM stocke le type de classification pour le pilote.

Une erreur retournée à partir d’un rappel de mise à jour d’état est traitée comme une erreur irrécupérable et entraîne une vérification des bogues système. Cela permet à un pilote ELAM d’indiquer quand un état est atteint en dehors de la stratégie AM. Par exemple, si un pilote d’exécution AM n’a pas été chargé et initialisé, le pilote de lancement anticipé peut échouer lors du rappel de préparation au déchargement pour empêcher Windows d’entrer dans un état sans qu’un pilote AM soit chargé.

Une image est traitée comme inconnue lorsqu'une erreur est retournée à partir du rappel d'initialisation de l'image. Les pilotes inconnus sont initialisés ou leur initialisation est ignorée en fonction de la politique de l'OS.

Signatures de programmes malveillants

Les données de signature de programmes malveillants sont déterminées par l’ISV AM, mais doivent inclure, au minimum, une liste approuvée de hachages de pilotes. Les données de signature sont stockées dans le Registre dans une nouvelle ruche « Early Launch Drivers » sous HKLM, qui est chargée par Winload. Chaque pilote AM possède une clé unique pour stocker son BLOB (Binary Large Object) de signature. Le chemin d’accès et la clé du Registre ont le format suivant :

HKLM\ELAM\<VendorName>\

Dans la clé, le fournisseur est libre de définir et d’utiliser l’une des valeurs. Il existe trois valeurs de blobs binaires définies qui sont mesurées par le Démarrage Mesuré, et le fournisseur peut utiliser chacune des valeurs.

• Mesuré
• Stratégie
• Configuration

La ruche ELAM est déchargée après son utilisation par l'antimalware de démarrage anticipé pour des raisons de performance. Si un service en mode utilisateur souhaite mettre à jour les données de signature, il doit monter le fichier hive à partir de l’emplacement du fichier \Windows\System32\config\ELAM. Par exemple, vous pouvez générer un UUID, le convertir en chaîne et l’utiliser comme clé unique dans laquelle monter la ruche. Le format de stockage et de récupération de ces objets BLOB de données est laissé au fournisseur de logiciels indépendant, mais la signature des données doit être apposée afin que le pilote AM puisse vérifier l’intégrité des données.

Vérification des signatures de programmes malveillants

La méthode permettant de vérifier l’intégrité des données de signature de programmes malveillants est laissée à chaque éditeur de logiciels indépendants AM. Les fonctions primitives de chiffrement CNG sont disponibles pour vous aider à vérifier les signatures numériques et les certificats sur les données de signature de programmes malveillants.

Échec de signature de programme malveillant

Si le pilote ELAM vérifie l’intégrité des données de signature et que cette vérification échoue, ou s’il n’y a pas de données de signature, l’initialisation du pilote ELAM réussit toujours. Dans ce cas, pour chaque pilote de démarrage, le pilote ELAM doit renvoyer « inconnu » lors de chaque rappel d'initialisation. En outre, le pilote ELAM doit transmettre ces informations au composant AM runtime une fois qu’il a démarré.

Déchargement du pilote AM

Lorsque le callback StatusType est BdCbStatusPrepareForUnload, il s’agit d’une indication du pilote AM que tous les pilotes de démarrage ont été initialisés et que le pilote AM doit se préparer à être déchargé. Avant le déchargement, le pilote AM de lancement précoce doit désinscrire ses rappels. La désinscription ne peut pas se produire pendant un rappel ; il doit plutôt se produire dans la fonction DriverUnload, qu’un pilote peut spécifier pendant DriverEntry.

Pour maintenir la continuité dans la protection contre les programmes malveillants et garantir une transmission correcte, le moteur AM d'exécution doit être démarré avant que le pilote AM de lancement anticipé soit déchargé. Cela signifie que le moteur AM runtime doit être un pilote de démarrage vérifié par le pilote AM de lancement précoce.

Performances

Le pilote doit répondre aux exigences de performances définies dans le tableau suivant :

Initialisation des pilotes

Une fois que les pilotes de démarrage sont évalués par le pilote ELAM, le noyau utilise la classification retournée par ELAM pour décider s’il faut initialiser le pilote. Cette décision est dictée par la stratégie et est stockée ici dans le Registre à l’adresse suivante :

HKLM\System\CurrentControlSet\Control\EarlyLaunch\DriverLoadPolicy

Cela peut être configuré par le biais d’une stratégie de groupe sur un client joint à un domaine. Une solution anti-programme malveillant peut souhaiter exposer cette fonctionnalité à l’utilisateur final dans des scénarios non managés. Les valeurs suivantes sont définies pour DriverLoadPolicy :

PNP_INITIALIZE_DRIVERS_DEFAULT 0x0  (initializes known Good drivers only)
PNP_INITIALIZE_UNKNOWN_DRIVERS 0x1  
PNP_INITIALIZE_BAD_CRITICAL_DRIVERS 0x3 (this is the default setting)
PNP_INITIALIZE_BAD_DRIVERS 0x7

Échecs de démarrage

Si un pilote de démarrage est ignoré en raison de la stratégie d’initialisation, le noyau continue à tenter d’initialiser le pilote de démarrage suivant dans la liste. Cela se poursuit jusqu'à ce que tous les pilotes soient initialisés, ou que le démarrage échoue, car un pilote de démarrage ignoré s'est avéré essentiel pour le démarrage. Si le blocage se produit après le démarrage de la pile de disques, il existe un vidage sur incident et contient des informations sur la raison ou le blocage, pour inclure des informations sur les pilotes manquants. Cela peut être utilisé dans WinRE pour déterminer la cause de l’échec et tenter de corriger.

ELAM et démarrage mesuré

Si le pilote ELAM détecte une violation de stratégie (un rootkit, par exemple), il doit immédiatement appeler Tbsi_Revoke_Attestation pour invalider les PCR qui indiquaient que le système était dans un bon état. La fonction renvoie une erreur s'il y a un problème lié au démarrage mesuré, par exemple si le système ne possède pas de TPM.

Tbsi_Revoke_Attestation peut être appelé à partir du mode noyau. Il étend le PCR[12] par une valeur non spécifiée et incrémente le compteur d’événements dans le TPM. Les deux actions sont nécessaires, de sorte que la confiance est rompue dans toutes les devis créés à partir de maintenant. Par conséquent, les journaux de démarrage mesurés ne reflètent pas l’état actuel du module de plateforme sécurisée pendant le reste du temps pendant lequel le module de plateforme sécurisée est alimenté, et les systèmes distants ne pourront pas faire confiance à l’état de sécurité du système.