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 |
|
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 _____________________________________ 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-----
But even with
secure external memory, once the code is
up and running 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 === __________________________________________________ |