return to home page show site map structure contact information and feedback form
Visit MAXXdefense security information portal Mitglieder

nicht registriert

Registrierung
oder einloggen
hier

Security Nachrichten

Information

Firma & AGB
Referenzen & Presse
Produkte
PHP Programmierung
Downloadbereich
Dienstleistungen
Consulting
Security Konzept
Security Auditing
Security-Scan
Auftrags-Hacking
Wireless LAN Security
PKI Konzepte & Integration
Forensik
Telefonsupport
Managed Services
Produktentwicklung
Datenschutz
Rechtsberatung
Weiterbildung
Veranstaltungen
Informationen
IT-Versicherung
Finanzierung
Gratis & Service
IT-Glossar
Login & Registrierung
Partnerprogramm
Kontakt & Anfragen


 24/06/2005 04:38 GroupsSearch NewsNews vorschlagen  
Hardware Festplattenverschlüsselung unzureichend?
Windige Festplattenverschlüsselung
Excelstors GStor-Plus-Festplatte gehackt,

Immer wieder kommen Produkte mit proprietären Verschlüsselungsalgorithmen auf den Markt. Die Wahrscheinlichkeit, dass solch ein selbst gebasteltes Verfahren einer ernsthaften Kryptanalyse standhält, ist gering. Das Beispiel der Festplattenverschlüsselung der GStor Plus von Excelstor zeigt, wie leicht sich so etwas manchmal knacken lässt.

Unter dem Namen GStor Plus[1] bietet der chinesische Hersteller Excelstor eine Festplatte mit integrierter Verschlüsselung und Funktionen zur Systemwiederherstellung an. Einen Testbericht darüber finden Sie in c't 14/05, S. 78[2].

Eine ordentliche Festplattenverschlüsselung in Hardware wäre keine schlechte Sache, bietet doch der ATA-Security-Mechanismus nur einen begrenzten Schutz – Datenrettungsunternehmen können ihn aushebeln (mehr darüber im c't-Artikel Bärendienst[3]). Doch schon die Beschreibung des Verschlüsselungsmechanismus der GStor Plus auf der Website stimmt misstrauisch: Eine "64-Bit-Verschlüsselung", die man gemäß FAQ auch einschalten kann, ohne ein Passwort zu vergeben, welchen Sinn sollte das haben? Selbst wenn alles verschlüsselt auf der Platte gespeichert ist: Wenn sie beim Zugriff on-the-fly alles entschlüsselt, kann man es auch gleich bleiben lassen. Und dass die so genannte Verschlüsselung auch ohne Passwort funktioniert, legt den Schluss nahe, dass der Schlüssel fest auf der Platte gespeichert ist, wo ihn der professionelle Datenretter ebenso leicht findet wie das ATA-Security-Passwort.

Eigentlich wollte ich gar nicht ernsthaft versuchen, die Verschlüsselung zu knacken, weil sie sich durch die eben genannten Eigenschaften für den ernsthaften Schutz vertraulicher Daten ohnehin disqualifiziert. Aber da es relativ mühelos in kurzer Zeit gelungen ist, habe ich meine Erfahrungen in diesem Artikel festgehalten. Das Folgende ist nicht als systematische Anleitung zur Kryptanalyse gedacht. Vielmehr soll es als abschreckendes Beispiel dafür dienen, wie wenig Schutz ein selbst erfundener Verschlüsselungsalgorithmus unter Umständen bietet, selbst wenn der Autor sich etwas "unheimlich kompliziertes" ausgedacht hat.

Die Geschichte beginnt damit, dass ich mal so aus Neugier mit dem Diskeditor in den ersten Sektor der verschlüsselten (Slave-)Platte geschaut habe:

0000 18 39 85 76 43 04 F6 5F-D0 42 F0 C2 27 CE 5E A6 .9.vC.._.B..'.^.
0010 C5 76 02 B0 F6 A9 D7 A8-5C 2F 63 65 C3 66 5F E4 .v......\/ce.f_.
0020 43 C1 24 92 DD 93 A0 A5-42 85 4C BE 3B 85 8B D3 C.$.....B.L.;...
0030 00 7F B0 10 FA 80 1A 16-5E DA 8C 8E 06 AB A2 A9 ........^.......
0040 7C 0E 9D CA 7E 9A FF C6-04 8A 25 F0 B4 58 55 05 |...~.....%..XU.
0050 3D 33 CF 9C 84 D0 7E 33-42 A0 24 D6 A2 40 A2 5C =3....~3B.$..@.\
0060 24 D6 22 02 DA 02 6B 61-86 B3 50 2C 42 60 A0 29 $."...ka..P,B`.)
0070 62 20 82 68 72 60 52 01-08 01 D8 23 0C CE F2 A9 b .hr`R....#....
0080 E5 9F B9 30 83 93 0B 42-7F BA DD 6A 04 92 47 33 ...0...B...j..G3
0090 9A 67 6B E7 7D BF EC 2E-FB 2C 63 25 02 01 3B 52 .gk.}....,c%..;R
00A0 04 8A 27 D0 14 F1 22 B1-44 07 BD 63 79 FE 09 53 ..'...".D..cy..S
00B0 C4 FB E8 6D 50 4F C3 1D-02 F8 CD BE 5E 7D 6C 96 ...mPO......^}l.
00C0 FB 61 0C F1 A6 81 02 68-78 A3 1F CE A4 E8 5E 00 .a.....hx.....^.
00D0 5F E4 A0 68 52 20 F3 BA-D8 B1 C1 79 1F E0 75 29 _..hR .....y..u)
00E0 52 20 45 0F 15 3F 3B 52-04 10 BB A7 56 8B CA C1 R E..?;R....V...
00F0 14 F1 9A 28 81 B7 8B 42-1C DA C0 05 FE 40 50 D0 ...(...B.....@P.
0100 37 B3 CF EA 07 F7 FE 23-7A 20 CF EA 11 00 72 5E 7......#z ....r^
0110 24 51 14 8A E0 68 9D 2D-94 31 CC D1 FB 72 A2 5C $Q...h.-.1...r.\
0120 1C 3A 87 3C A0 1A F2 A5-D6 34 5F 97 3D 53 D0 7C .:.<.....4_.=S.|
0130 91 83 4E 00 DC 10 5C 74-33 00 6B 99 17 20 D0 5C ..N...\t3.k.. .\
0140 6C 32 4A 01 46 D1 FA 74-5C 20 69 98 4C 13 7A D2 l2J.F..t\ i.L.z.
0150 4E 21 C9 7B 4E D1 5C D0-13 C0 4E 21 FC B1 5C F4 N!.{N.\...N!..\.
0160 EE 13 A0 12 95 D1 D2 F4-B1 E1 AC 52 DC 12 D0 74 ...........R...t
0170 FE 10 49 B8 8C D0 F4 D6-DE 12 CD CB 00 00 00 00 ..I.............
0180 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0190 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01A0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01B0 00 00 00 00 24 02 F0 48-5A 66 8B 5B 00 00 80 00 ....$..HZf.[....
01C0 00 01 26 FA 63 23 00 BE-00 00 21 AC 00 21 00 00 ..&.c#....!..!..
01D0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 32 CD ..............2.

Moment mal, das sind verdächtig viele Nullen am Ende. Die Ausgabe eines vernünftigen Verschlüsselungsalgorithmus müsste eigentlich aussehen wie Zufallszahlen. Dieser Sektor hier hat aber Nullen an genau den Stellen stehen, wo man sie auch in einem Master Boot Record erwarten würde.

Hier zum Vergleich der unverschlüsselte MBR, wie die Festplatte ihn freigibt, wenn man von ihr bootet. (Im Folgenden ist der Klartext jeweils blau dargestellt, das Chiffrat rot.) Erst ein bisschen Maschinencode:

0000 33 C0 8E D0 BC 00 7C FB-50 07 50 1F FC BE 1B 7C 3.....|.P.P....|
0010 BF 1B 06 50 57 B9 E5 01-F3 A4 CB BD BE 07 B1 04 ...PW...........
0020 38 6E 00 7C 09 75 13 83-C5 10 E2 F4 CD 18 8B F5 8n.|.u..........
0030 83 C6 10 49 74 19 38 2C-74 F6 A0 B5 07 B4 07 8B ...It.8,t.......
0040 F0 AC 3C 00 74 FC BB 07-00 B4 0E CD 10 EB F2 88 ..<.t...........
0050 4E 10 E8 46 00 73 2A FE-46 10 80 7E 04 0B 74 0B N..F.s*.F..~..t.
0060 80 7E 04 0C 74 05 A0 B6-07 75 D2 80 46 02 06 83 .~..t....u..F...
0070 46 08 06 83 56 0A 00 E8-21 00 73 05 A0 B6 07 EB F...V...!.s.....
0080 BC 81 3E FE 7D 55 AA 74-0B 80 7E 10 00 74 C8 A0 ..>.}U.t..~..t..
0090 B7 07 EB A9 8B FC 1E 57-8B F5 CB BF 05 00 8A 56 .......W.......V
00A0 00 B4 08 CD 13 72 23 8A-C1 24 3F 98 8A DE 8A FC .....r#..$?.....
00B0 43 F7 E3 8B D1 86 D6 B1-06 D2 EE 42 F7 E2 39 56 C..........B..9V
00C0 0A 77 23 72 05 39 46 08-73 1C B8 01 02 BB 00 7C .w#r.9F.s......|
00D0 8B 4E 02 8B 56 00 CD 13-73 51 4F 74 4E 32 E4 8A .N..V...sQOtN2..
00E0 56 00 CD 13 EB E4 8A 56-00 60 BB AA 55 B4 41 CD V......V.`..U.A.
00F0 13 72 36 81 FB 55 AA 75-30 F6 C1 01 74 2B 61 60 .r6..U.u0...t+a`
0100 6A 00 6A 00 FF 76 0A FF-76 08 6A 00 68 00 7C 6A j.j..v..v.j.h.|j
0110 01 6A 10 B4 42 8B F4 CD-13 61 61 73 0E 4F 74 0B .j..B....aas.Ot.

Dann ein paar Fehlermeldungen im Klartext:

0120 32 E4 8A 56 00 CD 13 EB-D6 61 F9 C3 49 6E 76 61 2..V.....a..Inva
0130 6C 69 64 20 70 61 72 74-69 74 69 6F 6E 20 74 61 lid partition ta
0140 62 6C 65 00 45 72 72 6F-72 20 6C 6F 61 64 69 6E ble.Error loadin
0150 67 20 6F 70 65 72 61 74-69 6E 67 20 73 79 73 74 g operating syst
0160 65 6D 00 4D 69 73 73 69-6E 67 20 6F 70 65 72 61 em.Missing opera
0170 74 69 6E 67 20 73 79 73-74 65 6D 00 00 00 00 00 ting system.....

ein paar Nullen

0180 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0190 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01A0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

eine Festplattensignatur von Windows

01B0 00 00 00 00 00 2C 44 63-F6 06 29 70 00 00 .....,Dc..)p..

und ab Offset 0x1BE die Partitionstabelle. Sie enthält vier Einträge á 16 Byte, von denen hier nur der erste belegt ist:

01B0 00 01 ..
01C0 01 00 06 FE 3F 0C 3F 00-00 00 8E 2F 03 00 00 00 ....?.?..../....
01D0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
01F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 ..............

Die letzten beiden Bytes enthalten schließlich die Signatur 55 AA:

01F0 55 AA U.

Vielleicht könnte man allein durch den Vergleich dieser beiden Sektoren hinter das Verfahren kommen. Aber das erscheint mir zu mühsam, ich brauche einfachere Testdaten. Zu diesem Zweck fülle ich einmal den nächsten Sektor von Hand mit dem Diskeditor.

Um herauszufinden, mit welcher Blockgröße die Verschlüsselung arbeitet, ob sie also byteweise, wortweise oder noch anders vorgeht, schreibe ich immer 32 gleiche Bytes hintereinander. Und zwar erst einmal die Bytes, die nur ein Bit gesetzt haben, also 1, 2, 4, 8 usw.:

0000 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0020 01 01 01 01 01 01 01 01-01 01 01 01 01 01 01 01 ................
0030 01 01 01 01 01 01 01 01-01 01 01 01 01 01 01 01 ................
0040 02 02 02 02 02 02 02 02-02 02 02 02 02 02 02 02 ................
0050 02 02 02 02 02 02 02 02-02 02 02 02 02 02 02 02 ................
0060 04 04 04 04 04 04 04 04-04 04 04 04 04 04 04 04 ................
0070 04 04 04 04 04 04 04 04-04 04 04 04 04 04 04 04 ................
0080 08 08 08 08 08 08 08 08-08 08 08 08 08 08 08 08 ................
0090 08 08 08 08 08 08 08 08-08 08 08 08 08 08 08 08 ................
00A0 10 10 10 10 10 10 10 10-10 10 10 10 10 10 10 10 ................
00B0 10 10 10 10 10 10 10 10-10 10 10 10 10 10 10 10 ................
00C0 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
00D0 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
00E0 40 40 40 40 40 40 40 40-40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
00F0 40 40 40 40 40 40 40 40-40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
0100 80 80 80 80 80 80 80 80-80 80 80 80 80 80 80 80 ................
0110 80 80 80 80 80 80 80 80-80 80 80 80 80 80 80 80 ................

Dann noch 0xFF (alle Bits gesetzt), 0x55 und 0xAA (jeweils jedes zweite Bit gesetzt):

0120 FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF ................
0130 FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF ................
0140 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
0150 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
0160 AA AA AA AA AA AA AA AA-AA AA AA AA AA AA AA AA ................
0170 AA AA AA AA AA AA AA AA-AA AA AA AA AA AA AA AA ................

Jetzt fix ein Linux gebootet und den verschlüsselten Sektor in den Diskeditor geladen. Die Nullen bleiben erwartungsgemäß Nullen:

0000 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

Die Zeilen aus Einsen, Zweien und Vieren verwandeln sich in Zeilen mit derselben Anzahl gesetzter Bits:

0020 80 01 80 01 80 01 80 80-80 01 80 01 80 01 80 80 ................
0030 80 01 80 01 80 01 80 80-80 01 80 01 80 01 80 80 ................
0040 00 60 00 60 00 60 20 20-00 60 00 60 00 60 20 20 .`.`.` .`.`.`
0050 00 60 00 60 00 60 20 20-00 60 00 60 00 60 20 20 .`.`.` .`.`.`
0060 02 02 02 02 02 02 08 08-02 02 02 02 02 02 08 08 ................
0070 02 02 02 02 02 02 08 08-02 02 02 02 02 02 08 08 ................

Dann plötzlich eine Abweichung von diesem Muster:

0080 5F 93 A7 CA 79 00 02 02-5F 93 A7 CA 79 00 02 02 _...y..._...y...
0090 5F 93 A7 CA 79 00 02 02-5F 93 A7 CA 79 00 02 02 _...y..._...y...

Es ist also doch nicht nur eine einfache Vertauschung von Bits. Aber jetzt wird klar, was Excelstor mit einer "proprietären 64-Bit-Verschlüsselung" meint: Aus 32 identischen Bytes wurden hier vier gleiche Bytefolgen á 8 Byte, die Platte verschlüsselt also anscheinend jeweils 64-Bit-Wörter. Da hat wohl jemand bei Excelstor nicht verstanden, dass es einen Unterschied zwischen 64-Bit-Schlüsseln und einer Block-Chiffre mit 64-Bit-Blöcken gibt.

In den nächsten drei Abschnitten sind wieder nur einfach die Bits ein bisschen vertauscht:

00A0 10 80 10 80 10 80 04 04-10 80 10 80 10 80 04 04 ................
00B0 10 80 10 80 10 80 04 04-10 80 10 80 10 80 04 04 ................
00C0 0C 00 0C 00 0C 00 10 10-0C 00 0C 00 0C 00 10 10 ................
00D0 0C 00 0C 00 0C 00 10 10-0C 00 0C 00 0C 00 10 10 ................
00E0 40 10 40 10 40 10 40 40-40 10 40 10 40 10 40 40 @.@.@.@@@.@.@.@@
00F0 40 10 40 10 40 10 40 40-40 10 40 10 40 10 40 40 @.@.@.@@@.@.@.@@

Aus der Folge von 0x80-Bytes wird schließlich wieder ein etwas komplizierteres Muster, das sich aber wie alle anderen nach jeweils 8 Byte wiederholt:

0100 00 0C 00 0C 00 0C 57 71-00 0C 00 0C 00 0C 57 71 ......Wq......Wq
0110 00 0C 00 0C 00 0C 57 71-00 0C 00 0C 00 0C 57 71 ......Wq......Wq

Weil die Verschlüsselung Nullen auf Nullen abbildet, hatte ich von Anfang an das Gefühl, sie könnte vielleicht so funktionieren: Jedes Bit im Klartext liefert ein bestimmtes Bitmuster im Chiffrat. Bei mehreren gesetzten Bits im Klartext werden die zugehörigen Bitmuster im Chiffrat per Exklusiv-Oder miteinander verknüpft. (Für Mathematiker: Ich hatte den Verdacht, die Verschlüsselung könnte eine lineare Abbildung sein, wenn man die 64-Bit-Wörter als Elemente eines 64-dimensionalen Vektorraums über dem Körper {0, 1} auffasst.) Ein Blick auf die Chiffrate der Bytefolgen aus 0xFF, 0x55 und 0xAA erhärtet diese Hypothese:

Klartext Chiffrat
01 01 01 01 01 01 01 01 80 01 80 01 80 01 80 80
02 02 02 02 02 02 02 02 00 60 00 60 00 60 20 20
04 04 04 04 04 04 04 04 02 02 02 02 02 02 08 08
08 08 08 08 08 08 08 08 5F 93 A7 CA 79 00 02 02
10 10 10 10 10 10 10 10 10 80 10 80 10 80 04 04
20 20 20 20 20 20 20 20 0C 00 0C 00 0C 00 10 10
40 40 40 40 40 40 40 40 40 10 40 10 40 10 40 40
80 80 80 80 80 80 80 80 00 0C 00 0C 00 0C 57 71
-----------------------XOR-----------------------
FF FF FF FF FF FF FF FF 81 6C 79 35 A7 FF A9 8F

Klartext Chiffrat
01 01 01 01 01 01 01 01 80 01 80 01 80 01 80 80
04 04 04 04 04 04 04 04 02 02 02 02 02 02 08 08
10 10 10 10 10 10 10 10 10 80 10 80 10 80 04 04
40 40 40 40 40 40 40 40 40 10 40 10 40 10 40 40
-----------------------XOR-----------------------
55 55 55 55 55 55 55 55 D2 93 D2 93 D2 93 CC CC

Klartext Chiffrat
02 02 02 02 02 02 02 02 00 60 00 60 00 60 20 20
08 08 08 08 08 08 08 08 5F 93 A7 CA 79 00 02 02
20 20 20 20 20 20 20 20 0C 00 0C 00 0C 00 10 10
80 80 80 80 80 80 80 80 00 0C 00 0C 00 0C 57 71
-----------------------XOR-----------------------
AA AA AA AA AA AA AA AA 53 FF AB A6 75 6C 65 43

Diese Rechnung (spaltenweise Exklusiv-Oder) geht tatsächlich für alle Bytes in Klartext und Chiffrat auf. Vermutlich brauche ich also nur ein Bit "durch das 64-Bit-Wort zu schieben" und jeweils zu verschlüsseln, um daraus das komplette Verfahren zu rekonstruieren. Ein weiterer Sektor mit Testdaten liefert die gewünschten Werte:

Klartext Chiffrat
0000000000000001 0000000000000100
0000000000000002 0000000000002000
0000000000000004 0000000000000002
0000000000000008 000000000000937f *
0000000000000010 0000000000000010
0000000000000020 0000000000000008
0000000000000040 0000000000000040
0000000000000080 0000000000000400
0000000000000100 0000000000000080
0000000000000200 0000000000004000
0000000000000400 0000000000000200
0000000000000800 0000000000000020
0000000000001000 0000000000008000
0000000000002000 0000000000000004
0000000000004000 0000000000001000
0000000000008000 0000000000000800
0000000000010000 0000000001000000
0000000000020000 0000000020000000
0000000000040000 0000000000020000
0000000000080000 00000000ca870000 *
0000000000100000 0000000000100000
0000000000200000 0000000000080000
0000000000400000 0000000000400000
0000000000800000 0000000004000000
0000000001000000 0000000000800000
0000000002000000 0000000040000000
0000000004000000 0000000002000000
0000000008000000 0000000000200000
0000000010000000 0000000080000000
0000000020000000 0000000000040000
0000000040000000 0000000010000000
0000000080000000 0000000008000000
0000000100000000 0000010000000000
0000000200000000 0000200000000000
0000000400000000 0000000200000000
0000000800000000 0000005900000000 *
0000001000000000 0000001000000000
0000002000000000 0000000800000000
0000004000000000 0000004000000000
0000008000000000 0000040000000000
0000010000000000 0000008000000000
0000020000000000 0000400000000000
0000040000000000 0000020000000000
0000080000000000 0000002000000000
0000100000000000 0000800000000000
0000200000000000 0000000400000000
0000400000000000 0000100000000000
0000800000000000 0000080000000000
0001000000000000 8000000000000000
0002000000000000 2000000000000000
0004000000000000 0800000000000000
0008000000000000 0200000000000000
0010000000000000 0400000000000000
0020000000000000 1000000000000000
0040000000000000 4000000000000000
0080000000000000 7057000000000000 *
0100000000000000 0080000000000000
0200000000000000 0020000000000000
0400000000000000 0008000000000000
0800000000000000 0002000000000000
1000000000000000 0004000000000000
2000000000000000 0010000000000000
4000000000000000 0040000000000000
8000000000000000 0100000000000000

Mit dieser Tabelle kann man ein kleines C-Programm schreiben, das den vermuteten Verschlüsselungsalgorithmus implementiert:

/* gcrypt.c by Harald Bögeholz / c't */

#include

typedef long long LWORD;

LWORD crypt_bits[64] =
{
0x0000000000000100LL, /* 0000000000000001 */
0x0000000000002000LL, /* 0000000000000002 */
0x0000000000000002LL, /* 0000000000000004 */
...
0x0100000000000000LL /* 8000000000000000 */
};

int main(void)
{
LWORD word, eword;
int i;

while (1 == fread(&word, sizeof word, 1, stdin))
{
eword = 0;
for (i=0; i<64; ++i)
if (word & (1LL << i))
eword ^= crypt_bits[i];
fwrite(&eword, sizeof eword, 1, stdout);
}

return 0;
}

Es prüft für jedes auf stdin eingelesene 64-Bit-Wort der Reihe nach jedes Bit und fügt bei gesetzten Bits das zugehörige Muster aus der Tabelle dem Ergebniswort eword per Exklusiv-Oder hinzu.

Spannender und für die Praxis nützlicher ist natürlich die Decodierung. Sie funktioniert genau nach demselben Schema, nur benötigt man eine andere Tabelle decrypt_bits[]. Während die Tabelle crypt_bits[] zu jedem Klartextbit das zugehörige Bitmuster im Chiffrat enthält, ist es bei decrypt_bits umgekehrt: Für jedes Bit des Chiffrats steht dort ein Bitmuster im Klartext. (Für Mathematiker: Es geht hier einfach darum, die 64×64-Matrix über {0, 1} zu invertieren.)

Zum Glück hat die Tabelle ja einen ziemlich einfachen Aufbau: In den meisten Bitmustern des Chiffrats ist nur genau ein Bit gesetzt. Das Umkrempeln der Tabelle beschränkt sich also im Wesentlichen darauf, die Zeilen aufsteigend nach den Bits des Chiffrats zu ordnen. Nur in den oben mit * markierten Zeilen ist Nacharbeit gefragt, weil hier im Chiffrat mehrere Bits gesetzt sind. Man könnte das Invertieren der Matrix programmieren, aber da es nur so wenige Zeilen zum Puzzlen gab, habe ich es von Hand im Emacs gemacht. Das Ergebnis sieht so aus:

LWORD decrypt_bits[64] =
{
0x0000000000007c7dLL, /* 0000000000000001 (war 000000000000937f) */
0x0000000000000004LL, /* 0000000000000002 */
0x0000000000002000LL, /* 0000000000000004 */
0x0000000000000020LL, /* 0000000000000008 */
0x0000000000000010LL, /* 0000000000000010 */
0x0000000000000800LL, /* 0000000000000020 */
0x0000000000000040LL, /* 0000000000000040 */
0x0000000000000100LL, /* 0000000000000080 */
0x0000000000000001LL, /* 0000000000000100 */
0x0000000000000400LL, /* 0000000000000200 */
0x0000000000000080LL, /* 0000000000000400 */
0x0000000000008000LL, /* 0000000000000800 */
0x0000000000004000LL, /* 0000000000001000 */
0x0000000000000002LL, /* 0000000000002000 */
0x0000000000000200LL, /* 0000000000004000 */
0x0000000000001000LL, /* 0000000000008000 */
0x00000000b70c0000LL, /* 0000000000010000 (war 00000000ca870000) */
0x0000000000040000LL, /* 0000000000020000 */
0x0000000020000000LL, /* 0000000000040000 */
0x0000000000200000LL, /* 0000000000080000 */
0x0000000000100000LL, /* 0000000000100000 */
0x0000000008000000LL, /* 0000000000200000 */
0x0000000000400000LL, /* 0000000000400000 */
0x0000000001000000LL, /* 0000000000800000 */
0x0000000000010000LL, /* 0000000001000000 */
0x0000000004000000LL, /* 0000000002000000 */
0x0000000000800000LL, /* 0000000004000000 */
0x0000000080000000LL, /* 0000000008000000 */
0x0000000040000000LL, /* 0000000010000000 */
0x0000000000020000LL, /* 0000000020000000 */
0x0000000002000000LL, /* 0000000040000000 */
0x0000000010000000LL, /* 0000000080000000 */
0x0000007800000000LL, /* 0000000100000000 (war 0000005900000000) */
0x0000000400000000LL, /* 0000000200000000 */
0x0000200000000000LL, /* 0000000400000000 */
0x0000002000000000LL, /* 0000000800000000 */
0x0000001000000000LL, /* 0000001000000000 */
0x0000080000000000LL, /* 0000002000000000 */
0x0000004000000000LL, /* 0000004000000000 */
0x0000010000000000LL, /* 0000008000000000 */
0x0000000100000000LL, /* 0000010000000000 */
0x0000040000000000LL, /* 0000020000000000 */
0x0000008000000000LL, /* 0000040000000000 */
0x0000800000000000LL, /* 0000080000000000 */
0x0000400000000000LL, /* 0000100000000000 */
0x0000000200000000LL, /* 0000200000000000 */
0x0000020000000000LL, /* 0000400000000000 */
0x0000100000000000LL, /* 0000800000000000 */
0x78e2000000000000LL, /* 0001000000000000 (war 7057000000000000) */
0x0800000000000000LL, /* 0002000000000000 */
0x1000000000000000LL, /* 0004000000000000 */
0x0400000000000000LL, /* 0008000000000000 */
0x2000000000000000LL, /* 0010000000000000 */
0x0200000000000000LL, /* 0020000000000000 */
0x4000000000000000LL, /* 0040000000000000 */
0x0100000000000000LL, /* 0080000000000000 */
0x8000000000000000LL, /* 0100000000000000 */
0x0008000000000000LL, /* 0200000000000000 */
0x0010000000000000LL, /* 0400000000000000 */
0x0004000000000000LL, /* 0800000000000000 */
0x0020000000000000LL, /* 1000000000000000 */
0x0002000000000000LL, /* 2000000000000000 */
0x0040000000000000LL, /* 4000000000000000 */
0x0001000000000000LL /* 8000000000000000 */
};

Mit dieser Tabelle unter einem von CD gebooteten Knoppix übersetzt, hat das Programm das verschlüsselte Datenlaufwerk auf der GStor Plus korrekt decodiert – Verschlüsselung geknackt.

Das wäre natürlich nicht so einfach gewesen, hätte man nicht die Möglichkeit gehabt, speziell gewählte Klartextwörter durch die Platte chiffrieren zu lassen (Chosen Plain Text Attack). Aber auch durch reine Analyse des Chiffrats dürfte sich die Verschlüsselung einem Experten nicht lange widersetzen, zumal man ja über die auf einer Platte üblicherweise gespeicherten Datenstrukturen einige Annahmen treffen kann (Known Plaintext Attack).

Laut Excelstor arbeitet jedes Laufwerk mit einem anderen Schlüssel, sodass das hier vorgestellte Decodierprogramm für ein anderes Exemplar der GStor Plus nicht funktioniert. Schaut man in die obigen Tabellen, so ist aber nicht schwer zu erraten, wo dieser Schlüssel wohl sitzt: In genau vier Zeilen der Verschlüsselungstabelle, nämlich bei Bit 3, 19, 35 und 51 hat man offenbar ein 16-Bit-Wort als Schlüssel eingebaut, wobei das niederwertige Bit dieses Worts eine Eins sein muss, damit die Matrix invertierbar bleibt. Somit dürfte es sich um nur 60 Schlüsselbits handeln, von denen sich die ersten 15 zum Beispiel durch die bekannte Signatur 55 AA am Ende des MBR rekonstruieren lassen dürften.

Das Ganze hat übrigens einschließlich Programmierung gerade mal zwei Stunden gedauert, wobei eine halbe Stunde allein dafür draufging, von Hand im Emacs eine Matrix zu invertieren. Die Verschlüsselung der GStor Plus ist also allenfalls als milde Datenverschleierung zu bezeichnen. Als Schutz für vertrauliche Daten taugt sie definitiv nicht. Nach dieser Erkenntnis dachte ich mir: Mal schauen, ob sich der Passwortschutz ebenso leicht aushebeln lässt. (bo[4]/c't)

URL dieses Artikels:
http://www.heise.de/security/artikel/60711

Links in diesem Artikel:
[1] http://www.gstor.de/
[2] http://www.heise.de/ct/05/14/078/
[3] http://www.heise.de/ct/05/08/172/
[4] mailto:bo@ct.heise.de
Source: http://www.heise.de/
Category: Festplatten
Raiting:
Assessment:
» Next: Festplatte mit geheimen Polizeidaten versteigert