Freigeben über

UEFI-Validierungsoptions-ROM-Leitfaden

Version 1.3

Dieses Dokument hilft OEMs und ODMs zu überprüfen, ob ihre Firmware die Signaturen seiner Options-ROM als Teil der Vertrauenskette für sicheres Starten überprüft.

In diesem Leitfaden wird davon ausgegangen, dass Sie die Grundlagen der UEFI kennen, grundlegende Kenntnisse des sicheren Starts (Kapitel 1, 2, 13, 20 und 27 der UEFI-Spezifikation) und des PKI-Sicherheitsmodells.

Einführung

Options-ROMs (oder OpROMs) sind Firmware, die während der Plattforminitialisierung vom PC-BIOS ausgeführt wird. Sie werden in der Regel auf einer Plug-In-Karte gespeichert, obwohl sie sich auf dem Systemboard befinden können.

Geräte, für die in der Regel Options-ROMs erforderlich sind, sind Grafikkarten, Netzwerkadapter und Speichertreiber für RAID-Module. Diese Options-ROMs stellen normalerweise auch Firmwaretreiber für den PC bereit.

Dazu gehören eine Vielzahl von Firmwaretreibern, darunter ältere PC-AT-, Open Firmware- und EFI-Options-ROMs. Beispiele für Firmwaretreiber sind Video-BIOS auf Grafikkarten, PXE-Starttreiber für Ethernet-Adapter und Speichertreiber auf RAID-Controllern. Diese Geräte verfügen in der Regel über Options-ROMs, die Firmwaretreiber bereitstellen.

Die Unified Extensible Firmware Interface (UEFI) unterstützt Option-ROMs im Legacy-Modus.

Gemäß der neuesten UEFI-Spezifikation (derzeit bei 2.3.1 Errata C – Abschnitt 2.5.1.2) sind ISA(Legacy)-Options-ROMs nicht Teil der UEFI-Spezifikation. Für diese Diskussion werden nur PCI-basierte UEFI-kompatible Options-ROMs berücksichtigt.

Options-ROMs können verwendet werden, wenn es nicht möglich ist, die Firmware eines Geräts in die PC-Firmware einzubetten. Wenn die Option ROM den Treiber trägt, kann der IHV diesen Treiber nutzen und den Treiber und das Gerät an einer zentralen Stelle halten.

In diesem Dokument wird erläutert, warum Sie Options-ROMs überprüfen müssen, und zeigt einige Techniken, wie Sie dies tun müssen.

Unterstützung von UEFI-BIOS und Legacy-BIOS

Viele Hersteller erstellen Geräte, die Options-ROMs und Firmware für viele Arten von PCs enthalten. Zu den gängigen Kombinationen gehören:

  • Nur Legacy-ROM
  • UEFI Native OpROM
  • Legacy ROM + UEFI EBC OpROM
  • Legacy ROM + UEFI x64 OpROM
  • Legacy ROM + UEFI x64 + UEFI IA32
  • Legacy ROM + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

Das UEFI-BIOS kann ältere Firmwaretreiber laden und ausführen, wenn ein Kompatibilitätssupportmodul (Compatibility Support Module, CSM) aktiviert ist. Beachten Sie, dass beim Aktivieren des sicheren Starts die Ausführung des Kompatibilitätsunterstützungsmoduls und legacy-ROMs verboten ist, da ältere Firmwaretreiber die Authentifizierung nicht unterstützen. Wenn das Option ROM-Format in der BIOS-Konfiguration auf Legacy-ROM festgelegt ist, wird immer die legacy-ROM auf dem Gerät verwendet.

Wenn das Option ROM-Format auf UEFI-kompatiblenfestgelegt ist, wird die neuere EFI-ROM verwendet, wenn eine vorhanden ist, und die ältere, wenn keine vorhanden ist.

UEFI-Treiber sind für viele der neuen Sicherheitsfeatures auf Firmwareebene sowie für die Aktivierung von UEFI-Startsequenzen erforderlich. Das Installieren von Windows von einem optischen Datenträger, der an einen nicht UEFI-kompatiblen Speichercontroller angeschlossen ist, ist beispielsweise nicht möglich, wenn ein System im UEFI-Modus gestartet wird, wenn der sichere Start aktiviert ist.

1. UEFI- und Options-ROMs

Diagramm der Überlegungen zu Uefi-Treibern

Abbildung 2: Überlegungen zur Sicherheit des UEFI-Treibers, Quelle: UEFI 2.3.1 Errata C

Der folgende Text stammt aus UEFI 2.3.1 Errata C, wurde aber seitdem mit Erkenntnissen von partnersf geändert:

Da das UEFI-Benutzerprofil eine Reihe sicherheitsbezogener Berechtigungen enthält, ist es wichtig, dass der Benutzeridentitäts-Manager und die Benutzeranmeldeinformationsanbieter und die Umgebung, in der sie ausgeführt werden, vertrauenswürdig sind.

Dazu gehören:

  • Schützen des Speicherbereichs, in dem diese Treiber gespeichert werden.
  • Schützen der Mittel, mit denen diese Treiber ausgewählt werden.
  • Schützen der Ausführungsumgebung dieser Treiber vor nicht überprüften Treibern.
  • Die von diesen Treibern verwendeten Datenstrukturen sollten nicht von nicht autorisierten Treibern beschädigt werden, während sie noch verwendet werden.

Komponenten wie Benutzeridentitätsmanager, Benutzerdatentreiber und integrierte Treiber befinden sich möglicherweise an einem sicheren Speicherort wie einem schreibgeschützten Flashlaufwerk, das von der Plattformrichtlinie als vertrauenswürdig eingestuft wird.

Einige andere Treiber befinden sich möglicherweise an einem nicht geschützten Speicherort wie Options-ROMs oder einer Festplattenpartition und können leicht ersetzt werden. Diese Treiber müssen überprüft werden.

Entweder muss die Standardplattformrichtlinie erfolgreich in der Lage sein, die in den Ladeoptionen "Driver#####" aufgeführten Treiber zu überprüfen, sonst muss der Benutzer vor der Verarbeitung dieser Treiber identifiziert werden. Andernfalls sollte die Treiberausführung zurückgestellt werden. Wenn das Benutzerprofil über einen nachfolgenden Aufruf zur Identifizierung () oder durch dynamische Authentifizierung geändert wird, werden die Treiber#####-Optionen möglicherweise nicht erneut verarbeitet.

Die Benutzerprofildatenbank wird mit unterschiedlichen UEFI-Signalereignissen geschlossen, je nachdem, ob sie geschützt werden kann.

UEFI-Treiber & UEFI-Options-ROMs werden nur für Geräte im Startpfad ausgeführt.

Die PCI-Spezifikation erlaubt mehrere Option-ROM-Images auf demselben Gerät. Diese Option-ROM könnte Legacy x86 & UEFI enthalten. UEFI-Firmware legt Plattformrichtlinie für die Auswahl der Option ROM fest. Dadurch kann die ROM des optionalen Adapters als eigenes Steuergerät ausgeführt werden.

Die Firmware überprüft Signaturen während der BDS- und DXE-Phasen. Die Abfolge von Ereignissen lautet wie folgt:

  1. PCI- und abgeleitete Busse initialisieren
  2. Prüfe PCI-Geräte auf Option-ROMs
  3. Gefundene Options-ROMs werden im Arbeitsspeicher zugeordnet
  4. DXE-Phase lädt alle UEFI-Treiber in ROMs

UEFI-Options-ROMs können sich überall im Arbeitsspeicher befinden. Standardmäßig sorgt das ROM auf der Karte dafür, dass das Gerät verwaltet wird. UEFI ermöglicht es der Plattform, die Richtlinie zu steuern, welche Option ROM welches Gerät kontrolliert, indem EFI_PLATFORM_DRIVER_OVERRIDE verwendet wird. UEFI unterstützt Options-ROMs zum Registrieren einer Konfigurationsschnittstelle.

Auf einem PC mit aktiviertem sicheren Start stellen Option ROM-Treiber eine Sicherheitsgefahr dar, wenn sie nicht signiert oder nicht überprüft werden. Die Signaturüberprüfung für Options-ROMs ist eine WHCK-Anforderung. Dies gilt auch für Wartungsoptions-ROMs, um sicherzustellen, dass das Update vor der Installation überprüft wird.

Aus den Spezifikationen und Richtlinien des Windows-Hardwarekompatibilitätsprogramms, Version 1809:

  1. Signierte Firmware-Code-Integritätsprüfung. Firmware, die vom OEM installiert wird und entweder schreibgeschützt oder durch einen sicheren Firmwareupdateprozess geschützt ist, wie oben definiert, kann als geschützt betrachtet werden. Systeme müssen überprüfen, ob alle nicht geschützten Firmwarekomponenten, UEFI-Treiber und UEFI-Anwendungen mit mindestens RSA-2048 mit SHA-256 (MD5 und SHA-1 verboten) signiert sind, und überprüfen, ob UEFI-Anwendungen und Treiber, die gemäß diesen Anforderungen nicht signiert sind, nicht ausgeführt werden (dies ist die Standardrichtlinie für akzeptable Signaturalgorithmen). Wenn eine Bildsignatur in der autorisierten Datenbank nicht gefunden wird oder in der verbotenen Datenbank gefunden wird, darf das Bild nicht gestartet werden, und stattdessen müssen Informationen darüber in der Informationstabelle für die Bildausführung platziert werden.

2. Problemstellung

Einige Builds des sicheren Start-fähigen UEFI-BIOS, einschließlich Tiano Core, authentifizierten standardmäßig keine UEFI-Options-ROMs, da signierte UEFI-Options-ROMs während der Entwicklung des sicheren Starts nicht verfügbar waren. Dadurch wird eine Angriffsfläche bzw. Sicherheitslücke beim UEFI Secure Boot aufgedeckt.

2.1. Schwachstelle

Diese Sicherheitsanfälligkeit war noch in EDK II und UDK2010 seit August 2013 vorhanden. Die Quellbetreuer sind sich des Problems bewusst und ein Fehler wurde gemeldet. Alle von EDK II und UDK2010 abgeleitete Firmware sollte überprüfen, wie die Option ROM-Verifikation durchgeführt wird. Das Überprüfungsverhalten von Option ROM wird durch einen PCD-Wert PcdOptionRomImageVerificationPolicy im EDK II SecurityPkg-Paket gesteuert.

Der Quellcode für die Sicherheitsanfälligkeit in TianoCore ist die Datei "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

Der Standardwert (0x00) ist ALWAYS_EXECUTE, wodurch die Überprüfung von signierten Treibern in Option ROMs für Add-In-Peripheriegeräte nicht ordnungsgemäß ausgeführt wird. Dies ist kein idealer Wert für jedes System, das UEFI Secure Boot-Funktionen implementiert.

Empfohlener Wert (beste Sicherheit): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

Empfohlener Wert (beste Flexibilität): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

In EDK II & UDK2010 verwendet die ordnungsgemäße Codierungspraxis einen Außerkraftsetzungsmechanismus, um PCD-Werte für plattformbasierte Firmware zu ändern. Daher sollte der Wert für PcdOptionRomImageVerificationPolicy in SecurityPkg\SecurityPkg.decnicht geändert werden. Der Override-Wert sollte in der DSC-Datei der Plattform festgelegt werden. Nachfolgend finden Sie ein Beispiel unter Verwendung von Nt32Pkg\Nt32Pkg.dsc:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

Die PCD-Außerkraftsetzung sollte unter dem Abschnitt [PcdsFixedAtBuild] der DSC-Datei stehen. Der genaue Mechanismus für die Außerkraftsetzung von Parametern kann je nach BIOS-Anbietertools unterschiedlich sein.

Anmerkung

Diese Sicherheitsanfälligkeit kann in frühen Implementierungen des BIOS für den sicheren Start von UEFI von unabhängigen BIOS-Anbietern bestehen. Wenden Sie sich an Ihren BIOS-Anbieter, um zu ermitteln, ob Ihre Version beeinträchtigt werden kann.

3. Wer ist betroffen?

Ein UEFI-PC, der den sicheren Start implementiert und über einen UEFI-Options-ROM-Treiber verfügt, der nicht signiert ist. Die Firmware zur Herstellung der Kompatibilität, um die vorhandenen Karten funktionsfähig zu machen, weist möglicherweise eine Sicherheitslücke auf, da sie die Option ROMs nicht überprüft.

Laptops, Netbooks, Ultrabooks, & Tablets: Die meisten sind nicht betroffen. Options-ROMs sind in der Regel auf Backplanebussen wie PCI/e, ISA und deren Ableitungen (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt usw.) vorhanden. Wenn ein Laptop keines dieser offengelegt hat, wird seine Angriffsfläche erheblich reduziert. Darüber hinaus ist es wahrscheinlich, dass UEFI-Treiber für die im Laptop verbauten Komponenten in das zentrale BIOS-Firmware-Volumen integriert sind und nicht auf einer separaten Option-ROM liegen. Daher sind die meisten Laptops nicht gefährdet. Wenn RoMs mit Legacyoption deaktiviert sind, sieht es auch so aus, als ob UEFI nur PCI-basierte Options-ROMs unterstützt.

Wenn Sie jedoch über einen Desktop, eine Hauptplatine oder einen Server mit einem UEFI-BIOS verfügen und einen sicheren Start implementieren, sind Sie möglicherweise betroffen. Auf dem dedizierten RAID-Controller eines Servers oder einem zusätzlichen Speichercontroller für SATA, FC usw. sowie bei Ethernet PCIe-Netzwerkkarten können optionale ROMs vorhanden sein. Add-In-Controller, die eine breite Palette von Funktionen auf Servern unterstützen, sind üblich, sodass dies insbesondere für den Serverspeicher gilt.

Dies kann sich möglicherweise auf 32-Bit- und 64-Bit-PCs auswirken, sowohl die Klasse 2 als auch die Klasse 3.

Wenn eine Plattform für den sicheren Start Options-ROMs von Geräten unterstützt, die nicht dauerhaft an die Plattform angefügt sind und die Möglichkeit zur Authentifizierung dieser Options-ROMs unterstützt, muss sie die in Netzwerkprotokollen beschriebenen Rom-Validierungsmethoden ( UDP und MTFTP) und die authentifizierten EFI-Variablen, die in der UEFI-Spezifikation 2.3.1 Errata C Section 7.2 beschrieben sind, unterstützen.

4. Wie teste ich darauf?

Wenn Sie die Firmware entwickeln und sie auf Tiano Core basiert ist, überprüfen Sie bitte, ob die in Abschnitt 2.1 erwähnte Sicherheitsanfälligkeit vorliegt. Wenn Sie die Firmware eines anderen IBV verwenden, wenden Sie sich bitte an sie. Oder Sie können den Test selbst durchführen, wie unten erwähnt.

Sie benötigen Folgendes:

  • PC unter Test mit UEFI-Firmware
  • PCI-Gerät mit Option ROM auf dem PC unter Testbedingungen (z. B. einer Grafikkarte)
  • Stellen Sie sicher, dass "Sicherer Start" aktiviert ist.

Schritte zum Testen:

  1. Setzen Sie eine UEFI-Zusatzkarte mit UEFI-Option-ROM in den zu testenden PC ein.

    Wenn Sie eine PCI-Grafikkarte zum Testen verwenden, verbinden Sie einen externen Monitor.

  2. Aktivieren Sie den sicheren Start mit den folgenden Einstellungen:

    • PK: Ihre PK oder selbstsignierte Test-PK
    • KEK: MS KEK, PK-signierter Fabrikam-Test-KEK oder ein anderer KEK
    • DB: NULL. (Dies muss NULL sein.)
    • DBX: NULL.
    • SecureBoot: Die UEFI-Variable sollte auf "true" festgelegt werden.

  3. Neustarten des PCs

  4. Erwarten Sie folgendes Ergebnis:

    • Wenn die UEFI-Firmware ordnungsgemäß implementiert ist, würde der UEFI-Option-ROM-Treiber nicht geladen, da das Vorhandensein eines Option-ROM die Firmware veranlasst, die 'Db' nach einem Zertifikat zu überprüfen. Da "Db" NULL ist, wird der UEFI-Treiber nicht geladen. Wenn Sie beispielsweise die Grafikkarte zum Testen verwenden, wird auf dem Bildschirm nichts angezeigt.
    • Wenn die Firmware nicht ordnungsgemäß implementiert ist, wird der UEFI-Treiber von der Option ROM geladen, da die Firmware nicht auf Signaturen in "Db" überprüft. Wenn Sie z. B. die Grafikkarte zum Testen verwenden, sehen Sie, dass der Monitor, der an die Option ROM-Karte angeschlossen ist, ein Bild zeigt.

    ! [Hinweis] Es spielt keine Rolle, ob der UEFI-Options-ROM-Treiber signiert ist oder nicht, die Option ROM wird nicht geladen, wenn DB null ist und SB aktiviert ist (PK und KEK sind registriert).

Bitte beziehen Sie sich auf Beispielskripts, die im WHCK zum Generieren der PK und KEK zur Verfügung stehen. Anhang B enthält Beispielskripts und weitere Details.

Sie können auch auf Anhang A verweisen, um einen anderen Ansatz zur Durchführung des obigen Tests zu erhalten. Für diesen Ansatz ist es nicht erforderlich, die DB auf Null festzulegen, sondern einen nicht signierten UEFI-Options-ROM-Treiber aus dem IHV zu benötigen.

5. So beheben Sie es

Wenn der obige Test fehlschlägt, arbeiten Sie mit Ihrem IBV zusammen, um die erforderlichen Versionen zu erwerben und zu konfigurieren, um Options-ROMs zu überprüfen. Stellen Sie sicher, dass die Firmware den Test bestanden hat. Für PCs, die ausgeliefert wurden, müssen Sie ein sicheres Firmwareupdate durchführen. Weitere Informationen finden Sie unter NIST-Publikation 800-147 und/oder lesen Sie Windows 8.1 Anleitung zur Erstellung und Verwaltung von Sicheren Startschlüsseln.

Sie können den PC testen und Windows HCK als Testtool (kein Zertifizierungstool) zum Testen des sicheren Firmwareupdates nutzen.

5.1. Treiber signieren

Falls Sie feststellen, dass Sie möglicherweise nicht signierte Treiber auf UEFI-Options-ROMs haben, lesen Sie unten, wie Sie dies beheben können.

Signieren Sie jeden Options-ROM-Treiber einzeln. Dadurch wird das Format der PCI-Option-ROM zerstört. Sie müssen den UEFI-Treiber nur signieren, bevor Sie die kombinierte Option ROM erstellen.

Bevor Sie den UEFI-Treiber in das OpROM einfügen, signieren Sie das UEFI-Image, und testen Sie es mit secure Boot ON & OFF an der UEFI-Shell (Laden/Entladen der Treiberdatei). Platzieren Sie dann den signierten Treiber in das kombinierte Option-ROM.

Sie können Ihren IHV an das Microsoft Hardware Dev Center weiterleiten, um ihre UEFI-Option-ROMs über einen im Hardware Dev Center verfügbaren Dienst signieren zu lassen.

5.2. Überprüfung des Updates

Führen Sie den oben erwähnten Test aus, um zu überprüfen, ob die Sicherheitsanfälligkeit nicht vorhanden ist. Verwenden Sie die HCK-Tests, um sicherzustellen, dass keine funktionalen Regressionen vorhanden sind.

6. Betriebsmittel

Anhang A: Alternativer Ansatz zum Testen mit nicht signierten Option ROM-Treibern

Dieser Ansatz basiert darauf, Tools von IHV zu erhalten, um sicherzustellen, dass der UEFI-Options-ROM-Treiber signiert ist.

Sie benötigen Folgendes:

  • PC unter Test mit UEFI-Firmware
  • PCI-Gerät mit einem unsignierten Option-ROM-Treiber, der mit dem zu testenden PC verbunden ist (z. B. eine Grafikkarte)
  • Stellen Sie sicher, dass "Sicherer Start" aktiviert ist.
  • Einsatz von IHV-Tools zur Erkennung der Signatur auf dem Option-ROM-Treiber, wenn nicht klar ersichtlich ist, ob der Option-ROM-Treiber signiert ist oder nicht.

Wenn die Firmware ordnungsgemäß implementiert ist und die Option-ROM nicht signiert ist, sollte die Firmware die Überprüfung nicht bestehen, und der Treiber sollte nicht auf der Karte geladen werden. Der PC sollte einen Fehlercode wie EFI_IMAGE_EXECUTION_AUTH_SIG_FOUNDmelden. Falls Sie eine Grafikkarte verwenden, sehen Sie möglicherweise, dass der PC nur einen schwarzen Bildschirm anzeigt, da der Option ROM-Treiber nicht geladen wurde.

Wenn die Firmware falsch implementiert ist, funktioniert dieser Test.

Anhang B: Skripts zum Aktivieren des sicheren Starts mit NULL db

Sie können entweder Ihren aktuellen Satz sicherer Startvariablen (PK und KEK) verwenden oder Testvariablen zum Testen generieren.

Die folgenden Schritte werden verwendet, um die Testdaten PK und KEK zu generieren und Db auf NULL zu setzen. Stellen Sie sicher, dass der sichere Start nicht aktiviert ist; andernfalls erfordern diese Schritte signierte UEFI-Bindateien.

Anmerkung

Wir legen die Variable "Sicherer Start" – Db, KEK und PK in umgekehrter Reihenfolge fest, sodass wir die UEFI-Bin-Dateien nicht signieren müssen.

Vor diesem Schritt sollte sich der PC im Setupmodus befinden.

  1. Erstellen von KEK- und PK-Zertifikaten

    Für diesen Schritt ist das makecert.exe Tool im Windows SDKverfügbar.

    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. Skript zum Erzeugen eines Test-PK

    Nachfolgend finden Sie ein Beispiel.

    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. Test-KEK generieren oder eigenen OEM-KEK verwenden

    Sie können dazu Ihren eigenen OEM KEK oder Skripten aus dem WHCK nutzen.

    Nachfolgend finden Sie ein Beispiel.

    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. Db auf Null festlegen und KEK und PK auf setzen

    Als Erstes legt dieses Skript die Db auf Null fest.

    Anmerkung

    Beachten Sie bitte, dass, wenn die Fabrikam Test KEK CA die einzige KEK-Zertifizierungsstelle ist (d. h. es gibt keine Windows KEK CA), der PC möglicherweise mit Windows RE startet.

    Führen Sie vor der Skriptausführung "Set-ExecutionPolicy Bypass -Force" aus.

    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. Stecken Sie die optionale ROM-Karte ein und testen Sie

    Der Test sollte entweder bestanden oder fehlgeschlagen sein, basierend auf der Korrektheit der Firmware. Zum Beispiel:

    Wenn die Option ROM in der Firmware korrekt implementiert ist und Sie eine Grafikkarte zum Testen verwenden, sollte keine Anzeige auf dem angeschlossenen Monitor vorhanden sein.

    Wenn Sie jedoch falsche Firmware verwenden, sollte die Grafikkarte eine Ausgabe auf dem Display anzeigen.

Windows Secure Boot-Schlüssel-Erstellung und Verwaltungsrichtlinien

Übersicht über den sicheren Start

Überprüfen der Windows UEFI Firmware Update Platform-Funktionalität