Securing code in embedded devices

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.

In article <cuqlu4$p0o$0$208.20.133.66@netheaven.com>, Bruce Barnett
<spamhater113+U050214113747@grymoire.com> writes
>
>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.

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



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 14 Feb 2005 17:08:20 GMT, Bruce Barnett 
<spamhater113+U050214113747@grymoire.com> wrote:

> I realize that any system can be defeated, especially if you have
> physical access.

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

"Bruce Barnett" <spamhater113+U050214113747@grymoire.com> wrote in message
news:cuqlu4$p0o$0$208.20.133.66@netheaven.com...
>
> 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.

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

"Bruce Barnett" <spamhater113+U050214113747@grymoire.com> wrote
 
> Some people have asked me for help in securing their application code
> in embedded devices from the threat of reverse engineering.

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/

Bruce Barnett <spamhater113+U050214113747@grymoire.com> writes:

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.

"Nicholas O. Lindan" wrote:
> 
... snip ...
> 
> 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..

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

"Bruce Barnett" <spamhater113+U050214215959@grymoire.com> wrote in message
news:curojp$v2i$2$208.20.133.66@netheaven.com...

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

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.

..