FileVault mit 256Bit. Tipp!

[SilentCry]

Liebe Freunde,
nachdem offenbar lt. macmacken (http://www.macmacken.com/2007/12/09/10-schwaechen-von-filevault/) der Leopard zwar AES256 kann, auf FileVault aber nicht anwendet, hier ein kurzer Tipp, wie man FileVault dazu bringt, AES256 zu verwenden.

Vorweg: Viele Tests habe ich noch nicht gemacht. Über stabiles Arbeiten kann ich wenig sagen.
Alle Verwaltungsfunktionen sind als Admin zu tun.

Schritt 1: Festplattendienstprogramm
Man erstellt im Festplattendienstprogramm ein mitwachsendes Sparsebundle mit Angabe der entspr. Maximalgröße. Wichtig dabei ist, dass es so heisst wie der User (in meinem Beispiel test) und auch der Dateiname am besten schon test gewählt wird. Am Ende steht also ein test.sparsebundle irgendwo. (Ich habe es in das Verzeichnis "Für alle User" gestellt).
Achtung: Wir wählen natürlich AES256! Sonst macht es keinen Sinn!

Schritt 2: Zugriffsrechte
Man muss dem User test R/W-Rechte geben. Am einfachsten im Finder unter Informationen. Auch innerhalb des gemounteten Images sollte man am Besten Ownership setzen. Ordner kann man nach Belieben schon kopieren oder generieren, nur Schreibtisch, Downloads und Library würde der Login beim ersten Mal anlegen.

Schritt 3: Benutzer anlegen
Ganz normal Benutzer test anlegen, mit FileVault absichern (nanonanet, weswegen machen wir denn den Zauber? ;.).

Schritt 4: Die Shell.
Leider kann man in das Verzeichnis eines FileVault-Users nicht hinein.
Daher muss man auf der Shell (bash) als Admin entsprechende sudo-Operationen ausführen.
Zuerst geht man in das root-Verzeichnis, dann in Users:
cd /Users/
Unter der Voraussetzung dass im "Für alle User" (aka Shared) nur das sparsebundle liegt hier der sudo, kopiert das test.sparsebundle in das Userdir test:
sudo cp -R Shared/* test/
Zur Sicherheit den Owner setzen:
sudo chown test test/*
Und checken, ob es klappte:
sudo ls -lisa test
Man sieht das test.sparseimage, den Eigentümer test und rwx als seine Zugriffsrechte.

Nun kann man sich als Admin ausloggen und als test einloggen und siehe da, es geht.

Ein sudo ls -lisa test
liefert sowas wie das da:
total 16
2 0 drwx------+ 12 admin staff 476 Feb 11 19:20 .
31113 0 drwxr-xr-x 8 root admin 272 Feb 11 19:20 ..
112 16 -rw-------@ 1 test staff 6148 Feb 11 19:26 .DS_Store
25 0 drwx------ 3 root staff 102 Feb 11 19:20 .Spotlight-V100
115 0 drwx------ 2 test staff 68 Feb 11 19:20 .Trash
20 0 dr-x------@ 3 admin staff 102 Feb 11 19:17 .Trashes
21 0 dr-x------+ 5 admin staff 170 Feb 11 19:21 .fseventsd
101 0 drwx------+ 3 test staff 102 Feb 11 19:20 Desktop
87 0 drwx------+ 3 test staff 102 Feb 11 19:20 Downloads
56 0 drwx------+ 13 test staff 442 Feb 11 19:27 Library

(Euch sollte es besser gehen, ich habe nämlich vergessen, vorher die Ordner wie Dokumente und dgl. zu kopieren).

Eine Verbesserung wäre wahrscheinlich zuerst einmal als test anzuloggen, bevor man den ganzen Zinober mit AES256 veranstaltet und die Ordnerstruktur komplett umzukopieren in den neuen Container bevor man ihn dem System "unterschiebt".

Achja: Ich schreibe dieses Forenupdate mit dem User test mit dem ich das gerade exerziert habe. Scheint also zu klappen.

Edit: Und so sieht es aus, wenn man test abgemeldet hat:
Users admin$ sudo ls -lisa test
total 0
365670 0 dr-x------ 3 test staff 102 Feb 11 19:00 .
31113 0 drwxr-xr-x 8 root admin 272 Feb 11 19:48 ..
365671 0 drwx------@ 6 test staff 204 Feb 11 19:00 test.sparsebundle

 

[reab]

Vorweg: Viele Tests habe ich noch nicht gemacht. Über stabiles Arbeiten kann ich wenig sagen.

Und genau deshalb: Finger weg!

 

[mds]

Was nützt AES-256, wenn das Hauptkennwort mit deutlich schwächerer Verschlüsselung gespeichert wird und auch das eigene Benutzerkennwort kaum AES-256-Stärke haben dürfte?

Das fehlende AES-256 ist eine von zahlreichen FileVault-Schwächen, aber wenn ich zwischen AES-256 und Full Disk Encryption mit FileVault wählen könnte, würde ich die Full Disk Encryption wählen …

Martin

 

[SilentCry]

Was nützt AES-256, wenn das Hauptkennwort mit deutlich schwächerer Verschlüsselung gespeichert wird und auch das eigene Benutzerkennwort kaum AES-256-Stärke haben dürfte?

Ja, ich kenne die 23C3 auch. Das sind dennoch Infos aus 2006. Ich habe die Autoren (Jacob Appelbaum und Ralf-Philipp Weinmann) des Vortrags schon mal angeschrieben, wie denn das mit Leopard sei. Keine Antwort. In 10.4.7 war es "3DES effective 112bit || AES-128 || RSA-1024" aber wie ist es in 10.5?

Das fehlende AES-256 ist eine von zahlreichen FileVault-Schwächen, aber wenn ich zwischen AES-256 und Full Disk Encryption mit FileVault wählen könnte, würde ich die Full Disk Encryption wählen …

Signed. Natürlich fehlt OS X eine Fulldisk-Encryption, keine Frage.

 

[SilentCry]

Und genau deshalb: Finger weg!

Das möge doch bitte jeder selbst entscheiden - ich habe nie behauptet, ich würde für einen reibungslosen Ablauf garantieren. Wiewohl ich schon relativ entspannt bin. Wenn der Container vom System gemounted und als $home angesprochen wird, scheint es OS X egal zu sein, welchen Algorithmus es zum ver-/entschlüsseln nimmt.

Ich habe eben keine explizite Testmaschine, aber sollte jemand über eine solche verfügen und das dort ausprobieren wäre ich über Ergebnisse solcher Praxis-/Lasttests sehr erfreut.

 

[reab]

Truecrypt
http://www.macnews.de/news/106235.html
http://www.truecrypt.org/

 

[SilentCry]

Truecrypt

Wie bindet man TC so ein, dass es beim Anmelden das Homedir zur Verfügung stellt?
TC wäre fantastisch, wenn sie die Funktion wie in der Windowsversion - Full Bootdisk-Encryption - auch am Mac implementiert hätten. Reich könnten sie werden, reich. Aber leider...

 

[Rastafari]

TC wäre fantastisch, wenn sie die Funktion wie in der Windowsversion - Full Bootdisk-Encryption - auch am Mac implementiert hätten.

Wieviel Kopfgeld zahlst du für einen Hack, der die Windowsversion als Nullnummer zerlegt?

 

[SilentCry]

Ich kenne das System von TC nicht, da es das nicht für Mac gibt, habe ich mich damit nicht beschäftigt. Aber wenn sie nicht ganz blöde sind...

 

[Rastafari]

Aber wenn sie nicht ganz blöde sind...

Das hat nichts mit "blöde" zu tun.
Sichere FDE ohne entsprechende Hardwareunterstützung ist unmöglich.
Solange BIOS und der Controller der HD das nicht direkt unterstützen (und zwar nativ im ROM), ist das alles nur ein Schildbürgerstreich.
Diese Kröte hat auch Microsoft beim Vista "BitLocker"-Flop schon schlucken müssen. Und die haben sich wirklich reingehängt.

 

[SilentCry]

Wir werden wohl bald wieder um etwas rumdisktutieren... aber eine FullHDD-Encryption halte ich genau dann für sinnvoll, wenn einem die HW entzogen wird. Weil man dann sicher sein kann, dass nichts (in Worten: Nichts) kompromittierendes auf der Platte aufzufinden ist.
Wenn der Schutz gut ist, wäre auch Suspend to Disk wieder eine Option.

Sollte natürlich eine außeridische Rasse mit Asgard-Hirnsonden kommen und im Namen des Antiterrors ... ;.) eh scho' wissen.

Edit: Übrigens wäre ich auch dafür: HW-Encryption, abgefragt im EFI und von dort auch gestützt. Klar wäre mir das lieber.

 

[reab]

Ich kenne das System von TC nicht, da es das nicht für Mac gibt...

Doch, doch gibt es.

 

[SilentCry]

Doch, doch gibt es.

Sorry, missverständlich: Die FULL HDD-Encryption mit Preboot-Authentication gibt es nicht für Macs.

 

[Rastafari]

aber eine FullHDD-Encryption halte ich genau dann für sinnvoll, wenn einem die HW entzogen wird.

Was hilft dir denn in dem von dir gemutmassten Super-kontroll-terror-repressions-Staat ein Verbergen deiner Daten, wenn man dir mühelos den Besitz von willkürlich gewählten, frei erfundenen Daten jederzeit absolut glaubwürdig unterstellen kann?

Ein simples Beispiel. Gegeben sei folgender Ciphertext (oder auch nur eine zufällig entstandene Bytefolge mit gänzlich anderer Bedeutung, die ich nur als Ciphertext vermute bzw eine kryptographische Verschleierung des Inhalts unterstelle - könnte auch purer Nonsense sein):

0x...  
  10 51 11 47  0F 4E 01 5C   16 5A 9B 0D  19 06 08 13 
  5A 0E 09 0F  03 18 5E 1B   5C 42 05 13  1B 58 29 52 
  12 33 66 3C  23 D8 A5 46   17 1C 14 15  32 5B 22 35 
  3E 3F 06 17  05 55 E1 5C   06 5A 04 0F  01 54 26 07 
  3D 36 20 56  0A 06 09 13   1A 5E 6F 3E  15 1F 1B 1C 
  02 55 10 5A  16 54 C9 54   5C 17 49 1F  06 56 7F 24 
  12 42 43 05  0E 25 0F 48   0E 2F 04 00  47 56 5E 15 
  54 3C 3A 66  27 04 0D 1E   07 16 24 4B  02 1D 09 1B 
  4F 57 14 4E  19 7F 53 4A   52 16 33

Auf diese irgendwo auf der HD vorgefundene Bytefolge wende ich jetzt den "richtigen" Schlüssel an. In diesem Fall ein supersimpler Algorithmus, nämlich billigstes bitweises X-OR. So simpel das als Verfahren auch erscheint - da der dazugehörige Schlüssel in der Länge identisch und völlig zufällig im Inhalt ist, ist diese primitive "Verschlüsselung" definitiv unknackbar - ein solches "One Time Pad" ist milliardenfach sicherer als ein FDE-System je sein kann. (Unglaublich, aber wahr...)

Der "richtige" Schlüssel lautet:

0x...
  58 34 64 33  6A 6E 6F 3D   75 32 F6 64  6D 72 69 74 
  7A 69 6C 67  66 38 37 78   34 62 68 7A  6F 78 6E 33 
  70 5A 46 52  4C BB CD 66   72 75 7A 35  38 37 47 56 
  55 5A 74 72  76 75 A4 35   75 7A 66 6A  68 74 76 66 
  52 5A 4F 76  6F 75 7A 76   74 72 4F 55  7A 72 76 6F 
  76 75 74 2F  36 35 BC 37   34 37 24 76  72 69 75 76 
  67 24 63 68  67 46 67 68   6B 46 6A 66  26 35 36 35 
  36 55 49 46  52 69 2D 76   66 7A 46 6B  74 74 6C 69 
  6F 36 7A 62  39 38 36 38   36 38 39

Probiers ruhig selbst, aber heraus kommt folgender Klartext:

Heute nachmittag gehe ich mit Gabi noch ein 
leckeres Eis bei Paolo essen, kommst du auch mit?
Ruf mich einfach bis um halb vier an, Gerd.

So weit, so gut.
Aber nun stehst du als Angeklagter bei Richter Unhold (Freisler reloaded) vor dem Kadi und der will vom hinzugezogenen Sachverständigen (der in der Realität der Justiz nur selten wirklich Sachverstand hat) gerne wissen, was er denn auf deiner beschlagnahmten HD denn bei der forensischen Untersuchung alles vorgefunden habe.
Dieser gibt nun zu Protokoll -und beweise du ihm doch erst mal das Gegenteil- dass er nur folgenden Schlüssel verwenden musste, um dein Crypt-System erfolgreich zu knacken:

0x...
  51 3D 5A 26  66 2A 60 7C   54 35 F6 6F  7C 26 5C 76 
  3F 7C 66 67  71 38 08 7E   32 26 60 67  6F 39 09 0B 
  73 58 13 46  42 F8 F6 15   63 7D 75 61  12 13 4D 51 
  5B 51 6D 65  60 37 92 7C   4E 3F 6D 63  68 33 43 69 
  59 57 4D 3B  68 74 7C 70   72 7E 2B 57  79 7B 74 3C 
  49 27 79 3F  71 27 A4 35   2E 7E 27 7A  26 05 1C 4C 
  73 37 28 60  62 55 69 2D   7C 4B 24 42  32 3B 33 66 
  30 55 59 0E  07 50 7F 7F   6B 77 48 2A  22 5C 65 77 
  2E 3F 34 00  78 0F 20 3E   37 64 39

Klar, sein Knackversuch war auch damit zu 100% "erfolgreich". Ohne hinreichend begründbaren Zweifel hattest du demnach ganz eindeutig folgendes auf der Platte:

AlKaida Bombe Teerohr Vendetta Yakuza SStaat Hodenkrebs Heiligendammbruch Dildo Kriegsmarine Schaukelpferd Bummsdich Tralala Allah Napster

Wie gesagt - beweise doch mal das Gegenteil, da bin ich gespannt?

Tja, und jetzt kommst du: Hat dir die "plausible deniability" nun genutzt oder hast du dir damit nur selbst ordentlich ans Bein gepisst?

Fakt ist:
Wenn es für dich wirklich einen guten Grund gäbe, solche Verfahren aus Angst vor staatlicher Willkür einzusetzen, helfen sie dir nicht im geringsten. Ganz im Gegenteil, du zerstörst damit nur die eigene Glaubwürdigkeit und lieferst dich der totalen Willkür erst so richtig ans Messer.
Und wenn du davor keine Angst haben musst - wozu brauchst du das denn dann überhaupt?
Stellst du dir solche grundlegenden Fragen eigentlich, bevor du deine Daten dem allgegenwärtigen, grossen Bugmonster als Leckerbissen zum Frass vorwirfst?

 

[SilentCry]

Was hilft dir denn in dem von dir gemutmassten Super-kontroll-terror-repressions-Staat ein Verbergen deiner Daten, wenn man dir mühelos den Besitz von willkürlich gewählten, frei erfundenen Daten jederzeit absolut glaubwürdig unterstellen kann?

Nichts. Aber meine Daten haben sie trotzdem nicht. Ich habe nie behauptet, Full HDD Encryption würde gegen Unterstellung schützen. Den Aufwand bräuchten sie ja gar nicht, sie nehmen einfach ein HDD-Image aus der GeStaSiPo-Kammer, clonen ein System mit KP, Bombenplänen und Anschlagsdialogen AUF meinen Rechner und geben ihn dann dem Richter.

Oder sie schiessen mir gleich in den Kopf, ist mir auch wurscht. Shal kek nem ron.

Wichtig ist für mich: Niemand kommt an meine Echtdaten. Punkt.

 

[lngo]

*push*

Um wiederbelebe den Thread, er führt nämlich genau in die Richtung, in die ich möchte:

- eine vernünftige Verschlüsselung meiner Benutzerdaten (Full-Disk-Encryption ist für mich nicht nötig).
- Möglichst komfortabel. Soll heißen, dass sich der Installationsaufwand letztendlich irgendwo zwischen FileFault und Terminalarbeiten "für Fortgeschrittene" bewegen soll. Die Benutzung soll den Aufwand "Passwort eingeben nicht übersteigen, ebenso soll die Bootzeit nicht explodieren
- Für einige möglicherweise unverständlich: ein Backup im Klartext. My Home Is My Castle, und das halte ich für sicher /genug/.

Vorgestellt habe ich mir eine Verschlüsselung des Userdir mit Truecrypt, da mitwachsend und somit schneller einzurichten, mit dem Festplattendienstprogramm.
Das Passwort müsste vermutlich sehr früh eingegeben werden. Ich lese mich gerade in launchd/launchctl ein, weiss da jemand was genaueres?
Träumen tu ich natürlich auch noch: SL zum Sichern der entschlüsselt gemounteten Klardaten zu prügeln.

grüße
lngo

 

[waschbär123]

Ich frage jetzt mal so in die Runde:

Warum kein Image mit dem FDP und in dieses PW gesichertes Image all eure Daten rein hauen, die eben geschützt sein sollen. Geht das nicht? Reicht dort die Verschlüsselung nicht aus? (Natürlich nicht wenn ich mein PW im SB sichere ^^)

Für System interna wie Mails, iCal, Adressbuch usw... könnte man mit simplen Symlinks arbeiten, die in das Image verweisen.

Gruß

 

[SilentCry]

Also, um das Userverzeichnis mit TrueCrypt zu verschlüsseln gibt es eine Anleitung:
http://veltrus.de/blog/2009/10/25/a...chnis-von-mac-os-mit-truecrypt-verschlusseln/

Transparent (FullDisk, Hardwareencryption) geht es so: http://www.apfeltalk.de/forum/p2710578.html

Edit: Ich möchte im Zusammenhang mit SW-Verschlüsselung allerdings immer gerne das Thema FROZEN RAM (oder auch Cold Boot-Attacke) genannt wissen.
http://www.apfeltalk.de/forum/sicherheits-gau-spion-t129159.html

 

[hazen]

Das hat nichts mit "blöde" zu tun.
Sichere FDE ohne entsprechende Hardwareunterstützung ist unmöglich.
Solange BIOS und der Controller der HD das nicht direkt unterstützen (und zwar nativ im ROM), ist das alles nur ein Schildbürgerstreich.
Diese Kröte hat auch Microsoft beim Vista "BitLocker"-Flop schon schlucken müssen. Und die haben sich wirklich reingehängt.

Würde das aus Intresse gerne noch mal aufwärmen. Kann mir jemand erklären, warum das ohne Hardwareunterstützung nicht sicher ist? Zumindest wenn der Rechner ausgeschaltet irgendwo rumsteht, kann doch wohl niemand an die Daten ran, oder?

 

[Mitglied 129448]

Ich äussere jetzt mal eine Vermutung, daher schlagt mich nicht gleich von allen Seiten wenn ich dmait daneben liege!

Ich glaube das hat damit zu tun das der Speicherort des zur Entschlüsselung benötigten Schlüssel an sich, bzw. die Verfahren zum Ver- und Entschlüsseln eben nicht direkt als Anwendung auf Ebene des Betriebssystems stattfinden, sondern eben hardwaremässig auf einem entsprechenden Controller. So kann der Datenträger eben nur in Kombination mit dem entsprechenden Controller verwendet werden, während eine per Software verschlüsselte HD ja z.B. in einen anderen Rechner eingebaut werden kann und dort der Versuch unternommen werden kann diese zu entschlüsseln. Generell sind "Angriffe" auf Hardware (also z.B. ein Contoller) immer schwieriger als auf eine Software.

Lasse mir das aber gerne auch mal genauer von jemandem erläutern der sich da wirklich auskennt. Interessantes Thema!