# Nachträgliches Verschlüsseln

## sewulba

Hallo...

Ich möchte gerne die Festplatte in meinem Laptop nachträglich verschlüsseln.   :Rolling Eyes: 

Meine Recherche hat ergeben, dass ich dazu dm-crypt benutzen muss. Allerdings habe leider keine Anleitung gefunden, wie ich mein komplettes System nachträglich komplett verschlüsseln kann. Wäre sehr dankbar, wenn mir mal eider eineer von euch da weiter helfen könnte mit einem guten Link, bzw. kleiner Anleitung wie ich da vorgehen muss.

THNX.

Gruss Sewulba   :Wink: 

----------

## ScytheMan

am einfachsten wäre es wenn du ein externes backup anfertigtst, dort alles auslagerst und dann z.b. nach 

http://de.gentoo-wiki.com/wiki/DM-Crypt oder

http://en.gentoo-wiki.com/wiki/DM-Crypt oder

http://en.gentoo-wiki.com/wiki/Root_filesystem_over_LVM2,_DM-Crypt_and_RAID

alles nötige erstellst und dann wieder zurückkopierst.

----------

## schachti

Das geht rein theoretisch auch on-the-fly (habe ich selbst schon gemacht) - wenn dabei aber der Rechner abstürzt, der Strom ausfällt etc., sind die Daten unter Umständen weg.

Anleitung: http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptExistingDevice (im Google-Cache).

----------

## fangorn

Es wurde hier im Forum mal eine Anleitung gepostet, wie man on the fly eine Partition in eine dm-crypt verschlüsselte Partition umwandeln kann. Allerdings ohne LUKS Erweiterungen, sodas ich nur davon abraten kann. Die Verschlüsselung ist ohne LUKS nachweislich angreifbar! 

Hinzu kommt das Problem mit dem Datenverlust wenn irgendetwas schief geht. 

Ich kann auch nur davon abraten, eine Partition on the fly zu verschlüsseln. 

Daten verschieben, ein Backup vom System erstellen, verschlüsseln, Backup wiederherstellen, daten zurückkopieren. 

Nebenbei hast du dann ein Backup erstellt, was auch keine schlechte Idee ist.   :Wink: 

----------

## ScytheMan

hinzufügen sollte man vllt. noch, dass wenn man ein backup erstellt, dieses auch nachdem man das system erstellt hat löschen sollte. 

da eine verschlüsselung nichts bringt, wenn die daten plain vorhanden sind.

sichere datenlöschung funktioniert mit shred (vllt. etwas überparanoid) und z.b. dd mit belegung if=/dev/urandom oder /dev/random oder /dev/null. 

was hierbei als "sicher" gilt, da streiten sich die geister. näheres dazu findet man unter anderem unter dem stichwort "restmagnetisierung"

----------

## schachti

Ich würde das Backup auf gar keinen Fall löschen (was bringt mir das Backup dann noch?), sondern mit GPG verschlüsseln und dann archivieren.

----------

## fangorn

Externe Festplatten kann man wunderbar verschlüsseln, bevor man ein Backup darauf erstellt.   :Wink: 

----------

## mv

 *fangorn wrote:*   

> Die Verschlüsselung ist ohne LUKS nachweislich angreifbar!

 

Diese Information ist schlichtweg falsch.

----------

## fangorn

 *mv wrote:*   

>  *fangorn wrote:*   Die Verschlüsselung ist ohne LUKS nachweislich angreifbar! 
> 
> Diese Information ist schlichtweg falsch.

 

Soll ich sie relativieren und sagen. 

dmcrypt ohne LUKS-Erweiterung ist angreifbarer.

 :Question: 

Bei Verschlüsselung geht es nicht um absolute Sicherheit. Es geht um Wahrscheinlichkeiten. Wie wahrscheinlich ist es, dass jemand der meinen Schlüssel nicht kennt die Daten entschlüsseln kann. 

Wenn die Berichterstattung damals nicht komplett falsch war, wurden die LUKS-Erweiterungen nach einer Analyse von cryptsetup in den Hauptzweig von cryptsetup übernommen, weil die Wahrscheinlichkeit einer Entschlüsselung ohne LUKS signifikant höher war als bei anderen Lösungen und bei cryptsetup mit LUKS. 

Ich kann nicht voraussetzen, dass jeder die damalige Diskussion verfolgt hat. Da ich keine Romane schreiben will und keine Linkorgie parat habe, rate ich von dmcrypt ohne LUKS schlicht ab.

----------

## r3tep

Um zu Verhindern, dass kritische Daten bei Verlust des Laptops in fremde Hände gelangen, sollten dmcrypt/LUKS bzw. Truecrypt ausreichen. Alternativ lassen sich Daten auch mit GPG verschlüsseln.

Nichtsdestrotz können all diese drei Methoden umgangen werden, wie das vor einiger Zeit z.B. bei Truecypt bewiesen wurde.

----------

## mv

 *fangorn wrote:*   

> dmcrypt ohne LUKS-Erweiterung ist angreifbarer

 

Ist genauso falsch.

 *Quote:*   

> Wenn die Berichterstattung damals nicht komplett falsch war, wurden die LUKS-Erweiterungen nach einer Analyse von cryptsetup in den Hauptzweig von cryptsetup übernommen, weil die Wahrscheinlichkeit einer Entschlüsselung ohne LUKS signifikant höher war als bei anderen Lösungen und bei cryptsetup mit LUKS.

 

Ich weiß nicht, von welcher Berichterstattung Du sprichst, aber der Unterschwied zwischen LUKS und nicht-LUKS ist nur, dass LUKS das eigentliche Passwort (und möglicherweise auch den Cipher-Namen, das weiß ich jetzt nicht auswendig) im ersten Block speichert; deswegen werden die Daten alle um einen Block nach hinten geschoben, und daher ist online Ver-/Entschlüsselung nicht möglich. Und deswegen kann man bei LUKS das User-Passwort "im Nachhinein" ändern, weil es nur zur Verschlüsselung des ersten Blocks benutzt wird. Sicherheitstechnisch könnte das Verfahren höchstens dann einen Unterschied machen, wenn der Hash-Algorithmus für das User-Passwort schlecht oder gar vollkommen gebrochen wäre.

Vielleicht ging es in der damaligen Diskussion über andere Aspekte: Die heutzutage üblichen Block-Modi (damals vermutlich zunächst cbc-essiv) u.ä. kamen ca. zeitgleich mit LUKS zu dmcrypt hinzu, möglicherweise ursprünglich im Rahmen der LUKS-Erweiterung. Diese können aber auch ohne LUKS benutzt werden.

----------

## zyko

LUKS hat in speziellen Szenarien einige praktische und theoretische Vorteile gegenüber dem alten Cryptsetup: Bei Cryptsetup-ohne-LUKS wird für die Erstellung des Ciphertextes eine Funktion des benutzergenerierten Passwortes verwendet. Beim Cryptsetup-mit-LUKS ist der Ciphertext unabhängig vom benutzergenerierten Passwort. Das ist kryptologisch ein sehr wichtiger Punkt, denn ersteres gilt unter Umständen als inhärentes Risiko.

Die Passworthierarchie nach LUKS macht beispielsweise Angriffe der Variante Chosen-Plaintext/Chosen-Ciphertext schwerer. Das heißt praktisch: Wer verschiedene Klartexte (=Partitionen, Festplatten) mit demselben Passwort verschlüsselt, oder mehrfach denselben Klartext mit verschiedenen Passwörtern (Backups), sollte unbedingt LUKS verwenden! Anderenfalls werden o.g. Angriffe erleichtert. Bei Verwendung von aes-xts oder serpent-xts weist dieser Punkt sicherlich eine sehr geringe Realitätsnähe auf.

LUKS hat ebenfalls wichtige Implikationen im Bezug auf Angriffe der Variante "Brute Force". Durch das zeitaufwändige Verfahren, mit dem der Masterkey verschlüsselt ist, werden Brute-Force-Angriffe auf das eigentliche Passwort unpraktikabel. Bei schwachen Passwörtern (<128bit, <22 Zeichen) ist LUKS daher um Welten sicherer, da ein Angreifer hier nicht mehr das eigentliche Passwort erraten kann, sondern an den (erheblich größeren) Masterkey ran muss. D.h. als User von LUKS muss man sich um die "Bruteforcebarkeit" von kurzen Passwörtern keine großen Gedanken machen.

Am allerwichtigsten ist jedoch, dass das Passwort durch Neuverschlüsselung/Zerstörung des Masterkeys nutzlos wird. Das bedeutet, dass man die verschlüsselten Daten zuverlässig geheimhalten/zerstören kann, selbst wenn das Passwort (etwa durch Keylogger) bekannt geworden ist! Beim alten Cryptsetup-ohne-LUKS wurde der Ciphertext wie gesagt als Funktion des Passwortes generiert. Bei Bekanntwerden des Passwortes hätte man in diesem Szenario den gesamten Ciphertext zerstören müssen. Letzteres dauert sehr lange und ist rein theoretisch nicht zuverlässig möglich, da Festplatten überschriebene Daten als elektromagnetische Signatur behalten können.

Diese Revocability des Passworts ist sehr wichtig und hat große praktische Implikationen.

----------

## mv

 *zyko wrote:*   

> LUKS hat in speziellen Szenarien einige praktische und theoretische Vorteile gegenüber dem alten Cryptsetup: Bei Cryptsetup-ohne-LUKS wird für die Erstellung des Ciphertextes eine Funktion des benutzergenerierten Passwortes verwendet. Beim Cryptsetup-mit-LUKS ist der Ciphertext unabhängig vom benutzergenerierten Passwort. Das ist kryptologisch ein sehr wichtiger Punkt, denn ersteres gilt unter Umständen als inhärentes Risiko.

 

Höchstens dann, wenn entweder Hash- oder Cipheralgorithmus als gebrochen zu betrachten sind - und zwar massiv gebrochen (nicht nur, wie bei MD5, dass man irgendwelche Kollissionen erzeugen kann).

 *Quote:*   

> Die Passworthierarchie nach LUKS macht beispielsweise Angriffe der Variante Chosen-Plaintext/Chosen-Ciphertext schwerer. Das heißt praktisch: Wer verschiedene Klartexte (=Partitionen, Festplatten) mit demselben Passwort verschlüsselt, oder mehrfach denselben Klartext mit verschiedenen Passwörtern (Backups), sollte unbedingt LUKS verwenden! Anderenfalls werden o.g. Angriffe erleichtert.

 

Wer das selbe Passwort mehrmals benutzt, muss immer damit rechnen, dass ein erfolgreicher Angriff auf eine Partition dann auch auf die andere Partition erfolgreich ist. Damit muss man mit oder ohne LUKS rechnen, denn man weiss nicht, welche Art von Angriff ggf. erfolgreich war. Das Argument mit Chosen-Plaintext/Chosen-Chipertext lasse ich nicht gelten, da sich die Möglichkeiten ja nicht ver-10^x-fachen sondern bei 3 gleich großen Partitionen nur verdreifachen, was statistisch vollkommen irrelevant ist; dies ist höchstens dann ein Argument, wenn man eine riesige Plattenfarm betreut und alle einzeln verschlüsselt. Aber wer da immer das selbe Passwort benutzt, ohne auf andere Dinge zurückzugreifen, dem ist sowieso nicht zu helfen. Der andere genannte Punkt (verschiedene Passworte für die selben Daten) ist schlichtweg falsch, weil das mit LUKS auch nicht anders aussieht.

 *Quote:*   

> Am allerwichtigsten ist jedoch, dass das Passwort durch Neuverschlüsselung/Zerstörung des Masterkeys nutzlos wird. Das bedeutet, dass man die verschlüsselten Daten zuverlässig geheimhalten/zerstören kann, selbst wenn das Passwort (etwa durch Keylogger) bekannt geworden ist! Beim alten Cryptsetup-ohne-LUKS wurde der Ciphertext wie gesagt als Funktion des Passwortes generiert. Bei Bekanntwerden des Passwortes hätte man in diesem Szenario den gesamten Ciphertext zerstören müssen. Letzteres dauert sehr lange und ist rein theoretisch nicht zuverlässig möglich, da Festplatten überschriebene Daten als elektromagnetische Signatur behalten können.
> 
> Diese Revocability des Passworts ist sehr wichtig und hat große praktische Implikationen.

 

Wenn man keine Argumente mehr hat, erfindet man sich Phantasie-Szenarien: "da Festplatten überschriebene Daten als elektromagnetische Signatur behalten können" ist schon seit langer Zeit bei modernen Festplatten nur noch eine Urban legend; und selbst wenn man das könnte, ist ja der erste Sektor soviel schwerer zu restaurieren als der Rest. Und dass jemand einen Keylogger installieren kann, es aber nicht schafft, den ersten Sektor zu sichern ist erst recht an den Haaren herbeigezogen - wenn die Daten so brisant sind, dass ein Entdecken eines Keyloggers ihre gesamte Vernichtung rechtfertigt, dann kommt es auf die Vernichtung der Festplatte (so man denn tatsächlich glaubt, die Festplattenhersteller würden nur aus Unfähigkeit deren Speicherkapazität nicht vervielfachen) auch nicht mehr an.

Die "große praktische Implikation", die für den normalen Mann gilt, ist vielmehr eine andere: Wenn man LUKS benutzt hat, so kann das Umkippen eines Bits in nur einem einzigen Sektor die gesamten Daten vernichten.

Und nebenbei: Die ganzen genannten Argumenten haben mit der LUKS-Erweiterung gar nichts zu tun. Wer - aus welchen Gründen auch immer - ein generiertes Passwort für die Daten benutzen will, der kann dies ohnehin tun; dafür muss man nicht den LUKS-Unsinn mitmachen, alle Daten zu verschieben, um so eine Online Ver-/Entschlüsselung grundsätzlich unmöglich zu machen.

----------

## cryptosteve

 *mv wrote:*   

> Die "große praktische Implikation", die für den normalen Mann gilt, ist vielmehr eine andere: Wenn man LUKS benutzt hat, so kann das Umkippen eines Bits in nur einem einzigen Sektor die gesamten Daten vernichten.

 

Kannst Du das etwas genauer erklären bzw. hast einen Link dazu?

Ich habe seit einiger Zeit mein /home auf einer LUKS-Paritition ... nicht so sehr aus Angst, der Geheimdienst von nebenan steigt durch Oberlicht ein und entschlüsselt meine bedeutungslosen Schreiben und Familienfotos, sondern vielmehr, um die Daten bei Verlust/Diebstahl des Gerätes nicht sofort jedem zugänglich zu machen.

----------

## schachti

 *Steve` wrote:*   

>  *mv wrote:*   Die "große praktische Implikation", die für den normalen Mann gilt, ist vielmehr eine andere: Wenn man LUKS benutzt hat, so kann das Umkippen eines Bits in nur einem einzigen Sektor die gesamten Daten vernichten. 
> 
> Kannst Du das etwas genauer erklären bzw. hast einen Link dazu?
> 
> 

 

Der Punkt ist relativ klar: Wenn Du LUKS verwendest und der Sektor auf der Festplatte, in der das Passwort für die Verschlüsselung gepseichert ist, geht kaputt, kommst Du an die gesamten Daten nicht mehr ran. Das liegt daran, dass LUKS die Daten mit einem zufällig (?) gewählten Passwort verschlüsselt, und dieses Passwort wiederum wird (mit dem Passwort, dass Du als Benutzer Dir ausgedacht hast) verschlüsselt am Anfang der Partition gespeichert.

Daher kann man nur empfehlen, den entsprechenden Bereich anderweitig zu sichern. Macht das LUKS angreifbarer?

----------

## trikolon

Hallo,

ich hänge mich einfach mit an diese Diskussion auch wenn meine Frage etwas OT ist.

Ich habe eine verschlüsselte Daten-hd, welche ich per Passworteingabe freischalte. Da ich meine Server aber nachts immer herunterfahre ist es ziemlich lästig jeden Morgen das Passwort erneut einzugeben. Gibt es denn eine feine Möglichkeit wie man das umgehen kann? Ich weiss, dass man z.B. mit einem Passwortfile und usb stick arbeiten könnte, ist mir aber ehrlichgesagt auch nicht ganz geheuer... habt ihr noch Ideen dazu?

Gruß Ben

----------

## manuels

 *mv wrote:*   

> Die "große praktische Implikation", die für den normalen Mann gilt, ist vielmehr eine andere: Wenn man LUKS benutzt hat, so kann das Umkippen eines Bits in nur einem einzigen Sektor die gesamten Daten vernichten.

 Bist du dir da sicher?

Ich meine (leider finde ich gerade keine Quelle um es zu belegen), dass die Schlüsselinformationen mehrfach auf der Festplatte verteilt abgelegt werden.

----------

## cryptosteve

 *trikolon wrote:*   

> Ich habe eine verschlüsselte Daten-hd, welche ich per Passworteingabe freischalte. Da ich meine Server aber nachts immer herunterfahre ist es ziemlich lästig jeden Morgen das Passwort erneut einzugeben. Gibt es denn eine feine Möglichkeit wie man das umgehen kann? Ich weiss, dass man z.B. mit einem Passwortfile und usb stick arbeiten könnte, ist mir aber ehrlichgesagt auch nicht ganz geheuer... habt ihr noch Ideen dazu?

 

An was hast Du denn sonst gedacht? Fingerprint? Eye-Scanner?  :Smile: 

Kurzum: eigentlich geht nur Passwort oder Keyfile ...

----------

## py-ro

Was hätte eine Verschlüsselung für einen Sinn, wenn man die Passwort-/Keyeingabe umgehen könnte?

Py

----------

## mv

 *manuels wrote:*   

> Ich meine (leider finde ich gerade keine Quelle um es zu belegen), dass die Schlüsselinformationen mehrfach auf der Festplatte verteilt abgelegt werden.

 

Ich habe jetzt nachgesehen: Jein, der Header ist 516K gross, und dort wird es laut einer Webseite "redundant" gespeichert. Eine Grobdurchsicht der Sourcen lieferte aber keinen Error-Correcting Code we Reed-Solomon o.ä., so dass ich vermute, dass es wirklich einfach nur mehrmals hintereinander geschrieben wird o.ä., was natürlich bei dem "typischen" Festplattendefekt (Ausfall einer Spur) nicht wirklich hilft. Mir jedenfalls ist es lieber, ich habe das Passwort in einem File und kann dieses ganz ordinär sichern. Für Leute, die LUKS benutzen, würde ich mal (aufgrund der obigen informellen Beschreibung) vermuten, dass sie dieses File mit 

```
dd if=/dev/sd... of=/root/password_of_sd... count=1032
```

 erzeugen können. Ich gebe aber keine Gewähr für die Größe - die habe ich nur aus einer informellen Beschreibung auf einer Webseite gesehen und nicht anhand der Sourcen verifiziert.

----------

## think4urs11

 *trikolon wrote:*   

>  habt ihr noch Ideen dazu?

 

Klar, eine ganz wilde:

Die Passphrase zum einhängen der Platte wird via eines response-Headers von einem Server im Internet (den natürlich du kontrollierst) zurückgeschickt bei einer Anfrage nach http://my.server/gimme_phrase also etwas wie "ETag:'98447cf737060cd8c284d8af7ad3082f209582d'"

----------

## toralf

 *ScytheMan wrote:*   

> näheres dazu findet man unter anderem unter dem stichwort "restmagnetisierung"

 Nun ja, http://www.heise.de/ix/news/foren/S-Mehrfaches-Ueberschreiben-ueberfluessiger-Unsinn/forum-135755/msg-14754790/read/

 :Smile: 

----------

