LUKS keyslot 4 is invalid.

dm-crypt Mika Kujanpää 3 participants 4 messages Nov 26, 2011 – Nov 27, 2011

Share & tools

Mika Kujanpää

author

2011-11-26 14:29 UTC #0 lore raw

I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get

cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3 LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.

cryptsetup luksOpen /dev/disk/by-uuid/96914f6d-25c8-43d2-8133-2d9c971db9df vara LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.

Milan Broz

2011-11-26 18:45 UTC #1 lore raw

Quoted 5 lines · Mika Kujanpää

I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get
cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3 LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.

Which cryptsetup version?

Basically it means that either kesylot has wrong offset (or there is bug in cryptsetup itself, I recently added some offset check code here).

Could you send me (to private mail, not to list) dd of this broken LUKS header so I can check what's wrong?

(just first 4k of device - without private keyslots area, e.g. only visible information - you can use this command

dd if=<luks_device> of=<backup_file> bs=4096 count=1

Thanks,
Milan

Milan Broz

2011-11-27 11:33 UTC #2 lore raw

Quoted 6 lines · Milan Broz

Quoted 5 lines · Mika Kujanpää
I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get
cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3 LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.

Perhaps another item to FAQ:

In cryptsetup 1.4.x I added check of keyslot data offset. (Keyslot offset is calculated during format for all slots including inactive slots.)

If any keyslot offset points to the area outside of LUKS header, header is corrupted (IOW keylot point to the payload data area and in theory can overwrite user data when activated.)

And exactly this happened there, inactive slot 4 and 5 had wrong offset. Because there was know signature 0x55 0xAA in last bytes of the first sector I guess some "clever" partition tool wrote few bytes there after LUKS was formatted.

if you run luksDump --debug here, you will see better error message, here e.g.

# Reading LUKS header of size 1024 from device /dev/sdb
# Invalid offset 1760061416 in keyslot 4 (beyond data area offset 4096). LUKS keyslot 4 is invalid.

How to fix that depends on situation...

If you have old cryptsetup, you can activate device and reformat the header using "How do I recover the master key
from a mapped LUKS container?" in FAQ.

With exact knowledge of LUKS header you can fix that manually. (I used simple dd from another device in this case but offset depends on situation.)

Milan

Arno Wagner

2011-11-27 12:30 UTC #3 lore raw

Hi Lilan,

I will add this. The check is a pretty good idea IMO.

Arno

Quoted 47 lines · Milan Broz

Quoted 6 lines · Milan Broz
Quoted 5 lines · Mika Kujanp??
I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get
cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3 LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.
Perhaps another item to FAQ:
In cryptsetup 1.4.x I added check of keyslot data offset. (Keyslot offset is calculated during format for all slots including inactive slots.)
If any keyslot offset points to the area outside of LUKS header, header is corrupted (IOW keylot point to the payload data area and in theory can overwrite user data when activated.)
And exactly this happened there, inactive slot 4 and 5 had wrong offset. Because there was know signature 0x55 0xAA in last bytes of the first sector I guess some "clever" partition tool wrote few bytes there after LUKS was formatted.
if you run luksDump --debug here, you will see better error message, here e.g.
# Reading LUKS header of size 1024 from device /dev/sdb
# Invalid offset 1760061416 in keyslot 4 (beyond data area offset 4096). LUKS keyslot 4 is invalid.
How to fix that depends on situation...
If you have old cryptsetup, you can activate device and reformat the header using "How do I recover the master key
from a mapped LUKS container?" in FAQ.
With exact knowledge of LUKS header you can fix that manually. (I used simple dd from another device in this case but offset depends on situation.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Signature · 7 lines

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
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