[linux-l] quick-&-dirty-Lösung für Festplattenverschlüsselung

[Steffen Dettmer]

* Christoph Biedl wrote on Wed, Jun 14, 2006 at 10:47 +0200:
> > Natürlich könnte ich auch /dev/null nehmen, aber /dev/urandom erscheint
> > mir irgendwie sicherer. Liege ich damit richtig?

In Security-Applikationen wird auch immer alles mit Zufallsdaten und
nicht mit Nullen überschrieben. Soweit ich weiss, macht es auch
Rekonstruktionen schwieriger. Dabei meinte ich mal gehört zu haben, dass
je nach Medium durchaus auch mehrere Überschreibvorgänge notwendig sein
können.

> Ich persönlich finde es übertrieben. Schon nach einem einfachen
> Überschreiben der Daten ist der Aufwand zur Wiederherstellung sehr
> hoch.  

Soweit ich weiss, gibt es Firmen, die für ein paar Tausend Euro
"gelöschte Festplatten" oder kaputte restaurieren. Weiss nicht, ob da
auch sowas dabei ist und wie teuer das werden würde. Ich wäre jedenfalls
nicht überrascht, wenn das für ein paar Tausende oder Zehntausende
möglich wäre.

> Paranoide sehen natürlich die Schlapphüte, die weder Mühen noch Kosten
> scheuen, aber besonders realistisch ist das nicht. 

Kommt natürlich auf die Daten an. Das das Löschen nicht wirklich teuer
ist, würde ich als Kunde auch erwarten, dass meine Daten sinnvoll
gelöscht werden.

> Zufallsdaten hingegen "Der hat gecryptet[2], also suchen wir mal den
> Key.". Was als nächstes passiert, überlasse ich Deiner Fantasie.

Wenn der Key brauchbar ist, ist das natürlich viel viel sicherer als
Nullen (ist ja wie ein null-cipher oder cipher mit bekanntem Key).

> Mir selber reicht ein einfaches dd oder badblocks -svw.
>
> > (Die Zeit für einen whiptail habe ich natürlich nicht, zumal es nicht
> > darum geht, sich vor Festplatten-Forensik zu schützen. ;-)
> 
> Eben. /dev/urandom ist nämlich außerdem ziemlich teuer.

Warum ist /dev/urandom ziemlich teuer? Kostet doch nix, maximal ein paar
Sekünchen Zeit, obwohl man ja eh nicht daneben steht, sondern inzwischen
was anderes macht?

> [1] Irgendwo hörte ich mal, daß das mit der Restmagnetisierung (die
>     letzten n Zustände seien noch auslesbar, mit n zwischen 1 und 10),
>     ganz großer Humbug wäre. Kennt jemand Positionen für die eine oder
>     andere Richtung?

Leider nicht, nur Gerüchte. Angeblich gibt es für bestimmte Medien
(Flash?) Algorithmen, die sogar zwischendurch bestimmte Muster
schreiben um bestimmte statistische Angriffe zu erschweren (zehnmal mit
richtigem Zufall überschreiben ist ja statisch u.U. ähnlich wie einmal
mit Zufall, wenn der Speicher "alte Einsen" z.B. besser "refresht" als
"alte Nullen", daher wird angeblich Zufall, 01010101, zufall, 10101010
oder sowas in der Art gemacht.

Kann ich mir physikalisch nicht wirklich vorstellen, klingt aber
andererseits auch irgendwie einleuchtend.

Schlüssel würde ich immer mehrfach mit Zufall überschreiben,
Liebesbriefe einfach nur löschen, der Rest liegt halt entsprechend
dazwischen :)

> [2] Eine gute Crypto unterscheidet sich bekanntlich nicht von zufälligen
>     Daten.

Na ja, kommt auf das Analyseverfahren an. 10 MB Zufall sind wirklich
unabhängig, 10 MB 3DES CBC sehen nur so aus als ob sie das seien und
können angegriffen werden. Im ersten Fall ist die "one time pad"
Schlüsselstärke 10 MB (!), im zweiten Fall 112 Bit. Obwohl man zu Hause
wohl auch keine 10 MB Zufallsdaten erzeugen kann (bzw. ist das nicht so
einfach). Bei crypto keys die z.B. 112 Bit "reine Entropie" zu bekommen,
ist auch nicht einfach, so ein linux /dev/urandom ist sicherlich für
Schlüsselerzeugung nicht stark, /dev/random wohl auch noch nicht, da
sollte man einen Hardwaregenerator nehmen oder zwei, z.B. von einer
electronic-cash Chipkarte oder so. Guten Zufall sollte man ver-XORn
können und die grösste Entropie sollte das Ergebnis sein.

Kann mir aber nicht vorstellen, dass man im "Alltag" so ein hohes Niveau
brauchen sollte und würde /dev/urandom nehmen :-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.