ubuntuusers.de

Hallo zusammen,

ich selbst werde in absehbarer Zeit für eine Menschenrechtsorganisation im Mittelmeerraum arbeiten. Dabei kam es durch verschiedene Staatlichkeiten immer wieder zur Beschlagnahmung verschiedener digitaler Endgeräte - darunter auch Handys und Laptops. Ich habe mir deshalb in der Hoffnung dieses Wissen nie umsetzen zu müssen im Vorfeld einige Gedanken dazu gemacht, wie ich vor diesem Hintergrund meine informationelle Selbstbestimmung wahren kann. Dies ist in Bezug auf meinen Laptop besonders wichtig, weil sich auf diesem nicht nur persönliche Informationen befinden, sondern durch die Arbeit zunehmend auch schützenswerte sensible Daten die NGO betreffend.

Ich selbst habe meinen Laptop im wesentlichen nach dieser Anleitung hier mit LUKS 2verschlüsselt und mit einem entsprechend langen alphanumerischen Passwort versehen: System verschlüsseln/Schlüsselableitung zusätzlich habe ich allerdings noch ein home-LV angelegt und dieses entsprechend gemountet.

1. Frage: Mich würde eure Meinung für sichere Parameter für ein LUKS2-Passwort interessieren. Hier sind die zufinden Meinungen ziemlich divers.

2. Behörden europäischer Staaten geben beschlagnahmte Medien im Gegensatz zu nordafrikanischen und türkischen Behörden in aller Regel in absehbarer Zeit zurück.
   Nun ist es so, dass neben der mit LUKS2 verschlüsselten Partition auch eine unverschlüsselte Boot-Efi- und eine unverschlüsselte Boot-Partition auf der SSD angelegt werden müssen. Man sagt zwar, dass in während der forensischen Untersuchung nur das Laufwerk gespiegelt wird, dennoch bieten die unverschlüsselten Partitionen Raum für Manipulationen. Hierzu fallen mir beispielsweise Keylogger oder die Implementierung von Hintertüren ein.
   Meine Überlegung ist mit dd nach jedem Update Iso-Images der beiden unverschlüsselten Partitionen zu ziehen. Sollte es tatsächlich zu dem unschönen Fall einer Beschlagnahmung kommen, würde ich den Laptop per Bootstick starten und Boot und Boot-Efi mit shred gründlich platt machen. Nach einem Neustart würde ich die Lukspartitionen enstschlüsseln und mounten und durch dd mit den in ihr gespeicherten Isos die beiden Partitionen neu anlegen.
   Zusätzlich habe ich natürlich den LUKS-Header gesichert.
   Was sagt ihr dazu?

3. Wie gehe ich vor, wenn Punkt 2 nicht funktioniert?
   ich bräuchte hier Befehle, um den Bootloader, den Diskloader und das Kernel neuzuinstallieren. Nach meinem Verständnis müsste ich zusätzlich alle Schritte aus der oben verlinkten Anleitung nach der Installation neu ausführen, oder?

4. Gibt es Möglichkeiten ein weiteres Passwort anzulegen, dass einem keinen Zugang gewährt, sondern im Hintergrund Befehle ausführt? Ich denke da an soetwas wie löschen des LUKS-Headers und herunterfahren. Das wäre sowohl am Anmeldebildschirm, als auch bei der Passwortabfrage bei der Festplattenentschlüsselng interessant. Gibt es auch Möglichkeiten dies durch eine Tastenkombination im laufenden Betrieb zu erreichen? Etwas gemeiner als das bloße Löschen wäre vielleicht auch das überschreiben des LUKS-Headers? Das sollte in Anbetracht der Größe auf einer SSD in Sekundenbruchteilen durchführbar sein. Das mit shred zu realisieren wäre aber vermutlich riskant.

5. Fallen euch zusätzliche Sicherheitsmaßnahmen ein?

Zusätzlich habe ich mir den folgenden Sicherungsbefehl gebastelt, den ich ausführe, wenn es Updates gibt:

sudo apt upgrade && ls -la /home/[user]/Dokumente/Backup && sudo mkdir /home/[user]/Dokumente/Backup/$(date +%d.%m.%Y_%H:%M) && sudo cryptsetup luksHeaderBackup /dev/sdx3 --header-backup-file /home/[user]/Dokumente/Backup/$(date +%d.%m.%Y_%H:%M)/Backup_luksHeader_$(date +%d.%m.%Y_%H:%M) ;  sudo dd if=/dev/sdx1 of=/home/[user]/Dokumente/Backup/$(date +%d.%m.%Y_%H:%M)/Backup_Boot-Efi_$(date +%d.%m.%Y_%H:%M).iso status=progress ; sudo dd if=/dev/sdx2 of=/home/[user]/Dokumente/Backup/$(date +%d.%m.%Y_%H:%M)/Backup_Boot_$(date +%d.%m.%Y_%H:%M).iso status=progress && sudo apt update && ls -la /home/[user]/Dokumente/Backup

Grundsätzlich läuft der Befehl gut durch. Das einzige Problem besteht darin, dass

sudo mkdir /home/[user]/Dokumente/Backup/$(date +%d.%m.%Y_%H:%M)

einen Ordner erstellt, der die Bezeichnung des Datums und der Uhrzeit zum Zeitpunkt der Erstellung enthält. Der Pfad der anschließend zu erstellenden Dateien enthält /$(date +%d.%m.%Y_%H:%M). Somit ändert sich der Schreibpfad minütlich. Selten passiert es deshalb, dass Iso-Images nicht erstellt werden können, wenn sich währenddessen die Uhrzeit ändert. Gibt es eine alternativen Befehl, der anstatt /Backup/$(date +%d.%m.%Y_%H:%M) den letzten erstellten Ordner im Ordner Backup addressiert? Zusätzlich fände ich es noch interessant einen Befehl zu implementieren, der alle im Ornder im Ordner Backup löscht, die älter als x-Tage sind und sicherstellt, dass nur die neuesten en drei Ordner behalten werden.

Danke euch schon mal. ☺

Groetjes

Hallo ihr Lümmel,

so langsam würde ich mich ja mal freuen, wenn hier jemand geflissentlich seinen Senf dazu gäbe. ☺ Subjektive Meinungen sind auch willkommen und natürlich muss nicht auf alle meine Punkte/Hypothesen eingegangen werden. Vor allem der vierte Punkt ist wohl sehr hypothetisch und schwer realisierbar.

Danke und nen schönen Abend

Dir Antwortet keiner weil dein Beitrag eine gigantische Textwüste ist.

1. LUKS Passwort: Lang ist gut, länger ist besser.

2. EFI und /boot enthalten keine wichtigen Daten. Du kannst ein Image schon machen, aber wenn man ganz krass drauf ist können die auch nen Chip einbauen als Keylogger oder sonstwas. Es reicht die sha512sum der Dateien zu haben um zu Wissen ob was verändert wurde.

3. Keine Ahnung warum du mit Schlüsselabteilung arbeitet, das ist ein sehr dummes Verfahren. KISS, alles in ein LVM und da ist Verschlüsselt, fertig.

4. Nein

5. Nein, außer das Gerät das du potentiell Abgeben musst sollte nur so wenig Daten wie möglich haben.

Moin encbladexp,

danke für deine Antwort. Dazu hätte ich glatt noch ein paar Rückfragen:

2. Soweit ich weiß wurden Computer bei einer forensischen Untersuchung bislang noch nicht physisch verändert. Hast du dazu irgendwelche Belege, dass das mal geschehen ist? Die sha512sum sollte ich ja auf die verschlüsselte LUKS2-Partition beziehen, oder? Wie überprüfe ich das? Hättest du ansonsten noch Ideen, wie man sicherstellen könnte, dass Boot und Efi nicht verändert wurden, außer stoisch ein Iso drüberzubügeln?

3. Weshalb ist das ein sehr dummes Verfahren? Ich habe bislang noch nirgends (bis auf einen sehr unglücklichen Fall, in dem der Schlüssel wohl im Betrieb im RAM hinterlegt war) gelesen, dass LUKS2 bei vernünftiger Passwortwahl geknackt worden wäre. Ich verstehe nicht so recht, was du damit meinst: > KISS, alles in ein LVM und da ist Verschlüsselt, fertig. Meine Hauptpartition ist LUKS2 verschlüsselt. In ihr habe ich eine entsprechende LVM-Struktur angelegt.

4. Im Laufenden Betrieb müsste es doch eigentlich die Möglichkeit geben Hotkeys zu definieren. Ich denke dabei daran auf irgendeiner abwägigen Tastenkombination soetwas wie das hier zu legen:

sudo cryptsetup -v erase /dev/sdx3 ; sudo poweroff

Dabei sehe ich zwei Probleme, dass wird so ohne weiteres nicht ohne weitere Tools unterstützt und das zweite viel größere Problem wäre, dass ich vermute, dass erase nicht auf einer gemounteten Partition durchführbar ist. Gäbe es eine Möglichkeit diesen Befehl zu erzwingen? Beim Befehl erase war immer wieder von wipe die Rede. Verstehe ich das richtig, dass die Keyslots im Header überschrieben werden? Das ganze wäre natürlich super, wenn man das ohne Passworteingabe realisieren könnte. Gibts eine Möglichkeit das root-Passwort im Befehl mitzugeben?

5. Mir gehts darum, dass die Ordner Dateien mit root-rechten enthalten. Somit sind sie in der Oberfläche nicht löschbar. Deshalb räume ich immer mal wieder mit

sudo rm -r 

auf. Es wäre einfach cool sich diesen Schritt sparen zu können.

gazrilla92 schrieb:

...Soweit ich weiß wurden Computer bei einer forensischen Untersuchung bislang noch nicht physisch verändert.

Mag sein, aber so ein Gerät erstmal aus der Hand....

...Die sha512sum sollte ich ja auf die verschlüsselte LUKS2-Partition beziehen, oder?

Nein, auf /boot und die EFI Partition, es reicht also:

find /boot -type f | xargs -- sha512sum > SHA512SUMS

Check Mode findest du in der Manpage.

Weshalb ist das ein sehr dummes Verfahren?

Du hast den Wiki Artikel zu Schlüsselableitung verlinkt, das ist was ich für ein dummes Verfahren hat. LUKS an sich hängt nur an der Sicherheit der Passphrase.

Im Laufenden Betrieb müsste es doch eigentlich die Möglichkeit geben Hotkeys zu definieren.

Im laufenden Betrieb schaltest du das Ding einfach Hart aus, fertig. Verschlüsselung wirkt wenn die Kiste aus ist, ansonsten sind Angriffe per z.b. DMA möglich.

encbladexp schrieb:

Mag sein, aber so ein Gerät erstmal aus der Hand....

Fair Point. Am Ende des Tages kann man eben nur schauen, dass man in so einer Situation so viele Manipulationsmöglichkeiten wie irgend möglich ausschließen kann, um sich im Anschluss bei der Benutzung seines Gerätes wieder wohl zu fühlen. Eine absolute Garantie gibts da natürlich nicht.

Nein, auf /boot und die EFI Partition, es reicht also:

find /boot -type f | xargs -- sha512sum > SHA512SUMS

Check Mode findest du in der Manpage.

Magst du das mal bitte ein bisschen genauer Ausführen? Ich verstehe hier gerade nur Bahnhof. Was für ein Befehl ist das, was bewirkt er und welchen Mehrwert ziehe ich daraus?

Im laufenden Betrieb schaltest du das Ding einfach Hart aus, fertig. Verschlüsselung wirkt wenn die Kiste aus ist, ansonsten sind Angriffe per z.b. DMA möglich.

Jo. Da gehe ich mit. Klar. man kann natürlich den Schlüssel aus dem RAM auslesen, wenn der Computer läuft. Von daher die Kiste vor dem aushändigen brav herunterfahren. 😉 Meine Überlegung ist nur die folgende: Im luksHeader stehen ja die entsprechenden Parameter, mit denen aus dem Kennwort der eigentliche Schlüssel ableitbar ist. Das ist ja der Punkt an dem wenn überhaupt eine Brutforceattacke erfolgt. Die Verschlüsselung an sich gilt ja als unknackbar. Wenn man die Keyslots vor dem Herunterfahren mit einem Hotkey entfernt, kommt man mit Brutforce auch nicht weit. egal wie sicher das Passwort wäre.

Ich habe in der Zwischenzeit die Probe aufs Exempel gemacht:

sudo cryptsetup -v erase /dev/sdx3 ; sudo poweroff

Der Befehl läuft auch bei einer gemounteten Partition durch und tut, was er soll. Problem: Nur als sudo ausführbar. Kann das root-Passwort bei dem Befehl als Parameter mit übergeben werden?

gazrilla92 schrieb:

Magst du das mal bitte ein bisschen genauer Ausführen? Ich verstehe hier gerade nur Bahnhof. Was für ein Befehl ist das, was bewirkt er und welchen Mehrwert ziehe ich daraus?

Der Befehl speichert eine Prüfsumme aller Dateien, wird eine Datei manipuliert / geändert, ändert sich auch diese.

Im luksHeader stehen ja die entsprechenden Parameter, mit denen aus dem Kennwort der eigentliche Schlüssel ableitbar ist.

Deine Überlegung ist Quatsch. Die Verfahren zur Schlüsselableitung / argon2i / PBKDF2 etc pp sind ausreichend sicher. Dein Passwort ist das Problem, nicht diese Funktion.

Wenn man die Keyslots vor dem Herunterfahren mit einem Hotkey entfernt, kommt man mit Brutforce auch nicht weit. egal wie sicher das Passwort wäre.

Aber einer bestimmten Stelle ist AES einfacher durch Bruteforce zu knacken als das Passwort. Du kannst pro Sekunde mehrere Millionen AES Operationen durchführen, aber nur sehr wenige argon2i.

Problem: Nur als sudo ausführbar. Kann das root-Passwort bei dem Befehl als Parameter mit übergeben werden?

Man kann sudo sagen das bestimmte/alle Befehle eines Users kein Passwort brauchen, steht im Wiki.

Moin encbladexp,

Der Befehl speichert eine Prüfsumme aller Dateien, wird eine Datei manipuliert / geändert, ändert sich auch diese.

Das ist clever. Gefällt mir! Die Prüfsumme gilt dann nach meinem Verständnis für die jeweilige Partition und wird dann auf dieser abgelegt und bei entsprechenden Veränderungen mitverändert, richtig? Bräuchte ich dafür nicht zwei Befehle? Einen zum einrichten der Prüfsumme auf der jeweiligen Partition. Das müsste ja dieser hier sein:

find /boot -type f | xargs -- sha512sum > SHA512SUMS

Und einen um die Prüfsumme wieder in Form einer Datei auszulesen und mit einer zu einem vorherigen Zeitpunkt ausgelesenen Prüfsumme zu vergleichen.

Ich meine mal irgendwo gelesen zu haben, dass in der Boot oder in der Efi Partition unter anderem mitgeloggt wird, wie oft der Computer hochgefahren wurde. Dadurch änderte sich doch die Checksumme bei jedem hochfahren...

Deine Überlegung ist Quatsch. Die Verfahren zur Schlüsselableitung / argon2i / PBKDF2 etc pp sind ausreichend sicher. Dein Passwort ist das Problem, nicht diese Funktion.

So wie ich das Verstehe wird der Schlüssel aus zwei Teilen erstellt:

1. Der statische Verwaltungsschlüssel, der sich innerhalb der Verschlüsselung nicht ändert

2. Individuelle passwortspezifische Parameter die mit Hilfe der Ableitungsfunktion nach Passworteingabe zum zweiten Schlüsselteil führen.

–> Beide zusammen ergeben dann den Entschlüsselngsschlüssel. Lösche ich die individuellen Ableitungsparameter im luksHeader, sollte doch auch bei der Eingabe eines korrekten Passwortes keine Entschlüsselung mehr möglich sein, weil die Schlüsselableitung nicht mehr möglich ist. Somit wäre eine Brutforceattacke nur gegen die Verschlüsselung selbst möglich, oder nicht? Dadurch würde doch die Passwortsicherheit als Unsicherheitsfaktor eliminiert. Habe ich da einen Denkfehler?

gazrilla92 schrieb:

find /boot -type f | xargs -- sha512sum > SHA512SUMS

Und einen um die Prüfsumme wieder in Form einer Datei auszulesen und mit einer zu einem vorherigen Zeitpunkt ausgelesenen Prüfsumme zu vergleichen.

Wir hatten so etwas ähnliches kürzlich: damit man bequem mit diff vergleichen kann braucht es Sortierung. Siehe 9418567

gazrilla92 schrieb:

Die Prüfsumme gilt dann nach meinem Verständnis für die jeweilige Partition und wird dann auf dieser abgelegt und bei entsprechenden Veränderungen mitverändert, richtig?

Es ist wirklich dein Problem wo und wie du diese wo ablegst. Du kanns die dann neu machen und per diff vergleichen, von mir aus per sha512sum -c datei checken lassen oder sonstwas. Ich werde dir diese Hausaufgabe für dein hypothetisches Problem nicht abnehmen.

Ich meine mal irgendwo gelesen zu haben, dass in der Boot oder in der Efi Partition unter anderem mitgeloggt wird, wie oft der Computer hochgefahren wurde. Dadurch änderte sich doch die Checksumme bei jedem hochfahren...

Kann sein das sowas in einer EFI Variable (UEFI) gespeichert ist, kann sein das dies eine Date ist, dann ist eben eine Datei immer falsch reported als manipuliert, das ist jetzt nicht so der Stress, du hast auch bei vielen Updates ein Kernel Update dabei oder sonst einen Grund warum sich da was ändern kann.

Dadurch würde doch die Passwortsicherheit als Unsicherheitsfaktor eliminiert. Habe ich da einen Denkfehler?

Dein, ich betone das nochmal: "Hypothetisches" Szenario kann, rein Hypothetisch auch jemand als Angreifer haben der sich mit der Firmware der SSD und LUKS auskennt. Durch die Arbeitsweise moderner SSDs kann sein das du zwar als letzte Operation den LUKS Header platt gemacht hast, dieser aber in den Reservesektoren oder sonstwo noch vorliegt.

Wie schon vor paar Posts geschrieben: KISS. Und immer an XKCD denken, wenn ich in einem Shady Land an dein Password will haue ich dir einfach auf die Fresse bist du es mir aufschreiben musst (mit der nicht gebrochenen Hand). Das klingt Brutal, aber wenn du wichtige Daten hast wird ein Land mit geringerem Verständnis von Grundrechten da nicht lange fackeln. Beachte auch das es Länder gibt die Beugehaft in weniger tollen Gefägnissen als Motivation anbieten.

Referenz: XKCD 538

Nicht alle Probleme sind technisch, das ist eines davon.

gazrilla92 schrieb:

Man sagt zwar, dass in während der forensischen Untersuchung nur das Laufwerk gespiegelt wird, dennoch bieten die unverschlüsselten Partitionen Raum für Manipulationen. Hierzu fallen mir beispielsweise Keylogger oder die Implementierung von Hintertüren ein.

Sowohl /boot/initrd.img als auch die EFI-Firmware könnten manipuliert werden, um das LUKS Passwort abzufangen/die Platte zu durchforsten/Verbindungen zu (Control)Servern aufzubauen. Die EFI-Firmware auf Manipulationen zu überprüfen, dürfte einen größeren Aufwand bedeuten. Bei jeden Start muß von der potentiell manipulierten Firmware gebootet werden. Wenn der EFI-Chip ausgelesen wird oder eine Firmware geflasht wird, sollte man sich nicht zu sicher sein, daß die richtige Information am richtigen Platz landet. Um hier eine Manipulation auszuschließen, müßte man den Chip ausbauen/auslöten und mit einem externen Gerät auslesen und/oder von einem garantiert mit der Original-Firmware bespielten Chip booten.