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?
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).
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.
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.
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.
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.
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.
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.
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
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
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.
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
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.