Some people have asked me for help in securing their application code in embedded devices from the threat of reverse engineering. I was looking for some papers/sites that discuss approaches, good and bad, to address this issue.
This system is attached to a network, so it can get encrypted data over a wire.
They are interested in options other than using a secure microprocessor with password protected memory. I'm not sure what the issues are.
I'm still gathering requirements, but perhaps someone can point me to commercial solutions, web pages, hack sites, lessons learned, do's and don'ts, etc.
Thanks
I realize that any system can be defeated, especially if you have physical access. Some are harder to defeat than others. SRAM vs. FLASH memory for instance.
--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.
See the work of Ross Anderson and Marcus Kuhn about reverse engineering.
Atmel and Maxim-Dallas (among others) have some extra secure processors, and for even higher security you may think of smartcards, as these are specialy designed to withstand reverse engineering (with varying degrees of success)
This issue comes up frequently with naive clients. Clients are often convinced the product developed for them is worth uncounted riches when in reality it is worth no more than it would cost to have a college student write a virgin copy of the software from scratch.
The most successful companies publish the source code for their products. Published schematics are SOP for h/p^H^H^HAgilent, IBM, Tektronix, consumer products etc. etc. etc..
Even if this is a secure application the product should be designed such that knowing the circuit and the algorithm one should not be able to crack the encrypted data.
If another firm can produce a 'Chinese copy' and take the market the problem is manufacturing, product quality, product pricing, distribution, service .... everywhere _but_ intellectual property.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
I heartily agree. One problem is that some of the code, and some of the circuitry, of commercial products are so bad that their owners would be embarassed by publication. It happends in the public domain world too - someone publishes a binary and hides the embarassing source. That was the fate of NULU in the CP/M world
25+ years ago, for example. Everybody used it. About the same time I published LT, and I believe that is still going.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
There is something else that concerns me, and earlier I thought I would be kind and let it pass.
Initially, you indicated that this was for an embedded application, but the implementors wanted to use general purpose tools (you didn't word it that way, but that is how I read it). This tells me that the implementors are likely inexperienced in embedded applications.
Other posters have pointed out that the common code protection schemes in embedded microprocessors, although breakable, are pretty good. Parts intended for embedded deployment also tend to be very inexpensive compared to their more general purpose counterparts. Insisting on using a hammer when you need a screwdriver suggests to me that the implementors are unwilling to learn the trade. Perhaps they should be guided into some other endeavor.
Assuming you are in the U.S., some other questions come to mind. As another poster pointed out, absolutely securing something is impossible. You can raise the discovery cost, but at a cost to yourself.
You want to question whether it is the impelementation that needs to be protected, or the algorithm. If the implementation, then copyrights provide pretty decent protection, especially if you take some reasonable steps to protect the underlying implementation.
However, if the algorithm is the thing, then you have another problem. Should someone else discover the algorithm and patent it, they can then prevent you from using it, even if you used it first. As long as you keep it a secret, you have no claim that having discovered it first. If you publish it, they can no longer prevent you from using it, and if you patent it, you can now prevent them from using it. But by maintaining the secret, you do take a considerable risk.
As another poster pointed out, though, the best protection is to have such a good implementation provided at such a competitive cost that it will not be lucrative for competitors to go after your market.
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.