der TPM-Chip prüft die Zertifikate, tauschbar nur nach gültiger Validierung mit gültigem Zertifikat...
Dein Problem ist ein Folgendes: Du vertraust auf Geräte und Software, die manipulierbar vorliegt, um dir einen unverschlüsselten Kernel zu validieren, der die Entschlüsselung übernimmt. Das erste Glied der Kette ist Mist, eben weil es ein erstes Glied ist (das man, als Nutzer bei einem Hoster, nichtmal selbst bestimmen kann).
Um derartige Manipulation weitestgehend auszuschließen, musst du Tricks anwenden, und das wäre sogar gar nicht so schwer:
Part. 1 (plain): /boot
Part. 2 (LUKS): /
Part. 3 (LUKS): /home bzw. Daten
Partition 2 hat eine komplette Kopie von /boot in - z. B. /opt liegen. Diese Kopie ist de facto durch einen Angreifer nicht manipulierbar, weil das den Zugriff auf die entschlüsselte Partition erfordert. Sie wird angelegt, kurz nachdem ein Systemupdate gefahren wird (also quasi ein post-postinst-Script). Zu Beginn des Bootvorgangs entschlüsselst du Part 2. Noch bevor /home entschlüsselt wird, gibst du systemd eine Dependency, dass ein binärer Diff zwischen der verschlüsselten Kopie von /boot und /boot keine Unterschiede aufweisen darf. Gibt es welche, bricht der Bootvorgang mit einem Systemfehler ab. Wir erinnern uns: Die Kopie von /boot ist vom Angreifer nicht manipulierbar. Auch der Check ist nicht umgehbar, denn /etc/systemd mit der Dependency sowie /usr/bin mit dem Diff-Script liegen auf der verschlüsselten, d. h. offline nicht manipulierbaren Partition. Egal was der Angreifer macht, eine unentdeckte Manipulation der plaintext-Partition 1 ist nicht möglich, wenn er nicht direkten Zugriff auf die entschlüsselte Partition 2 bekommt. Partition 3, welche die tatsächlich zu schützenden Daten enthält, wird erst entschlüsselt, wenn keine Manipulation vorlag. Darüber hinaus ist es einem Angreifer initial nicht möglich, das Vorhandensein dieses Checks zu erkennen (ein bisschen Security through Obscurity, aber halt als one-shot-Lösung wirksam).
Wir verbrennen also im Manipulationsfall den LUKS-Key für Partition 2, auf der liegen aber, abgesehen von deiner Dependency und dem Diff-Script, keinerlei Daten, die der Angreifer nicht ganz normal von einem Linux-Repository holen könnte. Der Key für Partition 3 hingegen verbleibt geheim, bis du die Integrität des Systems über den Ringschluss überprüft hast.
Angriffsszenario 2: manipulierter SSH-Server.
Grundsätzlich musst du ja, um die Festplatten zu entschlüsseln, einen SSH-Server laufen haben (oder einen Terminalserver, der dir den Bildschirm streamt - wobei du da wahrscheinlich verkackt hast). Der muss ja auch in /boot liegen, um dir Login und Entschlüsselung für Partition 2 zu ermöglichen. Weiß nicht, ob das so einfach geht, aber wir nehmen es mal an. Aufgebläht auf / ist das Ding ja sofort.
Um die Integrität des Gegenübers zu prüfen, wird ein PrivateKey auf dem unverschlüsselten Teil der Festplatte nötig. Den kann ein Angreifer kopieren, um dir quasi eine Umgebung zu schaffen, in der du ohne dein Prüfscript den Key für Partition 3 übergibst (die verschlüsselten Partitionen gibt es aber dann nicht, die Frage ist eine Attrappe ohne Wirkung). Also er lässt dich in ein Standard-Debian booten, das Kennwörter frägt, die es nicht braucht. Die Manipulation würdest du erst bemerken, wenn deine Daten auf dem System nicht existieren. Dem kannst du entgegenwirken, indem dein Diff-Script dir eine sichtbare Meldung ausgibt, dass keine Manipulation entdeckt wurde. Da der Angreifer zumindest beim ersten Mal nichts von deinem Check weiß, kann er diese Meldung nicht fälschen. Deine Daten auf Partition 3 bleiben also sicher.
Also ja, man kann gewisse Gegenmaßnahmen treffen, aber sie müssen zwingend darauf aufbauen, dass die Integrität des Systems durch Maßnahmen überprüft wird, die sich hinter einer Verschlüsselung verbergen, deren Schlüssel nur du kennst. Loggst du dich über einen Terminalserver ein (z. B. VNC), kann dieser einen Keylogger haben - du arbeitest nicht an einem System, das du selbst prüfen kannst, damit bist du schutzlos.
