[10.11 El Capitan] FileVault - Bitfehler-resistent?

[Wuchtbrumme]

Hallo,
ich möchte gerne ein Backup einiger Ordner mit wichtigen Daten erstellen. Da da wirklich allerhand Informationen dabei sind, die den persönlichen Lebensbereich betreffen (Steuerunterlagen, Passphrases, Keys, Briefe, etc) möchte ich das verschlüsseln.

Nimm doch FileVault? Genau an der Stelle bin ich jetzt. Die Frage ist nur, ist denn FileVault einigermaßen "sicher" im Sinne von was ist mit Bitfehlern? Ich meine nicht "sicher" im Sinne von Verschlüsselung - alles was mehr als 64bit DES ist reicht mir im Prinzip schon mal.
Eine Datensicherung sollte rückspielbar sein und ich kenne noch Zip-Dateien, ein Fehler in der Datei und alles, was danach kam, war verloren. Andererseits gibt es Dateisysteme wie Btrfs und ZFS, die Bitfehler adressieren. Nur zu Filevault finde ich keine Aussage. Dass HFS+ ontop kommt ist mir schon klar. Allenfalls müsste ich wenn dann noch verstehen, wie HFS+ und FV zusammenspielen.

Denken tu ich an 4TiB und werde auch eine Festplatte mit ohne SMR nehmen (keine Experimente mit neuer Technologie, 4TB WD Green ist bewährt).

 

[dg2rbf]

hi..
eine Verschlüsselung ist nicht Bittfehler ressistent, sobald ein Bit defekt ist die ganze Verschlüsselung defekt..

Gruss Franz..

 

[Rastafari]

alles was mehr als 64bit DES ist reicht mir im Prinzip schon mal.

Das wird schwierig, denn DES gibts nur mit 56 Bit.

1) FileVault verschlüsselt das Startlaufwerk, keine externen Medien.
(Externe Volumes lassen sich verschlüsseln, aber das ist nicht der Job von FV.)

2) Du brauchst keine ganzen externen Platten crypten, du kannst auch verschlüsselte Diskimages nutzen. Davon kannst du dann mehrere Kopien vorhalten, und du kannst diese auch problemlos in ein ganz normales, unverschlüsseltes Backup mit aufnehmen, wenn dich das mehr beruhigt.

Andererseits gibt es Dateisysteme wie Btrfs und ZFS, die Bitfehler adressieren.

Ich weiss nicht so recht was du dir darunter vorstellst.
Wenn du glaubst, dadurch würden irgendwie Daten vor einem Verlust durch Hardwarefehler geschützt, dann bist du jedenfalls schwer auf dem Holzweg.

 

[Wuchtbrumme]

Das wird schwierig, denn DES gibts nur mit 56 Bit.

hehe Bitte um Verzeihung, die Frage war nur so "runtergerotzt", weil man manche Sachen einfach mal in Angriff nehmen muss, anstatt zu prokrastinieren.

(Externe Volumes lassen sich verschlüsseln, aber das ist nicht der Job von FV.)

äh - ist dann FV nur der Name des Mechanismus fürs Bootlaufwerk? Ich dachte jedenfalls an die Option der Verschlüsselung aus dem Festplattendienstprogramm und hätte gedacht, dass es sich dabei um FV handelt (wobei mir da schon klar ist, dass fürs Bootlaufwerk ungleich mehr passieren muss)

Du brauchst keine ganzen externen Platten crypten, du kannst auch verschlüsselte Diskimages nutzen.

das wäre dann eine Option, wenn der Inhalt ungleich den Zip-Dateien, von deren unrühmlicher Erfahrung ich sprach, auch partiell recovert werden könnte. Aber das Diskimage ist ja ein Container - muss der in Gänze entschlüsselt werden können, um meinetwegen auf die Datei im letzten "Block" des Geräts zugreifen zu können?

Ich weiss nicht so recht was du dir darunter vorstellst.
Wenn du glaubst, dadurch würden irgendwie Daten vor einem Verlust durch Hardwarefehler geschützt, dann bist du jedenfalls schwer auf dem Holzweg.

Ich glaube natürlich nicht, dass mich das vor Datenverlust schützt. Ich rede aber andererseits nicht von Headcrashs oder ähnlichen Katastrophen, sondern von einzelnen gekippten Bits, die man ja mit ECC oder irgendeiner Redundanz adressieren könnte. Wenn ich von unverschlüsselten Dateisystemen ausgehe, dann habe ich ein Wurzelverzeichnis und davon abzweigend ein Verzeichnis für Steuererklärungen, für Keys usw. Hätte ich da einen Bitfehler, wäre vermutlich eine Datei unrettbar. Ich möchte einfach "nur", dass dieselbe Risikoabschätzung auch für mein verschlüsseltes Volume gilt, habe aber leider gar keine Ahnung.

 

[Rastafari]

ist dann FV nur der Name des Mechanismus fürs Bootlaufwerk?

Check.

wenn der Inhalt ... partiell recovert werden könnte

Es gibt nur wenige (ernsthaft) verschlüsselnde Formate, die durch das optionale hinzufügen einiger Prozent an redundanten Daten ein Stück weit fehlertolerant erstellt werden können. Die wichtigsten beiden in diesem Anwendungsbereich sind RAR und SITX (aka "StuffIt"). Die haben aber gemeinsam, dass sie nicht als gewöhnliches beschreibbares Medium nutzbar sind (bei jeglicher nachträglicher Änderung müssen diese sehr resourcenfressend komplett neu erstellt werden).
Eine Alternative könnte zB so etwas für dich bieten. Das kennt zwar keine Recover-Funktionen, aber es werden damit keine Archive erstellt, sondern jede einzelne Datei für sich allein gestellt gespeichert. (Die Ordnerstruktur bleibt sichtbar, aber alle Inhalte und Namen sind verschleiert.)
Diese gewöhnlichen Dateien lassen sich ganz bequem mit TM in ein Backup aufnehmen und dadurch vor Verlust schützen. Ist auch eine der wenigen Lösungen, die plattformübergreifend unter allen relevanten OS funktionieren, wenn auch nur mit sehr magerer Performance. Aber immerhin...
Dazu ist allerdings zu erwähnen, dass das nicht der Sicherung von Daten auf dem Rechner selbst dient, sondern seine Schutzfunktion NUR auf externen Medien entfalten kann (auf der lokalen HD können unverschlüsselte Fragmente der Dateien zurückbleiben, die evtl durch Recovery-Programme gefunden werden können). Sprich: Das Programm dient nur dem Schutz von archivierten oder transportierten Daten.

muss der in Gänze entschlüsselt werden können, um meinetwegen auf die Datei im letzten "Block" des Geräts zugreifen zu können?

Ja, das ist unvermeidbar bei solchen Verschlüsselungsmethoden.

sondern von einzelnen gekippten Bits, die man ja mit ECC oder irgendeiner Redundanz adressieren könnte

Das macht bereit jede Festplatte ganz ohne weiteres Zutun. Seit es Festplatten gibt (fast).

 

[ImperatoR]

Ist die Volumen-Verschlüsselung von Mac OS X nicht Black-basiert? Das müsste doch bedeuten, dass wenn du einen Block durch einen Bitfehler "verlierst", sollten zumindest die anderen Blocks noch immer entschlüsselbar sein (im Sinne von intakte Daten herstellen)?

 

[Wuchtbrumme]

Ich habe mir meine Fragen mal auch praxis-relevant selbst zu erklären versucht. Ein 5,5GB-Sparse Bundle mitwachsend mit HFS+ und verschlüsselt im FPDP gebaut und dann:

macbookpro:~ root# cd /Volumes/secure\ Test/

macbookpro:secure Test root# dd if=/dev/random of=./test1.bin bs=1000000 count=1000
1000+0 records in
1000+0 records out
1000000000 bytes transferred in 72.288768 secs (13833408 bytes/sec)
macbookpro:secure Test root# dd if=/dev/random of=./test2.bin bs=1000000 count=1000
1000+0 records in
1000+0 records out
1000000000 bytes transferred in 74.141728 secs (13487681 bytes/sec)
macbookpro:secure Test root# dd if=/dev/random of=./test3.bin bs=1000000 count=1000
1000+0 records in
1000+0 records out
1000000000 bytes transferred in 73.889205 secs (13533777 bytes/sec)
macbookpro:secure Test root# dd if=/dev/random of=./test4.bin bs=1000000 count=1000
1000+0 records in
1000+0 records out
1000000000 bytes transferred in 68.261186 secs (14649614 bytes/sec)
macbookpro:secure Test root# dd if=/dev/random of=./test5.bin bs=1000000 count=1000
1000+0 records in
1000+0 records out
1000000000 bytes transferred in 68.934535 secs (14506517 bytes/sec)
macbookpro:secure Test root# dd if=/dev/random of=./test6.bin bs=1000000 count=1000
dd: ./test6.bin: No space left on device
127+0 records in
126+2 records out
126496768 bytes transferred in 8.800035 secs (14374576 bytes/sec)

macbookpro:secure Test root# find ./ -name 'test*.bin' -exec md5sum -b {} \; >> /Volumes/Ohne\ Titel/md5sums_before.txt

Hier habe ich das verschlüsselte Dateisystem ausgeworfen und mir den Paketinhalt vom Sparsebundle-Ordner anzeigen lassen und eine Datei recht weit am Anfang einfach weggeworfen. Dann Sparsebundle wieder gemountet.

macbookpro:secure Test root# find ./ -name 'test*.bin' -exec md5sum -b {} \; >> /Volumes/Ohne\ Titel/md5sums_after.txt  

macbookpro:secure Test root# sdiff ../Ohne\ Titel/md5sums_before.txt ../Ohne\ Titel/md5sums_after.txt
12bbf06d94f5bbda522797c2df6838a7 *.//test1.bin                | b467b423fb422bbe12547a61304126ff *.//test1.bin
ba5b0fa0a8078aeb843d4aa5a1f8cf30 *.//test2.bin                  ba5b0fa0a8078aeb843d4aa5a1f8cf30 *.//test2.bin
3ac9040a6f3f91591e81c6df9d185cab *.//test3.bin                  3ac9040a6f3f91591e81c6df9d185cab *.//test3.bin
9d93c655d62fc7b1dce6e1e49c078bb5 *.//test4.bin                  9d93c655d62fc7b1dce6e1e49c078bb5 *.//test4.bin
643444b57999c7dc72dcadc4b17e85c5 *.//test5.bin                  643444b57999c7dc72dcadc4b17e85c5 *.//test5.bin
ab25d731ecfaff7fa537c3111e08b1e4 *.//test6.bin                  ab25d731ecfaff7fa537c3111e08b1e4 *.//test6.bin
macbookpro:secure Test root#

Damit ist geklärt:
-das verschlüsselte Sparsebundle ist tolerant ggü. kaputten/fehlenden eigenen Teilen (vmtl. mit der Einschränkung: solange das Dateisystem OK ist; wenn man die erste Datei weggeworfen hätte, sähe das wahrscheinlich anders aus)
-Dateien nach einem Bitfehler (oder gar 8,3MB Leere (Größe des weggeworfenen Teils)) bleiben intakt
-Fehler betreffen nur die Datei, die in den Sektoren liegt, in denen die Fehler sind

...das reicht mir, weil es keine Verschlechterung gegenüber unverschlüsselt ist.

...einen Hinweis noch, weil beim Unmounten aufgefallen: OS X kann das kaputte Sparsebundle nicht auswerfen. Mit diskutil umount force <disk> ging es dann. Soll heißen: kaputt ist so ein Laufwerk dann doch schon.