Please Critique This Security Scheme

Hello all,

I have developed an embedded system that I wish to protect from reverse engineering and piracy, while at the same time allowing end users to easily update the units with newer versions of my software. I have come up with a security scheme that I believe will be a "win" for everybody, but I would like to get some feedback from your guys.

The hardware for my embedded system is made by a third party. My plan is to buy the boards from the manufacturer, flash the software I have developed onto them, and then sell the complete package to an end user. This board is based on a variant of the TMS470 chip which features both Flash Protection and Memory Security modules in hardware. Once locked, the micro cannot be reflashed, nor can its on-chip memories be accessed by a JTAG, without supplying two 128-bit keys, one for the flash and one for the memory. In addition, the flash can be reprogrammed by code running on the micro without unlocking the MSM as long as the correct Flash Protection key is supplied.

I have written a small bootloader which will be programmed in at the "factory" (i.e. my living room) prior to final shipment. This bootloader code will not be overwritten, nor will the flash sectors it occupies ever need to be erased or reprogrammed during normal usage. Only the application portion of the code, which resides in a separate region of the flash, will ever need to be updated. This separation is intended to premit an end user to recover from a botched update (e.g. serial cable got pulled out, power was interrupted during the flashing process, etc.) without having to ship the board back to me for repair.

To make software updates as easy as possible for the end users, I would like to make update files freely available, e.g. via FTP or on a web site. An end user would simply download the update program, plug in a serial cable, and run it on their PC.

An obvious danger here is that someone could simply buy one of these COTS boards direct from the manufacturer or elsewhere, download one of my firmware update files, and install it onto their board without obtaining a license from me. To prevent this, I would encrypt the update files before making them available to end users. The update utility would connect to the board via a serial port and transfer the encrypted file to the target. The bootloader would receive the file, decrypt it, unlock the flash, and burn the decrypted image. The Memory Security Module in the micro would prevent anyone from snooping on this process and retrieving either the keys or the cleartext software image. The bootloader code, as well as all keys, will never released to any third party.

What do you think? Can any of you spot any weaknesses in my little scheme? How would you go about trying to break it?

Reply to
Fred
Loading thread data ...

The real question is "how much is it worth to break it"? If the answer is less than $5000, your scheme is just fine.

If the answer is > $500,000, your scheme probably needs a rigorous analysis. In between, I don't know...

Reply to
Jim Stewart

That *used* to be a good summary of the risk/benefit analysis. Nowadays, you have to add the "novelty/desirability" factor. E.g., how motivated would a *hacker* (in the sense of someone who just tinkers -- not a malicious intent) be to reverse engineer it. Then, how likely is it for a *community* (even 3 people!) of such hackers to develop and get together "on line" to share their results.

And, how "rich" will your feature set be -- i.e., how motivated would folks be to hack the device so *they* could add the features that you *should* have!

With COTS hardware, you risk losing your "product" since anyone hacking this can bypass you to purchase the hardware on which to deploy *their* software...

Reply to
D Yuniskis

What was described is pretty standard method; weakness is in the details.

How much is it worth to develop the same thing from scratch? Since OP spend X amount of development effort, somebody else could do the same for the amount of effort less then X.

Yes. Also, the conglomeration of protection measures tells a lot about the ego of the author. As such, highly protected softwares are usually a total crap as far as their functionality.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky
[...]

I had a discussion about this in sci.crypt several years ago you might want to read. An attacker could try to upload modified code, or analyse differences between firmware files.

Oliver

--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:
Reply to
Oliver Betz

If the device is hackable it could actually increase the desirability of the device. Examples are the OpenWRT firmware for the LinkSys router and the CHDK firmware for Canon cameras.

Unless it is a popular, easily obtainable, high volume product with interesting features, or a hack is worth a substantial financial reward, it is unlikely any one is willing to invest any time to reverse engineer and hack the device.

Or a hacked version of *your* software.

Reply to
Dombo

Note that the OP is basing *his* product on a COTS hardware platform. I.e., *he* gets cut out of the picture *completely* if his product is hacked. By contrast, linksys/Cisco still gets to sell routers *despite* the hacks!

I think you would be surprised at the types of products that have been hacked/stolen in this way. I've seen folks reverse engineer *arcade* games (not easily obtainable, not particularly high volumes -- a few thousand of each "model",

*no* financial reward, etc.).

I've seen folks de-pot devices that they could *emulate* in software "for free", etc.

It's foolish to cling to old cost/benefit analysis for these sorts of things. And, since it is easy for anyone who does this sort of thing to *rapidly* share their activities with others, you can easily lose your market if you go down this road.

Reply to
D Yuniskis

Exactly. If I manufactured and sold the hardware it would be a completely different story.

Reply to
Swarga Research

That's a fascinating generalization you've made there, Vlad.

BTW, I took the liberty of visiting your web site. Looks like you've worked on all kinds of neat embedded devices. However, I didn't see the source code for any of them on your site. Do you not release the source code to your products because you have a huge ego and "your softwares are a total crap?" Or could it possibly be because you make your living developing software, the time you spend doing so has value, and you prefer to be compensated for your efforts rather than work for free?

Reply to
Fred

:)))))

That's based on experience.

I am a professional and I work for money. The code and schematics that I develop is a property of my customers. And they are free to do whatever they want; if they decide to publish, so be it. If I am asked to implement a protection, then I do protection which is adequate to the value been protected and the nature of the threat. As simple as that. BTW, from devices mentioned at the web site, most don't have any protection at all.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.