[Gloucs] How to rescue data from a encrypted filesystem

[Matthew Booth]

On Wed, 2007-09-26 at 10:44 +0100, Nick wrote:
> > Just of curiousness: I have a encrypted partition now running which is
> > password protected. In case the PC does not start I could rescue the
> > data of a non encrypted partition with a Live CD. This is not possible
> > obviously for a encrypted partition. Is there a similar solution eg.
> > to mount the encrypted partition from a Live CD and after giving the
> > correct password to have fully access to it and to rescue the data?
> 
> How's it encrypted? If it's LUKS, then so long as the livecd has
> support for the cipher you chose, the kernel has dm-crypt support, and
> there's a copy of cryptsetup-luks in easy reach, you should be able
> to mount it without problem with something like:
> 
> cryptsetup luksOpen /dev/hda2 rescue
> <enter password>
> mount /dev/mapper/rescue /mnt/rescue
> 
> Of course, if the partition was damaged in some way, then I don't
> expect you could get anything from it at all.

This is a shortcoming of LUKS that makes me very nervous, specifically
that the encryption header isn't replicated on the device in the way
that, for example, an EXT superblock is. The developer claims that it's
not required because you can use RAID, but this misses a couple of major
points:

* RAID is a big hammer. Losing a single sector shouldn't lose your
entire filesystem.

* RAID won't protect you from a wayward tool which overwrites the
encryption header. It'll faithfully overwrite all your copies too.

I suspect the real reason is simplicity of implementation. However, as
the developer takes pains to point out, LUKS is a data format definition
with a reference implementation. Defining the standard with such an
obvious deficiency seems incredibly short sighted to me.

That said, I still use LUKS. It just makes me nervous.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.lug.org.uk/pipermail/gloucs/attachments/20070928/07048af2/attachment.bin