Leitfaden zur Erstellung und Verwaltung von Schlüsseln für Windows Sicherer Start

In diesem Dokument werden OEMs und ODMs bei der Erstellung und Verwaltung der Schlüssel und Zertifikate für Sicherer Start in einer Fertigungsumgebung unterstützt. Es behandelt Fragen zur Erstellung, Speicherung und dem Abruf von Plattformschlüsseln (PKs), sicheren Firmwareupdateschlüsseln und Schlüsselaustauschschlüsseln von Drittanbietern (KEKs).

Hinweis

Geräte-OEMs, Unternehmen und Kunden finden die von Microsoft empfohlenen PK-, KEK-, DB- und DBX-Binärdateien im Microsoft Open-Source-Repository für sicheren Start. Die Binärdateien werden in das erwartete EDKII-Format formatiert, um problemlos in die Firmware integriert werden zu können.

Geräte-OEMs finden die Konfigurationsanforderungen für den sicheren Start für Windows 11, Version 25H2, in Abschnitt 1.6 dieses Artikels.

Hinweis

Das Microsoft Corporation KEK CA 2011-Zertifikat wird im Jahr 2026 ablaufen. Für das neue Microsoft Corporation KEK CA 2023-Zertifikat müssen alle OEMs Updates erstellen, signieren und an Microsoft übermitteln. Auf diese Weise kann Microsoft marktübliche Geräte mit dem neuen Microsoft KEK-Zertifikat aktualisieren, damit Systeme auch nach 2026 weiterhin DB- und DBX-Updates erhalten. Anweisungen und Begleitmaterial für Tests finden Sie unter https://aka.ms/KEKUpdatePackage

Windows-Anforderungen für UEFI- und Sicherer Start finden Sie in den Windows-Hardwarezertifizierungsanforderungen. Dieses Dokument führt keine neuen Anforderungen ein oder stellt ein offizielles Windows-Programm dar. Es ist als Anleitung über Zertifizierungsanforderungen hinaus vorgesehen, um effiziente und sichere Prozesse zum Erstellen und Verwalten von Schlüsseln für den sicheren Start zu unterstützen. Dies ist wichtig, da UEFI Secure Boot auf der Grundlage der Verwendung von Public Key Infrastructure basiert, um Code zu authentifizieren, bevor er ausgeführt werden darf.

Es wird vom Leser erwartet, dass er die Grundlagen von UEFI, das grundlegende Verständnis von Sicherer Start (Kapitel 27 der UEFI-Spezifikation) und das PKI-Sicherheitsmodell kennt.

Anforderungen, Tests und Tools, die Sicherer Start unter Windows überprüfen, sind heute über das Windows Hardware Certification Kit (HCK) verfügbar. Diese HCK-Ressourcen adressieren jedoch nicht die Erstellung und Verwaltung von Schlüsseln für Windows-Bereitstellungen. In diesem Papier wird die Schlüsselverwaltung als Ressource behandelt, um Partner durch die Bereitstellung der Schlüssel zu unterstützen, die von der Firmware verwendet werden. Es ist nicht als präskriptive Anleitung vorgesehen und enthält keine neuen Anforderungen.

Auf dieser Seite:

• 1. Sicherer Start, Windows und Key Management enthält Informationen zur Startsicherheit und PKI-Architektur, wie sie auf Windows und den sicheren Start angewendet wird.
• 2. Key Management Solutions soll Partnern dabei helfen, eine Schlüsselverwaltungs- und Entwurfslösung zu entwerfen, die ihren Anforderungen entspricht.
• 3. Zusammenfassung und Ressourcen umfasst Indizes, Checklisten, APIs und andere Verweise.

Dieses Dokument dient als Ausgangspunkt für die Entwicklung von kundenfähigen PCs, Fabrikbereitstellungstools und wichtigsten bewährten Sicherheitsmethoden.

1. Sicherer Start, Windows und Schlüsselverwaltung

Die UEFI-Spezifikation (Unified Extensible Firmware Interface) definiert einen Firmware-Ausführungsauthentifizierungsprozess namens Sicherer Start. Als Branchenstandard definiert Sicherer Start, wie Plattform-Firmware Zertifikate verwaltet, Firmware authentifiziert und wie sich das Betriebssystem mit diesem Prozess verbindet.

Sicherer Start basiert auf dem PKI-Prozess (Public Key Infrastructure), um Module zu authentifizieren, bevor sie ausgeführt werden dürfen. Diese Module können Firmwaretreiber, Option ROMs, UEFI-Treiber auf dem Datenträger, UEFI-Anwendungen oder UEFI-Startlademodule enthalten. Durch die Imageauthentifizierung vor der Ausführung reduziert Sicherer Start das Risiko von Vorstart-Schadsoftwareangriffen wie Rootkits. Microsoft setzt auf UEFI Secure Boot in Windows 8 und höher als Teil der Sicherheitsarchitektur Trusted Boot, um die Plattformsicherheit für unsere Kunden zu verbessern. Sicherer Start ist für Windows 8 und höher von Client-PCs erforderlich und für Windows Server 2016 wie in den Windows-Hardwarekompatibilitätsanforderungen definiert.

Der Prozess Sicherer Start funktioniert wie folgt und wie in Abbildung 1 dargestellt:

1. Firmwarestartkomponenten: Die Firmware überprüft, ob das Betriebssystem-Ladeprogramm vertrauenswürdig ist (Windows oder ein anderes vertrauenswürdiges Betriebssystem.)
2. Windows-Startkomponenten: BootMgr, WinLoad, Windows Kernel-Start. Windows-Startkomponenten überprüfen die Signatur für jede Komponente. Nicht vertrauenswürdige Komponenten werden nicht geladen und lösen stattdessen einen Secure Boot-Wiederherstellungsprozess aus.
   • Antivirus- und Antimalware-Software-Initialisierung: Diese Software wird auf eine spezielle Signatur überprüft, die von Microsoft ausgestellt wurde, um sicherzustellen, dass es sich um einen vertrauenswürdigen startkritischen Treiber handelt, und frühzeitig im Startprozess gestartet.
   • Initialisierung startkritischer Treiber: Die Signaturen aller startkritischen Treiber werden im Rahmen der Überprüfung von Sicherer Start in WinLoad überprüft.
3. Zusätzliche Betriebssystem-Initialisierung
4. Windows-Anmeldebildschirm

Abbildung 1: Windows Vertrauenswürdige Startarchitektur

Die Implementierung von UEFI Secure Boot ist Teil der vertrauenswürdigen Startarchitektur von Microsoft, die in Windows 8.1 eingeführt wurde. Ein wachsender Trend in der Entwicklung von Schadsoftware-Exploits zielt auf den Startpfad als bevorzugten Angriffsvektor ab. Diese Angriffsklasse war schwierig zu schützen, da Antimalware-Produkte durch bösartige Software deaktiviert werden können, die verhindert, dass sie vollständig geladen werden. Mit der Trusted Boot-Architektur von Windows und der Einrichtung eines Vertrauensankers mit Secure Boot ist der Kunde vor bösartigem Code geschützt, der im Startpfad ausgeführt wird. Es wird sichergestellt, dass nur signierter, zertifizierter "known good" Code und Bootloader ausgeführt werden können, bevor das Betriebssystem selbst geladen wird.

1.1 Public-Key Infrastruktur (PKI) und Sicherer Start

Die PKI legt Authentizität und Vertrauen in ein System fest. Sicherer Start nutzt PKI für zwei hohe Zwecke:

1. Während des Starts, um zu ermitteln, ob frühe Startmodule für die Ausführung vertrauenswürdig sind.
2. Um Anforderungen für Dienstanfragen zu authentifizieren, sind Änderungen der Secure-Boot-Datenbanken und Aktualisierungen der Plattform-Firmware erforderlich.

Eine PKI besteht aus:

• Eine Zertifizierungsstelle (CA), die die digitalen Zertifikate ausgibt.
• Eine Registrierungsbehörde, die die Identität der Benutzer überprüft, die ein Zertifikat aus der Zertifizierungsstelle anfordern.
• Ein zentrales Verzeichnis, in dem Schlüssel gespeichert und indiziert werden sollen.
• Ein Zertifikatverwaltungssystem.

1.2 Kryptografie mit öffentlichem Schlüssel

Kryptografie mit öffentlichem Schlüssel verwendet ein Paar mathematischer kryptografischer Schlüssel, die als öffentlicher und privater Schlüssel bezeichnet werden. Wenn Sie einen der Schlüssel kennen, können Sie nicht einfach berechnen, was das andere ist. Wenn ein Schlüssel zum Verschlüsseln von Informationen verwendet wird, kann nur der entsprechende Schlüssel diese Informationen entschlüsseln. Für Sicherer Start wird der private Schlüssel zum digitalen Signieren von Code verwendet. Der öffentliche Schlüssel wird verwendet, um die Signatur auf diesem Code zu überprüfen und dessen Authentizität zu beweisen. Wenn ein privater Schlüssel kompromittiert ist, sind Systeme mit entsprechenden öffentlichen Schlüsseln nicht mehr sicher. Dies kann zu Bootkit-Angriffen führen und den Ruf der Entität beeinträchtigen, die für die Sicherheit des privaten Schlüssels verantwortlich ist.

In einem Secure Boot-System mit öffentlichem Schlüssel haben Sie Folgendes:

• 1.2.1 RSA 2048-Verschlüsselung

  RSA-2048 ist ein asymmetrischer kryptografischer Algorithmus. Der zum Speichern eines RSA-2048-Moduls in roher Form erforderliche Speicherplatz beträgt 2048 Bit.

• 1.2.2 Selbstsigniertes Zertifikat

  Ein Zertifikat, das vom privaten Schlüssel signiert ist, der dem öffentlichen Schlüssel des Zertifikats entspricht, wird als selbst signiertes Zertifikat bezeichnet. Wurzelzertifikate einer Zertifizierungsstelle fallen in diese Kategorie.

• 1.2.3 Zertifizierungsstelle

  Die Zertifizierungsstelle (ZS) stellt signierte Zertifikate aus, die die Identität des Zertifikatbetreffs bestätigen und diese Identität an den öffentlichen Schlüssel binden, der im Zertifikat enthalten ist. Die CA signiert das Zertifikat mithilfe des privaten Schlüssels. Sie stellt den entsprechenden öffentlichen Schlüssel allen Interessierten in Form eines selbstsignierten Stamm-CA-Zertifikats zur Verfügung.

  In Sicherer Start umfassen Zertifizierungsstellen (ZS) den OEM (oder ihre Stellvertretungen) und Microsoft. Die CAs generieren die Schlüsselpaare, die die Vertrauenswurzel bilden, und verwenden dann die privaten Schlüssel, um legitime Vorgänge zu signieren, z. B. zulässige EFI-Module für den frühen Start und Firmware-Wartungsanforderungen. Die entsprechenden öffentlichen Schlüssel sind in die UEFI-Firmware von mit Secure Boot aktivierten PCs eingebettet und werden verwendet, um diese Vorgänge zu überprüfen.

  (Weitere Informationen zur Verwendung von ZS und Schlüsselaustausch sind im Internet verfügbar, die sich auf das Modell Sicherer Start beziehen.)

• 1.2.4 Öffentlicher Schlüssel

  Der öffentliche Plattformschlüssel wird auf dem PC bereitgestellt und ist zugänglich oder „öffentlich“. In diesem Dokument verwenden wir das Suffix „pub“, um öffentlichen Schlüssel zu bezeichnen. Beispielsweise bezeichnet PKpub die öffentliche Hälfte des PK.

• 1.2.5 Privater Schlüssel

  Damit PKI funktioniert muss der private Schlüssel sicher verwaltet werden. Er sollte für einige sehr vertrauenswürdige Personen in einer Organisation zugänglich sein und sich an einem physischen sicheren Ort mit starken Zugriffsrichtlinieneinschränkungen befinden. In diesem Dokument verwenden wir das Suffix „priv“, um privaten Schlüssel zu bezeichnen. Beispielsweise gibt PKpriv die private Komponente des PK an.

• 1.2.6 Zertifikate

  Die primäre Verwendung für digitale Zertifikate besteht darin, den Ursprung signierter Daten zu überprüfen, z. B. Binärdateien usw. Eine häufige Verwendung von Zertifikaten ist für die Internetnachrichtensicherheit mithilfe von Transport Layer Security (TLS) oder Secure Sockets Layer (SSL). Wenn Sie die signierten Daten mit einem Zertifikat überprüfen, kann der Empfänger den Ursprung der Daten kennen und ob sie während der Übertragung geändert wurden.

  Im Allgemeinen enthält ein digitales Zertifikat auf hoher Ebene einen definierten Namen (DN), einen öffentlichen Schlüssel und eine Signatur. Der DN identifiziert eine Entität – beispielsweise ein Unternehmen – die den privaten Schlüssel enthält, der dem öffentlichen Schlüssel des Zertifikats entspricht. Das Signieren des Zertifikats mit einem privaten Schlüssel und das Platzieren der Signatur im Zertifikat verknüpft den privaten Schlüssel mit dem öffentlichen Schlüssel.

  Zertifikate können einige andere Datentypen enthalten. Beispielsweise enthält ein X.509-Zertifikat folgende Zertifikatdaten: Format, Seriennummer, Algorithmus der Signatur, Name der ausstellenden Zertifizierungsstelle, Name und öffentlicher Schlüssel der Entität, die das Zertifikat anfordert, sowie Signatur der Zertifizierungsstelle.

• 1.2.7 Zertifikate verketten

  Von: Zertifikatketten:

  

  Abbildung 2: Drei-Zertifikatkette

  Benutzerzertifikate werden häufig von einem anderen privaten Schlüssel signiert, z. B. einem privaten Schlüssel der CA. Dies stellt eine Zwei-Zertifikatkette dar. Die Überprüfung, ob ein Benutzerzertifikat echt ist, erfordert die Verifizierung seiner Signatur, wofür der öffentliche Schlüssel der Zertifizierungsstelle aus ihrem Zertifikat benötigt wird. Bevor jedoch der öffentliche Schlüssel der CA verwendet werden kann, muss das umschließende Zertifikat der CA überprüft werden. Da das ZS-Zertifikat selbstsigniert ist, wird der öffentliche Schlüssel der ZS verwendet, um das Zertifikat zu überprüfen.

  Ein Benutzerzertifikat muss nicht vom privaten Schlüssel der Stamm-CA signiert werden. Es könnte vom privaten Schlüssel eines Vermittlers signiert werden, dessen Zertifikat wiederum vom privaten Schlüssel der Zertifizierungsstelle signiert ist. Dies ist ein Beispiel für eine Zertifikatskette aus drei Komponenten: Benutzerzertifikat, Vermittlerzertifikat und CA-Zertifikat. Aber mehr als ein Vermittler kann Teil der Kette sein, sodass Zertifikatketten beliebig lang sein können.

1.3 Die Anforderungen an die Secure Boot-PKI

Der durch UEFI definierte Vertrauenswurzel besteht aus dem Plattformschlüssel und allen Schlüsseln, die ein OEM oder ODM im Firmwarekern enthält. Vor-UEFI-Sicherheit und ein Vertrauensanker werden nicht vom UEFI Secure Boot-Prozess berücksichtigt, sondern von den Veröffentlichungen des National Institute of Standards and Technology (NIST) und der Trusted Computing Group (TCG), die in diesem Dokument genannt werden.

• 1.3.1 Anforderungen für Sicherer Start

  Sie müssen die folgenden Parameter für die Implementierung von Sicherer Start berücksichtigen:

  • Kundenanforderungen
  • Windows-Hardwarekompatibilitätanforderungen
  • Schlüsselgenerierungs- und Verwaltungsanforderungen.

  Sie müssen Hardware für die Verwaltung sicherer Startschlüssel wie Hardwaresicherheitsmodule (HSMs) auswählen, besondere Anforderungen an PCs berücksichtigen, um Regierungen und andere Agenturen zu beliefern und schließlich den Prozess zum Erstellen, Auffüllen und Verwalten des Lebenszyklus verschiedener Sicherer Startschlüssel zu erstellen, zu füllen und zu verwalten.

• 1.3.2 Secure Boot-bezogene Schlüssel

  Die Schlüssel, die für Sicherer Start verwendet werden, sind unterhalb aufgeführt:

  

  Abbildung 3: Schlüssel im Zusammenhang mit Sicherer Start

  Abbildung 3 oberhalb stellt die Signaturen und Schlüssel in einem PC mit Sicherer Start dar. Die Plattform wird über einen Plattformschlüssel gesichert, den der OEM während der Fertigung in der Firmware installiert. Andere Schlüssel werden von Sicherer Start verwendet, um den Zugriff auf Datenbanken zu schützen, die Schlüssel speichern, um die Ausführung von Firmware zuzulassen oder zu verbieten.

  Die autorisierte Datenbank (db) enthält öffentliche Schlüssel und Zertifikate, die vertrauenswürdige Firmwarekomponenten und Betriebssystem-Ladeprogramme darstellen. Die verbotene Signaturdatenbank (dbx) enthält Hashes bösartiger und anfälliger Komponenten sowie kompromittierte Schlüssel und Zertifikate und blockiert die Ausführung dieser schädlichen Komponenten. Die Stärke dieser Richtlinien basiert auf der Signatur der Firmware mithilfe von Authenticode und Public Key Infrastructure (PKI). PKI ist ein gut etablierter Prozess zum Erstellen, Verwalten und Widerrufen von Zertifikaten, die während des Informationsaustauschs Vertrauen herstellen. PKI befindet sich im Kern des Sicherheitsmodells für Sicherer Start.

  Nachfolgend finden Sie weitere Details zu diesen Schlüsseln.

• 1.3.3 Plattformschlüssel (PK)

  Gemäß Abschnitt 27.5.1 des UEFI 2.3.1 Errata C stellt der Plattformschlüssel eine Vertrauensstellung zwischen dem Plattformbesitzer und der Plattform-Firmware her. Der Plattformbesitzer registriert die öffentliche Hälfte des Schlüssels (PKpub) in der Plattform-Firmware, wie in Abschnitt 7.2.1 des UEFI 2.3.1 Errata C angegeben. Dieser Schritt verschiebt die Plattform aus dem Setupmodus in den Benutzermodus. Microsoft empfiehlt, dass der Plattformschlüssel vom Typ EFI_CERT_X509_GUID mit dem Public Key-Algorithmus RSA, der Länge des öffentlichen Schlüssels von 2048 Bit und dem Signaturalgorithmus sha256RSA ist. Der Plattformbesitzer kann den Typ EFI_CERT_RSA2048_GUID verwenden, wenn Speicherplatz ein Problem darstellt. Öffentliche Schlüssel werden verwendet, um Signaturen – wie weiter oben in diesem Dokument beschrieben – zu überprüfen. Der Plattformbesitzer kann später die private Hälfte des Schlüssels (PKpriv) verwenden:

• Um den Besitz der Plattform zu ändern, müssen Sie die Firmware in den UEFI-definierten Setupmodus setzen, der Sicherer Start deaktiviert. Kehren Sie nur dann in den Setupmodus zurück, wenn dies während der Herstellung erforderlich ist.

• Für Desktop- und Servergeräte können OEMs den PK und die ihm zugeordnete PKI verwalten oder den von Microsoft verwalteten PK für OEMs verwenden. Der von Microsoft verwaltete PK wird durch Microsoft-HSMs geschützt und als Teil der bewährten Methoden für PKI verwaltet. Dieser PK wird für das Windows-Ökosystem bevorzugt.

1.3.3.1 So registrieren oder aktualisieren Sie einen Schlüsselaustauschsclüssel (KEK) Registrieren des Plattformschlüssels

Der Plattformbesitzer registriert die öffentliche Hälfte des Plattformschlüssels (PKpub) durch Aufrufen des UEFI-Startdiensts SetVariable() gemäß Abschnitt 7.2.1 der UEFI Spec 2.3.1 errata C und Zurücksetzen der Plattform. Wenn sich die Plattform im Setupmodus befindet, wird der neue PKpub mit seinem PKpriv-Gegenstück signiert. Wenn sich die Plattform im Benutzermodus befindet, muss der neue PKpub mit dem aktuellen PKpriv signiert werden. Wenn die PK vom Typ EFI_CERT_X509_GUID ist, muss sie durch den unmittelbaren PKpriv signiert werden, nicht mit einem privaten Schlüssel eines Zertifikats, das von der PK ausgestellt wurde.

1.3.3.2 Löschen des Plattformschlüssels

Der Plattformbesitzer löscht die öffentliche Hälfte des Plattformschlüssels (PKpub), indem er UEFI-Start Service SetVariable() mit einer Variablengröße von 0 aufruft und die Plattform zurücksetzt. Wenn sich die Plattform im Setupmodus befindet, muss die leere Variable nicht authentifiziert werden. Wenn sich die Plattform im Benutzermodus befindet, muss die leere Variable mit dem aktuellen PKpriv signiert werden; Einzelheiten finden Sie im Abschnitt 7.2(Variable Services) unter UEFI-Spezifikation 2.3.1 Errata C. Es wird dringend empfohlen, dass die Produktions-PKpriv niemals verwendet wird, um ein Paket zu signieren, um die Plattform zurückzusetzen, da dadurch Sicherer Start programmgesteuert deaktiviert werden kann. Dies ist in erster Linie ein Vorproduktionstestszenario.

Der Plattformschlüssel kann auch mithilfe einer sicheren plattformspezifischen Methode gelöscht werden. In diesem Fall muss der globale Setupmodus auch auf 1 aktualisiert werden.

Abbildung 4: Diagramm „Plattformschlüsselzustand“

1.3.3.3 PK Erzeugung

Gemäß UEFI-Empfehlungen muss der öffentliche Schlüssel im nicht veränderlichen Speicher gespeichert werden, der manipulations- und löschsicher auf dem PC ist. Die privaten Schlüssel bleiben beim Partner oder im Security Office des OEM sicher, und nur der öffentliche Schlüssel wird auf die Plattform geladen. Es gibt weitere Details in den Abschnitten 2.2.1 und 2.3.

Microsoft stellt einen PK für OEMs bereit, um keine Verantwortung für die Aufrechterhaltung und Sicherung des PK-Zertifikats tragen zu müssen. Der PK ist durch Microsoft-HSMs geschützt und wird im Rahmen der Microsoft-PKI-Vorgänge verwaltet.

Die Anzahl der generierten PK liegt nach Ermessen des Plattformanbieters (OEM). Diese Schlüssel könnten sein:

1. Einer pro PC. Es gibt einen eindeutigen Schlüssel für jedes Gerät. Dies kann für Behörden, Finanzinstitute oder andere Serverkunden mit hohen Sicherheitsanforderungen erforderlich sein. Er kann zusätzliche Speicher- und Kryptoverarbeitungsleistung erfordern, um private und öffentliche Schlüssel für große Anzahl von PCs zu generieren. Dadurch wird die Komplexität hinzugefügt, Geräte mit ihrem entsprechenden Primärschlüssel (PK) zuzuordnen, wenn in Zukunft Firmwareupdates an die Geräte übertragen werden. Es gibt ein paar verschiedene HSM-Lösungen, um eine große Anzahl von Schlüsseln basierend auf dem HSM-Anbieter zu verwalten. Weitere Informationen finden Sie unter Sicherer Start Schlüsselerstellung mit HSM.

2. Einer pro Modell. Ein Schlüssel pro PC-Modell. Hier besteht der Kompromiss darin, dass alle Computer innerhalb desselben Modells anfällig wären, wenn ein Schlüssel kompromittiert wird. Dies wird von Microsoft für Desktop-PCs empfohlen.

3. Einer pro Produktlinie. Wenn ein Schlüssel kompromittiert wird, wäre eine ganze Produktlinie anfällig.

4. Einer pro OEM. Obwohl dies das einfachste Setup ist, wäre jeder von Ihnen hergestellte PC anfällig, wenn der Schlüssel kompromittiert wird. Um den werksseitigen Prozess zu beschleunigen, könnten PK und potenziell andere Schlüssel vorgeneriert und an einem sicheren Ort gespeichert werden. Diese können später abgerufen und in der Montagelinie verwendet werden. Weitere Details finden Sie in den Kapiteln 2 und 3.

1.3.3.4 Erneutes Schlüsseln des PK

Dies kann erforderlich sein, wenn der PK kompromittiert wird oder als Anforderung eines Kunden, der aus Sicherheitsgründen entscheiden könnte, seinen eigenen PK zu registrieren.

Die Neuschlüsselung kann entweder für ein Modell oder einen PC ausgeführt werden, basierend auf der ausgewählten Methode zum Erstellen des PK. Alle neueren PCs werden mit dem neu erstellten PK signiert.

Das Aktualisieren des PK auf einem Produktions-PC erfordert entweder ein mit dem vorhandenen PK signiertes Variablenupdate, das den PK ersetzt, oder ein Firmware-Update-Paket. Ein OEM könnte auch ein SetVariable()-Paket erstellen das nur den PK ändert und dieses mit einer einfachen Anwendung wie PowerShell verteilen. Das Firmware-Update-Paket wird mit dem Schlüssel für das sichere Firmware-Update signiert und von der Firmware überprüft. Wenn Sie ein Firmwareupdate durchführen, um den PK zu aktualisieren, sollten Sie sicherstellen, dass keK, db und dbx erhalten bleiben.

Auf allen PCs empfiehlt es sich, den PK nicht als sicheren Firmwareupdateschlüssel zu verwenden. Wenn der PKpriv kompromittiert wird, ist dies ebenfalls der Schlüssel für das sichere Firmwareupdate (da sie identisch sind). In diesem Fall ist das Update zum Registrieren eines neuen PKpubs möglicherweise nicht möglich, da der Aktualisierungsprozess ebenfalls kompromittiert wurde.

Auf SOCs-PCs gibt es einen weiteren Grund, den PK nicht als sicheren Firmwareupdateschlüssel zu verwenden. Dies liegt daran, dass der Schlüssel für das sichere Firmwareupdate dauerhaft auf PCs gebrannt wird, die den Anforderungen der Windows-Hardwarezertifizierung entsprechen.

• 1.3.4 Schlüsselaustauschschlüssel (KEK) Schlüsselaustauschschlüssel richten eine Vertrauensstellung zwischen dem Betriebssystem und der Plattform-Firmware ein. Jedes Betriebssystem (und potenziell jede Drittanbieteranwendung, die mit der Plattform-Firmware kommunizieren muss) registriert einen öffentlichen Schlüssel (KEKpub) in der Plattform-Firmware.

  1.3.4.1 Registrieren von Schlüsselaustauschschlüsseln

  Schlüsselaustauschschlüssel werden in einer Signaturdatenbank gespeichert, wie unter 1.4 Signaturdatenbanken (Db und Dbx) beschrieben. Die Signaturdatenbank wird als authentifizierte UEFI-Variable gespeichert.

  Der Plattformbesitzer registriert die Schlüsselaustauschschlüssel, indem entweder SetVariable() aufgerufen wird, wie in Abschnitt 7.2(Variable Services) unter UEFI-Spezifikation 2.3.1 Errata C angegeben, mit dem EFI_VARIABLE_APPEND_WRITE Attributsatz und dem Data-Parameter, der die neuen Schlüssel enthält, oder indem Sie die Datenbank mithilfe von GetVariable() lesen, den neuen Schlüsselaustauschschlüssel an die vorhandenen Schlüssel anfügen und dann die Datenbank mithilfe von SetVariable()wie in Abschnitt 7.2(Variable Services) unter UEFI-Spezifikation 2.3.1 Errata C ohne Attributsatz EFI_VARIABLE_APPEND_WRITE schreiben.

  Wenn sich die Plattform im Setupmodus befindet, muss die Signaturdatenbankvariable nicht signiert werden, aber die Parameter für den SetVariable()-Aufruf müssen weiterhin wie für authentifizierte Variablen in Abschnitt 7.2.1 angegeben vorbereitet werden. Wenn sich die Plattform im Benutzermodus befindet, muss die Signaturdatenbank mit dem aktuellen PKpriv signiert werden

  1.3.4.2 Leeren des KEK

  Es ist möglich, den KEK zu „leeren“ (löschen). Beachten Sie, dass, wenn der PK nicht auf der Plattform installiert ist, „leeren“-Anforderungen nicht signiert werden müssen. Wenn sie signiert sind, erfordert das Leeren der KEK ein PK-signiertes Paket, und das Leeren von db oder dbx erfordert ein Paket, das von jeder Entität in der KEK signiert ist.

  1.3.4.3 Microsoft KEK

  Das folgende Microsoft KEK-Zertifikat ist erforderlich, um die Sperrung fehlerhafter Images zu ermöglichen, indem das dbx aktualisiert wird und möglicherweise auch das db aktualisiert wird, um sich auf neuere signierte Windows-Images vorzubereiten.

1. Microsoft Corporation KEK 2K CA 2023

   • SHA-1 Cert Hash: 459AB6FB5E284D272D5E3E6ABC8ED663829D632B.
   • Signaturinhaber GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft stellt das Zertifikat Partnern zur Verfügung und es kann entweder als EFI_CERT_X509_GUID oder als EFI_CERT_RSA2048_GUID Typsignatur hinzugefügt werden.
   • Das Microsoft KEK-Zertifikat kann von: https://go.microsoft.com/fwlink/?linkid=2239775 heruntergeladen werden.

1.3.4.4 KEKDefault Der Plattformanbieter muss in der KEKDefault-Variablen einen Standardsatz von Schlüsselaustauschschlüsseln (KEK) bereitstellen. Weitere Informationen finden Sie in der UEFI-Spezifikation im Abschnitt 27.3.3.

1.3.4.5 OEM/Drittanbieter KEK – Hinzufügen mehrerer KEK

Kunden und Plattformbesitzer müssen keine eigenen KEK haben. Auf nicht Windows RT PCs verfügt der OEM möglicherweise über zusätzliche KEKs, um zusätzliche OEM- oder eine vertrauenswürdige Drittanbietersteuerung der db und dbx zu ermöglichen.

• 1.3.5 Schlüssel für die Firmwareaktualisierung beim sicheren Startvorgang Der Schlüssel für die sichere Firmwareaktualisierung wird verwendet, um die Firmware zu signieren, wenn sie aktualisiert werden muss. Dieser Schlüssel muss mindestens eine Schlüsselstärke von RSA-2048 haben. Alle Firmwareupdates müssen vom OEM, deren vertrauenswürdiger Stellvertretung wie ODM oder IBV (Unabhängiger BIOS-Anbieter) oder durch einen sicheren Signaturdienst signiert werden.

  Gemäß der NIST-Publikation 800-147 Field Firmware Update müssen alle Elemente von Richtlinien unterstützt werden:

  Alle Aktualisierungen des Firmware-Flashspeichers müssen vom Ersteller signiert werden.

  Firmware muss die Signatur des Updates überprüfen.

• 1.3.6 Erstellung von Schlüsseln für Sicheres Firmwareupdate

  Derselbe Schlüssel wird verwendet, um alle Firmwareupdates zu signieren, da sich der öffentliche Teil auf dem PC befindet. Sie können das Firmwareupdate auch mit einem Schlüssel signieren, der mit dem Secure-Firmware-Update-Schlüssel verkettet ist.

  Pro PC kann ein Schlüssel wie PK oder ein Schlüssel pro Modell oder einer pro Produktlinie vorhanden sein. Wenn pro PC ein Schlüssel vorhanden ist, bedeutet dies, dass Millionen von eindeutigen Updatepaketen generiert werden müssen. Bitte berücksichtigen Sie basierend auf der Ressourcenverfügbarkeit, welche Methode für Sie funktionieren würde. Ein Schlüssel pro Modell oder Produktlinie ist ein guter Kompromiss.

  Der öffentliche Schlüssel des sicheren Firmware-Updates (oder sein Hash, um Speicherplatz zu sparen) würde in einem geschützten Speicher auf der Plattform gespeichert werden – im Allgemeinen in „geschütztem Flash“ (PC) oder „einmalig programmierbaren Sicherungen“ (SOC).

  Wenn nur der Hash dieses Schlüssels gespeichert ist (um Speicherplatz zu sparen), enthält das Firmwareupdate den Schlüssel, und die erste Phase des Updatevorgangs überprüft, ob der öffentliche Schlüssel im Update dem auf der Plattform gespeicherten Hash entspricht.

  Kapseln sind eine Möglichkeit, mit der das Betriebssystem Daten über einen Neustart an die UEFI-Umgebung übergeben kann. Windows ruft UEFI UpdateCapsule() auf, um System- und PC-Firmwareupdates bereitzustellen. Zur Startzeit vor dem Aufrufen von ExitBootServices() übergibt Windows alle neuen Firmwareupdates im Windows Driver Store an UpdateCapsule(). Die UEFI-System-Firmware kann diesen Prozess verwenden, um die System- und PC-Firmware zu aktualisieren. Durch die Nutzung dieser Windows-Firmwareunterstützung kann sich ein OEM auf dasselbe gängige Format und denselben Prozess für die Aktualisierung der Firmware für System- und PC-Firmware verlassen. Firmware muss die ACPI ESRT-Tabelle implementieren, um UEFI UpdateCapsule() für Windows zu unterstützen.

  Ausführliche Informationen zur Implementierung der Windows UEFI Firmware Update Plattform finden Sie in der folgenden Dokumentation: Windows UEFI Firmware Update Plattform.

  Updatekapseln können sich im Arbeitsspeicher oder auf dem Datenträger befinden. Windows unterstützt Arbeitsspeicherupdates.

  1.3.6.1 Kapsel (Capsule-in-Memory)

  Nachfolgend ist der Ablauf der Ereignisse, damit eine In-Memory-Update-Kapsel funktioniert.

  1. Eine Kapsel wird von einer Anwendung im Betriebssystem in den Arbeitsspeicher gesetzt
  2. Postfachereignis wird so festgelegt, dass BIOS über ausstehende Updates informiert wird
  3. Der PC startet neu, überprüft das Kapsel-Image, und das Update wird vom BIOS durchgeführt.

• 1.3.7 Workflow eines typischen Firmwareupdates

  1. Laden Sie den Firmware-Treiber herunter, und installieren Sie ihn.
  2. Führen Sie einen Neustart aus.
  3. Das Betriebssystem-Ladeprogramm erkennt und überprüft die Firmware.
  4. Betriebssystem-Ladeprogramm übergibt ein binäres Blob an UEFI.
  5. UEFI führt das Firmwareupdate aus (Dieser Prozess ist im Besitz des Chipanbieters).
  6. Die Erkennung des Betriebssystem-Loaders wird erfolgreich abgeschlossen.
  7. Das Betriebssystem schließt den Startvorgang ab.

1.4 Signaturdatenbanken (Db und Dbx)

• 1.4.1 Zulässige Signaturdatenbank (db)

  Der Inhalt der EFI _IMAGE_SECURITY_DATABASE db steuert, welche Images beim Überprüfen geladener Images vertrauenswürdig sind. Die Datenbank kann mehrere Zertifikate, Schlüssel und Hashes enthalten, um zulässige Images zu identifizieren.

  Das folgende Zertifikat muss in db enthalten sein, damit das Windows-Betriebssystemladeprogramm geladen werden kann:

1. Windows UEFI CA 2023
   • SHA-1 Cert Hash: 45A0FA32604773C82433C3B7D59E7466B3AC0C67.
   • Signaturinhaber GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft stellt das Zertifikat Partnern zur Verfügung und es kann entweder als EFI_CERT_X509_GUID oder als EFI_CERT_RSA2048_GUID Typsignatur hinzugefügt werden.
   • Windows UEFI CA 2023 kann von hier heruntergeladen werden: https://go.microsoft.com/fwlink/?linkid=2239776.

Außer für Systeme, die nur für den Windows-Start gesperrt sind, sollte der OEM erwägen, UEFI-CAs von Microsoft-Drittanbietern und Microsoft Option ROM CA einzuschließen, damit Drittanbieter-UEFI-Treiber und -Anwendungen ohne zusätzlicher Schritte seitens des Benutzers auf dem Computer ausgeführt werden können.

1. Microsoft Corporation UEFI CA 2011

   • SHA-1 Cert Hash: 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3.
   • Signaturinhaber GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft stellt das Zertifikat Partnern zur Verfügung und es kann entweder als EFI_CERT_X509_GUID oder als EFI_CERT_RSA2048_GUID Typsignatur hinzugefügt werden.
   • Microsoft Corporation UEFI CA 2011 kann von hier heruntergeladen werden: https://go.microsoft.com/fwlink/p/?linkid=321194.

2. Microsoft UEFI CA 2023

   • SHA-1 Cert Hash: B5EEB4A6706048073F0ED296E7F580A790B59EAA.
   • Signaturinhaber GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft stellt das Zertifikat Partnern zur Verfügung und es kann entweder als EFI_CERT_X509_GUID oder als EFI_CERT_RSA2048_GUID Typsignatur hinzugefügt werden.
   • Microsoft Corporation UEFI CA 2023 kann von hier heruntergeladen werden: https://go.microsoft.com/fwlink/?linkid=2239872.

3. Microsoft Option ROM UEFI CA 2023

   • SHA-1 Cert Hash: 3FB39E2B8BD183BF9E4594E72183CA60AFCD4277.
   • Signaturinhaber GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft stellt das Zertifikat Partnern zur Verfügung und es kann entweder als EFI_CERT_X509_GUID oder als EFI_CERT_RSA2048_GUID Typsignatur hinzugefügt werden.
   • Microsoft Option ROM UEFI CA 2023 kann von hier heruntergeladen werden: https://go.microsoft.com/fwlink/?linkid=2284009.

• 1.4.2 DbDefault: Der Plattformanbieter muss in der in der Variablen dbDefault einen Standardsatz von Einträgen für die Signaturdatenbank bereitstellen. Weitere Informationen finden Sie unter Abschnitt 27.5.3 in der UEFI-Spezifikation.

• 1.4.3 Verbotene Signaturdatenbank (dbx)

  Der Inhalt von EFI_IMAGE_SIGNATURE_DATABASE1 dbx muss überprüft werden, wenn Images überprüft werden, bevor db überprüft wird, und alle Übereinstimmungen müssen verhindern, dass das Image ausgeführt wird. Die Datenbank kann mehrere Zertifikate, Schlüssel und Hashes enthalten, um verbotene Images zu identifizieren. Die Windows-Hardware-Zertifizierungsanforderungen geben an, dass ein dbx vorhanden sein muss, daher kann jeder Dummywert, z. B. der SHA-256-Hash von 0, als sicherer Platzhalter verwendet werden, bis Microsoft mit der Bereitstellung von dbx-Updates beginnt. Klicken Sie hier, um die neueste UEFI-Sperrliste von Microsoft herunterzuladen.

• 1.4.4 DbxDefault: Der Plattformanbieter kann einen Standardsatz von Einträgen für die Signaturdatenbank in der dbxDefault-Variable bereitstellen. Weitere Informationen finden Sie unter Abschnitt 27.5.3 in der UEFI-Spezifikation.

1.5 Erforderliche Schlüssel für Sicherer Start auf allen PCs

Hinweis

Geräte-OEMs, Unternehmen und Kunden finden die von Microsoft empfohlenen PK-, KEK-, DB- und DBX-Binärdateien im Microsoft Open-Source-Repository für sicheren Start. Die Binärdateien werden in das erwartete EDKII-Format formatiert, um problemlos in die Firmware integriert werden zu können.

Schlüssel/db-Name	Variable	Besitzer	Hinweise
PKpub	PK	Erstausrüster (OEM)	PK – nur 1. Muss RSA 2048 oder stärker sein. https://go.microsoft.com/fwlink/?linkid=2255361
Microsoft Corporation KEK 2K CA 2023	KEK	Microsoft	Ermöglicht Updates für db und dbx: https://go.microsoft.com/fwlink/p/?linkid=2239775.
Windows UEFI CA 2023	Datenbank	Microsoft	Diese CA in der Signaturdatenbank (db) ermöglicht es Windows, zu starten: https://go.microsoft.com/fwlink/?LinkId=2239776.
Verbotene Signaturdatenbank	dbx	Microsoft	Liste der bekannten fehlerhaften Schlüssel, ZS oder Images von Microsoft
Schlüssel für ein sicheres Firmwareupdate		Erstausrüster (OEM)	Empfehlung besteht darin, dass sich dieser Schlüssel vom PK unterscheidet

Tabelle 1: Schlüssel/db, die für Sicherer Start erforderlich sind

1.6 UEFI–Konfigurationsanforderungen für den sicheren Start für Windows 11, Version 25H2+ Geräte

OEMs müssen sicherstellen, dass die UEFI Secure Boot-Konfiguration, die auf Windows 11-, 25H2+-Geräten mit vorinstalliertem Windows bereitgestellt und ausgeliefert wird, Folgendes umfasst:

PK	OEM oder Microsoft PK
KEK	Microsoft Corporation KEK 2K CA 2023
Deutsche Bahn	Windows UEFI CA 2023
DBX	Neuestes dbx-Paket

Für Geräte, die Linux, andere UEFI-Apps von Drittanbietern unterstützen oder spezielle Hardware enthalten, die Options-ROMs erfordern, können OEMs Geräte mit dieser alternativen Konfiguration versenden:

PK	OEM oder Microsoft PK
KEK	Microsoft Corporation KEK 2K CA 2023
Deutsche Bahn	Windows UEFI CA 2023 Microsoft UEFI CA 2023 Microsoft Corporation UEFI CA 2011 Microsoft Option ROM UEFI CA 2023
DBX	Neuestes dbx-Paket

OEMs müssen das Gerät mit dem Windows UEFI CA 2023-signierten Windows-Start-Manager sowohl auf dem Gerät als auch in den mitgelieferten startbaren Medien ausliefern. Dadurch wird sichergestellt, dass das Gerät den Windows-Start-Manager verwendet, der nach Ablauf der Zertifikate von 2011 weiterhin gewartet wird.

Es wird zwar nicht empfohlen, diese Konfigurationen für Geräte zu verwenden, die mit vorinstalliertem Windows ausgeliefert werden, aber sie können genutzt werden:

• Die Microsoft Windows Production PCA 2011, die Microsoft Corporation UEFI CA 2011 und die Microsoft Corporation KEK CA 2011 können nur enthalten sein, um die Startkompatibilität mit älteren oder noch nicht aktualisierten Systemen und UEFI-Apps von Drittanbietern zu erhalten.
• Bei Bedarf kann eine OEM-UEFI-Zertifizierungsstelle in der DB für eine der oben aufgeführten Konfigurationen enthalten sein.

Informationen zu den empfohlenen Inhalten für alle UEFI-Variablen für den sicheren Start finden Sie im Open Source-Repository von Microsoft . Bei dbx-Inhalten werden Widerrufe basierend auf den Signaturzertifikaten aufgeteilt und in der KEK- und DB-Variable des Geräts angewendet.

2. Schlüsselverwaltungslösungen

Nachfolgend finden Sie einige der Metriken, die wir zum Vergleich verwendet haben.

2.1 Verwendete Metriken

Die folgenden Metriken können Ihnen helfen, einen HSM-PC basierend auf den Anforderungen der UEFI-Spezifikation 2.3.1 Errata C und Ihren Bedürfnissen auszuwählen.

Public Key-Infrastruktur (PKI)-bezogen

• Unterstützt es RSA 2048 oder höher? - Die UEFI-Spezifikation 2.3.1 Errata C empfiehlt, dass die Schlüssel RSA-2048 oder besser sind.
• Hat es die Möglichkeit, Schlüssel zu generieren und zu signieren?
• Wie viele Schlüssel können gespeichert werden? Speichert es Schlüssel auf einem HSM oder einem angeschlossenen Server?
• Authentifizierungsmethode für den Schlüsselabruf. Einige PCs unterstützen mehrere Authentifizierungsentitäten, die zum Abrufen von Schlüsseln vorhanden sind.

Preise

• Was ist der Preispunkt? HSMs können je nach verfügbaren Features von $1.500 bis $70.000 im Preis liegen.

Fertigungsumgebung

• Geschwindigkeit der Abläufe in der Fertigungshalle. Kryptoprozessoren können die Schlüsselerstellung und den Zugriff beschleunigen.
• Einfachheit der Einrichtung, Bereitstellung, Wartung.
• Qualifikation und Schulung erforderlich?
• Netzwerkzugriff für Sicherung und Hochverfügbarkeit

Standards und Einhaltung

• Welche FiPS-Einhaltungsstufe hat sie? Ist es manipulationssicher?
• Unterstützung für andere Standards, z. B. MS-Krypto-APIs.
• Erfüllt es staatliche und andere Behördenanforderungen?

Zuverlässigkeit und Notfallwiederherstellung

• Lässt es die Schlüsselsicherung zu?

  Sicherungen können sowohl vor Ort an einem sicheren Ort als auch an einem anderen physischen Standort als der CA-Computer und das HSM gespeichert werden und/oder an einem Standort außerhalb aufbewahrt werden.

• Lässt es Hochverfügbarkeit für die Notfallwiederherstellung zu?

2.2 Schlüsselverwaltungsoptionen

• 2.2.1 Hardwaresicherheitsmodul (HSM)

  Basierend auf den oben genannten Kriterien ist dies wahrscheinlich die am besten geeignete und sichere Lösung. Die meisten HSM sind FIPS 140-2 Level 3 konform. Die FIPS 140-2-Einhaltung der Ebene 3 ist streng bei der Authentifizierung und erfordert, dass Schlüssel nicht exportiert oder aus dem HSM importiert werden.

  Sie unterstützen mehrere Möglichkeiten des Schlüsselspeichers. Sie könnten lokal auf dem HSM selbst oder auf dem Server gespeichert werden, der an das HSM angefügt ist. Auf dem Server werden die Schlüssel verschlüsselt und gespeichert und sind für Lösungen vorzuziehen, die viele Schlüssel speichern müssen.

  Die Sicherheitsrichtlinie für kryptografische Module muss eine physische Sicherheitsrichtlinie angeben, einschließlich physischer Sicherheitsmechanismen, die in einem kryptografischen Modul implementiert werden, z. B. Manipulationsschutz, Sperrungen, Manipulationsantwort und Nullisierungsschalter sowie Alarme. Sie ermöglicht außerdem die Angabe von Maßnahmen, die von den Bedienern durchgeführt werden müssen, um sicherzustellen, dass die physische Sicherheit beibehalten wird, wie etwa periodische Inspektionen von Manipulationssiegeln oder Tests der Antwortmechanismen bei Manipulation und Nullisierungsschaltern.

  • 2.2.1.1 Netzwerk HSM

    Diese Lösung ist die beste in ihrer Klasse hinsichtlich Sicherheit, Einhaltung von Standards, Schlüsselgenerierung, Speicher und Abruf. Die meisten dieser PCs unterstützen Hochverfügbarkeit und haben die Möglichkeit, Schlüssel zu sichern.

    Die Kosten dieser Produkte können bei zehntausend Dollar liegen, basierend auf den zusätzlichen Diensten, die sie anbieten.

  • 2.2.1.2 Eigenständiges HSM

    Diese funktionieren hervorragend mit eigenständigen Servern. Man kann Microsoft CAPI und CNG oder eine andere sichere API verwenden, die von HSM unterstützt wird. Diese HSMs sind in verschiedenen Formfaktoren erhältlich, die USB-, PCIe- und PCMCIA-Bus unterstützen.

    Sie unterstützen optional die Schlüsselsicherung und Hochverfügbarkeit.

• 2.2.2 Benutzerdefinierte Lösungsanbieter

  Die Kryptografie für öffentliche Schlüssel kann schwierig sein und erfordert ein Verständnis von kryptografischen Konzepten, die vielleicht neu sind. Es gibt Anbieter von maßgeschneiderten Lösungen, die helfen könnten, Secure Boot in einer Fertigungsumgebung zu implementieren.

  Es gibt verschiedene benutzerdefinierte Lösungen, die von BIOS-Anbietern, HSM-Unternehmen und PKI-Beratungsunternehmen angeboten werden, um Secure Boot PKI in der Fertigungsumgebung einzurichten.

  Einige dieser Anbieter werden im Folgenden aufgeführt:

  • 2.2.2.1 BIOS-Anbieter

    Es gibt einige BIOS-Anbieter, die möglicherweise benutzerdefinierte Lösungen bereitstellen können.

  • 2.2.2.2 HSM-Anbieter

    Einige HSM-Anbieter können möglicherweise benutzerdefinierte Beratungen anbieten. Weitere Informationen finden Sie unter Generieren und Signieren von Schlüsseln für Sicherer Start mithilfe von HSM (Beispiel).

• 2.2.3 Trusted Platform Module (TPM)

  Ein Trusted Platform Module (TPM) ist ein Hardwarechip auf dem Motherboard, das kryptografische Schlüssel speichert, die für die Verschlüsselung verwendet werden. Viele Computer enthalten ein TPM, aber wenn der PC es nicht enthält, ist es nicht möglich, eins hinzuzufügen. Nach der Aktivierung kann das Trusted Platform Module die vollständigen Datenträgerverschlüsselungsprodukte wie Microsoft BitLocker-Funktionen sichern. Es hält Festplatten gesperrt oder versiegelt, bis der PC einen Systemüberprüfungs- oder Authentifizierungsprozess abgeschlossen hat.

  Das TPM kann Schlüssel generieren, speichern und schützen, die im Verschlüsselungs- und Entschlüsselungsprozess verwendet werden.

  Die Nachteile von TPMs sind, dass es möglicherweise keine schnellen Kryptoprozessoren hat, um die Verarbeitung in der Fertigungsumgebung zu beschleunigen. Sie eignen sich auch nicht zum Speichern einer großen Anzahl von Schlüsseln. Datensicherung, Hochverfügbarkeit und Standardkonformität bis zur FIPS 140-2 Ebene 3 könnten nicht verfügbar sein.

• 2.2.4 Smart Cards

  Eine Smartcard kann Schlüssel generieren und speichern. Sie geben einige Features frei, die HSM unterstützen, z. B. Authentifizierung und Manipulationsprüfung, aber sie enthalten nicht viel Schlüsselspeicher oder -sicherung. Sie erfordern manuelle Interventionen und sind möglicherweise nicht für die Automatisierung und Verwendung in der Produktionsumgebung geeignet, da die Leistung möglicherweise gering ist.

  Die Nachteile von Smartcards ähneln TPMs. Sie haben möglicherweise keine schnellen Kryptoprozessoren, um die Verarbeitung in der Fertigungsumgebung zu beschleunigen. Sie eignen sich auch nicht zum Speichern einer großen Anzahl von Schlüsseln. Datensicherung, Hochverfügbarkeit und Standardkonformität bis zur FIPS 140-2 Ebene 3 könnten nicht verfügbar sein.

• 2.2.5 Erweitertes Validierungszertifikat

  EV-Zertifikate sind Hochsicherheitszertifikate, deren private Schlüssel in Hardwaretoken gespeichert werden. Dies hilft bei der Einrichtung stärkerer Methoden für die Schlüsselverwaltung. EV-Zertifikate haben dieselben Nachteile wie Smartcards.

• 2.2.6 Softwareorientierte Ansätze (NICHT EMPFOHLEN)

  Verwenden Sie Krypto-APIs für die Schlüsselverwaltung. Dies kann das Speichern eines Schlüssels in einem Schlüsselcontainer auf einer verschlüsselten Festplatte umfassen, sowie die mögliche Nutzung einer virtuellen Maschine für zusätzliche Sandboxing- und Sicherheitszwecke.

  Diese Lösungen sind nicht so sicher wie die Verwendung eines HSM und machen einen höheren Angriffsvektor verfügbar.

  2.2.6.1 Makecert (NICHT EMPFOHLEN)

  Makecert ist ein Microsoft-Tool und kann wie folgt für die Schlüsselgenerierung verwendet werden. Um sicherzustellen, dass die Angriffsfläche minimiert wird, müssen Sie möglicherweise den PC „air-gappen“. Der PC, auf dem der PKpriv ist, sollte nicht mit dem Netzwerk verbunden sein. Es sollte sich an einem sicheren Ort befinden und idealerweise mindestens einen Smartcard-Leser verwenden, falls kein echtes HSM vorhanden ist.

  makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r
  

  Weitere Informationen finden Sie unter Zertifikaterstellungstool (Makecert.exe).

  Diese Lösung wird nicht empfohlen.

2.3 Generierung und Speicherung von Schlüsseln für den Secure Boot

• 2.3.1 Speichern privater Schlüssel

  Die Speicherplatzanforderung für jeden RSA-2048-Schlüssel beträgt 2048 Bit. Der tatsächliche Speicherort der Schlüssel hängt von der ausgewählten Lösung ab. HSM ist eine gute Möglichkeit zum Speichern von Schlüsseln.

  Die werksseitige physische Position der PCs muss ein geschützter Bereich sein, der eingeschränkten Benutzerzugriff wie einen sicheren Käfig hat.

  Je nach Ihren Anforderungen können diese Schlüssel auch an einem unterschiedlichen geografischen Standort gespeichert oder an einem anderen Ort gesichert werden.

  Die Neuschlüsselanforderungen für diese Schlüssel können je nach Kunden variieren (siehe Anhang A für die Neuschlüsselungsrichtlinien der Federal-Bridge-Zertifizierungsstelle).

  Dies könnte einmal pro Jahr erfolgen. Möglicherweise müssen Sie für bis zu 30 Jahre Zugriff auf diese Schlüssel haben (je nach den Anforderungen für die Neuschlüsselung usw.).

• 2.3.2 Abrufen der privaten Schlüssel

  Die Schlüssel müssen möglicherweise aus vielen Gründen abgerufen werden.

  1. Der PK muss möglicherweise abgerufen werden, um einen aktualisierten PK auszustellen, da er kompromittiert ist oder Regierungs-/andere Agenturbestimmungen eingehalten werden sollen.
  2. KEKpri wird verwendet, um die db und dbx zu aktualisieren.
  3. Sicherer Firmwareupdateschlüssel – pri wird verwendet, um neuere Updates zu signieren.

• 2.3.3 Authentifizierung

  Die Authentifizierung gemäß FIPS 140-2 erfolgt basierend auf der Zugriffsebene.

  Ebene 2

  Die Sicherheitsstufe 2 erfordert mindestens eine rollenbasierte Authentifizierung, in der ein kryptografisches Modul die Autorisierung eines Operators authentifiziert, um eine bestimmte Rolle zu übernehmen und eine entsprechende Gruppe von Diensten auszuführen.

  Ebene 3

  Sicherheitsstufe 3 erfordert identitätsbasierte Authentifizierungsmechanismen, die die Sicherheit verbessern, die von den rollenbasierten Authentifizierungsmechanismen bereitgestellt werden, die für Sicherheitsstufe 2 angegeben sind. Ein kryptografisches Modul authentifiziert die Identität eines Operators und überprüft, dass der identifizierte Operator berechtigt ist, eine bestimmte Rolle zu übernehmen und eine entsprechende Gruppe von Diensten auszuführen.

  PCs wie HSM unterstützen Sicherheitsstufe 3, die identitätsbasierte „k of m Authentifizierung“ erfordert. Dies bedeutet, dass k Entitäten mit einem Token Zugriff auf das HSM erhalten, aber zu einem bestimmten Zeitpunkt müssen mindestens k der m Tokens vorhanden sein, damit die Authentifizierung funktioniert und auf die privaten Schlüssel des HSM zugegriffen werden kann.

  Beispielsweise sollten 3 aus 5 Token authentifiziert werden, um auf HSM zuzugreifen. Diese Mitglieder könnten die Sicherheitsbeauftragten, Transaktionsautorisierer und/oder Mitglieder aus der Geschäftsleitung sein.

  HSM-Token

  Sie könnten eine Richtlinie auf dem HSM haben, die das Vorhandensein des Tokens erfordert.

  • Lokal

  • Fernbedient

  • Für die Automatisierung konfiguriert

  Als bewährte Methode verwenden Sie bitte eine Kombination aus Token und ein Kennwort je Token.

2.4 Sicherer Start und Drittanbietersignierung

• 2.4.1 Signieren von UEFI-Treibern

  UEFI-Treiber müssen von einer Zertifizierungsstelle oder einem Schlüssel in der db signiert werden, wie an anderer Stelle im Dokument beschrieben, oder der Hash des Treiberimages muss in der db enthalten sein. Microsoft stellt einen UEFI-Treibersignaturdienst bereit, der dem WHQL-Treibersignaturdienst mit der Microsoft UEFI CA 2023 ähnelt. Alle von dieser signierten Treiber werden nahtlos auf allen PCs ausgeführt, die die Microsoft UEFI-Zertifizierungsstelle (CA) enthalten. Es ist auch möglich, dass ein OEM vertrauenswürdige Treiber signiert und die OEM-Zertifizierungsstelle in die DB einschließt oder Hashes der Treiber in die DB einschließt. In allen Fällen wird ein UEFI-Treiber (Option ROM) nicht ausgeführt, wenn er nicht in der db vertrauenswürdig ist.

  Alle Treiber, die im System-Firmwareimage enthalten sind, müssen nicht erneut überprüft werden. Als Teil des Gesamtsystemimages wird ausreichend Gewissheit geboten, dass der Treiber auf dem PC vertrauenswürdig ist.

  Microsoft hat dies für jeden verfügbar gemacht, der UEFI-Treiber signieren möchte. Dieses Zertifikat ist Teil der Windows HCK Sicherer Start-Tests. Folgen Sie [diesem Blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/)), um mehr über die UEFI-Zertifizierungsrichtlinie und -updates zu erfahren.

• 2.4.2 Startladeprogramme

  Das Microsoft UEFI-Treibersignaturzertifikat kann zum Signieren anderer Betriebssysteme verwendet werden. Beispielsweise wird der Fedora-Linux-Bootloader von ihm signiert.

  Diese Lösung erfordert keine weiteren Zertifikate, die der Schlüssel-Db hinzugefügt werden sollen. Zusätzlich zur kostenwirksamen Nutzung kann es für jede Linux-Verteilung verwendet werden. Diese Lösung funktioniert für jede Hardware, die Windows unterstützt, sodass es für eine Vielzahl von Hardware nützlich ist.

  Das UEFI-CA kann von hier zum Herunterladen abgerufen werden: https://go.microsoft.com/fwlink/p/?LinkID=321194. Die folgenden Links verfügen über weitere Informationen zur Windows HCK UEFI-Signatur und -Übermittlung:

  • Windows Dev Center Hardware-Dashboard
  • Windows-Zertifizierungsdashboardverwaltung
  • UEFI Firmware-Signierung
  • Windows Hardware-Zertifizierungsblog: UEFI-Signatur-Zertifizierungsstellen-Update

3. Zusammenfassung und Ressourcen

Dieser Abschnitt beabsichtigt, die obigen Abschnitte zusammenzufassen und einen Schritt-nach-Schritt-Ansatz zu zeigen:

1. Richten Sie eine sichere Zertifizierungsstelle (CA) ein oder identifizieren Sie einen Partner, um Schlüssel sicher zu erzeugen und zu speichern

   Wenn Sie keine Drittanbieterlösung verwenden:

   1. Installieren und Konfigurieren der HSM-Software auf dem HSM-Server. Überprüfen Sie Ihr HSM-Referenzhandbuch für Installationsanweisungen. Der Server wird entweder mit einem eigenständigen oder Netzwerk-HSM verbunden.

      Informationen zur HSM-Konfiguration finden Sie unter Abschnitt 2.2.1, 2.3 und im Anhang C.

      Die meisten HSMs bieten FIPS 140-2-Zertifizierungen der Stufen 2 und 3. Konfigurieren Sie das HSM für die Einhaltung auf Ebene 2 oder Ebene 3. Die Einhaltung auf Ebene 3 verfügt über strengere Anforderungen rund um Authentifizierung und Schlüsselzugriff und ist daher sicherer. Ebene 3 wird empfohlen.

   2. Konfigurieren Sie HSM für Hochverfügbarkeit, Sicherung und Authentifizierung. Überprüfen Sie Ihr HSM-Referenzhandbuch.

      Folgen Sie HSM-Anbieterrichtlinien zum Einrichten von HSM für Hochverfügbarkeit und Sicherung.

      Außerdem verfügen Netzwerk-HSMs in der Regel über mehrere Netzwerkports, um Datenverkehr zu trennen; damit ein Server mit Netzwerk HSMs in einem Netzwerk kommunizieren kann, das vom regulären Produktionsnetzwerk getrennt ist.

      Sobald die Teammitglieder, die Teil des Sicherheitsteams sind, identifiziert und ihnen Token zugewiesen wurden. Sie müssen HSM-Hardware für die k-of-m-Authentifizierung einrichten.

   3. Secure Boot-Schlüssel und Zertifikatsvorgenerierung. Siehe Abschnitte 1.3 bis 1.5

      Verwenden Sie HSM-APIs, um den PK und Firmware Updateschlüssel und die Zertifikate vorab zu generieren.

      Erforderlich – PK (empfohlen 1 pro Modell), Firmware Update-Schlüssel (empfohlen 1 pro Modell), Microsoft KEK, Db, DbxNOTE: Die Microsoft KEK, db und dbx müssen nicht vom OEM generiert werden und werden für der Vollständigkeit halber erwähnt. Optional - OEM/Drittanbieter KEK db, dbx und alle anderen Schlüssel, die in OEM Db gehen würden.

2. Wenden Sie ein Windows-Image auf den PC an.

3. Installieren Sie Microsoft db und dbx. Siehe Abschnitt 1.3.6 und Anhang B – Sicherer Start-APIs.

   1. Installieren Sie die Windows UEFI CA 2023 in die Datenbank.

   2. Installieren Sie eine leere dbx, wenn Microsoft keine bereitstellt. Windows aktualisiert DBX automatisch auf das neueste DBX über Windows Update zum ersten Neustart.

   Hinweis

   Verwenden Sie PowerShell-Cmdlets, die Teil der Windows-HCK-Tests sind oder verwenden Sie Methoden, die vom BIOS-Anbieter bereitgestellt werden.

4. Microsoft KEK installieren. Siehe Abschnitt 1.3.3.

   Installieren von Microsoft KEK in der UEFI KEK-Datenbank

   Achtung

   Verwenden Sie PowerShell-Cmdlets, die Teil der Windows-HCK-Tests sind oder verwenden Sie Methoden, die vom BIOS-Anbieter bereitgestellt werden.

5. Optionaler Schritt – OEM/Drittanbieter-Komponenten für Sicherer Start. Siehe Abschnitt 1.3.4 und 1.4.

   1. Identifizieren Sie, ob Sie einen OEM/Drittanbieter-KEK, db und dbx erstellen müssen.

   2. Signieren Sie die OEM- und Drittanbieter-db und -dbx unter Verwendung der zuvor generierten OEM/Drittanbieter-KEK über die HSM API.

   3. Installieren Sie OEM/Drittanbieter KEK, db und dbx.

6. UEFI-Treibersignierung – Siehe Abschnitt 2.4.

   Wenn Add-In-Karten oder andere UEFI-Treiber/Apps/Bootloader unterstützt werden, installieren Sie Microsoft UEFI CA 2023 und Microsoft Corporation UEFI CA 2011 in UEFI db.

7. Updateschlüssel für die Firmware des sicheren Starts – Siehe Abschnitt 1.3.5.

   1. Nur Nicht-Windows-RT-PCs: Installieren Sie den öffentlichen Schlüssel des sicheren Firmware-Updates oder dessen Hash, um Speicherplatz zu sparen.

   2. Nur bei SoC müssen Sie möglicherweise eine andere Maßnahme ergreifen, z. B. den sicheren Key für Firmware-Updates programmieren: öffentlich oder dessen Hash.

8. Sicherer Start aktivieren. Siehe Anhang B – Sicherer Start-APIs.

   1. Installieren Sie den OEM/ODM PKpub (Zertifikat bevorzugt, aber Schlüssel ist okay) in den UEFI-PK ein.

   2. Registrieren Sie den PK mithilfe der Secure Boot-API. Der PC sollte jetzt für Sicherer Start aktiviert sein.

   Hinweis

   Wenn Sie den PK am Ende installieren, müssen die MS KEK, db, dbx nicht signiert werden – keine SignerInfo darf vorhanden sein. Dies ist eine Verknüpfung.

9. Testen von Sicherer Start: Führen Sie alle proprietären Tests und Windows HCK-Tests nach Anweisungen aus. Siehe Anhang B – Sicherer Start-APIs.

10. Versandplattform: Der PKpriv wird wahrscheinlich nie wieder verwendet werden, bewahren Sie ihn gut auf.

11. Wartung: Zukünftige Firmwareupdates werden sicher mit dem „privaten“ Schlüssel für Firmwareupdates mit dem Signaturdienst signiert.

3.1. Ressourcen

Whitepaper zu Sicherheitsstrategien – https://go.microsoft.com/fwlink/p/?linkid=321288

Windows HCK-Übermittlung –https://go.microsoft.com/fwlink/p/?linkid=321287

Anhang A – Checkliste für das sichere Startvorgang-PKI in der Fertigung

Nachfolgend finden Sie eine Checkliste auf hoher Ebene, die die erforderlichen Schritte zum Aktivieren von Sicherer Start auf nicht Windows RT PCs zusammenfasst.

Einrichten von Secure Boot

1. Definieren Sie die Sicherheitsstrategie (identifizieren Sie Bedrohungen, definieren Sie proaktive und reaktive Strategie) gemäß dem Whitepaper in Abschnitt 4.

2. Identifizieren Sie das Sicherheitsteam gemäß dem Whitepaper in Abschnitt 4.

3. Richten Sie eine sichere CA ein oder identifizieren Sie einen Partner (empfohlene Lösung), um Schlüssel sicher zu generieren und zu speichern.

4. Identifizieren Sie die Richtlinie, wie häufig Sie Schlüssel neu schlüsseln. Dies kann davon abhängen, ob Sie spezielle Kundenanforderungen wie Regierungen oder andere Behörden haben.

5. Verfügen Sie über einen Notfallplan, falls der Schlüssel für Sicherer Start kompromittiert ist.

6. Identifizieren Sie, wie viele PK- und andere Schlüssel sie gemäß Abschnitt 1.3.3 und 1.5 generieren.

   Dies basiert auf Kundenbasis, Schlüsselspeicherungslösung und Sicherheit von PCs.

   Sie können die Schritte 7-8 überspringen, wenn Sie die empfohlene Lösung für die Verwendung eines Drittanbieters für die Schlüsselverwaltung verwenden.

7. Beschaffen Sie Server und Hardware für die Schlüsselverwaltung. – Netzwerk oder eigenständiges HSM gemäß Abschnitt 2.2.1. Überlegen Sie, ob Sie ein oder mehrere HSMs für Hochverfügbarkeit und Ihre Schlüssel-Backup-Strategie benötigen.

8. Identifizieren Sie mindestens 3-4 Teammitglieder, die über ein Authentifizierungstoken für die Authentifizierung auf HSM verfügen.

9. Verwenden Sie HSM oder ein Drittanbieter-Tool, um Secure Boot-bezogene Schlüssel und Zertifikate vorab zu generieren. Die Schlüssel hängen vom PC-Typ ab: SoC, Windows RT oder nicht Windows RT. Weitere Informationen finden Sie in den Abschnitten 1.3 bis 1.5.

10. Füllen Sie die Firmware mit den entsprechenden Schlüsseln auf.

11. Registrieren Sie den Plattformschlüssel für Sicherer Start, um Sicherer Start zu aktivieren. In Anhang B finden Sie nähere Informationen.

12. Führen Sie alle proprietären Tests und HCK Secure Boot Tests gemäß Anweisungen aus. In Anhang B finden Sie nähere Informationen.

13. Liefern Sie den PC aus. Der PKpriv wird wahrscheinlich nie wieder verwendet, bewahren Sie ihn sicher auf.

Wartung (Firmware aktualisieren)

Möglicherweise müssen Sie die Firmware aus mehreren Gründen aktualisieren, z. B. das Aktualisieren einer UEFI-Komponente oder das Beheben einer Kompromittierung des Schlüssels von Sicherer Start oder regelmäßige Neuschlüsselung der Schlüssel von Sicherer Start.

Weitere Informationen finden Sie im Abschnitt 1.3.5 und Abschnitt 1.3.6.

Anhang B – Secure Boot-APIs

1. Sicherer Start API

   Die folgenden APIs beziehen sich auf UEFI/Sicherer Start:

   1. GetFirmwareEnvironmentVariableEx: Ruft den Wert der angegebenen Firmwareumgebungsvariable ab.

   2. SetFirmwareEnvironmentVariableEx: Legt den Wert der angegebenen Firmwareumgebungsvariable fest.

   3. GetFirmwareType: Ruft den Firmwaretyp ab.

2. Festlegen von PK

   Verwenden Sie das Cmdlet Set-SecureBootUEFI, um Sicherer Start zu aktivieren. Nachdem der Code den PK festgelegt hat, wird die Systemerzwingung von Secure Boot erst wirksam, wenn der nächste Neustart ausgeführt wird. Vor dem Neustart kann Ihr Code GetFirmwareEnvironmentVariableEx() oder das PowerShell-Cmdlet: Get-SecureBootUEFI aufrufen, um den Inhalt der Datenbanken von Sicheres Start zu bestätigen.

3. Überprüfung

   Sie können Msinfo32.exe- oder PowerShell-Cmdlets verwenden, um den Status der Variablen für Sicherer Start zu überprüfen. Es gibt keine WMI-Schnittstelle. Sie können auch testen, indem sie einen falsch signierten startbaren USB-Stick (z. B. aus dem Windows HCK Secure Boot Manual Logo Test) einstecken und überprüfen, ob er nicht gestartet werden kann.

4. Secure Boot PowerShell Cmdlets

   • Confirm-SecureBootUEFI: Ist UEFI Secure Boot „EIN“, True oder False?

     SetupMode == 0 && SecureBoot == 1

   • Set-SecureBootUEFI: Festlegen oder Anfügen authentifizierter SecureBoot UEFI-Variablen

   • Get-SecureBootUEFI: Abrufen authentifizierter SecureBoot UEFI-Variablenwerte

   • Format-SecureBootUEFI: Erstellt EFI_SIGNATURE_LISTs & EFI_VARIABLE_AUTHENTICATION_2 Serialisierungen

5. Windows HCK- und Secure Boot-Anleitungen

   Die folgenden Schritte gelten für Systemtests und Nicht-Klassen-Treiber-PC-Tests.

   1. Deaktivieren Sie die Schutzvorrichtungen des sicheren Starts.

      Geben Sie Ihre BIOS-Konfiguration ein, und deaktivieren Sie Sicherer Start.

   2. Installieren Sie die HCK-Clientsoftware.

   3. Führen Sie alle Windows HCK-Tests aus, mit Ausnahme der folgenden:

      • BitLocker TPM- und Wiederherstellungskennwort-Tests mit PCR[7]
      • BitLocker TPM und Wiederherstellungskennworttests für Arm-PCs mit Secure Boot
      • Sicherer Start – Logo-Test
      • Sicherer Start – Manueller Logo-Test

   4. Geben Sie Ihre BIOS-Konfiguration ein, aktivieren Sie Sicherer Start, und stellen Sie Sicherer Start in der Standardkonfiguration wieder her.

   5. Führen Sie die folgenden BitLocker- und Sicherer Start-Tests aus:

      • BitLocker TPM- und Wiederherstellungskennwort-Tests mit PCR[7]
      • BitLocker TPM- und Wiederherstellungskennwort-Tests für Arm-PCs mit Sicheres Booten
      • Sicherer Start – Logo-Test (automatisiert)

   6. Öffnen Sie die BIOS-Konfiguration, und deaktivieren Sie die Konfiguration des sicheren Starts. Dadurch wird der PC im Setupmodus wiederhergestellt, indem PK und andere Schlüssel gelöscht werden.

      Hinweis

      Unterstützung für das Löschen ist für x86/x64-PCs erforderlich.

   7. Führen Sie den manuellen Logo-Test für den sicheren Start aus.

      Hinweis

      Der sichere Start erfordert von Windows HCK signierte oder VeriSign-Treiber auf Nicht-Windows-RT-PCs.

6. Windows HCK Sicherer Start – Logo-Test (automatisiert)

   Dieser Test überprüft die ordnungsgemäße Standardkonfiguration von Secure Boot. Dies schließt Folgendes ein:

   • Sicherer Start ist aktiviert.
   • Der PK ist kein bekannter Test-PK.
   • KEK enthält das Produktions-Microsoft KEK.
   • db enthält die Windows-CA der Produktion.
   • dbx präsent.
   • Viele 1kB-Variablen werden erstellt/gelöscht.
   • Eine 32kB-Variable wird erstellt/gelöscht.

7. Manuelles Testordnerlayout für Windows HCK Sicherer Start

   Das manuelle Testordnerlayout für Windows HCK Secure Boot wird unten beschrieben:

   • "\Test" Ordner weist folgendes auf:

     • Fertigungs- und Wartungstest
     • Programmgesteuertes Aktivieren von Sicherer Start in der Testkonfiguration
     • Wartungstests
     • Anfügen eines Zertifikats an db, Überprüfen der Funktion
     • Anfügen eines Hashs an dbx, Überprüfen der Funktion
     • Anfügen eines Zertifikats an dbx, Überprüfung der Funktion
     • Über 600 Hashes an dbx anfügen, Größe überprüfen
     • Programmgesteuertes Ändern des PK

   • "\Generate" Ordner enthält Skripte, die Folgendes anzeigen:

     • Wie Testzertifikate erstellt wurden

     • Die Testzertifikate und private Schlüssel sind enthalten

     • Wie alle Tests erstellt wurden

     • Ändern von Zertifikaten und Hashes in signierte Pakete

     • Sie können dies selbst ausführen, Ihre eigenen Zertifikate ersetzen

   • "\certs" Ordner enthält alle Zertifikate, die Sie zum Starten von Windows benötigen:

     Hinweis

     Bitte verwenden Sie nicht die Methode, die in "ManualTests\generate\TestCerts" zum Generieren von Schlüsseln und Zertifikaten verwendet wird. Dies ist nur für Windows HCK-Testzwecke vorgesehen. Es verwendet Schlüssel, die auf dem Datenträger gespeichert werden, der sehr unsicher ist und nicht empfohlen wird. Dies ist nicht für dir Verwendung in einer Produktionsumgebung vorgesehen.

• "ManualTests\example\OutOfBox" Ordner enthält Skripts, die Sie für die Installation von Sicherer Start auf Produktions-PCs nutzen können.

  Die "ManualTests\generate\tests\subcreate_outofbox_example.ps1" zeigt, wie diese Beispiele generiert wurden und enthält „TODO“-Abschnitte, in denen ein Partner seinen PK und andere Metadaten ersetzen kann.

8. Windows HCK UEFI-Signatur und -Übermittlung

   Unter den folgenden Links finden Sie weitere Informationen:

   • Hardware-Developer-Center-Dashboard
   • UEFI Firmware-Signierung
   • Windows-Zertifizierungsdashboardverwaltung
   • Windows-Blog zur Hardware-Zertifizierung: UEFI CA-Signaturrichtlinien-Updates von Microsoft

Anhang C – Bundesbrücken-Zertifizierungsstelle Zertifikatrichtlinien-Versicherungszuordnung

1. Rudimentär

   Diese Ebene stellt den niedrigsten Grad der Sicherheit hinsichtlich der Identität des Einzelnen dar. Eine der primären Funktionen dieser Ebene besteht darin, Datenintegrität für die signierten Informationen bereitzustellen. Diese Ebene ist für Umgebungen relevant, in denen das Risiko schädlicher Aktivitäten als niedrig angesehen wird. Es eignet sich nicht für Transaktionen, die eine Authentifizierung erfordern, und ist im Allgemeinen nicht ausreichend für Transaktionen, die Vertraulichkeit erfordern, aber für die letztere verwendet werden kann, wenn Zertifikate mit höheren Sicherheitsstufen nicht verfügbar sind.

2. Grundlegend

   Diese Ebene bietet eine grundlegende Sicherheitsebene, die für Umgebungen relevant ist, bei denen Risiken und Folgen von Datenkompromittierungen vorhanden sind, aber sie nicht als wichtig gelten. Dies kann den Zugriff auf private Informationen umfassen, bei denen die Wahrscheinlichkeit des böswilligen Zugriffs nicht hoch ist. Es wird auf dieser Sicherheitsstufe angenommen, dass Benutzer nicht böswillig sind.

3. Mittel

   Diese Ebene ist für Umgebungen relevant, in denen Risiken und Folgen von Datenkompromittierungen moderat sind. Dies kann Transaktionen mit erheblichem Geldwert oder Betrugsrisiko oder den Zugriff auf private Informationen umfassen, bei denen die Wahrscheinlichkeit des böswilligen Zugriffs erheblich ist.

4. Hoch

   Diese Ebene ist für die Verwendung geeignet, wenn die Bedrohungen für Daten hoch sind oder die Folgen des Fehlers von Sicherheitsdiensten hoch sind. Dies kann sehr hochwertige Transaktionen oder hohe Betrugsrisiken umfassen.

Zugehörige Themen

Generieren und Signieren von Schlüsseln für das sichere Starten mithilfe von HSM (Beispiel)

Leitfaden zur Validierung von UEFI und Option ROM

Übersicht über den sicheren Start