Re: Extract master key from running system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 27, 2011 at 08:07:24PM -0700, Brian wrote:
> Hi all - 
> 
> Sorry to ask such a noob question, but the FAQ states in the section on
> "Why is all my data permanently gone if I overwrite the LUKS header?": "If
> your header does not contain an intact salt, best go directly to the last
> stage ("Acceptance") and think about what to do now.  There is one
> exception that I know of: If your LUKS container is still open, then it
> may be possible to extract the master key from the running system.  Ask on
> the mailing-list on how to do that and make sure nobody switches off the
> machine."
> 
> If anybody can help fill in the blanks there I'd very much appreciate it.
> I'm on the verge of the acceptance stage of grieving myself, but realized
> that I might fall into this category - the external drive was removed, and
> initialized on a new machine - never properly closed the container, and
> the machine is still running.  I also still see the dm device.  I believe
> the LUKS header is trashed on disk - isLuks gives 234 return, luksDump
> tells me it's not a valid LUKS device.  Any way to recover here?  Or do I
> accept?
 

I have to admit that there is no info in the FAQ because when I wrote 
that I did not have time to find out. In the mean time I have had
an opportunity to do so, so I should probably update the FAQ. First, 
I think trying to dump will not create additional damage. Here is what 
works on my machine:

 cryptsetup luksDump --dump-master-key 

This asks first for a "YES" and then for a valid passphrase.
Result looks like this (test-container via losetup):

LUKS header information for /dev/loop0
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Payload offset: 4096
UUID:           79c87d87-a8c0-4967-b1e4-4c54a11b8b93
MK bits:        256
MK dump:        7d b6 99 d8 3a 09 97 51 92 fa 99 47 b4 bf 33 01 
                a2 12 0e b3 0d 41 f1 c5 e8 78 e3 78 fe eb 1b d8 

If you get this, then you have the real, not protected master 
key. The way to use it is to convert the hex digits of the
MK dump into a binary file, e.g. using hexedit. 

No idea whether this can be done easier, but this approach
worked in an experiment I did.

Then you can use that file with "luksFormat --master-key-file ..." 
and, given all other parameters are the same (not the salt, just 
the parameters passed on the old luksFormat call) you should then 
be able to open the device again.

Safety precaution 1: Make a backup of the first 100MB of
the disk if something goes wrong.

Safety precaution 2: Do a normal "cryptsetup luksDump <device>"
after you get the master key, just in case some parameters are
not the defaults or this container was created with an 
cryptsetup with different defaults.

Note: You may have some filesystem damage on inside the
container, depending on what type of "initialization"
was done.

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
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux