SirLockholmes
Aktives Mitglied
Thread Starter
- Dabei seit
- 22.07.2009
- Beiträge
- 777
- Reaktionspunkte
- 99
Hallo MU,
ich habe mir in irgendeinem Thread mal vorgenommen, Filevault2 unter OSX 10.7 wenn es denn "fertig" ist zu testen und will nun hier kurz meine Erkenntnisse festhalten.
Zu mir, ich arbeite nun seit 1994 im Bereich Network und Information Security und beschäftige mich u.a. mit Crypto-Analyse, Penetration Testing, Hacking und sonstigem über das man im dem Bereich stolpern könnte und denke, ich kann mir bestimmt eine entsprechende Meinung über die Features bilden, auch wenn es nicht wirklich viel zu sagen gibt ...
Review: OSX 10.7 Filevault2
Vorab sollte man wissen: Apple integrierte in OSX 10.7 Filevault2 welches selbst auf eine Verschlüsselung, basierend auf XTS-AES 128 (eigentlich 256 bit, dazu später mehr), für die gesamte Festplatte zurück greift. Eine zusätzliche Verschlüsselung des Home-Verzeichnisses ist für die unterschiedlichen Benutzer des Systems leider nicht möglich. Es lassen sich natürlich weiterhin verschlüsselte Images erzeugen in denen man Daten speichert und diese im Home-Verzeichnis ablegen, aber eine echte "multi-layer security" mit mehreren "Hürden" die es zu bewältigen gibt, gibt es im Vergleich zu anderen am Markt erhältlichen Lösungen leider nicht. Ich zitiere mich an dieser Stelle gerne mal wieder selbst: "Gut gemacht Apple, überlegt und integriert, aber leider mal wieder nicht zu Ende gedacht - wie leider so oft."
XTS selbst, ist in der IT-Security Branche unterschiedlich angesehen, es gibt Gruppen die sagen es sei hervorragend, andere die sagen ausreichend und wiederum andere die der Meinung sind, dass es den Prozess lediglich unnötig verkompliziert da es aufgrund des "multi-keying" keine Steigerung der Sicherheit gibt gegenüber XEX (Xor-Encrypt-Xor). Hintergrund ist hier dass XTS das Schlüsselmaterial, dass für die Verschlüsselung herangezogen wird halbiert bzw teilt und somit mit zwei (2) Schlüsseln mit halber Länge arbeitet - also bei XTS-AES-128 (eigentlich sind dies 256 bit) mit 2 Schlüsseln mit jeweils 128 bit, wo hingegen XEX mit voller Schlüssellänge (in diesem Fall 256 bit) arbeitet. Daher integriert man XTS normal auch so, dass der Benutzer die Schlüssellänge variabel nutzen kann, zB mit 256 (Filevault2) oder 512 bit um eine entsprechend "stärkere" Verschlüsselung zu erreichen, diese Funktion sucht man im OSX 10.7 Lion jedoch vergeblich. D.h. im Klartext, dass unter OSX 10.7 Lion mit XTS AES-128 die effektive Schlüssellänge lediglich 128 bit und nicht 256 bit beträgt. Weitere Details zu XTS lassen sich im IEEE Projekt 1619 nachlesen, das zur Herleitung von XTS führte. Andere Lösungen die ebenfalls auf XTS setzen sind - ohne gewähr auf Vollständigkeit - Truecrypt, Bestcrypt, DMcrypt, Free-OTFE, Diskcryptor, Free- sowie Open-BSD - soviel zum allgemeinen Verständnis.
Kommen wir nun zur integrierten Lösung selbst:
Der "Administrator" hat die Möglichkeit Filevault2 nach der Installation für die im System befindliche Festplatte zu aktivieren - später auch weitere externe oder USB-Sticks. Dieser Prozess ist meiner Einschätzung nach vollkommen unnötig, da man bei der Installation die Festplatte bereits formatieren und die Daten sofort auf ad-hoc verschlüsselten Sektoren ablegen könnte. Ich denke mal Apple hat sich hierbei gedacht, dass dies einen negativen Einfluss auf die Installationszeit haben könnte und es daher unterlassen hat, dieses Feature zu integrieren. Man muss jedoch gestehen, dass dies ein valider Einwand ist. Während die Verschlüsselung - also nach der Installation, Aktivierung von Filevault2 und Reboot (erst nach dem nächsten Start beginnt der Verschlüsselungsprozess) - im Hintergrund läuft, steht das System bereits dem Benutzer zur Nutzung zur Verfügung, dennoch ist ein "sicheres" Ausliefern nach Basisinstallation so nicht möglich. Der Verschlüsselungsprozess selbst kann jedoch durch Log-Out, Sleep Funktion oder auch Herunterfahren des Systems temporär unterbrochen werden und nimmt an der Stelle seine Arbeit wieder auf wo er "pausiert" wurde, ein warten auf Beendigung des Prozesses ist somit nicht notwendig.
Aktiviert der Administrator oder Hauptbenutzer nach der Installation dieses Feature über Systemeinstellungen/Sicherheit/Filevault, wird automatisch ein Recovery-Key erzeugt mit dem es möglich ist, Daten bei Problemen mit dem System an sich wieder herzustellen - soweit die Theorie (konnte ich bisher nicht testen). Dieser Recovery-Key kann entweder notiert und an einer "sicheren" Position abgelegt werden, alternativ bietet Apple auch an, den Recovery-Key für den Benutzer zu speichern. Letzteres benötigt die Vergabe von Antworten auf Sicherheitsfragen, mit denen der Recovery-Key selbst gesichert wird. Die Antworten auf die Sicherheitsfragen agieren, so wie ich es bisher nachvollziehen konnte, in diesem Szenario als Authentisierung gegen sowie als "Seeds" für die Verschlüsselung des Keys (packet-trace und crypto-Analyse bei/nach Übertragung des Recovery-Keys).
Nachdem der Verschlüsselungsprozess abgeschlossen ist - die Zeit ist abhängig vom System an sich, bei mir ca. 8 Stunden auf meinen basiskonfigurierten System (Mail (200.000 Mails), iTunes Library sowie ein paar Applikationen (ca.130GB an echten Daten) siehe Signatur)) - erwartet OSX 10.7 nach Kaltstart des Systems dass sich ein autorisierter Benutzer gegen Filevault2 authentisiert um das System zu starten. Leider hat Apple hier es unterlassen, die Benutzer zu verstecken und es werden letztlich die autorisierten Benutzer zur Auswahl angeboten, anders als man es zB kennt wenn man die Anmeldeoption "Anmeldefenster zeigt an: "Name und Kennwort"" gewohnt ist. Dieses erleichtert es einem potenziellem Angreifer, da er den Benutzernamen nicht zusätzlich erraten muss, sondern lediglich das Passwort - welches zusätzlich die Autorisierung gegen das Benutzeraccount darstellt. Also eine zweigeteilte Überprüfung des Benutzers nach Authentisierung und Autorisierung, einmal gegen die Festplattenverschlüsselung und dann gegen das Benutzeraccount selbst, gibt es nicht - quasi eine - aus meiner Sicht - "schlechtere" Art von Single-SignON.
Bestehen zum Punkt der Einrichtung von Filevault2 bereits weitere Benutzer auf dem System kann der Administrator oder Hauptbenutzer entscheiden ob auch andere Benutzer die Möglichkeit haben, ebenfalls das System entschlüsseln zu können. Erlaubt man es ihnen nicht muss erst umständlich der Hauptbenutzer das System starten und dann per FastUserSwitching der Zugang für anderen Benutzer ermöglicht werden.
Die Beeinträchtigung des Systems selbst bei der Benutzung ist "gefühlt" nicht wirklich hoch, das Starten eines Systems, hier zB mein in der Signatur genanntes MacBook Pro, beträgt nach der Authentisierung gegen Filevault2, Systemstart, automatischer Anmeldung an ein Wireless Netzwerk und manuelles starten von Safari mit www.google.com als Startseite ca. 40 Sekunden (5400rpm HDD).
Also kurz zusammengefasst, aus meiner Sicht ein guter Anfang, aber bei weitem nicht zu Ende gedacht und es gibt sehr viel Spielraum für Verbesserung. Was die Belastung des Systems angeht, konnte ich bisher nichts negatives feststellen, auch nicht bei hoher Speicher und hoher Festplattenaktivität, also zB Speicher nahezu ausgelastet und lesen von zB HD Material 1080p oder gar 4k. Auch das Abspielen und bearbeiten von größeren Logic-Projekten wurde nicht wirklich signifikant beeinträchtigt.
Problematisch bzw Nachbesserung erhoffe ich mir an folgenden Punkten:
- Nicht beeinflussbare Schlüssellänge - zB 512 bit
- Autorisierte Benutzer - ich möchte a) verstecken welche Benutzer das System entschlüsseln können und b) Berechtigungen zuweisen und auch wieder entziehen können - bei SingleUser Systemen bestimmt zu vernachlässigen.
- Authentisierung & Autorisierung - ich möchte kein Single-SignOn, es sollten getrennte Möglichkeiten bestehen, a) die Festplatte entschlüsseln und das System starten zu können und b) der/die Benutzer sich gegen ihr Benutzerprofil authentisieren können.
- Verschlüsselung des Benutzerprofils - der Benutzer sollte die Möglichkeit haben, sein Profil zusätzlich zu verschlüsseln, dies mit einem anderen Schlüssel, damit seine Daten gegenüber anderen Benutzern auf dem System und auch generell zusätzlich geschützt sind.
- "Network-Keys" - es sollte möglich sein, Benutzern innerhalb eines Netzwerks Zugriff zu erlauben oder zu negieren, derzeit verläuft es so, dass sobald eine zB AFP- oder SMB-Session im Benutzerkontext erlaubt ist, dies auch innerhalb des Benutzerkontexts verläuft (Usermode). Es kann somit jeder Benutzer, dem man erlaubt über das Netzwerk auf Daten zu zugreifen auf diese Daten unverschlüsselt zugreifen und diese auch unverschlüsselt zB lokal auf seinem Rechner ablegen.
Träume und Wünsche:
- Unterstützung von zusätzlichen Medien zur Authentisierung, zB USB-Stick mit einem De-cryption- oder Authentication-Key der an den Benutzer gebunden ist (Smartcard oder Fingerprint lasse ich mal aufgrund fehlender Hardware außen vor).
- "Key-Sharing" - für geteilte Verzeichnisse oder Dateien selbst auf zB OSX 10.7 Server sollte man unterschiedlichen Benutzern mit unterschiedlichen Keys Zugriff auf Daten erlauben können - ich weiss es war bestimmt nicht die Intention von Apple aber man darf doch auch noch Wünsche äussern oder?
Soweit erstmal der "quick review", den ich vielleicht noch hier und da je nach Erfahrungen ergänzen werde.
Hoffe für einige hilfreich ...
SirLockholmes
ich habe mir in irgendeinem Thread mal vorgenommen, Filevault2 unter OSX 10.7 wenn es denn "fertig" ist zu testen und will nun hier kurz meine Erkenntnisse festhalten.
Zu mir, ich arbeite nun seit 1994 im Bereich Network und Information Security und beschäftige mich u.a. mit Crypto-Analyse, Penetration Testing, Hacking und sonstigem über das man im dem Bereich stolpern könnte und denke, ich kann mir bestimmt eine entsprechende Meinung über die Features bilden, auch wenn es nicht wirklich viel zu sagen gibt ...
Review: OSX 10.7 Filevault2
Vorab sollte man wissen: Apple integrierte in OSX 10.7 Filevault2 welches selbst auf eine Verschlüsselung, basierend auf XTS-AES 128 (eigentlich 256 bit, dazu später mehr), für die gesamte Festplatte zurück greift. Eine zusätzliche Verschlüsselung des Home-Verzeichnisses ist für die unterschiedlichen Benutzer des Systems leider nicht möglich. Es lassen sich natürlich weiterhin verschlüsselte Images erzeugen in denen man Daten speichert und diese im Home-Verzeichnis ablegen, aber eine echte "multi-layer security" mit mehreren "Hürden" die es zu bewältigen gibt, gibt es im Vergleich zu anderen am Markt erhältlichen Lösungen leider nicht. Ich zitiere mich an dieser Stelle gerne mal wieder selbst: "Gut gemacht Apple, überlegt und integriert, aber leider mal wieder nicht zu Ende gedacht - wie leider so oft."
XTS selbst, ist in der IT-Security Branche unterschiedlich angesehen, es gibt Gruppen die sagen es sei hervorragend, andere die sagen ausreichend und wiederum andere die der Meinung sind, dass es den Prozess lediglich unnötig verkompliziert da es aufgrund des "multi-keying" keine Steigerung der Sicherheit gibt gegenüber XEX (Xor-Encrypt-Xor). Hintergrund ist hier dass XTS das Schlüsselmaterial, dass für die Verschlüsselung herangezogen wird halbiert bzw teilt und somit mit zwei (2) Schlüsseln mit halber Länge arbeitet - also bei XTS-AES-128 (eigentlich sind dies 256 bit) mit 2 Schlüsseln mit jeweils 128 bit, wo hingegen XEX mit voller Schlüssellänge (in diesem Fall 256 bit) arbeitet. Daher integriert man XTS normal auch so, dass der Benutzer die Schlüssellänge variabel nutzen kann, zB mit 256 (Filevault2) oder 512 bit um eine entsprechend "stärkere" Verschlüsselung zu erreichen, diese Funktion sucht man im OSX 10.7 Lion jedoch vergeblich. D.h. im Klartext, dass unter OSX 10.7 Lion mit XTS AES-128 die effektive Schlüssellänge lediglich 128 bit und nicht 256 bit beträgt. Weitere Details zu XTS lassen sich im IEEE Projekt 1619 nachlesen, das zur Herleitung von XTS führte. Andere Lösungen die ebenfalls auf XTS setzen sind - ohne gewähr auf Vollständigkeit - Truecrypt, Bestcrypt, DMcrypt, Free-OTFE, Diskcryptor, Free- sowie Open-BSD - soviel zum allgemeinen Verständnis.
Kommen wir nun zur integrierten Lösung selbst:
Der "Administrator" hat die Möglichkeit Filevault2 nach der Installation für die im System befindliche Festplatte zu aktivieren - später auch weitere externe oder USB-Sticks. Dieser Prozess ist meiner Einschätzung nach vollkommen unnötig, da man bei der Installation die Festplatte bereits formatieren und die Daten sofort auf ad-hoc verschlüsselten Sektoren ablegen könnte. Ich denke mal Apple hat sich hierbei gedacht, dass dies einen negativen Einfluss auf die Installationszeit haben könnte und es daher unterlassen hat, dieses Feature zu integrieren. Man muss jedoch gestehen, dass dies ein valider Einwand ist. Während die Verschlüsselung - also nach der Installation, Aktivierung von Filevault2 und Reboot (erst nach dem nächsten Start beginnt der Verschlüsselungsprozess) - im Hintergrund läuft, steht das System bereits dem Benutzer zur Nutzung zur Verfügung, dennoch ist ein "sicheres" Ausliefern nach Basisinstallation so nicht möglich. Der Verschlüsselungsprozess selbst kann jedoch durch Log-Out, Sleep Funktion oder auch Herunterfahren des Systems temporär unterbrochen werden und nimmt an der Stelle seine Arbeit wieder auf wo er "pausiert" wurde, ein warten auf Beendigung des Prozesses ist somit nicht notwendig.
Aktiviert der Administrator oder Hauptbenutzer nach der Installation dieses Feature über Systemeinstellungen/Sicherheit/Filevault, wird automatisch ein Recovery-Key erzeugt mit dem es möglich ist, Daten bei Problemen mit dem System an sich wieder herzustellen - soweit die Theorie (konnte ich bisher nicht testen). Dieser Recovery-Key kann entweder notiert und an einer "sicheren" Position abgelegt werden, alternativ bietet Apple auch an, den Recovery-Key für den Benutzer zu speichern. Letzteres benötigt die Vergabe von Antworten auf Sicherheitsfragen, mit denen der Recovery-Key selbst gesichert wird. Die Antworten auf die Sicherheitsfragen agieren, so wie ich es bisher nachvollziehen konnte, in diesem Szenario als Authentisierung gegen sowie als "Seeds" für die Verschlüsselung des Keys (packet-trace und crypto-Analyse bei/nach Übertragung des Recovery-Keys).
Nachdem der Verschlüsselungsprozess abgeschlossen ist - die Zeit ist abhängig vom System an sich, bei mir ca. 8 Stunden auf meinen basiskonfigurierten System (Mail (200.000 Mails), iTunes Library sowie ein paar Applikationen (ca.130GB an echten Daten) siehe Signatur)) - erwartet OSX 10.7 nach Kaltstart des Systems dass sich ein autorisierter Benutzer gegen Filevault2 authentisiert um das System zu starten. Leider hat Apple hier es unterlassen, die Benutzer zu verstecken und es werden letztlich die autorisierten Benutzer zur Auswahl angeboten, anders als man es zB kennt wenn man die Anmeldeoption "Anmeldefenster zeigt an: "Name und Kennwort"" gewohnt ist. Dieses erleichtert es einem potenziellem Angreifer, da er den Benutzernamen nicht zusätzlich erraten muss, sondern lediglich das Passwort - welches zusätzlich die Autorisierung gegen das Benutzeraccount darstellt. Also eine zweigeteilte Überprüfung des Benutzers nach Authentisierung und Autorisierung, einmal gegen die Festplattenverschlüsselung und dann gegen das Benutzeraccount selbst, gibt es nicht - quasi eine - aus meiner Sicht - "schlechtere" Art von Single-SignON.
Bestehen zum Punkt der Einrichtung von Filevault2 bereits weitere Benutzer auf dem System kann der Administrator oder Hauptbenutzer entscheiden ob auch andere Benutzer die Möglichkeit haben, ebenfalls das System entschlüsseln zu können. Erlaubt man es ihnen nicht muss erst umständlich der Hauptbenutzer das System starten und dann per FastUserSwitching der Zugang für anderen Benutzer ermöglicht werden.
Die Beeinträchtigung des Systems selbst bei der Benutzung ist "gefühlt" nicht wirklich hoch, das Starten eines Systems, hier zB mein in der Signatur genanntes MacBook Pro, beträgt nach der Authentisierung gegen Filevault2, Systemstart, automatischer Anmeldung an ein Wireless Netzwerk und manuelles starten von Safari mit www.google.com als Startseite ca. 40 Sekunden (5400rpm HDD).
Also kurz zusammengefasst, aus meiner Sicht ein guter Anfang, aber bei weitem nicht zu Ende gedacht und es gibt sehr viel Spielraum für Verbesserung. Was die Belastung des Systems angeht, konnte ich bisher nichts negatives feststellen, auch nicht bei hoher Speicher und hoher Festplattenaktivität, also zB Speicher nahezu ausgelastet und lesen von zB HD Material 1080p oder gar 4k. Auch das Abspielen und bearbeiten von größeren Logic-Projekten wurde nicht wirklich signifikant beeinträchtigt.
Problematisch bzw Nachbesserung erhoffe ich mir an folgenden Punkten:
- Nicht beeinflussbare Schlüssellänge - zB 512 bit
- Autorisierte Benutzer - ich möchte a) verstecken welche Benutzer das System entschlüsseln können und b) Berechtigungen zuweisen und auch wieder entziehen können - bei SingleUser Systemen bestimmt zu vernachlässigen.
- Authentisierung & Autorisierung - ich möchte kein Single-SignOn, es sollten getrennte Möglichkeiten bestehen, a) die Festplatte entschlüsseln und das System starten zu können und b) der/die Benutzer sich gegen ihr Benutzerprofil authentisieren können.
- Verschlüsselung des Benutzerprofils - der Benutzer sollte die Möglichkeit haben, sein Profil zusätzlich zu verschlüsseln, dies mit einem anderen Schlüssel, damit seine Daten gegenüber anderen Benutzern auf dem System und auch generell zusätzlich geschützt sind.
- "Network-Keys" - es sollte möglich sein, Benutzern innerhalb eines Netzwerks Zugriff zu erlauben oder zu negieren, derzeit verläuft es so, dass sobald eine zB AFP- oder SMB-Session im Benutzerkontext erlaubt ist, dies auch innerhalb des Benutzerkontexts verläuft (Usermode). Es kann somit jeder Benutzer, dem man erlaubt über das Netzwerk auf Daten zu zugreifen auf diese Daten unverschlüsselt zugreifen und diese auch unverschlüsselt zB lokal auf seinem Rechner ablegen.
Träume und Wünsche:
- Unterstützung von zusätzlichen Medien zur Authentisierung, zB USB-Stick mit einem De-cryption- oder Authentication-Key der an den Benutzer gebunden ist (Smartcard oder Fingerprint lasse ich mal aufgrund fehlender Hardware außen vor).
- "Key-Sharing" - für geteilte Verzeichnisse oder Dateien selbst auf zB OSX 10.7 Server sollte man unterschiedlichen Benutzern mit unterschiedlichen Keys Zugriff auf Daten erlauben können - ich weiss es war bestimmt nicht die Intention von Apple aber man darf doch auch noch Wünsche äussern oder?
Soweit erstmal der "quick review", den ich vielleicht noch hier und da je nach Erfahrungen ergänzen werde.
Hoffe für einige hilfreich ...
SirLockholmes
Zuletzt bearbeitet: