- Registriert
- 03.01.08
- Beiträge
- 3.831
Hallo Freunde.
Basis: Full HDD-Encryption unter OS X
und ein Thema allgemeiner Natur zur Sicherheit hier.
Ich habe diese Checkpoint-SW für OS X gekauft. Momentan schreibe ich das hier von meinem Test-MB auf dem diese FDE läuft.
Vorab: Mein Test-System ist ein MB 3,1 4GB RAM mit einer 160GB 7200rpm SAMSUNG HM160HI Platte. OS X ist 10.5.2. Am Testsystem arbeite ich als Administrator (pfui, ich weiss, aber es ist ein Testsystem :.) ohne FileVault.
Erste Erfahrung: Das Produkt ist schwer zu bekommen. Checkpoint hat keinen Webshop, man muss sich einen Vertriebspartner suchen - das klingt erstmal leicht, da auf checkpoint.com eine Liste existiert, aber in Österreich dünnt sich das dann rasch aus, wenn man nach einer Bezugsquelle sucht.
Es liegt mir also fern, Werbung zu machen, aber die Firma internet-security.at hat mir dann auf direkte Anfrage die SW verkauft - was so simpel klingt, aber nicht ist (siehe unten) .
Zweite Erfahrung: Die SW ist technisch leicht zu installieren, organisatorisch nicht. Man braucht einen Key. Wer aber denkt, das wäre der Code, den man zugeschickt bekommt, der irrt. Man braucht eine Checkpoint-User-ID (die dankenswerterweise für mich von internet-security eingerichtet wurde) und muss das Produkt "registrieren". Spassigerweise soll man eine IP-Adresse eingeben. Dann kann man sich ein keyfile laden, das man beim Installieren angeben muss.
Klingt einfach, wenn ich das so erzähle, aber man muss erst draufkommen.
Technisch ist es sauber gelaufen. Die Installation war problemlos. Danach rebootet der Mac und die Verschlüsselung beginnt im Hintergrund zu laufen. Das dauert mehrere Stunden, man könnte parallel dazu was tun, ich habe es aber einfach laufen lassen. man muss ja nicht beim ersten Test die SW gleich am Limit stressen :.)
Die Checkpoint-SW installiert in die Menüleiste einen "Schnellstarter", über die man vorrangig die Verwaltungs-SW FDEMC starten kann. Zu sehen ist, dass es sich um ein viel umfangreicheres Verwaltungstool handelt als man für eine lokale Endpoint-Security braucht. Unter "local" findet man dann die verfügbaren Einstellmöglichkeiten. Man könnte die PWD-Policy verändern, und den sogenannten "recovery path" anpassen, etc. Kleinigkeiten halt. Unter "Mount Points" sieht man in meinem Fall nur "/" (klar, ich habe ja die ganze Platte verschlüsselt) und kann dort auch erkennen, dass mit AES256 verschlüsselt wurde.
Was ich ausprobieren wollte war, ob mit der FDE ein Benutzen des Sleepmodes trotz der Frozen-RAM-Katastrophe möglich ist. Die Idee war, den Mac immer in den SafeSleep (Deep Sleep) zu zwingen, also das Auslagern des RAM-Inhalts auf die Platte, wodurch auch das RAM ohne Strom geschaltet werden kann. Ein Wiederanfahren würde dann natürlich die Eingabe der FDE-Passphrase bedingen, sonnst könnte das RAM-Image (/var/vm/sleepimage) ja nicht gelesen werden.
Kurz und bündig: Es geht nicht. Man kann zwar sudo pmset -a hibernatemode [Zahl] eingeben (Details siehe zB. hier oder hier) setzen, der Mac führt diesen Befehl auch aus aber das System geht weder über das Menü noch beim Zuklappen des Displays in den Deep Sleep sondern weiterhin in den normalen Sleep (S3), "suspend to RAM". Vermutlich verhindert die FDE-SW das, weil das PreBoot-Authentifizieren eben nicht beim Deep-Sleep funktioniert. Eventuell sehen wir das in einer weiteren Version der Checkpoint-SW, im Moment aber geht es nicht. Auch das Widget "Deep Sleep" (klick) schafft es nicht. Es scheint zwar etwas zu tun, aber beim Aufwachen sieht man, dass man keine Passphrase eingeben musste und auch das System ist viel zu schnell wieder wach als dass es ein sleepimage angelegt haben könnte.
Was bringt die SW: Nun, zum Einen bin ich guter Dinge, dass Checkpoint den Deep-Sleep-Mode eines Tages unterstützt. Der Anfang ist schonmal gemacht, denn vor kurzer Zeit gab es noch überhaupt keine Full Disc Encryption für OS X.
Zum zweiten spart man sich FileVault. Das ist insofern ein Vorteil als dass in 10.5. jedesmal beim Logoff/Runterfahren der freie FileVault-Platz freigegeben wird. (Unter 10.4. durfte man sich noch entscheiden, ob man das nun wollte und warten wollte oder nur einfach Logoff/Runterfahren wollte ohne Pause.). Ausserdem ließe sich Timemachine nutzen (was mit FileVault ja praktisch unbrauchbar ist) - vorausgesetzt, man schafft es TM ein verschlüsseltes Ziellaufwerk unterzuschieben. Ich werde diesbezüglich mal mit TrueCrypt und verschlüsselten Partitionen experimentieren bzw. PGP-Desktop.
Auch kann man ein wesentlich schwächeres Nutzerpasswort verwenden, da ja beim Booten die Passphrase nur einmal benötigt wird. Damit muss man beim Screensaver oder nach einem Sleep nicht wieder 30+ Zeichen lange Passphrases eintippen.
Man kann ein abgeschaltets Gerät also als datentechnisch perfekt gesichert bezeichnen. Nicht einmal Daten die versehentlich ausserhalb des Nutzerordners landen oder Metadaten aus dem Filesystem sind sichtbar.
Was bringt sie nicht: Die Checkpoint-SW schützt nicht vor Frozen RAM. Ich gehe davon aus, dass sie wie jede derartige SW während des Laufens die Passphrase in irgendeiner Form im Speicher haben muss. Wie leicht sie auszulesen ist, weiss ich nicht, die Jungs von Stanford haben ja "nur" Truecrypt, Vistas Bitlocker und Apples FileVault via Frozen RAM geknackt. Vermutlich gibt es für Checkpoint-Breaks noch keine automatisierte Methode, aber das ist an sich unwichtig, denn _wenn_ die Verbrecher mal das Speicherabbild haben und eine verschlüsselte Harddisk dazu ist Zeit kein Thema (in realen Maßstäben, nicht in bruteforce-Dimensionen von Fantastilliarden Jahren), da kann sich ein Expertenteam auch wochenlang damit beschäftigen, wo im Memorydump der Checkpoint-Encryption-Key zu finden ist.
Da man keinen "Suspend to Disk" (Deep Sleep) erzwingen kann, kann man auch mit der FDE den Rechner nicht mit gemounteten "redflag"-Daten in einem Sleepmode hinterlassen/transportieren.
Das heisst, für "redflag"-Daten ist ein zweiter Perimeter unabdingbar. Also zB. eine Partition, die TC- oder PGP-Desktop-verschlüsselt ist und nur in einer sicheren Umgebung und nur für den Zeitraum der Bearbeitung der sensiblen Daten darin gemounted wird und dann unmittelbar wieder dismounted werden muss. Günstigerweise mit einem Scrip gekoppelt das via sleepwatcher ein "force dismount" macht, sodass man eine Art "Notabschaltung" hat bzw. nicht vergessen kann, die Cryptopartition zu dismounten wenn man den Rechner zuklappt.
Performance: Im Moment (allerdings habe ich noch nicht viel Zeit mit dem System verbracht) kann ich keine Geschwindigkeitsmakel feststellen. Wenn jemand Ideen hat, was zu testen wäre (Geschwindigkeit betreffend) und die entsprechende TestSW gratis ist, mache ich das gerne.
Basis: Full HDD-Encryption unter OS X
und ein Thema allgemeiner Natur zur Sicherheit hier.
Ich habe diese Checkpoint-SW für OS X gekauft. Momentan schreibe ich das hier von meinem Test-MB auf dem diese FDE läuft.
Vorab: Mein Test-System ist ein MB 3,1 4GB RAM mit einer 160GB 7200rpm SAMSUNG HM160HI Platte. OS X ist 10.5.2. Am Testsystem arbeite ich als Administrator (pfui, ich weiss, aber es ist ein Testsystem :.) ohne FileVault.
Erste Erfahrung: Das Produkt ist schwer zu bekommen. Checkpoint hat keinen Webshop, man muss sich einen Vertriebspartner suchen - das klingt erstmal leicht, da auf checkpoint.com eine Liste existiert, aber in Österreich dünnt sich das dann rasch aus, wenn man nach einer Bezugsquelle sucht.
Es liegt mir also fern, Werbung zu machen, aber die Firma internet-security.at hat mir dann auf direkte Anfrage die SW verkauft - was so simpel klingt, aber nicht ist (siehe unten) .
Zweite Erfahrung: Die SW ist technisch leicht zu installieren, organisatorisch nicht. Man braucht einen Key. Wer aber denkt, das wäre der Code, den man zugeschickt bekommt, der irrt. Man braucht eine Checkpoint-User-ID (die dankenswerterweise für mich von internet-security eingerichtet wurde) und muss das Produkt "registrieren". Spassigerweise soll man eine IP-Adresse eingeben. Dann kann man sich ein keyfile laden, das man beim Installieren angeben muss.
Klingt einfach, wenn ich das so erzähle, aber man muss erst draufkommen.
Technisch ist es sauber gelaufen. Die Installation war problemlos. Danach rebootet der Mac und die Verschlüsselung beginnt im Hintergrund zu laufen. Das dauert mehrere Stunden, man könnte parallel dazu was tun, ich habe es aber einfach laufen lassen. man muss ja nicht beim ersten Test die SW gleich am Limit stressen :.)
Die Checkpoint-SW installiert in die Menüleiste einen "Schnellstarter", über die man vorrangig die Verwaltungs-SW FDEMC starten kann. Zu sehen ist, dass es sich um ein viel umfangreicheres Verwaltungstool handelt als man für eine lokale Endpoint-Security braucht. Unter "local" findet man dann die verfügbaren Einstellmöglichkeiten. Man könnte die PWD-Policy verändern, und den sogenannten "recovery path" anpassen, etc. Kleinigkeiten halt. Unter "Mount Points" sieht man in meinem Fall nur "/" (klar, ich habe ja die ganze Platte verschlüsselt) und kann dort auch erkennen, dass mit AES256 verschlüsselt wurde.
Was ich ausprobieren wollte war, ob mit der FDE ein Benutzen des Sleepmodes trotz der Frozen-RAM-Katastrophe möglich ist. Die Idee war, den Mac immer in den SafeSleep (Deep Sleep) zu zwingen, also das Auslagern des RAM-Inhalts auf die Platte, wodurch auch das RAM ohne Strom geschaltet werden kann. Ein Wiederanfahren würde dann natürlich die Eingabe der FDE-Passphrase bedingen, sonnst könnte das RAM-Image (/var/vm/sleepimage) ja nicht gelesen werden.
Kurz und bündig: Es geht nicht. Man kann zwar sudo pmset -a hibernatemode [Zahl] eingeben (Details siehe zB. hier oder hier) setzen, der Mac führt diesen Befehl auch aus aber das System geht weder über das Menü noch beim Zuklappen des Displays in den Deep Sleep sondern weiterhin in den normalen Sleep (S3), "suspend to RAM". Vermutlich verhindert die FDE-SW das, weil das PreBoot-Authentifizieren eben nicht beim Deep-Sleep funktioniert. Eventuell sehen wir das in einer weiteren Version der Checkpoint-SW, im Moment aber geht es nicht. Auch das Widget "Deep Sleep" (klick) schafft es nicht. Es scheint zwar etwas zu tun, aber beim Aufwachen sieht man, dass man keine Passphrase eingeben musste und auch das System ist viel zu schnell wieder wach als dass es ein sleepimage angelegt haben könnte.
Was bringt die SW: Nun, zum Einen bin ich guter Dinge, dass Checkpoint den Deep-Sleep-Mode eines Tages unterstützt. Der Anfang ist schonmal gemacht, denn vor kurzer Zeit gab es noch überhaupt keine Full Disc Encryption für OS X.
Zum zweiten spart man sich FileVault. Das ist insofern ein Vorteil als dass in 10.5. jedesmal beim Logoff/Runterfahren der freie FileVault-Platz freigegeben wird. (Unter 10.4. durfte man sich noch entscheiden, ob man das nun wollte und warten wollte oder nur einfach Logoff/Runterfahren wollte ohne Pause.). Ausserdem ließe sich Timemachine nutzen (was mit FileVault ja praktisch unbrauchbar ist) - vorausgesetzt, man schafft es TM ein verschlüsseltes Ziellaufwerk unterzuschieben. Ich werde diesbezüglich mal mit TrueCrypt und verschlüsselten Partitionen experimentieren bzw. PGP-Desktop.
Auch kann man ein wesentlich schwächeres Nutzerpasswort verwenden, da ja beim Booten die Passphrase nur einmal benötigt wird. Damit muss man beim Screensaver oder nach einem Sleep nicht wieder 30+ Zeichen lange Passphrases eintippen.
Man kann ein abgeschaltets Gerät also als datentechnisch perfekt gesichert bezeichnen. Nicht einmal Daten die versehentlich ausserhalb des Nutzerordners landen oder Metadaten aus dem Filesystem sind sichtbar.
Was bringt sie nicht: Die Checkpoint-SW schützt nicht vor Frozen RAM. Ich gehe davon aus, dass sie wie jede derartige SW während des Laufens die Passphrase in irgendeiner Form im Speicher haben muss. Wie leicht sie auszulesen ist, weiss ich nicht, die Jungs von Stanford haben ja "nur" Truecrypt, Vistas Bitlocker und Apples FileVault via Frozen RAM geknackt. Vermutlich gibt es für Checkpoint-Breaks noch keine automatisierte Methode, aber das ist an sich unwichtig, denn _wenn_ die Verbrecher mal das Speicherabbild haben und eine verschlüsselte Harddisk dazu ist Zeit kein Thema (in realen Maßstäben, nicht in bruteforce-Dimensionen von Fantastilliarden Jahren), da kann sich ein Expertenteam auch wochenlang damit beschäftigen, wo im Memorydump der Checkpoint-Encryption-Key zu finden ist.
Da man keinen "Suspend to Disk" (Deep Sleep) erzwingen kann, kann man auch mit der FDE den Rechner nicht mit gemounteten "redflag"-Daten in einem Sleepmode hinterlassen/transportieren.
Das heisst, für "redflag"-Daten ist ein zweiter Perimeter unabdingbar. Also zB. eine Partition, die TC- oder PGP-Desktop-verschlüsselt ist und nur in einer sicheren Umgebung und nur für den Zeitraum der Bearbeitung der sensiblen Daten darin gemounted wird und dann unmittelbar wieder dismounted werden muss. Günstigerweise mit einem Scrip gekoppelt das via sleepwatcher ein "force dismount" macht, sodass man eine Art "Notabschaltung" hat bzw. nicht vergessen kann, die Cryptopartition zu dismounten wenn man den Rechner zuklappt.
Performance: Im Moment (allerdings habe ich noch nicht viel Zeit mit dem System verbracht) kann ich keine Geschwindigkeitsmakel feststellen. Wenn jemand Ideen hat, was zu testen wäre (Geschwindigkeit betreffend) und die entsprechende TestSW gratis ist, mache ich das gerne.
) nur anschließen: Du hast hier einen sehr interessanten Bericht verfasst. Zu Thema Geschwindigkeit: Hast du schon einmal an Xbench gedacht?