Freigeben über

Spezifikation zur Prüfbarkeit der Hardwaresicherheit

  • Artikel

Einführung

HSTI schützt vor der Fehlkonfiguration von Sicherheitsfunktionen auf Windows-Geräten. Für Kunden bietet HSTI die Gewissheit, dass das von ihnen gekaufte Gerät standardmäßig sicher ist. Für IHVs und IBVs sorgt HSTI dafür, dass Ihre Sicherheitszusagen eingehalten werden. OEMs und ODMs können auf einfache Weise sicherstellen, dass die von Ihnen ausgelieferten Systeme sicher konfiguriert sind und sicher bleiben, ohne dass Sie eigene Lösungen entwickeln müssen.

Die Ergebnisse der HSTI-Tests werden von den Windows-Kompatibilitätstests verwendet und können verwendet werden, um zu überprüfen, ob die Geräte richtig konfiguriert wurden, um die unterstützten Sicherheitsfunktionen zu aktivieren. Diese Tests können verwendet werden, um ungesicherte technische Geräte im Feld zu identifizieren, z. B. technische Geräte, die unsichere Testschlüssel enthalten könnten. Die Ergebnisse dieser Tests können vom Windows-Betriebssystem verwendet werden, um auf unsicheren Geräten ein Wasserzeichen (oder einen ähnlichen Hinweis) anzuzeigen.

Hinweis

  Die Plattform muss eine Hardwareschnittstelle implementieren und die Dokumentation und Tools, wie in diesem Thema beschrieben, gemeinsam nutzen.

Hintergrund

Es wird erwartet, dass der Leser die Grundlagen von UEFI kennt und ein Verständnis für SecureBoot-Technologien hat, einschließlich Abschnitt 27 „Sicherheit“ der UEFI-Spezifikation und NIST SP 800-147.

Diese Anforderung weist drei Aspekte auf:

  • Plattformunabhängige Schnittstellen zur Abfrage des Sicherheitsstatus von Hardware und Firmware
  • Entwurf und optionale Codeüberprüfung der oben genannten Schnittstellenimplementierungen
  • Gemeinsame Nutzung von Dokumentation und Tools

Hochwertige Implementierung

Das Bitfeld

Die IHV definiert ein Bitfeld, das die testbaren Sicherheitsmerkmale der Plattform darstellt. Dieses Bitfeld deckt alle definierbaren Bits ab, die für die HSTI-Objekte verfügbar sind, die von den IHV-, IBV- oder OEM-HSTI-Tests zurückgegeben werden. Der IHV-Implementierer muss die Definition des Bitfelds entwerfen und eine entsprechende Dokumentation bereitstellen, damit die IBVs die Ergebnisse ihrer HSTI-Tests korrekt zurückgeben können.

SecurityFeaturesRequired

Das Feld „SecurityFeaturesRequired“ wird nur bei der Verarbeitung verwendet, wenn ein Feld in einem IHV HSTI-Objekt verwendet wird und die Methode ist, durch die der IHV das Bitfeld der erforderlichen Sicherheitsfeatures definiert.

SecurityFeaturesImplemented

Dies ist ein Bitfeld der Sicherheitsmerkmale, die von den Tests implementiert werden, die das HSTI-Objekt zurückgeben.

SecurityFeaturesVerified

Dies ist ein Bitfeld mit den Sicherheitsmerkmalen, die durch die Tests, die das HSTI-Objekt zurückgeben, überprüft wurden.

Richtlinien zur Implementierung

Die IHV wird Referenz-Sicherheitsentwürfe für ihre Plattformen entwickeln, die den Windows-Kompatibilitätsanforderungen entsprechen. Darüber hinaus implementieren IHVs und IBVs auch programmatische Tests, die die ordnungsgemäße Aktivierung der Referenzsicherheitsimplementierungen überprüfen und die Ergebnisse über die Schnittstelle des Hardware-Sicherheitstest melden. Diese Tests werden an OEMs-ODMs & als kompilierte Module (nicht Quelle) bereitgestellt und sollten ohne Änderung funktionieren. Wenn ein OEM/ODM von den Referenz-Sicherheitsentwürfe abweicht, können diese Testmodule Fehler melden. Der OEM/ODM muss sich dann an Microsoft wenden, um die Änderungen zu überprüfen und eine zusätzliche HSTI-Instanz zu implementieren, die diese Ausnahmen meldet. OEMs sollten in der Lage sein, diese Sicherheitsmodule ohne Änderungen zu nutzen, indem sie den Referenzentwurf und die Dokumentation befolgen. OEMs, die zusätzliche Sicherheitsmodule hinzufügen oder das Verhalten eines Sicherheitsmoduls ändern möchten, müssen sich einer Entwurfsprüfung durch Microsoft unterziehen.

Als Teil der Implementierung von Tests werden die Modul-Implementierer eine Struktur enthalten. Ein Prototyp dieser Struktur ist unten im „Abschnitt Prototyp“ enthalten. Die IHV wird die Bedeutung der einzelnen Bits in der Checkliste der Sicherheitsverweise definieren. In der IHV wird die Bedeutung der einzelnen Bits in den Bitfeldern näher definiert. Schließlich fügt die IHV ein Bitfeld „Erforderlich“ in die OEM-Struktur ein, und für alle Anforderungen, die sie programmgesteuert testen kann, setzt sie ein Bit im Bitfeld „Implementiert“.

IBVs und OEMs können Bits im Feld „Implementiert“ festlegen, wenn sie Microsoft einen Entwurf zur programmgesteuerten Überprüfung des Vorhandenseins der durch diese Bits repräsentierten Sicherheitsmerkmale vorgelegt haben. Wenn diese Tests erfolgreich sind, können sie das Feld „Geprüft" in die jeweiligen Strukturen einsetzen.

Die Testmodule für IHV, IBV und OEM müssen ausgeführt werden, falls vorhanden. Der Wert „true“, der auf ein Bit im Feld SecurityFeaturesEnabled angewendet wird, zeigt ein erfolgreiches Testergebnis an. Wenn ein Test nicht durchgeführt wird oder nicht erfolgreich ist, wird für das repräsentative Bit der Wert 0 festgelegt.

Beispiel für Logik der Ergebnisverarbeitung

Dieses Beispiel ist repräsentativ für die Logik, die von der Ergebnisverarbeitung verwendet wird. Implementierte Bitfelder müssen dem Format entsprechen, dass eine 1 für implementiert und eine 0 für nicht implementiert steht. Wenn etwas implementiert wird, ist dies erforderlich. Die Ergebnis-Bitfelder müssen dem Format entsprechen, dass eine 0 für „fehlgeschlagen“ oder „Test nicht verfügbar“ und eine 1 für „erfolgreich“ steht.

Nachdem alle Ergebnisse berechnet wurden, wird das Bitfeld IHV Results mit dem Bitfeld Required verknüpft (NXORd). Alle Nicht-IHV-Ergebnis-Bitfelder werden mit ihren jeweiligen Implementiert-Bitfeldern verknüpft (AND). Die sich daraus ergebenden Bitfelder werden alle miteinander verbunden (OR), um das Gesamtergebnis zu erhalten. Ein erfolgreiches Ergebnis dieser Operation ist ein Bitfeld, das ausschließlich aus 1en besteht.

Ergebnisse und Eigentum

Unabhängige Hardware-Anbieter (IHVs) und unabhängige BIOS-Anbieter (IBVs)

Silizium-Lieferanten und IBVs, die verbundene Standby-Systeme unterstützen, müssen die plattformunabhängigen Schnittstellen zur Abfrage des jeweiligen Hardware- und Firmware-Sicherheitsstatus ihrer Referenzplattformen implementieren. Diese Implementierungen müssen als kompilierte Module bereitgestellt werden. Es ist empfehlenswert, dass diese Module signiert sind und eine Signaturprüfung durchgeführt wird, wenn sie ausgeführt werden. Der Zweck besteht darin, die Hardware- und Firmware-Entwürfe & abzufragen, um die ordnungsgemäße Sicherheitsbereitstellung der Plattform zu melden.

OEMs und ODMs

OEMs und ODMs dürfen die HSTI-Tests, die ihnen von den Anbietern zur Verfügung gestellt wurden, nicht verändern oder verfälschen. OEMs und ODMs müssen garantieren, dass ihre Systeme die HSTI-Tests als Bestandteil der Windows-Zertifizierungsanforderungen bestehen werden:

Windows Hardware-Zertifizierungsanforderung – Windows 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby

Wenn ein OEM von einer Methode verlangt, eine alternative Methode bereitzustellen, die die gleiche oder eine bessere Sicherheit bietet, kann er anstelle einer Änderung zusätzliche Sicherheitsüberprüfungen durchführen. OEM-Sicherheitsprüfungen müssen mindestens einen IHV- oder IBV-Sicherheitstest vollständig abdecken. OEMs müssen sich vor der Verwendung einer Entwurfsprüfung durch Microsoft unterziehen und unterliegen den gleichen Anforderungen an die Dokumentation und die Offenlegung der Tools wie andere HSTI-Testanbieter. Nach Genehmigung durch Microsoft kann der OEM Sicherheitstests einbauen, die über die IHV- und IBV-Tests hinausgehen.

Beachten Sie, dass eine OEM-Bescheinigung als Teil des HSTI-Entwurfs nicht erforderlich ist. HSTI ist keine Liste von Anforderungen an OEMs, sondern eine Schnittstelle, die effektive programmatische Sicherheitstests von Firmware, Hardware und Konfigurationsparametern gewährleistet.

Schnittstellen für den Sicherheitsstatus

Die Schnittstellen basieren auf dem EFI Adapter Information Protocol, das in UEFI Version 2.4 definiert ist.

Schnittstellen für den Sicherheitsstatus der Plattform

Zusammenfassung

Sicherheitsinformationen der Plattform – Liefert Informationen über die Konformität der Plattform mit der Windows Hardware-Zertifizierungsanforderung System.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby und System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Prototyp

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

Entsprechender InformationBlock:

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
Begriff Beschreibung

Version

Return PLATFORM_SECURITY_VERSION_VNEXTCS

Rolle

Die Rolle des Herausgebers dieser Schnittstelle. Von Entwicklern von Referenzplattformen wie IHVs und IBVs wird erwartet, dass sie PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE bzw. PLATFORM_SECURITY_ROLE_PLATFORM_IBV zurückgeben. Wenn die Testmodule der Entwickler nicht in der Lage sind, alle Sicherheitsmerkmale vollständig zu überprüfen, müssen die Implementierer der Plattform, OEMs und ODMs, diese Schnittstelle mit der Rolle des Implementierers veröffentlichen.

ImplementationID

Von Menschen lesbarer Hersteller, Modell, & Version dieser Implementierung. Zum Beispiel „SiliconVendorX Chip1234 v1“ und „BIOSvendorY BIOSz v2“.

SecurityFeaturesSize

Die Größe der Arrays SecurityFeaturesRequired und SecurityFeaturesEnabled in Bytes. Die Arrays müssen dieselbe Größe aufweisen.

SecurityFeaturesRequired

IHV-definiertes Bitfeld, das allen Sicherheitsmerkmalen entspricht, die implementiert werden müssen, um die durch die entsprechende Version der PLATFORM_SECURITY_VERSION definierten Sicherheitsanforderungen zu erfüllen. Wenn zum Beispiel 7 Funktionen implementiert werden müssen, um die Version zu erfüllen, könnte ein Wert von 0b01111111 gemeldet werden.

SecurityFeaturesImplemented

Vom Herausgeber definiertes Bitfeld, das allen Sicherheitsmerkmalen entspricht, die in diesem Modul programmatische Tests implementiert haben.

SecurityFeaturesVerified

Vom Herausgeber definiertes Bitfeld, das allen Sicherheitsmerkmalen entspricht, deren Implementierung durch diese Implementierung verifiziert wurde.

ErrorString

Eine Null-terminierte Zeichenkette, ein Fehler pro Zeile (CR/LF-terminiert), mit einer eindeutigen Kennung, die der OEM/ODM verwenden kann, um die Dokumentation zu finden, in der die Schritte zur Behebung des Fehlers beschrieben werden – eine URL zur Dokumentation wird empfohlen. Beispiel:

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

Überlegungen zur Speicherverwaltung

Aus Gründen der Kompatibilität zwischen HSTI-Modulen sollten Implementierer AllocatePool() und nicht AllocatePages() verwenden.

Entwurfsprüfung der HSTI-Implementierung

Microsoft führt vorläufige Entwurfsprüfungen aller Implementierungen von Testschnittstellen durch. Beispiele für Fragen, die bei einer Entwurfsprüfung gestellt werden können, finden Sie im Abschnitt Überlegungen zum HSTI-Entwurf.

Optionale Code-Überprüfungen

HSTI-Implementierer können Code-Überprüfungen von Microsoft anfordern. Code-Überprüfungen können je nach Priorität und Verfügbarkeit von Ressourcen durchgeführt werden und sind nicht garantiert. Die Code-Überprüfung erfolgt im Rahmen einer Geheimhaltungsvereinbarung.

Gemeinsame Nutzung von Dokumentation und Tools

Silizium- und Firmware-Lieferanten sollten Microsoft alle notwendigen sicherheitsrelevanten Referenzdokumentationen und Tools zur Verfügung stellen, die sie auch den OEMs zur Verfügung stellen. Diese Dokumentationen und Tools sollten spätestens dann zur Verfügung gestellt werden, wenn sie den Windows-OEMs zur Verfügung gestellt werden. Dazu gehören u.a. alle Dokumentationen und Tools im Zusammenhang mit der Fusion, Installation und Aktualisierung der Firmware, Firmware- und Boot-Wiederherstellung, Hardware-Diagnose, Firmware-Diagnose, & Boot-Diagnose. Die zur Verfügung gestellten Dokumentationen und Tools sollten völlig ausreichen, um HSTI-Prüfungen in einer Laborumgebung durchzuführen.

Überlegungen zum HSTI-Entwurf

Im Folgenden finden Sie eine illustrative Liste von Überlegungen zum Entwurf, die ein HSTI-Implementierer für seine HSTI-Implementierung berücksichtigen muss. Dies ist weder eine strikt zu befolgende Liste von Anforderungen noch eine abschließende Aufzählung von Überlegungen. Als HSTI-Implementierer werden Sie Tests schreiben, um die Sicherheitsfunktionen zu validieren, die Sie so umfassend wie möglich abdecken wollen. Wir empfehlen Ihnen, diese Liste vor Ihrer Entwurfsprüfung durch Microsoft durchzugehen, um sich Anregungen zu holen. Und bedenken Sie, dass Microsoft wahrscheinlich möchte, dass Sie diese Funktionen so umfassend wie möglich testen, bevor Sie sie implementieren.

Silizium-Lieferanten/Anbieter (IHV) HSTI-Prüfungen

  1. Verwenden Sie nur RSA 2048 und SHA256 (oder ähnliche Verschlüsselungen)
  2. Firmware-Code muss im geschützten Speicher vorhanden sein
    1. Schützen Sie Spiflash?
    2. Halten Sie eMMC-Partitionen bis zum Zurücksetzen schreibgeschützt
    3. Wird signierte Firmwareprüfung unterstützt – Firmware, die von OEMs installiert wird, ist entweder schreibgeschützt oder durch einen sicheren Firmware-Update-Prozess geschützt.
  3. Prozess für ein sicheres Firmwareupdate
    1. Ist der Prozess des sicheren Firmware-Updates mit Testschlüsseln standardmäßig aktiviert? (EMPFOHLEN)
    2. Haben Sie überprüft, ob Testschlüssel in der Produktion verwendet werden?
    3. Erlauben Sie ein Zurückgehen auf eine unsichere Firmware-Version? Wenn ja, was ist der Schutzmechanismus? Wird das TPM gelöscht, wenn ein Zurückgehen erfolgt?
  4. Haben Sie eine Hintertür, um SecureBoot außer Kraft zu setzen
    1. Unterstützt Ihr System die Inline-Eingabeaufforderung zur Umgehung von SecureBoot? Wenn ja, ist es deaktiviert, während SecureBoot aktiviert ist?
    2. Verfügen Sie über eine Hintertür für die Herstellung? Prüfen Sie, ob sie deaktiviert sind, während SecureBoot aktiviert ist, und ob sie im Produktionssystem immer deaktiviert sind?
  5. [CS]Unterstützung der Boot-Integrität
    1. Unterstützen Sie Boot-Integrität und ist sie standardmäßig aktiviert?
    2. Die Plattform verwendet On-Die-ROM oder One-Time Programmable (OTP) Speicher zur Speicherung des anfänglichen Boot-Codes und bietet eine Power-On-Neustart-Logik zur Ausführung aus dem On-Die-ROM oder dem sicheren On-Die-SRAM.
  6. [CS]Schutz vor internem und externem DMA
    1. Lassen Sie das interne DMA nur für Komponenten aktiviert, die während des Startvorgangs benötigt werden? Und ist es für alle anderen Komponenten deaktiviert?
    2. Lassen Sie externes DMA nur für Komponenten aktiviert, die während des Startvorgangs benötigt werden? Und ist es für alle anderen Komponenten deaktiviert?
    3. Wenn die Firmware über eine Option zum Aktivieren und Deaktivieren des DMA-Schutzes verfügt, muss der DMA-Schutz in der Auslieferungskonfiguration standardmäßig aktiviert sein
    4. Welche Busse/Geräte (Sicherungen, Sicherheitssysteme, TZ, Video, Caches, IMEM, Kernel-Speicher) sind in der Lage, per DMA auf verschiedene permanente und sprunghafte Speicherregionen zuzugreifen und wie werden sie geschützt?
    5. Unterstützen Sie die Implementierung von MOR-Bit
  7. Schutz vor externem Hardware-Debugger
    1. Unterstützen Sie JTAG? Steht JTAG auf OFF, wenn SecureBoot auf ON steht
    2. Bieten Sie eine Hintertür für die Herstellung an, um den JTAG-Schutz zu deaktivieren? Überprüfen Sie, ob diese Hintertür in Produktionssystemen nicht vorhanden ist?
    3. Wird das TPM gelöscht, wenn JTAG aktiviert ist?
    4. Unterstützen Sie einen anderen Hardware-Debugger? Führen Sie dafür die gleichen Überprüfungen durch?
  8. Haben Sie das eindeutige Geheimnis für jedes Gerät korrekt bereitgestellt?
  9. Welche Sicherungen haben Sie (herstellerspezifisch)
    1. SOC SecureBoot Sicherung
    2. Eindeutige Geheimnisse pro Gerät, wie z. B. Sicherungen zur Bestätigung oder Verschlüsselung
    3. JTAG-Sicherungen
    4. SOC Apps-Prozessor SecureBoot Sicherungen
    5. SOC MBA-Prozessor SecureBoot Sicherungen
    6. SOC Moderner Prozessor SecureBoot Sicherungen
    7. Alle weiteren spezifischen Sicherungen für Ihre Plattform im SOC

IBV HSTI-Überprüfungen

  1. Verwenden Sie nur RSA 2048 und SHA256 (oder höher, aber nicht niedriger als dies)
  2. Module zur Unterstützung der Kompatibilität (Compatibility Support Modules, CSM)
    1. Bieten Sie die Möglichkeit, CSM zu aktivieren?
    2. Prüfen Sie die Blockierung des CSM-Ladevorgangs, wenn SecureBoot aktiviert ist
    3. [CS]Prüfen Sie, ob CSM auf CS-Systemen dauerhaft nicht vorhanden ist
  3. Firmware-Code muss im geschützten Speicher vorhanden sein
    1. Schützen Sie Spiflash?
    2. Halten Sie eMMC-Partitionen bis zum Zurücksetzen schreibgeschützt
    3. Wird signierte Firmwareprüfung unterstützt – Firmware, die von OEMs installiert wird, ist entweder schreibgeschützt oder durch einen sicheren Firmware-Update-Prozess geschützt.
  4. Prozess für ein sicheres Firmwareupdate
    1. Ist der Prozess des sicheren Firmware-Updates mit Testschlüsseln standardmäßig aktiviert?
    2. Haben Sie überprüft, ob Testschlüssel in der Produktion verwendet werden?
    3. Erlauben Sie ein Zurückgehen auf eine unsichere Firmware-Version? Wenn ja, was ist der Schutzmechanismus? Wird das TPM gelöscht, wenn ein Zurückgehen erfolgt?
    4. Werden Testschlüssel verwendet?
  5. Haben Sie eine Hintertür, um SecureBoot außer Kraft zu setzen
    1. Unterstützt Ihr System die Inline-Eingabeaufforderung zur Umgehung von SecureBoot? Wenn ja, ist es deaktiviert, während SecureBoot aktiviert ist?
    2. Verfügen Sie über eine Hintertür für die Herstellung? Prüfen Sie, ob sie deaktiviert sind, während SecureBoot aktiviert ist, und ob sie im Produktionssystem immer deaktiviert sind?
  6. [CS]Schutz vor internem und externem DMA
    1. Lassen Sie das interne DMA nur für Komponenten aktiviert, die während des Startvorgangs benötigt werden? Und ist es für alle anderen Komponenten deaktiviert?
    2. Lassen Sie externes DMA nur für Komponenten aktiviert, die während des Startvorgangs benötigt werden? Und ist es für alle anderen Komponenten deaktiviert?
    3. Wenn die Firmware über eine Option zum Aktivieren und Deaktivieren des DMA-Schutzes verfügt, muss der DMA-Schutz in der Auslieferungskonfiguration standardmäßig aktiviert sein
    4. Welche Busse/Geräte (Sicherungen, Sicherheitssysteme, TZ, Video, Caches, IMEM, Kernel-Speicher) sind in der Lage, per DMA auf verschiedene permanente und sprunghafte Speicherregionen zuzugreifen und wie werden sie geschützt?
    5. Unterstützen Sie die Implementierung von MOR-Bit