Prev: Regression testing for /* CAN'T HAPPEN */
Next: MII Management Interface, turnaround bits
From: Fred on 28 Mar 2010 18:27
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?
From: Jim Stewart on 29 Mar 2010 13:41
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...



From: D Yuniskis on 29 Mar 2010 15:58
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...
From: Oliver Betz on 30 Mar 2010 05:28
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:
From: Dombo on 31 Mar 2010 16:29
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.
 |  Next  |  Last
Pages: 1 2
Prev: Regression testing for /* CAN'T HAPPEN */
Next: MII Management Interface, turnaround bits