Forums

Protecting firmware in 5680x

Started by Unknown October 11, 2002
In order to avoid that anyone can clone my product, I ask you if is there
any possibility or idea to protect firmware when my product is delivered.
Are you sensible to this problem ?
I'm evaluationg MAXIM DS2432 but (it seems difficult to obtains)
Thanak you
Giuliano




We use this part for this purpose. Apart from the normal problems with
Maxim, I haven't heard any specific problems getting this part.

Of course, this is not as good a solution as if Motorola had provided some
security bits in their part.

-----Original Message-----
From: [mailto:]
Sent: October 11, 2002 5:56 AM
To:
Subject: [motoroladsp] Protecting firmware in 5680x In order to avoid that anyone can clone my product, I ask you if is there
any possibility or idea to protect firmware when my product is delivered.
Are you sensible to this problem ?
I'm evaluationg MAXIM DS2432 but (it seems difficult to obtains)
Thanak you
Giuliano _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/


There was a discussion on this issue back in March. Please look at the
following archive:

http://groups.yahoo.com/group/motoroladsp/messages/165

To sum up this discussion, there is no way for you to guarantee firmware
protection, however some developers pointed out very inventive ways of
deterring someone from reading flashed code.

Our next generation flash devices (DSP56800E) will have the kind of
security protection you are looking for.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: [mailto:]
Sent: Friday, October 11, 2002 5:56 AM
To:
Subject: [motoroladsp] Protecting firmware in 5680x

In order to avoid that anyone can clone my product, I ask you if is
there
any possibility or idea to protect firmware when my product is
delivered.
Are you sensible to this problem ?
I'm evaluationg MAXIM DS2432 but (it seems difficult to obtains)
Thanak you
Giuliano _____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/


Using external devices to provide internal security won't work unless there
is some unique secret in the external security device and some matching
unique secret embedded in the code on the DSP. Otherwise, the code in the
DSP can still be analyzed and the behaviour of the external security device
can be emulated, based on observing how it responds to the DSP.

Even internal security is no guarantee, since all it requires is failure
analysis equipment and a real desire to get the contents out. About all you
can hope for is to make the difficulty of getting the code about the same as
or greater than the effort to code the same application from scratch.

Security is not implemented in the 56800 devices becuase of their heritage:
it was originally a RAM based family with no FLASH based derivatives on the
horizon. To implement security (which is non-trivial as it requires a
redesign of the core) at this late date is not worth the effort in terms of
raw cost and resources, not to mention the risk of errata in the operation
of the core and the time and effort to get those cleared up.

--david
-----Original Message-----
Date: Fri, 11 Oct 2002 07:55:20 -0700
From: Simon Lightbody <>
Subject: RE: Protecting firmware in 5680x

We use this part for this purpose. Apart from the normal problems with
Maxim, I haven't heard any specific problems getting this part.

Of course, this is not as good a solution as if Motorola had provided some
security bits in their part.

-----Original Message-----
From: [mailto:]
Sent: October 11, 2002 5:56 AM
To:
Subject: [motoroladsp] Protecting firmware in 5680x In order to avoid that anyone can clone my product, I ask you if is there
any possibility or idea to protect firmware when my product is delivered.
Are you sensible to this problem ?
I'm evaluationg MAXIM DS2432 but (it seems difficult to obtains)
Thanak you
Giuliano
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


David-

The issue of code security was recently discussed on the C54xx group and on
comp.dsp. The consensus is that something like the Xbox approach is required.
What
Microsoft did was implement a small, inexpensive "shadow" microcontroller that
has
built-in code security features. The uC feeds encrypted data to the Pentium
(568xx
DSP in your case), and -- most importantly -- performs watchdog and monitoring
functions to detect tampering. For example, any type of anomaly in boot-up
sequence
or timing, any halt or pause during normal operation (possible indication of
JTAG
debugging), etc. causes the uC to shut the system down. Or worse, cause a
pwr-gnd
short or otherwise do something unpleasant to the PCB.

If you search the comp.dsp archives, you should be able to find some links to
web
pages where people have been working amazingly hard and in micro-detail to pull
apart
the Xbox. What they have accomplished and learned reminds anyone who doubts
what is
possible in terms of reverse engineering given enough effort. It appears they
now
know more about the Xbox overall then some of the specialized hw/sw team members
who
worked on it at Microsoft. They have been able to usurp the board for their own
use
(e.g. to run Linux or other OS), but evidently have not been able to get hold of
any
Microsoft (or video game) code of value -- a testament to Microsoft's basic
method to
security.

Jeff Brower
DSP sw/hw engineer
Signalogic Davie wrote:
>
> I was reading the DS2432 data sheet and several white papers from
> Maxim/Dallas Semiconductor about their 1-Wire security devices.
>
> It fairly explicitly states at the end of one of the white papers
> (http://www.maxim-ic.com/appnotes.cfm/appnote_number/1098) that in
> order to preserve the security of the system from physcial attacks,
> the reading of the firmware in the SCU (service control unit -
> DSP56F8xx in this case) needs to be prevented.
>
> Since the 56F8xx family does not provide any internal electrical
> security, how can the use of the DS2432 provide any security, much
> less peace of mind? It would seem that it would only make the
> reverse engineering of the 56F8xx code marginally more difficult.
>
> How can the expense of 3.9 euros be justified if the device cannot,
> by itself, provide any significant or tangible security?
>
> --david
>
> --- In motoroladsp@y..., giuliano.to@q... wrote:
> >
> > Ok, I found another that using DS2432!
> > Which is code size to decode DS2432 information ?
> >
> > P.S. DS2432 seems expensive (for my applicaton) (around 3.9 euro).
> >
> >
> > Regards,
> > Giuliano
> >
>
> >Simon Lightbody
> ><Simon.Lightbody@
> >Per: "'giuliano.to@q...'" <giuliano.to@q...>,
> > pwrm.com>
> > motoroladsp@y...
> >Cc:
> > 11/10/02 16.55
> >Oggetto: RE: [motoroladsp] Protecting firmware in 5680x
> >
> >
> > We use this part for this purpose. Apart from the normal problems
> with
> > Maxim, I haven't heard any specific problems getting this part.
> >
> > Of course, this is not as good a solution as if Motorola had
> provided some
> > security bits in their part.
> >
> > -----Original Message-----
> > From: giuliano.to@q... [mailto:giuliano.to@q...]
> > Sent: October 11, 2002 5:56 AM
> > To: motoroladsp@y...
> > Subject: [motoroladsp] Protecting firmware in 5680x
> >
> >
> > In order to avoid that anyone can clone my product, I ask you if is
> there
> > any possibility or idea to protect firmware when my product is
> delivered.
> > Are you sensible to this problem ?
> > I'm evaluationg MAXIM DS2432 but (it seems difficult to obtains)
> > Thanak you
> > Giuliano





Jeff provides an effective approch to protect your
code. You also can use a so-called Secure Memory to
protect your design. Atmel has both Secure Memory and
Secure MCU to provide security feature for your
design. The low cost solution is to place a part of
you DSP code in an Atmel 8951 MCU. When power on,
transfer the this piece of code for 8951 to DSP's
internal data or program memory. 8951 has the
security lock for its internal flash memory.

Charlie W.

--- Jeff Brower <> wrote:
> David-
>
> The issue of code security was recently discussed on
> the C54xx group and on
> comp.dsp. The consensus is that something like the
> Xbox approach is required. What
> Microsoft did was implement a small, inexpensive
> "shadow" microcontroller that has
> built-in code security features. The uC feeds
> encrypted data to the Pentium (568xx
> DSP in your case), and -- most importantly --
> performs watchdog and monitoring
> functions to detect tampering. For example, any
> type of anomaly in boot-up sequence
> or timing, any halt or pause during normal operation
> (possible indication of JTAG
> debugging), etc. causes the uC to shut the system
> down. Or worse, cause a pwr-gnd
> short or otherwise do something unpleasant to the
> PCB.
>
> If you search the comp.dsp archives, you should be
> able to find some links to web
> pages where people have been working amazingly hard
> and in micro-detail to pull apart
> the Xbox. What they have accomplished and learned
> reminds anyone who doubts what is
> possible in terms of reverse engineering given
> enough effort. It appears they now
> know more about the Xbox overall then some of the
> specialized hw/sw team members who
> worked on it at Microsoft. They have been able to
> usurp the board for their own use
> (e.g. to run Linux or other OS), but evidently have
> not been able to get hold of any
> Microsoft (or video game) code of value -- a
> testament to Microsoft's basic method to
> security.
>
> Jeff Brower
> DSP sw/hw engineer
> Signalogic > Davie wrote:
> >
> > I was reading the DS2432 data sheet and several
> white papers from
> > Maxim/Dallas Semiconductor about their 1-Wire
> security devices.
> >
> > It fairly explicitly states at the end of one of
> the white papers
> >
>
(http://www.maxim-ic.com/appnotes.cfm/appnote_number/1098)
> that in
> > order to preserve the security of the system from
> physcial attacks,
> > the reading of the firmware in the SCU (service
> control unit -
> > DSP56F8xx in this case) needs to be prevented.
> >
> > Since the 56F8xx family does not provide any
> internal electrical
> > security, how can the use of the DS2432 provide
> any security, much
> > less peace of mind? It would seem that it would
> only make the
> > reverse engineering of the 56F8xx code marginally
> more difficult.
> >
> > How can the expense of 3.9 euros be justified if
> the device cannot,
> > by itself, provide any significant or tangible
> security?
> >
> > --david
> >
> > --- In motoroladsp@y..., giuliano.to@q... wrote:
> > >
> > > Ok, I found another that using DS2432!
> > > Which is code size to decode DS2432 information
> ?
> > >
> > > P.S. DS2432 seems expensive (for my applicaton)
> (around 3.9 euro).
> > >
> > >
> > > Regards,
> > > Giuliano
> > >
> >
> > >Simon Lightbody
> > ><Simon.Lightbody@
> > >Per: "'giuliano.to@q...'" <giuliano.to@q...>,
> > > pwrm.com>
> > > motoroladsp@y...
> > >Cc:
> > > 11/10/02 16.55
> > >Oggetto: RE: [motoroladsp] Protecting firmware
> in 5680x
> > >
> > >
> > > We use this part for this purpose. Apart from
> the normal problems
> > with
> > > Maxim, I haven't heard any specific problems
> getting this part.
> > >
> > > Of course, this is not as good a solution as if
> Motorola had
> > provided some
> > > security bits in their part.
> > >
> > > -----Original Message-----
> > > From: giuliano.to@q... [mailto:giuliano.to@q...]
> > > Sent: October 11, 2002 5:56 AM
> > > To: motoroladsp@y...
> > > Subject: [motoroladsp] Protecting firmware in
> 5680x
> > >
> > >
> > > In order to avoid that anyone can clone my
> product, I ask you if is
> > there
> > > any possibility or idea to protect firmware when
> my product is
> > delivered.
> > > Are you sensible to this problem ?
> > > I'm evaluationg MAXIM DS2432 but (it seems
> difficult to obtains)
> > > Thanak you
> > > Giuliano


__________________________________________________



But even with secure external memory, once the code is up and running
in the DSP, there is very little to stop one from pulling the contents
of FLASH and RAM out of the DSP.

Since there is no security built into the DSP, what real security is
provided by any secure external devices? Why bother spending the
money on relatively expensive secure devices and time designing and
debugging code to utilize them if they don't add anything tangible?

Multiple supervisory devices like the XBox would only work if they
were secure and their real function in the system could be obscured or
hidden. Most 56F8xx applications (if not all) are nowhere near the
complexity of an XBox. If the supervisory devices control something
or turn something off that needs to be on, it can be discovered and
emulated... Again, no real security after a whole lot of design and
debug effort to implement in the first place.

Physical access to the application board coupled with the lack of
security in the 56F8xx unavoidably makes for unsecurable designs.
There's no way around that with 56F8xx devices short of blowing
JTAG/OnCE pins after programming. And even then, the DSP could
probably be brought up with external memory and be made to dump the
contents of internal FLASH without even bothering with the JTAG/OnCE
at all...

--david

--- In motoroladsp@y..., Charlie W <charliewtx@y...> wrote:
> Jeff provides an effective approch to protect your
> code. You also can use a so-called Secure Memory to
> protect your design. Atmel has both Secure Memory and
> Secure MCU to provide security feature for your
> design. The low cost solution is to place a part of
> you DSP code in an Atmel 8951 MCU. When power on,
> transfer the this piece of code for 8951 to DSP's
> internal data or program memory. 8951 has the
> security lock for its internal flash memory.
>
> Charlie W.
>
> --- Jeff Brower <jbrower@s...> wrote:
> > David-
> >
> > The issue of code security was recently discussed on
> > the C54xx group and on
> > comp.dsp. The consensus is that something like the
> > Xbox approach is required. What
> > Microsoft did was implement a small, inexpensive
> > "shadow" microcontroller that has
> > built-in code security features. The uC feeds
> > encrypted data to the Pentium (568xx
> > DSP in your case), and -- most importantly --
> > performs watchdog and monitoring
> > functions to detect tampering. For example, any
> > type of anomaly in boot-up sequence
> > or timing, any halt or pause during normal operation
> > (possible indication of JTAG
> > debugging), etc. causes the uC to shut the system
> > down. Or worse, cause a pwr-gnd
> > short or otherwise do something unpleasant to the
> > PCB.
> >
> > If you search the comp.dsp archives, you should be
> > able to find some links to web
> > pages where people have been working amazingly hard
> > and in micro-detail to pull apart
> > the Xbox. What they have accomplished and learned
> > reminds anyone who doubts what is
> > possible in terms of reverse engineering given
> > enough effort. It appears they now
> > know more about the Xbox overall then some of the
> > specialized hw/sw team members who
> > worked on it at Microsoft. They have been able to
> > usurp the board for their own use
> > (e.g. to run Linux or other OS), but evidently have
> > not been able to get hold of any
> > Microsoft (or video game) code of value -- a
> > testament to Microsoft's basic method to
> > security.
> >
> > Jeff Brower
> > DSP sw/hw engineer
> > Signalogic
> >
> >
> > Davie wrote:
> > >
> > > I was reading the DS2432 data sheet and several
> > white papers from
> > > Maxim/Dallas Semiconductor about their 1-Wire
> > security devices.
> > >
> > > It fairly explicitly states at the end of one of
> > the white papers
> > >
> >
> (http://www.maxim-ic.com/appnotes.cfm/appnote_number/1098)
> > that in
> > > order to preserve the security of the system from
> > physcial attacks,
> > > the reading of the firmware in the SCU (service
> > control unit -
> > > DSP56F8xx in this case) needs to be prevented.
> > >
> > > Since the 56F8xx family does not provide any
> > internal electrical
> > > security, how can the use of the DS2432 provide
> > any security, much
> > > less peace of mind? It would seem that it would
> > only make the
> > > reverse engineering of the 56F8xx code marginally
> > more difficult.
> > >
> > > How can the expense of 3.9 euros be justified if
> > the device cannot,
> > > by itself, provide any significant or tangible
> > security?
> > >
> > > --david
> > >
> > > --- In motoroladsp@y..., giuliano.to@q... wrote:
> > > >
> > > > Ok, I found another that using DS2432!
> > > > Which is code size to decode DS2432 information
> > ?
> > > >
> > > > P.S. DS2432 seems expensive (for my applicaton)
> > (around 3.9 euro).
> > > >
> > > >
> > > > Regards,
> > > > Giuliano
> > > >
> > >
> > > >Simon Lightbody
> > > ><Simon.Lightbody@
> > > >Per: "'giuliano.to@q...'" <giuliano.to@q...>,
> > > > pwrm.com>
> > > > motoroladsp@y...
> > > >Cc:
> > > > 11/10/02 16.55
> > > >Oggetto: RE: [motoroladsp] Protecting firmware
> > in 5680x
> > > >
> > > >
> > > > We use this part for this purpose. Apart from
> > the normal problems
> > > with
> > > > Maxim, I haven't heard any specific problems
> > getting this part.
> > > >
> > > > Of course, this is not as good a solution as if
> > Motorola had
> > > provided some
> > > > security bits in their part.
> > > >
> > > > -----Original Message-----
> > > > From: giuliano.to@q... [mailto:giuliano.to@q...]
> > > > Sent: October 11, 2002 5:56 AM
> > > > To: motoroladsp@y...
> > > > Subject: [motoroladsp] Protecting firmware in
> > 5680x
> > > >
> > > >
> > > > In order to avoid that anyone can clone my
> > product, I ask you if is
> > > there
> > > > any possibility or idea to protect firmware when
> > my product is
> > > delivered.
> > > > Are you sensible to this problem ?
> > > > I'm evaluationg MAXIM DS2432 but (it seems
> > difficult to obtains)
> > > > Thanak you
> > > > Giuliano
> >
> > __________________________________________________
>





David-

> Multiple supervisory devices like the XBox would only work if they
> were secure and their real function in the system could be obscured or
> hidden. Most 56F8xx applications (if not all) are nowhere near the
> complexity of an XBox. If the supervisory devices control something
> or turn something off that needs to be on, it can be discovered and
> emulated... Again, no real security after a whole lot of design and
> debug effort to implement in the first place.

Are you just guessing or did you study the web pages I recommended? It has
worked
(to date) for Microsoft; I'm sure they put some thought and effort into it.

The supervisory uC in the Xbox is not emulatable. It contains onchip FLASH with
code
security; this approach was taken because of the lack of onchip secure FLASH in
the
Pentium -- the same situation you are discussing with the 568xx devices.

Jeff Brower
DSP sw/hw engineer
Signalogic > --- In motoroladsp@y..., Charlie W <charliewtx@y...> wrote:
> > Jeff provides an effective approch to protect your
> > code. You also can use a so-called Secure Memory to
> > protect your design. Atmel has both Secure Memory and
> > Secure MCU to provide security feature for your
> > design. The low cost solution is to place a part of
> > you DSP code in an Atmel 8951 MCU. When power on,
> > transfer the this piece of code for 8951 to DSP's
> > internal data or program memory. 8951 has the
> > security lock for its internal flash memory.
> >
> > Charlie W.
> >
> > --- Jeff Brower <jbrower@s...> wrote:
> > > David-
> > >
> > > The issue of code security was recently discussed on
> > > the C54xx group and on
> > > comp.dsp. The consensus is that something like the
> > > Xbox approach is required. What
> > > Microsoft did was implement a small, inexpensive
> > > "shadow" microcontroller that has
> > > built-in code security features. The uC feeds
> > > encrypted data to the Pentium (568xx
> > > DSP in your case), and -- most importantly --
> > > performs watchdog and monitoring
> > > functions to detect tampering. For example, any
> > > type of anomaly in boot-up sequence
> > > or timing, any halt or pause during normal operation
> > > (possible indication of JTAG
> > > debugging), etc. causes the uC to shut the system
> > > down. Or worse, cause a pwr-gnd
> > > short or otherwise do something unpleasant to the
> > > PCB.
> > >
> > > If you search the comp.dsp archives, you should be
> > > able to find some links to web
> > > pages where people have been working amazingly hard
> > > and in micro-detail to pull apart
> > > the Xbox. What they have accomplished and learned
> > > reminds anyone who doubts what is
> > > possible in terms of reverse engineering given
> > > enough effort. It appears they now
> > > know more about the Xbox overall then some of the
> > > specialized hw/sw team members who
> > > worked on it at Microsoft. They have been able to
> > > usurp the board for their own use
> > > (e.g. to run Linux or other OS), but evidently have
> > > not been able to get hold of any
> > > Microsoft (or video game) code of value -- a
> > > testament to Microsoft's basic method to
> > > security.
> > >
> > > Jeff Brower
> > > DSP sw/hw engineer
> > > Signalogic
> > >
> > >
> > > Davie wrote:
> > > >
> > > > I was reading the DS2432 data sheet and several
> > > white papers from
> > > > Maxim/Dallas Semiconductor about their 1-Wire
> > > security devices.
> > > >
> > > > It fairly explicitly states at the end of one of
> > > the white papers
> > > >
> > >
> > (http://www.maxim-ic.com/appnotes.cfm/appnote_number/1098)
> > > that in
> > > > order to preserve the security of the system from
> > > physcial attacks,
> > > > the reading of the firmware in the SCU (service
> > > control unit -
> > > > DSP56F8xx in this case) needs to be prevented.
> > > >
> > > > Since the 56F8xx family does not provide any
> > > internal electrical
> > > > security, how can the use of the DS2432 provide
> > > any security, much
> > > > less peace of mind? It would seem that it would
> > > only make the
> > > > reverse engineering of the 56F8xx code marginally
> > > more difficult.
> > > >
> > > > How can the expense of 3.9 euros be justified if
> > > the device cannot,
> > > > by itself, provide any significant or tangible
> > > security?
> > > >
> > > > --david
> > > >
> > > > --- In motoroladsp@y..., giuliano.to@q... wrote:
> > > > >
> > > > > Ok, I found another that using DS2432!
> > > > > Which is code size to decode DS2432 information
> > > ?
> > > > >
> > > > > P.S. DS2432 seems expensive (for my applicaton)
> > > (around 3.9 euro).
> > > > >
> > > > >
> > > > > Regards,
> > > > > Giuliano
> > > > >
> > > >
> > > > >Simon Lightbody
> > > > ><Simon.Lightbody@
> > > > >Per: "'giuliano.to@q...'" <giuliano.to@q...>,
> > > > > pwrm.com>
> > > > > motoroladsp@y...
> > > > >Cc:
> > > > > 11/10/02 16.55
> > > > >Oggetto: RE: [motoroladsp] Protecting firmware
> > > in 5680x
> > > > >
> > > > >
> > > > > We use this part for this purpose. Apart from
> > > the normal problems
> > > > with
> > > > > Maxim, I haven't heard any specific problems
> > > getting this part.
> > > > >
> > > > > Of course, this is not as good a solution as if
> > > Motorola had
> > > > provided some
> > > > > security bits in their part.
> > > > >
> > > > > -----Original Message-----
> > > > > From: giuliano.to@q... [mailto:giuliano.to@q...]
> > > > > Sent: October 11, 2002 5:56 AM
> > > > > To: motoroladsp@y...
> > > > > Subject: [motoroladsp] Protecting firmware in
> > > 5680x
> > > > >
> > > > >
> > > > > In order to avoid that anyone can clone my
> > > product, I ask you if is
> > > > there
> > > > > any possibility or idea to protect firmware when
> > > my product is
> > > > delivered.
> > > > > Are you sensible to this problem ?
> > > > > I'm evaluationg MAXIM DS2432 but (it seems
> > > difficult to obtains)
> > > > > Thanak you
> > > > > Giuliano



I would like to reiterate what I have states previously, and what is OFFICIAL position from Motorola regarding flash security:

 

None of the currently available 56800 flash devices have a security protection implemented. Future 56800 flash devices will probably have flash security features, but for now, you'll have to use more physical means of protecting any Intellectual Property (IP) in the FLASH.

 

This statement is directly from our FAQ DSP-11506. We will have security protection in our new flash parts. For existing devices, however, there is no 100% protection for DSP code. Previous discussions on this newsgroup pointed out that you can deter someone from reading DSP code, in other words make it very difficult for some to read code, so they will simple give up. Some of the ideas from our customers is to remove JTAG pins and erase Motorola part number from the chip (if you don’t know what device this is, you don’t know how to interface to it).

 

For some other ideas, you can read old discussion thread:

 

http://groups.yahoo.com/group/motoroladsp/messages/165

 

Leonard N. Elevich

Motorola DSPO

 

 

-----Original Message-----
From: Davie [mailto:b...@yahoo.com]
Sent: Tuesday, October 15, 2002 7:19 PM
To: m...@yahoogroups.com
Subject: [motoroladsp] Re: Where, oh where is my security? WAS: Protecting firmware in 5680x

 

But even with secure external memory, once the code is up and running
in the DSP, there is very little to stop one from pulling the contents
of FLASH and RAM out of the DSP. 

Since there is no security built into the DSP, what real security is
provided by any secure external devices?  Why bother spending the
money on relatively expensive secure devices and time designing and
debugging code to utilize them if they don't add anything tangible?

Multiple supervisory devices like the XBox would only work if they
were secure and their real function in the system could be obscured or
hidden.  Most 56F8xx applications (if not all) are nowhere near the
complexity of an XBox.  If the supervisory devices control something
or turn something off that needs to be on, it can be discovered and
emulated...  Again, no real security after a whole lot of design and
debug effort to implement in the first place.

Physical access to the application board coupled with the lack of
security in the 56F8xx unavoidably makes for unsecurable designs.
There's no way around that with 56F8xx devices short of blowing
JTAG/OnCE pins after programming.  And even then, the DSP could
probably be brought up with external memory and be made to dump the
contents of internal FLASH without even bothering with the JTAG/OnCE
at all...

--david

--- In motoroladsp@y..., Charlie W <charliewtx@y...> wrote:
> Jeff provides an effective approch to protect your
> code. You also can use a so-called Secure Memory to
> protect your design. Atmel has both Secure Memory and
> Secure MCU to provide security feature for your
> design. The low cost solution is to place a part of
> you DSP code in an Atmel 8951 MCU. When power on,
> transfer the this piece of code for 8951 to DSP's
> internal data or program memory.  8951 has the
> security lock for its internal flash memory.
>
> Charlie W.

> --- Jeff Brower <jbrower@s...> wrote:
> > David-
> >
> > The issue of code security was recently discussed on
> > the C54xx group and on
> > comp.dsp.  The consensus is that something like the
> > Xbox approach is required.  What
> > Microsoft did was implement a small, inexpensive
> > "shadow" microcontroller that has
> > built-in code security features.  The uC feeds
> > encrypted data to the Pentium (568xx
> > DSP in your case), and -- most importantly --
> > performs watchdog and monitoring
> > functions to detect tampering.  For example, any
> > type of anomaly in boot-up sequence
> > or timing, any halt or pause during normal operation
> > (possible indication of JTAG
> > debugging), etc. causes the uC to shut the system
> > down.  Or worse, cause a pwr-gnd
> > short or otherwise do something unpleasant to the
> > PCB.
> >
> > If you search the comp.dsp archives, you should be
> > able to find some links to web
> > pages where people have been working amazingly hard
> > and in micro-detail to pull apart
> > the Xbox.  What they have accomplished and learned
> > reminds anyone who doubts what is
> > possible in terms of reverse engineering given
> > enough effort.  It appears they now
> > know more about the Xbox overall then some of the
> > specialized hw/sw team members who
> > worked on it at Microsoft.  They have been able to
> > usurp the board for their own use
> > (e.g. to run Linux or other OS), but evidently have
> > not been able to get hold of any
> > Microsoft (or video game) code of value -- a
> > testament to Microsoft's basic method to
> > security.
> >
> > Jeff Brower
> > DSP sw/hw engineer
> > Signalogic
> >
> >
> > Davie wrote:
> > >
> > > I was reading the DS2432 data sheet and several
> > white papers from
> > > Maxim/Dallas Semiconductor about their 1-Wire
> > security devices.
> > >
> > > It fairly explicitly states at the end of one of
> > the white papers
> > >
> >
> (http://www.maxim-ic.com/appnotes.cfm/appnote_number/1098)
> > that in
> > > order to preserve the security of the system from
> > physcial attacks,
> > > the reading of the firmware in the SCU (service
> > control unit -
> > > DSP56F8xx in this case) needs to be prevented.
> > >
> > > Since the 56F8xx family does not provide any
> > internal electrical
> > > security, how can the use of the DS2432 provide
> > any security, much
> > > less peace of mind?  It would seem that it would
> > only make the
> > > reverse engineering of the 56F8xx code marginally
> > more difficult.
> > >
> > > How can the expense of 3.9 euros be justified if
> > the device cannot,
> > > by itself, provide any significant or tangible
> > security?
> > >
> > > --david
> > >
> > > --- In motoroladsp@y..., giuliano.to@q... wrote:
> > > >
> > > > Ok, I found another that using DS2432!
> > > > Which is code size to decode DS2432 information
> > ?
> > > >
> > > > P.S.  DS2432 seems expensive (for my applicaton)
> > (around 3.9 euro).
> > > >
> > > >
> > > > Regards,
> > > > Giuliano
> > > >
> > >
> > > >Simon Lightbody
> > > ><Simon.Lightbody@
> > > >Per: "'giuliano.to@q...'" <giuliano.to@q...>,
> > > >     pwrm.com>
> > > >     motoroladsp@y...
> > > >Cc:
> > > >     11/10/02 16.55
> > > >Oggetto:  RE: [motoroladsp] Protecting firmware
> > in 5680x
> > > >
> > > >
> > > > We use this part for this purpose. Apart from
> > the normal problems
> > > with
> > > > Maxim, I haven't heard any specific problems
> > getting this part.
> > > >
> > > > Of course, this is not as good a solution as if
> > Motorola had
> > > provided some
> > > > security bits in their part.
> > > >
> > > > -----Original Message-----
> > > > From: giuliano.to@q... [mailto:giuliano.to@q...]
> > > > Sent: October 11, 2002 5:56 AM
> > > > To: motoroladsp@y...
> > > > Subject: [motoroladsp] Protecting firmware in
> > 5680x
> > > >
> > > >
> > > > In order to avoid that anyone can clone my
> > product, I ask you if is
> > > there
> > > > any possibility or idea to protect firmware when
> > my product is
> > > delivered.
> > > > Are you sensible to this problem ?
> > > > I'm evaluationg MAXIM DS2432 but (it seems
> > difficult to obtains)
> > > > Thanak you
> > > > Giuliano
> >
> >
>
>
> __________________________________________________
>



_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


David,

This newgroup is providing an approach to protect your
investment. Is there 100% security? I said No. For me,
I only give the people who wants to copy my design a
big headache. So he or she should consider whether it
is worth to copy my desgin. If people is smart enough
to copy my design, he or she should be smart enough to
do a design that is even better mine. I can do many
things to protect my design. I can make PCB board to
be very difficulty to be copied. I can sand off the
marks or labels on some of devices. I can put some
data tables inside my program, so the people wouldn't
easily disassemble my code. So copy cat can copy my
DSP code but it cannot copy my products.

Charlie W

--- Davie <> wrote:
> But even with secure external memory, once the code
> is up and running
> in the DSP, there is very little to stop one from
> pulling the contents
> of FLASH and RAM out of the DSP.
>
> Since there is no security built into the DSP, what
> real security is
> provided by any secure external devices? Why bother
> spending the
> money on relatively expensive secure devices and
> time designing and
> debugging code to utilize them if they don't add
> anything tangible?
>
> Multiple supervisory devices like the XBox would
> only work if they
> were secure and their real function in the system
> could be obscured or
> hidden. Most 56F8xx applications (if not all) are
> nowhere near the
> complexity of an XBox. If the supervisory devices
> control something
> or turn something off that needs to be on, it can be
> discovered and
> emulated... Again, no real security after a whole
> lot of design and
> debug effort to implement in the first place.
>
> Physical access to the application board coupled
> with the lack of
> security in the 56F8xx unavoidably makes for
> unsecurable designs.
> There's no way around that with 56F8xx devices short
> of blowing
> JTAG/OnCE pins after programming. And even then,
> the DSP could
> probably be brought up with external memory and be
> made to dump the
> contents of internal FLASH without even bothering
> with the JTAG/OnCE
> at all...
>
> --david >
>
> --- In motoroladsp@y..., Charlie W <charliewtx@y...>
> wrote:
> > Jeff provides an effective approch to protect your
> > code. You also can use a so-called Secure Memory
> to
> > protect your design. Atmel has both Secure Memory
> and
> > Secure MCU to provide security feature for your
> > design. The low cost solution is to place a part
> of
> > you DSP code in an Atmel 8951 MCU. When power on,
> > transfer the this piece of code for 8951 to DSP's
> > internal data or program memory. 8951 has the
> > security lock for its internal flash memory.
> >
> > Charlie W.
> >
> > --- Jeff Brower <jbrower@s...> wrote:
> > > David-
> > >
> > > The issue of code security was recently
> discussed on
> > > the C54xx group and on
> > > comp.dsp. The consensus is that something like
> the
> > > Xbox approach is required. What
> > > Microsoft did was implement a small, inexpensive
> > > "shadow" microcontroller that has
> > > built-in code security features. The uC feeds
> > > encrypted data to the Pentium (568xx
> > > DSP in your case), and -- most importantly --
> > > performs watchdog and monitoring
> > > functions to detect tampering. For example, any
> > > type of anomaly in boot-up sequence
> > > or timing, any halt or pause during normal
> operation
> > > (possible indication of JTAG
> > > debugging), etc. causes the uC to shut the
> system
> > > down. Or worse, cause a pwr-gnd
> > > short or otherwise do something unpleasant to
> the
> > > PCB.
> > >
> > > If you search the comp.dsp archives, you should
> be
> > > able to find some links to web
> > > pages where people have been working amazingly
> hard
> > > and in micro-detail to pull apart
> > > the Xbox. What they have accomplished and
> learned
> > > reminds anyone who doubts what is
> > > possible in terms of reverse engineering given
> > > enough effort. It appears they now
> > > know more about the Xbox overall then some of
> the
> > > specialized hw/sw team members who
> > > worked on it at Microsoft. They have been able
> to
> > > usurp the board for their own use
> > > (e.g. to run Linux or other OS), but evidently
> have
> > > not been able to get hold of any
> > > Microsoft (or video game) code of value -- a
> > > testament to Microsoft's basic method to
> > > security.
> > >
> > > Jeff Brower
> > > DSP sw/hw engineer
> > > Signalogic
> > >
> > >
> > > Davie wrote:
> > > >
> > > > I was reading the DS2432 data sheet and
> several
> > > white papers from
> > > > Maxim/Dallas Semiconductor about their 1-Wire
> > > security devices.
> > > >
> > > > It fairly explicitly states at the end of one
> of
> > > the white papers
> > > >
> > >
> >
>
(http://www.maxim-ic.com/appnotes.cfm/appnote_number/1098)
> > > that in
> > > > order to preserve the security of the system
> from
> > > physcial attacks,
> > > > the reading of the firmware in the SCU
> (service
> > > control unit -
> > > > DSP56F8xx in this case) needs to be prevented.
> > > >
> > > > Since the 56F8xx family does not provide any
> > > internal electrical
> > > > security, how can the use of the DS2432
> provide
> > > any security, much
> > > > less peace of mind? It would seem that it
> would
> > > only make the
> > > > reverse engineering of the 56F8xx code
> marginally
> > > more difficult.
> > > >
> > > > How can the expense of 3.9 euros be justified
> if
> > > the device cannot,
> > > > by itself, provide any significant or tangible
> > > security?
> > > >
> > > > --david
> > > >
> > > > --- In motoroladsp@y..., giuliano.to@q...
> wrote:
> > > > >
> > > > > Ok, I found another that using DS2432!
> > > > > Which is code size to decode DS2432
> information
> > > ?
> > > > >
> > > > > P.S. DS2432 seems expensive (for my
> applicaton)
> > > (around 3.9 euro).
> > > > >
> > > > >
> > > > > Regards,
> > > > > Giuliano
> > > > >
> > > >
> > > > >Simon Lightbody
> > > > ><Simon.Lightbody@
> > > > >Per: "'giuliano.to@q...'" <giuliano.to@q...>,
> > > > > pwrm.com>
> > > > > motoroladsp@y...
> > > > >Cc:
> > > > > 11/10/02 16.55
> > > > >Oggetto: RE: [motoroladsp] Protecting
> firmware
> > > in 5680x
> > > > >
> > > > >
> > > > > We use this part for this purpose. Apart
> from
> > > the normal problems
> > > > with
> > > > > Maxim, I haven't heard any specific problems
> > > getting this part.
> > > > >
>
=== message truncated === __________________________________________________