Ein möglichst offenes und ein möglichst vertrauenswürdiges System widersprechen sich manchmal. Besonders deutlich wird dies beim Thema Verified Boot unter Linux.
Linux kennt mit LUKS/cm-crypt eine gute und sichere Verschlüsselungslösung. Man kann ein solchermaßen verschlüsseltes System sogar zusätzlich mit einem Hardware-Token wie z. B. einem YubiKey absichern. Doch woher weiß man beim Hochfahren eines Systems eigentlich, das man ein unverändertes System startet und nicht eine heimlich manipulierte Variante?
Ein sogenannter Verifizierter oder Vertrauenswürdiger Start (Verified / Trusted Boot) ist bei Mobilgeräten schon länger Standard. Der Ansatz ist – stark vereinfacht dargestellt – eine Vertrauenskette vom Bootloader, über die Boot-Partition bis hin zu den verifizierten System-Partitionen. Während des Systemstarts überprüft jede Stufe die Integrität und Sicherheit der nächsten Stufe, bevor sie übergibt. Erkennt das System eine Manipulation, führt es automatisch einen Rollback zur letzten verifizierten Version durch.
Klassische Desktop- oder Notebooksysteme kennen so etwas nicht. Das meist völlig ungesicherte BIOS erlaubt den Start von jedem beliebigen Medium und sofern man dabei nicht den Bootloader versehentlich zerstört, kann man so ziemlich alles mit dem System machen, was man möchte.
Apple hat das Prinzip des Verified Boot bereits vor längerer Zeit auf den Desktop gebracht mit den sogenannten T1/T2 Sicherheitschips. Der T1 brachte die Secure Enclave vom Mobilgerät auf das MacBook bzw. den iMac, der T2 brachte den sichereren Start.
Bei normaler Desktop-/Notebook-Hardware wäre so etwas theoretisch auch möglich. Microsoft hat vor einigen Jahren mit Secure Boot versucht, einige Schritte in diese Richtung zu unternehmen. Aus der ersten Debatte um diese Funktion hat sich leider in der Linux-Community das Gerücht gehalten, dass man Secure Boot immer deaktivieren sollte. Dabei funktionieren professionelle Linux-Distributionen schon lange mit Secure Boot (und alle anderen verwendet man sowieso nicht, wenn einem Sicherheit wichtig ist).
Alle heute verkauften Geräte haben zudem einen sogenannten TPM-Sicherheitschip (verdankt man den Basis-Anforderungen von Microsoft). Die neueste systemd-Version unterstützt nicht nur die Bindung der LUKS-Verschlüsselung an diesen TPM-Chip, sondern SUSE hat auch eine Implementierung von Trusted Boot für GRUB entwickelt (mehr Informationen dazu), die theoretisch mit dem TPM-Chip zusammen arbeitet.
Meiner Meinung nach sind das sinnvolle Schritte in die richtige Richtung. Wie immer stört das natürlich die Frickler und Bastler in der Community, aber wenn man im Bereich Sicherheit am Ball bleiben möchte, kann man diese Entwicklung nicht ignorieren.
Secure Boot ist unter openSUSE schon lange kein Problem mehr, mit der nächsten systemd-Version werde ich mein LUKS-Systemvolume auch an den TPM-Chip binden. Danach folgt dann TrustedGRUB/Trusted Boot aber hier scheint es noch wenige Erfahrungen und folglich auch wenige Bericht zu geben.
Schön und gut. Das setzt voraus, dass man SystemD vertraut (das Thema hatten wir hier ja schon mal). Ich hab‘ es da eher mit simplen Lösungen: Die /boot-Partition auf einen USB-Stick kopieren/verschieben und diesen beim verlassen des Rechners in die Tasche stecken. Die anderen Partitionen sind ja eh verschlüsselt. Solange man dann konsequent von diesem Stick bootet, gibt’s da keine Sicherheitsprobleme.
Das ist solange eine Lösung wie man den Signierschlüssel auch selbst im BIOS setzen kann, in dem Moment in dem ich darauf angewiesen bin dass eine dritte Partei mir meinen bootloader signiert ist der Sicherheitsgewinn hinfällig (mein hp Notebook frisst nur MS signierte Keys, verboten gehört sowas…)
Ich kann bei meinem EliteBook individuelle Schlüssel hinterlegen.