Am Donnerstag, den 17.11.2016, 20:56 +0100 schrieb Christian Knoke: > Sascha Reißner schrieb am 17. Nov um 14:14 Uhr: > > Sobald der LUKS-Container aufgesperrt ist, kann man den Stick bereits > > abziehen, da alle nötigen Sachen in der initramfs liegen die ja schon im > > RAM ist. > > Da ein LUKS-Container einen Header hat, ist dies die einzige Information > > die ein Angreifer bekommt und wieviele aktive Key-Slots vorhanden sind. > > Dieser Header ist auch ein Schwachpunkt, weil man allein auf den header, > ohne den Rest der Platte, einen brut force angriff machen kann. > > Der angreifer klaut erst den header, und bei seinem zweiten Besuch kann er > das System modifizieren. Er muss nicht mehr die ganze Platte kopieren, > sondern kann gezielt nach Informationen suchen. Das ist mir klar. Ich spielte auch mit dem Gedanken die Platte mit crypt-setup ohne LUKS zu verschlüsseln. Dadurch gibt es garkeinen Header und die Platte ist auch voll verschlüsselt. Nachteil ist aber, daß man das Key-File später nicht tauschen kann (außer man macht ein volles Backup der Daten und formatiert die Platte komplett neu). Mit LUKS hab ich die Möglichkeit später das Key-File zu tauschen. Zusätzlich habe ich 8 Key-Slots. Ein Slot enthält eine Passphrase vom einrichten. Diese habe ich belassen für den Fall, daß der Stick mal kaputt oder verloren geht. Dann boote ich mit einer GRML, schließe LUKS mit der Passphrase auf, erstelle ein neues Key-File, lösche das alte Key-File aus dem Key-Slot, füge das neue hinzu und erstelle mir einen neuen Stick. Ohne LUKS müsste ich das Key-File irgendwo ganz sicher aufbewahren, damit ich im Falle eines kaputten oder verloren gegangenen Sticks an meine Daten komme. Im Falle eines Diebstahls müsste ich die Platte mit dem gesicherten Key-File aufsperren, ein volles Backup ziehen und die Platte mit einem neuen Key-File wieder verschlüsseln. Erheblicher Aufwand wenn man bedenkt, daß ich hier jetzt immer nur von der Platte geschrieben habe. In dem Container muß man ja auch die LV's mit den Filesystemen wieder erstellen und die fstab mit den neuen UUID's anpassen. Ein dritter Gedanke kommt mir da: Man kann ein Backup vom LUKS-Header ziehen. Ob LUKS den Header direkt vor dem Container braucht, hab ich noch nicht geprüft. Wenn das nicht erforderlich ist könnte man den Header ebenfalls auf den Stick schreiben und den auf der Platte löschen. Dazu muß man aber die Start-Scripte, die den LUKS-Container öffnen, anpassen, damit diese den LUKS-Header in der Datei auf dem Stick verwenden um den Container auf der Platte zu öffnen. Oder man fügt 2 Scripte hinzu. Das erste schreibt beim Start des Rechners das Backup wieder am Anfang der Platte. Das andere läuft als letztes beim Shutdown und überschreibt den Header auf der Platte wieder mit Datenmüll. Bei beiden Varianten wird das Header-Backup-File zur wichtigsten Datei die man irgendwo absolut sicher verwahren muß für den Fall eines kaputten Sticks. So, das ist mal wieder genug Gedankenspielerei. Vielleicht ist jetzt dem Einen oder Anderen von Euch noch etwas eingefallen. -- mfG Sascha Sich mit wenigem begnügen ist schwer, sich mit vielem begnügen unmöglich. -- Marie von Ebner-Eschenbach
Attachment:
signature.asc
Description: This is a digitally signed message part