Freigeben über

System Guard: Wie ein hardwarebasierter Vertrauensstamm Windows schützt

Um kritische Ressourcen wie den Windows-Authentifizierungsstapel, SSO-Token, den biometrischen Windows Hello-Stapel und das Virtual Trusted Platform-Modul zu schützen, müssen Firmware und Hardware eines Systems vertrauenswürdig sein.

System Guard organisiert die vorhandenen Windows-Systemintegritätsfeatures unter einem Dach neu und richtet die nächsten Investitionen in die Windows-Sicherheit ein. Es wurde entwickelt, um folgende Sicherheitsgarantien zu gewährleisten:

  • Schützen und Aufrechterhalten der Integrität des Systems beim Starten
  • Überprüfen, ob die Systemintegrität durch lokalen und Remotenachweis tatsächlich aufrechterhalten wurde

Beibehalten der Integrität des Systems beim Starten

Static Root of Trust for Measurement (SRTM)

Mit Windows 7 war eine der Mittel, mit denen Angreifer die Erkennung beibehalten und umgehen würden, die Installation eines häufig als Bootkits oder Rootkit bezeichneten Systems. Diese Schadsoftware wurde gestartet, bevor Windows gestartet wurde, oder während des Startvorgangs selbst, sodass sie mit der höchsten Berechtigungsstufe beginnen kann.

Wenn Windows 10 auf moderner Hardware ausgeführt wird, stellt ein hardwarebasierter Vertrauensstamm sicher, dass keine nicht autorisierte Firmware oder Software (z. B. ein Bootkit) vor dem Windows-Startladeprogramm gestartet werden kann. Dieser hardwarebasierte Vertrauensstamm stammt aus dem Feature "Sicherer Start" des Geräts, das Teil der Unified Extensible Firmware Interface (UEFI) ist. Diese Technik zur Messung der statischen UEFI-Komponenten für den frühen Start wird als Static Root of Trust for Measurement (SRTM) bezeichnet.

Da es Tausende von PC-Anbietern gibt, die viele Modelle mit verschiedenen UEFI-BIOS-Versionen produzieren, wird beim Start eine unglaublich große Anzahl von SRTM-Messungen. Es gibt zwei Verfahren, um vertrauen zu können: entweder eine Liste der bekannten "schlechten" SRTM-Messungen (auch als Blockliste bezeichnet) oder eine Liste der bekannten "guten" SRTM-Messungen (auch als Positivliste bezeichnet).

Jede Option hat einen Nachteil:

  • Eine Liste der bekannten "schlechten" SRTM-Messungen ermöglicht es einem Hacker, nur 1 Bit in einer Komponente zu ändern, um einen völlig neuen SRTM-Hash zu erstellen, der aufgelistet werden muss. Dies bedeutet, dass der SRTM-Fluss von Natur aus spröde ist - eine geringfügige Änderung kann die gesamte Vertrauenskette für ungültig erklären.
  • Eine Liste der bekannten "guten" SRTM-Messungen erfordert, dass jede neue BIOS/PC-Kombinationsmessung sorgfältig hinzugefügt wird, was langsam ist. Außerdem kann das Entwerfen, Erstellen, Erneutes Testen, Überprüfen und erneutes Bereitstellen einer Fehlerbehebung für UEFI-Code sehr lange dauern.

Sicherer Start – der dynamische Vertrauensstamm für die Messung (DRTM)

System Guard Secure Launch, das erstmals in Windows 10 Version 1809 eingeführt wurde, zielt darauf ab, diese Probleme zu beheben, indem eine Technologie verwendet wird, die als Dynamic Root of Trust for Measurement (DRTM) bekannt ist. DRTM ermöglicht es dem System, zunächst frei in nicht vertrauenswürdigen Code zu starten, aber kurz danach startet das System in einen vertrauenswürdigen Zustand, indem es die Kontrolle über alle CPUs übernimmt und sie auf einen bekannten und gemessenen Codepfad zwingt. Dies hat den Vorteil, dass nicht vertrauenswürdiger früher UEFI-Code das System starten kann, dann aber sicher in einen vertrauenswürdigen und gemessenen Zustand übergehen kann.

Sicherer System Guard-Start.

Secure Launch vereinfacht die Verwaltung von SRTM-Messungen, da der Startcode jetzt nicht mehr mit einer bestimmten Hardwarekonfiguration zusammenhängt. Dies bedeutet, dass die Anzahl der gültigen Codemessungen gering ist und zukünftige Updates breiter und schneller bereitgestellt werden können.

Schutz des Systemverwaltungsmodus (System Management Mode, SMM)

Der Systemverwaltungsmodus (System Management Mode, SMM) ist ein spezieller CPU-Modus in x86-Mikrocontrollern, der energieverwaltung, Hardwarekonfiguration, thermische Überwachung und alles, was der Hersteller für nützlich hält, verarbeitet. Wenn einer dieser Systemvorgänge angefordert wird, wird zur Laufzeit ein nicht maskierbarer Interrupt (SMI) aufgerufen, der den vom BIOS installierten SMM-Code ausführt. SMM-Code wird in der höchsten Berechtigungsstufe ausgeführt und ist für das Betriebssystem unsichtbar, was ihn zu einem attraktiven Ziel für böswillige Aktivitäten macht. Auch wenn der sichere Start von System Guard für den späteren Start verwendet wird, kann SMM-Code potenziell auf hypervisor-Arbeitsspeicher zugreifen und den Hypervisor ändern.

Um dies zu schützen, werden zwei Techniken verwendet:

  • Auslagerungsschutz, um unangemessenen Zugriff auf Code und Daten zu verhindern
  • SMM-Hardwareüberwachung und -nachweis

Der Auslagerungsschutz kann implementiert werden, um bestimmte Codetabellen schreibgeschützt zu sperren, um Manipulationen zu verhindern. Dadurch wird der Zugriff auf keinen Speicher verhindert, der nicht zugewiesen wurde.

Ein hardwaregestütztes Prozessorfeature, das als Supervisor-SMI-Handler bezeichnet wird, kann den SMM überwachen und sicherstellen, dass er nicht auf einen Teil des Adressraums zugreift, den er nicht verwenden soll.

Der SMM-Schutz basiert auf der Secure Launch-Technologie und erfordert, dass sie funktioniert. In Zukunft wird Windows 10 auch das Verhalten dieses SMI-Handlers messen und bestätigen, dass kein betriebssystemeigener Arbeitsspeicher manipuliert wurde.

Überprüfen der Plattformintegrität nach der Ausführung von Windows (Laufzeit)

System Guard bietet zwar erweiterten Schutz, mit dem die Integrität der Plattform während des Startvorgangs und zur Laufzeit geschützt und aufrechterhalten wird, aber die Realität ist, dass wir selbst auf unsere anspruchsvollsten Sicherheitstechnologien eine "Sicherheitsverletzung annehmen"-Mentalität anwenden müssen. Wir können darauf vertrauen, dass die Technologien ihre Arbeit erfolgreich erledigen, aber wir brauchen auch die Fähigkeit, zu überprüfen, ob sie ihre Ziele erfolgreich erreicht haben. Aus Gründen der Plattformintegrität können wir nicht einfach darauf vertrauen, dass die Plattform, die möglicherweise kompromittiert werden könnte, ihren Sicherheitsstatus selbst bestätigt. System Guard umfasst daher eine Reihe von Technologien, die eine Remoteanalyse der Integrität des Geräts ermöglichen.

Wenn Windows gestartet wird, werden eine Reihe von Integritätsmessungen von System Guard unter Verwendung des Trusted Platform Module 2.0 (TPM 2.0) des Geräts durchgeführt. System Guard Secure Launch unterstützt keine früheren TPM-Versionen, z. B. TPM 1.2. Dieser Prozess und die Daten sind hardwareisoliert von Windows, um sicherzustellen, dass die Messdaten nicht der Art der Manipulation unterliegen, die bei einer Kompromittierung der Plattform auftreten könnte. Von hier aus können die Messungen verwendet werden, um die Integrität der Gerätefirmware, des Hardwarekonfigurationszustands und der Windows-Startkomponenten zu bestimmen, um nur einige zu nennen.

Startzeitintegrität.

Nachdem das System gestartet wurde, signiert und versiegelt System Guard diese Messungen mithilfe des TPM. Auf Anfrage kann ein Verwaltungssystem wie Intune oder Microsoft Configuration Manager sie für die Remoteanalyse abrufen. Wenn System Guard angibt, dass dem Gerät die Integrität fehlt, kann das Verwaltungssystem eine Reihe von Aktionen ausführen, z. B. das Verweigern des Zugriffs auf Ressourcen für das Gerät.

Windows-Edition und Lizenzierungsanforderungen

In der folgenden Tabelle sind die Windows-Editionen aufgeführt, die System Guard unterstützen:

Windows Pro Windows Enterprise Windows Pro Education/SE Windows Education
Ja Ja Ja Ja

System Guard-Lizenzberechtigungen werden durch die folgenden Lizenzen gewährt:

Windows Pro/Pro Education/SE Windows Enterprise E3 Windows Enterprise E5 Windows Education A3 Windows Education A5
Ja Ja Ja Ja Ja

Weitere Informationen zur Windows-Lizenzierung finden Sie unter Übersicht über die Windows-Lizenzierung.

Systemanforderungen für System Guard

Dieses Feature ist für die folgenden Prozessoren verfügbar:

  • Intel® vPro-Prozessoren™ ab Intel® Coffeelake, Whiskeylake oder höher
  • AMD-Prozessoren® ab Zen2 oder höher
  • Qualcomm-Prozessoren® mit SD850-Chipsätzen oder höher

Anforderungen für Intel® vPro-Prozessoren™ ab Intel® Coffeelake, Whiskeylake oder höher

Name Beschreibung
CPU mit 64 Bit Ein 64-Bit-Computer mit mindestens vier Kernen (logische Prozessoren) ist für Hypervisor und virtualisierungsbasierte Sicherheit (VBS) erforderlich. Weitere Informationen zu Hyper-V finden Sie unter Hyper-V unter Windows Server 2016 oder Einführung in Hyper-V unter Windows 10. Weitere Informationen zum Hypervisor finden Sie unter Hypervisorspezifikationen.
Trusted Platform Module (TPM) 2.0 Plattformen müssen ein diskretes TPM 2.0 unterstützen. Integrierte/Firmware-TPMs werden nicht unterstützt, mit Ausnahme von Intel-Chips, die Platform Trust Technology (PTT) unterstützen. Hierbei handelt es sich um eine Art integriertes Hardware-TPM, das die TPM 2.0-Spezifikation erfüllt.
Windows DMA-Schutz Plattformen müssen die Windows DMA-Schutzspezifikation erfüllen (alle externen DMA-Ports müssen standardmäßig deaktiviert sein, bis das Betriebssystem sie explizit antreibt).
SMM-Kommunikationspuffer Alle SMM-Kommunikationspuffer müssen in den Speichertypen EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS oder EfiReservedMemoryType implementiert werden.
SMM-Seitentabellen Darf KEINE Zuordnungen zu EfiConventionalMemory enthalten (z. B. kein Betriebssystem-/VMM-Speicher).
Darf KEINE Zuordnungen zu Codeabschnitten in EfiRuntimeServicesCode enthalten.
Darf NICHT über Ausführungs- und Schreibberechtigungen für dieselbe Seite verfügen
Darf NUR zulassen, dass TSEG-Seiten als ausführbar markiert werden können, und die Speicherzuordnung muss TSEG EfiReservedMemoryType melden.
Der BIOS-SMI-Handler muss so implementiert werden, dass SMM-Seitentabellen für jeden SMM-Eintrag gesperrt sind.
Moderner/verbundener Standbymodus Plattformen müssen modernen/verbundenen Standbymodus unterstützen.
TPM-AUX-Index Die Plattform muss einen AUX-Index mit Index, Attributen und Richtlinien einrichten, die genau dem in der TXT DG angegebenen AUX-Index mit einer Datengröße von genau 104 Bytes (für SHA256-AUX-Daten) entsprechen. (NameAlg = SHA256)
Plattformen müssen einen PS-Index (Plattformlieferant) einrichten mit:
  • Genau der "TXT PS2"-Stil Attribute bei der Erstellung wie folgt:
    • AuthWrite
    • RichtlinieLöschen
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • NoDa
    • Schriftlich
    • PlattformErstellen
  • Eine Richtlinie von genau PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg und Policy)
  • Größe von genau 70 Bytes
  • NameAlg = SHA256
  • Außerdem muss es zum Zeitpunkt des Betriebssystemstarts initialisiert und gesperrt worden sein (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1).
DIE PS-Indexdaten DataRevocationCounters, SINITMinVersion und PolicyControl müssen alle 0x00
AUX-Richtlinie Die erforderliche AUX-Richtlinie muss wie folgt aussehen:
  • A = TPM2_PolicyLocality (Lokalität 3 & Ort 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
TPM NV-Index Plattformfirmware muss einen TPM NV-Index für die Verwendung durch das Betriebssystem einrichten mit:
  • Handle: 0x01C101C0
  • Attribute:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Eine Richtlinie von:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Digestwert für 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Plattformfirmware Plattformfirmware muss den gesamten Code enthalten, der zum Ausführen eines sicheren Starts der Intel® Trusted Execution Technology erforderlich ist:
  • Intel® SINIT ACM muss im OEM-BIOS mitgeführt werden
  • Plattformen müssen mit einem Produktions-ACM ausgeliefert werden, der vom richtigen Intel® ACM-Produktionssignierer für die Plattform signiert ist.
Plattformfirmwareupdate Es wird empfohlen, die Systemfirmware über UpdateCapsule in Windows Update zu aktualisieren.

Anforderungen für AMD-Prozessoren® ab Zen2 oder höher

Name Beschreibung
CPU mit 64 Bit Ein 64-Bit-Computer mit mindestens vier Kernen (logische Prozessoren) ist für Hypervisor und virtualisierungsbasierte Sicherheit (VBS) erforderlich. Weitere Informationen zu Hyper-V finden Sie unter Hyper-V unter Windows Server 2016 oder Einführung in Hyper-V unter Windows 10. Weitere Informationen zum Hypervisor finden Sie unter Hypervisorspezifikationen.
Trusted Platform Module (TPM) 2.0 Plattformen müssen ein diskretes TPM 2.0 oder Microsoft Pluton TPM unterstützen.
Windows DMA-Schutz Plattformen müssen die Windows DMA-Schutzspezifikation erfüllen (alle externen DMA-Ports müssen standardmäßig deaktiviert sein, bis das Betriebssystem sie explizit antreibt).
SMM-Kommunikationspuffer Alle SMM-Kommunikationspuffer müssen in den Speichertypen EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS oder EfiReservedMemoryType implementiert werden.
SMM-Seitentabellen Darf KEINE Zuordnungen zu EfiConventionalMemory enthalten (z. B. kein Betriebssystem-/VMM-Speicher).
Darf KEINE Zuordnungen zu Codeabschnitten in EfiRuntimeServicesCode enthalten.
Darf NICHT über Ausführungs- und Schreibberechtigungen für dieselbe Seite verfügen
Der BIOS-SMI-Handler muss so implementiert werden, dass SMM-Seitentabellen für jeden SMM-Eintrag gesperrt sind.
Moderner/verbundener Standbymodus Plattformen müssen modernen/verbundenen Standbymodus unterstützen.
TPM NV-Index Plattformfirmware muss einen TPM NV-Index für die Verwendung durch das Betriebssystem einrichten mit:
  • Handle: 0x01C101C0
  • Attribute:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Eine Richtlinie von:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Digestwert für 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Plattformfirmware Plattformfirmware muss den gesamten Code enthalten, der zum Ausführen des sicheren Starts erforderlich ist:
  • AMD® Secure Launch-Plattformen müssen mit verfügbarem AMD® DRTM-Treiber und installiertem AMD® DRTM-Treiber ausgeliefert werden.

Auf der Plattform muss der Amd® Secure Processor Firmware Anti-Rollback-Schutz aktiviert sein.
Auf der Plattform muss AMD® Memory Guard aktiviert sein.
Plattformfirmwareupdate Es wird empfohlen, die Systemfirmware über UpdateCapsule in Windows Update zu aktualisieren.

Anforderungen für Qualcomm-Prozessoren® mit SD850-Chipsätzen oder höher

Name Beschreibung
Kommunikation im Überwachungsmodus Alle Kommunikationspuffer im Monitormodus müssen entweder in EfiRuntimeServicesData (empfohlen) und datenabschnitten von EfiRuntimeServicesCode implementiert werden, wie in den Speichertypen "Memory Attributes Table", "EfiACPIMemoryNVS" oder "EfiReservedMemoryType" beschrieben.
Seitentabellen im Überwachungsmodus Alle Seitentabellen im Überwachungsmodus müssen:
  • KEINE Zuordnungen zu EfiConventionalMemory enthalten (z. B. kein Betriebssystem-/VMM-Speicher)
  • Sie dürfen NICHT über Ausführungs- und Schreibberechtigungen für dieselbe Seite verfügen.
  • Plattformen dürfen nur Seiten im Überwachungsmodus zulassen, die als ausführbare Datei gekennzeichnet sind
  • Die Speicherzuordnung muss den Monitormodus als EfiReservedMemoryType melden.
  • Plattformen müssen Einen Mechanismus bereitstellen, um die Seitentabellen im Überwachungsmodus vor Änderungen zu schützen.
Moderner/verbundener Standbymodus Plattformen müssen modernen/verbundenen Standbymodus unterstützen.
Plattformfirmware Plattformfirmware muss den gesamten Code enthalten, der zum Starten erforderlich ist.
Plattformfirmwareupdate Es wird empfohlen, die Systemfirmware über UpdateCapsule in Windows Update zu aktualisieren.