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

  • Artikel

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.

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 und 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.

Gehen Sie auf dieser Seite wie folgt vor:

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 basiert auf UEFI Secure Boot in Windows 8 und höher als Teil seiner vertrauenswürdigen Startsicherheitsarchitektur, 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. Alle nicht vertrauenswürdigen Komponenten werden nicht geladen, und stattdessen löst Sicherer Start die Korrektur 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 der Plattform-Integritätsarchitektur

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 Vertrauenswürdigen Startarchitektur von Windows und seiner Einrichtung eines Stamms der Vertrauensstellung mit Sicherer Start ist der Kunde vor böswilligem Code geschützt, der im Startpfad ausgeführt wird, indem sichergestellt wird, dass nur signierter, zertifizierter „bekannter guter“ Code und Startlader 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 an Dienstanforderungen zu authentifizieren, gehören Änderungen der Datenbanken und Updates von Sicherer Start zur Plattform-Firmware.

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 Startkitangriffen führen und den Ruf der Entität beeinträchtigen, die für die Sicherheit des privaten Schlüssels verantwortlich ist.

In einem Sicherer Start 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. Stammzertifikate einer Zertifizierungsstelle (ZS) 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 ZS signiert das Zertifikat mithilfe des privaten Schlüssels. Sie stellt den entsprechenden öffentlichen Schlüssel für alle Interessierten in einem selbst signierten Stamm-ZS-Zertifikat dar.

    In Sicherer Start umfassen Zertifizierungsstellen (ZS) den OEM (oder ihre Stellvertretungen) und Microsoft. Die ZS generieren die Schlüsselpaare, die den Stamm der Vertrauensstellung bilden, und verwenden Sie dann die privaten Schlüssel, um legitime Vorgänge zu signieren, z. B. zulässige frühe Start-EFI-Module und Firmware-Wartungsanforderungen. Die entsprechenden öffentlichen Schlüssel werden in die UEFI-Firmware auf Sicherer Start-aktivierten PCs eingefügt 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 Hälfte 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:

    Stamm-CA ist selbstsigniert, andere signiert von Stamm-ZS

    Abbildung 2: Drei-Zertifikatkette

    Benutzerzertifikate werden häufig von einem anderen privaten Schlüssel signiert, z. B. einem privaten Schlüssel der ZS. Dies stellt eine Zwei-Zertifikatkette dar. Die Überprüfung, ob ein Benutzerzertifikat original ist, umfasst die Überprüfung der Signatur aus seinem Zertifikat, das den öffentlichen Schlüssel der ZS erfordert. Bevor der öffentliche Schlüssel der ZS verwendet werden kann, muss das eingeschlossene Zertifizierungsstellenzertifikat jedoch ü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 vom privaten Schlüssel der ZS signiert wird. Dies ist eine Instanz einer Drei-Zertifikatkette: Benutzerzertifikat, Vermittlerzertifikat und ZS-Zertifikat. Aber mehr als ein Vermittler kann Teil der Kette sein, sodass Zertifikatketten beliebig lang sein können.

1.3 Anforderungen für Sicherer Start-PKI

Der UEFI-definierte Stamm der Vertrauensstellung besteht aus dem Plattformschlüssel und allen Schlüsseln, die ein OEM oder ODM im Firmwarekern enthält. Vor-UEFI-Sicherheit und ein Stamm der Vertrauensstellung werden nicht vom UEFI Secure Boot-Prozess behandelt, sondern stattdessen von National Institute of Standards and Technology (NIST) und Trusted Computing Group (TCG) Publikationen, auf die in diesem Dokument verwiesen wird.

  • 1.3.1 Anforderungen für Sicherer Start

    Sie müssen die folgenden Parameter für die Implementierung von Sicherer Starts 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 Sicherer Start-bezogene Schlüssel

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

    pk, kek, db, dbx, und Firmware-Schlüssel, winrt-Schlüssel

    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 nur 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 dieser von der unmittelbaren PKpriv signiert werden, nicht mit einem privaten Schlüssel eines Zertifikats, das unter dem 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: PK legt Setup- oder Benutzermodus fest

    Abbildung 4: Diagramm „Plattformschlüsselzustand“

    1.3.3.3 PK Generierung

    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-Elemente liegt im Ermessen des Plattformbesitzers (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 der Zuordnung von Geräten mit ihrer entsprechenden PK hinzugefügt, wenn Firmwareupdates in Zukunft 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. Es gibt einen 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 Variablenupdate, das mit dem vorhandenen PK signiert ist, das den PK ersetzt oder ein Firmwareupdatepaket. Ein OEM könnte auch ein SetVariable()-Paket erstellen das nur den PK ändert und dieses mit einer einfachen Anwendung wie PowerShell verteilen. Das Firmwareupdatepaket würde vom Schlüssel für das sichere Firmwareupdate 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

    Um die dbx-Datenbank zu aktualisieren und auf diese Weise die Sperrung fehlerhafter Images zu aktivieren und um die db-Datenbank zu aktualisieren und sie so für neuere Windows-signierte Images vorzubereiten, sind die folgenden zwei Microsoft KEK-Zertifikate erforderlich.

  1. Microsoft Corporation KEK CA 2011

    • SHA-1 Cert Hash: 31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30.
    • SignatureOwner 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=321185 heruntergeladen werden.

  2. Microsoft Corporation KEK 2K CA 2023

    • SHA-1 Cert Hash: 45 9a b6 fb 5e 28 4d 27 2d 5e 3e 6a bc 8e d6 63 82 9d 63 2b.
    • SignatureOwner 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 Updateschlüssel für die Firmware von Sicherer Start Der Schlüssel zum Sicheren Firmwareupdate 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 die öffentliche Hälfte auf dem PC befindet. Sie können das Firmwareupdate auch mit einem Schlüssel signieren, der mit dem Schlüssel zum Sicheren Firmwareupdate-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 Firmwareupdates (oder sein Hash zum Sparen von Speicherplatz) würde in einem geschützten Speicher auf der Plattform gespeichert – im Allgemeinen geschützter Flash (PC) oder einmaliger programmierbarer Fuses (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 sehen Sie den Ablauf von Ereignissen 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 Kapselimage und die Aktualisierung durch das BIOS

  • 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 Betriebssystem-Ladeprogrammerkennung 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.

    Damit das Windows-Betriebssystemladeprogramm geladen werden kann, muss die Datenbank die folgenden zwei Zertifikate enthalten:

  1. Microsoft Windows Production PCA 2011

    • SHA-1 Cert Hash: 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d.
    • SignatureOwner 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 Production PCA 2011 kann hier heruntergeladen werden: https://go.microsoft.com/fwlink/p/?linkid=321192.

  2. Windows UEFI CA 2023

    • SHA-1 Cert Hash: 45 a0 fa 32 60 47 73 c8 24 33 c3 b7 d5 9e 74 66 b3 ac 0c 67.
    • SignatureOwner 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 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: 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3.
    • SignatureOwner 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: b5 ee b4 a6 70 60 48 07 3f 0e d2 96 e7 f5 80 a7 90 b5 9e aa.
    • SignatureOwner 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.

  • 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. Der Windows-Zertifizierungsanforderungenstatus gibt 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

OEM

PK – nur 1. Muss RSA 2048 oder stärker sein.

https://go.microsoft.com/fwlink/?linkid=2255361

Microsoft Corporation KEK CA 2011

Microsoft Corporation KEK 2K CA 2023

KEK

Microsoft

Ermöglicht Updates für db und dbx:

https://go.microsoft.com/fwlink/p/?linkid=321185

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Microsoft Windows Production CA 2011

Windows UEFI CA 2023

db

Microsoft

Diese CA in der Signaturdatenbank (db) ermöglicht Windows den Start: https://go.microsoft.com/fwlink/?LinkId=321192.

https://go.microsoft.com/fwlink/p/?linkid=2239776.

Verbotene Signaturdatenbank

dbx

Microsoft

Liste der bekannten fehlerhaften Schlüssel, ZS oder Images von Microsoft

Schlüssel für ein sicheres Firmwareupdate

OEM

Empfehlung besteht darin, dass sich dieser Schlüssel vom PK unterscheidet

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

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.

  • Unterstützt es RSA 2048 oder höher? - Die UEFI-Spezifikation 2.3.1 Errata C empfiehlt das Schlüssel RSA-2048 oder stärker sind.
  • Hat es die Möglichkeit, Schlüssel zu generieren und zu signieren?
  • Wie viele Schlüssel können gespeichert werden? Speichert Schlüssel auf HSM oder einem angefügten 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 des werksseitigen Vorgangs. 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 lokal als auch an einem sicheren Ort gespeichert werden, der einen anderen physischen Speicherort als der ZS-Computer und HSM und/oder an einem Standort vor Ort darstellt.

  • 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 verfügen über FIPS 140-2 Einhaltung der Ebene 3. 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 Aktionen, die vom Betreiber erforderlich sind, um sicherzustellen, dass die physische Sicherheit beibehalten wird, z. B. regelmäßige Überprüfung von Siegeln der Manipulationserkennung oder Tests der Manipulationsantwort und Nullisierungsschalter.

    • 2.2.1.1 Network 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 Standalone 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 benutzerdefinierte Lösungsanbieter, die helfen könnten, Sicherer Start für die Arbeit in der Fertigungsumgebung zu erhalten.

    Es gibt Verschiedene benutzerdefinierte Lösungen, die von BIOS-Anbietern, HSM-Unternehmen und PKI-Beratungsunternehmen angeboten werden, um Sicherer Start PKI in der Fertigungsumgebung zu erhalten.

    Einige dieser Anbieter werden im Folgenden aufgeführt:

  • 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. Sicherung und Hochverfügbarkeit und Einhaltung von Standards bis FIPS 140-2 Ebene 3 sind möglicherweise nicht verfügbar.

  • 2.2.4 Smartcards

    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. Sicherung und Hochverfügbarkeit und Einhaltung von Standards bis FIPS 140-2 Ebene 3 sind möglicherweise nicht verfügbar.

  • 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 und möglich sein, um zusätzliche Sandkasten und Sicherheit auf einem virtuellen Computer zu verwenden.

    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 für den PC ein „Air Gap“ erstellen. 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 Smartcardleser verwenden, wenn kein echtes HSM.

    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 Generieren uns Speichern von Schlüsseln für Sicherer Start

  • 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

    Je nach FIPS 140-2-Authentifizierung 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 Zugriff auf das HSM mit einem Token erhalten, aber mindestens k aus den m-Token müssen für die Authentifizierung vorhanden sein, um Zugriff auf private Schlüssel von HSM zu erhalten.

    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 Tokens

    Sie könnten eine Richtlinie auf dem HSM haben, die das Token zur Verfügung stellen muss:

    • Lokal

    • Remote

    • Für die Automatisierung konfiguriert

    Als bewährte Methode verwenden Sie bitte eine Kombination aus Token und pro Tokenkennwort.

2.4 Sicherer Start und Drittanbietersignierung

  • 2.4.1 Signieren von UEFI-Treibern

    UEFI-Treiber müssen von einer ZS oder einem Schlüssel in der db signiert werden, wie im Dokument beschrieben, oder der Hash des Treiberimages in db enthalten ist. Microsoft stellt einen UEFI-Treibersignaturdienst bereit, der dem WHQL-Treibersignaturdienst mit dem Microsoft Corporation UEFI CA 2011 ähnelt. Alle von diesem signierten Treiber werden nahtlos auf allen PCs ausgeführt, die die Microsoft UEFI-ZS enthalten. Es ist auch möglich, dass ein OEM vertrauenswürdige Treiber anmeldet und die OEM-ZS in der 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. Im Rahmen des Gesamtsystemimages ist ausreichend sicher, 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 das Fedora Linux-Startladeprogramm von davon 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-ZS kann von hier heruntergeladen werden: https://go.microsoft.com/fwlink/p/?LinkID=321194. Die folgenden Links verfügen über weitere Informationen zur Windows HCK UEFI-Signatur und -Übermittlung:

3. Zusammenfassung und Ressourcen

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

  1. Einrichten einer sicheren ZS oder Identifizieren eines Partners zum sicheren Generieren und Speichern von Schlüsseln

    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 Einhaltung auf Ebene 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.

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

    3. Schlüssel von Sicherer Start und Zertifikatvorgenerierung. 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 den Microsoft Windows Production PCA 2011 in db.

    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. Installieren von Microsoft KEK. 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 OEM/Drittanbieter db und dbx mit OEM/Drittanbieter KEK (zuvor generiert) mithilfe der 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 Corporation UEFI CA 2011 in UEFI db.

  7. Updateschlüssel für Sicherer Start-Firmware – Siehe Abschnitt 1.3.5.

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

    2. Nur auf SoC müssen Sie möglicherweise etwas anderes tun, z. B. den Schlüssel zum Sichern des Firmwareupdates: öffentlich oder deren 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.

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

    Hinweis

    Wenn Sie den PK am Ende installieren, muss die MS KEK, db, dbx nicht signiert werden – es muss keine SignerInfo 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. Plattform versenden: Der PKpriv wird wahrscheinlich nie wieder verwendet, bewahren Sie ihn sicher 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 – Sicherer Start-PKI-Checkliste für die Herstellung

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 Sicherer Start

  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 einen sicheren ZS oder Identifizieren Sie einen Partner (empfohlene Lösung) zum sicheren Generieren und Speichern von Schlüsseln ein.

  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-Sicherungsstrategie 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 Drittanbieter, um Sicherer Start-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 – Sicherer Start-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 deb PK festgelegt hat, wird die Systemerzwingung von Sicherer Start 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. Sicherer Start 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 Sicherer Start-Anweisungen

    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 Wiederherstellungskennwort-Tests für Arm-PCs mit Sicherer Start
      • 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 Sicherer Start
      • 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

      Sicherer Start erfordert 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 Konfiguration von Sicherer Start. Dies schließt Folgendes ein:

    • Sicherer Start ist aktiviert.
    • Der PK ist kein Bekannter, Test-PK.
    • KEK enthält die Produktion von Microsoft KEK.
    • db enthält die Produktions-Windows-ZS.
    • dbx vorhanden.
    • 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 Sicherer Start 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 db, Überprüfen der Funktion
      • Anfügen von mehr als 600 Hashes an dbx, Überprüfen der Größe
      • 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" veranschaulicht, wie diese Beispiele generiert wurden und verfügt über „TODO“-Abschnitte, wenn ein Partner seinen PK und andere Metadaten ersetzen kann.

  1. Windows HCK UEFI-Signatur und -Übermittlung

    Unter den folgenden Links finden Sie weitere Informationen:

Anhang C – Zertifizierungsstelle für Federal Bridge-Zertifikatrichtlinie Sicherheitszuordnung

  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.

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

Leitfaden für die UEFI- und Option ROM-Überprüfung

Übersicht über den sicheren Start