Neustart-Linux.de

Ich habe tatsächlich einen Nachteil von Linux gefunden

August 2026 · Lesezeit ca. 8 Minuten · Thema: Verschlüsselung

Es gibt Handgriffe, die macht man tausendmal, ohne darüber nachzudenken. Bei mir ist das der Tausch einer Hauptplatine an einem verschlüsselten Windows-Rechner im Vollzeitjob: Verschlüsselung kurz aussetzen, Platine tauschen, Verschlüsselung wieder scharf schalten. Zwei Handgriffe, keine Rückfragen. Neulich wollte ich einen ähnlichen Handgriff auf einem Linux-Rechner machen – und stand vor einer Wand.

Kurzfassung:
Linux-Verschlüsselung will vorher eingeplant sein, Windows lässt sich leichter nachrüsten – dafür gibt es einen handfesten technischen Grund. Wer genauer hinsieht, findet aber auf beiden Seiten Kompromisse, und ausgerechnet der scheinbare Nachteil erweist sich als Teil der Lösung. Am Ende steht das Verfahren, das ich mir dafür in der Werkstatt gerade selbst zurechtlege.

Der Handgriff, der nicht ging

Vorgeschichte: In der Werkstatt entsteht gerade eine eigene Installationsanlage – ein Server im eigenen Netzwerk, der andere Geräte mit Linux bestückt: Vom Einschalten bis zum fertigen System, ohne dass ich an jeder Kiste einzeln mit einem Stick hantiere. Parallel dazu hatte ich im Linux-Magazin den Praxis-Bericht über den Sicherheitschip TPM (Trusted Plattform Module) gelesen[1]: über einen kleinen Baustein, der auf so gut wie jeder Hauptplatine sitzt und heute dazu dient, verschlüsselte Datenträger beim Hochfahren zu entsperren.

Also der naheliegende Praxistest: Ich installiere ein Testgerät und gebe mir selbst die Aufgabe das Gerät nachträglich zu verschlüsseln und wieder zu entschlüsseln, als wäre es eine Kundenanforderung, beispielsweise für einen Tausch der Hautplatine. Genau die Reihenfolge, die ich aus dem Berufsalltag kenne. Unter Linux ging genau das nicht. Nicht „umständlich". Nicht „dauert länger". Es ging schlicht überhaupt gar nicht, ohne einen riskanten Eingriff zu wagen, den ich auf keinem Kundengerät verantworten könnte.

Kurz erklärt – was macht so ein Sicherheitschip?
Er merkt sich, in welchem Zustand der Rechner beim letzten Start war: welche Firmware, welcher Bootloader, welcher Kernel. Weicht das beim nächsten Start unerwartet ab, verweigert er die Herausgabe des Schlüssels. Ein stiller Wächter, der nur prüft, ob alles beim Alten geblieben ist.

Sechzehn Megabyte, die alles entscheiden

Der Grund ist banal und trotzdem folgenreich. Jede Linux-Verschlüsselung durch "LUKS" legt am Anfang des Datenträgers ein Schließfach an: Dort steht, mit welchem Passwort welcher Schlüssel entsperrt wird, und dort ist Platz für weitere Passwörter reserviert. Dieses Schließfach belegt 16 Megabyte[2] Speicherplatz. Ist der Datenträger bereits vollständig aufgeteilt – und das ist er nach jeder gewöhnlichen, unverschlüsselten Installation –, ist dafür schlicht kein Platz. Man müsste erst das Dateisystem kompliziert verkleinern, um Raum zu schaffen. Auf dem eigenen Bastelrechner mag man das riskieren. Auf dem Rechner eines Kunden werde ich das nicht tun.

Windows hat es an dieser Stelle viel leichter: Die Verwaltungsdaten von derer Verschlüsselungstechnologie "BitLocker" sind mit rund 200 Kilobyte winzig[3]. Und Microsoft überlässt nichts dem Zufall – Geräteherstellern ist zusätzlich eine mindestens 250 Megabyte große, unverschlüsselte Reservefläche vorgeschrieben[4]. Der Platz für später ist also längst da, bevor der Rechner das Werk verlässt.

Platzbedarf der reinen Verwaltungsdaten der Verschlüsselung im Vergleich. Angaben nach dem cryptsetup-Projekt und der BitLocker-Formatbeschreibung, Stand 2026.
Linux (LUKS2) 16.384 KB
Windows (BitLocker) ~200 KB

Zwei Wege, ein Ziel

Interessant wird es, wenn man beide Verfahren nebeneinanderlegt. Sie sind im selben Jahr entstanden – und haben sich seither in entgegengesetzte Richtungen entwickelt.

Jahr Linux Windows
2004 Clemens Fruhwirth entwirft LUKS als offenen Standard – bewusst so, dass jedes Programm und jedes System damit umgehen kann[5]. Microsoft beginnt unter dem Decknamen „Cornerstone" mit BitLocker, von Anfang an eng an den Sicherheitschip gebunden[6].
2007 Verschlüsselung ist längst bei allen großen Distributionen im Installationsprogramm angekommen – kostenlos, für jeden. BitLocker erscheint mit Windows Vista, aber nur in den teuersten Business-Versionen. Privatanwender bleiben jahrelang außen vor.
2019 Das Nachfolgeformat LUKS2 wird Standard: stärkerer Schutz gegen das Durchprobieren von Passwörtern, ein doppelt gesichertes Schließfach – und eben jene sechzehn Megabyte Reserve. Verschlüsselung wandert in die Pro-Ausgabe. Die Home-Ausgabe bekommt nur eine abgespeckte Automatik ohne Wahlfreiheit.
Heute Mehrere Projekte arbeiten unabhängig voneinander daran, das Nachrüsten zu automatisieren. Nachrüsten ist einfach – dafür entscheidet vieles andere der Hersteller.

Und jetzt der Haken auf der anderen Seite

Denn so bequem BitLockers Nachrüstbarkeit ist – sie hat einen Preis, und der heißt Unbeweglichkeit. Ohne einen Sicherheitschip der Version 2.0 auf der Hauptplatine läuft die Verschlüsselung in der Home-Version von Windows überhaupt nicht[7]. Wer einen älteren Rechner ohne diesen Chip hat, hat schlicht Pech gehabt – es sei denn, er kauft sich die Pro-Version (199$) und schaltet dort über eine Systemrichtlinie frei, was ihm sonst verwehrt bleibt; danach muss er bei jedem Start ein Passwort eintippen oder einen Stick einstecken. Verschlüsselung, die vom Alter der Hauptplatine abhängt.

Linux kennt diese Bedingung nicht. LUKS läuft auf meinem Notebook von 2008 (auf dem dieser Blog-Artikel geschrieben wurde) genauso wie auf einem Neugerät – der Sicherheitschip ist dabei eine optionale Sicherheitserweiterung, keine Voraussetzung. Genau darin liegt der Unterschied, der in meiner Werkstatt zählt: Ich arbeite mit aufbereiteten Geräten, und ein Kriterium wie "Dein Rechner ist zu alt, um deine Daten zu schützen" kann ich mir nicht erlauben.

Dazu kommt eine zweite Sache, über die man selten spricht: Bei Windows Home wandert der Wiederherstellungsschlüssel – der Generalschlüssel zu allen Daten – automatisch ins Microsoft-Konto, sobald man sich mit einem solchen Konto anmeldet. Das steht so in Microsofts eigener Dokumentation[8]. Nur mit einem lokalen Konto bleibt er im Haus. Linux hat dieses Problem nicht – es gibt dort schlicht keinen Hersteller, der mithören könnte. Sichern kann man ihn deshalb trotzdem.

Was sich gerade bewegt

Bleibt die unbequeme Frage, die ich mir während der Recherche selbst gestellt habe: Open Source, schön und gut – warum hakt es dann ausgerechnet an so einer wichtigen Stelle? Die Antwort war für mich die eigentliche Überraschung.

Bei openSUSE liefert man Systeme seit Ende 2023 zunächst unverschlüsselt aus. Beim allerersten Start verkleinert ein Skript die Systemfläche selbsttätig um die nötigen Megabyte und verschlüsselt sie im laufenden Betrieb nach – der Anwender erfährt davon nur durch den Wiederherstellungsschlüssel, den er sich anschließend notieren soll[9]. Seit August 2025 steckt dasselbe Verfahren fest im offiziellen Installationsprogramm[10]. Ubuntu hat mit der Version 26.04 die chipgestützte Verschlüsselung für serienreif erklärt und benennt im eigenen Blog offen, was noch fehlt: das nachträgliche Verschlüsseln selbst[11]. Und beim cryptsetup-Projekt diskutiert die Gemeinschaft öffentlich über ein kleineres Schließfach für genau solche Fälle[12].

Und hier schließt sich der Kreis: Die sechzehn Megabyte, über die ich gestolpert bin, sind kein Versehen. Sie sind Reserve. Damals bereits bewusst eingeplant für Erweiterungen, die noch gar nicht erfunden waren – und genau dieser Platz ist es, den openSUSE heute benutzt, um das Problem zu lösen, das er scheinbar verursacht. Wer auf Jahrzehnte baut statt auf das nächste Verkaufsargument, sieht kurzfristig manchmal älter aus.

Dass es dabei rumpelt, gehört dazu. Ubuntus neues Installationsprogramm verlor zwischenzeitlich sogar die Fähigkeit, bestehende verschlüsselte Systeme überhaupt zu erkennen[13]. Aber jede dieser Entscheidungen ist nachlesbar. Als das openSUSE-Team jahrelang bewusst beim älteren Verfahren LUKS1 blieb, obwohl das neuere LUKS2 längst bereitstand, stand die Begründung öffentlich in der Mailingliste: Der Startlader war noch nicht so weit, und den Anwender vor einem nicht mehr startenden System zu bewahren wog schwerer als Aktualität um jeden Preis. Bei einem geschlossenen Produkt hätte man diese Abwägung nie zu Gesicht bekommen – man hätte nur das Ergebnis vorgesetzt bekommen.

Ehrlich bleiben: für wen das zählt

Für Privatleute ist die ganze Sache selten dringend. In aller Regel weiß man vorher, ob man Verschlüsselung möchte – und wenn nicht, sichert man im schlimmsten Fall seine persönlichen Dateien und setzt einmal neu auf. Ärgerlich, aber an einem Nachmittag erledigt.

Als Dienstleister sieht meine Rechnung anders aus. Zwanzig bereits ausgelieferte Firmenrechner setzt niemand neu auf, weil ein halbes Jahr später ein Auftrag mit sensiblen Daten hereinkommt oder eine Versicherung Verschlüsselung verlangt. Was für den Einzelnen ein Nachmittag ist, ist für einen Betrieb eine Woche Stillstand. Deshalb löse ich das lieber vorher: Meine Installationen werden künftig von vornherein mit dem entsprechenden Puffern geplant. IM Nachgang kann jeder Kunde selbst entscheiden: Verschlüsseln oder nicht - wie bei Windows.

Was ich an deiner Stelle täte

  1. Weißt du schon vorher, dass du verschlüsseln willst: gleich bei der Installation einrichten. Dort kostet es keinen zusätzlichen Handgriff.
  2. Bist du unschlüssig, willst dir die Tür aber offen halten: beim Einrichten bewusst nicht die volle Plattengröße vergeben, sondern am Ende etwas Platz frei lassen. Auf einer heutigen Platte fällt das nicht ins Gewicht.
  3. Betreust du mehrere Geräte, etwa als Betrieb: das Freilassen zum festen Bestandteil jeder Auslieferung machen, nicht dem Einzelfall überlassen. Genau das lege ich mir gerade in meiner eigenen Installationsanlage zurecht.

Zum Schluss

Der Nachteil, mit dem dieser Artikel begann, ist echt – ich habe ihn nicht erfunden, um am Ende doch wieder Werbung für Linux zu machen. Er hat mich ein Wochenende gekostet. Aber je tiefer ich gegraben habe, desto klarer wurde: Was hier fehlt, ist Bequemlichkeit. Was dafür nicht fehlt, ist die Freiheit, es selbst in Ordnung zu bringen – ohne auf jemanden zu warten, der es einem verkauft. BitLocker versteckt seine Kompromisse hinter Komfort. Linux legt seine offen hin. Nur deshalb konnte ich sie überhaupt finden – und nur deshalb konnte ich sie umgehen.

Quellen

Stand dieses Artikels ist August 2026. Wer das später liest, prüft besser nach:

  1. Praxis-Workshop „TPM 2.0 unter Linux", zur Geschichte des Chips und seiner heutigen Rolle beim Entsperren verschlüsselter Datenträger: Linux-Magazin, Martin Loschwitz.
  2. Standardgröße des LUKS2-Schließfachs von 16 MB seit cryptsetup 2.1.0, samt Begründung (Reserve für spätere Erweiterungen): cryptsetup 2.1.0 Release Notes (englisch).
  3. Aufbau und Größe der BitLocker-Verwaltungsdaten: irq5.io (englisch).
  4. Vorschrift für eine mindestens 250 MB große, unverschlüsselte BitLocker-Systemfläche bei Geräteherstellern: Microsoft Learn.
  5. Entstehung von LUKS 2004 als plattformunabhängiger Standard: Wikipedia (englisch).
  6. Entstehung von BitLocker ab 2004 unter dem Decknamen „Cornerstone", Verfügbarkeit zunächst nur in Ultimate und Enterprise: Wikipedia.
  7. Sicherheitschip 2.0 als Voraussetzung der Geräteverschlüsselung unter Windows Home, Umgehung nur über die Pro-Ausgabe samt Passwort oder Stick bei jedem Start: PC-WELT und heise.
  8. Automatische Sicherung des Wiederherstellungsschlüssels im Microsoft-Konto bei aktivierter Geräteverschlüsselung: Microsoft-Support.
  9. Selbsttätige Nachverschlüsselung beim ersten Start in openSUSE (Dezember 2023): openSUSE News (englisch).
  10. Aufnahme desselben Verfahrens in das offizielle Installationsprogramm (August 2025): openSUSE MicroOS Blog (englisch).
  11. Chipgestützte Verschlüsselung in Ubuntu 26.04, mit dem Hinweis, dass nachträgliches Verschlüsseln noch nicht unterstützt wird: OSTechNix (englisch).
  12. Offene Diskussion um ein kleineres LUKS2-Schließfach: cryptsetup-Projekt auf GitLab (englisch).
  13. Verlust der Erkennung bestehender verschlüsselter Systeme im Ubuntu-Installationsprogramm seit Version 23.10: Thomas Horsten (englisch).

Fragen oder Widerspruch? Schreib mir.