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.
..under a flower pot.....
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:
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.
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.
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.
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.
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...
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.
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.
Do other people avoid using EEPROM for long-term storage of important data?
yes. EEPROMs will get zapped. One cause is an all too easy to make mistake when re-flashing.
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...
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 ;) .
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:
First is to store it in an external secure memory with serial access like atmels cryptomemory
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.
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...
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.
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)
First is to store it in an external secure memory with serial access like atmels cryptomemory as one of many examples.
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.
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)
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.
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.
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..
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
c_oflynn:
You could write a simple program that dumps the entire RAM contents out over a pin, and reprogram the device with this.
Cooling the RAM works on DRAM, but hardly with SRAM.
What about one of those fake rocks you can get?
They look pretty unsuspecting....
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.
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.
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.
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.
You guys think in devious ways :mrgreen:
You guys think in devious ways :mrgreen:
If you secure it, they will crack...
