Configuration requise du pilote ELAM

Article
06/15/2023

L’installation du pilote doit utiliser les outils existants pour l’installation en ligne et hors connexion, en inscrivant un pilote par le biais d’un traitement INF standard. 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é de l’installation 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 « Lancement anticipé ». Le comportement de lancement anticipé pour les pilotes de ce groupe sera implémenté dans Windows, comme décrit dans la section suivante.

Voici un exemple de la section d’installation de pilote d’un inf du pilote ELAM.

[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é en tant que pilote PNP normal, il sera ajouté à la section enum du Registre et aura donc une référence PDO, ce qui entraînera un comportement indésirable lors du déchargement du pilote.)

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

Installation du pilote de sauvegarde

Pour fournir un mécanisme de récupération dans le cas où 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 le propre copier 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é d’inscription.

Initialisation du pilote AM

Le chargeur de démarrage Windows, Winload, charge tous les pilotes de démarrage et leurs DLL dépendantes dans la mémoire avant la remise au 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 le pilote de système de fichiers et les pilotes de bus pour le périphérique de 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 il peut classer chaque image de démarrage comme un fichier binaire correct connu, un binaire incorrect connu ou un binaire inconnu.

La stratégie de système d’exploitation par défaut ne consiste pas à initialiser les pilotes et DLL incorrects connus. 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.

Notes

Toutes les modifications apportées à la ruche du Registre ELAM sont ignorées avant le démarrage du système. Par conséquent, un pilote ELAM doit utiliser la journalisation ETW (Event Tracing for Windows) standard au lieu d’écrire dans le Registre.

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

Rappels de pilotes de démarrage

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

Ce rappel fournit status mises à jour 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 status à 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 contextuelle du rappel de mise à jour status contient un type énuméré unique décrivant la légende Windows.

La structure contextuelle du rappel d’image initialiser est plus complexe, car elle contient 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 par un rappel de mise à jour status est traitée comme une erreur irrécupérable et entraîne un bogue système case activée. Cela permet à un pilote ELAM d’indiquer quand un état est atteint en dehors de la stratégie AM. Par exemple, si un pilote du runtime AM n’a pas été chargé et initialisé, le pilote de lancement anticipé peut échouer au rappel de préparation au déchargement pour empêcher Windows d’entrer dans un état sans pilote AM chargé.

Une image est traitée comme inconnue lorsqu’une erreur est retournée à partir du rappel d’image initialiser. Les pilotes inconnus sont initialisés ou leur initialisation est ignorée en fonction de la stratégie du système d’exploitation.

Signatures de programmes malveillants

Les données de signature des programmes malveillants sont déterminées par l’éditeur de logiciels indépendants 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 « Pilotes de lancement anticipé » sous HKLM qui est chargée par Winload. Chaque pilote AM a une clé unique dans laquelle stocker son objet 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 d’objets blob binaires définies qui sont mesurées par démarrage mesuré, et le fournisseur peut utiliser chacune :

Mesurée
Policy
Config

La ruche ELAM est déchargée après son utilisation par le logiciel anti-programme malveillant à lancement anticipé pour des performances. 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é à l’éditeur de logiciels indépendants, mais les données de signature doivent être signées pour 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 programme malveillant est laissée à chaque éditeur de logiciels indépendants AM. Les fonctions primitives de chiffrement CNG sont disponibles pour faciliter la vérification des signatures numériques et des certificats sur les données de signature des 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 case activée é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 retourner « inconnu » pour chaque rappel d’initialisation. En outre, le pilote ELAM doit transmettre ces informations au composant AM du runtime une fois qu’il a démarré.

Déchargement du pilote AM

Lorsque le statusType de rappel est BdCbStatusPrepareForUnload, cela indique au 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 à lancement précoce doit annuler l’inscription de ses rappels. La désinscription ne peut pas se produire pendant un rappel ; Au lieu de cela, cela doit se produire dans la fonction DriverUnload, qu’un pilote peut spécifier pendant DriverEntry.

Pour maintenir la continuité de la protection contre les programmes malveillants et garantir un transfert approprié, le moteur AM d’exécution doit être démarré avant le déchargement du pilote AM de lancement anticipé. Cela signifie que le moteur AM runtime doit être un pilote de démarrage vérifié par le pilote AM de lancement anticipé.

Performances

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

Scénario(s)	Heure de Début	Heure de fin	Limite supérieure
Évaluez le pilote critique de démarrage chargé avant de l’autoriser à s’initialiser. Cela inclut également les rappels de mise à jour status.	Le noyau rappelle le pilote anti-programme malveillant pour évaluer le pilote critique de démarrage chargé.	Le pilote anti-programme malveillant retourne le résultat de l’évaluation.	0,5 ms
Évaluer tous les pilotes critiques de démarrage chargés	Le noyau rappelle le pilote anti-programme malveillant pour évaluer le premier pilote critique de démarrage chargé.	Le pilote anti-programme malveillant retourne le résultat d’évaluation du dernier pilote critique de démarrage.	50 ms
Empreinte (pilote + données de configuration en mémoire)	N/A	N/A	128 Ko

Initialisation des pilotes

Une fois les pilotes de démarrage é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é via stratégie de groupe sur un client joint à un domaine. Une solution anti-programme malveillant peut vouloir 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 d’essayer d’initialiser le pilote de démarrage suivant dans la liste. Cela se poursuit jusqu’à ce que les pilotes soient tous initialisés ou que le démarrage ait échoué, car un pilote de démarrage qui a été ignoré était essentiel pour le démarrage. Si l’incident se produit après le démarrage de la pile de disques, il y a un vidage sur incident, qui contient des informations sur la raison ou l’incident, 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 appeler immédiatement Tbsi_Revoke_Attestation pour invalider les fichiers pcr indiquant que le système était en bon état. La fonction retourne une erreur en cas de problème avec le démarrage mesuré, par exemple aucun module TPM sur le système.

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

Partager via