Pardon the double post, but I'm not getting much traction with this question over at arduino.cc so I'm looking for answers here now.

Original post: http://forum.arduino.cc/index.php?topic=391698.0

I get the idea of uploading a "stop" sketch for the purpose of overriding a previously uploaded program in Flash memory space.

Then of course we have EEPROM for "long-term" storage.

However, let's say an Arduino: Read user input as secret key and store in memory (SRAM) Performed a signing operation with secret key Subsequently powered off

We know that computers introduce a wide range of complications to security because data can still be recovered, even after being erased or overwritten in some cases, variables stored in memory float around (unless pinned for decryption in SecureString contexts, etc.), etc.

To establish context for the following questions, let's [overly] simplify the attack vector in saying this would be a scenario where an Arduino used in a security application is physically disconnected, stolen, and then powered on sometime later.

Question 1: Obviously we're not talking about storing keys on disk necessarily (i.e. EEPROM). How likely (or difficult) would it be to analyze SRAM with the intent to recover keys that may have been previously stored in memory?

Question 2: Similarly, let's say sensitive information was in fact stored in EEPROM. Does the same hold true of data previously stored in EEPROM that has since been overwritten with new (i.e. zero) data?

Any help would be greatly appreciated. Thanks!

  • As the others already said, if it is in RAM as soon as you power it off your key is gone. If you want to be really safe, overwrite the key as soon as you stop using it. If you store it in EEPROM, theoretically it is recoverable, but practically it isn't (it would require the "attacker" to tear apart the uC case, estract the silicon die, know where are the eeprom cells and read it with costy equipment. But before doing this, probably they already guessed your password (or brute-forced it)
    – frarugi87
    Commented Apr 6, 2016 at 10:16
  • RAM can be retained for a while under certain circumstances. Read e.g. this article wp.josh.com/2014/03/03/the-mystery-of-the-zombie-ram
    – Gerben
    Commented Apr 6, 2016 at 11:36
  • Mystery of the zombie RAM, nice. I just read about this recently in an electronics book that LEDs not only give off light, but can produce a tiny current if light is shown onto it, "enough to sustain RAM indefinitely." So don't forget to bring a flashlight along with your liquid nitrogen (RE: Nick Gammon) :)
    – Matt Borja
    Commented Apr 6, 2016 at 20:30

2 Answers 2


RAM memory looses its contents when it's powered off. However, this natural erasure process is not instantaneous: it can take several seconds, or even minutes. It has been demonstrated that cooling down a memory chip can extend its data retention time to hours, which enables a type of attack known as cold boot attack.

This type of attack has been studied mostly on DRAM computer modules. The Arduino memory, however, is based on SRAM, which is physically very different from DRAM (a transistor feedback loop vs. a capacitor). There seems to be very little research on cold boot attacks against SRAM. I found nonetheless a technical report from the computer laboratory of the University of Cambridge: Low temperature data remanence in static RAM, by Sergei Skorobogatov. Quoting from the conclusion:

Contrary to the established wisdom, there are several chips that retain data for dangerous periods of time at temperatures above −20°C. The temperature at which 80% of the data are retained for one minute varies widely between devices. Some require cooling to at least −50°C, while others retain data for this period at room temperature. Retention times can be significantly reduced by shorting VCC to ground rather than by leaving it floating.

From this perspective I would say that, although the attack seems non obvious, your secret key is not completely safe even in SRAM. Since the data retention time varies widely between devices, it could be worth testing on your Arduino. If possible, I would suggest you overwrite the key after the signing operation.

Update: I did a quick test on my Arduino Uno, at room temperature, by just unplugging and plugging back the board. Here is my test code:

// This memory buffer will not be zeroed at startup by the C runtime.
uint8_t __attribute__((section(".noinit"))) buffer[1024];

void setup()
    Serial.println(F("Program started."));

void loop()
    switch (Serial.read()) {
        case 'i':  // Initialize the buffer with pseudo-random bits.
            for (size_t i = 0; i < sizeof buffer; i++)
                buffer[i] = rand();
            Serial.println(F("Buffer initialized."));
        case 'f':  // Report number of flipped bits.
            int count = 0;
            for (size_t i = 0; i < sizeof buffer; i++) {
                uint8_t mask = buffer[i] ^ rand();
                while (mask) {
                    count += mask & 1;
                    mask >>= 1;
            Serial.print(F("Flipped bits: "));
            Serial.print(F(" / "));
            Serial.println(8 * sizeof buffer);

And this is the output, with my comments on the right:

Program started.            ← fresh boot
Buffer initialized.         ← pressed 'i'
Program started.            ← pressed the reset button
Flipped bits: 0 / 8192      ← pressed 'f'
Program started.            ← unplugged and plugged back
Flipped bits: 4166 / 8192   ← pressed 'f'

It appears the RAM is preserved across a warm reboot (pressing the reset button), but it is completely lost after a power cycle: half the bits flipped is a total loss of information. I tried to do this as fast as I could, which is slightly less than one second. It would seem the SRAM in the ATmega chips decays pretty fast, at least at room temperature.

Update 2: I found an enlightening story about an unpowered AVR keeping data in RAM for more than 10 minutes, but only on mornings: The mystery of the Zombie RAM.

  • 1
    Sounds good, but if I was going to burst into a room with liquid nitrogen to cool down the chip, I would arrive a minute earlier, and make sure that the chip wasn't powered down in the first place.
    – Nick Gammon
    Commented Apr 6, 2016 at 9:36
  • +1 for conducting your own separate tests to validate existing research :)
    – Matt Borja
    Commented Apr 6, 2016 at 20:17

Uploading a new sketch using the IDE does "page erases" which means that a small sketch will not completely replace a larger one. However using a ICSP programmer starts with a complete flash erase, so that would be more secure. Or you could probably (and it would be better to) upload a new sketch containing mostly random data (eg. a large array in PROGMEM).

Rewriting EEPROM should be pretty secure, especially if you replace the EEPROM with random data, and preferably do it a number of times.

As for SRAM, I would be surprised if you could recover much after a power-off. If the attacker manages to keep the power on that would be different. If possible, write over sensitive data with random bytes as soon as you don't need it any more.

If the data has to stay in RAM, I could envisage a scenario where if I got access to the processor (still powered on) I would upload a small sketch which would simply dump RAM to (say) the serial port a byte at a time, to avoid needing much RAM to do the dumping.

I think the AVR processors at least would be comparatively safe. After all they don't have disks, virtual memory, or fancy remapping of sectors like a USB stick might.

Read user input as secret key and store in memory (SRAM) Performed a signing operation with secret key. Subsequently powered off.

Sounds pretty safe once you specify "powered off".



  • 1
    I would upload a small sketch which would simply dump RAM to (say) the serial port a byte at a time, to avoid needing much RAM to do the dumping.” I bet you would write the program in such a way that it uses zero RAM. Commented Apr 6, 2016 at 9:15
  • Yes, quite possibly. :) It might depend on how much money changed hands. :P
    – Nick Gammon
    Commented Apr 6, 2016 at 9:35
  • +1 for covering EEPROM details and pointing out complete flash erase as added safety measure. Thanks!
    – Matt Borja
    Commented Apr 6, 2016 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.