Maker Pro
Maker Pro

DRAM data persistence

R

Richard Henry

Jan 1, 1970
0
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?
 
R

Robert Baer

Jan 1, 1970
0
Richard said:
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).
 
M

MooseFET

Jan 1, 1970
0
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?


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.
 
K

krw

Jan 1, 1970
0
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.
 
R

Richard Henry

Jan 1, 1970
0
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.

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

Iwo Mergler

Jan 1, 1970
0
Richard said:
Any suggestions on how to clear the remnants if one does not have the
time to overwrite the whole memory?

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
 
A

Andy F Z

Jan 1, 1970
0
Richard Henry wrote:
....
Any suggestions on how to clear the remnants if one does not have the
time to overwrite the whole memory?


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

Richard Henry

Jan 1, 1970
0
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.
If the data were encrypted, there wouldn't be any concern.
 
M

MooseFET

Jan 1, 1970
0
Any suggestions on how to clear the remnants if one does not have the
time to overwrite the whole memory?


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.
 
M

MooseFET

Jan 1, 1970
0
If the data were encrypted, there wouldn't be any concern.


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.
 
R

Richard Henry

Jan 1, 1970
0
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.
 
R

Richard Henry

Jan 1, 1970
0
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.- Hide quoted text -

- Show quoted text -

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
 
N

Nico Coesel

Jan 1, 1970
0
MooseFET said:
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.

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.
 
J

Jan Panteltje

Jan 1, 1970
0
I doubt it. Any modern OS clears the memory before freeing it for use
by other tasks.

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.


This is done to prevent security leaks. Shutting down
the computer frees

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 so all memory is cleared before you can
read it.

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

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

Richard Henry

Jan 1, 1970
0
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.

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

Rich Grise

Jan 1, 1970
0
.
Solution is disk encryption, but FLASH will hold data for a hundred
years..

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

Cheers!
Rich
 
C

Chris Jones

Jan 1, 1970
0
Richard said:
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?

Here are some papers about getting data out of powered-off SRAM and erased
flash microcontrollers:
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-536.html
http://www.cl.cam.ac.uk/~sps32/DataRem_CHES2005.pdf

Couldn't find anything about DRAM.

Chris
 
N

Nico Coesel

Jan 1, 1970
0
Jan Panteltje said:
This is not correct.

This is very correct otherwise there would be a huge security hole.
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.

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.
 
Top