Matthias Weingart wrote:
> On Thu, Jul 08, 2004 at 05:29:36PM +0200,
Dieter Teuchert wrote:
>
>
>>Unless you need other peripherals of the MSP430, here another proposal
>>for DSP firmware security:
>>
>>Combine a flash with a laser ID chip (Single Wire).
>>
>>Then you need the capability in the DSP firmware to read the ID. Then
>>the firmware can modify itself during the first boot such as to boot and
>>function later only with the unique id present (use ID for encryption).
>>Imitating the ID chip is "impossible".
>
>
> It is quite simple to imitate a Dallas one wire serial number chip
(DS2401?)
> by a PLD or even a faster microcontroller. They store just some bits, no
> encryption, no special security. You just need to know the serial number
> and as far as I remember the number is printed on the button-type case.
The 2401 is a bit small to print the serial number on :> Its a 6 pin
SOIC(I think that's the package). Also, the full 64 bits aren't
unique,
there are 8 bits of family code and 8 bits of CRC8 checksum. The
remaining 48 bits are sequential from the factory, so figuring out a
range to brute force isn't too difficult.
But its better than nothing :)
Brian
--
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design
On Thu, Jul 08, 2004 at 05:29:36PM +0200, Dieter Teuchert wrote:
> Unless you need other peripherals of the MSP430,
here another proposal
> for DSP firmware security:
>
> Combine a flash with a laser ID chip (Single Wire).
>
> Then you need the capability in the DSP firmware to read the ID. Then
> the firmware can modify itself during the first boot such as to boot and
> function later only with the unique id present (use ID for encryption).
> Imitating the ID chip is "impossible".
It is quite simple to imitate a Dallas one wire serial number chip (DS2401?)
by a PLD or even a faster microcontroller. They store just some bits, no
encryption, no special security. You just need to know the serial number
and as far as I remember the number is printed on the button-type case.
M.
Reply by Brian C. Lane●July 8, 20042004-07-08
onestone wrote:
> Neat idea. Inefficient ;@} but neat. I have to
admit security has never
Thanks :) Its actually not too terrible, overhead for the load is
minimal, being a start address and count and most of the code goes into
contiguous memory so most of the usage is raw data. but it would be nice
to have it compressed as well -- that's on the list of stuff to do as
soon as there's time (or I totally run out of space).
> been of huge concern to me in micros, having , for
a while, specialised
> in reverse engineering. It became obvious to me that functional
> reproduction is far cheaper than expensive software cracks. The only
> thing I do is have a few code or data tables that are real, but which,
> when decoded show a copyright message. Other than that first in best
> dressed, keep every code copy, and have the next 4 versions ready before
> mk 1 gets released.
A copyright notice is a must if you ever have to go to court to prove
that someone has copied your code. On some older Motorola parts they had
'extra' opcode values that could be used to obscure some pieces of
code,
but in the end if you can read it you can copy it and you can eventually
understand it and reproduce it.
The '430 was a part we were already using and has the added benefit of
having a large flash (most of which was not being used by '430 code)
and the JTAG fuse blowing feature. We also looked hard at the LPC21xx
series but they have no code protection at all.
Brian
--
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design
Reply by Brian C. Lane●July 8, 20042004-07-08
Dieter Teuchert wrote:
>
> Unless you need other peripherals of the MSP430, here another proposal
> for DSP firmware security:
>
> Combine a flash with a laser ID chip (Single Wire).
>
> Then you need the capability in the DSP firmware to read the ID. Then
> the firmware can modify itself during the first boot such as to boot and
> function later only with the unique id present (use ID for encryption).
> Imitating the ID chip is "impossible".
>
> In this way you can choose the flash you like, development is only for
> one processor (the DSP) and you have a true serial number built into
> your device. If you choose a singlewire temperature sensor as ID, you
> have the temperature sensor of the MSP430 replaced, too.
The problem is that the code is still in the flash, and some part of it
has to be 'in the clear' in order for the DSP to boot. It would be
nice
if TI had built a 'secure bootloader' into the DSP so that the flash
could be encrypted (or at least obscured to some degree).
The basic problem is that if the code passes across wires it can be
sniffed, disassembled and copied. The real solution is DSP's with
integrated flash for booting.
I should probably stop before I get into trouble for talking too much
(don't you just love working with closed source).
Brian
--
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design
Reply by Dieter Teuchert●July 8, 20042004-07-08
Brian C. Lane wrote:
>onestone wrote:
>
>
>
>>Hi Brian
>>
>>Perhaps you'd be better off with a DSP? I do use the MSP430 for
DSP, but
>>primarily for fairly simple filters, and, at 8k sample rate still
can't
>>
>>
>
>Not to give too much away, but the code is for a DSP. The '430 has a TI
>DSP's host port connected to a bunch of its I/O pins. The DSP code is
>loaded into the DSP's RAM at bootup. Putting the DSP code into a
'430
>with the fuse blown is a bit more secure than having it hanging out in a
> flash attached to the DSP.
>
>Brian
>
>
>
Unless you need other peripherals of the MSP430, here another proposal
for DSP firmware security:
Combine a flash with a laser ID chip (Single Wire).
Then you need the capability in the DSP firmware to read the ID. Then
the firmware can modify itself during the first boot such as to boot and
function later only with the unique id present (use ID for encryption).
Imitating the ID chip is "impossible".
In this way you can choose the flash you like, development is only for
one processor (the DSP) and you have a true serial number built into
your device. If you choose a singlewire temperature sensor as ID, you
have the temperature sensor of the MSP430 replaced, too.
Regards
D. Teuchert
--
Dipl.-Phys. Dieter Teuchert
Software und Systeme
Postanschrift:
Telefon:
Telefax:
EMail Firma:
EMail perslich:
Internet:
Rommelstr. 6
D-76571 Gaggenau
Germany
+49 7225 989253
+49 7225 989254
info@info...
dieter@diet...
_http://www.cadt.de_
Reply by onestone●July 7, 20042004-07-07
Neat idea. Inefficient ;@} but neat. I have to admit security has never
been of huge concern to me in micros, having , for a while, specialised
in reverse engineering. It became obvious to me that functional
reproduction is far cheaper than expensive software cracks. The only
thing I do is have a few code or data tables that are real, but which,
when decoded show a copyright message. Other than that first in best
dressed, keep every code copy, and have the next 4 versions ready before
mk 1 gets released.
Al
Brian C. Lane wrote:
> onestone wrote:
>
>
>>Hi Brian
>>
>>Perhaps you'd be better off with a DSP? I do use the MSP430 for
DSP, but
>>primarily for fairly simple filters, and, at 8k sample rate still
can't
>
>
> Not to give too much away, but the code is for a DSP. The '430 has a
TI
> DSP's host port connected to a bunch of its I/O pins. The DSP code is
> loaded into the DSP's RAM at bootup. Putting the DSP code into a
'430
> with the fuse blown is a bit more secure than having it hanging out in a
> flash attached to the DSP.
>
> Brian
>
Reply by onestone●July 7, 20042004-07-07
Richard (UK). wrote:
>>>I do use the MSP430 for DSP, but primarily
for fairly simple filters, and, at 8k sample rate still can't
>
> manage more than 6 in real time,
>
> Hi Al,
>
> Interesting post. Is that 6 taps or 6 filters?
6 off 4 pole low pass filters, but they are a very special filter case.
I'm trying to get 48 in real time to duplicate some work I did on an
ADSP2105 back in 1993, hence my interest in clock doubling.
Al
>
> regards,
>
> Richard (UK)
>
>
>
> ----- Original Message -----
> From: "onestone" <onestone@ones...>
> To: <msp430@msp4...>
> Sent: Wednesday, July 07, 2004 3:29 AM
> Subject: Re: [msp430] Guru needed
>
>
>
>>Hi Brian
>>
>>Perhaps you'd be better off with a DSP? I do use the MSP430 for
DSP, but
>>primarily for fairly simple filters, and, at 8k sample rate still
can't
>>manage more than 6 in real time, but the code is tiny, even FFT code is
>>tiny, larger if you implement a radix-2 Cooley-Tukey algorithm, but
>>typically less than 1k even for large sample sizes.The base algorithm,
>>implemented as a brute force pair of loops requires much less memory. Of
>>course if you have your tables for sin/cos in memory that will eat up a
>>lot of space very quickly.
>>
>>Al
>>
>>
>>
>>Brian C. Lane wrote:
>>
>>
>>>Jonathan Kirwan wrote:
>>>
>>>
>>>
>>>>On Tue, 06 Jul 2004 20:07:43 +0930, Al wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I'd look at the application to figure out why and how
you managed to use
>>>>>up so much memory.
>>>>
>>>>
>>>>Probably using someone's C compiler, I bet. There's
the problem. ;)
>>>>
>>>
>>>
>>>I must be finally getting the hang of MSP430 assembly. I can now
take
>>>some of the assembly produced by ICC430 and make it smaller :)
>>>
>>>In my case I have a bunch (50kbytes or so) of DSP code that is
eating up
>>>most of my '430 flash. The next step is to try to compress the
code a
>>>bit to save some space. Does anyone have any suggestions for simple
to
>>>implement code de-compression routines?
>>>
>>>Brian
>>>
>>>
>>
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/04
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Reply by onestone●July 7, 20042004-07-07
Marco I still believe you have a lot to gain by taking a longer look at
data compression, and I don't just mean conventional methods like huffman.
Al
marcostucchi2000 wrote:
> --- In msp430@msp4..., "Paul Curtis"
<plc@r...> wrote:
>
>>Marco,
>>
>>That truly is ROM, otherwise it could be upgraded--and TI don't
>
> upgrade
>
>>the BSL, they put patches in RAM (the "patch.txt" file).
>>
>>-- Paul.
>>
>
>
> Thank you Paul !
>
> I hoped it was not ROM ( why put a small amount of memory of a
> different technology (+$) in a chip ? ). It's more likely that
it's a
> flash region not writable. And if it is so, it's too tricky for a TI
> fellow not to put a workaround ( that is not to be made available to
> customer, of course )
>
>
> Thanks also to all other replies, but I already have huffman
> compression implemented for string management, some code in assembler
> ( I love it ), some data already compressed and some C code for LCD
> management.
>
> The right answer is to change micro, but not after 2 years work on a
> product sold in 25k pieces/year, and TI rolls out new version but for
> flash size.
>
> bye, Marco
>
>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Reply by Jonathan Kirwan●July 7, 20042004-07-07
On Wed, 07 Jul 2004 08:25:27 -0700, you wrote:
>Not to give too much away, but the code is for a
DSP. The '430 has a TI
>DSP's host port connected to a bunch of its I/O pins. The DSP code is
>loaded into the DSP's RAM at bootup. Putting the DSP code into a
'430
>with the fuse blown is a bit more secure than having it hanging out in a
> flash attached to the DSP.
Been there, done that. But using a PIC18 and an ADSP-2184. DSP memory on the
2184 is only 12kbyte, though, so that's all the space that was required
from the
flash on the PIC.
Jon
Reply by Brian C. Lane●July 7, 20042004-07-07
onestone wrote:
> Hi Brian
>
> Perhaps you'd be better off with a DSP? I do use the MSP430 for DSP,
but
> primarily for fairly simple filters, and, at 8k sample rate still
can't
Not to give too much away, but the code is for a DSP. The '430 has a TI
DSP's host port connected to a bunch of its I/O pins. The DSP code is
loaded into the DSP's RAM at bootup. Putting the DSP code into a '430
with the fuse blown is a bit more secure than having it hanging out in a
flash attached to the DSP.
Brian
--
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design
