OpenSUSE macht das immer noch so. Wenn man im Installer [x] encrypt disk anklickt, legt der eine verschlüsselte Root-Partition an, die auch /boot enthält.
In dem von mir ganz oben verlinkten Wiki-Artikel wird das auch als der Normalzustand impliziert:
fde-tools expects an encrypted root file system including /boot.
Do this only if you have an encrypted root partition that includes /boot (no separate /boot partition)
Genau deswegen mag ich das nicht.
Oder hat OpenSUSE die Patches im grub2 drin, die Ihen argon2i fähig machen und supportet das?
Die von mir oben zitierten cryptsetup-team.pages haben auch so eine Lösung im Angebot, bei der man auf LUKS1 /boot und /root mit „schön einfach“ zu faktorisierender Rundenzahl installiert hat.
Gut - das Vorgehen hilft gegen staatlich angestellte Wirtschaftinformatiker FH und ggf. intelligentere - aber arme Script-Kiddies. Sobald aber wirkliches Interesse in 5 stelliger EURO Zahl aufwärts festgestellt werden würde - würde es mich wundern, wenn nicht externe Dienstleister schnell zu einer Hilfsstellung fähig sein sollten. (Z.B. die Elmsofties haben die nötigen Ressourcen…)
Auf der anderen Seite braucht man wirklich kein Experte zu sein um mit dieser Lösung von der Stange imho besser abzuschneiden als die Enterprise Versionen von Windows. 
OpenSUSE hat zwar ihre „eigene“ Version von Grub2 mit diversen Patches, aber soweit ich weiß geht LUKS2 nur mit PBKDF2.
Es wird nebenbei auch daran gearbeitet, Grub2 in der Zukunft durch Systemd-Boot zu ersetzen.
Das ist in dem Debian/Devuan Paket auch der Fall - und imho eher weniger hilfreich. (Bei meinem letzten Versuch die iterations Variable in LUKS2 mit PBKDF2 zu verändern kam nichts brauchbares heraus.)
Vielleicht sind möglicherweise in der Gummi-/systemd-Boot Entwicklung fähige, produktive Leute versammelt - die dieses Problem mit einem sauberen Design angehen.
Ich lasse mich gerne positiv überraschen.
Inwiefern ist das Linux Login keine große Hürde, kannst du da mögliche Angriffe beschreiben, die über brute force hinausgehen?
Das Linux Login - ist in so weit - mit übersichtlichem Aufwand überwindbar, als das Du einfach den Rechner von einem USB Stick bootest und dann das password auf der entsprechenden Festplatte änderst… Danach kennst Du das password für den user, den Du nutzen willst. (Und wenn Du vorher den entsprechenden Passwordhash zur Seite kopiert hast und ihn nicht gelöscht hast - kannst Du danach das orignal - Dir unbekannt Password - (mit dem wiederhergestellten Passworthash) wieder herstellen. - No witchcraft involved…)
Daher sind imho (nicht nur) Linux Systeme, die ohne verschlüsselte Festplatte unterwegs sind - und bei denen physikalischer Zugang zur Hardware nicht auszuschließen ist - als wahrscheinlich kompromitiert zu betrachten…
Übrigens, wenn Du Dich einlesen willst diese Art der Angriffe heißt „evil maid“.
Ja aber das geht nicht, wenn die Festplatte verschlüsselt ist. Und das TPM wird es nicht entschlüsseln, wenn man vom USB-Stick bootet. Also bräuchte man ja nach wie vor eine Möglichkeit (z.B. ein Bug), um die Passwortabfrage von SDDM/GDM/LightDM zu umgehen.
Ja mit verschlüsseltem /root ist man vor der Schülerversion dieses „evil maid“ geschützt.
Wenn man /boot unverschlüsselt hat - plaziert die „evil maid“ dort einen (Software) keylogger.
Alternativ ist es imho viel billiger und auch sicherer eine „Hardwareeigenheit“ von allen mir bekannten Laptops zu nutzen.
Das dort verbaut Keyboard wird i.d.R. auf der Rückseite des mobo montiert - .
Aus mir logisch unerklärlichen Gründen wird der Anschluß des Keyboard aber i.d.R. auf der Frontseite des mobo i.d.R. mit einem Flachbandkabel von der Rückseite aufwändig herumgeführt - vorne geklemmt. (Der Teil des mobo, den man sieht, wenn man den rückwärtigen Deckel des Laptop abschraubt.)
Der Umbau gängiger Keylogger Hardware um sich da (ggf. mit angepasstem Flachbandkabel ) - dazwischen zu klemmen dürfte im Minuten Bereich liegen…
Der Einbau auch…
Wobei die Gesetzeslage klar ist. Auch verboten ist die Installation von Minikameras, die z.B. wie Wildkameras, nur bei Bewegung starten und ganz kurze - relativ hoch aufgelöste Videos (möglicherweise von Keyboards) aufnehmen…
Der Angriff auf luks1 kostet bestimmt 5 stellig. Die oben aufgeführten illegalen Methoden sind (ggf. im örtlichen Bahnhofmilleu) imho billiger zu haben.
Jein, die werden von dem dann unverschlüsselten /root ausgeführt. Sobald die Passwortabfrage sichtbar ist - ist der Rechner für „evil maid“ imho ein eher leichtes Ziel.
(Dann kommt es sehr darauf an welche Treiber geladen sind, was für Dienste laufen, welche Konfigurationen geladen sind - (Staats)forensiker - werden einen Weg finden.)
Gegen Evil Maid Angriffe und auch den von dir skizzierten kann man sich mit der Kombination Coreboot + Heads + Nitrokey schützen, verbaut in eigenen Nitropads und den Librem Notebooks. Was es nicht verhindert ist, dass wenn der User erst einmal eingeloggt ist Passwörter gestohlen werden können, der Zugriff an sich auf die Daten ist aber in Abwesenheit von Nutzer und Nitrokey nicht möglich, auch wenn ich das Login Passwort habe.
Edit: Wobei: Wenn der Keylogger das LUKS Passwort mitschneidet, dann müsste man ja die Festplatte ausbauen können und entschlüsseln können. Muss da nochmal drüber nachdenken …
Ein unbefugter Zugriff auf /boot bedeutet für mich immer, dass diese Partition nicht mehr vertrauenswürdig ist, das ist sicher klar.
Aber, wie fährst du einen evil maid Angriff gegen einen Rechner, der ohne Passwort gar nicht erst startet, bzw. ohne PW überhaupt kein anderes Bootlaufwerk gesetzt werden kann? Selbst der Hersteller soll nicht in der Lage sein, das Bios PW auf diesem Laptop zu resetten.
Wenn ich ein böser Hacker wäre - und gut dafür bezahlt werden würde, dann würde ich ein (gerne auch kaputtes MoBo und ein Keyboard ) des entsprechenden Laptop organisieren und einen physikalischen (vom Gehäuse befreiten) Keylogger so herreichten, dass der sich in < 20 Sekunden einfach zwischen MoBo und Keyboard einklipsen läßt (entsprechendes Flachbandkabel in entsprechender Breite und Dicke anlöten) . Je nach Laptop (Volumen / Gehäusermaterial) könnte das sogar ein Funkkeylogger sein.
Also Gehäuse auf - schnell rein das Ding - Gehäuse zu . (Wer so twas macht - macht sich nach § 202c StGB strafbar - daher besser lassen…)
Solange da nicht irgendein TOTP beim Booten über das tpm den /root LUKS-Key entschlüsslt - liegen danach zumindest die bei diesem Booten verwendeten /boot und /root LUKS-Keys „sicher“ auf dem Keylogger - oder sind schon fröhlich per Funk verschickt worden…
Danach braucht es einen zweiten „evil maid“ um den Keylogger einer möglichen Forensik zu entziehen… (Bei der Gelegenheit könnte dann auch gleich die SSD geclone werden und der Clone kann in Ruhe ausgewertet werden…)
Aber so etwas passiert nicht, weil es verboten ist (jedenfalls für alle Menschen die nicht bei Diensten oder bei Dienstleistern für die Polizei arbeiten.).
Dieser Angriff hat mehrfache Voraussetzungen, der Angreifer kennt das verwendete Computersystem und hat physischen Zugriff und das Opfer bemerkt weder den physischen Zugriff, noch die Manipulation.
Um das Thema zu erweitern, Luks Volumes mit einer PGP Smartcard zu entsperren, mit nem Klasse 3 Lesegerät, finde ich eine spannende Sache. Da nützt dann auch der Keylogger nichts.
Man kann auch generell für die Eingabe von PWs ne andere Tastatur benutzen.
Ja bei „evil maid“ ist physikalischer Zugang angezeigt.
Zudem ist es beim „ausbaldovern“ hilfreich zu wissen mit was man es zu tun hat.
Ich nehme an >99% aller „evil maids“ machen das nicht spontan…
Ja da kommen wir in Bereiche in denen sich bei Forensikern die Spreu vom Weizen trennt. Das sind z.Zt. noch Angriffskosten - die will einfach keiner tragen…
Aber da die Mehrheit unserer Planetenmitbewohner Ihre Daten in Clouds hält (es ist so praktisch, es kostet nichts …) ist das eine verschwindende Minderheit, die sich mit praktischer IT-Sec für den praktischen Hausgebrauch auseinander setzt.
Ja das ist u.U. auch ganz praktisch um das Std. „C“ Layout von grub2 mit transkodierten Umlauten zu füttern - um mehr Entropie in die Passphrase zu bringen.
Manchmal sind die Wege zu komplexeren Passpharses eher einfach. (Schauen ob die Zeichen druckbar sind sollte man schon vorher …)
Kurze Frage: Warum sollte die Anzahl der Iterationen eine Primzahl sein?
Wie du sagst: Es kostet keine ms mehr - wenn die Primzahl nicht zu weit von der sonstigen Auswahl entfernt ist.
Aber jede andere Zahl die keine Primzahl ist, ist auch nicht die Standardanzahl, und bietet somit den gleichen Vorteil. Nämlich dass eine Tabelle mit der Standardanzahl an Iterationen und dem eigenen Salt nicht gültig ist?
Jede höhere Anzahl an Iterationen ist gut, weil mehr Zeit benötigt wird - deswegen ist „keine ms mehr“ m.M.n. eine schlechte Aussage: Dann bringt es nichts. Ob es eine Primzahl ist spielt - meines Wissens nach - überhaupt keine Rolle? Die Anzahl der Iterationen ist eine öffentliche Angabe, im Header. Primzahl oder keine, für die Anzahl wie häufig gehasht wird, es wird „nichts“ an der Berechnung ändern.
Oder liege Ich hier falsch?
Kurze Antwort: Weil man eine Primzahl per Definition nicht faktorisieren kann.
Du gehst davon aus, dass die Menschen, die seit Jahrzehnten ein Interessen an einer einfachen Überwindung dieser Verschlüsselung haben - keinen besseren Weg als „brute force“ gefunden haben.
Warum haben dann die LUKS Entwickler bei LUKS2 die Pferde gewechselt?
Mein Vertrauen in die Kosten von pbkdf ist begrenzt - und Primzahlen von gleicher Länge wie faktorisierbare Zahlen sind auf gar keinen Fall schlechter…
Ich bin kein Cryptoanalytiker und meine Mathe-Kenntnisse reichen auch nur für den Hausgebrauch. Wenn man beispielsweise große vorberechnete Tabellen zum Knacken von Algorithmen nutzt, dann ist das viel einfacher(billiger), die nur für kleinere Faktoren (mehrdimensional) berechnen zu lassen als für die Menge aller viel größeren Primzahlen…
Ich habe keinen Beweis dafür, dass pbkdf einfach mit Hilfe solcher Tabellen (schneller = billiger) zu knacken ist - aber mit hoher Wahrscheinlichkeit machen entsprechende äquivalent gewählte Primzahlen in der Zahl der Iterationen - speziell, wenn sie zufällig gewählt werden - das Knacken nicht leichter 
.
Wenn in 30 Jahren pbkdf endgültig in Rente geht - dann gibt es vielleicht auch entsprechende Publikationen wie zu einst zu DES…
Bis dahin kostet eine vergleichbar lange Primzahl beim Entschlüsseln keine ms mehr.
Und da hast Du natürlich Recht - mehr Iterationen - sind besser. Imho kann es auch bei denen nicht schaden zufällige, individuelle Primzahlen zu verwenden.
Dass die Iterationszahl offen im Header steht ist für die Entschlüsselung unabdingbar. Das macht aber auch nichts. Imho schadet die Verwendung von Primzahlen bei rekursiven Iterationen nicht - einem potentiellen Angreifer kann das aber potentiell weh tun, weil sich u.U. möglicherweise dieses Problem weniger parallel angehen lässt. (Beweisen kann ich das nicht. Ich halte das aber für plausibel - und schaden tut es sicher nicht.)
Ein kreativer Ansatz wurde bei Golem berichtet. Da hat einer an den Beinchen des TPM Chip mittels eines Pi Pico mitgelesen 
Das gehört jetzt hier alles nur noch indirekt zum Thema „TPM“, aber ich mag diese ganzen Behauptungen nicht unwidersprochen stehen lassen.
Du kannst Calamares so einrichten, dass /boot (unter Nutzung von PBKDF2) verschlüsselt wird. Vernünftige Distros machen das aber nicht, denn
a) für 99% aller Nutzer ist evil maid kein realistisches Angriffsszenario
b) dem verbleibende Prozent wird nicht wirklich geholfen, da auch bei verschlüsseltem /boot die Einfallstore EFI und ME/PSP offen bleiben
c) eine Verschlüsselung ist nur dann gut, wenn sie so benutzerfreundlich ist, dass sie auch benutzt wird
d) die Distro muss auch mit z.B. Devanagari als Zeichensatz funktionieren - grub2 kann aber nur Passwörter in en_US
e) Distros können nicht voraussetzen, dass die Nutzer*innen ausreichend lange Passwörter benutzen, deshalb ist argon2id unumgänglich und alles mit PBKDF2 riskant.
JanH versucht eine Tür mit Spanplatten zu vernageln, während er für 2 Hintertüren (EFI und ME/PSP) nicht mal weiß, wer alles den Schlüssel hat. Wenn man erhöhte Sicherheitsanforderungen hat bzw evil maid befürchtet, wäre es sinnvoller, /boot auf einen USB-Stick auszulagern, den man nie am Rechner stecken läßt. Oder sogar davon auszugehen, dass ein Rechner, den man aus den Augen gelassen hat, immer kompromittiert ist.
Um zum Thema zurückzukehren: Es kommt immer auf das Bedrohungsszenario und das Bequemlichkeitsbedürfnis an. Beim für viele Nutzer*innen relevanten Diebstahlsszenario kommt sowohl die Platte als auch der TPM abhanden. Da würde ich mich auf die PIN nicht verlassen wollen. Mir macht die Eingabe meines Entschlüsselungssatzes (diceware) auch keine Mühe. Solange das so ist, ist TPM kein Thema.
Es geht um alle die keinen Bock darauf haben, den Inhalt Ihres um 5:00 von der Staatsmacht eingesammelten Laptops vor Gericht gegen sich verwendet zu sehen. (Und sei es nur wegen irgendwelcher Zickereien/Lapalien).
Ich habe etwas zu verbergen, denn ich habe eine Menschenwürde.
Das setzt imho schon viel mehr Invest beim Angreifer voraus.
Zwei Passwörter beim Booten - das halte ich für mich ok. Der 2 x verschlüsselte Linux Schleppi bootet damit immer noch schneller als mein Winseuche Arbeitsgerät mit bitlocker…
Die Nummer mit dem Zeichensatz ist eigentlich ganz cool - um schöne lange Passphrases, die aus keinem Wörterbuch zusammengepusselt werden - zu erhalten…
Du kannst ein Terminal in en_US umstellen und mit der Tastatur deines Beliebens das lustige Passphrase deines Beliebens - beliebig kreativ eingeben…
Natürlich kannst Du auch grub2 auf Devanagari umstellen - aber das ist imho eher etwas für masochistisch veranlagte Admins…
Das könnte man erzwingen - aber wer 12345678 erfolgreich seit 40 Jahren nutzt wird wohl dabei bleiben wollen…
Da hast Du möglicherweise Recht - wie würdest Du mich den damit ganz praktisch angreifen wollen. Budget 1000 EURO?
Ich lerne gerne täglich dazu!
Wer die Storys von David Miranda kennt, der weiß wie gut das geht…
Das ist imho immer so: - Security vs Usability
Da muss jeder sein Maß und seine Mitte finden.
Ich persönlich würde eine Kombi aus TPM && Password && TOTP für das Starten der /root Partition für mich als angemessen empfinden.
Im Moment müßte ich aber zu lange - zu viel dafür tun um das in angemessener Qualtität hin zu kriegen. Aber man soll nie nie sagen.