Possible that Prop can be more code secure than other MCUs?
Rayman
Posts: 14,876
I know the issue of code security has often come up...
Was just wondering if one can keep the Prop powered with a supercap or battery, if it could offer more code security that something like a PIC.
Was reading the other day about how to crack the PIC code security and rip the flash...
Does the Prop have an advantage in being able to run code from RAM?
Is there a way to steal Prop code that's only in RAM?
Was just wondering if one can keep the Prop powered with a supercap or battery, if it could offer more code security that something like a PIC.
Was reading the other day about how to crack the PIC code security and rip the flash...
Does the Prop have an advantage in being able to run code from RAM?
Is there a way to steal Prop code that's only in RAM?
Comments
I was evaluating this chip but ... the support is just extremely horrible :frown:
http://www.atmel.com/dyn/products/tools_devices.asp?category_id=172&family_id=646&subfamily_id=736&tool_id=4535
Could one force a reset and load a very tiny program that outputted the remaining RAM contents?
Does a reset clear RAM?
Replacements are shipped to be inserted into the device, already powered, running code.
-Phil
No, Unless you pot the whole thing in epoxy block.
There are chips with strong code encryption, of course, that are virtually immune to attack.
In order to prevent inadvertent resets, you'd have to tie both /BOE and /RST to Vdd.
-Phil
Then provide a battery sufficient to handle 2+ days without wall power and a way to replace the battery without powering down the system. Then provide a way to replace the system when they reset in spite of everything.
I've been looking into exactly this concept - in fact have just been discussing with Cluso.
My system has a GPRS modem which has "over the air" updates and should have enough smarts to be able to load the prop. So the "fix" in event of long term disconnection (1 month+, large supercap) is to "reflash" the modem with the prop loader code, reload the RAM based prop, and reflash the loader code and its payload out of there.
Here's what I think is the critical thing to check:- when loading the prop I think its possible to load a 'short' program. What happens to the remaining RAM in such an event? If it does remain it still may be possible to work around by keeping the private key near the start of RAM, so even a 'short' program would overwrite or at least corrupt it.
That raises an interesting question: what happens when the prop resets and there's no EEPROM and no PC connected? When it addresses EEPROM, is it smart enough to recognize that it's not getting an ACK and quit, or does it blithely fill RAM with $FFs? And if it quits, what next? Restart with the program currently in RAM? (That would be nice.)
-Phil
-Phil
According to the manual (page 18):
I guess this means that it doesn't touch the RAM. So, if the reset did not involve loss of power, would the RAM still be populated?
Would one possibility be to include an EEPROM with your device, but load it with a "fake" program? If you have a display on the device, this program could just show the message "Return to xxxx for servicing" or something similar. The manual says it reads an entire 32K image from the EEPROM - that would fill RAM.
Before shipping, you power up the device and load the real program into RAM. You then ship it out powered (as discussed above).
If it loses power or resets, it will load the program in EEPROM - wiping out the RAM (if necessary) and indicating that it will no longer function as expected.
Good thought, though this would not prevent someone from pulling the reset line low and loading a small program through P30/P31 as this is checked by the Propeller boot loader before it checks for an EEPROM.
Yeah. Unless the bootloader happens to clear RAM.
Maybe, after loading the RAM you just need to "cut off" pins 30 and 31. Of course, after that you couldn't reprogram the chip but at least people wouldn't be able to load another program. You'd have to replace the device instead of doing a factory "refurb."
The cutting off wouldn't necessarily have to be physical. Could you electrically jolt the receive pin sufficiently to destroy it without messing up the rest of the chip?
-Phil
Then there's that nasty inadvrtent reset issue. In nice environments, it wouldn't be a problem. But in industrial settings with lots of EMI, anything is possible.
-Phil
If the bootloader could be fooled into thinking it had received (serially without a reset) a valid program with the command to load to EEPROM then the current contents of RAM would be written to an EEPROM if fitted. I'm not saying its possible but it is an intriguing thought
As an unrelated side note, with a modified bootloader written to an EEPROM the Prop can be programmed from any pin pair 0 - 27 without a reset so if those pins are damaged all is not lost.
Jeff T.
If someone has a real need with volumes to match, I am prepared to discuss offline and can indeed provide some solutions. I think Ken and Chip also have ideas, so discuss with them directly too. I might add, nothing is quite perfect. Russia proved that with their Z80 clones.
Please divulge your idea. Security-by-obscurity is not security at all.
-Phil
I'll have to remember to ask Chip about this at UPEW (assuming he'll be there). I'm sure Chip and Parallax are well versed in code security from the Basic Stamp series.
I'd be surprised if they haven't thought about this already. Maybe they already know a weakness...
Good point, then the only solution would be to case it in unobtainium if security for the prop is your concern.
"Possible that Prop can be more code secure than other MCUs?"
is an oxymoron when you consider that the prop has no code security to start with and most other micros do.
The probing techniques required to break and read the volatile ram contents of the prop are different to breaking the "secure" memory of another flash based microcontroller.