Full Disk Encryption / FDE - Vor- und Nachteile

FDE und Dual Boot / GRUB

Hallo,

hat schon jemand, der FDE aktiviert hat (über BIOS Passwort), anschließend zusätzlich zu Windows ein zweites Betriebssystem und einen Bootloader installiert, beispielsweise Ubuntu und GRUB?

So wie ich das verstanden habe, wird die Verschlüsselung bei Thinkpads ausschließlich vom BIOS/Hardware durchgeführt, d.h. eigtl. sollte diese Installation möglich sein, oder hat jemand gegenteilige Informationen?

Gruß,
Thomas
 
Natürlich ist das möglich, eine Festplatte mit FDE ist eine ganz normale Festplatte...

Von der Verschlüsselung bekommst du nichts mit, ausser die Abfrage des Passwortes durch das Bios.

Allerdings solltest du beachten, dass wenn Passphrase im Bios aktiviert ist, die Festplatte nur mit einem Computer ausgelesen werden kann, welches ebenfalls den Passphrase Algorithmus unterstützt. Sprich Thinkpads > 30er Serie.

mfg Moskito
 
Ich war mir nicht sicher, ob der MBR der HD bei FDE-HDs frei beschrieben werden kann bzw. ob die Passworteingabe/Fingerprint Reader noch funktionieren, wenn dort der GRUB eingetragen wird. Aber wenn das alles ausschließlich vom BIOS gesteuert wird, steht dem Dual-Boot ja nichts im Wege.

Danke für die Antwort, Moskito!
Thomas
 
Bin/war auch am überlegen mir eine Seagate FDE (intern für mein X61s) anzuschaffen. Doch mehr und mehr glaube ich das ist Augenwischerei.
Aber so wie ich's bisher verstanden habe schützt die ganze Hardwareverschlüssellei nur vor folgendem Angriffszenario:
Jemand öffnet die Platte mit dem begehrten Daten in einem Reinraum, bastelt eine kompatible, vermutlich werksneu-baugleiche interne Elektronik herein, oder legt die eigentlichen Scheiben auf eine Spindel und zieht sich ein Image. Nunja, diese Technik haben Datenrettungsfirmen und bestenfalls geheimdienstliche oder größe Strafverfolgungsbehörden. Sie wird in der Regel eingesetzt, um Platten auszulesen, deren Controller, Köpfe oder Lager defekt sind, für deren Inhalt aber kein Backup vorhanden ist. Der Spass kostet dann vielleicht einen vierstelligen Betrag oder mehr. Und wer das kann, der kann sich auch den HPA oder sonstwelche von aussen nicht ohne Weiteres adressierbaren Bereiche oder Chips angucken, ob da nicht vielleicht die Schlüssel gar im Plaintext vorliegen.
Der Zugriff von aussen auf die Platte wird aber über ATA Security Features gelöst, und das kann auch jede moderne Platte. Ob ATA/SF ein so sinnvolles Verfahren ist, bleibt dahingestellt, man lese diesen CT Artikel. Erschreckend ist auch dies: http://www.seagateunlock.com/. Letzteres mag hoffentlich auf die FDE-Platten nicht zutreffen, aber ich vermute, dass das nicht das einzige ist, was Datenretter an Firmengeheimnissen in der Schublade haben. In einem etwas späteren Artikel (finde ihn leider nicht mehr) hat CT eine Datenrettungsbude damit beauftragt, eine ATA/SF mit Masterpassword gelockte Platte auszulesen. Dies haben sie wohl problemlos getan, auch ohne die Platte zu öffnen. Und wer an ATA/SF vorbeikommt, kommt auch an die Daten, egal ob sie verschlüsselt sind oder nicht. Für Datenforensiker gibt es aber auch eine kommerzielle Lösung, falls mal keine Herstellerbackdoor zur hand ist: http://www.vogon-investigation.com/password-cracker.htm
http://www.eevidencelabs.com/article/ATA_Security_Roadblock_to_Computer_Forensics.pdf
Die Idee der Ver-/Entschlüsselung durch Plattenhardware hinkt schon daran, dass auch die Authentifizierung nicht vom System gemacht wird sondern einer Security-By-Obscurity-Box-Lösung. Ich fahre seid knapp 1,5 Jahren ein Dualboot System mit Truecrypt und Cryptsetup/Luks. Mit Dualcore2 ist für mich gefühlt keine merkliche Geschwindigkeitseinbuße feststellbar.

Fazit: ATA/SF ist keine verlässliche Authentifikationsmethode, denn wenn diese überwunden ist, liegt die Platte offen, egal ob verschüsselt gespeichert oder nicht.
 
Security-By-Obscurity-Box-Lösung[/url]. Ich fahre seid knapp 1,5 Jahren ein Dualboot System mit Truecrypt und Cryptsetup/Luks. Mit Dualcore2 ist für mich gefühlt keine merkliche Geschwindigkeitseinbuße feststellbar.

Fazit: ATA/SF ist keine verlässliche Authentifikationsmethode, denn wenn diese überwunden ist, liegt die Platte offen, egal ob verschüsselt gespeichert oder nicht.
Naja nicht alles hier ist Security by Obscurity, kommt auf den Hersteller an. Ansonsten stimme ich dir bezüglich FDE soweit zu. Allerdings ist das ein Fehler in der Implementierung, nicht von FDE an sich. Zudem gebe ich folgendes zu bedenken: Authentifizieren musst du dich bei LUKS/Cryptsetup und Truecrypt genauso, und beide Varianten sind angreifbar, da der Bootloader selbst nicht abgesichert ist. Selbst ein TPM schützt nicht wirklich, wenn die Authentifizierung nicht vernünftig implementiert wurde (wie bei Bitlocker, siehe http://testlab.sit.fraunhofer.de/content/output/project_results/bitlocker_skimming/). Und selbst wenn sie das wäre bleiben immer noch Hardware-Keylogger als Angriffsmöglichkeit.
 
[quote='hanseatic',index.php?page=Thread&postID=837540#post837540]Ich fahre seid knapp 1,5 Jahren ein Dualboot System mit Truecrypt und Cryptsetup/Luks. Mit Dualcore2 ist für mich gefühlt keine merkliche Geschwindigkeitseinbuße feststellbar. [/quote]
Dann pack mal 'ne SSD in Dein System :D

Selbst bei FDE ist gibt es die Möglichkeit einer known-plaintext-attack: Teile des OS - egal ob Windows, Linux oder MacOS liegen im Klartext vor...
 
[quote='fishmac',index.php?page=Thread&postID=837602#post837602][quote='hanseatic',index.php?page=Thread&postID=837540#post837540]Ich fahre seid knapp 1,5 Jahren ein Dualboot System mit Truecrypt und Cryptsetup/Luks. Mit Dualcore2 ist für mich gefühlt keine merkliche Geschwindigkeitseinbuße feststellbar. [/quote]
Dann pack mal 'ne SSD in Dein System :D

Selbst bei FDE ist gibt es die Möglichkeit einer known-plaintext-attack: Teile des OS - egal ob Windows, Linux oder MacOS liegen im Klartext vor...[/quote]Naja dann solltest du eine Chiffre nehmen die nicht anfällig für known-plaintext Attacken ist, das ist kein Problem von FDE, Cryptsetup/Luks oder Truecrypt.

Edit: Warum sollte es bei einer SSD höhere Einbußen geben als bei einer Festplatte? Das einzige Argument was mit grad spontan einfällt ist dass die CPU tendenziell eh mehr rattert, da zumindest bei Random-I/O nicht so lange auf die Daten gewartet werden muss, und die CPU daher mehr Arbeit pro Zeit verrichten kann.
 
[quote='tarzan',index.php?page=Thread&postID=837609#post837609]Warum sollte es bei einer SSD höhere Einbußen geben als bei einer Festplatte?[/quote]
Weil die CPU mit dem De-/Encrypten nicht hinterherkommt. Probier's doch mal - Versuch macht kluch...

Welche Chffren - ausser One-Time-Pad - sind denn nicht anfällig für known plaintext attacks ?
 
Dann pack mal 'ne SSD in Dein System :D
Äh, ja, SSDs sind schneller, als Platten, können aber nicht so viel speichern... und? Irgendwo in meinem letzten Link wird unterstellt, dass die in der Platte verbaute CPU mitnichten schnell genug ist, um die Read/Write vorgänge nicht auszubremsen. Bei den noch schnelleren SSDs müsste die Hardware Encryption noch leistungsstärker sein, als bei dem Platten, um nicht zum Flaschenhals zu werden. Wo ist dein Punkt?

[quote='fishmac',index.php?page=Thread&postID=837602#post837602]Teile des OS - egal ob Windows, Linux oder MacOS liegen im Klartext vor... [/quote]So ganz stimmt das nicht, bei Truecrypt ist es der TC eigene Bootloader der offenliegt das ist kein Teil von Windows, bei Linux ist es das Bootsystem (ganz grob vergleichbar mit NTLDR) danach wird ins eigentliche System gewechselt. Dennoch ist beides austauschbar durch etwas, was eine Authentifizierung mitliesst, egal ob das nun eine eingetippte Passphrase ist, eine Smartcard oder eben TPM. Nur dazu müsste erst jemand Zugriff auf den Rechner haben, und warten, bis er wieder von einer authorisierten Person hochgefahren ist. Schützen kann die Daten nur wenn einem der Rechner (oder die Platte) entwendet wird.
 
[quote='hanseatic',index.php?page=Thread&postID=837636#post837636]
Dann pack mal 'ne SSD in Dein System :D
Äh, ja, SSDs sind schneller, als Platten, können aber nicht so viel speichern... und? Irgendwo in meinem letzten Link wird unterstellt, dass die in der Platte verbaute CPU mitnichten schnell genug ist, um die Read/Write vorgänge nicht auszubremsen. Bei den noch schnelleren SSDs müsste die Hardware Encryption noch leistungsstärker sein, als bei dem Platten, um nicht zum Flaschenhals zu werden. Wo ist dein Punkt?[/quote] wieso meinst Du plötzlich den Chip auf der Platte ? Ich rede von der CPU die software en-/decryption durchführt.

[quote='fishmac',index.php?page=Thread&postID=837602#post837602]Teile des OS - egal ob Windows, Linux oder MacOS liegen im Klartext vor...
So ganz stimmt das nicht, bei Truecrypt ist es der TC eigene Bootloader der offenliegt das ist kein Teil von Windows, bei Linux ist es das Bootsystem (ganz grob vergleichbar mit NTLDR) danach wird ins eigentliche System gewechselt. Dennoch ist beides austauschbar durch etwas, was eine Authentifizierung mitliesst, egal ob das nun eine eingetippte Passphrase ist, eine Smartcard oder eben TPM. Nur dazu müsste erst jemand Zugriff auf den Rechner haben, und warten, bis er wieder von einer authorisierten Person hochgefahren ist. Schützen kann die Daten nur wenn einem der Rechner (oder die Platte) entwendet wird.[/quote]Was ist mit Libs und systemnahen Programmen ?
 
Also definieren wir der Einfachheit halber mal FDE= Hardwareimplementiertes FDE. "FDE" wird auch im Truecryptumfeld verwendet, im CryptsetupLUKS umfeldspricht man missverständlich von Full System Encryption (Eben alles bis auf /boot).

[quote='fishmac',index.php?page=Thread&postID=837643#post837643]wieso meinst Du plötzlich den Chip auf der Platte ? Ich rede von der CPU die software en-/decryption durchführt.
[/quote]OK, dann verstehe ich Deinen Punkt, mir ging es hier um HDD Verschlüsselung.
Mein Punkt war eher: Wenn sie da verschlüsselt auf die Packung schreiben ist vielleicht der CEO oder Behördenchef beruhigt, aber technisch Sinn macht es nicht, einen Tresor irgendwohin hinzustellen, und daran hängt ein Holzkästchen mit einem Buntbartschloss gesichert, wo der Zettel mit dem Code für den Tresor drin ist.
Dass man Codes zu Tresoren auch skimmen könnte ist 'ne andere Baustelle.
Naja nicht alles hier ist Security by Obscurity, kommt auf den Hersteller an. Ansonsten stimme ich dir bezüglich FDE soweit zu. Allerdings ist das ein Fehler in der Implementierung, nicht von FDE an sich.
Aber wie würdest Du das theoretisch lösen wollen? Das system greift über ein Sata Device als De/Encrypting HilfsCPU zu?
Also ich hab bei Seagate kaum etwas gefunden wie deren FDE genau funktionieren soll. Über 'zig FDE kritische Texte bin ich dann zu der Annahme gekommen, dass es sich bei der Authentifikation um schlichtes ATA/sf handelt. Wenn das jemand wiederlegen kann, wär ich froh. Wenn meine Annahme aber richtig ist, dann schafft eine stinknormale Platte (oder SSD) Mit ATA Passwörtern quasi das gleiche Maß an Sicherheit, es wird nur teurer, wenn einem die Platte crascht und die Rettungsfirma noch mit der Verschlüsselung handtieren muss.
Was ist mit Libs und systemnahen Programmen ?
Ja, was ist damit? Wenn mir jemand ein trojanisches initramfs unterjubelt, dann muss er physischen Zugriff auf meinen Rechner haben, oder auch von aussen Rootrechte auf meinem System. Aber wenn er die hat, kommt er auch so an alle Daten.
 
ich nutze TrueCrypt & SSD

und bei dem controller flaschenhals der x61 reihe bremst TC / cpu da nix aus ...
 
@hanseatic

Hmmm.... kann es sein, dass Du bei Deiner letzten Message irgendwas mit den quotes durcheinandergebracht hast ?

[quote='hanseatic',index.php?page=Thread&postID=837664#post837664]Also definieren wir der Einfachheit halber mal FDE= Hardwareimplementiertes FDE. "FDE" wird auch im Truecryptumfeld verwendet, im CryptsetupLUKS umfeldspricht man missverständlich von Full System Encryption (Eben alles bis auf /boot).[/quote]
Darauf bezog sich mein Einwand zu den libs - also libc wird z.B. nicht in /boot liegen oder ? - da es nur "endlich viele" libc gibt und libc im verschlüsselten Bereich liegt, wage ich mal zu behaupten, es handelt sich dabei um eine known plaintext attack.

@verdi: Ich habe ein T400 und da gilt für den Speed LUKS + SSD = Standard Platte
 
[quote='fishmac',index.php?page=Thread&postID=837687#post837687]Darauf bezog sich mein Einwand zu den libs - also libc wird z.B. nicht in /boot liegen oder ? - da es nur "endlich viele" libc gibt und libc im verschlüsselten Bereich liegt, wage ich mal zu behaupten, es handelt sich dabei um eine known plaintext attack.[/quote]Es gibt sicher eine Menge known plaintext in einer beliebigen Linuxinstallation. Ich warlich kein Cryptoexperte, aber so wie ich das Salt bei AES oder SHA verstehe dient es genau dazu, dass das Ergebnis einer Verschlüsselung jedesmal unterschiedlich ist. Wie dem auch sei, sehe ich die Möglichkeit eines Angriffs auf eine Verschlüsselung, nicht als Grund, auf eine sinnvolle Authentifizierung zu verzichten.
 
mag sein dass es mit LUKS so ist ... tc & win 7 & ssd is jedenfalls DEUTLICH schneller als die standard hdd

und mit/ohne TC macht im netzbetrieb auf dem x61t nichts aus ... bei cpu auf minimum im akkubetrieb merkt man es etwas aber immernoch deutlich schneller als standardplatte
 
[quote='hanseatic',index.php?page=Thread&postID=837664#post837664]
Naja nicht alles hier ist Security by Obscurity, kommt auf den Hersteller an. Ansonsten stimme ich dir bezüglich FDE soweit zu. Allerdings ist das ein Fehler in der Implementierung, nicht von FDE an sich.
Aber wie würdest Du das theoretisch lösen wollen? Das system greift über ein Sata Device als De/Encrypting HilfsCPU zu?
Also ich hab bei Seagate kaum etwas gefunden wie deren FDE genau funktionieren soll. Über 'zig FDE kritische Texte bin ich dann zu der Annahme gekommen, dass es sich bei der Authentifikation um schlichtes ATA/sf handelt. Wenn das jemand wiederlegen kann, wär ich froh. Wenn meine Annahme aber richtig ist, dann schafft eine stinknormale Platte (oder SSD) Mit ATA Passwörtern quasi das gleiche Maß an Sicherheit, es wird nur teurer, wenn einem die Platte crascht und die Rettungsfirma noch mit der Verschlüsselung handtieren muss.
[/quote]Ich will gar nichts lösen :) . Ich sage nur das ist ein Implementierungsproblem. Wenn die Hersteller Backdoors einbauen oder sonstige Fehler bei der Implementierung der ATA Security Features machen, heisst das nicht, das FDE seine Sicherheitsziele nicht erreicht, sondern nur das der Hersteller Mist baut. [quote='hanseatic',index.php?page=Thread&postID=837699#post837699][quote='fishmac',index.php?page=Thread&postID=837687#post837687]Darauf bezog sich mein Einwand zu den libs - also libc wird z.B. nicht in /boot liegen oder ? - da es nur "endlich viele" libc gibt und libc im verschlüsselten Bereich liegt, wage ich mal zu behaupten, es handelt sich dabei um eine known plaintext attack.[/quote]Es gibt sicher eine Menge known plaintext in einer beliebigen Linuxinstallation. Ich warlich kein Cryptoexperte, aber so wie ich das Salt bei AES oder SHA verstehe dient es genau dazu, dass das Ergebnis einer Verschlüsselung jedesmal unterschiedlich ist. Wie dem auch sei, sehe ich die Möglichkeit eines Angriffs auf eine Verschlüsselung, nicht als Grund, auf eine sinnvolle Authentifizierung zu verzichten.[/quote]Die Authentifizierung bei ATA Security erfolgt hier durch Wissen, nämlich durch das Passwort, durch dass der Schlüssel innerhalb der Plattenelektronik freigeschaltet wird. Das ist dennoch blöd, da kein vertrauenswürdiger Pfad zwischen dir und der Gegenstelle existiert (Keylogger oder das Sniffen des IDE/SATA Bus wären Möglichkeiten, das Passwort abzufangen, was auch der Grund ist, das Smartcard-Reader für Homebanking eine eigene Tastatur haben). Ich wollte mit meinen Posts nur sagen, dass FDE bei korrekter Implementierung nicht weniger Sicherheit bietet als Cryptsetup/LUKS oder Truecrypt.[quote='fishmac',index.php?page=Thread&postID=837623#post837623][quote='tarzan',index.php?page=Thread&postID=837609#post837609]Warum sollte es bei einer SSD höhere Einbußen geben als bei einer Festplatte?[/quote]Weil die CPU mit dem De-/Encrypten nicht hinterherkommt. Probier's doch mal - Versuch macht kluch...

Welche Chffren - ausser One-Time-Pad - sind denn nicht anfällig für known plaintext attacks ?[/quote]Ein OTP bietet perfekte Informationssicherheit, wolltest du darauf hinaus? Ich lass mich natürlich gerne korrigieren, ist auch schon ne Weile her, aber meines Wissens gilt beispielsweise AES bisher noch als sicher gegen known-plaintext Angriffe (wenn man mal von fehlerhaften Implementierungen absieht (Angriffe über den Cache, Differential Power Analysis...)).
 
Im Wesentlichen sind wir uns ja einig.
Aber nochmal zu meinem Verständnis:
Nehmen wir an, die ATA Sicherheitsfeatures sind korrekt, (sprich ohne absichtliche oder versehentliche Sicherheitslücken) implementiert. Sprich die Platte gibt ihren Inhalt nur frei, wenn sie ein gültiges Passwort erhält. (Workarounds zum Resetten des Passwords oder der Firmware sind auch nicht vorgesehen. Welchen zusätzlichen Schutz bietet dann eine in der Platte herumfuhrwerkende Verschlüsselung, abgesehen vom Lesen von Plaintext auf den eigentlichen Scheiben unter Laborbedingungen?
Und: Muss nicht zwingend irgendwo in der Platte, sei es in einem ROM, HPA oder woauchimmer die Passphrase im Plaintext vorliegen, oder wäre es auch denkbar, dass diese irgendwie gehasht ist?

Update:
Aus den Altoa Insight FAQs:

Question: When I lock a hard drive in a laptop with known password and then try to extract that password with Atola Insight, extracted password does not match the one I used to lock the drive Cause: Laptops apply some scrambling algorithm (depending on the laptop manufacturer) before sending the password you type to the hard drive.
Resolution: There is nothing to resolve. The extracted (encrypted) password is the one that is in the hard drive. You can use it to unlock the drive.

Aus : http://atola.com/products/insight/supported-drives.html

Automatic password removal works for the following models:
  • All Seagate hard drives except 7200.11 models (and newer) - we are currently working on these
Nochwas interessantes, es scheint sich nicht "nur" um "simple" ATA Security zu handeln.

http://www.heise.de/mobil/artikel/Laborbericht-474761.html
 
Hallo Ihr Experten. Mein Sicherheitskonzept sieht ganz anders aus. Man nehme 1 Thinkpad und 2 Festplatten, 1 FP fürs Internet, und 1 Platte für den privaten und geschäftlichen Bereich. Kann man ja bei einem Thinkpad leicht wechseln. Keylogger oder Bundestrojaner haben so nur eine Change auf die Internetplatte zu schauen. Auf die private FP kommt ein Truecrypt Container gegen Diebstahl und gut is. Gibt es bei dieser Lösung ein Sicherheitsrisiko ? Gruß Linse1
 
[quote='linse1',index.php?page=Thread&postID=837865#post837865]Hallo Ihr Experten. Mein Sicherheitskonzept sieht ganz anders aus. Man nehme 1 Thinkpad und 2 Festplatten, 1 FP fürs Internet, und 1 Platte für den privaten und geschäftlichen Bereich. Kann man ja bei einem Thinkpad leicht wechseln. Keylogger oder Bundestrojaner haben so nur eine Change auf die Internetplatte zu schauen. Auf die private FP kommt ein Truecrypt Container gegen Diebstahl und gut is. Gibt es bei dieser Lösung ein Sicherheitsrisiko ? Gruß Linse1[/quote]Mit Festplattenverschlüsselung in welcher Form auch immer schützt man nicht Daten in einem laufenden System, denn dieses hat ja zugriff auf die Platte. Soweit richtig. Aber machst Du im Internet nicht auch Dinge, die schützenswert sind? Z.B. Onlinebanking, im Thinkpadforum anmelden, Emails etc.)
Auch zweifel ich einwenig an der Praktikabilität. Ich will ja nicht immer rebooten, wenn ich zwischen einer on- und offline Anwendung wechsle. Gehst Du denn nicht auch geschäftlich/privat ins Netz? Spätestens wenn ich meinen Liebesbrief oder eine Rechnung drucken will muss ich zumindst was zum Netzwerkdrucker schicken, in einem Netzwerk, in dem auch andere potentielle Zombierechner sind. Ich will auch mal was im privaten oder Geschäftlichen Bereich aus dem Internet copypasten oder nachschlagen. Ausserdem gibt es ja auch Dinge die man im www so macht, die auch schützenswert sind (nicht nur Onlinebanking).
 
[quote='hanseatic',index.php?page=Thread&postID=837892#post837892]Auch zweifel ich einwenig an der Praktikabilität. Ich will ja nicht immer rebooten,[/quote]

Das ist ein Nachteil dieser Lösung, den ich aber in Kauf nehme. Ich glaube kaum, das eine FDE Platte beim surfen einen Schutz bietet. Die größte Gefahr sehe ich immer noch durch Trojaner und Keylogger, die Passwörter mitschreiben und weitersenden. Vertrauliche Mails werden auf der privaten FP geschrieben und verschlüsselt, dann per USB Stick auf die dann gewechselte Internetplatte verschoben. Sicher ein großer Aufwand, aber dafür sehr sicher. Ein Rechner in Netz ist immer ein Risiko. Auch Privat habe ich 2 Rechner am laufen, die untereinander nicht vernetzt sind, 1* Internet und 1* Privatrechner. Drucker sind auch 2 vorhanden. Alles ein wenig aufwändig, aber sehr sicher.

Gruß Linse1
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben