Ok, here is a preliminary analysis. Note that I use "hex", not "hexdump"
for the output, which gives better readability, as the data is stored
in network byte order, i.e. big-endian by LUKS. This means with the "hex"
output you can just read numbers left-to-right. Sorry for going over 80
columns, the alternative is unprintables which confuse my terminal.
First the part before the keyslots:
Good LUKS header:
0x00000000: 4c 55 4b 53 ba be 00 01 - 61 65 73 00 00 00 00 00 LUKS<BA><BE>..aes.....
0x00000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000020: 00 00 00 00 00 00 00 00 - 63 62 63 2d 65 73 73 69 ........cbc-essi
0x00000030: 76 3a 73 68 61 32 35 36 - 00 00 00 00 00 00 00 00 v:sha256........
0x00000040: 00 00 00 00 00 00 00 00 - 73 68 61 31 00 00 00 00 ........sha1....
0x00000050: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000060: 00 00 00 00 00 00 00 00 - 00 00 04 08 00 00 00 10 ................
0x00000070: 14 dd 4f b8 1f 42 a1 02 - 9a 93 ec ae bf 26 8d 7c ..O..B....<EC><AE>.&.|
0x00000080: 40 2e 6d 5c 4c ba 21 d8 - 31 94 dc 00 2c 0d 43 39 @.m\L.!.1...,.C9
0x00000090: bb 03 24 95 4f fe 97 97 - a0 2c 75 63 ea 92 cb a5 ..$.O....,uc..<CB><A5>
0x000000a0: 4d aa a0 1c 00 00 00 0a - 31 35 31 61 37 30 34 64 M.......151a704d
0x000000b0: 2d 34 36 33 36 2d 34 61 - 38 30 2d 39 34 61 66 2d -4636-4a80-94af-
0x000000c0: 63 32 61 34 65 61 62 66 - 36 38 31 63 00 00 00 00 c2a4eabf681c....
Good GRUB bootsector:
0x00000000: eb 48 90 00 00 00 00 00 - 00 00 00 00 00 00 00 00 .H..............
0x00000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 03 02 ................
0x00000040: ff 00 00 20 01 00 00 00 - 00 02 fa 80 ca 80 ea 53 ... ...........S
0x00000050: 7c 00 00 31 c0 8e d8 8e - d0 bc 00 20 fb a0 40 7c |..1.<8E><D8>.<8E><D0>... ..@|
0x00000060: 3c ff 74 02 88 c2 52 be - 79 7d e8 34 01 f6 c2 80 <.t...R.y}.4.<F6><C2>.
0x00000070: 74 54 b4 41 bb aa 55 cd - 13 5a 52 72 49 81 fb 55 tT.A<BB><AA>U..ZRrI..U
0x00000080: aa 75 43 a0 41 7c 84 c0 - 75 05 83 e1 01 74 37 66 .uC.A|..u....t7f
0x00000090: 8b 4c 10 be 05 7c c6 44 - ff 01 66 8b 1e 44 7c c7 .L...|.D..f..D|.
0x000000a0: 04 10 00 c7 44 02 01 00 - 66 89 5c 08 c7 44 06 00 ....D...f.\..D..
0x000000b0: 70 66 31 c0 89 44 04 66 - 89 44 0c b4 42 cd 13 72 pf1..D.f.D..B..r
0x000000c0: 05 bb 00 70 eb 7d b4 08 - cd 13 73 0a f6 c2 80 0f ...p.}....s.<F6><C2>..
The problem:
0x00000000: eb 48 90 53 ba be 00 01 - 61 65 73 00 00 00 00 00 .H.S<BA><BE>..aes.....
0x00000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000020: 00 00 00 00 00 00 00 00 - 63 62 63 2d 65 73 73 69 ........cbc-essi
0x00000030: 76 3a 73 68 61 32 35 36 - 00 00 00 00 00 00 03 02 v:sha256........
0x00000040: ff 00 00 80 3d 3f 3a 01 - 00 08 fa 90 90 f6 c2 80 ....=?:......<F6><C2>.
0x00000050: 75 02 b2 80 ea 59 7c 00 - 00 31 c0 8e d8 8e d0 bc u....Y|..1.<8E><D8>.<8E><D0>
0x00000060: 00 20 fb a0 40 7c 3c ff - 74 02 88 c2 52 be 7f 7d . ..@|<.t...R..}
0x00000070: e8 34 01 f6 c2 80 74 54 - b4 41 bb aa 55 cd 13 5a .4.<F6><C2>.tT.A<BB><AA>U..Z
0x00000080: 52 72 49 81 fb 55 aa 75 - 43 a0 41 7c 84 c0 75 05 RrI..U.uC.A|..u.
0x00000090: 83 e1 01 74 37 66 8b 4c - 10 be 05 7c c6 44 ff 01 ...t7f.L...|.D..
0x000000a0: 66 8b 1e 44 7c c7 04 10 - 00 c7 44 02 01 00 66 89 f..D|.....D...f.
0x000000b0: 5c 08 c7 44 06 00 70 66 - 31 c0 89 44 04 66 89 44 \..D..pf1..D.f.D
0x000000c0: 0c b4 42 cd 13 72 05 bb - 00 70 eb 7d b4 08 cd 13 ..B..r...p.}....
This looks very much like GRUB taking the original sectors, modifying
only the bytes it needs, and thereby leaving parts of the LUKS header intact.
Now for the rest of the problem:
0x000000d0: 73 0a f6 c2 80 0f 84 ea - 00 e9 8d 00 be 05 7c c6 s.<F6><C2>..........|.
0x000000e0: 44 ff 00 66 31 c0 88 f0 - 40 66 89 44 04 31 d2 88 D..f1...@xxxxxxx
0x000000f0: ca c1 e2 02 88 e8 88 f4 - 40 89 44 08 31 c0 88 d0 <CA><C1>......@.D.1..<D0>
0x00000100: c0 e8 02 66 89 04 66 a1 - 44 7c 66 31 d2 66 f7 34 ...f..f.D|f1.f.4
0x00000110: 88 54 0a 66 31 d2 66 f7 - 74 04 88 54 0b 89 44 0c .T.f1.f.t..T..D.
0x00000120: 3b 44 08 7d 3c 8a 54 0d - c0 e2 06 8a 4c 0a fe c1 ;D.}<.T.<C0><E2>..L.<FE><C1>
0x00000130: 08 d1 8a 6c 0c 5a 8a 74 - 0b bb 00 70 8e c3 31 db ...l.Z.t...p<8E><C3>.1<DB>
0x00000140: b8 01 02 cd 13 72 2a 8c - c3 8e 06 48 7c 60 1e b9 .....r*....H|`..
0x00000150: 00 01 8e db 31 f6 31 ff - fc f3 a5 1f 61 ff 26 42 ..<8E><DB>.1.1.<FC><F3>..a.&
0x00000160: 7c be 85 7d e8 40 00 eb - 0e be 8a 7d e8 38 00 eb |..}.@.....}.<8E><B8>..
0x00000170: 06 be 94 7d e8 30 00 be - 99 7d e8 2a 00 eb fe 47 ...}.0...}.*.<EB><FE>G
0x00000180: 52 55 42 20 00 47 65 6f - 6d 00 48 61 72 64 20 44 RUB .Geom.Hard D
0x00000190: 69 73 6b 00 52 65 61 64 - 00 20 45 72 72 6f 72 00 isk.Read. Error.
0x000001a0: bb 01 00 b4 0e cd 10 ac - 3c 00 75 f4 c3 00 00 00 ........<8E><BC>.u<F4><C3>..
0x000001b0: 00 00 00 00 00 00 00 00 - 00 00 02 08 00 00 0f a0 ................
0x000001c0: 00 00 de ad 00 00 00 00 - 00 00 00 00 00 00 00 00 ..<DE><AD>............
0x000001d0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x000001e0: 00 00 00 00 00 00 00 00 - 00 00 02 88 00 00 0f a0 ................
0x000001f0: 00 00 de ad 00 00 00 00 - 00 00 00 00 00 00 55 aa ..<DE><AD>..........U.
0x00000200: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000210: 00 00 00 00 00 00 00 00 - 00 00 03 08 00 00 0f a0 ................
0x00000220: 00 00 de ad 00 00 00 00 - 00 00 00 00 00 00 00 00 ..<DE><AD>............
0x00000230: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0x00000240: 00 00 00 00 00 00 00 00 - 00 00 03 88 00 00 0f a0 ................
...
This looks to me like GURB data until 0x1b0 and then remaining (unfortunately unused)
LUKS keyslot descriptors, up to and including slot 8.
After that ist continues in what sems to be random data:
0x00000250: 96 60 e2 85 e9 52 b4 cd - 82 d9 de 46 91 af 79 cd .`...R<B4><CD>.<D9><DE>F..y
0x00000260: ed 19 2e d8 38 dc 56 d9 - 2e cb fd 28 b2 e4 e6 79 ....8.V..<CB><FD>(<B2><E4>.y
0x00000270: 9e 9f f6 46 39 77 32 ec - 91 bd c1 83 72 62 9f dd ...F9w2..<BD><C1>.rb.<DD>
0x00000280: ea d9 7e cf 7b 64 ea 7c - 0c cb 6d e3 4c 77 ac f2 ..~.{d.|..m.Lw<AC><F2>
0x00000290: b6 cc 20 bb 2a 7d 83 ce - 4e 5e f7 cd 4f 0e 2d f7 <B6><CC> .*}..N^<F7><CD>O.
...
I asumme this is leftover disk content from before the LUKS initialisation.
Given that the key-mateial-offsets in the residue look like my reference
all-default values, I would say there is a good change the key material
for keyslot 0 still resides at offset 0x1000 - 0x2000. However, here the
problem starts. While the key is probably still there, the 256 bit salt,
stored in the keyslot, is not. Also the salt parameter for the master key
(also 256 bit) is very likely missing as well as GRUB writes data in both
areas.
As far as I understand PBKDF2, the key without the salts is completely
useless. As far as I can tell, both salts are generated in cryptsetup
by a call to getRandom, which in turn uses /dev/urandom. This means
the salts are of key-material quality, unless the random pool was really,
really empty.
Hmm. Keep in mind this is preliminary. If I have this righ, then an
attack on two key-strength 256 bit random numbers would be needed to
recover the data, even if the key material is intact. That would be
infeasible.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx
