Der systemd-Entwickler schreckt mal wieder die Linux-Gemeinde auf. Nicht ganz unerwartet befasst er sich mit der Ar,t wie die meisten Linux-Distributionen Daten verschlüsseln und Integrität gewährleisten. Ein notwendiger Weckruf für die oft bräsige Community.
Poettering befasst sich bereits seit längerem mit der Datensicherheit, LUKS und TPM. Der aktuelle Blogpost von ihm kommt daher nicht gänzlich unerwartet. Eine kurze Zusammenfassung und Bewertung kann man auch bei Golem lesen.
Einleitend befasst er sich mit dem aktuellen Status quo. Hier ist er sogar in vielen Fällen zu optimistisch, denn die Situation ist oft noch viel schlimmer.
Die meisten Distributionen verschlüsseln standardmäßig gar nicht und drängen diese Möglichkeit ihren Nutzern auch nur dezent auf. Linux ist hier schon länger deutlich unsicherer als die meisten anderen Betriebssysteme – abgesehen nur von der Windows-Home-Edition. Linux-Distributionen verschlüsseln Daten mittels einer LUKS/Cryptsetup-Lösung, die frühere verbreitete eCryptFS-Methode ist kaum noch verbreitet. Basale TPM-Unterstützung ist zwar vorhanden, wird aber kaum genutzt, obwohl (wegen entsprechender Microsoft-Vorgaben) alle halbwegs neuen Geräte einen TPM-Chip aufweisen.
Ein weiterer Baustein in der Validierungskette ist Secureboot. Hier ist Poettering wieder mal viel zu optimistisch, wenn er schreibt, dass die meisten Distributionen hierüber absichern. Insbesondere die vielen Kleinprojekte, aber auch so beliebte Distributionen wie Arch Linux oder Manjaro bieten kein Secureboot an bzw. zumindest nicht als Standard. Im besten Fall nutzt eine Distribution Secureboot und validiert via Shim Bootloader und Kernel. Eine lückenlose Valididerungskette inklusive Initrd und Betriebssystem erfolgt bei keiner Distribution. Dazu hatte ich mich hier auch schon mal geäußert. Das nicht verifizierte Initrd wird entpackt und fragt nach einem Passwort, um das LUKS-Volume zu entschlüsseln. Ab jetzt sind die Daten verfügbar. Der Benutzerlogin ist dann nur noch Kosmetik und wird von vielen LUKS-Nutzern bei Einzelnutzung auch per Autologin übersprungen.
Die aktuelle Vorgehensweise hat gleich mehrere offene Flanken. Vor allem schützt sie nicht, wenn die Festplatte physisch gestohlen oder komplett kopiert wird. Der Angreifer hat danach alle Zeit der Welt, um sich mit der Verschlüsselung und ihrer Umgehung zu beschäftigen. Ein weiteres Szenario ist die unbeobachtete Kompromittierung des Systems, genant Evil Maid Angriff.
Poettering kommt deshalb auch zu dem harten Schluss, dass alle anderen Betriebssysteme – ChromeOS, Android, Windows und macOS – die Daten der Anwender besser schützen.
Zur Abhilfe schlägt Poettering einige Punkte vor. Initrd müsste beim Start authentifiziert werden, ebenso das System unter /usr (was einen vollständigen usr-merge voraussetzt – Hallo Debian) und die Verschlüsselung des Benutzerverzeichnisses sollte an das Nutzerpasswort gebunden werden und nicht an das System. Besser wären noch Lösungen ohne Passwörter, wie beispielsweise FIDO2. Hier enteilt Microsoft Windows mit Hello Linux sowieso hoffnungslos.
Die Lösungsvorschläge basieren natürlich viel auf Entwicklungen in systemd (z. B. system-cryptenroll, systemd-home), aber auch auf Kryptofunktionen im Kernel wie dm-Verify und dm-Integrity. Ingesamt setzt Poettering auf eine viel stärkere Einbeziehung der sowieso verfügbaren TPM-Technik in die Sicherheitskonzepte der Distributionen. In diesem Zusammenhang wendet er sich auch massiv gegen nicht faktengestützte Vorurteile gegenüber TPM.
Diese Ideen sind natürlich weit entfernt davon, produktiv einsetzbar zu sein. Vermutlich werden sie am ehesten bei Fedora umgesetzt und dann sukzessive bei weiteren Distributionen.
Leider werden viele schon alleine deshalb dagegen arbeiten, weil die Ideen von Poettering kommen und systemd bei vielen nicht faktengestützte Vorurteile hervorrufen. Zudem haben viele Linux-Nutzer sich bequem in der Vergangenheit eingerichtet und leugnen die Herausforderungen der Gegenwart (von der Zukunft ganz zu schweigen).
Wäre zu schön, wenn man sich hin und wieder mal darauf einigen könnte, dass Leute einfach Recht haben mit dem, was sie sagen. Oder man Lennart zumindest mal zugestehen könnte, dass seine manchmal kontroversen Ansichten immerhin die richtigen Denkanstöße geben. Die Kommentare zu seinem Beitrag sind aber wie immer unerträglich. Diesmal besonders unerträglich, weil sofort wieder systemd diskutiert wird und irgendwie keiner über das eigentliche Thema redet.
In einer Sache muss ich dir dringend widersprechen, weil das sind keine Herausforderungen der Zukunft. Das ist jetzt! Wir haben überall Daten und die gehören auch überall geschützt. Linux-Betriebssysteme sollten hier innovative Vorreiter sein und nicht aus philosophischen Gründen der 1970er Jahre der zeitgemäßen Entwicklung hinterherlaufen. Manchmal glaube ich, dass zu viele Leute noch in den Dimensionen eines Heimcomputers und dem Elektroschrott in ihrem Heimlabor (den ich selber aber auch noch liebevoll pflege) denken. In jedem Unternehmen muss man aber andere Maßstäbe anlegen. Und genau das tut Lennart auch in seinem Beitrag. Vollverschlüsselte Mehrbenutzersysteme mit dynamischen Benutzerverzeichnissen und anständiger Authentifizierung.
Mir hat Ubuntu schon ein verschlüsseltes Home-Verzeichnis vorgeschlagen, als das unter Windows noch eine Pro-Funktion war (also den meisten Nutzern nicht verfügbar), und unter Android auch nur durch manuelles Anstoßen versteckt in den Einstellungen.
Auch wenn ecryptfs Schwächen hatte, war die einfache Verfügbarkeit von Verschlüsselung schon früh eine Stärke von Linux, die aber wieder mal verschlafen wurde, mit dem Stand der Technik mitzuhalten.
Hallo,
natürlich wäre es schön, wenn alle Linux-Distributionen alle Arten von Sicherheitsmechanismen unterstützen würden. Aber: Hardware (TPM) und Firmware (BIOS – Secure Boot) können nicht kompromittiert werden / sein? Sein wir ehrlich, gegen Angriffe potenter Gegner (Geheimdienste, Industriespionage großen Stils) wird das auch nicht viel helfen.
Für alle Anderen reicht LUKS vollkommen. Sicher wäre es schön, wenn auch der Bootloader und Bootdateien signiert / verschlüsselt wären, jedoch lässt sich hier leicht nach dem Start und Benutzeranmeldung ein Script starten, das prüft und in den verschlüsselten Bereich (zur Sicherung) kopiert. Zudem aktualisieren „gute“ Distributionen Pakete (sehr wohl signiert) inkl. Kernel so häufig, dass ein „Bundestrojaner“ in diesem Bereich wohl recht rasch wieder „rausfliegen“ würde. Ubuntu bringt z.B., noch ohne kritische Sicherheitsaktualisierungen, 2 Mal monatlich Updates, bei denen das Bootimage neu generiert wird. Und Sicherheitsaktualisierungen würden wohl auch schnell die Lücken, die überhaupt den „Bundestrojaner“ möglich machten, schließen.
Der Geräteverlust ist kein Argument. Egal, welches Betriebssytem (und ob – externe Medien), in diesem Fall hat der Angreifer immer alle Zeit der Welt. Außerdem wird er sich kaum die Mühe machen, das Gerät zig Tausend Mal zu booten, sondern einfach das Speichermedium ausbauen, kopieren und analysieren.
Und hier geht es darum, die nötige Zeit für’s Knacken möglichst auszudehnen. In den meisten Fällen sind Tage zu lang, auf jeden Fall aber Monate. Und in diesem Bereich (und noch mehr) liegen alle aktuellen Verschlüsselungen. In den USA wurde bei einem Gerichtsverfahren von Beweisaufnahme einer Festplatte abgesehen, nachdem es dem FBI nicht gelang, diese innerhalb von 8 Monaten zu „knacken“. Ganz ohne TPM und Secure Boot…
Mehr noch: Je mehr „Sicherheit“ (das sehen wir auch im Alltag), desto mehr verlassen sich die Menschen darauf, und desto unvorsichtiger werden sie, weil eh die Technik alles macht. Technische Sicherheit ist wichtig, aber viel mehr noch menschliche Intelligenz und Menschenverstand. Der Angriffsvektor Nummer 1 ist bei Weitem (etwa 85 % der erfolgreichen Angriffe) die soziale Komponente und nicht der böse Hacker im Internet oder der Hardwaredieb. Das fängt beim Führen von Telefongesprächen in der U-Bahn an, in denen persönliche Daten, und sei es, eine Telefonnummer, erwähnt werden. Auch Passwörter konnte ich schon mit anhören… (Das ist übrigens sehr wohl auch ein Fall für die DSGVO, denn „Daten“ heißt nicht nur: digital.)
Ich glaube du hast was falsch verstanden. Es geht um die Verschränkung vieler Methoden und nicht um die Ablösung einer einzigen durch eine andere Variante.
„Hardware (TPM) und Firmware (BIOS – Secure Boot) können nicht kompromittiert werden / sein? Sein wir ehrlich, gegen Angriffe potenter Gegner (Geheimdienste, Industriespionage großen Stils) wird das auch nicht viel helfen.“
Das ist doch eine Nebelkerze. Nur weil einzelne (nicht mal alle westlichen) Geheimdienste potenziell Hardware und Firmware manipulieren können, sollen wir pauschal auf Schutz verzichten? Wenn man das weiter denkt, können wir eigentlich alles sein lassen.
„Für alle Anderen reicht LUKS vollkommen“
Und bei einem Mehrbenutzersystem?
„Außerdem wird er sich kaum die Mühe machen, das Gerät zig Tausend Mal zu booten, sondern einfach das Speichermedium ausbauen, kopieren und analysieren.“
Wo wir wieder bei TPM wären.
Es ist naiv und dumm ein TPM ausschließlich positiv zu bewerben. Schließlich ist ein TPM eine rein proprietäre Technologie, deren Interna auch heutzutage noch verdunkelt werden. Zudem hat der Nutzer keine Kontrolle über die ab Werk präsenten kryptographischen Schlüssel eines TPM, die beim Einsatz des TPM eine wesentliche Relevanz haben. Nicht vertrauenswürdig. Und das schlimmste betrifft das Thema Datenverlust. Denn ein TPM kann nicht kopiert werden, sprich dessen Konfiguration ist unwiederbringlich verloren, sollte das TPM irgendeinen Fehler aufweisen, möglicherweise einem Kurzschluss zum Opfer fallen, oder in irgendeiner Weise physisch beschädigt oder gar gestohlen bzw. beschlagnahmt werden. Somit wären ausnahmslos alle Daten die auf diese Weise verschlüsselt wurden, für immer und ewig verloren. Und das ist ein undefinierbares Risiko. Zudem ist Diebstahl angesichts der Qualität moderner Verschlüsselung wohl kaum ein Thema. Sollen die Angreifer doch die Festplatte bis zum Erbrechen bearbeiten, dass wird innerhalb deren Lebenszeit nichts werden wenn nicht gerade die miesesten Passwörter zum Einsatz kamen. Da kann der Angreifer noch so potent sein, auch dieser ist den astronomisch mathematischen Problemen unterworfen. Also bitte realistisch bleiben. Nimmt man auch noch hinzu, dass das Cryptsetup vor zwei Jahren mit LUKS2 erheblich aufgewertet und für die Zukunft fit gemacht wurde, lässt die Situation nochmals in einem anderen Licht erscheinen. Ich nutze beispielsweise einen Nitrokey an meinem System anstatt eines TPM. Zudem kann ich mehrere Nitrokeys mit denselben Schlüsseln füttern, womit hier immer ein Backup existieren kann sollte ein Nitrokey abhanden kommen. Ansonsten wirkt die Kritik von Lennart mehr wie Werbung für seine eigene Lösung, als das hier wirklich ein akutes Problem existiert.
Hast du dir das Konzept wirklich durchgelesen? Es geht mitnichten darum einfach ein herkömmlichen LUKS Key durch TPM zu ersetzen, sondern TPM ist ein potenzieller Baustein in einem Konzept, das die Linux-Sicherheit deutlich besser aufstellt und näher an Standards heranführt, die moderne Systeme gesetzt haben. Es geht zudem nicht darum LUKS2 zu ersetzen, sondern es zu ergänzen. Dazu gehört auch so was für verifizierter Start, Verschlüsselung auf Benutzerebene etc.
Für Nitrokey kannst du die Lösung übrigens auch benutzen und das ist deutlich stabiler als die bisherigen zusammen gestückelten Scripte unter Debian und Arch.
Wo ich dir recht gebe ist, dass er Werbung für seine Ideen macht. Das finde ich legitim. Zumal diese bei ihm keine Luftschlösser sind, sondern frühere Konzepte von PulseAudio bis systemd Realität und Standard unter Linux geworden sind.