[dm-crypt] Data recovery

Nico Gevers ingevious at gmail.com
Sun Oct 9 19:17:31 CEST 2011


Hi Arno

Thanks for the help. I'll consider the data lost and move on.

Incidentally, is there any way to recover deleted files from an encrypted
drive. eg, you delete some files (and empty the trash), and then recover
them afterwards. I know there are tools available, but I'm not sure i they
would work on an encrypted drive (while mounted of course). Will encrypting
a drive remove all possibilities of undelete?

On Sat, Oct 8, 2011 at 10:02 PM, Arno Wagner <arno at wagner.name> wrote:

> On Sat, Oct 08, 2011 at 07:42:09PM +0200, Nico Gevers wrote:
> > Hi Arno
> >
> > Thanks for your reply. I made a header backup and had a look at the hex
> > dump. Its about 1.4M so haven't attached it, but can if its useful. The
> > drive was using aes-xts-plain with a 512 bit key. According to the FAQ
> this
> > means that 1st keyslot starts at 0x1000 and runs until 0x3f800. Having
> had a
> > look at the dump, I noticed 0x1000 - 0x13300 was fairly regular, and from
> > 0x14000 the dump looked quite random until the end of the keyspace. I
> guess
> > that means I've lost some of the key.
>
> Actually, you lost the full key, due to the anti-forensic properties
> of LUKS key storage. Hanginf a few bits anywhere in the keyslot is
> enough to make the master-key irrecoverable. This is by design.
>
> No idea what overwrites 0x1000-0x13300, except possibly the
> fdisk-run...
>
> > Excuse my ignorance here, but wouldn't it be possible (in my case) to
> > reverse engineer the data in the keyslot, since I know the original key
> as
> > well as the iterations and salt value. Could I not regenerate the key
> hash
> > and insert it back into the header. I could even check the correctness of
> > the key my matching the last half of the bits to the ones in the existing
> > keyslot.
>
> No. The key that was lost is the master key, encrypted with
> your passphrase and "streched" to the full keyslot size.
> If a reconstruction as you suggest were possible, disabling
> old passphrases would be impossible.
>
> > As for how it happened, I wish I knew. All I remember is one morning
> > starting my machine up and being surprised that the external drive
> wouldn't
> > accept my password. I do remember getting semaphore errors for the first
> > time, and since I'm running ubuntu 11.10 beta, perhaps I did an update
> that
> > might have caused a hassle some where (perhaps a kernel update or an
> update
> > to cryptsetup). I wasn't really paying attention since I didn't
> anticipate
> > anything like this.
>
> Should not cause this. Some versions of Ubuntu have a problem that
> they offer to create new LUKS partitions during install in unclear
> language, leading people to belive their existing LUKS containers
> would be activated, but that is about it AFAIK.
>
> So what you see should not happen. Read errors from the disk
> would also show up differently. Has maybe somebody else had
> access to that disk?
>
> Since you ran fdisk, it is likely impossible to find out anything from
> the change-pattern now.
>
> Arno
>
> > Oh, and here's a dump of the luksDump command. I can attach the header if
> > its useful to anyone.
> >
> > Version:       1
> > Cipher name:   aes
> > Cipher mode:   xts-plain
> > Hash spec:     sha1
> > Payload offset: 4040
> > MK bits:       512
> > MK digest:     1e 01 d1 96 ba 79 cd 9f d1 cd 7f ee 1c e5 e7 51 ed a7 61
> 06
> > MK salt:       60 32 3e 38 42 1f 5c 05 ce 21 d6 27 ad 23 bf 1e
> >                 a7 18 13 a7 75 8f 33 f0 f6 f8 25 da 0c e0 af 60
> > MK iterations: 9125
> > UUID:           5048085d-d798-4b4f-902b-88eb2e71fd88
> >
> > Key Slot 0: ENABLED
> > Iterations:         36805
> > Salt:               25 4b 79 50 a4 0b 26 40 85 48 5c d0 28 1b 42 73
> >                        7b 59 a7 e6 17 81 94 22 c8 45 de 96 b7 bd 8f f1
> > Key material offset: 8
> > AF stripes:             4000
> >
> > <the rest of the keyslots are empty>
> >
> > thanks again
> > Nico
> >
> > On Sat, Oct 8, 2011 at 6:22 PM, Arno Wagner <arno at wagner.name> wrote:
> >
> > > On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote:
> > > > Hi
> > > >
> > > > I've recently decided to encrypt all my drives using luks, running on
> > > ubuntu
> > > > 11.10. I encrypted my external drive, and loaded all my backups onto
> the
> > > > drive. One morning, I tried accessing the drive, and it wouldn't
> accept
> > > my
> > > > key phrase. I tried a couple of times, even tried some variations,
> but no
> > > > avail. Then I stupidly thought of running fsck on the drive. I fixed
> a
> > > > couple of innodes, but then stopped, realising that I was probably
> doing
> > > > more harm than good.
> > > >
> > > > When I run luksDump on that drive, I get all the expected
> information. My
> > > > question is: is the header still intact. Is there any chance I can
> > > recover
> > > > my data, owing to the fact that luksDump displays, what seems to me,
> a
> > > valid
> > > > header? (I'm assuming that if luksDump shows the information, the
> header
> > > is
> > > > intact).
> > >
> > > The header itself may be intact. But the problem here is the keyslots.
> > > If they are damaged, the only thing that can save your data is a header
> > > backup.
> > >
> > > What I wonder is why fsck was even willing to run. Due to the
> encryption,
> > > it will have seen absolutely nothing that looks like a filesystem.
> > > It also is quite possible that it 'fixed' things in the keyslot area.
> > >
> > > In addition, there is the question for the reason fo the initial
> > > fail.
> > >
> > > So, what you do now is make a header backup (procedure is in the
> > > FAQ) und analyse that. First, find out in which keyslot your key
> > > is (likely the first), then look at the FAQ section on on-disk
> > > format and look at the encrypted keyslot with a hex-dump
> > > tool, e.g. hd. If there is anything looking regular in the
> > > keyslot area, apply procedure for dealing with permanent data
> > > loss, also described in the FAQ.
> > >
> > > You can of course ask for further advice here, but it is impossible
> > > to answer your question without looking at that keyslot data.
> > >
> > > Arno
> > > --
> > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> > > arno at 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 at saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt
> > >
>
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt at saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
>
>
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno at 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 at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20111009/a26b5ea0/attachment.html>


More information about the dm-crypt mailing list