Sign in

Search adsp

Subscribe to adsp

adsp by Keywords

Discussion Groups

Discussion Groups | Analog Devices DSPs | Code protection

Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).

Post a new Thread

Code protection - asdfatih - Oct 16 13:01:00 2003

I am using ADSP 21992 with eprom boot, Do you know how to manage code protection.

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: Code protection - Dieter Teuchert - Oct 16 15:47:00 2003

Hi, i think a practical solution is to build a unique number into the hardware, like a DS18B20 1-wire thermometer. That device contains a unique, laser-burnt 48 bit id. The device is complicated enough to not be easily faked by some GAL or PAL, since 1-wire has rather elaborate timing conditions. You will have to implement that interface in your firmware. Maxim provides example source code. Then you can put a unique firmware into your signal processor device that will not run unless the thermometer chip with the expected id is present. Nobody can order lots of those thermometer chips with a certain ID from MAXIM. If you use EEPROM, you can feed your device with a "mother" version of firmware that will modify itself and "lock" onto the actual id present during first boot. Then you have to watch out not to deliver devices without booting them once. I guess you will boot them anyway for QM. Then you save the effort of handling a different firmware version for each device. Using this cheap method you can force a potential attacker into analyzing your binary instead of just copying it. If your processor has a jtag interface, you should try to make it physically inaccessible in order to remove this analysis entry point. In our case we had a SPI EEPROM and we could dig the MISO data line into the multilayer to have binary data physically inaccessible, too. Blackfin processor and EEPROM have ballgrid-type packages. There has been another thread on this issue in July with some long EMails, see "DSP binary protection". Regards D. Teuchert asdfatih wrote: > I am using ADSP 21992 with eprom boot, Do you know how to manage >code protection. > > >_____________________________________ >/groups.php3

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: Code protection - Mike Rosing - Oct 16 16:27:00 2003

On Thu, 16 Oct 2003, asdfatih wrote: > I am using ADSP 21992 with eprom boot, Do you know how to manage > code protection. You can't. One way around it is to use something like a PIC which has protected flash, so instead of letting the adsp do something "secret", let the PIC do that part. The PIC turns on with code inside. The 21992 can be built so the lines to the eprom are scrambled. That will slow people down, but it won't stop them from stealing your code. Unless it is inside the chip, you can't protect it. Here's an idea tho: if you boot the 21992 with a public key algorithm, and have the PIC hold the code, you can generate random public keys on every boot and use some simple thing like Diffie-Hellman key exchange to create a common secret key in both the PIC and 21192. The real trick here is "random", and how well you make it truely random determines how much work your adversary has to do to beat this method. But that means the 21192 has to waste space with both the key exchange code and decryption code. Patience, persistence, truth, Dr. mike

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: Code protection - Steve Holle - Oct 16 16:59:00 2003

Dallas also makes devices that are just the 48-bit ID in a 3-pin package. Very inexpensive.

At 09:47 AM 10/16/2003, Dieter Teuchert wrote:

Hi,
i think a practical solution is to build a unique number into the
hardware, like a DS18B20 1-wire thermometer. That device contains a
unique, laser-burnt 48 bit id. The device is complicated enough to not
be easily faked by some GAL or PAL, since 1-wire has rather elaborate
timing conditions. You will have to implement that interface in your
firmware. Maxim provides example source code.

Then you can put a unique firmware into your signal processor device
that will not run unless the thermometer chip with the expected id is
present. Nobody can order lots of those thermometer chips with a certain
ID from MAXIM.

If you use EEPROM, you can feed your device with a "mother" version of
firmware that will modify itself and "lock" onto the actual id present
during first boot. Then you have to watch out not to deliver devices
without booting them once. I guess you will boot them anyway for QM.
Then you save the effort of handling a different firmware version for
each device.

Using this cheap method you can force a potential attacker into
analyzing your binary instead of just copying it.
If your processor has a jtag interface, you should try to make it
physically inaccessible in order to remove this analysis entry point.

In our case we had a SPI EEPROM and we could dig the MISO data line into
the multilayer to have binary data physically inaccessible, too.
Blackfin processor and EEPROM have ballgrid-type packages.

There has been another thread on this issue in July with some long
EMails, see "DSP binary protection".

Regards
D. Teuchert

asdfatih wrote:

> I am using ADSP 21992 with eprom boot, Do you know how to manage
>code protection. >
>
>_____________________________________
>/groups.php3 >
>

_____________________________________
/groups.php3

-------------------------- Steve Holle Link Communications, Inc. 1035 Cerise Road Billings, Montana 59101-7378 406.245.5002 s...@link-comm.com --------------------------

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )