UEFI Secure Boot: Microsoft legt Signaturvergabe offenbar bis 2021 auf Eis

Neue MS-Signaturen für UEFI Secure Boot lassen auf sich warten – wegen einer konzeptionellen Schwäche der Schlüsseldatenbank möglicherweise bis Frühjahr 2021.

Lesezeit: 2 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 181 Beiträge

(Bild: David Wolski)

Von
  • David Wolski

Um den Start manipulierter Kernel und unerwünschter Module auf UEFI-Systemen zu verhindern, kontrolliert Secure Boot kryptografische Signaturen und verweigert im Falle fehlender oder gesperrter Signaturen den Start. Der Hauptschlüssel zum Signieren von Bootloadern liegt seit jeher bei Microsoft. Wer als Entwickler ein Betriebssystem unter Secure Boot bootfähig haben möchte, muss Microsofts Zertifizierungsprozess durchlaufen, der unter anderem eine Prüfung durch das so genannte Shim Review Board umfasst. Letztlich signiert dann Microsoft die vom Board als ausreichend sicher befundenen Shim-Bootloader.

Seit Bekanntwerden der Sicherheitslücke "Boothole" im Juli 2020 ist dieser schon zuvor oft als langwierig beschriebene Zertifizierungsprozess nochmals stark in Verzug geraten: Monatelange Wartezeiten bei der Freigabe von Signaturen für den Shim-Bootloader sorg(t)en bei Entwicklern für Unmut. So blieben etwa Anfragen an das Review Board, die im Rahmen des öffentlichen Zertifizierungsprozesses im August 2020 auf GitHub gestellt wurden, teilweise unbeantwortet.

Wichtig für eine Zertifizierung ist die Dokumentation seitens der Entwickler, dass im gestarteten System ein Kernel-Lockdown funktioniert, damit keine unsignierten Module nachgeladen werden können. Wie heise online allerdings bereits vor rund zwei Wochen berichtete, sehen sich die Reviewer des Shim Review Boards derzeit außerstande, den Kernel Lockdown Mode bei anderen als Linux-Kernels zu beurteilen.

Zu den auf Zeitmangel und fehlenden Fachkenntnissen fußenden Hürden bei der Signaturvergabe haben sich jetzt offenbar weitere Schwierigkeiten gesellt: Eine konzeptionelle Schwäche der Schlüsseldatenbank DBX könnte dafür sorgen, dass Microsoft bis zum Frühjahr 2021 überhaupt keine Shims mehr signiert.

Besagte konzeptionelle Schwäche trat zutage, nachdem zur Behebung der Boothole-Schwachstelle viele Signaturen anfälliger Shims seitens der Microsoft-CA zurückgezogen ("revoked") wurden. Sie betrifft die Schlüsseldatenbank DBX im UEFI Secure Boot. Diese Datenbank liegt im nichtflüchtigem Speicher der Firmware und kontrolliert bei aktiviertem Secure Boot, ob der Bootloader in der Liste der erlaubten oder in der Liste der gesperrten Signaturen steht.

Das Problem: Nach "Boothole" ist die Sperrliste zu groß geworden und der Revoke-Prozess funktioniert nicht mehr, wenn die auf 30KB begrenzte DBX-Schlüsseldatenbank voll ist. Die (noch nicht einmal abgeschlossenen) Aufräumarbeiten nach Boothole haben mit drei widerrufenen Zertifikaten und 150 ungültigen Signatur-Hashes bereits die Hälfte des verfügbaren Platzes in der DBX aufgebraucht.

Aktuell sucht Microsofts CA nach einer alternativen Lösung, gesperrte Signaturen platzsparend zu hinterlegen und hat einen ersten Entwurf auf GitHub gestellt. Dieser sieht vor, statt einem SHA-256-Hashwert für ungültige Signaturen bei umfassenden Schwachstellen mit Versionsnummern zu arbeiten, um eine ganze Serie von Bootloadern mit einem einzigen Eintrag unbrauchbar machen zu können. Weiter geht noch der Vorschlag, die Anzahl unterschiedlicher Shims generell zu reduzieren, was auch einen beschleunigten Review-Prozess zur Folge hätte.

Bis der Vorschlag mit allen Partnern Microsofts geklärt ist, dürften noch Wochen vergehen. Einem Softwareunternehmen, das per E-Mail bei Microsoft nachhakte (der Schriftwechsel liegt heise online vor) wurde mitgeteilt, dass Microsoft mindestens bis Frühjahr 2021 keine neuen Shims mehr signieren werde. Ein offizielles Statement Microsofts zu dieser Planung steht noch aus; in der E-Mail heißt es allerdings, dass man derzeit an einem solchen arbeite und es bald veröffentlichen wolle.

Als vorübergehende Lösung bleibe, eigene Machine Owner Keys (MOKs) im UEFI für Secure Boot zu hinterlegen. Praktikabel ist dieser Vorschlag des Review Boards bei der Administration der eigenen zertifizierbaren IT, jedoch kaum für Softwarehersteller, die Systeme ausliefern, die auf UEFI Secure Boot ohne Manipulation der Schlüsseldatenbank bootfähig sein müssen.

(ovw)