File Vault Sicherheit

Ok, wie erklärst du, dass ohne Eingabe eines Entschlüsselungspasswortes aufgewacht werden kann, obwohl keine Daten auf dem RAM verwendet werden? Diese Thematik hat doch eigentlich nichts damit zu tun, dass nicht ausgehangen wird?

Ich hab keine Ahnung wie genau das FileVault funktioniert. Nichts, weils mich nicht interessiert, eher, dass es keine Angaben dazu gibt. Ich fand das Prinzip schon bescheuert, dass es User am Computer gibt, die NICHT die Erlaubnis haben beim booten FileVault zu öffnen. Das widerstrebt eigentlich jeglichen Sicherheitsgedanken. Wieso hat sojemand dann ein Benutzerkonto für das System.

Ich meinte halt mit aushängen schließen der Verschlüsslung. Sorry, falls das bei Dir zur Verwirrung geführt hat. Es kann doch nur so sein, dass das Logische Volumen noch offen ist, wenn der Computer in den Suspend geht, anders kann er ja nicht auf die Festplatte schreiben. Sonst, wie du richtig sagst, brauch man entweder Daten aus den Ram, oder, wie ich geschrieben hab, Daten aus einer Unverschlüsselten Parititon, wie die Recovery Partition. Damit wird ja auch gebootet, bis der Kernel so weit ist, dass Dateisystem zu öffnen.

Da du aber sagst, dass das Sleepimage immer noch in /var/ herumliegt, da aber nichts anderes eingehangen ist, und man ja auch einfach die Recovery Partition einhängen kann (die EFI) auch, da kein Image ist, wird das wohl so sein. Ich fände das auch weniger sicherheitsbedenklich als ein Sleep Image auf einer unverschlüsselten Partition.

Ich finde meine Theorie schlüssiger, immerhin musst du beweise bringen, dass es unverschlüsselt irgendwo herumliegt ;). Du bist damit angefangen, und bis auch wil spekuliert hast du auch noch nichts, ..
 
Tja, bis zur Inode von meinem Sleepimage komm ich noch. N hfs_debug scheints nicht zu geben..
 
Ich finde meine Theorie schlüssiger, immerhin musst du beweise bringen, dass es unverschlüsselt irgendwo herumliegt ;)

Möglicherweise liegt nicht das gesamte Image unverschlüsselt rum, vielleicht wird auch einfach nur der Masterkey irgendwo unverschlüsselt gespeichert. Während der Rechner läuft, liegt der Masterkey im Ram. Wenn wir nun ohne Ram aufwachen wollen und dabei kein Entschlüsselungspasswort eingeben, muss der Masterkey irgendwo unverschlüsselt in einem nicht-flüchtigen Speicher angelegt worden sein. Anders kann ich es mir nicht erklären. Du etwa?
 
Hi

Ohne genau zu wissen wie es umgesetzt wird muss ich Spacemarine recht geben-der Rechner braucht einen Key um die Platte zu entschlüsseln. Wenn ich ein Verschlüsseltes Volume öffne dann wird üblicherweise der Verschlüsselte Key mit meinem Passwort enschlüsselt und im Arbeitsspeicher oder CPU-Cache abgelegt. Mit diesem Schlüssel kann dann der Festplatteninhalt enschlüsselt werden. Wenn der Rechner aus irgendwelchen Gründen den Inhalt von RAM und Cache verliert und die Platte trotzdem ohne Passworteingabe entschlüsselt werden kann dann lässt das nur den Schluss zu dass der Schlüssel auf einem nicht flüchtigen Medium gespeichert wird - und ausser der Festplatte hat er nicht viel zur Verfügung.

4 Möglichkeiten sehe ich:
1.) Der Dump des Arbeitsspeichers wird in einem unverschlüsselten Teil der Festplatte abgelegt == SICHERHEITSTECHNISCHER WAHNSINN!!!!!
2.) Der Dump des Arebitsspeichers wird in einem verschlüsselten Teil der Festplatte abgelegt, der Key irgendwo unverschlüsselt == SICHERHEITSTECHNISCHER WAHNSINN!!!!!
3.) Der Dump des Arebitsspeichers wird in einem verschlüsselten Teil der Festplatte abgelegt und ein Benutzerpasswort eines Benutzers der zur Entschlüsselung berechtigt ist wir benötigt == Sicherheitstechnisch ok-aber man kann sich als unpriviliegierter Nutzer aussperren wenn der Rechner schlafen geht. Diese Lösung gefällt mir am besten scheint aber durch die Beobachtungen von Spacemarine wiederlegt zu sein.
4.)Der Dump des Arbeitsspeichers wird in einem verschlüsselten Teil der Festplatte abgelegt, der Key mit dem Benutzerpasswort des angemeldeten Users verschlüsselt == Sicherheitstechnisch bedenklich da der Nutzer Privilegien bekommt die er eigentlich nicht haben sollte-ausserdem müsste das Passwort des Users im Klartext bekannt sein

Habe ich einen Denkfehler begangen?

mfg
Alex
 
Ich fand das Prinzip schon bescheuert, dass es User am Computer gibt, die NICHT die Erlaubnis haben beim booten FileVault zu öffnen. Das widerstrebt eigentlich jeglichen Sicherheitsgedanken. Wieso hat sojemand dann ein Benutzerkonto für das System.
Dann mach einen besseren Vorschlag, wie unter Einhaltung jeglicher normaler Sicherheitsrichtlinien, bei der Ersteinrichtung von FileVault2 verfahren werden soll, wenn es bereits mehr als einen Benutzer auf dem System gibt. Jeder neu angelegter Benutzer, der nach der Verschlüsselung angelegt wird, hat das Recht die Platte zu entschlüsseln.

Ansonsten gilt generell für verschlüsselte Systeme: Willst Du den vollen Schutz, schalt den Rechner komplett aus. ;)
 
  • Gefällt mir
Reaktionen: Rupp
Ansonsten gilt generell für verschlüsselte Systeme: Willst Du den vollen Schutz, schalt den Rechner komplett aus. ;)

das mag ja stimmen aber hier kann der gleiche schutz auch im standby erreicht werden wenn der ram dump auch verschlüsselt wird und beim aufwachen das passwort abgefragt wird (welches meißtens gleich dem benutzerpasswort ist). damit ist es keine einschränkung in der benutzung und beinträchtigt trotzdem nicht die sicherheit.

mfg
 
Unter Lion ist secure virtual memory (svm) standardmässig aktiviert und das man für pmset gibt nur 3 empfohlene Werte aus 0, 3, und 25:
0 - suspend to RAM
3 - suspend to RAM and disk
25 - suspend to disk

Solange hier jetzt niemand das Gegenteil beweist, gehe ich davon aus, dass der RAM per svm verschlüsselt gespeichert wird. Und warum jemand den in Lion undokumentierten hibernatemode 1 anstatt 25 benutzt, verstehe ich nicht. Früher als man den svm noch extra aktivieren musste, war übrigens der Befehl sudo pmset -a hibernatemode 5 das Mittel der Wahl, um den RAM verschlüsselt auf der HD zu speichern (und 7, falls man das sichere Pendant zu 3 haben wollte). Da beide Modi noch übers Terminal aktivierbar sind, können ganz skeptische dann ja einfach diese Argumente benutzen.

Wer aber wirklich sicher gehen will, schaltet den Mac aus. Ich bezweifle, dass ein Bootvorgang bei aktuellen MacBooks mit teilweise bis zu 8GB RAM wesentlichen langsamer ist, als ein Wake-up mit einem RAM-Restore von der Disk (mit 'ner SSD vielleicht, aber selbst da dürfte der Vorteil marginal sein). Und je mehr Programme von Resume und Autosave profitieren, desto sinnloser wird Safe Sleep generell.

Edit: Nachdem ich eine Quelle gefunden habe, die behauptet, dass die Modi 5 und 7 unverschlüsselt speichern, bleibt es bei der Empfehlung nur 0, 3 und 25 mit Lion zu verwenden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Rupp
Solange hier jetzt niemand das Gegenteil beweist, gehe ich davon aus, dass der RAM per svm verschlüsselt gespeichert wird.

Und wo wird in diesem Fall der Schlüssel zum Entschlüsseln beim Aufwachen gespeichert?

Ich habe gerade sudo pmset -a hibernatemode 25 ausprobiert. Damit kann ich ebenfalls ohne Eingabe eines Entschlüsselungspasswortes aufwachen.
 
Ich komme mir so langsam vor wie ein Papagei: Willst Du vollen Schutz, schalte den Mac aus!

Auch beim Deep Sleep findet nie ein unmount der Bootpartition statt, d.h. dass das System noch immer vollen Zugriff auf die Daten hat, da ja die Entschlüsselung innerhalb des Systems nie aufgehoben war. Also wird das (per svm) verschlüsselte RAM-Image nach beenden des Deep Sleep wieder in den RAM geladen und weiter geht's. Wenn Du das nicht willst, schalte den Mac aus!

Jede andere Implementierung des Deep Sleep läuft auf ein unmount der Bootpartition hinaus und dann bist Du wieder beim Neustart des Systems…
 
Dass ein boot nicht viel länger dauert als ein resume from disk mag ja stimmen-aber der resume from disk kommt nur vor wenn der Akku leer geworden ist. Ansonsten ist es ein resume from ram und der ist deutlich schneller.

evtl währe das mal eine Anfrage an den Apple Support wert?

mfg
 
Suspend to Disk ist als Feature von Apple doch eh eingestampft worden. Es gibt doch nun das Tolle „Resume“-Feature ;) . In diesem Zusammenhang macht es, gerade auch wenn man FV2 nutzt, sowieso Sinn den Rechner komplett auszuschalten.

Wie David X schon gesagt hat ist es bei soviel RAM (6GB+) unerheblich ob man neu bootet oder den Rechner aus dem Suspend to Disk aufwachen lässt.

Bei Rechnern mit SSD ist ein Suspend to Disk zudem noch ein Flash-Zellen-Killer (mind. einmal am Tag 8 GB schreiben :eek: ).
 
Dann mach einen besseren Vorschlag, wie unter Einhaltung jeglicher normaler Sicherheitsrichtlinien, bei der Ersteinrichtung von FileVault2 verfahren werden soll, wenn es bereits mehr als einen Benutzer auf dem System gibt. Jeder neu angelegter Benutzer, der nach der Verschlüsselung angelegt wird, hat das Recht die Platte zu entschlüsseln.

Alle oder keiner. Hab ich doch gesagt, wo ist das Problem? Wenn nachträglich auch jeder das recht hat. Wieso sollte ich nen Nutzer an meinen Computer lassen, der den Computer nicht starten kann. Entweder ist er vertrauenswürdig, oder eben nicht.
 
Beispiel: Ein Lion-System (Upgrade von Snow Leopard), 3 existierende Benutzer, FileVault wird vom Admin aktiviert. Wie können jetzt alle Benutzer den Rechner entsperren? Richtig - alle Benutzer müssen erst ihr Passwort eingeben. Kennt der Admin das? Normalerweise ja wohl nicht. Wie können also die verbleibenden 2 Nutzer den Rechner entsperren? Richtig - gar nicht. Ihre Passwörter müssen also nachträglich in die Entsperr-Tabelle auf der Recovery HD eingetragen werden. Bis dies geschieht, können sie nicht entschlüsseln. Liegt also am Admin die Benutzer einzubinden. Macht er das nicht - Pech gehabt…

Bei mit Lion ausgelieferten Systemen besteht das Problem nicht. Admin verschlüsselt die Platte, jeder neu hinzugefügte Benutzer erhält automatisch das Recht, die Platte zu entschlüsseln - so wie Du das haben willst…
 
ich finde sogar dass es durchaus sinn machen kann dass manche benutzer die platte nicht entschlüsseln können. stichwort familienrechner. die kinder sollen ihren eigenen account haben damit sie nix an meinem zerstören können aber desswegen will ich noch lange nicht die sicherheit des systems im schadensfall von deren meißt etwas einfachen wenn überhaupt vorhandenen kennwörtern abhängig machen.

und suspend to ram ist mir als notebookuser extrem wichtig-leider wird dabei auch automatisch ein suspend to disk durchgeführt. darauf könnte ich allerdings gerne verzichten.

mfg
 
und suspend to ram ist mir als notebookuser extrem wichtig-leider wird dabei auch automatisch ein suspend to disk durchgeführt.

Kannst du ganz easy abstellen: sudo pmset -a hibernatemode 0

Dadurch wird allerdings im Standby mehr Strom verbraucht. Bei meinem MBA ca. 10% Akku pro Tag.
 
und suspend to ram ist mir als notebookuser extrem wichtig-leider wird dabei auch automatisch ein suspend to disk durchgeführt. darauf könnte ich allerdings gerne verzichten.

Seit Lion nicht mehr. Seit Lion ist der standard hibernatemode = 0. Also suspend to RAM, ohne suspend to disk.

An meinem Macbook jedenfalls.
 
An David X würde ich nochmal die Frage richten, wie denn das verschlüsselte Ram-Image nach dem Aufwachen entschlüsselt werden soll? Dabei muss der Masterkey zur Entschlüsselung ja zwangsläufig in einem nichtflüchtigen Speicher unverschlüsselt abgelegt worden sein. Bislang wurden hierzu noch keine Erklärungsansätze geliefert.
 
Zurück
Oben Unten