Best place to store a secret key

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On a standard (non-secure) AVR is there any location that would be safer than others to store secret keys? For example, is eeprom better or worse than flash? Would it help to store keys at the start, middle, or end of the eeprom or flash?

I'm assuming of course that fuses and lockbits are set to prevent reading and that someone is trying to hack the device.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

..under a flower pot.....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now John you are being ridiculous. Everyone knows that is the first place to look. Put it under your neighbour's flower pot instead :roll:

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a locked cabinet in a dark room (the lights had gone) with a sign on the door marked 'beware of the leopard' and the bottom of a flight of stairs (which have also gone)...

More sensibly - what's the function of the secret key? If your system falls over if the key is known, don't put it on the chip; it must be assumed that the chip can be hacked.

In terms of storage - if there's not too much damage if the key is known - I'd think about hiding it in the middle of a code segment (a byte here, a byte there) or in a data block. Without the source code, someone's going to have to work hard to see how it's done. You could also perhaps xor it with e.g. a section of your code to make it less obvious.

Note though that this is not a *high* security approach, though it will probably stop the casual sniffer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can inprove security a little if you use 2 or even more keys that are for example XOR connected to get the final one. One is in the flash and one in EEPROM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My doors never (more then 12 years) get locked, so I guess I don't need to hide a key. But if I had to hide a key, I'd put it under the door Matt, in the visor, or on a "Post-It " note and slide it under the micro-controller - assuming you're using a PDIP.

I've never even locked a controller, so I really wouldn't know what would be best. Though, I have "Pass-worded " some alterable parameters in programs to keep the ignorant from important parameters. But even this was just a numeric string converted to a long data type and stored in EEPROM.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The key is primarily for authentication and integrity (HMAC or CMAC). The application is a game and the MAC is used to prevent cheating. The potential gain from hacking the devices isn't high, so the goal is to just make it "hard enough" to not be worth the effort.

I do plan to generate the final key dynamically so that you'd have to grab both the data and examine the program execution. But I'm still wondering if there is any well known difference between stealing eeprom vs. flash data.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

You might want to check out http://www.cl.cam.ac.uk/~sps32/m... and the newer updates at http://www.cl.cam.ac.uk/techrepo...

Note that the older AVRs were fairly insecure (AT90S series), the Mega are supposed to be better...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In general, I would stay away from storing critical information that cannot be easily regenerated or replaced into EEPROM because of its volatility. Opinions may differ, but that's my advice.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

farang wrote:
In general, I would stay away from storing critical information that cannot be easily regenerated or replaced into EEPROM because of its volatility. Opinions may differ, but that's my advice.

Have you lost data, or is this just a precaution?

Do other people avoid using EEPROM for long-term storage of important data?

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes. EEPROMs will get zapped. One cause is an all too easy to make mistake when re-flashing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Under the pillow is a good place.

Seriously: In the RAM and keep the processor always running of, say, a 3V lithium battery in sleep mode when the device is off, and when turned on, simply give it the normal power. If anyone decides to remove the AVR for analysis, the code will be lost...

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

daqq wrote:
Seriously: In the RAM and keep the processor always running of, say, a 3V lithium battery in sleep mode when the device is off, and when turned on, simply give it the normal power. If anyone decides to remove the AVR for analysis, the code will be lost...

...And if device is loosing power, even though it should not, you are lost...

Standard AVRs are not secure devices and where never ment to be used in topsecret pentagone protection devices even though you can. There are two options which comes to me that will give you the proper protection. First is to store it in an external secure memory with serial access like atmels cryptomemory as one of many examples.

The second option I cant tell you because it is an secret and I would have to look you up if I told you ;) .

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Schickb, yes, I have lost data from EEPROMs plenty of times. Usually as power goes up or down. I think the situation persists because even the latest controller data sheets contain a section advising on ways to minimize loss.

Personally, I like Daqq's idea of keeping the processor on all the time. Of course, this would also save the EEPROM problem as well. :lol:

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zainka wrote:
First is to store it in an external secure memory with serial access like atmels cryptomemory

But then don't you just have to store the authentication key somewhere else and if they can get the secret key from EEPROM, then they can get the authentication key from it and you're only slightly more secure and only due to further annoyance of one more step.

Your easiest bet is probably neil's idea to just store it in random bits of the EEPROM. Have some fixed location somewhere to store an address list that's been mangled. Then on startup, read the location(s) that contain the mangled list, run it through some algorithm to regenerate the list and then using that list, go fetch the pieces of the key to reassemble them.

Then to find your key, someone would have to know where the list is stored, the algorithm to unmangle it and then grab the pieces of the key and reassemble them (possible unmangling again through a different algorithm.

Getting the list out is hard enough, not to mention guessing how to unmangle it, getting the other bits and guessing how to unmangle those as well.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

farang wrote:
Schickb, yes, I have lost data from EEPROMs plenty of times. Usually as power goes up or down. I think the situation persists because even the latest controller data sheets contain a section advising on ways to minimize loss.

Personally, I like Daqq's idea of keeping the processor on all the time. Of course, this would also save the EEPROM problem as well. :lol:

I'd think the stability of EEPROM is at least as good as the stability of ensuring the device remains powered from flashing till forever... Plus if you have to change the battery, you'll need low battery sensing and warning and be able to switch it on the fly and not cut power during or you lose everything...

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No matter what you do, you will not gain better security than the security provided by lock bit settings, more or less, since the code in flash contain the information to resolve the key in the algorithm retrieving the key. I.e. the one which knows how to tweak the protection provided by the lock bit settings also holds the protected key in his hand even though it require some clever reverse engineering.

Therefor, storing the key as is in program flash is more than enough protection for most of us since the key now will be protected by the same security level as the flash itself. Moving the key to external secure flash may provide even better security but one then also need to be aware that the communication between external secure memory and mcu may be sniffed so key exchange must be encrypted.

No need to do it more difficult than necessary, hide it in internal flash.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, if you put the encryption stuff into the RAM (say, program it once), the guy hacking into it would have to be one hell of a person. The RAM data would dissolve the second power would be disconnected (ie chip taken out of the device, or reprogrammed with new firmware)

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zainka wrote:
First is to store it in an external secure memory with serial access like atmels cryptomemory as one of many examples.

That doesn't really help because as clpalmer said, the key could be sniffed when retrieved by the MCU. Or if it was sent encrypted, all the insecure data from the MCU could be retried to impersonate it. I believe cryptomemory is best used when the other side of the transfer is secure and the MCU is just a pass-through device.

Now if I could get cytpomemory itself to do the data signing that would be perfect. But they don't work on a stream of data and will only encrypt what is written into their flash memory.. Not really designed for frequent updates.

Since there have been a number of suggestions about power, I should mention that my device is only powered when plugged into USB. No batteries.

I'll have to do some reading about EEPROM volatility since I hadn't know about that issue before. This devices won't be re-flashed in the field often, but I guess it could happen. Certainly the power will be coming and going frequently.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

daqq wrote:
Actually, if you put the encryption stuff into the RAM (say, program it once), the guy hacking into it would have to be one hell of a person. The RAM data would dissolve the second power would be disconnected (ie chip taken out of the device, or reprogrammed with new firmware)

Assuming I had a battery, wouldn't this still be rather risky? If someone left the device sitting on their shelf until the batteries died, the device would become useless wouldn't it (assuming the encryption stuff is required to function)? Or am I missing something?

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

did you folks read the news story recently where some University students found that if they took RAM temperature very low, it would retain data with power off. A decrypted key or other data is a sitting duck.

one would have to steal the device while powered on, I suppose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is also described in the links posted by c_oflynn (articles from 2000 and 2005). Apparently that is why "secure" devices have temperature sensors.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Therefor, storing the key as is in program flash is more than enough protection for most of us since the key now will be protected by the same security level as the flash itself.

Yes - thats why for me FLASH is the best bet. For instance one thing I'm working on right now uses the key to authenticate a remote RF device, and if it authenticates the remote device can control withe local device.

While if the attacker has the ability to reprogram the local device, who the hell cares anymore? They can just ignore the encryption entirely..

Quote:
one would have to steal the device while powered on, I suppose.

Really not that hard. For instance as above, say you want to figure out the key to the remote device.

Chances are the designer reads the key from wherever then chucks it in RAM, in a continuous byte stream. The device probably never powers down, as most just go into a sleep-mode, hence the RAM is still good.

You could write a simple program that dumps the entire RAM contents out over a pin, and reprogram the device with this. You never have to power down the device anywhere, so the RAM is still intact.

Thus the importance of disabling all programming interfaces is shown! Plus keeping important information unencrypted for as short a time as possible...

Also you can write a self-destruct sequence that clears everything, and call it if you detect 'funny business'. Could be multiple power glitches (since AVR tells you reset source), voltage abnormalities, temperature (some AVR have internal temp sensors), etc etc.

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn:

Quote:
You could write a simple program that dumps the entire RAM contents out over a pin, and reprogram the device with this.

This may work with some devices, not others. As an example the AT90CAN128 B+ will (try to) zerofill memory when you send it an erase command. I don't know if it's documented anywhere, but it does.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cooling the RAM works on DRAM, but hardly with SRAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about one of those fake rocks you can get?
They look pretty unsuspecting....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have more details on the requirements of the key(s) and whether you need to be able to store them or just retrieve them? Are you trying to prevent anyone from reading the key or prevent anyone from modifying the key or duplicating the key? Does the AVR need to be able to re-write or change the key during normal operation?

If it's just a one-time key you need to program, then you could stick it in EEPROM encrypted with a public key that you don't store on the device. Then the AVR could decrypt it as needed with the existing private key, but noone could modify or replace the key, as they would have no way of re-encrypting the new one. Any required updates to the key would have to come from one source that possessed the public key. If the AVR needs to be able to store data as well, though, then this doesn't really help.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clpalmer wrote:
Do you have more details on the requirements of the key(s) and whether you need to be able to store them or just retrieve them? Are you trying to prevent anyone from reading the key or prevent anyone from modifying the key or duplicating the key? Does the AVR need to be able to re-write or change the key during normal operation?

The keys will be used to create an HMAC to authenticate data being sent by the device to a central server. Each device will get its own key, which should never change. The security goal is to make it hard for people to read the key so that they can't submit bogus data.

clpalmer wrote:
If it's just a one-time key you need to program, then you could stick it in EEPROM encrypted with a public key that you don't store on the device. Then the AVR could decrypt it as needed with the existing private key, but noone could modify or replace the key, as they would have no way of re-encrypting the new one.

Well if an attacker can get the code from the AVR they can get the private key and decrypt the HMAC key themselves.

What I'll probably do is construct the key dynamically so it is a bit harder to grab (requires understand code execution) and throw in a few data obfuscations. Certainly not bullet proof, but maybe hard enough to not be worth the effort.

I mentioned earlier that this is for a game, and there will occasionally be small rewards involved. If the prize is valuable enough we could also require the winner to send in their device for inspection. Again, not 100% but another complexity for an attacker.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you already have the AVR contacting a server to publish results, then can you also have the central server push back new images or chunks of images to the AVR? That way, every week or few days or whatever, the AVR would have to reflash itself with a new code, a new location for the code and a new obfuscated algorithm for retrieving it. That way if someone did manage to crack the AVR and pull the code out, hopefully by the time they disassembled, figured out, modified and used it to cheat, it wouldn't be valid any more anyways.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You guys think in devious ways :mrgreen:

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

farang wrote:
You guys think in devious ways :mrgreen:

Unfortunately the hackers/cheaters/crackers/what-have-you will always find a more devious way to circumvent it =)

If you secure it, they will crack...

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post