Aktueller Status von Daten-Verschlüsselung

[JTH]

Ich kann dir aber nicht sagen, ob /tmp beim Shutdown gelöscht wird oder beim Booten. Ersteres wäre eigentlich die bessere Lösung.

Tja, der Konjunktiv passt da leider. Es passiert natürlich erst beim Boot.

Auf nem System mit systemd sorgt systemd-tmpfiles dafür, dass diverse temporäre Ordner etc. beim Boot definitiv angelegt sind, u.a. /tmp. Das ist in /usr/lib/tmpfiles.d/tmp.conf konfiguriert. Da ist auch angegeben, dass der Inhalt von /tmp gelöscht werden soll, das passiert aber prinzipbedingt immer (und damit hier „erst“) beim Boot.

Falls gewollt, kann man in diesen tmpfiles.d-Definitionen auch ein maximales Alter für Dateien/Ordner angeben. Sie werden dann gelöscht, wenn entsprechend lange nicht mehr geschrieben & gelesen. Das könnt man auch für /tmp machen.

Auf nem System mit systemd kann man eine vorinstallierte mount-Unit benutzen, um /tmp als tmpfs zu mounten:

Code: Alles auswählen

# systemctl link /usr/share/systemd/tmp.mount

Oder natürlich nen Eintrag in der fstab.

[MSfree]

Aber eigentlich ist das eher unerwünscht, dass das jeden Neustart neu erzeugen muss.

Wenn /tmp auf der Root-Partition liegt, ist das nur ein Verzeichniseintrag, da muß gar nichts neu erzeugt werden. Wenn /tmp ein tmpfs ist, dauert es halt ein paar zehntel Sekunden, um das beim Booten anzulegen.

Es gab schon immer Cleanup-Scripte.

Das ist mir natürlich bekannt. Die Frage war aber, ob der Cleanup beim Shutsown stattfindet oder erst beim Boot. Beim Shutdown hätte man halt kein Dateieinträge mehr im /tmp-Verzeichnis. Wenn man die Platte nach dem Shutdown ausbaut, hätte man keine Dateireste.

Löschen hilft halt nichts, weil du die Dateien direkt mit extundelete und co wieder bekommst.

Das ist natürlich richtig. Wer so eine ausgebaute Platte forensich auch auf gelöschte Daten untersucht, wird hier fündig werden.

[eggy]

Die Frage war aber, ob der Cleanup beim Shutsown stattfindet oder erst beim Boot.

Früher™, vor systemd, beim Boot. Wenn ichs richtig im Kopf hab, wars nen Eintrag in der bootmisc.sh in /etc/init.d/ falls nicht, dann eins der rc scripte. Wurde am Ende vom Bootprozess abgearbeitet. D.h mit ner LiveCD kam man noch an Daten ran.
Bei systemd soll es wohl ne Variable dafür geben, bei der man setzen können soll, was wo wie wann gelöscht wird. Hab ich mich noch nicht genauer mit befasst, falls jemand noch weitere verlässliche Doku dazu findet, freu ich mich über den Link.

Überlebt der Inhalt von /tmp einen Neustart? Falls /tmp im RAM liegt, dann wohl mit Sicherheit nicht.

Jein, such mal nach "cold boot attack".

[Lord_Carlos]

Komisch. Ich bin mir recht sicher das es bei mir eine tmpfs partition ist.

Code: Alles auswählen

mount | grep tmp

Joa ist tmpfs, aber ich meinte eher das es schon default so war.

Systemd tmp.mount ist bei mir noch default und erstellt es tmp als tmpfs Wird das von einer anderen Config generiert?

[Spindoctor]

Wie ist es denn nun eigentlich mit der Hardware-Encryption moderner SSDs?

Habe bisher eher schlechtes darüber gelesen, aber vielleicht gibt es ja doch gute Implementierungen?

[wanne]

Wenn /tmp ein tmpfs ist, dauert es halt ein paar zehntel Sekunden, um das beim Booten anzulegen.

Es geht um Daten, die Programme da erzeugen. Früher waren das z.B. gerne Grafiken die erst berechnet werden und dann immer wieder verwendet werden. (3D-Scrensaver etc.)

aber vielleicht gibt es ja doch gute Implementierungen?

Vielleicht. Sogar wahrscheinlich. Die frage ist eher ob du dich auf vielleicht verlassen möchtest. Microsoft hat da lange Zeit ein Blacklist geführt. Irgend wann wurde die so riesig, dass sie es sein lassen haben und das gar nicht mehr verwenden. Praktisch jede untersuchte Platte hatte massive Mängel. Dazu kamen diverse BIOSe/EFIs, die die Keys raus tragen. Irgend wann hat man da halt aufgegeben. Das ist wie HTTP-Pipelining. Zu viele kaputte Implementierungen, als dass das irgend jemand verwenden will. Jetzt kommt halt QUIC bzw. http/3 als Alternative.

Joa ist tmpfs, aber ich meinte eher das es schon default so war.

Ich meine Installationen die als Debian 9 oder 10 installiert wurden haben das so ältere nicht.

[MSfree]

Wie ist es denn nun eigentlich mit der Hardware-Encryption moderner SSDs?

Möchtest du dich wirklich darauf verlassen?

So weit ich weiß, setzt man dazu ein Paßwort für die Platte/SSD im BIOS/UEFI. Dreimal falsch und die Platte/SSD ist permanet gesperrt. Du kannst sie nicht durch üebrschreiben mit Nullen reinitialisieren -> Elektroschrott. Eine Technik, für die es keine Möglichkeit gibt, selbst unter Verlust der Daten das Gerät wieder verwendbar zu machen, ist mir zutiefst suspekt.

Wie gut die Verschlüsselung ist, mag ich gar nicht beurteilen. Aber ich würde den Herstellern durchaus zutrauen, daß die mit Rot13 arbeiten und uns das als supersicher anpreisen.

[smutbert]

Schwächen oder Hintertüren hat es bei externen Festplatten und USB-Sticks mit Verschlüsselungsfunktionen ja bereits oft genug gegeben.

Ich habe im Repository noch etwas gefunden, was für mich so klingt, als wäre es genau das was der TE sucht, ob man es nun für sinnvoll hält oder nicht:
- encfs
- libpam-encfs

[Spindoctor]

So weit ich weiß, setzt man dazu ein Paßwort für die Platte/SSD im BIOS/UEFI. Dreimal falsch und die Platte/SSD ist permanet gesperrt. Du kannst sie nicht durch üebrschreiben mit Nullen reinitialisieren -> Elektroschrott. Eine Technik, für die es keine Möglichkeit gibt, selbst unter Verlust der Daten das Gerät wieder verwendbar zu machen, ist mir zutiefst suspekt.

Ist das echt so? Woher sind diese Informationen? Meine beiden Platten (hier und hier) setzen jedenfalls beide auf AES-256-Verschlüsselung.

Zumindest bei einer der beiden Platten ist auch OPAL 2.0 spezifiziert. Der Heise-Artikel dazu ist leider hinter einer Pay-Wall, aber im öffentlichen Teil steht bereis:

Ein Self-Encrypting Drive (SED), egal ob Festplatte oder SSD, schreibt ausschließlich verschlüsselte Daten auf seine Magnetscheiben oder in seine Chips. Die Verschlüsselung – meistens AES128 oder AES256 – lässt sich nicht abschalten. Den geheimen Schlüssel generiert die SED-Elektronik selbst.

Meines Wissens kann man mit sedutil die Verschlüsselung managen, also nicht NUR im BIOS/UEFI.

Allerdings wirkt das sedutil-Projekt in Github sehr stabil - oder eben sehr schlecht gepflegt. Außerdem verlässt man sich (auch mit AES-256), wie Du (MSfree) schon schreibst darauf, dass der Hersteller keine Hintertür oder Fehler in der Implementierung hinterlassen hat.

Vielleicht gibt es noch weitere Nachteile... jedenfalls genießt SED nicht unbedingt einen guten Ruf...

[Spindoctor]

Ich habe im Repository noch etwas gefunden, was für mich so klingt, als wäre es genau das was der TE sucht, ob man es nun für sinnvoll hält oder nicht:
- encfs
- libpam-encfs

Danke smutbert. Klingt gut. EncFS kannte ich bereits, libpam-encfs noch nicht. Leider habe ich keine halbwegs aktuelle Anleitung dafür gefunden, wie man das implementiert. Wirkt so, als hätte die Welt daran auch das Interesse verloren?
Bzw. ist es wirklich einfach zu integrieren?

Insgesamt glaub ich, haben mich die vielen kritischen Stimmen hier schon halbwegs überzeugt, dass mein ursprüngliches Vorhaben vielleicht eh nicht so sinnvoll ist.