Propeller 2 Code Protection
michaelshu
Posts: 3
I'm new to Propeller and evaluating Propeller 2. Is there any code protection feature built in hardware? Or anyway to implemet some software solution for code protection? I found this old forum article but not sure it's implemented in Propeller 2. https://forums.parallax.com/discussion/138403/parallax-propeller-2-code-authentication-and-protection
Comments
It was planned for, using poly fuses to set up a 256-bit key, but not implemented because of likely fuse error rates. There was an alternative possibility of using some ON Semi IP to get the needed bits, but it seemed too complicated to try to implement amid all the other things needing to get done at the time.
You could fashion your own protection using a small code-protected micro, but its efficacy will be determined by the likely efforts used against it. I think if everyone came up with their own scheme, so that there was no universal attack possible, these would be reasonably secure for most purposes.
That.
As soon as there is enough interest, any code protection WILL get cracked. IIRC most common microcontroller's code protection schemes are broken.
However, there are ways to prevent your code from being "stolen", such as:
- Come up with your own contrived encryption/verification scheme, as chip said.
- Hide some kind of message inside your code, so when you suspect someone has cloned your product, you can prove it.
- Store code on a RAM chip that looses power when an intrusion is detected (of course that only works when you can service the device)
- Release the code as open-source to begin with
Yes, even small sub 50c MCUs commonly have unique serial numbers, so those can be used for first level clone or gateway protection.
eg the EFM8UB3 USB-MCU on P2D2 says this
"5.2 Unique Identifier A 128-bit universally unique identifier (UUID) is pre-programmed into all devices."
Above that, there are more security focused MCUs and even FPGAs now, that managers are more likely to sign off on :
http://www.nuvoton.com/hq/products/microcontrollers/arm-cortex-m23-mcus/?__locale=en
http://www.latticesemi.com/Products/FPGAandCPLD/MachXO3D
What is "MS" ? A company?
So, if you can tag your code, the thief's code will be unprotected too and you'd have proof that it was stolen.
But, what next?
Is the goal to protect the P2 code or proprietary info about something connected to the P2?
In the latter case, they don't need your code, they just need to reverse engineer how what is connected to the P2 works...
Any protection scheme can be broken. Usually you just need to "keep the honest people honest" by not making it too easy to clone.
Bean
Microsoft.
I used a 1-wire serial number in a project. On initial boot-up the serial number would be read and store -- in an obfuscated way -- in the EEPROM. The idea was that someone making a copy of the EE (a concern for the client) would end up with a bricked system if the physical serial number didn't match the stored version. If a mismatch was detected I would erase the EE and display an obtuse error message. The scheme was never deployed, though, because the client needed one more feature and the 1W link was the last IO pin we could use.
The code protection was made by encoding part of the FRAM image. Once the image was transferred into the hub the un-encoded part of the image read the FM31L278's OTP serial number and the two counters value. This two was the decoding key to decrypt the hub content.
The protection was made in the advancing of the counters value, with external events, for example upon a chassis intrusion switch or a light/ir detector (into a dark closed pcb enclosure), ... The same event also cleared the P1 ram if the MCU was powered when it occurred.
Obviously there was no decoding key comparison: if the counters value was not the right one the program was simply decoded with the wrong key, leading to unpredictable results.
A minimum level of security (injury prevention) was made with one IO acting as *disable* to other IO's to avoid wrong outputs driving due to mismatched program.
In addition you can send them on a wild goose chase by having a "decoy" that isn't so obfuscated that seemingly leads to something while in fact leads to nothing.
nice
I did leave the vendor name in plain text and used it as part of the security check. If someone edited the EE image to change the name I would also brick the system. This is simple and doesn't require the 1W serial number.