On Wed, Oct 29, 2014 at 10:24:13 CET, Cpp wrote: > 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. While Ross Anderson does really good research and is well respected, that book is not a good book and in particular it is not an engineering book at all! As a collection of background stories, history, interesting phenomena, it does fairly well, but as a guideline to solve problems, it is a complete failure. As an example, moving the data around just means it getting burned in takes a little longer, even if you overwite the old data with crypto-randomness. The SRAM cells are succeptible to usage-bias and that means only the complement of the key, stored for the same time as the key, can erase the effect. (That is for short storage time. For long ones, even that may not be enough.) > 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? Do it simpler. Make one buffer and one flag, and periodically (once a minute or so), do the following: buffer := not(buffer) // bitwise flag := not (flag) // logical. That should be sufficient to prevent the burn-in effect. Key recovery via if (flag) { key := buffer; } else { key := not(buffer) // bitwise } As to your overall security model: You need to ensure that an attacker only gets access to the uC and computer in an unpowered state, or you are screwed (for a resourceful attacker). An ATmega48A may even be known well to a gifted amateur, as something pretty similar is in the Arduinos. It might be exceptionally easy to cause this thing to go into a debug mode, and it may leak the data via TEMPEST. But as a project to learn things, go for it. Arno > 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 -- 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
