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

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



On Mon, Oct 31, 2011 at 11:17:57PM +0100, Jonas Meurer wrote:
> Am 31.10.2011 08:18, schrieb Arno Wagner:
> > In addition, any kind of automatic header backup breaks the LUKS
> > security model and needs to come with a very clear warning if
> > automatized (as in an installer). The problem is that old
> > passphrases will be stored and will survive deletion in the active
> > LUKS header. That is not good at all.
> 
> While I agree with you, that cryptsetup already does a lot to prevent
> data (i.e. header) loss, I don't see a reason why (optional) header
> backup at some random place on the device would be such a big security
> problem.

And here is the problem. If it is optional, it will not help
in a careless installer. A fareful installer can offer to do 
a backup already, using "cryptsetup luksHeaderBackup". It can
also check whether something is a LUKS device via 
"cryptsetup isLuks". 

I really don't think this is a cryptsetup issue, excapt maybe
that the documentation (mostly the FAQ and man-page) could 
warn more. But I think looking into the FAQ is non-optional
and I have no idea how to make the warnings even clearer.
Especially somebody doing an installer that can do LUKS
should read the FAQ!

> For sure the exact place of backup header would be stored in the first
> header, and any cryptsetup action which changes/whipes (parts of) the
> header, would need to do this for the backup header as well.
> 
> Overwriting the first kbytes of device would no longer be sufficient.
> Instead overwriting the header would require to actually overwrite
> both first and backup header. But that's the only drawback I can see
> so far.
> 
> I guess that I missed something important.

In principle that could work. However there is good reason to place
the header at the start, so the backup would need to go right after 
it. This would decrease LUKS anti-forensic strength. In order to
keep passphrases secure, both headers would always need to be 
synchronized. This would make things perceptibly slower. Usability
(and speed) is very important in cryptographic tools, after all
a tool that is not used because people do not like it can never
offer any security improvement.

Then there are the ways people damage their header. One is putting 
a FAT filesystem on top. Now, say your FAT filesystem is 4GB in
FAT32. Then clsuter size would be 4kB, i.e. around 1'000'000 clusters.
This givesd a size of the actual FAT table of 4MB which is stored twice,
i.e. 8MB. The LUKS header is 1MB (or 2MB with xts). So the
FAT table gets wiped together with its backup. 

Another option would be to place the header at the end of the 
device. But this would be problematic for several reasons. One
is that it is certainly a bad idea to replicate the incredible
mess the md people have made with their headers. An other is that 
fast header wiping becomes hard. A third is that device resizing 
becomes hard. And a fourth is that suddenly LUKS would need to 
know about device sizes.

The other thing is that all this would not help for the installer 
problem, as an installer would definitely need to wipe the backup 
as well on creating a new LUKS container. For an installer, the 
only real solution is to clearly warn the user and possibly do that
header backup inless the user explicitely says no. And, as said 
above, it is easy to detect whether there is already a LUKS 
container on a device.

At this time the FAQ even has a warning at the beginning that some
installers are not clear enough on what they are doing. I guess
somebody wanting to be careful when creating an installer has
all the help needed (and can definitely ask here as well!). Somebody
that does not care or does not see the problem will manage to
botch it anyways and there is not really anything cryptsetup can do.

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


[DM Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

Add to Google Powered by Linux