Rookie question - Data Remanence

Deskguy

Very much a rookie with the Prop. However, I want to work on a program that will eventually be stored, as usual in EEPROM. Then, when the program runs, of course, variables will be created etc.

Question is - once the power is shut off, am I correct in assuming that nothing is 'stored' anywhere, and that given a 'reasonable' amount of time under 'normal conditions', then the working memory would be empty.

Of course, I'm probably not wording this well, but hopefully you get the gist if you look at the following couple of links:

http://en.wikipedia.org/wiki/Data_remanence



I'm assuming that the memory is nicely cleared after power is lost, just curious if there are any gotchas that I should know about.

Thanks,

David

Phil Pilgrim (PhiPi)

There's no data remanence unless you save it in EEPROM during execution. Upon powerup (or any reset), RAM is then reloaded from EEPROM.

-Phil

Mike Green

Have a look at the Basic_I2C_Driver from the Propeller Object Exchange (link on main Parallax webpage).· It provides some simple routines for writing (and reading) EEPROM including the unused portions of the one your program is stored in.

Deskguy

I don't suppose anyone has ever tested the type of RAM to see how long any data remains after the power is lost?

So, just as long as I don't write anything to the EEPROM at run-time, then there should not be run-time data kicking around after the power is lost, other than what might happen based on techniques as shown in the video? (for example, freezing the memory etc).

Any guesses as to how long it would take for the memory to be wiped? The video from Princeton shows about 2 minutes after powering down for the RAM to be cleared. Of course, that is on a PC, and no doubt different type of RAM.

No doubt, there is a handy way to test this, but it will take me putting on my thinking cap and trying to figure out the best methods of trying to consistently determine the results. Just trying to figure out if I want to go down the prop route for a project that I have in mind.

Thanks again,

David

BradC

Deskguy said...
I don't suppose anyone has ever tested the type of RAM to see how long any data remains after the power is lost?

So, just as long as I don't write anything to the EEPROM at run-time, then there should not be run-time data kicking around after the power is lost, other than what might happen based on techniques as shown in the video? (for example, freezing the memory etc).

Any guesses as to how long it would take for the memory to be wiped? The video from Princeton shows about 2 minutes after powering down for the RAM to be cleared. Of course, that is on a PC, and no doubt different type of RAM.

No doubt, there is a handy way to test this, but it will take me putting on my thinking cap and trying to figure out the best methods of trying to consistently determine the results. Just trying to figure out if I want to go down the prop route for a project that I have in mind.

Thanks again,

David

Not gonna happen. When the propeller comes out of reset the bootloader kicks in and re-loads the *entire* contents of ram from the eeprom. There is _no_ way any random remnant can be left anywhere.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

Peter Jakacki

Deskguy,

Even on a PC the memory gets overwritten and reallocated so any of this data "remanence" stuff is immaterial. I suppose some people are entertained by it but when it comes to the microcontroller world the startup routine normally zeros all it's working area in RAM. With the Propeller as has been mentioned it doesn't matter to us as all we see is the entire contents of RAM replaced with the contents of the EEPROM. All variables will be zeroed unless you have written the updated values back into EEPROM to automatically restore on power-up.

Go with the Propeller, you will be happy you did.

*Peter*

Deskguy

Thanks for the suggestions and input.

Seemingly the safest route to ensure the memory is fully cleared would be to:

1. Run the program
2. Shut down
3. Fire it up again (to clear the memory)
4. Shut it back down now that the memory is guaranteed clear

I know it is overkill, just trying to watch out for any potential problems.

Thanks.

David

Peter Jakacki

Sorry Dave, I just don't get it. What potential problems? Do you know something we don't or have never come across?

*Peter*

Deskguy

Bit of background - it is a security related application, so retaining anything in memory would be bad.

I've always thought that removing power would actually remove everything from memory. True, but apparently not right away. The example in the video, gives one example of parts of the memory staying for 2 minutes after the power is removed.

There are a number of various side-channel attacks which attempts to attack cryptography through bypassing anything to do with the cryptography. For example, monitoring power consumption during various stages of encryption or decryption, as this can leak information about the key being used. Similarly, one could monitor the amount of time it takes to perform various operations during encryption or decryption. In that case, one isn't trying to 'crack' the encryption by finding a flaw in the cryptography, but rather in some other way of finding leaked out information. For this project, I was only hoping to prevent against any memory retention.

So, my question about memory on the prop is along the same lines. I had assumed that it was fairly normal in comparison to other memory in that it might fade over the course of a few seconds or minutes after power has been removed - just curious if anyone had any data on that. It was a really good point to hear about the entire ram being overwritten on bootup, so a shut-down, and reboot would seem to solve most of my question.

FYI, the video link in the original post (from Pinceton) was pretty cool - in general, it is known as a 'cold boot attack'.

Hope that clarifies - and thanks for your help.

David

BradC

Deskguy said...

FYI, the video link in the original post (from Pinceton) was pretty cool - in general, it is known as a 'cold boot attack'.

Cold boot attacks are really only practical where you can access the RAM directly. I'm sure it's "possible" with the right tools, but it's sure as heck not as easy as whipping a DIMM out of a laptop and reading the remnants.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

Mike Green

You don't really have to get that complex unless the Propeller's package is removed so that you can use something like an electron beam probe on the chip. The internal memory is not accessible from outside the chip, there's no way to get a program into the chip except by using the masked ROM bootloader, and the bootloader always clears the HUB SRAM to zeros from the end of the loaded program through the end of memory. Each cog is always completely loaded from the HUB SRAM before it's allowed to run (and its registers are cleared) and there's no way to read the cog's memory from another cog.

Peter Jakacki

@Mike, I couldn't see where the Prop is actually "clearing" the RAM at reset as it looks like it either runs the serial comms or eeprom boot sequence or failing that it just shutdowns.

@Dave - The eeprom boot is locked into loading the entire 32K bytes of RAM so no chance that any previous data would survive. The cog RAM is also completely overwritten as soon as you load up anything into it so you couldn't find out what it had previously either. I looked at the video and concluded that as cool as the method was with memory modules it just didn't and couldn't apply to on-chip RAM. Besides the software used to locate the information must assume that it is in a identifiable format as is the case with many PC operating systems. Also, the deteriorating image was way too simple as it looked like they were using a simple black & white hires image which closely approximates the individual binary memory cells. The fact that we humans can recognize an image doesn't mean much as we can see faces in ink blots too. Now if they had run the test on a document it would have been instantly unreadable.

Oh, BTW, knowing that you are concerned about security keys would have made your questions and concerns a lot more understandable.

*Peter*

Deskguy

Thanks to all for the extra info - my bad for not being more clear with the project specs at the beginning.

Looks like the prop *is* the right fit for this project - appreciate the help.

David

heater

I can't really see how an attacker is going to get hold of your Prop based crypto widget after it last had some sensitive data in it, remove the chip, de-pot the thing, somehow gain access to the internal RAM and the read said RAM before the contents is garbage.

However I do know that some people/organizations can't sleep at night worrying about such things.

Best put some external circuitry on a pin and use that to trigger a COG, in the last moments before total power down, to clear all internal RAM. There are chips that detect this imminent power failure situation but I'm sure it can be done with a few discreet components.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Peter Jakacki

Hi David, it's been an education for all of us, and I hadn't thought about Prop security hacks before so it looks like the Prop's a winner for this specific type of attack.

@heater - some organizations get paid not to sleep at night [noparse]:)[/noparse]
The power-fail detect normally relies upon detecting a droop in the bulk supply or missing mains cycles and provided that there is enough capacitance in the power-supply the processor can have a few to several 100's of milliseconds to do what it needs to do. Of course from what we have discussed it is a totally unnecessary measure with the Prop.

*Peter*

Mike Green

@Peter
The bootloader can either load a program from an attached PC or copy the first 32K of attached EEPROM. The code that downloads from a PC gets a program size (in longs) from the PC and downloads that number of longs. It then clears the rest of SRAM to zeroes before starting up the loaded program. If there's no attached PC, the bootloader copies the entire first 32K of EEPROM from an attached EEPROM. If there's no attached EEPROM either, the Prop shuts down. The SRAM is unchanged in that case, but there's no access possible.

The ROM bootloader code has been posted and you can see this logic in the code.

Peter Jakacki

Thanks Mike, I had a cursory look at the code but didn't follow the serial part of it through. What you say about the RAM either being loaded or cleared or just plain inaccessible just reaffirms that the Prop is not quite so vulnerable when it comes to this kind of attack. I couldn't see any way of fooling it either.

*Peter*

heater

Yes indeed Peter.

From the static RAM retention paper "Retention times can be significantly reduced by shorting VCC to ground rather than by leaving it floating."

OK I did not read the whole paper but that statement makes me think they were simply disconnecting power to the SRAMs. Well "duh", modern low power device can of course hold themselves up for a while on capacitance if nothing is pulling Vcc to ground.

So arrange to have a resistor across your power supply rails which will ensure Vcc goes to zero eventually. Not helpful if this should be a low power device I know. In which case some kind of power off crowbar on the rails is required.

As for the video. There they were attacking the laptops dynamic RAM. Dynamic RAM is a different kettle of fish than static in that its memory cells are basically capacitors that are either charged or not. Hence the need for periodic refresh cycles to replenish the leaking charge.

So I would guess that even if the supplies go down to zero there is more chance of the data remaining with dynamic RAM.

So is the Props RAM dynamic or static? I would have guessed static.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Mike Green

@heater - I believe the whole Propeller is static. I think there's no minimum clock speed.

Peter Jakacki

Dynamic RAM is really just made up of very simple cells which are basically a capacitor on the mosfet gate. The capacitor holds a charge to say zero or one but the charge leaks away slowly (over many milliseconds) so the memory has to be refreshed which is a mechanism to read the current state of a cell and write it back again fully. It is possible for these memory cells to retain some of their charge even if you did remove power and short the supply.

Most RAM in micros is totally static in that it does not need to be refresh but instead relies upon a more complicated back-to-back arrangement much like a flip-flop. I think most static cells require 6 transistors per bit but since it does not require refresh clocking the RAM consumes very little power when not being accessed. Being static means you can stop everything and each memory cell remains latched in it's last state.

These static RAM chips can retain some of their memory for a few seconds (extremely indeterminate) even when they are unplugged as in the case of discrete devices. Shorting out the supply pretty much puts an end to that though.

*Peter*

heater

Reminds me of a frustrating SRAM failure that was bugging us once. The SRAM passed its RAM test OK. Many programs ran on it just fine. But one did not. We determined to track down the problem. We knew it was the SRAM chip as changing it cured the problem.

Turned out this SRAM had one bit in one byte that thought it was dynamic RAM. Any ones written to it would fade to zero after a few ms. Stayed up just long enough to pass the RAM test.

Lesson of the story?

Turns out that a "simple thing" like testing RAMs is actually a lot more complex than a first thought would have you believe.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Agent420

>Bit of background - it is a security related application, so retaining anything in memory would be bad.

Just curious, but if this esoteric element of 'cold ram' is such a potential issue, I'd almost think you'd want a controller chip that provides some minimal level of code protection as well?· I'd think that reverse-engineering the app would be a similar security risk?· Not to mention the potential of swapping the code eprom with a hacked one.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

heater

Agent420:

Not at all. Lets say your app is some kind of Enigma box. Plain text in, cipher text out or visa-versa. To do this you have to input a crypto key which lives in RAM as long as the machine is on.

Now your attacker gets the box. Hopefully the thing has been powered down when he snatches it. The key is gone. Perhaps he reverse engineers your code. Perhaps he knows very well all about the crypto algorithm you have used anyway. But with out that key he can't use the box to crack your ongoing communications or decipher your past messages.

I am assuming one is not daft enough to blow the cryto keys into EEPROM or such.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Agent420

^ Ok, I see that.· I was thinking along the lines that a hacked eprom might be able to circumvent non-crypto elements.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔