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
