Securing code in embedded devices

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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.


Re: Securing code in embedded devices
Quoted text here. Click to load it

Use a single chip MCU system with lock bits.  Many MCU have them.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Securing code in embedded devices
On 14 Feb 2005 17:08:20 GMT, Bruce Barnett

Quoted text here. Click to load it

Indeed.  Hope these links might be of interest:

http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html

Re: Securing code in embedded devices

Quoted text here. Click to load it

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)

Wim



Re: Securing code in embedded devices
 
Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Securing code in embedded devices
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Securing code in embedded devices

Thanks for the feedback.
This is the type of feedback i was looking for....


--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

Re: Securing code in embedded devices

Quoted text here. Click to load it

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.

..



Site Timeline