Measured Boot

Measured Boot ist ein Windows-Sicherheitsverfahren, das den gesamten Startvorgang eines Systems lückenlos protokolliert — von der UEFI-Firmware über den Bootloader bis zum Kernel und den frühgeladenen Treibern. Jede Komponente wird vor ihrer Ausführung gehasht, und der Hash-Wert wird in einem dedizierten Register des Trusted Platform Module abgelegt. Anders als Secure Boot blockiert Measured Boot dabei selbst nichts: Es schafft eine manipulationssichere Aufzeichnung des Bootverlaufs, die anschließend lokal oder durch ein externes System bewertet werden kann.

Secure Boot blockiert, Measured Boot zeichnet auf

Secure Boot und Measured Boot werden häufig verwechselt, obwohl sie komplementäre Aufgaben haben. Secure Boot prüft beim Start die Signatur jeder Bootkomponente gegen eine in der UEFI-Firmware hinterlegte Datenbank zugelassener Schlüssel und verweigert nicht signierten oder widerrufenen Code die Ausführung. Measured Boot hingegen lässt den Boot weiterlaufen — es misst nur, was tatsächlich gestartet wurde, und macht diese Information später überprüfbar. Erst die Kombination liefert vollständigen Schutz: Secure Boot stoppt bekannte bösartige Bootloader, Measured Boot deckt auch Manipulationen auf, die signierte Komponenten missbrauchen oder im Vertrauensanker selbst ansetzen.

Die PCR-Register des TPM

Die Messwerte landen in den Platform Configuration Registers (PCRs) des TPM. Ein PCR lässt sich nicht direkt überschreiben, sondern nur erweitern: Der neue Wert ergibt sich aus dem Hash aus altem PCR-Inhalt und dem aktuellen Messwert. Dadurch entsteht eine Kette, in der jede einzelne Bootphase nachträglich identifizierbar bleibt. In der Praxis sind vier Register besonders relevant: PCR 0 enthält die Messung der UEFI-Firmware (CRTM, BIOS-Code), PCR 2 erfasst Option-ROMs externer Erweiterungen, PCR 4 speichert die Messung des Windows Boot Managers und der Bootloader-Komponenten, PCR 7 dokumentiert den Secure-Boot-Status inklusive der verwendeten Plattformschlüssel und Signaturdatenbanken. Genau auf PCR 7 setzt BitLocker standardmäßig auf, weil dieser Wert auch nach Firmware-Updates in vielen Fällen stabil bleibt, solange der Secure-Boot-Zustand selbst unverändert ist.

Lokale Auswertung: BitLocker Sealing

Die einfachste Form der Auswertung ist das sogenannte Sealing: BitLocker bindet den Volume Master Key kryptografisch an erwartete PCR-Werte. Der Schlüssel wird vom TPM nur freigegeben, wenn die Messwerte beim Start exakt den hinterlegten Referenzen entsprechen. Wird der Bootloader manipuliert, ein bösartiges Option-ROM eingespielt oder Secure Boot deaktiviert, scheitert die PCR-Prüfung und das System fällt in den Recovery-Modus zurück. Diese lokale Attestierung erfordert keine Netzwerkverbindung und kein Backend — sie passiert vollständig zwischen TPM und Betriebssystem.

Remote Attestation: Azure Attestation und Intune

Für Unternehmensszenarien ist die entfernte Attestierung interessanter. Windows protokolliert den Bootvorgang zusätzlich im sogenannten TCG-Log und kann dieses gemeinsam mit einer signierten Quote der PCR-Werte an einen Attestation Service übergeben. Microsoft Azure Attestation prüft die Quote gegen erwartete Referenzwerte und stellt einen signierten Health-Token aus. Microsoft Intune nutzt diesen Mechanismus über die Compliance-Richtlinie "Geräte-Health-Bescheinigung": Nur Geräte, deren Boot- und Kernelzustand vom Attestation-Dienst als integer bestätigt wurde, gelten als konform. In Verbindung mit Conditional Access lässt sich daraus eine harte Zugriffsgrenze ziehen — wer kein "healthy device" vorweisen kann, erhält keinen Zugriff auf Microsoft 365, sensible Anwendungen oder VPN-Strecken.

Anwendungsfälle in der Praxis

Measured Boot adressiert eine Klasse von Bedrohungen, die unterhalb des Betriebssystems ansetzt. Bootkits wie BlackLotus oder ältere Varianten manipulieren Bootloader oder Firmware, um sich vor jeder Endpoint-Detection zu verstecken. Eine PCR-basierte Attestierung erkennt solche Manipulationen, weil der Hash der veränderten Komponente nicht mehr zur Referenz passt — selbst dann, wenn die Schadkomponente formal signiert ist. Über die Bootkit-Erkennung hinaus liefert Measured Boot die Datenbasis für Conditional Access auf Geräteebene, für Audit-Nachweise gegenüber Wirtschaftsprüfern und für die Verifikation, dass VBS und HVCI tatsächlich aktiv geladen wurden, statt nur in der Konfiguration zu stehen.

Grenzen

Measured Boot ist kein Selbstläufer. Die Aussagekraft der PCR-Werte hängt davon ab, dass die Referenzen korrekt verwaltet werden — bei jedem Firmware-Update, BIOS-Setting-Wechsel oder Treiber-Tausch ändern sich Messwerte, was bei lokal gesealten Schlüsseln zu Recovery-Prompts führt. Remote Attestation skaliert nur mit einem laufenden Backend; ohne Azure Attestation oder eine vergleichbare Plattform bleibt die Information ungenutzt. Schwächen im Vertrauensanker selbst — etwa ein kompromittiertes UEFI mit gültiger Signatur, wie wir es bei Lieferketten- und Firmware-Angriffen wiederholt sehen — kann auch Measured Boot nicht aufdecken, sondern höchstens dokumentieren. Und auf älterer Hardware ohne TPM 2.0 oder mit deaktiviertem Secure Boot fehlt die Grundlage komplett.

Relevanz für KMUs

Für mittelständische Unternehmen ist Measured Boot weniger ein eigenständiges Projekt als ein Baustein, der in modernen Microsoft-Architekturen ohnehin vorhanden ist — er muss nur konsequent genutzt werden. Wir finden in Assessments regelmäßig Geräteflotten, bei denen TPM und Secure Boot aktiv sind, die Compliance-Auswertung in Intune aber nie eingeschaltet wurde. Damit verschenkt die Organisation den entscheidenden Schritt: aus der Messung eine Zugriffsentscheidung zu machen. Ein realistischer Einstieg sind drei Schritte — Geräte-Health-Attestation in Intune aktivieren, eine Compliance-Richtlinie auf "Boot-Integrität erforderlich" setzen und diese Richtlinie als Bedingung in eine Conditional-Access-Policy einbinden. Wer zusätzlich auf Secured-Core PCs standardisiert, erhält eine Hardware-Basis, auf der die Messwerte stabil und auditierbar bleiben.