Tut mir leid, aber das ist jetzt alles andere als eine reputable Quelle bzw. die einzige Erklärung für diesen Effekt. Unterschiedliche Angaben von größen können durch unterschiedliche Berechnungen zu stande kommen.
Die Gesamtzahl an Sektoren braucht man nicht zu "berechnen". Man ruft sie aus dem ATA-Konfigurationsregister der Festplatte ab. Und Windows belügt dich hier, denn es werden dir ein paar Tausend unterschlagen.
Die Erklärung für diesen Effekt ist simpel: Die Windows-APIs arbeiten bis heute nicht mit LBA-Schemen, sondern mit einem modifizierten CHS-Modell, das aus dem Holozän der PC-Zeit stammt.
Es bleibt dadurch am Ende (in nahezu allen Fällen) ein damit nicht addressierbarer Bereich, der sich durch eine recht einfache Formel exakt definieren lässt:
Sektoraddresse --->
LBA[SIZE="-2"]
[/SIZE]Physische Gesamtanzahl Sektoren (== LBA[SIZE="-1"]
max[/SIZE] + 1) --->
S[SIZE="-1"]var[/SIZE][SIZE="-2"]
[/SIZE]Logische Spurgrösse (in Sektoren) --->
S[SIZE="-1"]p[/SIZE]T
Dieser Wert kann bei HD-Medien ≥ 2 GiB konstant mit (2^6) - 1 == 63 angesetzt werden.[SIZE="-2"]
[/SIZE]Logische Zylindergrösse (in Spuren) --->
T[SIZE="-1"]p[/SIZE]C
Dieser Wert kann bei HD-Medien ≥ 2 GiB konstant mit (2^8) - 1 == 255 angesetzt werden.[SIZE="-2"]
[/size]Logische Zylindergrösse (in Sektoren) == ( S[SIZE="-1"]p[/SIZE]T * T[SIZE="-1"]p[/SIZE]C ) --->
S[SIZE="-1"]p[/SIZE]C
Kann mit 63 * 255 == 16065 als Konstante angesehen werden.
Code:
S[SIZE="-1"][I]var[/I][/SIZE] > [COLOR="Blue"]LBA[SIZE="-1"][I]err[/I][/SIZE][/COLOR] > ( S[SIZE="-1"][I]var[/I][/SIZE] - ( S[SIZE="-1"][I]var[/I][/SIZE] mod S[SIZE="-1"]p[/SIZE]C ) )
Dazu kommt dann bei den Windows-eigenen Partitionierungswerkzeugen eine zusätzliche Sicherheitszone von einem weiteren freien Zylinder ( also ca. 8 MiB ), um unter wirklich allen Umständen mindestens 2048 Sektoren für den LVM (vulgo: "dynamischer Datenträger") freihalten zu können, s.u.
Benutzt man nicht die Windows Bordmittel, sondern Fremdsoftware zur Partitionierung, dann kann man diesen zusätzlichen Aufschlag zwar vermeiden, dennoch sieht zB eine für XP geeignete Festplatte immer noch so aus: Bilder 1/2
Ich nehme an, du siehst diese hellblaue Zeile, wo der Cursor draufsteht?
Windows Software sieht diese dummerweise
nicht.
Niemals.
Hier ( Bild 3 ) kannst du sehen, was mit "unter Windows nicht verfügbar" gemeint ist.
Die grün markierten Werte sind die realen Werte der Hardware, die roten sind diejenigen die der gesamten System- und Anwendungssoftware als
vermeintlich gesamte HD-Grösse präsentiert werden. Vergleiche die Werte mit denen auf den anderen Bildern...
Unter moderneren Windows-Versionen (hier: Server 2008) sieht es zwar sichtlich anders, aber nicht besser aus: Bild 4
Auf meinen Systemen ist dieser Bereich auch immer durch andere Betriebssysteme belegt und ich habe bisher nicht erlebt, dass Windows in diese Bereiche geschrieben hat, also eines meiner anderen Systeme beschädigt hat.
Wenn du diesen toten Bereich mit einer Datenpartition belegst, riskierst du dass...
A) Windows nicht mehr startet (fehlerhafte Geometrieerkennung, "Medienfehler")
B) Windows beim Start mit einem völlig unnötigen Bluescreen stehenbleibt ( Bild 5 )
C) Windows mit dem Angriff auf seine Alleinherrschaft nicht unbedingt einverstanden ist. Du kannst dich doch nicht einfach so erdreisten, dich nicht an den Paradogmen von MS zu orientieren!
Pfui du! So gehts doch nicht! ( Bild 6 )
D) GRUB oder LiLo mglws. auch kein Linux mehr laden können
(fehlerhafte Geometrieschätzung --> falsche Blockaddresse zum Kernelabbild)
Wie gesagt, ich glaube Dir durchaus, dass Windows nicht die komplette Festplatte Partitionieren kann, allerdings sollte verlässliche Quellen darüber geben was in diesem Bereich steht und ob Windows überhaupt dort etwas hinschreibt.
Tut es, aber nur im Ausnahmefall:
Richtest du die HD als einen "dynamischen Datenträger" ein (ein LVM-System also), dann landet dort die dazugehörige ( 1 MiB grosse ) Volumeverwaltungstabelle.
(Tu das NIEMALS auf einem Mac oder einem anderen EFI Rechner!)
Nicht ganz richtig, man kann wählen ob man die komplette Festplatte verschlüsselt haben will oder lediglich die Partition auf der Windows ist.
Das macht die Kryptoanalyse schwieriger, den Passwortdiebstahl dafür aber noch einfacher.
Mir ist im überigens gerade etwas aufgefallen. Selbst wenn diese Bereiche mit Nullen gefüllt sein sollten, wäre es dadurch nicht möglich den AES-Schlüssel zurück zu rechnen. Betrachte ich diesen Bereich, werde ich ein regelmäßiges Muster sehen.
Nein, das wirst du nicht. Das wäre ja eine gaaaanz tolle Verschlüsselung...
Ich kann also die Annahme treffen, dass hier vorher Nullen standen.
Diese Annahme kann ich bei FDE schon allein anhand der
Position des Chiffre-Blocks treffen.
Somit weiß ich, dass AES mit dem Schlüssel des Benutzers aus Nullen dieses Muster erzeugt.
Nein. Der Schlüssel des Benutzers kommt auf die Chiffreblöcke überhaupt nicht zur Anwendung. Dieser "Ur-Schlüssel" wird genau ein einziges mal benutzt, um den Seedwert für eine automatisch generierte Abfolge von zigtausenden Folgeschlüsseln zu erhalten. Zigtausende Folgeschlüssel, für die ich in den Rainbow Tables mit ebenso zigtausendfach höherer Wahrscheinlichkeit eine bereits vorausberechnete Kollision auffinden kann.
Finde ich davon (von tausenden Kandidaten!) lediglich
sechs direkt aufeinanderfolgende, braucht ein aktueller Consumer-PC für den Rest der gesamten Kette nur noch wenige Tage, mit etwas Glück findest du sieben, dann sind es nur noch wenige Minuten. Bei acht aufeinanderfolgenden Volltreffern gehts schon schneller als ein Wimpernschlag, den Rest des Weges mit purem "Brute Force" zu absolvieren. Das ist zwar bisher immer noch weit unwahrscheinlicher als ein Sechser im Lotto, aber von "sicherer Krypto" zu reden ist hierfür einfach nicht angebracht.
Ich zitiere hier mal das Handbuch zu PGP:
...
Wenn ein Benutzer Klartext mit PGP verschlüsselt, komprimiert PGP zunächst den Klartext. Die Datenkomprimierung spart Übertragungszeit, Speicherplatz und verstärkt vor allem die kryptographische Sicherheit. Die meisten Kryptanalytischen Techniken setzen an Mustern an, die im Klartext gefunden werden, um den Code zu brechen. Durch Komprimierung werden diese Muster im Klartext verringert, was den Widerstand gegen Kryptanalytische Angriffe wesentlich stärkt.
...
PGP erstellt dann einen geheimen Sitzungsschlüssel, der nur für eine Sitzung verwendet werden kann. Dieser Schlüssel ist eine zufällige Zahl, die aus den zufälligen Bewegungen Ihrer Maus und Ihren Tastenanschlägen erstellt wird. Der Sitzungsschlüssel verschlüsselt den Klartext mit einem äußerst sicheren und schnellen konventionellen Verschlüsselungsalgorithmus; das Ergebnis ist
Chiffrentext. Nach dem Verschlüsseln der Daten wird der Sitzungsschlüssel zum öffentlichen Schlüssel des Empfängers verschlüsselt. Dieser zum öffentlichen Schlüssel verschlüsselte Sitzungsschlüssel wird zusammen mit dem Chiffrentext an den Empfänger gesendet.
...
Prinzipiell geht FDE auch so vor, nur dass im Sinne der Performance nicht nur einer, sondern eine schier endlose Serie von ständig wechselnden Schlüsseln verwendet wird. Der Generationsalgorithmus ist dabei wohlbekannt, nur der Initialwert der allerersten Hashwertbildung ist dem Angreifer völlig fremd. Kann er in der Kette der Schlüssel eine hinreichende Regelmässigkeit finden, ist das System so gut wie geknackt, denn sich in dieser Kette beliebig vorwärts und rückwärts zu bewegen ist dann nicht mehr schwieriger als der ganz normale Betrieb des Systems.
Wo ein "normales" Chiffrat (zB aus PGP) nur zwei, drei, vielleicht auch mal 10 zu ermittelnde Hashwerte zum knacken anbietet, offeriert dir eine FDE eine Anzahl, die um mehrere Zehnerpotenzen darüber liegt. Welcher Angriff mag wohl aussichtsreicher sein?
Könnte ich nun daraus den kompletten Schlüssel zurück rechnen, wäre AES ein wirklich schlechter Algorithmus.
Der Algo scheint bisher exzellent zu sein. Aber auch der hypergenialste Alien-Algorithmus ist keinen Pfifferling wert, wenn man ihn falsch einsetzt.
Somit sind also weder die Lücken zwischen Partitionen, noch mit vllt. Null gefüllte Bereiche der Festplatte eine Signifikante Gefahr um daraus den Schlüssel zurück rechnen lassen.
Phil Zimmermann muss dann wohl ein paranoider Depp in dieser Hinsicht sein?
Jetzt wäre es nur mal interessant wo die kritische Menge an Daten liegt, aus der Sich, sofern man Abbildung zwischen Plain und Cipher kennt, die Schlüssel zurückrechnen lässt.
Die Frage muss eher lauten:
Wie gross ist die Menge an bereits vorausberechneten Schlüsseln (die täglich astronomisch zunimmt)?
Meine Efahrungen stammen aus dem Linux bereich und dort wird eine Partition vorher mit Zufallsdaten überschrieben.
Bei der Verwendung eines Dateisystems der ext-Familie (mit geradezu *herrlich* vorhersehbaren Strukturen in rund 10% der gesamten Partition...) kann man das nur als Treppenwitz bezeichnen.
Somit ist, zumindest bei Nutzdaten, für einen Äußeren Angreifer nicht ersichtlich wo was steht.
Du möchtest dich zuerst über den grundlegenden Aufbau eines typischen *nixoiden (iNode-basierten) Dateisystems schlau machen, bevor du solche Kalauer vom Stapel lässt. Dagegen wirkt auch ein NTFS geradezu optimal für diese Verwendung. Das legt seine Strukturen wenigstens zu einem gewissen Teil in unvorhersehbarer Anordnung ab. Bei ext2, ext3 oder ext4 stehen dagegen die Metadatenblöcke strammer in Reih und Glied als die Wachsoldaten vorm Buckingham Palace.
Und hier muss untersucht werden ob ein Angreifer entsprechende Annahmen über die exakte Position von Dateien innerhalb der Verschlüsselung treffen kann um Wiederum zu versuchen den Schlüssel zurück zu rechnen.
Man braucht gar keine Dateien zu finden, das ist ja grade das lustige daran. Ganz im Gegenteil sogar:
Keine Datei ist hier die beste Datei. Du suchst sozusagen nach Mist und erntest dafür das Gold...
Da also die von Dir erwähnten, u.U. mit Nullen gefüllten, Bereiche nicht genug Informationen für einen Kryptoanalyse liefern und man auch keine sichereren Annahmen über die exakte Position von Dateien innerhalb der verschlüsselten Platte treffen lassen, droht über die Kryptoanalyse eindeutig keine Gefahr.
Eine verdoppelte Verneinung mag ein Ja ergeben.
Aber eine doppelt falsche Prämisse ergibt keine richtige Schlussfolgerung.
Zumindest unter Linux kann ich durch überprüfung der /boot Parition eine Manipulation des Kernels nahezu ausschließen.
Will ich dein Passwort klauen, ist mir aber
sowas von egal welches OS du benutzt...
Ob du nun DOS einsetzt, Windows, Solaris, Linux, BSD oder auch Hottentotten-OS, das ändert am Vorgehen exakt überhaupt nichts.
Des weiteren lässt sich eine Manipulation dieser Bereiche weiter minimieren, in dem man dies nicht auf der Festplatte sondern z.B. auf einem USB Stick hat, den man immer bei sich trägt.
Und wie bitte möchtest du mich davon abhalten, deinen Rechner ohne dein Wissen wenigstens ein mal von einem anderen Medium booten zu lassen? Denkst du tatsächlich, das wäre mit einem BIOS-kontrollierten System überhaupt möglich?
Lachhaft.
