Benutzerdefinierte Kernel signierer für App Control for Business

Ab April 2026 sind crosssignierte Zertifizierungsstellen (CAs) für die Signatur des Kernelmodustreibers standardmäßig nicht mehr vertrauenswürdig. Der Standardpfad für die Kerneltreibersignierung erfolgt über das Hardware Dev Center (HDC), das die Übermittlung von Treiberbinärdateien an Microsoft für die WHCP-Zertifizierung (Windows Hardware Compatibility Program) erfordert. Organisationen mit klassifizierten, sensiblen oder Air Gap-Umgebungen können jedoch möglicherweise keine Treiber zur Zertifizierung an Microsoft übermitteln. Darüber hinaus möchten Organisationen, die Treiber nur für die interne Verwendung schreiben, möglicherweise keine Treiber für das Windows-Ökosystem zertifizieren.

Benutzerdefinierte Kernelsignaturgeber lösen dieses Problem, indem sie App Control for Business erweitern, damit Organisationen Kerneltreibern vertrauen können, die mit ihrer eigenen Public Key-Infrastruktur (PKI) signiert sind, ohne DASS WHCP-Signaturen erforderlich sind. Das Feature verwendet eine App Control-Richtlinie, die von einer Signaturstelle in der Hierarchie für den sicheren Start signiert wurde, um zu definieren, welche Signaturzertifikate für Kernelmoduscode autorisiert sind. Dieses Feature bietet Ihnen eine präzise, überprüfbare Kontrolle über Ihre Kernelvertrauensgrenze und entfernt die Anforderung, Ihre Treiber durch WHCP zu zertifizieren.

Funktionsweise von benutzerdefinierten Kernel signierern

Das Feature für benutzerdefinierte Kernelsignierer verwendet eine mehrstufige Vertrauenskette und eine App-Steuerungsrichtlinie, um die in den Windows-Kernel integrierten Standardsignaturanforderungen zu überschreiben. So funktioniert die Vertrauenskette:

Nur der Plattforminhaber (PK- oder KEK-Besitzer) kann die Richtlinie autorisieren. Dieser Registrierungsprozess mit hoher Reibung ist beabsichtigt. Der Prozess verhindert Missbrauch auf Consumergeräten und stellt sicher, dass nur Organisationen mit physischem Firmwarezugriff das Feature aktivieren können.

Sicherheitsgarantien

Benutzerdefinierte Kernel signierer bieten die folgenden Sicherheitsgarantien:

• Sichere Startintegrität: Benutzerdefinierte Kernel signierer funktionieren nur, wenn sicherer Start aktiviert ist. Die Richtlinie muss vom Secure Boot PK- oder KEK-Besitzer signiert werden und kann nicht ohne physischen Firmwarezugriff gespooft werden.
• Manipulationsschutz: Nach der Bereitstellung kann die signierte Richtlinie nicht ohne eine Ersatzrichtlinie entfernt werden, die von derselben Autorität signiert wurde.
• Granulare Vertrauensstellung: Die App-Steuerungsrichtlinie lässt Vertrauensregeln pro Zertifikat und Hash zu. Sie steuern genau, welche Treiber in Ihrem Kernel ausgeführt werden.
• Nicht-Ablehnung: Alle Richtlinien- und Treibersignaturen sind kryptografisch überprüfbar. Codeintegritätsereignisprotokolle erfassen alle Lade- und Blockentscheidungen für die Überwachung.

Unterstützte Plattformen und Editionen

Das Feature für benutzerdefinierte Kernel signierer ist auf den folgenden Windows-Plattformen mit dem nicht sicherheitsrelevanten Update vom April 2026 verfügbar:

• Windows 11 (Version 24H2 und höher)

Das Feature ist in allen Editionen von Windows mit Ausnahme von Home verfügbar.

Bereitstellung von benutzerdefinierten Kernel signierern

Bevor Sie beginnen, stellen Sie sicher, dass die folgenden Anforderungen erfüllt sind:

• Neuinstallation von Windows unter einer unterstützten Edition. Benutzerdefinierte Kernel signierer müssen während der anfänglichen Geräteeinrichtung aktiviert werden. Das Feature wird auf derzeit ausgeführten Systemen nicht aktiviert.
• UEFI-Firmware (Version 2.3 oder höher) mit aktiviertem sicheren Start.
• Kundeneigene PKI-Infrastruktur. Eine HSM-gestützte Schlüsselspeicherlösung wird für Produktionsumgebungen empfohlen.
• Administratorzugriff auf UEFI-Firmwarevariablen (PK, KEK, DB).
• SignTool.exe aus dem Windows SDK.
• Vertrautheit mit dem Richtlinienentwurf von App Control for Business, signierten Richtlinien und Richtlinienregeln.

Schritt 1: Generieren der Schlüssel für den sicheren Start

Generieren Sie das PKI-Schlüsselpaar, das als Vertrauensbasis für den sicheren Start dient, und wird zum Signieren Ihrer App-Steuerungsrichtlinie verwendet. Entweder der PK oder KEK kann als Vertrauensbasis verwendet werden, um die App-Steuerungsrichtlinie zu signieren. Microsoft empfiehlt es sich, den PKI-Schlüssel zum KEK hinzuzufügen, damit der PK-Besitzer den KEK auch in Zukunft weiter bedienen kann.

PK- und KEK-Zertifikate müssen Stammzertifikate oder Zwischenzertifikate (PCAs) sein, die direkt aus dem Stamm ausgestellt werden. Das Dokument Zum Erstellen und Verwalten von Windows-Schlüsseln für den sicheren Start finden Sie weitere Informationen und Anleitungen zum Erstellen von Zertifikaten, die mit dem sicheren Start kompatibel sind. Sie können den Microsoft KEK-Schlüssel auch als Referenzvorlage für wichtige Eigenschaften und Erweiterungen verwenden.

Schritt 2: Konfigurieren der UEFI-Variablen für den sicheren Start mit Zugriff auf den PK

Wenn Sie den PK auf Geräten besitzen, können Sie die KEK-Registrierung signieren, um Ihren öffentlichen KEK-Schlüssel zur UEFI-Firmware hinzuzufügen. Wenn Sie den PK nicht besitzen, können Sie mit Schritt 3 fortfahren.

Generieren des KEK-Registrierungsinhalts

# Generate KEK content file
# Replace the SignatureOwner GUID with your organization's GUID
Format-SecureBootUEFI `
    -Name KEK `
    -SignatureOwner "55555555-5555-5555-5555-555555555555" `
    -ContentFilePath C:\KEK\KEK_SigList.bin `
    -FormatWithCert `
    -Certificate C:\KEK\policy_signer.cer `
    -SignableFilePath C:\KEK\KEK_Signable_SigList.bin `
    -Time 2025-01-01T00:00:00Z `
    -AppendWrite:$true

Signieren der KEK-Registrierungsdatei mit Ihrem PK

signtool.exe sign /fd sha256 
    /p7 .\ 
    /p7co 1.2.840.113549.1.7.1 `
    /p7ce DetachedSignedData `
    /a `
    /f PK.pfx`
    C:\KEK\KEK_Signable_SigList.bin

Schritt 3. Konfigurieren der UEFI-Variablen für den sicheren Start ohne Zugriff auf den PK

Um die Variablen für den sicheren Start von UEFI festzulegen, deaktivieren Sie zunächst den sicheren Start im UEFI-Menü, um die Firmware in den Setupmodus zu versetzen. Im Setupmodus können Variablen ohne signierte Updates festgelegt werden.

Legen Sie die Variablen in der folgenden Reihenfolge fest:

1. DATENBANK : Fügen Sie das OEM- und Windows UEFI CA 2023-Zertifikat hinzu.
2. KEK: Fügen Sie das Microsoft KEK CA 2K 2023 und das Richtlinien signierer-Zertifikat Ihres organization hinzu.
3. PK: Legen Sie den Plattformschlüssel Ihres organization fest (oder behalten Sie die OEM-PK bei Verwendung der KEK-Registrierung bei).

Schritt 4: Erstellen der App-Steuerungsrichtlinie

Beginnen Sie mit der standardbasierten erzwungenen Windows-Richtlinie als Basisvorlage, und überprüfen Sie dann das Gerät nach anderen Signaturgebern, die vertrauenswürdig sein müssen.

Suchen der Standardrichtlinienvorlage

Die Standardrichtlinienvorlage ist verfügbar unter:

%WINDIR%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml

Überprüfen des Geräts auf vorhandene Kernel signierer

New-CIPolicy -ScanPath 'C:\' -UserPEs -NoScript `
    -FilePath '.\ScannedPolicy.xml' `
    -Level PCACertificate -Fallback Hash

Zusammenführen der Standardrichtlinie mit den Scanergebnissen

Merge-CIPolicy `
    -PolicyPaths 'C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml', '.\ScannedPolicy.xml' `
    -OutputFilePath '.\CustomKernelSignersPolicy.xml'

Vorbereiten Ihrer Richtlinie für die Signierung

Das Feature für benutzerdefinierte Kernelsignierer erfordert, dass die Richtlinie signiert und durch Komponenten für den sicheren Start und frühen Windows-Start geschützt wird. Weitere Informationen finden Sie unter Signierte App Control-Richtlinien. Um die signierte Richtlinie zu aktivieren, entfernen Sie Option 6 (richtlinie ohne Vorzeichen):

Set-RuleOption -Option 6 -FilePath .\CustomKernelSignersPolicy.xml -Delete

(Optional) Entfernen der Codeintegrität im Benutzermodus

Wenn die Richtlinie nur auf Kernelmodustreiber angewendet werden soll, entfernen Sie Option 0 (UMCI):

Set-RuleOption -Option 0 -FilePath .\CustomKernelSignersPolicy.xml -Delete

Bewährte Methoden für die Basisrichtlinie

• Passen Sie zuerst das Bild an. Entfernen Sie alle nicht genehmigten Software, bevor Sie das Gerät scannen.
• Verwenden -Level PCACertificate für ein optimales Gleichgewicht zwischen Spezifität und Abdeckung.
• Die Überprüfung erfasst alle vorhandenen Signierer auf dem Gerät und stellt sicher, dass Windows-Komponenten und Hardwaretreiber vertrauenswürdig bleiben. Überprüfen Sie stattdessen nur Ihre vertraulichen Treiber.
• Testen Sie gründlich im Überwachungsmodus , bevor Sie die Bereitstellung im erzwungenen Modus durchführen.

Schritt 5: Hinzufügen benutzerdefinierter Kernel signierer zur Richtlinie

Fügen Sie den TBS-Hash (Zu signiert) jedes vertrauenswürdigen Zertifikats den folgenden Abschnitten Ihrer Richtlinien-XML hinzu. Sie benötigen Einträge für:

# Policy signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Update

# Custom kernel signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Kernel

Schritt 6: Konvertieren und Signieren der Richtlinie

Konvertieren der XML-Richtlinie in das Binärformat

Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\CustomKernelSignersPolicy.xml
$PolicyId = ([xml](Get-Content .\CustomKernelSignersPolicy.xml)).SiPolicy.PolicyId
ConvertFrom-CIPolicy .\CustomKernelSignersPolicy.xml -BinaryFilePath ("./" + $PolicyId + ".cip")

Signieren der Richtlinie mit Ihrem Richtliniensignaturzertifikat

signtool.exe sign /fd sha256 `
    /p7 .\ `
    /p7co 1.3.6.1.4.1.311.79.1 `
    /p7ce Embedded`
    /a `
    /f policy_signer.pfx `
    ("./" + $PolicyId + ".cip")

Schritt 7: Bereitstellen der Richtlinie

Sie können die signierte Richtlinienbinärdatei mit einer der folgenden Methoden bereitstellen:

• MDM-Lösung wie Microsoft Intune
• CiTool (verfügbar auf Windows 11)
• Gruppenrichtlinie (Bereitstellung über GPO)
• Skriptbasierte Bereitstellung (Bereitstellen über Skript)

Skriptbasierte Bereitstellung auf der EFI-Systempartition

Alle oben genannten Lösungen stellen neben der skriptbasierten Bereitstellung die Richtlinienbinärdatei automatisch in der EFI-Systempartition (ESP) bereit. Bei der Bereitstellung über ein Skript müssen Sie die signierte Richtlinienbinärdatei manuell in die EFI-Partition kopieren:

# Mount the EFI System Partition
mountvol s: /s

# Copy the signed policy to the active policies directory
copy ("./" + $PolicyId + ".cip") s:\EFI\Microsoft\Boot\CiPolicies\Active\

Schritt 8: Zurücksetzen von Windows

Zum Aktivieren des Features ist eine Zurücksetzung von Windows erforderlich. Sobald die Richtlinie auf der EFI-Partition vorhanden ist, müssen Sie das Gerät mithilfe einer Zurücksetzungsmethode wie dem Zurücksetzen per Knopfdruck zurücksetzen. Die Richtlinie wird von Windows nicht als vertrauenswürdig eingestuft, wenn kein Zurücksetzen durchgeführt wird.

Schritt 9: Deaktivieren der Windows-Treiberrichtlinie

Ab dem nicht sicherheitsrelevanten Update vom April 2026 erzwingen Windows 11 (24H2 und höher) und Windows Server 2025 eine Kernelrichtlinie, die die Vertrauensstellung für das kreuzsignierte Treiberprogramm einschränkt. Wenn die Richtlinie aktiv ist, müssen Sie sie deaktivieren. Andernfalls blockiert die Treiberrichtlinie Ihre benutzerdefinierten PKI-signierten Treiber.

# Mount the EFI System Partition
mountvol s: /s

# Remove the default Windows kernel policy if present
del s:\EFI\Microsoft\Boot\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip

Schritt 10: Überprüfen der Bereitstellung

Test im Überwachungsmodus zuerst

Stellen Sie vor dem Erzwingen der Richtlinie mit aktiviertem Überwachungsmodus bereit, um Richtlinienverstöße zu protokollieren, ohne Treiber zu blockieren:

1. Stellen Sie sicher, dass Enabled:Audit Mode im Abschnitt richtlinie <Rules> festgelegt ist.
2. Stellen Sie die Richtlinie bereit, und starten Sie das Gerät neu.
3. Überprüfen Sie die Ereignisprotokolle für die Codeintegrität unter Anwendungs- und Dienstprotokolle>Microsoft>Windows>CodeIntegrity.

Überprüfungsprüfliste

• Benutzerdefinierte Treiber werden erfolgreich geladen.
• Nicht signierte oder nicht autorisierte Treiber werden blockiert (im Erzwingungsmodus).
• Windows Update- und Betriebssystemwartungsflows funktionieren weiterhin.
• Codeintegritätsereignisprotokolle zeigen nur erwartete Blockereignisse an.
• Die Richtlinie wird vor der flottenweiten Bereitstellung für alle Zielhardwarekonfigurationen überprüft.

Entfernen Sie nach Abschluss der Überprüfung die Enabled:Audit Mode Regeloption aus der Richtlinie, signieren Sie sie erneut, und stellen Sie sie auf Produktionsgeräten bereit. Eine sauber Installation von Windows ist für Richtlinienupdates nicht erforderlich.

Verwandte Themen

• Entwurfsleitfaden für App-Steuerung für Unternehmen
• App Control-Richtlinienregeln und Dateiregeln
• Bereitstellen von App Control-Richtlinien mit Skript
• Verwenden von signierten Richtlinien zum Schutz der App-Steuerung vor Manipulationen
• WHCP-Releasesignatur
• Übersicht über den sicheren Start