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 === __________________________________________________ |