[dm-crypt] Is partial LUKS recovery possible?

[dm-crypt] Is partial LUKS recovery possible?

[Miklos Bagi]

Hi all,

I'm hoping to get directions with a 'small' recovery task.

Given a partition that's known to be a broken LUKS one, lhdr is missing
(incl magic, chipher, hash, uuid, etc.), however there are some facts known:
- chipher: aes-cbc-essiv:sha256
- keysize: 256 bits
- offset: 2056 sectors
- most importantly: we have the master key file available.

I have the suspicion that the first approx 10% of the partition have
been overwritten with random data.
What are the chances of recovering any data in the given scenario?

Thanks in advance,
mB

Re: [dm-crypt] Is partial LUKS recovery possible?

[Miklos Bagi]

Apologies for replying my own post.

I believe I found the not so happy answer for me in Dr. Wagner's monthly
FAQ.

Is it possible to provide salt manually?
Implementing a simple logic may allow re-generating the original header
in case something bad happens, but I admit it makes sense keeping
backups of lhdrs somewhere safe.

Thanks,
Miklos

On 12/02/2010 11:28 AM, Miklos Bagi wrote:
> Hi all,
>
> I'm hoping to get directions with a 'small' recovery task.
>
> Given a partition that's known to be a broken LUKS one, lhdr is missing
> (incl magic, chipher, hash, uuid, etc.), however there are some facts known:
> - chipher: aes-cbc-essiv:sha256
> - keysize: 256 bits
> - offset: 2056 sectors
> - most importantly: we have the master key file available.
>
> I have the suspicion that the first approx 10% of the partition have
> been overwritten with random data.
> What are the chances of recovering any data in the given scenario?
>
> Thanks in advance,
> mB
>

Re: [dm-crypt] Is partial LUKS recovery possible?

[Arno Wagner]

Hi Miklos,

the salt is key-grade material, so without salt, you are 
about in the same situatuion as you are without master key. 
Basically everything in the header can be re-created but 
the salt, and therefore recovery without header is not possible.

It is not that intuitive, but salting itself is not intuitive
at first glance. Salts only work if they are non-predictable
and that is just the condition that a key must fulfill.

So, sorry, but without header backup you data is gone and
that is by design. Hopefully these disasters will get 
less frequent now that the FAQ is part of the cryptsetup
distribution.

I think I will add an explanation to the FAQ about what 
a salt is and how it is integrated in LUKS. This will
hopefully make things even clearer.

Gr"usse,
Arno



On Thu, Dec 02, 2010 at 01:15:52PM +0100, Miklos Bagi wrote:
> Apologies for replying my own post.
> 
> I believe I found the not so happy answer for me in Dr. Wagner's monthly
> FAQ.
> 
> Is it possible to provide salt manually?
> Implementing a simple logic may allow re-generating the original header
> in case something bad happens, but I admit it makes sense keeping
> backups of lhdrs somewhere safe.
> 
> Thanks,
> Miklos
> 
> On 12/02/2010 11:28 AM, Miklos Bagi wrote:
> > Hi all,
> >
> > I'm hoping to get directions with a 'small' recovery task.
> >
> > Given a partition that's known to be a broken LUKS one, lhdr is missing
> > (incl magic, chipher, hash, uuid, etc.), however there are some facts known:
> > - chipher: aes-cbc-essiv:sha256
> > - keysize: 256 bits
> > - offset: 2056 sectors
> > - most importantly: we have the master key file available.
> >
> > I have the suspicion that the first approx 10% of the partition have
> > been overwritten with random data.
> > What are the chances of recovering any data in the given scenario?
> >
> > Thanks in advance,
> > mB
> >
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

Re: [dm-crypt] Is partial LUKS recovery possible?

[Nargis Khan]

Kindly unsubscribe me from the mailing list

________________________________________
From: dm-crypt-bounces@saout.de [dm-crypt-bounces@saout.de] On Behalf Of Arno Wagner [arno@wagner.name]
Sent: Thursday, December 02, 2010 11:09 PM
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Is partial LUKS recovery possible?

Hi Miklos,

the salt is key-grade material, so without salt, you are
about in the same situatuion as you are without master key.
Basically everything in the header can be re-created but
the salt, and therefore recovery without header is not possible.

It is not that intuitive, but salting itself is not intuitive
at first glance. Salts only work if they are non-predictable
and that is just the condition that a key must fulfill.

So, sorry, but without header backup you data is gone and
that is by design. Hopefully these disasters will get
less frequent now that the FAQ is part of the cryptsetup
distribution.

I think I will add an explanation to the FAQ about what
a salt is and how it is integrated in LUKS. This will
hopefully make things even clearer.

Gr"usse,
Arno



On Thu, Dec 02, 2010 at 01:15:52PM +0100, Miklos Bagi wrote:
> Apologies for replying my own post.
>
> I believe I found the not so happy answer for me in Dr. Wagner's monthly
> FAQ.
>
> Is it possible to provide salt manually?
> Implementing a simple logic may allow re-generating the original header
> in case something bad happens, but I admit it makes sense keeping
> backups of lhdrs somewhere safe.
>
> Thanks,
> Miklos
>
> On 12/02/2010 11:28 AM, Miklos Bagi wrote:
> > Hi all,
> >
> > I'm hoping to get directions with a 'small' recovery task.
> >
> > Given a partition that's known to be a broken LUKS one, lhdr is missing
> > (incl magic, chipher, hash, uuid, etc.), however there are some facts known:
> > - chipher: aes-cbc-essiv:sha256
> > - keysize: 256 bits
> > - offset: 2056 sectors
> > - most importantly: we have the master key file available.
> >
> > I have the suspicion that the first approx 10% of the partition have
> > been overwritten with random data.
> > What are the chances of recovering any data in the given scenario?
> >
> > Thanks in advance,
> > mB
> >
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
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@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

Re: [dm-crypt] Is partial LUKS recovery possible?

[Mario 'BitKoenig' Holbe]

Miklos Bagi <miklos.bagi@mbjr.hu> wrote:
> Given a partition that's known to be a broken LUKS one, lhdr is missing
[cipher, keysize, offset]
> - most importantly: we have the master key file available.

Well, since you know cipher, keysize, offset and the master key, you
should be able to set up the dm-crypt device manually without the help
of LUKS via `cryptsetup create'.

> I have the suspicion that the first approx 10% of the partition have
> been overwritten with random data.
> What are the chances of recovering any data in the given scenario?

If your suspicion is true, your chances to recover anything primarily
depend on the filesystem type you created on top of the crypted device.
Try to find a superblock backup and try to recover the filesystem.

No need to mention: Keep the original data safe and unmodified, base
your recovery attempts on image-copies only.


regards
   Mario
-- 
Gib einem Hungrigen einen Fisch, und er ist fuer einen Tag satt.
Zeig ihm, wie man angelt, und er poebelt Dich an, dass er besseres
zu tun haette, als Schnuere ins Wasser haengen zu lassen.
                              -- David Kastrup in de.comp.text.tex

Re: [dm-crypt] Is partial LUKS recovery possible?

[Miklos Bagi]

Hi Mario,

Gave this a try, cryptsetup create worked fine as suggested.
FS is XFS, there are a number of superblock backups, but can't seem to find one.

Does salt get generated out of this info, or is it something totally random?

Thanks,
Miklos

> Well, since you know cipher, keysize, offset and the master key, you
> should be able to set up the dm-crypt device manually without the help
> of LUKS via `cryptsetup create'.
>If your suspicion is true, your chances to recover anything primarily
>depend on the filesystem type you created on top of the crypted device.
>Try to find a superblock backup and try to recover the filesystem.

>No need to mention: Keep the original data safe and unmodified, base
>your recovery attempts on image-copies only.

Re: [dm-crypt] Is partial LUKS recovery possible?

[Mario 'BitKoenig' Holbe]

Miklos Bagi <miklos.bagi@mbjr.hu> wrote:
> Gave this a try, cryptsetup create worked fine as suggested.
> FS is XFS, there are a number of superblock backups, but can't seem to find one.
> Does salt get generated out of this info, or is it something totally random?

Mh, I'm not really sure what you mean with "salt" here.

To set up a dm-crypt mapping you need a (block)cipher, a key, and a
(underlying) device.
If you set up a CBC-ESSIV (Encrypted Salt-Sector IV) cipher, there is
something like a salt (although this is more or less a misnomer)
involved, but this is deduced from the key.
So, you don't need an explicit salt to set up a dm-crypt mapping if you
know the key (called master key in LUKS context).

Furthermore, there are two salts involved with LUKS:
The first one is the salt used to derive the master key from a
passphrase. This one is stored in the respective key-slot. You don't
need this salt if you don't need to derive the master key from the
passphrase.
The second one is the so called master key salt used together with the
master key digest to verify the master key derived from a key slot is
correct. Needless to mention you don't need this as well if you know the
master key already.

Hence, if you *really* have the master key as you pretended, you don't
need a salt.

Thus, I'm not sure if you really have the master key.
Please tell us from where you have that what you think is the master
key.
Just as a hint: the master key is shown as hex string with
`dmsetup --showkeys table'. If you have it from there, you need to
convert it back to binary before feeding it to `cryptsetup create' via
--key-file.

It is not easy to check if your dm-crypt mapping is correct (i.e. feeded
with the correct key, the correct device offset, etc.) if, like in your
case, there is damage in the beginning of the partition - that decrypts
to more or less random data and thus doesn't let you easily verify the
correctness of your mapping.
If you know something about the data stored on the crypted device, you
could check the decrypted data for it. If, for example, you know there
should be ASCII data, you could browse the decrypted image for readable
text - it is very unlikely to decrypt something to readable text with
the wrong key. If, for example, you know there should be pictures, you
could try forensic tools like photorec, foremost or scalpel to see if
they find something that appears to make sense.


regards
   Mario
-- 
There are 10 types of people in the world:
Those who understand binary, and those who don't...

Re: [dm-crypt] Is partial LUKS recovery possible?

[Milan Broz]

On 12/02/2010 04:45 PM, Mario 'BitKoenig' Holbe wrote:

> It is not easy to check if your dm-crypt mapping is correct (i.e. feeded
> with the correct key, the correct device offset, etc.) if, like in your
> case, there is damage in the beginning of the partition - that decrypts
> to more or less random data and thus doesn't let you easily verify the
> correctness of your mapping.

If you know, that there was an fs, it is easy, just run
blkid -p /dev/mapper/<cryptdevice>
and it should detect fs signature.

Milan

Re: [dm-crypt] Is partial LUKS recovery possible?

[Mario 'BitKoenig' Holbe]

Milan Broz <mbroz@redhat.com> wrote:
> On 12/02/2010 04:45 PM, Mario 'BitKoenig' Holbe wrote:
>> It is not easy to check if your dm-crypt mapping is correct (i.e. feeded
>> with the correct key, the correct device offset, etc.) if, like in your
>> case, there is damage in the beginning of the partition - that decrypts
> If you know, that there was an fs, it is easy, just run
> blkid -p /dev/mapper/<cryptdevice>
> and it should detect fs signature.

Nope. blkid just probes the primary superblock, which is damaged if the
beginning of the partition is damaged.


regards
   Mario
-- 
It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories instead of theories
to suit facts.                   -- Sherlock Holmes by Arthur Conan Doyle

Re: [dm-crypt] Is partial LUKS recovery possible?

[Milan Broz]

On 12/02/2010 05:28 PM, Mario 'BitKoenig' Holbe wrote:
> Milan Broz <mbroz@redhat.com> wrote:
>> On 12/02/2010 04:45 PM, Mario 'BitKoenig' Holbe wrote:
>>> It is not easy to check if your dm-crypt mapping is correct (i.e. feeded
>>> with the correct key, the correct device offset, etc.) if, like in your
>>> case, there is damage in the beginning of the partition - that decrypts
>> If you know, that there was an fs, it is easy, just run
>> blkid -p /dev/mapper/<cryptdevice>
>> and it should detect fs signature.
> 
> Nope. blkid just probes the primary superblock, which is damaged if the
> beginning of the partition is damaged.

Ah so, I should read it properly.
You can probably use offset option in blkid, so it scans for backup superblock
but that is not so easy.

Milan

Re: [dm-crypt] Is partial LUKS recovery possible?

[Mario 'BitKoenig' Holbe]

Milan Broz <mbroz@redhat.com> wrote:
> Ah so, I should read it properly.

:)

> You can probably use offset option in blkid, so it scans for backup superblock
> but that is not so easy.

Yes. If you know it's XFS, it's more easy and less error-prone to do
what Miklos did - just use xfs_repair which seeks for superblock backups
automagically - a far less error-prone approach (i repeat: kids, don't
do this at home^W^W on your original data, always use copies for
recovery attempts).

However, since that didn't succeed, which can have multiple reasons, I
suggested other ways to find out whether the mapping (i.e. key) is good
or not.


regards
   Mario
-- 
Jene, die grundlegende Freiheit aufgeben wuerden, um eine geringe
voruebergehende Sicherheit zu erwerben, verdienen weder Freiheit noch
Sicherheit.
                                     -- Benjamin Franklin (1706-1790)

Re: [dm-crypt] Is partial LUKS recovery possible?

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]

On Thu, Dec 02, 2010 at 10:44:25PM +0100, Miklos Bagi wrote:
> > Mh, I'm not really sure what you mean with "salt" here.
> >
> > To set up a dm-crypt mapping you need a (block)cipher, a key, and a
> > (underlying) device.
> > If you set up a CBC-ESSIV (Encrypted Salt-Sector IV) cipher, there is
> > something like a salt (although this is more or less a misnomer)
> > involved, but this is deduced from the key.
> > So, you don't need an explicit salt to set up a dm-crypt mapping if you
> > know the key (called master key in LUKS context).
> Correct, this I can check when I luksDump my partition information: MK
> bits, MK digest, MK salt.
> The one I was talking about is in a key slot (same luksDump provides the
> info), and comes with iterations, key material offset and AF stripes.
> When I initialize my partition with cryptsetup --create, I see no way
> determining whether these details are matching, so I might be "reading"
> the whole partition wrong.
...
> I sense there might be a diff in terminology here. By master key I mean
> the one particular file provided to cryptsetup luksFormat <my_device>
> <key_file>, and used primarily to provide better security and at the
> same time avoid the requirement to enter passphrase.

All right, then we indeed have a difference in terminology here. Since
you explicitely claimed to "have the master key file available" I
assumed you were aware of the terminology.

What you have is not the master key but a key to unlock a LUKS keyslot,
i.e. a key the master key is derived from. The information you claimed
to have in your first mail (chipher, keysize, offset, and key file) are
not sufficient in this case.
To derive the master key (used to en/decrypt your data) from your key
you mandatorily need the salt and iterations of the respective key slot.
If you don't have that, you are definitely lost.

However, when you can luksDump your partition information (as you state
above) or when you have an older luksDump output available, you have all
the information required to restore the LUKS header, including the
mentioned salt and iterations.

On Thu, Dec 02, 2010 at 10:53:24PM +0100, Miklos Bagi wrote:
> I've been playing around with setting it up a couple of ways, no luck yet.
> The one most looking like the most "valid" to me at this stage is:
> #cryptsetup create crypt-test-sda1 /dev/sda1 -d <keyfile> -o 2056
> cipher, keysize, etc are detected properly - but xfs finds no supblock.

`cryptsetup create' does not detect anything, it just uses default
values for all the parameters you did not specify explicitely.
And the mappings it creates do all look equally "valid" - i.e. the
mapping it creates decrypts your partition to something... mostly more
or less random looking data.


PS: I re-added dm-crypt@ back to CC:

regards
   Mario
-- 
I've never been certain whether the moral of the Icarus story should
only be, as is generally accepted, "Don't try to fly too high," or
whether it might also be thought of as, "Forget the wax and feathers
and do a better job on the wings."            -- Stanley Kubrick

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]