Wir rennen sehenden Auges in ein massives Abhängigkeitsproblem.
Behörden erzwingen faktisch Microsoft-Software – Windows, Office, proprietäre Formate.

Jetzt kommt die nächste Eskalationsstufe: Secure Boot, TPM, Pluton, „Secured-Core PCs“.
Verkauft als Sicherheit – real bedeutet es Kontrolle über die Boot- und Vertrauenskette.

Wenn es nach Microsoft geht, läuft auf deiner eigenen Hardware künftig nur noch Software,
die Microsoft signiert und erlaubt.
Schlüssel können geändert oder revoked werden – auch nachträglich.

#Vendor-Lock-in auf Hardware-Ebene.

Echte Sicherheit gibt es nur mit:
offenen Standards, offenen Dateiformaten, Open Source
und Kontrolle über die eigenen Master Keys.

Deutschland war mal bekannt für kluge Köpfe.
Technisch gibt es sie noch – politisch sieht man die Abhängigkeit nicht,
weil das Brett vor dem Kopf „Windows“ heißt.

#DigitaleSouveränität #OpenSource #Linux #OffeneStandards #Microsoft
#VendorLockIn #TPM #SecureBoot #Pluton #SecuredCore #Behörden #ITSecurity

Wer #SecureBoot, #TPM und #Pluton fremdkontrolliert akzeptiert,
nimmt in Kauf, dass Eigentum nur noch Nutzungsrecht auf Widerruf ist.

Hardware ohne Schlüsselkontrolle ist keine eigene Hardware mehr, sondern man bezahlt für ein Nutzungsrecht, solange man sich an Regeln hält.

@ghul Dir ist schon klar, dass man die eigenen Secure Boot Keys ausrollen kann, oder? Ich benutze meine Eigenen mit Gentoo Linux für Measured Boot. Kein Windows lock-in auf meiner Seite.

@duxsco
Technisch ist das sauber, da widerspreche ich dir nicht, mit Gentoo / sbctl / Measured Boot, eigene Secure-Boot-Keys auszurollen.

Mein Punkt ist aber nicht, dass Secure Boot grundsätzlich unbrauchbar ist, sondern dass das eine Experten-Nische ist – und nicht die Richtung, in die sich die Plattform bewegt:

Secured-Core-PCs, Pluton, OEM-Firmware und fremdgesteuerten Update-Pfaden wird die Root-of-Trust schrittweise vom Nutzer weg verschoben.

Solange der Nutzer die Master Keys kontrolliert, ist Measured Boot sinnvoll.
Das wird aber gerade aufgeweicht:

fest verdrahtete Trust Anchors
nicht mehr abschaltbares Secure Boot
Policy-Enforcement per Firmware-Update

Was du beschreibst, ist der aktuelle Ausnahmefall – nicht der langfristige Normalzustand.

Kurz gesagt: Es funktioniert – noch.
Die eigentliche Frage ist, was passiert, wenn es außerhalb von Expertensystemen nicht mehr erlaubt ist?

@ghul Ich würde mich gerne da einlesen. Hast du irgendwelche Quellen?

@duxsco Für alle, die nach Quellen gefragt haben, wohin die Reise bei Secure Boot / TPM / Pluton geht – hier eine kleine, gut belegte Auswahl:

Microsoft Pluton Sicherheitsprozessor (offizielle Doku)
https://learn.microsoft.com/de-de/windows/security/hardware-security/pluton/microsoft-pluton-security-processor

Heise: Microsofts Sicherheitscontroller Pluton kommt auch in Intel-CPUs
https://www.heise.de/news/Microsoft-Sicherheitscontroller-Pluton-kommt-auch-in-Intel-Core-9833911.html

UEFI / Secure Boot – Kritik und Geschichte
https://en.wikipedia.org/wiki/UEFI#Criticism

Secure Boot – Hintergrund (Wikipedia)
https://en.wikipedia.org/wiki/UEFI

TPM & Secure Boot – Ängste, Zweifel und Kritik (deutsch)
https://curius.de/2022/02/kollektive-vorbehalte-gegen-tpm-und-secure-boot-aengste-unsicherheit-und-zweifel/

Niemand behauptet, Secure Boot sei per se böse.
Die Frage ist, wer langfristig die Root-Keys und die Policy kontrolliert.

Sicherheit ohne Nutzersouveränität ist Policy Enforcement.

#SecureBoot #TPM #Pluton #DigitaleSouveränität #OpenSource #Linux #VendorLockIn #ITSecurity

Microsoft Pluton-Sicherheitsprozessor

Weitere Informationen zum Microsoft Pluton-Sicherheitsprozessor

@ghul @duxsco Ich hatte bis gestern einen Laptop der nur noch meinen Kernel gebootet hat auch keinen Windows-Installer mehr. Dank TPM2.
Dummerweise hat ein dist-upgrade aber das setup geschrottet:
Jetzt ist ein grub drauf der nichts darf :(
Ja ich habe ein backup und ja ich werde das wieder so aufsetzen:
https://blastrock.github.io/fde-tpm-sb.html
The ultimate guide to Full Disk Encryption with TPM and Secure Boot (with hibernation support!)

@giggls @duxsco
ff 😅 willkommen im Club der „es war perfekt, bis es das nicht mehr war“-Setups.
Secure Boot + TPM: großartig … solange man sie nicht selbst anfassen muss.

Dass am Ende nur noch dein Kernel gebootet hat, ist eigentlich ein Qualitätsmerkmal.
Dass jetzt ein GRUB da sitzt, der nichts darf, leider auch.

Gut, dass du ein Backup hast – schlecht, dass du es jetzt wirklich brauchst.
Aber hey: immerhin weißt du, warum es kaputt ist. Luxusproblem 😉

Genau solche Momente sind der Grund, warum ich sage:
Sicherheit ohne schnellen Notausgang ist nur eine zeitverzögerte Lektion.

Viel Erfolg beim Rebuild – und möge der nächste dist-upgrade gnädiger sein 🍻

(Ich mache Secure Boot immer aus, ist besser für einen ruhigen Schlaf)

@ghul @giggls Ich meide GRUB. Ist mir zu aufgebläht. Und mein Setup setzt auf systemd-cryptenroll oder Clevis/Tang.
@duxsco @ghul Hm was ist denn der empfohlene Weg unter Debian 13 für so etwas? Mein setup war es offensichtlich nicht.
@giggls @ghul Keine Ahnung. Ich benutze nur Gentoo.
Debian with LUKS and TPM auto decryption | fernvenue's Blog

Recently, I just upgraded and reassembled an ITX daily computer. Considering that there is a native TPM chip, I decided to use LUKS with TPM autodecryption to ensure data security without affecting normal remote connections after Wake on LAN and other functions. However, I quickly found that although the Debian installer provided methods to configure LUKS, there were still some minor issues during the TPM configuration stage after entering the system. Here, I will briefly document the configuration process for future reference.