On 10/28/2014 10:15 AM, Cpp wrote: > - Does dm-crypt/LUKS employ any RAM anti-forensics? In particular, > what is the danger of a master key being "burnt-in" into the RAM, if a > certain container is mounted for an extended period of time (a few > years)? Is the master key being periodically moved around in RAM (this > acts like a screen-saver or rather a RAM-saver) or does it reside at a > static location after the container is mounted? No. And because dm-crypt just block processing wrapper around kernel crypto API it is more problem in cipher implementation there than in dmcrypt. (IIRC the key is duplicated several times there because of parallel processing on separate CPUs.) But I do not believe this is real problem at all. BTW you can run luksSuspend which should wipe all keys and reinstate them later, this will "refresh" the memory area, at least partially. (BTW If anyone have some reliable papers about this, please send a links, thanks.) > - Is it possible to separate the LUKS header from the encrypted data? > Normally when a partition is luksFormat-ted it will generate a LUKS > header on that partition at the very beginning of space. But I was > wondering, if it's possible to have only the encrypted data on the > partition, and move the LUKS header somewhere else i.e. a file on a > USB stick? Yes. See --header option and "detached metadata" in cryptsetup man. In this mode you should also use data payload offset to 0 bytes, so the data device contains only encrypted data. (Or you can have random data instead on LUKS header area on data device and use separate device or file with LUKS header). Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
