code protection?

mike56

I love the propeller but one thing that keeps me from using it in a commercial design is code protection.

How are people protecting their firmware and is parallax going to release code protection in the next propeller?

Mike Green

This has been discussed over and over again. In terms of actual protection from commercial theft, existing code protection schemes are useless. Chips can be unroofed and the contents of on-chip flash memory can be read using e-beam probes whether the on-chip locks are set or not. There are a variety of companies advertising their services on the web to do just this. To prevent casual theft, any of a variety of schemes can be used. Perhaps the easiest would be to include a 1-Wire device with a unique serial number and add a check routine into your program that uses a scrambled version of the serial number for checking. With the various command-line Spin compilers available, it would be straightforward to use any of a variety of scripting languages to compile and download a unique binary program for each device. For that matter, it would be easy to have a Propeller read its own serial number and modify its own program in the EEPROM overwriting its setup routine.

Prop II looks like it will have a one-time programmable 32-bit word (fusible ROM) that could be used to hold a unique serial number or decoding key. There's no guarantee that this will actually be included in the final Prop II, so I wouldn't count on it. There will not be any on-chip flash memory or EEPROM ... you can count on that.

ericball

Since the current Propeller does not have any internal non-volatile storage and must always start from unencrypted SPIN code, there's nothing to prevent anyone from reverse-engineering whatever code you create. Naturally, you can obsfucate the code to a greater or lesser extent. The question is then whether it is worth the time & effort for you to create the defenses and whether it is worth the attacker's time & effort to defeat them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC & PAL templates: http://forums.parallax.com/showthread.php?p=803904

dMajo

http://forums.parallax.com/showthread.php?p=814127

Mike Green

@ericball,
That's always the question. Since there's no existing commercial protection scheme that's proof from existing commercial reverse-engineering shops, it all comes down to making it hard enough for the casual thief to steal your product so they don't bother, yet not pricing your product out of the marketplace by trying to protect against the professional thieves. At a certain point, it's more cost effective to put the money into product development and support so you'll always have a better product than the thieves who will be trying to sell last years' model and your customers will pay a premium for your product rather than the copy-cats' because you support your products well.

Cluso99

This has always been a problem. Look at the extents MS goes to, but they still cannot stop it. There are always ways to disguise your code, but the best protection is customer service.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Clock Loop

I like the open nature of the prop, forces people to do it for the love....


Plus if we all released our work for free, we'd all be living in mansions created by robots, sipping our favorite drink that came from the food replicator(invented and released for free of coarse)...


But because we all want to "feed our children" or whatever (so many use that excuse)
we have to live in a world of "step on others, or get stepped on"


Soon, tho.. finally people will see and understand that the infinite future starts with self-sacrifice.


(if you keep your inventions, ideas, and programs up to date and provide support for them, you might find that you don't need to 'hide' your code.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

Cluso99

Years ago a multinational tried to look at my micros code and were disappointed they couldn't dump the internal code (MC68705). They built an inferior equivalent. I made a fortune having them replace them with mine. LOL. It was the only time anyone bothered. Customers were happy with what I built worked and the support.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Leon

Another embedded multi-core controller has 8k of OTP ROM for boot code and security keys. That should be very difficult to crack if code encryption is implemented properly. Perhaps the Propeller 2 will have something similar.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/24/2009 12:45:55 PM GMT

stevenmess2004

Leon, if as Mike says you can get a company to read the flash/rom on the chip then the only way to really secure the code is to encrypt the code and supply the key at run time by a secure method. If what Mike says is true putting the key on any chip isn't secure unless it has a self destruct mechanism (as in blows itself into a million pieces) or self clearing mechanism. As suggested in the thread linked to above storing the key (or the entire program) in volatile ram and then wiping the ram whenever the case is opened is probably about the most secure you can get. Don't know how you would distribute the keys when someone did open the box though. Maybe a trip at clients expense to "fix" it

To Parallax, if you are planning on only a 32 bit key is that going to be secure? I know Chip was talking about using a random number generator to increase the key size but to be useful that will have to be stored in the eeprom which means if anyone wants too they will find it. This means that we are back to a 32 bit key which I would guess to be pretty insecure since all the encryption routines I've heard of need a lot more bits than that. (and all of that should be taken with a grain of salt because the only thing I know about encryption is what I read in a couple of hours on wikipedia)

Mike Green

Encryption and code protection sound very straightforward when you look at the theory. You just do this or that and build X into your chip and you'll be safe from thieves. Reality and a look at history show that it's never true. Some years ago, it was believed that you could package your chip in the right package and no one could open it without destroying the chip. Then others found out how to dissolve the package and, under the right conditions, prevent the coatings from activating. The electron beam scanner has made it possible to read out the stored charge in a flash memory and to actually watch the chip operating. The chip manufacturers are trying to come up with metallization techniques to interfere with this so the e-beam has to go through a couple of layers of metal to read patches of flash, but the e-beam manufacturers will figure out how to do it and so the spy vs. spy battle goes on.

The people at Parallax have had real world experience with intellectual property theft and protection and they're convinced that there is no absolute code protection and it's foolish to spend much effort in trying to accomplish it. The 32 bit fusible ROM is something that is doable and relatively cheap to implement the way the chip is designed and has other uses as well. A 32 bit key is adequate to protect against casual theft.

Leon

Encrypting the code held in external flash memory is what I was assuming. Each system would have a different key, of course; it could be as large as required for a given security level. Military systems I once worked on had to erase the red and black memories, and clear the crypto key memory, if the case was opened. I had to demonstrate to the MoD that our anti-tamper system worked. There isn't any point in doing that on a non-military system, of course.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/24/2009 1:52:21 PM GMT

ericball

@Leon - reminds me of an X.25 encryption device I worked with. It had PCBs surrounding the main PCB with embeded clock traces. Pop the case or try to drill through it and the SRAM was zeroed. Remove the power, and it had an onboard battery which still did the job. Remove power and the battery and the SRAM zeroed itself. Loading the keys required a physical key with an embeded EPROM programmed by a C2 certificate storage computer in combination with a corresponding key sent via the X.25 network. A cool bit of hardware. There were two crypto guys on the project - one who spent his day looking for weakness in keys and the other who played Maxwell's demon with key exchange protocols.

Crypto is easy, but getting it right is very, very hard. One mistake and it's just a lot of wasted effort.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC & PAL templates: http://forums.parallax.com/showthread.php?p=803904

Leon

Our radios had micro-switches inside the case. When the case was opened, the switches were arranged so that the processor memories were zeroed long before there was enough clearance to get a probe inside. There was a complex key distribution system, with one key sent over the air and another one provided by a fill gun.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

kwinn

A company I worked for had a simple method of protecting their software. This was windows software for spectrometers, so quite expensive. When they sold a package they used the customer info and equipment model/serial number to encrypt all or part of the CD. Any tampering with the company or equipment information meant the CD was useless. Illegal copies and the source of the CD would be very apparent if the CD was copied and used elsewhere.

I am sure something similar can be done for the prop eprom, and a 32 bit serial number would provide additional security. Not the ultimate in security, but enough to prevent casual copying.

Jimmy W.

Code protection comes up over and over again, I am currently just doing a quick and easy check, a 1 wire serial number directly soldered to the underside of the chip, once booted it connects to our server send an encrypted packet that includes things like pin states and the serial number and if get back a packet that it decodes, if all is well then the encrypted file is sent to the prop, combine that with whats on the eeprom and it loads it into ram.


Jimmy

dMajo

stevenmess2004 said...
·As suggested in the thread linked to above storing the key (or the entire program) in volatile ram and then wiping the ram whenever the case is opened is probably about the most secure you can get. Don't know how you would distribute the keys when someone did open the box though. Maybe a trip at clients expense to "fix" it

The program is not in volatile ram but on fram. The key is in fram counter of the same device but accessed through a different I2C address. The counter is backed by the same battery that is running the RTC so it can count also in absence of power. (The device has two 16bit or one 32bit counter). A single-gate inverter oscillator circuit, that·feed the·clock to the counters, is (battery) powered through a device (switch, phototransistor ...) when needed so incrementing the counter values and changing the encryption keys (I must try with the 32K clock crystal oscillator,·already in place, to save the single-gate circuitry).

After copying the fram content to internal hub memory a loader reads the keys and decrypt the hub content (of course the loader is not encrypted). The loader is a pasm I2C multi-master/slave driver running in one cog with built in block-copy/move and read-and-decrypt/encrypt-and-write functions (once read the key·is stored internally·for further uses). An other application downloaded just to ram have the job to transfer the program from PC to the FRAM and preset the counter values (the key) the very first time. If you have other micros on board you can do that through the I2C while holding the prop in reset. Of course you must prevent downloading to prop ram otherwise the keys can be read and after that the fram content decrypted.