File Vault Sicherheit

[MAC Gyver]

Hi

Ich mache mir etwas gedanken um die Sicherheit von FileVault2. Laut Apple kommt dabei 128Bit AES zum Einsatz-was zwar nicht State of the Art ist jedoch wenn vernünftig implementiert und nicht durch schlechtes Passwort zu unterwandert ausreichend sicher sein müsste.

Nun verbietet die Rechtssprechung in manchen Ländern jedoch den Einsatz von starker Verschlüsselung (zb Frankreich) bzw schreibt Möglichkeiten vor den Schutz auszuhebeln.
Nun Frage ich mich was Apple in dem Punkt tut-gibt es eigene Versionen für den Französischen Raum in denen FileVault nicht implementiert ist? Oder lässt sich FileVault generell einfach aushebeln?

mfg
Alex

 

[Zitlo]

Ich frage mich manchmal auch ob es in FV2 eine Backdoor gibt, ich mein das is ja auch nich weit weg, gabs sowas nicht mal sogar bei der offiziellen PGPversion?

 

[MACombat]

Ich mache mir etwas gedanken um die Sicherheit von FileVault2. Laut Apple kommt dabei 128Bit AES zum Einsatz-was zwar nicht State of the Art ist jedoch wenn vernünftig implementiert und nicht durch schlechtes Passwort zu unterwandert ausreichend sicher sein müsste.

Warum sollte AES 128 nicht state of the art sein? Die Schlüsselimplementierung ist sogar besser als die unter AES 256. Daher ziehen einige AES 128 immer noch AES 256 vor, auch wenn dies eher eine akademische Diskussion ist, AES 256 hat dann andere Vorteile. Unknackbar ist bisher und auf längere Sicht beides, ein, wie du sagst, sicheres Kennwort vorausgesetzt.

Nun verbietet die Rechtssprechung in manchen Ländern jedoch den Einsatz von starker Verschlüsselung (zb Frankreich) bzw schreibt Möglichkeiten vor den Schutz auszuhebeln.

In Deutschland ist dies nicht der Fall, in den USA wird von der NSA AES eingesetzt, in Großbritannien kann man zur Herausgabe des Schlüssels angehalten werden, was in Deutschland gegen elementares Recht verstoßen würde. Die Situation in Frankreich kenne ich nicht.

Nun Frage ich mich was Apple in dem Punkt tut-gibt es eigene Versionen für den Französischen Raum in denen FileVault nicht implementiert ist? Oder lässt sich FileVault generell einfach aushebeln?

Nach allem, was bekannt ist, lässt sich Filevault nicht aushebeln und wurde gerade unter der Prämisse entwickelt, sicher zu sein, gerade was die Implemention des Algorithmus angeht, wenn auch hier ein Hauptkennwort erzeugt wird, den man aber schon freiwillig zu Apple schicken muss, wobei dieser dann ebenfalls dort nur verschlüsselt durch die angegebenen Antwortfragen vorliegen soll. Wer hier Zweifel hat, sendet diesen Schlüssel eben nicht weiter.

 

[MACombat]

Ich frage mich manchmal auch ob es in FV2 eine Backdoor gibt, ich mein das is ja auch nich weit weg, gabs sowas nicht mal sogar bei der offiziellen PGPversion?

Diese unbewiesenen Behauptungen und daher zuallererst Mythen über Backdoors scheinen hier ihre Wurzeln zu haben:

In 1991, Senate Bill 266 included a non-binding resolution, which if it had become real law, would have forced manufacturers of secure communications equipment to insert special "trap doors" in their products, so that the government could read anyone's encrypted messages. Before that measure was defeated, I wrote and released Pretty Good Privacy. I did it because I wanted cryptography to be made available to the American public before it became illegal to use it. I gave it away for free so that it would achieve wide dispersal, to inoculate the body politic. Quelle

Mit AES vernünftig verschlüsselte Informationen kann niemand lesen, auch die NSA nicht, die setzt AES selbst ein. Für andere Behauptungen gibt es keine Grundlage, daher ziehe ich diese auch nicht in Erwägung.

Mehr auch hier:

No Back Doors.

 

[MACombat]

Hier noch eine nette Antwort vom Entwickler:

"Look, if you really feel the need to believe in conspiracy theories, here's an even better one: The government actually started these nasty rumors of back doors in PGP, because in fact they don't know how to break it. What better way to scare people away from using it? And you played right into their hands by falling for their clever rumors."

 

[Rupp]

Da FileVault 2 auf XTS-AES basiert ist der Schlüssel 256bit lang. Er wird dann in 2 Schlüssel aufgeteilt und zweimal mit 128bit verschlüsselt.
Abgesehen von dieser (in einigen Kreisen als Fehlimplementation betrachtete) Tatsache, kann man an FileVault 2 sicherheitstechnisch nur kritisieren, dass das Anmeldepasswort = dem FileVault Passwort ist.

Das ist die einzige „Sicherheitslücke“.

 

[MACombat]

Eben, hier und da gibt es sicher verschiedene Ansichten, wie es hätte gelöst werden können, aber alles in allem ist Filevault 2 ein großer Schritt nach vorne und nicht nur sicher, sondern auch schnell. Kein Vergleich zu Filevault 1. Für mich, neben dem Sandbox-Prinzip und anderen Sicherheitsmaßnahmen, der Grund überhaupt, Lion einsetzen zu wollen, zumal verschlüsselte TM Backups endlich bequem zu bewerkstelligen sind.

Natürlich könnte man Filevault 2 noch aufbohren; dass die effektiven Schlüssellängen "nur" 128 bit betragen, sehe ich aber auch nicht als Problem.

 

[MAC Gyver]

hi
im gegenteil zu filevault 1 ist fv2 erst vernünftig verwendbar. und zwar komplett ohne einbußen. ich merke weder bei der geschwindigkeit noch bei der allgemeinen benutzbarkeit des systems irgendwelche unterschiede-einzig die passworteingabe gleich zu beginn verrät dass filevault aktiv ist.
mich hat nur interessiert wie apple mit den rechtlichen beschränkungen umgeht.

mfg
alex

 

[pe ter]

Vielleicht müssen die französischen Kunden ja ihr Passwort an Apple schicken. Dann wäre auch das gelöst. Vielleicht kommt ja der Hinweis, dass sie es müssen, ansonsten ist es illegal und jeder Kunde darf dann selbst entscheiden. Das ist aber reine Spekulation.

Gruß, Peter

 

[MACombat]

Vielleicht müssen die französischen Kunden ja ihr Passwort an Apple schicken. Dann wäre auch das gelöst. Vielleicht kommt ja der Hinweis, dass sie es müssen, ansonsten ist es illegal und jeder Kunde darf dann selbst entscheiden. Das ist aber reine Spekulation.

Wird das Passwort an Apple geschickt, kommt Apple selbst aber auch nicht an dieses Passwort, denn meines Wissens wird das Passwort mittels der Fragen und Antworten verschlüsselt auf den Servern abgespeichert und ist ohne die Antworten auf die gestellten Fragen nicht rekonstruierbar.

Apple selbst sagt hierzu in seinen Support-Dokumenten:

"Der Schlüssel, den Sie über Apple speichern, wird anhand der von Ihnen gegebenen Antworten verschlüsselt, bevor er an Apple gesendet wird. Bitte achten Sie darauf, Antworten auszuwählen, an deren Schreibweise Sie sich genau erinnern, falls Sie den Wiederherstellungsschlüssel irgendwann von Apple abrufen müssen.

 

[David X]

Das entsprechende Gesetz ist in Frankreich schon 1996 wieder gekippt worden, nachdem ein Journalist versucht hat, eine Behörde aufzutreiben, bei der er den Schlüssel hinterlegen kann - es gelang ihm nicht, da sich keine Behörde zuständig fühlte. Nachdem er das dann veröffentlichte, wurde das Gesetz schnellstens wieder entsorgt…

 

[MACombat]

Danke, erinnert damit an Senate Bill 266, letztere wurde nie Gesetz, gibt aber bis heute Raum für Vermutungen. Manches verselbstständigt sich eben im Laufe der Zeit.

 

[SirLockholmes]

Nun verbietet die Rechtssprechung in manchen Ländern jedoch den Einsatz von starker Verschlüsselung (zb Frankreich) bzw schreibt Möglichkeiten vor den Schutz auszuhebeln.

mfg
Alex

also das Gesetz ist aber eigtl schon vom Tisch, zudem ging es dabei auch im Import und Export, kann mich noch gut dran erinnern denn selbst SSH war davon betroffen ...

 

[Spacemarine]

Ich glaube noch einen bösen Bug in Filevault 2 gefunden zu haben. Und zwar wird beim Hybrid-Sleep nach längerer Zeit das RAM-Image auf der Platte benutzt um wieder aufzuwachen, da der RAM gelöscht wurde. Hierbei ist jedoch kein Entschlüsselungspasswort notwendig. So habe ich das ganze reproduzierbar gemacht, um es auszutesten:

Ich habe den Deep-Sleep mit sudo pmset -a hibernatemode 1 erzwungen. Das Aufwachen hat dadurch auch deutlich länger gedauert, außerdem wurde immer die Datei /var/sm/sleepimage erzeugt, der Deep-Sleep scheint also erfolgreich durchgeführt zu werden.

Ich konnte mich jedoch danach mit meinem Benutzer-Passwort anmelden, das ein anderes als das Passwort zum Entschlüsseln ist! Mein Benutzer-Passwort kann beim Booten NICHT zum entschlüsseln der Platte verwendet werden.

Dies lässt den einzigen Schluss zu, nämlich dass beim Deep-Sleep der Ram-Inhalt unverschlüsselt auf die Platte geschrieben wird.

 

[xentric]

Dies lässt den einzigen Schluss zu, nämlich dass beim Deep-Sleep der Ram-Inhalt unverschlüsselt auf die Platte geschrieben wird.

Wie kommst du zu der Theorie?! Natürlich ist /var verschlüsselt, weil / verschlüsselt ist. Der einzig sinnvolle Schluss ist, dass beim Schlafen des Systems die Festplatte nicht ausgehangen wird, und somit kein erneutes Abfragen für den Unlock erscheint.
So oder so. Entweder liegt das Sleep Image im /var, und es ist folglich unmöglich die Platte auszuhängen (wenn man nur ein Suspend-to-Disk macht), oder es liegt unverschlüsselt in der Recovery Partition, was imho eine größere Sicherheitseinschräung wäre.

 

[mikrowellenpiet]

Und zwar wird beim Hybrid-Sleep nach längerer Zeit der Ram-Inhalt auf die Platte geschrieben, ...

Er wird direkt auf die Festplatte geschrieben nicht erst nach längerer Zeit.

 

[Spacemarine]

Er wird direkt auf die Festplatte geschrieben nicht erst nach längerer Zeit.

Du hast recht, es wird sofort geschrieben, aber erst nach längerer Zeit benutzt. Vorher wird der RAM-Inhalt verwendet um aufzuwachen. Macht für unsere Belange keinen Unterschied, aber ich habe trotzdem mal in meinem Post korrigiert.

 

[Spacemarine]

Wie kommst du zu der Theorie?!

Aus meinen Beobachtungen habe ich das geschlossen. Falls du einen anderen Schluss hast, würde ich das gerne hören!

Natürlich ist /var verschlüsselt, weil / verschlüsselt ist.

Nicht zwingend. Da Filevault 2 blockweise verschlüsselt, könnte man z.B. im unverschlüsselten Header der Partition Blocknummern angeben, die nicht verschlüsselt werden sollen. Damit könnte man mitten in einer verschlüsselten Partition eine unverschlüsselte Datei ablegen.

Der einzig sinnvolle Schluss ist, dass beim Schlafen des Systems die Festplatte nicht ausgehangen wird, und somit kein erneutes Abfragen für den Unlock erscheint.

Das verstehe ich nicht genau. Was meinst du mit aushängen? Kannst du ein bisschen technischer erklären, was beim "Aushängen" beim Schlafen genau passiert?

 

[xentric]

Aus meinen Beobachtungen habe ich das geschlossen. Falls du einen anderen Schluss hast, würde ich das gerne hören!

Hab ich doch geschrieben.

Nicht zwingend. Da Filevault 2 blockweise verschlüsselt, könnte man z.B. im unverschlüsselten Header der Partition Blocknummern angeben, die nicht verschlüsselt werden sollen. Damit könnte man mitten in einer verschlüsselten Partition eine unverschlüsselte Datei ablegen.

Klar. Wie soll das sonst umgesetzt sein, wenn nicht blockweise. Dann erzähl mir mal, wie du das dem Filesystem beibringen willst, wo der was zu schreiben hat. Ist sicherlich machbar, aber halte ich für eine untreffende Theorie. Zumal nirgendwo in irgendeiner API/Source was davon zu lesen ist, und das schon ziemliches Versagen wär seitens Apple sowas in ein Dateisystem zu implementieren, und dann mit Sichertheit zu preisen. Du kannst ja gerne mal deine Sleep image tracken und schauen auf welchen Blöcken es liegt. Immerhin ist das _deine_ Theorie, und ich verspreche Dir, die werden nicht gleich sein.

Dein Partitionskonzept ist quasi wie die Recovery Partition, was ich schon angesprochen habe. Dann würde man aber die Blöcke sehen in einer anderen Partition, und die Partition wäre sicherlich nicht in /var/.. weil da nichts eingehangen ist. Geh sie selbst durch, da sind keine Lücken

$ diskutil list 
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:          Apple_CoreStorage                         240.9 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data Vista                   78.3 GB    disk0s4
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Mac OS X               *240.6 GB   disk1
 xen@ radeon ~ 508


Last login: Fri Nov  4 16:01:23 on ttys000
 xen@ radeon ~ 500
 $ man umount 
 xen@ radeon ~ 501
 $ diskutil cs listCoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group B3DCF837-35A9-46D4-B0C4-9898E8DC86E5
    =========================================================
    Name:         Mac OS X
    Sequence:     1
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume 29A1D4E1-57F2-4E4C-96A9-886333DF7101
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     240942931968 B (240.9 GB)
    |
    +-> Logical Volume Family 50BAE5B3-ED48-4A5E-B483-A8B4DAB2C99B
        ----------------------------------------------------------
        Sequence:               10
        Encryption Status:      Unlocked
        Encryption Type:        AES-XTS
        Encryption Context:     Present
        Conversion Status:      Complete
        Has Encrypted Extents:  Yes
        Conversion Direction:   -none-
        |
        +-> Logical Volume 057EE502-86E8-431F-B6D8-B779457CF1CC
            ---------------------------------------------------
            Disk:               disk1
            Status:             Online
            Sequence:           4
            Size (Total):       240624160768 B (240.6 GB)
            Size (Converted):   -none-
            Revertible:         Yes (unlock and decryption required)
            LV Name:            Mac OS X
            Volume Name:        Mac OS X
            Content Hint:       Apple_HFS
 xen@ radeon ~ 502
 $

Das verstehe ich nicht genau. Was meinst du mit aushängen? Kannst du ein bisschen technischer erklären, was beim "Aushängen" beim Schlafen genau passiert?

Technischer? Lies selbst, man umount. Ich hab das extra nicht technisch gemacht, weil die meisten mit den unix unterbau hier nix anfangen können. Nur immer das hervorholen, wenns im Einklang ist mit dem marketing Gerede über Viren.

 

[Spacemarine]

Technischer? Lies selbst, man umount.

Ich weiß was mounten und unmounten ist, da ich seit 10 Jahren mit Linux arbeite. Aber das meine ich gar nicht. Sondern wie das unmounten mit dem Schlafen zusammenhängt. Was da in welcher Reihenfolge passiert. Aber lassen wir das, ich glaube nämlich auch nicht dass die Platte ausgehangen wird, zumindest sehe ich nicht warum das unbedingt notwendig sein sollte.

Gehen wir nochmal auf deine Aussage weiter oben ein:

Der einzig sinnvolle Schluss ist, dass beim Schlafen des Systems die Festplatte nicht ausgehangen wird, und somit kein erneutes Abfragen für den Unlock erscheint.

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?