Es gibt vor allem in Deutschland kollektive Vorbehalte gegen moderne Techniken wie TPM oder Secure Boot. Sie sind nicht exklusiv für die Linux-Gemeinschaft, aber dort besonders stark verbreitet. Diese sind nicht auf Fakten gegründet, sondern basieren auf langjährig gepflegten Mythen.
Ich beschäftige mich aktuell ja mit Themen wie TPM. Ein Thema, um das ähnlich wie um Secure Boot unfassbar viel Fear, Uncertainty and Doubt (FUD) gestreut wird. Das ist keinesfalls von Nischenphänomen, sondern findet sich an hochkarätiger Stelle.
Die englischsprachige Wikipedia schreibt in ihrem Artikel als Einleitung zu TPM:
Trusted Platform Module (TPM, also known as ISO/IEC 11889) is an international standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. The term can also refer to a chip conforming to the standard.
TPM is used for digital rights management (DRM), Windows Defender, Windows Domain logon, protection and enforcement of software licenses, and prevention of cheating in online games.
One of Windows 11’s system requirements is TPM 2.0. Microsoft has stated that this is to help increase security against firmware and ransomware attacks.
Und weiter:
Overview
Trusted Platform Module provides
Wikipedia, Artikel „Trusted Platform Module“ unter Creative Commons Attribution-ShareAlike 3.0 Unported License (abgerufen am 08. Februar 2022.
A hardware random number generator
Facilities for the secure generation of cryptographic keys for limited uses.
Remote attestation: Creates a nearly unforgeable hash key summary of the hardware and software configuration. One could use the hash to verify that the hardware and software have not been changed. The software in charge of hashing the setup determines the extent of the summary.
Binding: Encrypts data using the TPM bind key, a unique RSA key descended from a storage key[clarification needed].
Sealing: Similar to binding, but in addition, specifies the TPM state for the data to be decrypted (unsealed).
Other Trusted Computing functions for the data to be decrypted (unsealed).
Der deutschsprachige Artikel beginnt mit:
Das Trusted Platform Module (TPM) ist ein Chip nach der TCG-Spezifikation, der einen Computer oder ähnliche Geräte um grundlegende Sicherheitsfunktionen erweitert. Diese Funktionen können beispielsweise dem Lizenz- und Datenschutz oder der nachrichtendienstlichen Kontrolle dienen. Der Chip verhält sich in einigen Punkten wie eine fest eingebaute Smartcard, allerdings mit dem wichtigen Unterschied, dass er nicht an einen konkreten Benutzer, sondern an den lokalen Computer gebunden ist. Außer der Verwendung in PCs und Notebooks kann das TPM in PDAs, Mobiltelefonen und Unterhaltungselektronik integriert werden. Ein Gerät mit TPM, speziell angepasstem Betriebssystem und entsprechender Software bildet zusammen eine Trusted-Computing-Plattform (TC-Plattform). Eine solche „vertrauenswürdige Plattform“ kann nicht mehr entgegen den Interessen des Herstellers genutzt werden, sofern dieser Beschränkungen festgelegt hat. Ein möglicher Vorteil für einen normalen Benutzer eines solchen Systems liegt im Schutz gegen softwareseitige Manipulation durch unbefugte Dritte.
Der Chip ist aktuell überwiegend passiv und kann weder den Bootvorgang noch den Betrieb direkt beeinflussen. Er enthält einen eindeutigen kryptografischen Schlüssel und kann damit zur Identifizierung des Rechners genutzt werden. Das ist jedoch nur möglich, wenn der Eigentümer das Auslesen dieser Information auch gestattet hat. Bei x86-basierten PCs konnte das TPM bisher im BIOS vollständig deaktiviert werden, so dass keine seiner Funktionen zur Verfügung steht. Allerdings gibt es immer mehr Anwendungen, die nur auf einer TC-Plattform mit aktiviertem TPM laufen, wie es z. B. bei Windows seit der Version 11 der Fall ist.
Wikipedia (de.), Artikel „Trusted Platform Module“ unter Creative Commons Attribution-ShareAlike 3.0 Unported
Der Unterschied ist eklatant. Der deutsche Artikel enthält in der Einleitung FUD in seiner Reinform, kaschiert und versteckt im Mantel vorgeblich neutraler Beschreibung plus den Hinweis, wie man es abschalten kann.
Das selbe Spiel kann man mit Secure Boot durchspielen. Einmal der Eintrag in der deutschsprachigen Wikipedia und einmal der Eintrag in der englischsprachigen Wikipedia. Aus Gründen der Redundanz verzichte ich hier auf die Vollzitate, denn der Mechanismus ist der Gleiche. Der Abschnitt in der deutschsprachigen Wikipedia ist tendenziös, verweist auf uralte Sicherheitslücken und hinsichtlich der Zertifikate und Shim auch nicht korrekt. (Vgl. dazu auch das Zitat weiter unten aus dem Debian Wiki)
Da wundert es einen nicht, warum in Deutschland auf die Ankündigung von Microsoft, künftig in Windows 11 TPM 2.0 zur Voraussetzung zu machen, so viel Unsicherheit und Vorbehalte vorherrschten. Dabei ist das langfristig die richtige Entscheidung von Microsoft. Ein etwas überzeichneter Artikel dazu, der aber vielleicht für manchen gewinnbringend sein kann: Packungsbeilage TPM.
In einigen Kreisen – besonders gerne bei Open Source-Anhängern – herrschen bezüglich solcher Techniken wie TPM oder Secure Boot unglaubliche Vorbehalte, die teilweise auf langjährig gepflegten Mythen basieren und bei denen einem abstrakten Risiko erstaunlich selten der konkrete Nutzen gegenüber gestellt wird. Die Ursache dafür liegt meiner Ansicht nach in alten Berichten, die vor vielen Jahren Angst geschürt haben. Das ist irgendwie bei vielen Lesern – vor allem im deutschsprachigen Raum – hängen geblieben. Das hat man inzwischen selbst bei den ursächlichen Medien eingesehen, die heute kritisch auf die eigene damalige Berichterstattung schauen und festhalten, dass daran nichts dran ist.
Noch erstaunlicher ist, dass die FUD-Verbreiter in der Linux-Community sogar gegen die eigenen Knowledge-Bases – die offiziellen Wikis der Distributionen – argumentieren. Dazu kann man beispielsweise auf die tollen Artikel zu TPM und Secure Boot im Arch Linux Wiki verweisen, aber auch konservativere und auf Freiheit bedachte Distributionen wie Debian haben das längst sauber dokumentiert:
What is UEFI Secure Boot NOT?
UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.
SB is also not meant to lock users out of controlling their own systems. Users can enrol extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries.
Debian Wiki Artikel Secure Boot (zuletzt abgerufen am 08.02.2022)
Aus diesem Grund hat man viel zu lange in der Linux-Community Bausteine wie Secure Boot oder TPM links liegen gelassen und es kursieren abenteuerliche Anleitungen für Einsteiger, wie böse Secure Boot ist und was sie alles in UEFI-Settings deaktivieren sollten, bevor sie Linux installieren können.
Die Zukunft gehört solchen Technologien, denn die Sicherheitskonzepte von vor 20 Jahren sind halt auf die Bedrohungen von vor 20 Jahren gemünzt. Heute speichern wir andere Daten auf den Geräten, nutzen sie für andere Zwecke und sind anderen Bedrohungsszenarien ausgesetzt. „Mein System ist Open Source und ich gebe ein Passwort beim Start ein“ ist kein alleinig ausreichendes Sicherheitskonzept mehr. Passend zum Thema sind kürzlich die neuen Sicherheitsrichtlinien der US-Regierung herausgekommen (die natürlich weit darüber hinausgehen). Das BSI wird sicher irgendwann nachziehen und wenn man nicht wünscht, dass Linux eines Tages offiziell vor der Tür bleiben muss, weil es elementare Sicherheitsstandards nicht erfüllt, dann ist jetzt die Zeit proaktiv mit der Implementierung zu beginnen.
Mobile Plattformen und macOS haben vorgemacht, wohin die Reise geht und Windows zieht hier mit der neuen Version Windows 11 konsequent nach. Dabei schließen sie dankenswerterweise die PC-Plattform nicht ab, sondern ermöglichen es Linux ebenfalls von diesen Entwicklungen zu profitieren.
Also hört auf jedem zu raten, Secure Boot und TPM zu deaktivieren und blockiert nicht TPM über die Modul-Blacklist – es sei denn, ihr versteht wirklich, warum ihr was tut.
Ich frage mich ja ob die Vorbehalte gegenüber Sercure Boot nur Hysterie waren, oder ob der Gegenwind nicht auch dafür gesorgt hat das es letzten Endes doch mit dem FOSS Gedanken kompatibel geworden ist. Ich meine die Option, das man extra keys eintragen oder austausche kann, hätte man ja durchaus mit dem verweis auf Sicherheitsbedenken nicht liefern müssen. Genau das war ja damals die Befürchtung. Es ist bisher nicht so gekommen und wird auch hoffentlich nie kommen, aber bei Secure boot geht es letztlich nur um eine chain of trust. Und wer das erste Stück kontrolliert hält alle Karten in der Hand. Das das eine abstrakte Bedrohung für FOSS ist, muss man schon respektieren. Ein Argument großflächig Secure Boot aus zu schalten ist es natürlich auch nicht.
Ja, das ist gut möglich. Unabhängig davon wäre es natürlich auch wünschenswert, wenn nicht Microsoft, sondern eine unabhängige dritte Partei für die Zertifizierung zuständig wäre. Dieser Mangel ergibt sich aber halt an Microsofts Anteil am PC-Markt und sollte kein Grund für einen vollständigen Boykott sein.
Das ist eine in sich absolut unlogische Argumentationskette.
Der Post heir ist nicht weniger tendenziös als die allwissende Müllhalde.
Auge um Auge, Zahn um Zahn?
Inwiefern?
Solange ich als Benutzer nicht die Kontrolle darüber habe, wird es gegen den Benutzer gewandt und muss praktisch weg! Alles andre wäre sich selbst belügen.
Es kommt halt auf die Implementierung von z.B. Secure-Boot an. Kann ich eigene Schlüssel hinzufügen? Kann ich Schlüssel löschen? Wenn nicht, ist es eine Technologie, um ein geschlossenes Ökosystem ab zu liefen. Solche Systeme sollte man nicht kaufen.
Wie das jetzt mit TPM aussieht, weiß ich nicht genau, da ich mich damit bisher nicht ausführlich beschäftigen konnte. Wenn ich aber sehe, dass Microsoft alte Computer vom neuen Windows ohne Grund aussperrt, dann frage ich mich, ob die noch alle Tassen im Schrank haben… denn sie nutzen die Software bereits jetzt indirekt gegen den Nutzer. Hey, du klemmst TPM ab, dann kriegst du keine Patches mehr. Was soll das? Das ist Erpressung! Entweder muss dann TPM weg, oder Linux her…
Das meine ich mit FUD: Ängste, Unsicherheit und Zweifel, mit der Gewissheit vorgetragen, wirklich Fakten zu kennen.
Du setzt für deine Argumentation Sachen voraus, die so einfach nicht stimmen. UEFI kann Schlüssel hinzufügen und entfernen. Wenn es irgendwelche Budget-Hardware nicht unterstützt ist das ein Argument gegen die Hardware und nicht gegen das Prinzip. (Fehlende Treiber sind z. B. schließlich auch kein Argument gegen Linux, sondern gegen die Hardwarehersteller) Und selbst wenn das nicht ginge, ignorierst völlig das Prinzip der Zertizierungskette/-stelle, das es ja auch jenseits von Secure Boot gibt.
Du hast dich nicht mit TMP und seinen Vor- und Nachteilen befasst, aber triffst eine Aussage und schmeißt noch gleich den Updateprozess bei Windows mit in den Topf. Dabei gibt es für Windows 10 noch bis Oktober 2025 Support und betroffen ist nur Hardware, die älter als 2016 ist. Nur um die neuen Kriterien für Windows 11 mal einzuordnen.
Wer Freiheit opfert, um Sicherheit zu erlangen, verliert am Ende beides. Genau darum gehts am Ende. Aber hey, man hat ja mal darüber nachgedacht (nicht).
Ich habe genug von UEFI gesehen, um es scheiße zu finden. Da gab es an der Arbeit Tablets mit Windows 8. Diese konnte man nicht upgraden, weil man eben keinen neuen Schlüssel eintragen konnte. Die Geräte konnte man nur in den Müll werfen! Super NICHT.
Bei meinem privaten PC habe ich mich auch gegen den Mist entschieden. Das U im Efi abgestellt, weil man immer erst einen neuen Schlüssel besorgen und installieren muss. So kann ich einfach ein Linux Iso nehmen, auf die Platte pappen und läuft. Oder eine andre Platte via Hot-Swap einlegen und das Linux einfach nutzen und muss nicht mit Keys herumhantieren.
Genauso am Handy. Warum muss ich erst den Bootloader freischalten in komplexer weise, um ihn dann wieder verschließen zu können! Bei Handys wo, das gar nicht geht, kann ich die Dinger wegwerfen, wie das Tablet. Da wird man nie etwas andres drauf bekommen, wie das der eingetragene Schlüssel zulässt. Also ist das Gerät abgeriegelt und niemals frei, also Müll. Und so ein Dreck soll man unterstützen? NEIN! TPM ist noch mal ne andre Kiste – kann aber wohl auch gegen den Benutzer angewandt werden. Zuvor war so was kaum bis gar nicht möglich. Ich wusste, ich kaufe einen PC und kann damit machen, was ich will und muss nicht extra mich mit Keys beschäftigen…. und ob man diesen Mechanismus nicht abstellen oder zu meinen Gunsten editieren kann.
Das Ziel sollte logisch sein, damit der Normalnutzer, nicht wie jetzt, einfach Linux installieren kann. Denn er müsste sich erst mal mit dem Secure-Boot beschäftigen. Dann hört der ganz schnell wieder auf und bleibt bei Windows. Ziel erreicht. Mit Scure-Boot will Microsoft nur den Nutzer daran hindern, auf Linux zu wechseln. Daher einfach Secure-Boot im Bios abschalten ist das einfachste. Und als Bonus bleibt man flexible und muss nicht für jede Distribution neue Schlüssel suchen.
Für Firmen mag das anders aussehen, die brauchen oder wollen ja diese Flexibilität anscheint nicht. Das ist aber dann nicht mein Problem. Daher nein zum Secure-Boot Scheiß! Das kommt aus der Praxis und nicht aus irgend einem Theorie-Buch…
Und noch mal FUD:
Der normale Anwender kann auf seiner Secure Boot-Hardware problemlos jedes verbreitete Linux installieren. Er hat also keine Probleme – es sei denn ihm reden Supporter mit Halbwissen Quatsch ein – und profitiert vom Mehr an Sicherheit.
Der Rest, den du schreibst ist schlicht und einfach falsch (z. B. „Das U im Efi abgestellt, weil man immer erst einen neuen Schlüssel besorgen und installieren muss.“) und hinsichtlich der Sicherheit hanebüchener Unsinn, wie dein Wunsch, dass jedes Smartphone mit entsperrtem Bootloader geliefert werden soll. Was für ein Albtraumszenario.
Hast du dich wirklich schon mal systematisch damit beschäftigt?
Natürlich gibt es denkbare Anwendungsfälle, bei denen es Sinn macht kein Secure Boot zu nutzen. Genau deshalb kann man es ja deaktivieren. Das betrifft aber nur eine winzige Minderheit und die weiß, was sie tut.
Ich finde gut dass Du festlegst was normal und verbreitet ist und was nicht, aber „auf […] Secure Boot-Hardware problemlos jedes verbreitete Linux installieren“ regt mich an zu fragen: hast Du das mal vollumfänglich überprüft?
Fangen wir mal an:
– Debian
– Ubuntu und alle offiziellen und inoffiziellen Derivate (inkl. eOS)
– SUSE / openSUSE
– Fedora
– RHEL und alle Klone
– Arch Linux nicht ootb aber sehr gute Anleitung im Wiki, das reicht für die Zielgruppe.
Klar, du findest jetzt bestimmt die superwichtige Distribution yzz, um Kritik zu üben. Sorry, ich nehme es gleich vorweg: Irrelevant. Die Distributionen oben decken vermutlich 95 % der Desktopnutzer ab.
Gibt es eigentlich Untersuchungen darüber, wie groß der Sicherheitsgewinn durch Secure-Boot in der Praxis ist? Laut Medienberichten scheinen Ransomware-Angriffe zur Zeit eine große Gefahr für private Desktopnutzer aber auch Institutionen zu sein. Gibt es Erkenntnisse darüber, ob z.B. Systeme mit aktiviertem Secure-Boot weniger oft von erfolgreichen Angriffen betroffen sind?
Eine Idee, die zwar in der Theorie nutzen bringt, in der Praxis aber hauptsächlich Aufwand, kann ja nicht das Ziel sein.
Secure Boot hilft v.a. gegen Schadsoftware, die sich tief ins System einnistet. Auch wenn es eine zweifelhafte Quelle ist, aber die NSA rät zu Secure Boot: https://www.heise.de/news/Empfehlungen-Die-NSA-raet-zu-UEFI-und-Secure-Boot-4902884.html
Als einzelner Baustein dürfte Secure Boot vermutlich nicht viel bewirken, aber es ist halt die Grundlage für einen verifizierten Start und das ist durchaus wichtig und kann Schadsoftware verhindern. Einige Bausteine dafür hat Linux ja bereits (verifizierte Kernel-Images), andere sind in der Pipeline (initrd-Verifizierung). Da wird sich vermutlich die nächsten Jahre viel tun. Das meiste davon bekommen normale Anwender dann gar nicht mehr mit.
Ob es das wirklich braucht, hängt vom Betrachtungswinkel ab. Es gibt Leute, die hatten mit 25 Jahren Windows-Nutzung noch nie Schadsoftware. Glück oder Verstand? Herausfinden will man es besser nicht.
Ich persönlich vermute halt, dass Einrichtungen wie das BSI gewisse Sicherheitsmaßnahmen irgendwann „empfehlen“ werden und wenn Linux das dann nicht kann, ist es Aus im Firmeneinsatz, weil niemand dort das Risiko eingeht, gegen eine BSI Empfehlung/Richtlinie whatever zu verstoßen.
„Linux“ muss das natürlich können. Ich frage mich aber ganz ehrlich als Linux-Desktop und Servernutzer, ob ich das persönlich brauche. Bisher habe ich Secure-Boot und TPM meist abgeschaltet. In der Praxis verursachen diese Technologien unter Linux etwas mehr Aufwand. Zudem gibt es das potentielle Risiko, das man u.U. die Kontrolle über die eigene Hardware verliert. Dagegen stehen potentielle Sicherheitsbedrohungen, die z.B. durch Secure-Boot abgefangen werden könnten. Mir kommt das ein bisschen so vor, als würde ich sehr einbruchssichere Fenster einbauen lassen aber ein unsicheres Schloss in der Haustür haben. Die Haustür sind in dem Fall die „normalen“ Bedrohungen, die ich mir über E-Mail, zugesandte Dokumente, Webseitenbesuch oder gehackte Softwarerepositories einfangen könnte. Und der Schaden kann meist sogar mit Userrechten und ohne Boot-Integration erfolgen.
„Ich frage mich aber ganz ehrlich als Linux-Desktop und Servernutzer, ob ich das persönlich brauche“
Ich denke das kann man auf den ganzen Bereich „Sicherheit, die über die Standardkonfiguration hinausgeht“ ausdehnen, z. B. Vollverschlüsselung mittels LUKS etc. Das ist ja auch mit Komfortverlust verbunden.
„Mir kommt das ein bisschen so vor, als würde ich sehr einbruchssichere Fenster einbauen lassen aber ein unsicheres Schloss in der Haustür haben.“
Zum aktuellen Zeitpunkt, beim aktuellen Implementierungsgrad und bei den mannigfaltigen anderen Problemen, finde ich den Vergleich ziemlich angebracht. Ich bin halt der Meinung, dass es gut wäre das eine zu tun und das andere nicht zu lassen 😉
Als (auch) Arch-Nutzer ist für mich der von Dir oben verlinkte Archlinux-Wiki-Artikel maßgebend. Bisher war mir das für meine Archlinux-Systeme zu aufwendig. Wenn aber die Vorteile in meiner Sicht überwiegen sollten, werde ich mich wieder damit beschäftigen ;-).
Das Arch Linux Wiki ist bei solchen „advanced“-Sachen sowieso unschlagbar. Aufgrund des hohen Standardisierungsgrades, den Linux inzwischen erreicht hat, kann man das zum Glück meistens auf openSUSE umlegen.
Ich erachte den Einsatz von Verschlüsselungstechnologien nur dann für Sinnvoll, wen diese nicht dem [Kerckhoffs’ Prinzip](https://de.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip) widersprechen.
Meines Wissens nach, gibt es aber keinen offenes TPM (Software & Hardware).
Daher sehe ich nur Nachteile, wie Probleme beim Hardware Austausch usw.
Hingegen die Vorteile für mich, gefährliche, falsche und trügerische Versprechen sind, ähnlich wie bei Anti-Viren Software.
Ich lasse mich da wirklich sehr gerne eines Besseren belehren und wäre sogar sehr Froh über einen separierten Chip für Verschlüsselungsthematiken. Solange dieser aber nicht auf gänzlich offener Hard- und Software beruht, stellt sich mir die Frage, wie so ich ihm bitte Vertrauen sollte?
Das Problem hast du aber doch überall? Unsere Systeme sind voll von unfreier Firmware jenseits unserer Kontrolle. Das fängt beim der SSD-Firmware an und hört bei Intel ME auf. Das kann man durchaus grundsätzlich problematisch finden, aber deshalb jetzt ausgerechnet zwei Lösungen nicht zu nutzen, die ausnahmsweise auch mal Mehrwerte generieren könn(t)en, finde ich nicht plausibel.
Beim TPM gebe ich dir (bis zum jetztigen Zeitpunkt) recht, secure boot ist jedoch mit merklichen Problemen verbunden. Es gibt keinen Zwang der einen Hersteller verpflichtet auch andere Schlüssel als die von Microsoft zur Verfügung zu stellen. Da Windows eine fast Monopolstellung auf dem Desktop hat macht das auch kaum ein Hersteller. Ich besitze selbst zwei Computer bei denen ich die Secure Boot keys nicht selbst tauschen kann, bin also auf Gedeih und Verderb Microsoft (einer Firma von der ich genau garnichts habe) ausgeliefert, dass sie doch bitte BITTE die Bootloader meiner Distribution signieren? Selbst erstellte Kernel sind damit vollkommen unmöglich und mir bleibt garnichts anderes übrig als eine Funktion die ich im Großen und Ganzen zwar befürworte, jedoch komplett gegen mich gerichtet ist, zu deaktivieren.
Meine Hardware ist ausgemustertes Büromaterial, mehr kann ich mir leider nicht leisten und Auswahlmöglichkeiten habe ich dabei auch bestenfalls begrenzt. Vote with your wallet funktioniert hier also nicht. Solange im Standard nicht festgeschrieben ist, dass man die Schlüssel auch tauschen können muss ist secure boot, so schön es auch sein könnte, weiterhin einfach ein Stock der mir in die Speichen geworfen wird.
Das Probleme sehe ich nicht so richtig. Es ist das Prinzip einer Zertifikatskette, dass an der Spitze eine Zertifizierungsstelle ist, von der sich alles ableitet. Das ist ja bei HTTPS oder S/MIME nicht anders und da sind „dubiosere“ Firmen als Microsoft zugange. Natürlich wäre es schön, wenn dort eine unabhängige Stiftung wäre, aber das ist für mich nicht so kritisch, wie das oft dargestellt wird. Ich meine, schaue dir mal die Master-Zertifikate in deinem Browser an, was da für „Bananenfirmen“ dabei sind.
Wenn man jetzt mal außen vor lässt, dass es nicht vollends abwegig wäre, würde die NSA mit Microsoft Keys signierte „Spy“ware verwenden, und auch anerkennt, dass eine perfekte Implementierung von Secure Boot (die vielleicht mal nicht Security by obscurity bietet, sondern einzig und allein auf Basis des Keys sicher ist) abstrakt keine schlechte Sache ist, so bleibt dennoch festzuhalten, dass die große Gefahr besteht, dass dem User hier schleichend nach und nach die Gerätehoheit entzogen wird (siehe Win RT Tablets etc).
Bei Smartphones ist man es ja schon fast gewohnt, dass man eben nicht mehr mit dem Gerät machen kann, was man möchte (da bootloader gesperrt), und wenn sich das bei PCs durchsetzen sollte, sind die User unter dem Feigenblatt der Sicherheit letzten Endes von ihren Geräten ausgesperrt un abhängig von den Herstellern :/
Da ich nicht mit Betriebs- oder Regierungsgeheimnissen zu tun habe, möchte ich einfach selbst abwägen dürfen, ob mir die Sicherheit einer Chain of Trust (mit MS als root… omg) oder eben die Gerätehoheit wichtiger ist. Und ich frage mich einfach, wielange wir diese Wahlfreiheit noch haben.
Warum solltest du diese Wahlfreiheit irgendwann nicht mehr haben? Die Möglichkeit der Abschaltung wird es immer geben, weil sie für gewisse Zwecke (Entwickler, selbstgebaute Kernel etc.) immer notwendig sein wird. Bootloader entsperren geht ja auch bei den von dir erwähnten Smartphones. Vielleicht nicht bei jedem Budgetgerät aus China, aber prinzipiell eben schon.
Linux-Nutzer haben manchmal so viel Angst davor, ihre Freiheit zu verlieren, dass sie darüber prinzipiell berechtigte Sicherheitsinteressen vergessen. Ich sehe das Problem also eher umgekehrt. Es hat ja schon Jahre gedauert, bis die Distributionen state-of-the-art Verschlüsselungslösungen in ihre Installationsroutinen bekommen haben. Und noch heute gibt es schlimme Baustellen, so ist etwa die Art, in der Fingerabdrücke vom System für die Verarbeitung mit Lesegeräten gespeichert werden, mangels Sicherheitsfunktionen eine Katastrophe sondergleichen und hochgradig gefährlich. Für so etwas nutzen andere Systeme Sicherheitschips, Windows nutzt für Hello z. B. TPM, Google und Apple haben ebenfalls entsprechende Chips (Secure Enclace, Titan, TPM bei Chromebooks).
Sollte man dann nicht versuchen noch einen Schritt weiter zugehen und mittels Intel Boot Guard versuchen die Firmware gegen Manipulationen abzusichern?
Ein Beispiel dafür, MoonBounce.
Researchers Discover Dangerous Firmware-Level Rootkit
https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit
Desktop Mainboards, die ich hatte, hatte alle laut HWiNFO keinen komplett geschlossenen und verifizierbaren Intel Boot Guard aktiviert.
Im Endeffekt ist das Problem, dass hier beschrieben wird ein Sozial-Poltitisches und damit auch ein Ideologisches.
Wenn es mich persönlich betrifft, dann würde ich auf Teufel komm raus, keine harte Bindung zu Hardware-Komponenten erlauben. In manchen Szenarien mag es eine SIcherheitsgewinn sein, anders herum ist es aber auch ein Verlust von Freiheit, wenn der Hersteller keinen Abschaltung erlaubt. Es ist eine Grad-Wanderung auf Messers-Schneide.
Ich sah das Problem schon bei Android Smartphones, wo der Bootloader durch „Secure Boot“ gesperrt wurde. Ja, man kann dann sicher sein, das an Systemelementen, wie der Kernel, keine Manipulationen vorgenommen werden, anders herum ist es so, dass ein entsperrter Bootloader dann zu Folge hat, dass durch einen Einblendung bei Start der Eindruck erweckt wird, dass das System unsicher sei, was nicht der Fall ist.
Die natürlich Folge von solchen Sicherheits-Technologien ist im Endstadium die Eliminierung von Multi-Boot Systemen, worauf sich sich viele eben wehren, da besonders Linux populär dafür ist, neben Mac und Windows installiert werden zu können.
Wo könnte und sollte Secure Boot und TPM verwendet werden? Antwort: Auf Hardware, die allein nur für eine bestimmtes Betriebssystem konzipiert ist. Das bedeutet dann, dass jede Hardware nur ein Betriebssystem vorinstalliert haben sollte und eine Installation von anderen Betriebssystemen unterbunden werden sollte. Darauf läuft es dann hinaus, wenn die Hersteller diktieren.
Es gibt keine 100% Sicherheit und hat es nie gegeben. Man kann es nur schwerer machen, Sicherheits-Konzepte zu durchbrechen, aber mit Secure Boot und TPM treibt man es auf den Gipfel.
Am Ende des Tages, sollte man sich fragen:
Will man Eigenverantwortlichkeit bei Anwendern fördern, oder die Infantilisierung vorantreiben?
Secure Boot und TPM sind nur Werkzeuge, dennoch werden Sie schon jetzt so eingesetzt, sodass der Anwender bevormundet wird und das schmeckt nicht jedem.
Ich verstehe die Befürchtungen, aber kann sie nicht ganz teilen, weil damit der Eindruck erweckt wird, die Technologien seien dazu da, um andere Betriebssysteme auszusperren.
Secure Boot: Ich kann alternative Betriebssysteme installieren, wenn diese ein gültiges abgeleitetes Zertifikat der „Microsoft CA“ haben. Das hat sogar Debian, das ist also nichts nur für Enterprise-Distributionen. Oft kann ich sogar selbst Schlüssel entfernen oder hinzufügen und das System so ganz auf meine Bedürfnisse anpassen und „abschließen“.
TPM: Jedes installierte System kann TPM nutzen. Das ist ein ISO-Standard. Ja, meine Linux-Distribution könnte damit theoretisch kritische Sachen machen, aber ein gewisses Grundvertrauen muss ich dem von mir genutzten Betriebssystem entgegen bringen. Ich kann ja auch sonst oft nicht prüfen, was genau passiert.
Der Eindruck, dass der Zweck von TPM und Secure Boot das Aussperren von anderen Betriebssystem sein soll, sollte nicht hinterlassen werden.
Ich sag mal so: Auf dem Papier und in der Theorie, sollte es möglich sein Sicherheit und Individualität (sprich: Dual-Boot etc.) zu vereinen, dennoch kann diese Technologie ebenfalls zum Aussperren von anderen System genutzt werden. In der Praxis (also der realen Welt) kommt es vor, aus welchen Gründen auch immer, dass sich Secure Boot nicht abschalten lässt zum Beispiel. Auf vielen System war die Umsetzung dieser Spezifikation einfach unzureichend bis mangelhaft; das hat sich verbessert, aber nicht gravierend. Aber man sollte die Hersteller nicht dafür verurteilen, denn die Nachfrage bestimmt ja das Angebot. Da die größten Abnehmer von Computersystemen Unternehmen sind, richtet man sich danach und das färbt dann auf den Markt der Home-Anwender ab.
Ja, ich verstehe nur zu gut, dass die Nachfrage nach Sicherheit besonders von Unternehmen kommt, die sehr wohl mit kritischen Daten arbeiten. Siehe zum Beispiel das Vendor-Locking von einigen AMD Prozessoren bei DELL und Lenovo.
Hier mal das Whitepaper dazu: https://www.amd.com/system/files/documents/amd-security-white-paper.pdf
Man will sicher arbeiten und dabei so bequem wie möglich. Auf einem Laptop vom Unternehmen, wo nicht nur meine eigenen Dateien gespeichert werden, wünscht man sich Sicherheit, aber das bedeutet auch Einschränkungen hinzunehmen, da Freiheit und Sicherheit Gegensätze sind, die sich nie vereinen lassen, sondern immer Wettstreit sind. Und das finde ich auch gut so. Denn nur durch Wettbewerb und Innovation kann man gewährleisten, dass man nicht in das eine oder andere Extrem fällt.
Es wird niemals eine andere Certificate Authority als Microsoft geben. Das bedeutet, jeder der eine neue Linux Distribution lauffähig machen will muss zunächst bei Microsoft betteln gehen. In der Theorie mag die chain of trust eine gute Idee sein. In der Praxis entscheidet nun Microsoft wieder etwas mehr, welche Software ich ausführen darf. Ich sehe außerdem mehr und mehr Systeme, wo sich secure boot eben nicht mehr deaktivieren lässt. Z.B. der Billig-Laptop hier neben mir. Insgesamt sehe ich diese Entwicklung sehr kritisch. Die Annahme, gerade Microsoft hätte dies allein ins Leben gerufen, um das System sicherer zu machen, halte ich für unglaubwürdig. Wenn das so wäre, würde es einen oder mehrere legitimierte Gatekeeper über den root key geben. So ist Windows nicht nur auf fast jedem Rechner vorinstalliert, sondern Microsoft kann auch jeder Alternative zunächst den Zutritt verwehren.
Erstens kann es ja theoretisch weitere CA’s geben. Diese müssten nur die Hersteller dazu bringen, die Zertifikate vorzuinstallieren. Zweitens zertifiziert Microsoft Systeme Dritter, weshalb auch bei Budget-Geräten (btw. welche solchen das seien, sogar bei Huawei Notebooks kann man Secure Boot abstellen?) alternative Systeme lauffähig wären. Drittens würde bei Eintreten des beschworenen schlimmsten Szenarios sofort die Regulierungsbehörden einschreiten, was natürlich auch Microsoft weiß.
Die bewusste Nicht-Nutzung solcher Technologien klingt immer mehr nach Selbstmord aus Angst vor dem Tod. Linux nimmt sich damit nämlich mehr und mehr aus dem Rennen, wenn es um ernsthafte Sicherheitsanforderungen oder moderne Technologien geht (Biometrie hatten wir ja z. B. schon in einem anderen Blogartikel). Heute geht’s nicht mehr nur um Exchange und Office, sondern auch um so etwas wie „Hello for Business“, wenn es um Firmeneinsatz geht. Da kann Linux aktuell überhaupt nichts bieten.
Die Idee ist ja wie gesagt nicht schlecht. Aber man müsste es komplett anders aufziehen, von unabhängiger Seite aus. Vielleicht baut ja coreboot mal etwas.
Verified Boot gibts bei Coreboot schon. vboot –> https://doc.coreboot.org/security/vboot/index.html
Ich hab gerade diesen Blog Beitrag von Lennart Poettering (systemd lead Programmierer) gelesen und musste unweigerlich an dich denken Gerrit. Der Post ist sehr lang und sehr technisch, aber interessant fand ich seine Meinung zu secure boot unter linux aktuell (Punkt 2)
“
The trust chain matters, from the boot loader all the way to the apps. This means all code that is run must be cryptographically validated before it is run. All storage must be cryptographically protected: public data must be integrity checked; private data must remain confidential.
This is in fact where big distributions currently fail pretty badly. I would go as far as saying that SecureBoot on Linux distributions is mostly security theater at this point, if you so will. That’s because the initrd that unlocks your FDE (i.e. the cryptographic concept that protects the rest of your system) is not signed or protected in any way. It’s trivial to modify for an attacker with access to your hard disk in an undetectable way, and collect your FDE passphrase. The involved bureaucracy around the implementation of UEFI SecureBoot of the big distributions is to a large degree pointless if you ask me, given that once the kernel is assumed to be in a good state, as the next step the system invokes completely unsafe code with full privileges.
This is a fault of current Linux distributions though, not of SecureBoot in general. Other OSes use this functionality in more useful ways, and we should correct that too.“