DSPRelated.com
Forums

Program intellectual property protection on DM648

Started by vcar August 21, 2008
In my project DM648 is used, and it boots from external EEPROM via SPI
interface. While for intellectual property protection reason after
mass production, what kind of methodology could I use? My concern is
about how to encrypt the data in EEPROM with the help of TI's
development tool chain. However I found nothing about code security or
anti-crack scheme at www.ti.com.
Can anyone tell me how to protect my design stored in the EEPROM in a
convenient way?
Is there anybody who can give some advice? I think this is very common
problem in product design.
Hello vcar,

What would you suggest ?
Let's assume I am an engineer hooking up with a Logic Analyser to your SPI 
interface.
Afterwards I play the recorded code into a non protected board booting my 
DSP with the same code.
Now I can analyse everything disregarding what you've scrambled while 
loading.

                                                    Regards, Greg.


"vcar" <hitsx@hit.edu.cn> schrieb im Newsbeitrag 
news:c8fcf81a-4417-4d37-9994-5041b583fc8c@z11g2000prl.googlegroups.com...
> Is there anybody who can give some advice? I think this is very common > problem in product design.
On Aug 22, 8:51&#4294967295;am, vcar <hi...@hit.edu.cn> wrote:
> Is there anybody who can give some advice? I think this is very common > problem in product design.
There's always explosive potting compound! For real security you need a processor that holds its code internally in an eprom or equiv. Also you will need to pop the security fuse to disable the reading out of the code. This is good but won't completely secure against someone willing to pry open the chip and attach electrodes to the right spot to read the code. The amount of protection needs to go hand in hand with the value of what you are protecting. How about a patent to at least give you legal protection? But be prepared to spend money aggresively going after those who violate your method. Clay
On Aug 25, 2:56&#4294967295;pm, "Greg" <G...@nospam.ca> wrote:
> Hello vcar, > > What would you suggest ? > Let's assume I am an engineer hooking up with a Logic Analyser to your SPI > interface. > Afterwards I play the recorded code into a non protected board booting my > DSP with the same code. > Now I can analyse everything disregarding what you've scrambled while > loading. > > &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; Regards, Greg. > > "vcar" <hi...@hit.edu.cn> schrieb im Newsbeitragnews:c8fcf81a-4417-4d37-9994-5041b583fc8c@z11g2000prl.googlegroups.com... > > > > > Is there anybody who can give some advice? I think this is very common > > problem in product design.- Hide quoted text - > > - Show quoted text -
As you have said, you can read the content of SPI EEPROM, so you can get everything you want. Even I will check the DSP Chip ID in my program, you can crack it away by disassembling the program code. So this is the typical situation. The problem is what could I do to prevent this kind of matter happen. Althought it is very hard to be protected completedly, I want to increase the crack cost as much as possible.

vcar wrote:


> As you have said, you can read the content of SPI EEPROM, so you can > get everything you want. Even I will check the DSP Chip ID in my > program, you can crack it away by disassembling the program code. So > this is the typical situation. > The problem is what could I do to prevent this kind of matter happen. > Althought it is very hard to be protected completedly, I want to > increase the crack cost as much as possible.
The managerial problems can't be resolved by any technical means. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
vcar <hitsx@hit.edu.cn> writes:

> On Aug 25, 2:56&#4294967295;pm, "Greg" <G...@nospam.ca> wrote: >> Hello vcar, >> >> What would you suggest ? >> Let's assume I am an engineer hooking up with a Logic Analyser to your SPI >> interface. >> Afterwards I play the recorded code into a non protected board booting my >> DSP with the same code. >> Now I can analyse everything disregarding what you've scrambled while >> loading. >> >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; Regards, Greg. >> >> "vcar" <hi...@hit.edu.cn> schrieb im Newsbeitragnews:c8fcf81a-4417-4d37-9994-5041b583fc8c@z11g2000prl.googlegroups.com... >> >> >> >> > Is there anybody who can give some advice? I think this is very common >> > problem in product design.- Hide quoted text - >> >> - Show quoted text - > > As you have said, you can read the content of SPI EEPROM, so you can > get everything you want. Even I will check the DSP Chip ID in my > program, you can crack it away by disassembling the program code. So > this is the typical situation. > The problem is what could I do to prevent this kind of matter happen. > Althought it is very hard to be protected completedly, I want to > increase the crack cost as much as possible.
This sort of protection would have to be built into the DM648 itself, Since it's not, you can't use the usual methods (encryption, e.g.). You _could_ obfuscate your code at the source level, though. -- % Randy Yates % "The dreamer, the unwoken fool - %% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Eldorado Overture', *Eldorado*, ELO http://www.digitalsignallabs.com
On Thu, 28 Aug 2008 04:58:40 -0400, Randy Yates <yates@ieee.org>
wrote:

>vcar <hitsx@hit.edu.cn> writes: > >> On Aug 25, 2:56&#4294967295;pm, "Greg" <G...@nospam.ca> wrote: >>> Hello vcar, >>> >>> What would you suggest ? >>> Let's assume I am an engineer hooking up with a Logic Analyser to your SPI >>> interface. >>> Afterwards I play the recorded code into a non protected board booting my >>> DSP with the same code. >>> Now I can analyse everything disregarding what you've scrambled while >>> loading. >>> >>> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; Regards, Greg. >>> >>> "vcar" <hi...@hit.edu.cn> schrieb im Newsbeitragnews:c8fcf81a-4417-4d37-9994-5041b583fc8c@z11g2000prl.googlegroups.com... >>> >>> >>> >>> > Is there anybody who can give some advice? I think this is very common >>> > problem in product design.- Hide quoted text - >>> >>> - Show quoted text - >> >> As you have said, you can read the content of SPI EEPROM, so you can >> get everything you want. Even I will check the DSP Chip ID in my >> program, you can crack it away by disassembling the program code. So >> this is the typical situation. >> The problem is what could I do to prevent this kind of matter happen. >> Althought it is very hard to be protected completedly, I want to >> increase the crack cost as much as possible. > >This sort of protection would have to be built into the DM648 itself, >Since it's not, you can't use the usual methods (encryption, e.g.). > >You _could_ obfuscate your code at the source level, though.
There are some automated code obsfuscators out there that are pretty hilarious to use. You put your code in and the comments come out translated into your choice of Muppets Swedish Chef speak or a wide variety of difficult-to-read accents. They're actually pretty effective, but also highly silly. We've considered using them a couple of times, but pretty much chicken out when it comes down to it. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php

Eric Jacobsen wrote:

> There are some automated code obsfuscators out there that are pretty > hilarious to use. You put your code in and the comments come out > translated into your choice of Muppets Swedish Chef speak or a wide > variety of difficult-to-read accents. They're actually pretty > effective, but also highly silly. We've considered using them a > couple of times, but pretty much chicken out when it comes down to it.
The real purpose of those obfuscators is to overcome the source code publishing requirement imposed by the GPL. So the obfuscated sources can be technically published however it will not benefit to anyone else. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Eric Jacobsen wrote:
> There are some automated code obsfuscators out there that are pretty > hilarious to use. You put your code in and the comments come out > translated into your choice of Muppets Swedish Chef speak or a wide > variety of difficult-to-read accents. They're actually pretty > effective, but also highly silly. We've considered using them a > couple of times, but pretty much chicken out when it comes down to it.
That makes me think of the language preferences available at Google. Go to google, click "Preferences", and change the Interface language to one of these: Bork, bork, bork! Elmer Fudd Hacker Klingon Pig Latin Changing it back to your real preference can be tricky though! -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 A pessimist is an optimist with experience