Fred wrote:

> Last time on comp.arch.embedded, Vladimir Vassilevsky
> <nospam@nowhere.com> said:
> 
> 
>>D Yuniskis wrote:
> 
> 
>>>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...
>>
>>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.
> 
> 
> That's a fascinating generalization you've made there, Vlad. 

:)))))

That's based on experience.

> 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?

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
http://www.abvolt.com

Last time on comp.arch.embedded, Vladimir Vassilevsky
<nospam@nowhere.com> said:

>D Yuniskis wrote:

>> 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...
>
>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.

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?

Last time on comp.arch.embedded, D Yuniskis <not.going.to.be@seen.com>
said:

>Dombo wrote:
 
>> 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.
>
>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!

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

Dombo wrote:
> D Yuniskis schreef:
>> Jim Stewart wrote:
>>> Fred wrote:
>>>> What do you think? Can any of you spot any weaknesses in my little
>>>> scheme? How would you go about trying to break it?
>>>
>>> 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...
>>
>> 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.
> 
> 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.

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!

>> 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!
> 
> 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.

<grin>  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.

>> 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...
> 
> Or a hacked version of *your* software.

D Yuniskis schreef:
> Jim Stewart wrote:
>> Fred wrote:
>>> What do you think? Can any of you spot any weaknesses in my little
>>> scheme? How would you go about trying to break it?
>>
>> 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...
> 
> 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.

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.

> 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!

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.

> 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...

Or a hacked version of *your* software.

Fred wrote:

[...]

>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?

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:

D Yuniskis wrote:

> Jim Stewart wrote:
> 
>> Fred wrote:
>>
>>> What do you think? Can any of you spot any weaknesses in my little
>>> scheme? How would you go about trying to break it?

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

>> The real question is "how much is it worth to break it"?

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.

> 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...

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
http://www.abvolt.com

Jim Stewart wrote:
> Fred wrote:
>> What do you think? Can any of you spot any weaknesses in my little
>> scheme? How would you go about trying to break it?
> 
> 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...

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...

Fred wrote:
> 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?

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...

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?