Partager via

Directives pour la validation ROM d'option UEFI

Version 1.3

Ce document aide les OEM et les ODM à valider que leur microprogramme vérifie les signatures de leur ROM optionnelle dans le cadre de la chaîne de confiance de démarrage sécurisé.

Ce guide suppose que vous connaissez les principes fondamentaux de l’UEFI, de la compréhension de base du démarrage sécurisé (chapitres 1, 2, 13, 20 et 27 de la spécification UEFI) et du modèle de sécurité PKI.

Présentation de

Les roms d’option (ou OpROMs) sont des microprogrammes exécutés par le BIOS du PC pendant l’initialisation de la plateforme. Ils sont généralement stockés sur une carte de plug-in, bien qu’ils puissent résider sur la carte système.

Les appareils qui nécessitent généralement des roms d’option sont des cartes vidéo, des cartes réseau et des pilotes de stockage pour les modules RAID. Ces roms d’option fournissent généralement des pilotes de microprogramme au PC.

Ils comprennent divers types de pilotes de microprogramme, notamment PC-AT hérités, Open Firmware et option ROMs EFI. Par exemple, les pilotes de microprogramme incluent le BIOS vidéo sur les cartes vidéo, les pilotes de démarrage PXE pour les adaptateurs Ethernet et les pilotes de stockage sur les contrôleurs RAID. Ces appareils ont généralement des roms d’option qui fournissent des pilotes de microprogramme.

L’interface UEFI (Unified Extensible Firmware Interface) prend en charge les ROMs d’option en mode Legacy.

Conformément à la dernière spécification UEFI (actuellement à 2.3.1 Errata C – section 2.5.1.2), les roms d’option ISA (hérité) ne font pas partie de la spécification UEFI. Dans le cadre de cette discussion, seules les roms compatibles UEFI basées sur PCI seront prises en compte.

Les roms d’option peuvent être utilisées lorsqu’il n’est pas possible d’incorporer le microprogramme d’un appareil dans le microprogramme du PC. Lorsque la ROM d'option transporte le pilote, l'IHV peut tirer parti de ce pilote et regrouper le pilote et le périphérique en un seul endroit.

Ce document explique pourquoi vous devez valider les roms d’option et présente certaines techniques de le faire.

prise en charge du BIOS UEFI et du BIOS hérité

De nombreux fabricants créent des appareils qui incluent des roms d’option et un microprogramme pour de nombreux types de PC. Les combos courants sont les suivants :

  • ROM ancienne uniquement
  • OpROM natif UEFI
  • ROM héritée + UEFI EBC OpROM
  • ROM ancien + UEFI x64 OpROM
  • ROM hérité + UEFI x64 + UEFI IA32
  • ROM hérité + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

LE BIOS UEFI peut charger et exécuter des pilotes de microprogramme hérités lorsqu’un module de prise en charge de compatibilité (CSM) est activé. Notez que lorsque le démarrage sécurisé est activé, l’exécution du module de support de compatibilité et des roms hérités est interdite, car les pilotes de microprogramme hérités ne prennent pas en charge l’authentification. Si le format de ROM d’option dans la configuration BIOS est défini sur le ROM hérité, il utilise toujours le ROM hérité sur l’appareil.

Si le format de ROM d’option est défini sur compatible UEFI, il utilise le rom EFI le plus récent s’il est présent et le ROM hérité si ce n’est pas le cas.

Les pilotes UEFI sont nécessaires pour la plupart des nouvelles fonctionnalités de sécurité au niveau du microprogramme, ainsi que pour activer les séquences de démarrage UEFI. Par exemple, l’installation de Windows à partir d’un disque optique attaché à un contrôleur de stockage non compatible UEFI n’est pas possible lorsqu’un système démarre en mode UEFI lorsque le démarrage sécurisé est activé.

1. UEFI et ROMs Option

diagramme des considérations relatives au pilote UEFI

Figure 2 : Considérations relatives à la sécurité des pilotes UEFI, source : UEFI 2.3.1 Errata C

Le texte suivant provient d’UEFI 2.3.1 Errata C, mais a depuis été modifié avec des insights de partnersf :

Étant donné que le profil utilisateur UEFI détaille un certain nombre de privilèges liés à la sécurité, il est important que le Gestionnaire d’identité utilisateur et les fournisseurs d’informations d’identification utilisateur et l’environnement dans lequel ils s’exécutent soient approuvés.

Cela inclut les éléments suivants :

  • Protection de la zone de stockage où ces pilotes sont stockés.
  • Protection des moyens par lesquels ces pilotes sont sélectionnés.
  • Protection de l’environnement d’exécution de ces pilotes contre les pilotes non vérifiés.
  • Les structures de données utilisées par ces pilotes ne doivent pas être endommagées par des pilotes non autorisés alors qu’elles sont toujours utilisées.

Les composants tels que le User Identity Manager, les pilotes d'identifiants utilisateur et les pilotes intégrés peuvent se trouver dans un emplacement sécurisé, comme le lecteur flash protégé en écriture; qui est approuvé par la politique de la plateforme.

Certains autres pilotes peuvent résider sur des emplacements de stockage non protégés, tels que des roms d’option ou une partition de disque dur, et peuvent être facilement remplacés. Ces pilotes doivent être vérifiés.

Par exemple, la stratégie de plateforme par défaut doit être en mesure de vérifier les pilotes répertoriés dans les options de chargement driver#####, ou bien l’utilisateur doit être identifié avant de traiter ces pilotes. Sinon, l’exécution du pilote doit être différée. Si le profil utilisateur est modifié par le biais d’un appel ultérieur à Identifier () ou à l’authentification dynamique, les options Driver#### peuvent ne pas être traitées à nouveau.

La base de données de profil utilisateur est fermée à l'aide de différents événements de signal UEFI, selon qu'elle peut être protégée ou non.

Les pilotes UEFI & les ROM d’option UEFI ne seront exécutés que pour les périphériques situés sur le chemin de démarrage.

La spécification PCI autorise plusieurs images ROM d’option sur le même appareil. Ces ROMs d'option peuvent être en mode classique x86 & UEFI. Le microprogramme UEFI définit la stratégie de plateforme pour choisir le ROM d’option. Cela peut faire en sorte que la ROM de l’adaptateur facultatif s’exécute en tant que son propre périphérique de contrôle.

Le microprogramme vérifie les signatures pendant les phases BDS et DXE. La séquence d’événements est la suivante :

  1. Initialiser les bus PCI et dérivés
  2. Sonder les périphériques PCI pour les ROMs optionnelles
  3. Les roms d’option trouvées sont mappées en mémoire
  4. La phase DXE charge tous les pilotes UEFI dans les ROM

Les roms d’option UEFI peuvent être n’importe où en mémoire. La valeur par défaut consiste à laisser le ROM sur la carte gérer l’appareil. UEFI permet à la plateforme de contrôler la stratégie concernant l'option ROM qui contrôle quel appareil à l’aide de EFI_PLATFORM_DRIVER_OVERRIDE. UEFI prend en charge les ROM d'option pour enregistrer une interface de configuration.

Sur un PC avec démarrage sécurisé activé, les pilotes ROM d’option présentent une menace de sécurité s’ils ne sont pas signés ou non validés. La validation de signature pour les roms d’option est une exigence WHCK. Cela s'applique également lors de la maintenance des ROMs optionnelles pour s'assurer que la mise à jour est validée avant l'installation.

À partir des spécifications et stratégies du programme de compatibilité matérielle Windows version 1809:

  1. vérification de l’intégrité du code du microprogramme signé. Le microprogramme installé par l’OEM est en lecture seule ou protégé par un processus de mise à jour de microprogramme sécurisé, tel que défini ci-dessus, peut être considéré comme protégé. Les systèmes vérifient que tous les composants de microprogramme non protégés, les pilotes UEFI et les applications UEFI sont signés à l’aide de RSA-2048 minimum avec SHA-256 (MD5 et SHA-1 sont interdits) et vérifiez que les applications et pilotes UEFI qui ne sont pas signés conformément à ces exigences ne seront pas exécutés (il s’agit de la stratégie par défaut pour les algorithmes de signature acceptables). Si une signature d’images n’est pas trouvée dans la base de données autorisée ou qu’elle se trouve dans la base de données interdite, l’image ne doit pas être démarrée et les informations relatives à celle-ci doivent être placées dans la table d’informations d’exécution de l’image.

2. Instruction de problème

Certaines builds du BIOS UEFI compatible avec le démarrage sécurisé, y compris Tiano Core, n’ont pas authentifié par défaut les roms d’option UEFI, car les roms d’option UEFI signées n’étaient pas disponibles pendant le développement de démarrage sécurisé. Cela expose une surface d’attaque/vulnérabilité dans le démarrage sécurisé UEFI.

2.1. Vulnérabilité

Cette vulnérabilité était toujours présente dans EDK II et UDK2010 depuis août 2013. Les responsables de la source sont au courant du problème et un bogue a été signalé. Tout microprogramme dérivé de EDK II et UDK2010 doit vérifier comment la vérification de l'Option ROM est gérée. Le comportement de vérification du ROM d’option est contrôlé par une valeur PCD PcdOptionRomImageVerificationPolicy dans le package SecurityPkg EDK II.

Le code source de la vulnérabilité TianoCore est le fichier SecurityPkg\SecurityPkg.dec :

## Pcd for OptionRom.
  #  Image verification policy settings:
  #  ALWAYS_EXECUTE                         0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

La valeur par défaut (0x00) est ALWAYS_EXECUTE, qui n’effectue pas correctement la vérification des pilotes signés dans les ROM d’option pour les périphériques d'extension. Il ne s’agit pas d’une valeur idéale pour tout système implémentant la fonctionnalité de démarrage sécurisé UEFI.

Valeur recommandée (meilleure sécurité) : DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

Valeur recommandée (meilleure flexibilité) : QUERY_USER_ON_SECURITY_VIOLATION (0x05)

Dans EDK II & UDK2010, une pratique de codage appropriée utilise un mécanisme de remplacement pour modifier les valeurs PCD pour le firmware de la plateforme. Par conséquent, la valeur de PcdOptionRomImageVerificationPolicy ne doit pas être modifiée dans SecurityPkg\SecurityPkg.dec. La valeur de remplacement doit être définie dans le fichier DSC de la plateforme. Voici un exemple utilisant Nt32Pkg\Nt32Pkg.dsc :

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

Le remplacement PCD doit être placé sous la section [PcdsFixedAtBuild] du fichier DSC. Le mécanisme exact de substitution des paramètres peut différer selon les outils du fournisseur du BIOS.

Note

Cette vulnérabilité peut exister dans les premières implémentations du BIOS de démarrage sécurisé UEFI auprès des fournisseurs de BIOS indépendants. Contactez votre fournisseur BIOS pour déterminer si votre version peut être affectée.

3. Qui est affecté ?

Un PC UEFI qui implémente le démarrage sécurisé et a un pilote ROM d’option UEFI qui n’est pas signé. En outre, le microprogramme pour assurer la compatibilité des cartes existantes peut présenter une vulnérabilité de sécurité qui ne vérifie pas les ROMs d’option.

Ordinateurs portables, netbooks, ultrabooks, tablettes & : la plupart ne sont pas affectés. Les roms d’option sont généralement présents sur des bus de backplane tels que PCI/e, ISA et leurs dérivés (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt, etc.). Si aucun de ces ordinateurs portables n’est exposé, sa surface d’attaque est considérablement réduite. De plus, il est probable que les pilotes UEFI pour les composants portables intégrés soient intégrés au volume de microprogramme BIOS de base, et non situés sur une rom d’option distincte. Ainsi, la plupart des ordinateurs portables ne sont pas à risque. En outre, lorsque les roms d’option héritées sont désactivées, il semble que l’UEFI prend uniquement en charge les rom d’option PCI.

Toutefois, si vous disposez d’un ordinateur de bureau, d’une carte mère ou d’un serveur doté d’un BIOS UEFI et que vous implémentez le démarrage sécurisé, vous pouvez être affecté. Sur le contrôleur RAID dédié d’un serveur, ou sur un contrôleur de stockage complémentaire pour SATA, FC, etc., les cartes réseau PCIe Ethernet peuvent avoir des ROMs d’option. Les contrôleurs de complément prenant en charge un large éventail de fonctionnalités sur les serveurs sont courants. Cela s’applique donc en particulier à l’espace serveur.

Cela peut affecter les PC 32 bits et 64 bits, à la fois la classe 2 et la classe 3.

Si une plateforme de démarrage sécurisé prend en charge les roms d’option provenant d’appareils non attachés définitivement à la plateforme et qu’elle prend en charge la possibilité d’authentifier ces roMs d’option, elle doit prendre en charge les méthodes de validation de ROM d’option décrites dans les protocoles réseau : UDP et MTFTP et les variables EFI authentifiées décrites dans la spécification UEFI 2.3.1 Errata C Section 7.2.

4. Comment le tester ?

Si vous développez le microprogramme et qu’il est basé sur Tiano Core, vérifiez la vulnérabilité mentionnée dans la section 2.1. Si vous utilisez le microprogramme d’un autre IBV, vérifiez avec eux. Vous pouvez également effectuer le test vous-même, comme mentionné ci-dessous.

Vous aurez besoin des éléments suivants :

  • PC testé avec le microprogramme UEFI
  • Appareil PCI avec option ROM sur le PC testé (comme une carte vidéo)
  • Vérifiez que le démarrage sécurisé est activé

Étapes de test :

  1. Insérez un module COMPLÉMENTAIRE UEFI sur une carte PCI avec le ROM d’option UEFI sur le PC testé.

    Si vous utilisez une carte vidéo PCI pour le test, raccordez un moniteur externe.

  2. Activez le démarrage sécurisé avec les paramètres ci-dessous :

    • PK : Votre PK de test ou PK auto-signé
    • KEK : MS KEK, fabrikam test KEK signé par PK ou un autre KEK
    • DB : NULL. Cela doit être NULL.
    • DBX : NULL.
    • SecureBoot : La variable UEFI doit être définie sur true

  3. Redémarrer le PC

  4. Attendez-vous au résultat suivant :

    • Si le firmware UEFI est correctement implémenté, le pilote de ROM d’option UEFI ne se chargera pas, car la présence d'une ROM d’option entraîne le firmware à vérifier la "Db" pour un certificat. Étant donné que le « Db » est NULL, le pilote UEFI échoue à se charger. Par exemple, si vous utilisez la carte vidéo pour tester, vous verrez que rien ne s’affiche sur l’affichage.
    • Si le microprogramme n’est pas correctement implémenté, le pilote UEFI se charge à partir du ROM d’option, car le microprogramme ne vérifie pas les signatures dans « Db ». Par exemple, si vous utilisez la carte vidéo pour le test, vous verrez que le moniteur branché à la carte ROM d’option aura l’affichage.

    ![note] Peu importe que le pilote de l'option ROM UEFI soit signé ou non, l'option ROM ne se chargera pas lorsque DB est null et SB est active (PK et KEK sont inscrits).

Reportez-vous aux exemples de scripts disponibles dans WHCK pour générer le PK et le KEK. L’annexe B contient des exemples de scripts et plus de détails.

Vous pouvez également référencer l’annexe A pour une autre approche pour effectuer le test ci-dessus. Cette approche ne nécessite pas de définir le DB sur Null, mais requiert un pilote ROM d’option UEFI non signé de l’IHV.

5. Guide pratique pour résoudre ce problème

Si le test ci-dessus échoue, collaborez avec votre IBV pour acquérir les versions nécessaires et les configurer afin de valider les ROMs d'option. Assurez-vous que le microprogramme réussit le test. Pour les PC fournis, vous devez effectuer une mise à jour sécurisée du microprogramme. Reportez-vous à publication NIST 800-147 et/ou consultez guide de création et de gestion de clé de démarrage sécurisé Windows 8.1.

Vous pouvez tester le PC et tirer parti de Windows HCK en tant qu’outil de test (et non outil de certification) pour tester la mise à jour sécurisée du microprogramme.

5.1. Signature du pilote

Si vous constatez que vous avez peut-être des pilotes non signés sur des roMs d’option UEFI, lisez ci-dessous sur la façon de résoudre ce problème.

Signer chaque pilote ROM d’option individuellement. Cela interrompt le format du ROM d’option PCI. Vous devez uniquement signer le pilote UEFI avant de créer l’Option ROM combinée.

Avant d’insérer le pilote UEFI dans l’OpROM, signez l’image UEFI et testez-la avec Secure Boot ON & OFF sur l’interface UEFI Shell (chargez/déchargez le fichier du pilote). Ensuite, placez le pilote signé dans le ROM d'option combinée.

Vous pouvez orienter votre IHV vers le Centre de développement matériel de Microsoft pour obtenir leurs ROMs d'options UEFI signées grâce à un service disponible sur le Centre de développement matériel.

5.2. Validation de la mise à jour

Exécutez le test que vous avez mentionné ci-dessus pour vérifier que la vulnérabilité n’existe pas. Utilisez les tests HCK pour vous assurer qu’il n’existe aucune régression fonctionnelle.

6. Ressources

Annexe A : Autre approche du test à l’aide de pilotes ROM d’option non signés

Cette approche s’appuie sur l’obtention d’outils à partir d’IHV pour vous assurer que le pilote ROM d’option UEFI est signé.

Vous aurez besoin des éléments suivants :

  • PC testé avec le microprogramme UEFI
  • Périphérique PCI avec un pilote ROM d’option non signé attaché au PC sous test (comme une carte vidéo)
  • Vérifiez que le démarrage sécurisé est activé
  • Outils IHV d’option permettant de détecter la signature sur le pilote rom d’option s’il n’est pas évident que le pilote ROM d’option est signé ou non

Si le microprogramme est correctement implémenté et que la rom d’option n’est pas signée, la carte doit échouer à la vérification par microprogramme et ne pas charger le pilote sur la carte. Le PC doit signaler un code d’erreur tel que EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND. Si vous utilisez une carte vidéo, vous pouvez voir que le PC affiche simplement un écran noir, car le pilote ROM d’option n’a pas chargé.

Si le microprogramme est implémenté de manière incorrecte, ce test fonctionne.

Annexe B : Scripts pour activer le démarrage sécurisé avec la base de données NULL

Vous pouvez utiliser votre ensemble actuel de variables de démarrage sécurisé (PK et KEK) ou générer des tests pour ce test.

Vous trouverez ci-dessous les étapes utilisées pour générer le PK de test, le KEK, et mettre la base de données à NULL. Assurez-vous que le démarrage sécurisé n’est pas activé ; sinon, ces étapes nécessitent des fichiers bin UEFI signés.

Note

Nous définissons la variable de démarrage sécurisé : db, KEK et PK dans l’ordre inverse afin de ne pas avoir à signer les fichiers bin UEFI.

Avant cette étape, le PC doit être en mode d’installation.

  1. créer des certificats KEK et PK

    Cette étape nécessite l’outil makecert.exe disponible dans le kit de développement logiciel (SDK) Windows .

    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer

  2. Script pour générer le test PK

    Un exemple est fourni ci-dessous.

    this scripts demonstrates how to format the Platform key
NOTE The PK is actually set in the Enable_OEM_SecureBoot.ps1 script
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "TestPK"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating PC or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
$sigowner = "55555555-5555-5555-5555-555555555555"

$var = "PK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

Workaround relative path bug
TODO substitute OEM with your OEM name
$siglist =  $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"

$appendstring = "set_"
$attribute = "0x27"
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z  -AppendWrite:$append

OutputFilePath - Specifies the name of the file created that contains the contents of what is set.
If this parameter is specified, then the content are not actually set, just stored into this file.
Please note if -OutputFilePath is provided the PK is not set like in this case. The master script sets it at the end.

Time - you can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist  -OutputFilePath $example -AppendWrite:$append

  3. Générez une clé KEK de test ou utilisez votre propre KEK OEM

    Vous pouvez tirer parti de votre propre KEK OEM ou de scripts à partir du WHCK pour cela.

    Un exemple est fourni ci-dessous.

    script to add option OEM KEK
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "Fabrikam_Test_KEK_CA"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

TODO change this path to where you have the OEM_KEK.cer file
Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating system or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID

$sigowner = "00000000-0000-0000-0000-000000000000"

$var = "KEK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

$siglist = $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"
if ($append -eq $false)
{
$appendstring = "set_"
$attribute = "0x27"
} else
{
$appendstring = "append_"
$attribute = "0x67"
}
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append

-Time You can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  4. Définir Db sur Null et définir KEK et PK

    La première chose que ce script fait est de définir la Db sur Null.

    Note

    Si l’autorité de certification KEK de test Fabrikam est la seule présente (c’est-à-dire qu’il n’y a pas d’autorité de certification KEK Windows), le PC peut démarrer dans Windows RE.

    Avant l’exécution du script, exécutez «Set-ExecutionPolicy Bypass -Force »

    Import-Module secureboot
try
{
Write-Host "Deleting db..."
Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
}
catch
{
}
Write-Host "Setting Fabrikam KEK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin  -Name KEK

Write-Host "Setting self-signed Test PK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin  -Name PK

Write-Host "`n... operation complete.  `nSetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, and that SecureBoot changes to 1."

  5. Branchez la carte ROM d’option et testez

    Le test doit réussir ou échouer en fonction de la correction du microprogramme. Par exemple:

    Si la ROM d’option dans le microprogramme est correctement implémentée et que vous utilisez une carte vidéo pour les tests, il ne doit pas y avoir d’affichage sur le moniteur attaché.

    Toutefois, si vous utilisez un microprogramme incorrect, la carte vidéo doit avoir une sortie sur l’affichage.

guide de création et de gestion des clés de démarrage sécurisé Windows

Vue d’ensemble du démarrage sécurisé

validation des fonctionnalités de la plateforme de mise à jour du microprogramme UEFI Windows