I see, thanks for the detailed answer. Personally I find this an interesting topic, and since I love to learn and experiment, I bought a printed copy of Security Engineering (2nd ed.) book by Ross Anderson. I'm currently on chapter 16 - Physical Tamper Resistance, and in this chapter there is a paragraph on page 490, "How to hack a cryptoprocessor (4)", it says that "The better third generation devices have RAM savers which function in much the same way as screen savers; they move data around the RAM to prevent it being burned in anywhere." This is where I got the idea to move the key around in RAM. The thing is I planned to use a microcontroller to store an encryption key in its RAM, and I see the device uses SRAM, so this might be a problem? http://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf But if moving the data around is ineffective then perhaps I could do something like this: Upon device power-on define two equal-length (fixed length) buffers on the heap. Then generate a random number of equal length from a cryptographic random number generator and write it to both buffers. At periodic time intervals (can be configured to 1 hour, 2 hours, 12 hours, 24 hours, etc) generate another random number like before, and XOR it into both buffers (buffer_1 ^= random_num; buffer_2 ^= random_num;). Once the device receives the encryption key, XOR it to *one* of the bufffers (buffer_1 ^= enc_key), and securely overwrite the enc_key variable. At any point in the future when we want to retrieve the key again, simply XOR both buffers to get it, export it, and securely overwrite the variable that held the key. Comments? On 10/28/14, Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Tue, Oct 28, 2014 at 10:15:22 CET, Cpp wrote: >> Hey, >> >> I've got two questions abour dm-crypt/LUKS. >> >> - Does dm-crypt/LUKS employ any RAM anti-forensics? > > No. And not really needed anyways. This is for > disk encryption, not for building a HSM (Hardware > Security Module). Keys get wiped unmapping though. > >> 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? > > That is potentially a concern with SRAM. DRAM may or may not be > subject to similar effects, but they are not as easy to detect or > use. Basically, you will have to lower refresh-rates until bits > fail and carefully monitor which ones will fail. Even that may > not be conclusive at all, as cells are different. The > thing with SRAM is that both transistors in the flip-flop > are very similar, as they are very close together. An SRAM cell > may tend to come up in the state it has held for a long time. > A DRAM cell will always come up the same way, regardless of > what value it held, namely with capacitor empty. > > AFAIK, the it is not even clear whether this still is an > issue in modern SRAMs. The only references I found on googeling > are describing this effect in the presence of a lot of > ionizing radiation for SRAM and I did not find a single > source for a similar effect for DRAM. > > Here is a current reference on that, the literature may give > you more info: > https://repositories.tdl.org/ttu-ir/bitstream/handle/2346/58641/NAIR-DISSERTATION-2013.pdf > > Note that the radiation doses this work looks at start at > 100R and go up to 100kR. About 200R are reliably deadly for > humans. > > There are also devices like the DS3640 that claim to prevent this, > but it would not be the first time that a manufacturer advertises > "preventing" things that are not there in the first place: > http://www.maximintegrated.com/en/products/power/supervisors-voltage-monitors-sequencers/DS3640.html > > BTW, you do _not_ move the key around to fight this. That > would not help. You complement all bits regularly instead. > >> - 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? > > See man-page and FAQ items 5.19 and 6.2. In the case of FLASH > disks, it is actually a good idea to do so. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 > ---- > A good decision is based on knowledge and not on numbers. -- Plato > > 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 > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
