DRAM data persistence

I remember years ago hearing about a security problem with DRAM, that data could partially persist in the DRAM cells through a power-off/ power-on cycle and might be retireved by careful application of power and reading of the DRAM contents. Does anyone remember details of this?

Reply to
Richard Henry
Loading thread data ...

Ages ago (30++years?), when RAM was PMOS, one of the Intel chips (needed 3 supplies, the rest i do not remember) was so well made that selected chips could store data for a few days without power. The cells were huge compared to anything made today,and that size was one factor that made such long-term storage possible. These daze, the only places where data is persistent, is the BIOS CMOS chip and the hard drive(s).

Reply to
Robert Baer

I have also seen it happen in static RAM. The data bits are not accurately remembered but there is a strong bias towards them waking up in the same state they were at power down.

I guess if someone can have access to the RAM every night after you go home, they may be able to reconstruct something of what you work on during the day.

Reply to
MooseFET

This is in fact an attack on crypto systems using CMOS memories. A little ionizing radiation helps things along. ;-) For things like crypto keys it's fairly easy to thwart the attack by flipping bits.

--
  Keith
Reply to
krw

Any suggestions on how to clear the remnants if one does not have the time to overwrite the whole memory?

Reply to
Richard Henry

Not with generic memory. If you are worried about a security critical application, the only secret should be a relatively small key, so you probably don't need to overwrite all memory, just the key storage.

DRAMs are normally specified to maintain storage reliably for 2ms between refresh cycles. This is of course at the limits of the process, temperature and voltage ranges. Under less extreme circumstances, the memory can easily maintain some bits over minutes, even hours. This can be further improved by getting them down to cryogenic temperatures.

With some SRAMs, there is some sort of burn-in effect, where if the same content is stored over a long time, there is a slightly over 50% chance that the bits flip back to this state after a power cycle.

To avoid this, it could help to add a frequently changing random 'salt' to the key storage. The idea is to store a random number (the salt) followed by the key which is scrambled with this salt. This doesn't increase the key security as such, but it avoids the burn-in.

There are special memories for key storage that have asymmetric SRAM memory cells, which guarantee a specific state at power-on.

Kind regards,

Iwo

Reply to
Iwo Mergler

Richard Henry wrote: ...

You may want to take a look at the DS3600 secure supervisor.

Reply to
Andy F Z

If the data were encrypted, there wouldn't be any concern.

Reply to
Richard Henry

On DRAMs, the RAS-MA-CAS circuit can cause the memory to get muddled if it is done wrong. You could consider adding a special mode to it that is activated during the power off. On the old multiple power supply chips, you could apply a reverse current onto the substrate pin after the other power lines were taken to zero.

More modern methods require explosives.

Reply to
MooseFET

This is not true. encrypted data must be decripted to be used. If that decription happens in software, the RAM that is used by the software is the target.

Reply to
MooseFET

I was speaking about my particular problem, not the general case. The data in the DRAM is not encrypted. The ability to recover the DRAM contents after a power ccycle will compromise the data.

Reply to
Richard Henry

We found an Air Force document that recommends three levels of security:

5.6.1. Clearing. Remove all power, including batteries and capacitor power supplies for the RAM circuit board for a minimum of 60 seconds. 5.6.2. Sanitizing. If RAM is functioning, clearpurge these storage media as follows: 1) overwrite all locations with binary zeros (i.e., 0000 0000), then with binary ones (i.e., 1111 1111), then with a random character; 2) remove power, (including batteries and capacitor power supplies from RAM circuit board. If RAM is not functioning, sanitize as follows: 1) perform three power on/off cycles (60 seconds on, 60 seconds off each cycle at a minimum); 2) remove all power, including batteries and capacitor power supplies from the RAM circuit board. 5.6.3. Destroying. Smelt, incinerate, disintegrate, or use another appropriate mechanism to insure the media is physically destroyed
Reply to
Richard Henry

I doubt it. Any modern OS clears the memory before freeing it for use by other tasks. This is done to prevent security leaks. Shutting down the computer frees all memory so all memory is cleared before you can read it.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

On a sunny day (Tue, 03 Jul 2007 17:46:11 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

This is not correct.

There are 2 ways to claim memory, and 'malloc()" is the usual way: - Function: void * malloc (size_t SIZE) This function returns a pointer to a newly allocated block SIZE bytes long, or a null pointer if the block could not be allocated.

The contents of the block are undefined; you must initialize it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ yourself (or use alloc' instead; *note Allocating Cleared Space::).

Function: void * calloc (size_t COUNT, size_t ELTSIZE) This function allocates a block long enough to contain a vector of COUNT elements, each of size ELTSIZE. Its contents are cleared to zero before alloc' returns.

So normally _nothing_ is done, only processes are killed on power down.

The other issue is that for DRAM I think it is highly unlikely data can be reliably restored, if if you took out the DRAM modules and had a special setup to look at these, but perhaps. Much more important is 'swapspace' as it is on disk, and likely a lot of data is still there. Then some modern laptops have a sleep state where _nothing_ is erased, or even the workspace copied to disk, to be read back in later. And now we are moving towards FLASH drives and even FLASH memory, where NOTHING is erased, you switch the PC off, and days later on again, and it continuous where it was. Solution is disk encryption, but FLASH will hold data for a hundred years.. Writing other data to disk sectors in swap space takes too much time to do on power-down (may be a gigabyte or more). These is no such thing as 100% security.

free() does not clear memory, it only changes a pointer table.

- Function: void free (void *PTR) The ree' function deallocates the block of memory pointed at by PTR.

All memory is cleared in DRAM because refresh and reads stops,

These are just a few issues... there are many more.

Reply to
Jan Panteltje

Does "any modern OS" include any version of Windows?

Reply to
Richard Henry

On Tue, 03 Jul 2007 18:22:31 +0000, Jan Panteltje wrote: ...

So, those FLASH chips they made in 1907 are still retaining their data, right? ;-)

Cheers! Rich

Reply to
Rich Grise

Here are some papers about getting data out of powered-off SRAM and erased flash microcontrollers:

formatting link
formatting link

Couldn't find anything about DRAM.

Chris

Reply to
Chris Jones

Obviously not under the rules.

Reply to
MooseFET

Did you actually ever have sex with Josephine?

Reply to
panteltje

This is very correct otherwise there would be a huge security hole.

You are qouting the C specification. This doesn't mean it is implemented that way it just tells you you must expect rubbish. But like I said, to be absolutely sure no data can be shared between different tasks unintended, any data used by an application is cleared (this does not necessarely mean made 0) by the OS before it is returned to the memory allocation pool.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.