Re: please HELP - can't acces encrypted LVM after linux reinstallation.

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

 



On Tue, Nov 01, 2011 at 12:46:57AM +0100, Claudio Moretti wrote:
> > I don't suggest to hide the backup header. In fact the exact place of
> > it should be obvious (either fixed, or better: random but written to
> > the first header). Thus the second header is as obvious as the first
> > one. Only difference: it's not at the beginning of the device.
> > Unfortunately the first sectors of a device are overwritten much more
> > often than later sectors.
> >
> >
> AFAIK, the LUKS header is not on the beginning of the partition, but it's
> distributed in it; there's a piece of it at the beginning (the "0x0A L U K
> S" part) but the rest is not there (because of anti-forensic stuff).. That
> said, if you overwrite the beginning of the disk (or it gets corrupted) you
> damage data that cannot be reconstructed, so you lose access to the disk.

Ah, no. There is a bit of padding between header and keyslots (and
between the keyslots), but besides that the whole structire is at
the start of the device. Higly recoomended: FAQ entry "What does the 
on-disk structure of LUKS look like?" in FAQ section 6.
 
> > I see that a backup header - which for sure needs to be overwritten by
> > new luksFormat - wouldn't prevent accidents like the one explained in
> > the first message to this thread. Only in cases where people
> > accidently overwrite the first sectors of a luks device, this kind of
> > backup header could prevent data loss.
> >
> 
> True, and that can be done: the header is not big, so there should be no
> problem in doing this. But if I'm right, and the header is in a
> unknown-but-reconstructable position (i.e. with the right passphrase, you
> access the right positions for keyslots/master key), doing so would expose
> the entire header: one simply has to look for identical data on the disk
> (if your header is - for example - "0x0123456789abcdef", an attacker that
> finds two occurrences of "0x0123456789abcdef" on the disk may assume that
> this is your header) and your anti-forensic measures are gone.

Sorry, but no. See above. Placing the header in a non-static location
would not even hide it. Encrypted data is pretty easy to identify.

> Also, suppose you have something really really secret on your LUKS disk, so
> secret that you'd rather lose it than admitting you have it; if you don't
> have a header backup on the disk, you should simply overwrite something
> like 1KB of data on your disk (and running dd if=/dev/urandom of=/dev/sdX
> ensures you can do it instantly: no way one can stop it in time) and you're
> safe. If there's a header backup somewhere, and you don't know where, how
> can you do it? dd-ing the entire disk takes hours, even with a "small" one
> (80GB?)..

That is indeed a concern. However for "really, really secret" better
use plain dm-crypt. Although "plausible deniability" sounds nice in
theory, it does not really work in practice. 
See FAQ and http://xkcd.com/538/

> Better idea is: you advise your users to backup their header (like
> Truecrypt does with its "boot rescue disk" or something) and you provide a
> stupid-proof procedure to do it (like modifying partman in every
> distribution to be able to create a header backup on an external disk or
> something..
> But that's something that should be done from distribution mantainers, not
> from cryptsetup itself.

I don't know what a distribution installer should do, but if it is
LUKS aware, it should check every partition to be written to for a 
present LUKS header before and warn very, very clearly that no, the
LUKS header is not going to be "activated", it is going to be killed!

The Ubuntu people had that problem already (no idea whether it is 
fixed by now) and now something similar in Debian. I do not even 
stricly see the installer people at fault. It seems people are very 
much used to software doing things right "automagically" these
days and mentally map "LUKS header creation" not to "disaster" but 
to "my existing LUKS container is to be included into the distros 
automation". When in a hurry/tired/distracted, this then leads 
to said disaster. 

The fix is a very clear question "Do you rally want to LOSE ALL 
DATA in the LUKS container?" to be answered, e.g., with an uppercase 
"YES" as cryptsetup does it.

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