* Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Fri, Jul 17, 2009 at 01:16:04AM +0200, Michael Gebetsroither wrote: >> Adding txt security features from current intel systems you have runtime >> secure boot, so no one will be able to break into your bootsequence. >> >> So it will only be possibel to decrypt the data on exactly this box with >> exactly this initrd+kernel. >> >> Though the attacker can restore the destroyed luks header from backups. > > This is what I am talking about. You can try to destroy > your LUKS header, but it will not work. The only thing you will > accomplish is another round in torture and then another go with > the backup. With todays technology it wouldn't be possible, but be aware that the next round of trusted computing is already specified. The next round completes the cycle as T13 specified a direct binding for the HD to the TPM. So it wouldn't be possible to restore the destroyed header from backup. It would be rather short sighted to not include the possibility, e.g a bitfield per key-slot for the next luks spec. >> The real problem imho is that with this feature you are actively >> destroying evidence. Even trying to to this will get you into _real_ >> problems, instead of just refusing to give out the keys or admit that >> this isn't just random data. > > And LUKS is totally unsuitable for it, as the header > can be clearly recognized. Nobody can prove otherwise if you > use dm-crypt and claim it was with a random key for wiping the > drive. This is still problematic, however. The only real solution > are a true tamper proof module (very hard to do) or that > mythical cyanide pill. Right, unfortunately one feature not supported by luks. It would be very nice to include the possibility of deniability in the next luks (even if this includes the loss of the isLuks/luksUUID functions when this feature is enabled). Hidden volumes would be desireable too, though would require a bit more thinking. >> > Oh, and btw, having cryptographically strong randomness on a drive is also >> > a risk. Come to think of it, I do secure wipoes by mounting with dm-crypt >> > and random password, then overwrite with ordinary prng-randomness. There is >> > no way I can prove I do not have the key or the data was random. But that >> > alone should protect me here. >> >> I usually do a whipe with dm-crypt + random password followed by dd with >> /dev/zero. >> Much less trouble, just in case someone takes a closer look. > > Basically the same thing I do and I doubt it is much less trouble ;-) Last time i checked hd delivers all zeros for unwritten sectors. Though i doubt that written zeros can't be distinguished from factory preset zeros on the pattern level. michael -- It's already too late! --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
