Unter dem Deckmantel der Sicherheit erschuf & kontrolliert Microsoft mit Secure Boot ein Gefängnis auf nahezu jedem PC. Der Konzern bestimmt, wer starten darf. Nur unter bestimmten Umständen signieren sie Bootloader von anderen Betriebssystemen. Freie Software unter GPL-Lizenz ist sogar unter einem Vorwand ausgeschlossen. Damit leidet die Vielfalt & Wahlfreiheit auf PCs – zugunsten von Windows.
Dieser Beitrag knüpft an den ersten Teil zu Secure Boot an. Während dort auf die Funktion, Microsofts Einfluss sowie allgemeine Risiken eingegangen wurde, fokussiert sich Teil 2 auf die Auswirkungen für freie Betriebssysteme. Sie sind gewaltig und haben bei bestimmten Linux-Distributionen zu massiven Ausfällen geführt.
Während GNU/Linux damit noch weniger schlecht dasteht, sieht es bei anderen Betriebssystemen weitaus katastrophaler aus. Um zu existieren, müssen Nutzer Secure Boot deaktivieren – sofern ihr Mainboard das noch erlaubt. Während solche Machtspiele seit Jahren auf unseren Computern in vollem Gange sind, zeigen ausgerechnet jene GNU/Linux-Distributionen eine beeindruckende Naivität, die sich früher radikal gegen unfreie Software gestellt haben.
Secure Boot: Der Sichere Start zusammengefasst
Das BIOS (Basic Input/Output System) revolutionierte PCs ab 1981. Durch eine Abstraktionsschicht sind Betriebssysteme nicht mehr an die Hardware gebunden. Über zwei Jahrzehnte später soll es von UEFI abgelöst werden. Der Nachfolger hebt einige technische Beschränkungen (z.B. Maximale Laufwerksgröße von 2TB) auf und bringt weitere Vorteile sowie Änderungen (etwa eine grafische Oberfläche). Zunächst für seine Komplexität kritisiert, kommt später auch noch Secure Boot dazu.
Der Sichere Start erlaubt nicht mehr jeder Software, frei zu starten. Stattdessen müssen dessen Bestandteile wie der Bootmanager signiert sein. Bei nahezu allen PCs & Laptops ist lediglich Microsoft als Zertifizierungsstelle hinterlegt. Damit kontrolliert der Konzern, welche Betriebssysteme booten dürfen. Und bei welchen der Versuch nur mit einem Fehler abbricht. Sie trotzdem zu nutzen, ist aufwändiger. Die Abschaltung von Secure Boot war bis einschließlich Windows 8 von Microsoft vorgeschrieben. Seit Windows 10 überlässt es der Konzern den Hardware-Herstellern, sodass dies nicht mehr garantiert ist.
Signieren zweiter Klasse
UEFIs Secure Boot Funktionalität basiert auf verschiedenen Schlüsselverwaltungen. Die Key Exchange Key (KEK) Datenbank darf bestimmen, welche Bootloader-Signaturen erlaubt oder gesperrt sind. Hier ist Microsoft Corporation KEK CA 2011 eingetragen – das schreibt der Konzern in seinen Anforderungen fürs Windows-Logo vor. Bei Microsoft Corporation UEFI CA 2011 hingegen verwendet das Unternehmen für alles andere, was sie signieren möchten. Sie ist nur optional.
Da Secure Boot komplett in der Kontrolle des Konzerns liegt, kann er frei entscheiden, unter welchen Umständen sie andere Betriebssysteme darüber starten lassen. Selbst 12 Jahre später scheint dieses Quasi-Monopol selbst für staatliche Regulierungsorganisationen kein Problem darzustellen. So führt der Konzern 2022 die NX Kompatibilität als Voraussetzung ein. Freie Softwarelizenzen wie die GPLv3 akzeptiert er nicht. Insgesamt 18 Punkte müssen erfüllt sein, um überhaupt von MS in Erwägung gezogen zu werden. 1
Microsoft sagt spring, GNU/Linux fragt wie hoch
GNU/Linux-Distributionen wie Fedora mussten dafür umfangreichere Änderungen vornehmen, die mehr Zeit benötigten. Doch das interessierte MS wenig. Auf einem Teil der PCs konnte Fedora drei Versionen lang (!) nicht mehr starten.2 Die Distribution ist als aktiv bekannt, etwa alle 6 Monate erscheint eine neue Version.
Die Ursache war ein Bug im Shim Bootloader. Aufgrund Microsofts schwierigem Zertifizierungsprozess erlaubte der Konzern keine Signierung der Aktualisierung – sie müssen erst andere Anforderungen erfüllen. Obwohl mit Red Hat ein großer Konzern wesentlich an Fedora beteiligt ist, führte das zu katastrophalen Problemen. Und das keineswegs temporär, sondern über mindestens 1,5 Jahre hinweg.3
Freie GPLv3 Software? Unerwünscht!
Im übrigen macht MS kein Geheimnis darum, freie Softwarelizenzen auszuschließen. Code, der beispielsweise unter GPLv3 steht (wie Grub), werden sie pauschal nicht signieren. Sollte das dennoch passiert sein, behält sich MS vor, dies zurück zu ziehen. MS behauptet, die GPLv3 würde sie zur Herausgabe der Master-Schlüssel zwingen.
Obwohl die FSF bereits 2012 klar gestellt hat: Die GPLv3 schützt zwar die Freiheit der Nutzer vor Einschränkungen, erhebt dabei aber eben keinen Anspruch auf Schlüssel. Ihr Ziel ist sicherzustellen, dass jeder die Freiheit besitzt, eigens angepasste GPLV3-Software auf dem System zu installieren. Bei Secure Boot genügt daher die Bereitstellung klarer Anweisungen, um sämtliche Boot-Einschränkungen deaktivieren oder ändern zu können, damit das ermöglicht wird.4 Bis heute scheint das Microsoft jedoch nicht zu interessieren – was die ernste Frage aufwirft, ob diese Begründung nur vorgeschoben ist, um es freier Software noch schwerer zu machen. Schließlich weisen sie ausdrücklich auf den unter GNU/Linux verbreiteten Bootloader GRUB 2 als Beispiel hin, den sie aufgrund dieser Ausrede nicht signieren. Microsoft hatte sich bereits früher abfällig über die GPL geäußert und sie als Krebsgeschwür bezeichnet.
Andere Betriebssysteme sind komplett raus
Noch schlimmer ist die Lage bei anderen Betriebssystemen: Der Shim Bootloader stammt aus der GNU/Linux Welt, da MS kein Interesse am Start der Konkurrenz hat. Für eine Signierung müssen einige Anforderungen erfüllt sein. Darunter beispielsweise der Beleg, dass vom Kernel nur signierte Module nachladen kann. Die Entwickler von Shim sehen sich außer Stande, diese Prüfung bei anderen Kerneln außer Linux vorzunehmen.5
Teilweise wurden zuvor trotzdem welche durchgeführt. Ende 2020 entschied man dort, zukünftig keine Signaturen bei Nicht-Linux-Kerneln vorzunehmen. Da nur MS die Schlüssel kontrolliert, gibt es kaum eine Alternative.6
Vertrau mir bro: Die Naivität innerhalb der FOSS-Bewegung
Dass MS kein echtes Interesse an der Verbreitung konkurrierender GNU/Linux-Betriebssysteme besitzt, war bereits damals absehbar. Insbesondere bei einem Unternehmen mit dieser Firmengeschichte. Wir erinnern uns: MS wurde wegen des erheblichen Missbrauchs ihrer marktbeherrschenden Stellung zur Zerschlagung verurteilt. Nur durch politisches Glück mussten sie ihre Strafe nicht antreten und kamen mit der Veröffentlichung von ein paar proprietären Spezifikationen davon.
Umso erstaunlicher ist es, dass zumindest ein Teil der GNU/Linux-Gemeinschaft glaubt, MS wäre nun ihr bester Freund geworden. Debian besitzt in ihrem Wiki einen eigenen Abschnitt, was UEFI Secure Boot nicht sei. Dort wird ausdrücklich betont, es handle sich um keinen Versuch von MS, Linux aus dem Markt zu drängen.7 Streitbar ist, ob es sich um pure Absicht handelt – oder ein Kollateralschaden. Möglicherweise ja auch beides. Schließlich hat MS gar kein Interesse daran, dass PCs mit konkurrierenden Betriebssystemen laufen. Im Gegenteil. Unabhängig von der Motivation schadet das abriegeln freien Betriebssystemen wie GNU/Linux.
GNU sieht den Angriff
Das GNU-Projekt kommt zu einer ganz anderen Einschätzung: Sie sehen UEFI als Sicherheitsrisiko, nicht zuletzt wegen ihrer proprietären Bestandteile.8 Ähnliche Kritik äußerte auch heise online 2022, als sie u.a. die unnötige Komplexität erwähnen und belegen das mit Sicherheitslücken, die von Intel alle paar Monate bekannt gegeben werden. Ein Teil der Hardware bekommt keine Aktualisierungen, weil man sich auf abgelaufene Unterstützungszeiträume beruft.9
Gerade Debian war Jahrzehntelang für kompromisslos freie Software bekannt. Ihnen war es derart ernst, dass offizielle Installationsmedien nicht mit proprietärer Firmware ausgeliefert werden durften. Es verwundert, dass Debian all diese Aspekte bei UEFI & Secure Boot zu ignorieren scheint. 2022 hatte es mit Debian 12 eine Kehrtwende gegeben, die zu einer Änderung des Gesellschafter-Vertrages führte. Seit dem dürfen offizielle Installationsmedien nicht nur proprietäre Firmware enthalten, sondern sogar automatisch laden. Man könnte daraus das Fazit ziehen, dass die Bedeutung freier Software für Debian zunehmend schwindet.
Wie kommen wir dort wieder heraus?
Solche Befürchtungen sind real, sofern nicht z.B. die EU den Missbrauch der Marktbeherrschenden Stellung erkennt & ahndet. Dabei ist die grundlegende Idee hinter Secure Boot durchaus sinnvoll, zumindest für Nutzer mit Mobilgeräten/höheren Sicherheitsanforderungen. Es gibt jedoch wenige, die noch schlechter dafür geeignet wären, als Microsoft. Fair ohne Gängelungen kann das nur von einer unabhängigen Organisation sein.
Obwohl 12 Jahre vergangen sind, scheint das Thema politisch nicht mehr auf der Agenda zu sein – obwohl es das am Anfang durchaus war. Neben dem BSI haben weitere Behörden Risiken festgestellt. Wer nun Bauchschmerzen mit seinem proprietären UEFI unter der Herrschaft des fragwürdigen MS-Konzerns bekommt, kann pragmatisch mit Libreboot eine freie Firmware nutzen.10 Dies kommt nur für erfahrenere Nutzer in Frage. Außerdem muss man dafür eines der kompatiblen Geräte besitzen – nicht jeder PC/Laptop wird unterstützt. Coreboot und LinuxBoot versprechen eine Alternative zu ZEFI DXE.
Die FSF unterhält ein Zertifikat für Hardware, welche die Freiheitsrechte des Besitzers wahrt. Grundsätzlich finde ich es eine gute Sache, über den Geldbeutel abzustimmen – abseits von rechtlich durchgesetzten Anforderungen lässt sich nur so eine Änderung bei kommerziell orientierten Unternehmen bewirken. Allerdings ist das Angebot überschaubar. Beispielsweise sind derzeit lediglich 5 Mainboards gelistet, alle bereits mehrere Jahre alt. Ähnlich sieht es bei Notebooks aus, die oft angepasste, gebrauchte ThinkPad-Modelle darstellen. Diese kommen mit Coreboot/Libreboot. Mit Prozessoren wie dem Intel Core 2 Duo P8400 von 2008 (!) ist das leider alles andere als praxistauglich.
Die Konsequenzen
Sie werden bei einer Betrachtung von außen deutlich: Wie viele Hürden sind einem durchschnittlichen Nutzer in den Weg gelegt, wenn er GNU/Linux installieren möchte? Secure Boot hat die Komplexität erheblich gesteigert. Selbst als erfahrener Nutzer benötigt man einige Zeit, um das System zu verstehen. Und dabei sind wir noch gar nicht bei den Fehlern sowie weiteren Problemen, welche durch dieses Chaos entstanden sind. MS hat sich bereits an vielen Stellen als Freund der Salami-Taktik geoutet. Was wird die nächste Stufe sein? Ein Secured-Core-PC+, bei dem leider alles außer dem super sicheren Windows ganz draußen bleiben muss?
Ohne Secure Boot mag sich der Nutzer einem theoretisch höheren Angriffsrisiko aussetzen. Konkret für Schadsoftware, die in den Startprozess vor dem Betriebssystem eingreift. Derartige Angriffe sind selten und für den normalen Nutzer überschaubar. Zumal die Überkomplexität das Gesamtkonstrukt nicht sicherer macht, sondern sogar unsicherer. Insbesondere, da Microsoft ihre Finger entscheidend im Spiel hat. Ein Konzern, der für alles außer tatsächliche Sicherheit bekannt ist. Durch den Verzicht darauf bleibt die Freiheit & Autonomie des Benutzers gewahrt. Die Installation eines Betriebssystems ist so einfach, wie zu BIOS-Zeiten: Bootbares Medium (meist USB-Stick) erstellen, davon booten, Installation starten & fertig.
So könnte ein gutes, sicheres Secure Boot aussehen
Der Gedanke dahinter ist nicht grundsätzlich falsch oder verwerflich. Theoretisch kann sich Schadsoftware in den Startprozess einschleusen. Aus der Ferne wird ein solcher Angriff komplex. Mit physischem Zugriff ist das allerdings einfacher. Wer Zugriff auf sensible Daten hat, kann & sollte das als realistisches Angriffsszenario betrachten. Insbesondere auf Reisen. Länder wie die USA sind bekannt dafür, Hardware zu manipulieren. Dort ist man selbst als normale Person einem hohen Risiko ausgesetzt.
Damit Secure Boot wirklich sicher wird, ohne dabei die Freiheit an einen Großkonzern zu opfern, müssten sich zwei grundlegende Dinge ändern:
- Die Hoheit über die Signierung gehört in die Hände einer unabhängigen Organisation. Weder für Microsoft, noch andere Konzerne dürfen sich dem entziehen. Nur so ist sichergestellt, dass Hardwarehersteller die Schlüssel dieser Organisation einbauen müssen.
- UEFI muss neu gemacht werden, mit Fokus auf seine Kernfunktionen. Seine Überkomplexität ist absurd und steht im Gegensatz zu Sicherheit. Wer zig hunderte Seiten an Spezifikationen implementieren muss, wird zwangsweise Fehler machen. Statt jedes Detail abbilden zu wollen, brauchen wir ein Minimalsystem. Die meisten Nutzer kommen mit der Firmware sehr selten bis nie in Berührung. Braucht man dafür z.B. eine grafische Oberfläche?
Völliges Neuland betreten wir damit übrigens nicht. Für Webserver-Zertifikate hat sich mit Let’s Encrypt längst eine Organisation durchgesetzt, welche diese neutral & kostenfrei ausstellt. Als U-Hacks gegründet wurde, gab es das noch nicht. Zertifikate konnten nur auf einem kapitalistischen Markt gekauft werden. Die Anbieter ließen sich das gut bezahlen – weitaus höher, als es im Verhältnis zum kaum vorhandenen Aufwand stand. Sowohl die Kosten, als auch Abhängigkeit sind Geschichte.
Fazit: Die Daumenschrauben werden angezogen
Der PC wurde durch seine (Quasi-) Standards und Offenheit groß. Erstmals mussten Betriebssystem & Software nicht mehr mühselig für jede einzelne Hardware angepasst werden. Die Abhängigkeit war weg: Ein IBM-PC konnte durch zig andere Hersteller getauscht werden, auf dem die gleiche Software unverändert weiter laufen kann. Diese Errungenschaft drohen wir zu verlieren. Secure Boot wird von Microsoft dominiert, damit verkommt es zu einer Windows-Lösung.
Wohin das führen kann, zeigen z.B. Smartphones. Die haben sich längst zu digitalen Gefängnissen entwickelt. Selbst unter dem noch vergleichsweise offenen Android ist es längst keine Selbstverständlichkeit mehr, selbst ein anderes Betriebssystem installieren zu können: Manche Hersteller verweigern schlicht die Entsperrung des Bootloaders. Damit kontrollieren sie alleine, welche (unfreie) Software wir einsetzen dürfen. So eine große Macht geht nicht ohne Missbrauch einher. Schließlich bringt der den Konzernen massiv Geld ein – auf unsere Kosten.
Noch sind (X86) PCs nicht auf dem Tiefpunkt von Smartphones angekommen. Doch das könnte sich in wenigen Jahren ändern, wenn keine Alternativen zur Übermacht der Konzerne geschaffen wird. Sondern diese auf Akzeptanz oder gar Toleranz stoßen. Auch Ignoranz reicht völlig, damit Microsoft & co. ihre Agenda ungestört durchziehen können.
Quellen
- https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 ↩︎
- https://discussion.fedoraproject.org/t/install-media-dont-boot-in-uefi-mode-on-certain-motherboards/71376 ↩︎
- https://bugzilla.redhat.com/show_bug.cgi?id=2113005#issuebot-ignore ↩︎
- https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web ↩︎
- https://www.heise.de/news/UEFI-Secure-Boot-sperrt-manche-freie-Software-aus-4936461.html ↩︎
- https://github.com/rhboot/shim-review/issues/102#issuecomment-698963751 ↩︎
- https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3F ↩︎
- https://www.gnu.org/proprietary/proprietary-insecurity.html#uefi-rootkit ↩︎
- https://www.heise.de/hintergrund/UEFI-BIOS-Funktionsweise-Risiken-und-Alternativen-7273584.html?seite=all ↩︎
- https://libreboot.org/ ↩︎



