On Fri, Jul 17, 2009 at 10:23:57AM +0200, Michael Gebetsroither wrote: > * 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. I have now followed this TPM idea for something like a decade. So far they have not produced anything really practical. The idea is sound, but as soon as an implementation becomes usable, DRM raises its ugly head and the thing falls apart again because nobody wants it. > It would be rather short sighted to not include the possibility, e.g a > bitfield per key-slot for the next luks spec. What for? If the HDD is tried to the TPM, have the HDD do the encryption and do without LUKS. LUKS is for software only and not a TPM replacement. > >> 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. Again, wrong system. LUKS does not try to hide. You can look at TrueCrypt, which already does this to some degree. Note however, that perfect hiding is not really possible as long as you require some level of usability. After all the passphrase has to be input at some time and you should also get an error if it is wrong (after some time to slow down brute-forcing). Anyways, the clsoest thing to deniability a partition encrypter without steganography can give you is already there: Just use plain dm-crypt. Also, even having an effective TPM and not disclosing its keys could get you thrown in jail in some places. If this really is secure, it could just lead to the hardware being outlawed in some countries. If not, I would strongly suspecty there is a backdoor. > >> > 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. Ah, so you mean you do zero the raw partition afterwards. Well, if you live in those countries, this may be a good idea. Personally, I don't bother. Peter Gutman does recommend random data overwrites and so I can justify them ;-) 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 - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
