UEFI-Validierungsoption ROM-Anleitung

  • Artikel

Version 1.3

Dieses Dokument hilft OEMs und ODMs zu validieren, dass ihre Firmware die Signaturen ihres Options-ROMs als Teil der Secure Boot-Vertrauenskette überprüft.

In diesem Handbuch wird davon ausgegangen, dass Sie die Grundlagen von UEFI, das grundlegende Verstehen von Secure Boot (Kapitel 1, 2, 13, 20 und 27 der UEFI-Spezifikation) und das PKI-Sicherheitsmodell kennen.

Einführung

Option ROMs (oder OpROMs) sind Firmware, die vom PC-BIOS während der Plattforminitialisierung ausgeführt wird. Sie werden normalerweise auf einer Steckkarte gespeichert, können sich aber auch auf der Systemplatine befinden.

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

Sie umfassen eine Vielzahl von Arten von Firmware-Treibern, einschließlich Legacy-PC-AT-, Open-Firmware- und EFI-Options-ROMs. Beispiele für Firmware-Treiber sind Video-BIOS auf Grafikkarten, PXE-Starttreiber für Ethernet-Adapter und Speichertreiber auf RAID-Controllern. Diese Geräte verfügen normalerweise über Options-ROMs, die Firmware-Treiber bereitstellen.

Das Unified Extensible Firmware Interface (UEFI) unterstützt Legacy-Modus-Options-ROMs.

Gemäß der neuesten UEFI-Spezifikation (derzeit bei 2.3.1 Errata C – Abschnitt 2.5.1.2) sind ISA-Options-ROMs (Legacy) kein Teil der UEFI-Spezifikation. Für die Zwecke dieser Diskussion werden nur PCI-basierte UEFI-kompatible Options-ROMs betrachtet.

Option-ROMs können verwendet werden, wenn es nicht möglich ist, die Firmware eines Geräts in die PC-Firmware einzubetten. Wenn das Options-ROM den Treiber enthält, kann das IHV diesen Treiber nutzen und den Treiber und das Gerät an einem Ort aufbewahren.

Dieses Dokument erklärt, warum Sie Options-ROMs validieren müssen, und zeigt einige Techniken, um dies zu tun.

Unterstützt sowohl UEFI-BIOS als auch Legacy-BIOS

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

  • Nur Legacy-ROM
  • UEFI Natives 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 Legacy-Firmware-Treiber laden und ausführen, wenn ein Compatibility Support Module (CSM) aktiviert ist. Beachten Sie, dass bei aktiviertem Secure Boot die Ausführung des Compatibility Support Module und Legacy-ROMs verboten ist, da Legacy-Firmware-Treiber keine Authentifizierung unterstützen. Wenn das Option ROM-Format in der BIOS-Konfiguration auf Legacy-ROM eingestellt ist, wird immer das Legacy-ROM verwendet auf dem Gerät.

Wenn das Option-ROM-Format auf UEFI-kompatibel eingestellt ist, wird das neuere EFI-ROM verwendet, falls eines vorhanden ist, und das Legacy-ROM, falls eines nicht vorhanden ist.

UEFI-Treiber sind für viele der neuen Sicherheitsfunktionen auf Firmware-Ebene sowie zum Aktivieren von UEFI-Startsequenzen erforderlich. Beispielsweise ist die Installation von Windows von einem optischen Datenträger, der an einen nicht UEFI-kompatiblen Speichercontroller angeschlossen ist, nicht möglich, wenn ein System im UEFI-Modus gestartet wird, wenn Secure Boot aktiviert ist.

1. UEFI and Option ROMs

diagram of uefi driver considerations

Abbildung 2: Überlegungen zur Sicherheit von UEFI-Treibern, Quelle: UEFI 2.3.1 Errata C

Der folgende Text stammt ursprünglich aus UEFI 2.3.1 Errata C, wurde aber seitdem mit Erkenntnissen von Partnern modifiziert:

Da das UEFI-Benutzerprofil eine Reihe von sicherheitsbezogenen Berechtigungen enthält, ist es wichtig, dass dem User Identity Manager und den Anbietern von Benutzeranmeldeinformationen sowie der Umgebung, in der sie ausgeführt werden, vertraut wird.

Dies schließt Folgendes ein:

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

Komponenten wie User Identity Manager, die Treiber für Benutzeranmeldeinformationen und integrierte Treiber befinden sich möglicherweise an einem sicheren Ort wie einem schreibgeschützten Flash-Laufwerk, dem die Plattformrichtlinie vertraut.

Einige andere Treiber befinden sich möglicherweise an ungeschützten Speicherorten wie optionalen ROMs oder einer Festplattenpartition und können leicht ersetzt werden. Diese Treiber müssen verifiziert werden.

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

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

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

Die PCI-Spezifikation erlaubt mehrere Options-ROM-Images auf demselben Gerät. Diese optionalen ROMs könnten Legacy x86 und UEFI sein. Die UEFI-Firmware legt die Plattformrichtlinie für die Auswahl des Options-ROM fest. Dadurch kann das ROM des optionalen Adapters als sein eigenes Steuergerät ausgeführt werden.

Die Firmware verifiziert Signaturen während der BDS- und DXE-Phasen. Die Ereignisse finden in der folgenden Reihenfolge statt:

  1. PCI und abgeleitete Busse initialisieren
  2. Prüfen Sie PCI-Geräte auf optionale ROMs
  3. Gefundene Options-ROMs werden im Speicher abgebildet
  4. Die DXE-Phase lädt alle UEFI-Treiber in ROMs

UEFI-Options-ROMs können sich überall im Speicher befinden. Standardmäßig wird das Gerät vom ROM auf der Karte verwaltet. UEFI ermöglicht es der Plattform, die Richtlinie zu steuern, welche Options-ROM welches Gerät mit EFI_PLATFORM_DRIVER_OVERRIDE steuert. UEFI unterstützt optionale ROMs zum Registrieren einer Konfigurationsschnittstelle.

Auf einem PC mit aktiviertem Secure Boot stellen optionale ROM-Treiber ein Sicherheitsrisiko dar, wenn sie nicht signiert oder nicht validiert sind. Die Signaturvalidierung für Options-ROMs ist eine WHCK-Anforderung. Dasselbe gilt für die Wartung von Options-ROMs, um sicherzustellen, dass das Update vor der Installation validiert wird.

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

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

2. Problemstellung

Einige Builds von Secure Boot-fähigem UEFI-BIOS, einschließlich Tiano Core, authentifizierten standardmäßig keine UEFI-Options-ROMs, da signierte UEFI-Options-ROMs während der Entwicklung von Secure Boot nicht verfügbar waren. Dadurch wird eine Angriffsfläche/Schwachstelle in UEFI Secure Boot verfügbar gemacht.

2.1. Sicherheitsrisiko

Diese Schwachstelle war im August 2013 noch in EDK II und UDK2010 vorhanden. Die Quellcodebetreuer sind sich des Problems bewusst und es wurde ein Fehler gemeldet. Jede von EDK II und UDK2010 abgeleitete Firmware sollte überprüfen, wie die Option ROM-Überprüfung verwaltet wird. Das Überprüfungsverhalten des Options-ROM wird durch einen PCD-Wert PcdOptionRomImageVerificationPolicy im EDK II SecurityPkg-Paket gesteuert.

Der Quellcode für die TianoCore-Schwachstelle 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äß durchgeführt wird. Dies ist kein idealer Wert für Systeme, die die UEFI Secure Boot-Funktionalität implementieren.

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

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

In EDK II und UDK2010 verwendet die richtige Codierungspraxis einen Überschreibungsmechanismus, um PCD-Werte für Plattform-Firmware zu ändern. Daher sollte der Wert für PcdOptionRomImageVerificationPolicy in nicht geändert werden SecurityPkg\SecurityPkg.dec. Der Override-Wert sollte in der DSC-Datei der Plattform festgelegt werden. Nachfolgend wird ein Beispiel mit Nt32Pkg\Nt32Pkg.dsc gezeigt:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

Die PCD-Überschreibung sollte unter dem [PcdsFixedAtBuild] Abschnitt der DSC-Datei platziert werden. Der genaue Mechanismus zum Überschreiben von Parametern kann je nach den Tools des BIOS-Anbieters unterschiedlich sein.

Hinweis

Diese Schwachstelle kann in frühen Implementierungen von UEFI Secure Boot BIOS von unabhängigen BIOS-Anbietern vorhanden sein. Wenden Sie sich an Ihren BIOS-Händler, um festzustellen, ob Ihre Version möglicherweise betroffen ist.

3. Wer ist betroffen?

Ein UEFI-PC, der Secure Boot implementiert und über einen UEFI-Options-ROM-Treiber verfügt, der nicht signiert ist. Darüber hinaus kann die Firmware für die Kompatibilität, um die vorhandenen Karten zum Laufen zu bringen, eine Sicherheitslücke aufweisen, die Options-ROMs nicht überprüft.

Laptops, Netbooks, Ultrabooks und Tablets: Die meisten sind nicht betroffen. Options-ROMs sind typischerweise auf Backplane-Bussen wie PCI/e, ISA und ihren Derivaten (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt usw.) vorhanden. Wenn ein Laptop nichts davon offen hat, ist seine Angriffsfläche stark reduziert. Darüber hinaus ist es wahrscheinlich, dass UEFI-Treiber für Onboard-Laptop-Komponenten in das Kern-BIOS-Firmware-Volume integriert sind und sich nicht in einem separaten Options-ROM befinden. Daher sind die meisten Laptops nicht gefährdet. Auch wenn Legacy-Options-ROMs deaktiviert sind, sieht es so aus, als ob UEFI nur PCI-basierte Options-ROMs unterstützt.

Wenn Sie jedoch einen Desktop, ein Motherboard oder einen Server haben, der über ein UEFI-BIOS verfügt und Secure Boot implementiert, sind Sie möglicherweise betroffen. Auf dem dedizierten RAID-Controller eines Servers oder Add-In-Speichercontroller für SATA, FC usw. oder Ethernet-PCIe-Netzwerkkarten können optionale ROMs vorhanden sein. Add-In-Controller, die eine Vielzahl von Funktionen auf Servern unterstützen, sind weit verbreitet, daher gilt dies insbesondere für den Serverbereich.

Dies kann möglicherweise 32-Bit- und 64-Bit-PCs sowohl der Klasse 2 als auch der Klasse 3 betreffen.

Wenn eine Secure Boot-Plattform optionale ROMs von Geräten unterstützt, die nicht dauerhaft mit der Plattform verbunden sind, und die Möglichkeit unterstützt, diese optionalen ROMs zu authentifizieren, muss sie die unter Netzwerkprotokolle – UDP und MTFTP beschriebenen Validierungsmethoden für optionale ROMs und die beschriebenen authentifizierten EFI-Variablen unterstützen in UEFI-Spezifikation 2.3.1 Errata C Abschnitt 7.2.

4. Wie kann man es testen?

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

Sie benötigen Folgendes:

  • Test-PC mit UEFI-Firmware
  • PCI-Gerät mit Option ROM auf dem zu testenden PC (wie eine Grafikkarte)
  • Stellen Sie sicher, dass Secure Boot aktiviert ist

Schritte zum Testen:

  1. Setzen Sie eine UEFI-Add-On-PCI-Karte mit UEFI-Options-ROM in den zu testenden PC ein.

    Wenn Sie zum Testen eine PCI-Grafikkarte verwenden, schließen Sie einen externen Monitor an.

  2. Aktivieren Sie Secure Boot 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 gesetzt werden

  3. Starten Sie den PC neu

  4. Erwarten Sie Folgendes Ergebnis:

    • Wenn die UEFI-Firmware korrekt implementiert ist, würde der UEFI-Options-ROM-Treiber nicht geladen, da das Vorhandensein eines Options-ROMs dazu führt, dass die Firmware die „Db“ auf ein Zertifikat überprüft. Da „Db“ NULL ist, kann der UEFI-Treiber nicht geladen werden. Wenn Sie beispielsweise die Grafikkarte zum Testen verwenden, werden Sie feststellen, dass nichts auf dem Display angezeigt wird.
    • Wenn die Firmware nicht korrekt implementiert ist, wird der UEFI-Treiber aus dem Options-ROM geladen, da die Firmware nicht nach Signaturen in „Db“ sucht. Wenn Sie zum Beispiel die Videokarte zu Testzwecken verwenden, werden Sie sehen, dass der Monitor, der an die optionale ROM-Karte angeschlossen ist, eine Anzeige hat.

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

Bitte beachten Sie die im WHCK verfügbaren Beispielskripts zum Generieren von PK und KEK. Anhang B enthält Beispielskripts und weitere Details.

Sie können auch Anhang A für einen anderen Ansatz zur Durchführung des obigen Tests heranziehen. Bei diesem Ansatz ist es nicht erforderlich, die DB auf Null zu setzen, sondern einen unsignierten UEFI-Options-ROM-Treiber vom IHV.

5. Wie man es repariert

Wenn der obige Test fehlschlägt, arbeiten Sie mit Ihrem IBV zusammen, um die erforderlichen Versionen zu erwerben und sie zu konfigurieren, um Options-ROMs zu validieren. Stellen Sie sicher, dass die Firmware den Test besteht. Für PCs, die ausgeliefert wurden, müssen Sie ein sicheres Firmware-Update durchführen. Siehe NIST-Publikation 800-147 und/oder Windows 8.1 Secure Boot Key Creation and Management Guidance.

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

5.1. Signieren des Fahrers

Falls Sie feststellen, dass Sie möglicherweise unsignierte Treiber auf UEFI-Options-ROMs haben, lesen Sie bitte unten, wie Sie das beheben können.

Signieren Sie jeden Options-ROM-Treiber einzeln. Dadurch wird das Format des PCI Option ROM beschädigt. Sie müssen nur den UEFI-Treiber signieren, bevor Sie das 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 und OFF in der UEFI-Shell (Laden/Entladen der Treiberdatei). Legen Sie dann den signierten Treiber in das kombinierte Options-ROM.

Sie können Ihren IHV an das Microsoft SysDev Center verweisen, um seine UEFI-Options-ROMs über einen Dienst signieren zu lassen, der über das SysDev Center verfügbar ist.

5.2. Validierung des Updates

Führen Sie den oben erwähnten Test durch, um sicherzustellen, dass die Schwachstelle nicht existiert. Verwenden Sie die HCK-Tests, um sicherzustellen, dass es keine funktionellen Regressionen gibt.

6. Ressourcen

Anhang A: Alternativer Ansatz zum Testen mit unsignierten Options-ROM-Treibern

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

Sie benötigen Folgendes:

  • Test-PC mit UEFI-Firmware
  • PCI-Gerät mit einem nicht signierten Option-ROM-Treiber, der an den zu testenden PC angeschlossen ist (wie eine Grafikkarte)
  • Stellen Sie sicher, dass Secure Boot aktiviert ist
  • Option IHV-Tools zum Erkennen von Signaturen auf Options-ROM-Treibern, wenn nicht offensichtlich ist, ob der Options-ROM-Treiber signiert ist oder nicht

Wenn die Firmware korrekt implementiert und das Options-ROM nicht signiert ist, sollte die Karte die Überprüfung durch die Firmware nicht bestehen und den Treiber nicht auf die Karte laden. Der PC sollte einen Fehlercode wie EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND melden. Falls Sie eine Grafikkarte verwenden, sehen Sie möglicherweise, dass der PC nur einen schwarzen Bildschirm anzeigt, da der Options-ROM-Treiber nicht geladen wurde.

Wenn die Firmware falsch implementiert ist, würde dieser Test funktionieren.

Anhang B: Skripte zum Aktivieren von Secure Boot mit NULL db

Sie können entweder Ihren aktuellen Satz von Secure Boot-Variablen (PK und KEK) verwenden oder Testvariablen zum Testen generieren.

Nachfolgend sind die Schritte aufgeführt, die zum Generieren des Test-PK, KEK und zum Setzen von Db auf NULL verwendet werden. Stellen Sie sicher, dass Secure Boot nicht aktiviert ist; andernfalls wären für diese Schritte signierte UEFI-Bin-Dateien erforderlich.

Hinweis

Wir setzen die Secure Boot-Variable – Db, KEK und PK in umgekehrter Reihenfolge, damit wir die UEFI-Bin-Dateien nicht signieren müssen.

Vor diesem Schritt sollte sich der PC im Setup-Modus befinden.

  1. Erstellen Sie KEK- und PK-Zertifikate

    Für diesen Schritt ist das im Windows SDK verfügbare Tool makecert.exe erforderlich.

    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 Generieren von Test-PK

    Unten sehen 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. Generieren Sie Test-KEK oder verwenden Sie Ihren eigenen OEM-KEK

    Sie können dafür Ihren eigenen OEM-KEK oder Skripte aus dem WHCK nutzen.

    Unten sehen 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. Setzen Sie Db auf Null und setzen Sie KEK und PK

    Das erste, was dieses Skript tut, ist, die Db auf Null zu setzen.

    Hinweis

    Denken Sie daran, wenn die Fabrikam Test KEK CA die einzige vorhandene KEK CA ist (d. h. es gibt keine Windows KEK CA), kann der PC in Windows RE booten.

    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 Options-ROM-Karte ein und testen Sie

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

    Wenn das Options-ROM in der Firmware korrekt implementiert ist und Sie eine Grafikkarte zum Testen verwenden, sollte auf dem angeschlossenen Monitor keine Anzeige erfolgen.

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

Anleitung zur Erstellung und Verwaltung von Windows Secure Boot Keys

Übersicht über den sicheren Start

Validierung der Funktionalität der Windows UEFI-Firmware-Aktualisierungsplattform