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.
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.
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?)..
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.
Claudio
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
