Security issue with MSP430?

I heard there is a security issue with the MSP430. Anybody able to 
verify this rumour? Allegedly, if the JTAG is disabled there exists a 
back door to download the code and it has something to do with the 
interrupt vector table.

Please help me verify if this is a real issue or not. Need to make quick 
decision for large volume design, soon. Cannot afford any security 
issues in this design. Maybe I'll go for an AVR instead.

Thanks,
HP

On Thu, 12 May 2005 10:11:33 +0300, HP wrote:

> I heard there is a security issue with the MSP430. Anybody able to 
> verify this rumour? Allegedly, if the JTAG is disabled there exists a 
> back door to download the code and it has something to do with the 
> interrupt vector table.
> 

It's not a "back door", it's an alternative method of programming the
chips.  Lots of flash-based micros (including the AVR) have something
similar.  In almost all cases, "security" means that no one can read out
the program in the chip, or modify it without completly erasing and
replacing it, unless they know a password of some sort.  In common with
other devices, the msp430 uses the interrupt vector table as a password -
easily obtained for those with access to the original program, but
impossible to guess.  Without the password, the only thing someone can do
is erase the chip - they can then program it with another program, but
your original program is gone.

> Please help me verify if this is a real issue or not. Need to make quick 
> decision for large volume design, soon. Cannot afford any security 
> issues in this design. Maybe I'll go for an AVR instead.

If you can't afford any security issues, you are in the wrong business. 
There are *always* ways to break any security.  But the security of
msp430's, in common with the AVR and lots of other devices, is pretty good
- getting a copy of the code out of one of these chips (assuming you apply
the security options appropriately) involves cutting the chips open and
using specialist hardware like electron microscopes.  For most purposes,
the devices are not the weak link in the system - it is the developers and
others in the company producing the system.

> 
> Thanks,
> HP

On Thu, 12 May 2005 10:11:33 +0300, HP <maustekastike@yahoo.com>
wrote:

>I heard there is a security issue with the MSP430. Anybody able to 
>verify this rumour? Allegedly, if the JTAG is disabled there exists a 
>back door to download the code and it has something to do with the 
>interrupt vector table.

To be a little less hand-waving than this, many of the earlier MSP430s
(the newer ones have some newer features on this point) have a "BSL"
program that is burned into ROM and cannot be disabled even when the
JTAG fuse is physically blown and the JTAG can no longer be used.  To
"unlock" the BSL for reading out code, it is necessary to provide a
password that consists of the entire IVT.  On smaller flash devices,
the addresses that the IVT might point to are similarly limited and
that might make such an "attack" a bit easier on them.  But it's not
exactly easy, though possible.  Some newer devices, I believe, include
a BSL with a feature where an incorrect password causes a bulk flash
erase.  That should nearly eliminate this "back-door" into the CPU.

For the older devices without that latest BSL feature, it's better to
make sure you place random "garbage" at all the IVT locations to help
make guessing the right 32 bytes required to enable access.

>Please help me verify if this is a real issue or not. Need to make quick 
>decision for large volume design, soon. Cannot afford any security 
>issues in this design. Maybe I'll go for an AVR instead.

Every CPU has its source of attacks.  I think some of the AVRs erase
their lock bits first, so that a properly timed attack can wind up
enabling the memory on them.  But I'm as vague on this as you were on
the MSP430.  My point isn't to accuse the AVR so much as to point out
that you need to carefully investigate the EXACT DETAILS of any choice
you might make, here.

...

Since you say this is for a large volume design, I think that should
mean there is sufficient reason to afford substantial due diligence on
your part.  Do your work, do it thoroughly.  There are PhD theses on
this subject, a variety of other articles, studies of processor
security including the MSP430 and the AVR, people at TI you should be
talking to, etc.  (In fact, I'm sure that TI would be very able at
helping you clearly apprehend the known issues.)

Regarding the MSP430, you should have already been well aware of what
I mentioned above -- not just the "something to do with" vagueness.
It's not even a slight interest of mine, yet it was no effort at all
to find the above details.  You said "quick decision" and it took me
only a few minutes to find it.  If you are really serious, you should
have already gleaned at least this much before posting (in my
opinion.)  Probably much more.  Which tells me a lot about the level
of effort you've expended so far...

Sorry about the snippy tone, but you aren't talking "hobby" here.  I
think you could have done at least the tiny amount of digging I did
before writing your query, especially in the situation you outline.

Oh, well.

Jon

David wrote:

> On Thu, 12 May 2005 10:11:33 +0300, HP wrote:
> 
>>I heard there is a security issue with the MSP430. Anybody able to 
>>verify this rumour? Allegedly, if the JTAG is disabled there exists a 
>>back door to download the code and it has something to do with the 
>>interrupt vector table.
> 
> It's not a "back door", it's an alternative method of programming the
> chips.  Lots of flash-based micros (including the AVR) have something
> similar.  In almost all cases, "security" means that no one can read out
> the program in the chip, or modify it without completly erasing and
> replacing it, unless they know a password of some sort.  In common with
> other devices, the msp430 uses the interrupt vector table as a password -
> easily obtained for those with access to the original program, but
> impossible to guess.  Without the password, the only thing someone can do
> is erase the chip - they can then program it with another program, but
> your original program is gone.
> 
>>Please help me verify if this is a real issue or not. Need to make quick 
>>decision for large volume design, soon. Cannot afford any security 
>>issues in this design. Maybe I'll go for an AVR instead.
> 
> If you can't afford any security issues, you are in the wrong business. 
> There are *always* ways to break any security.  But the security of
> msp430's, in common with the AVR and lots of other devices, is pretty good
> - getting a copy of the code out of one of these chips (assuming you apply
> the security options appropriately) involves cutting the chips open and
> using specialist hardware like electron microscopes.  For most purposes,
> the devices are not the weak link in the system - it is the developers and
> others in the company producing the system.
> 
> 
>>Thanks,
>>HP

Thanks, David,

Let's not call it a back door, then. But it certainly is a flaw in the 
design. Guessing a 256-bit password on random may take some time, but 
there are other methods available. Such methods include messing around 
with the supply voltage, temperature, and frequency. Well-known methods 
such as Differential Power Analysis (DPA) can be used to monitor the 
decoding of the password. Other methods exist. The MSP430 is not 
designed around the same principles as, say, smart card microcontrollers 
and leaves many security issues wide open. In addition, the bootstrap 
loader is ROM-coded, which  means it is the same in all devices and the 
password is always stored at the same location and is always the same 
length. Sounds very risky to me.

Now compare this to an AVR, where the same bootstrap functionality is 
achieved with a fully custom and customisable boot loader. The loader 
and any password can be resized, reallocated or reprogrammed during any 
firmware update. And even in between, thanks to self-programming.

I think the AVR would let me sleep my nights better.

BTW, you cannot read the firmware out from a Flash microcontroller using 
an electron microscope.

Cheers,
HP

Jonathan Kirwan wrote:
> On Thu, 12 May 2005 10:11:33 +0300, HP <maustekastike@yahoo.com>
> wrote:
>
> >I heard there is a security issue with the MSP430. Anybody able to
> >verify this rumour? Allegedly, if the JTAG is disabled there exists
a
> >back door to download the code and it has something to do with the
> >interrupt vector table.
>
> To be a little less hand-waving than this, many of the earlier
MSP430s
> (the newer ones have some newer features on this point) have a "BSL"
> program that is burned into ROM and cannot be disabled even when the
> JTAG fuse is physically blown and the JTAG can no longer be used.  To
> "unlock" the BSL for reading out code, it is necessary to provide a
> password that consists of the entire IVT.  On smaller flash devices,
> the addresses that the IVT might point to are similarly limited and
> that might make such an "attack" a bit easier on them.  But it's not
> exactly easy, though possible.  Some newer devices, I believe,
include
> a BSL with a feature where an incorrect password causes a bulk flash
> erase.  That should nearly eliminate this "back-door" into the CPU.
>
> For the older devices without that latest BSL feature, it's better to
> make sure you place random "garbage" at all the IVT locations to help
> make guessing the right 32 bytes required to enable access.
>
> >Please help me verify if this is a real issue or not. Need to make
quick
> >decision for large volume design, soon. Cannot afford any security
> >issues in this design. Maybe I'll go for an AVR instead.
>
> Every CPU has its source of attacks.  I think some of the AVRs erase
> their lock bits first, so that a properly timed attack can wind up
> enabling the memory on them.  But I'm as vague on this as you were on
> the MSP430.  My point isn't to accuse the AVR so much as to point out
> that you need to carefully investigate the EXACT DETAILS of any
choice
> you might make, here.
>
> ...
>
> Since you say this is for a large volume design, I think that should
> mean there is sufficient reason to afford substantial due diligence
on
> your part.  Do your work, do it thoroughly.  There are PhD theses on
> this subject, a variety of other articles, studies of processor
> security including the MSP430 and the AVR, people at TI you should be
> talking to, etc.  (In fact, I'm sure that TI would be very able at
> helping you clearly apprehend the known issues.)
>
> Regarding the MSP430, you should have already been well aware of what
> I mentioned above -- not just the "something to do with" vagueness.
> It's not even a slight interest of mine, yet it was no effort at all
> to find the above details.  You said "quick decision" and it took me
> only a few minutes to find it.  If you are really serious, you should
> have already gleaned at least this much before posting (in my
> opinion.)  Probably much more.  Which tells me a lot about the level
> of effort you've expended so far...
>
> Sorry about the snippy tone, but you aren't talking "hobby" here.  I
> think you could have done at least the tiny amount of digging I did
> before writing your query, especially in the situation you outline.
>
> Oh, well.
>
> Jon


I must agree with Jon here.  You seem to have an ill defined secrity
requirement for your product.  If a greater degree of security than
that provided in the MSP BSL is required then you should be talking
directly to the device manufacturers and giving them your detailed
requirements.

To my mind guessing sixteen 16 bit numbers before being able to read
the code comes in the pretty difficult category.  Judging by the number
of smartcard based systems that have been hacked - conditional access
TV, PAYG mobile phones among others the security on these is not
exactly bullet proof.

Ian

On Thu, 12 May 2005 15:19:56 +0300, HP wrote:

> David wrote:
> 
>> On Thu, 12 May 2005 10:11:33 +0300, HP wrote:
>> 
>>>I heard there is a security issue with the MSP430. Anybody able to 
>>>verify this rumour? Allegedly, if the JTAG is disabled there exists a 
>>>back door to download the code and it has something to do with the 
>>>interrupt vector table.
>> 
>> It's not a "back door", it's an alternative method of programming the
>> chips.  Lots of flash-based micros (including the AVR) have something
>> similar.  In almost all cases, "security" means that no one can read out
>> the program in the chip, or modify it without completly erasing and
>> replacing it, unless they know a password of some sort.  In common with
>> other devices, the msp430 uses the interrupt vector table as a password -
>> easily obtained for those with access to the original program, but
>> impossible to guess.  Without the password, the only thing someone can do
>> is erase the chip - they can then program it with another program, but
>> your original program is gone.
>> 
>>>Please help me verify if this is a real issue or not. Need to make quick 
>>>decision for large volume design, soon. Cannot afford any security 
>>>issues in this design. Maybe I'll go for an AVR instead.
>> 
>> If you can't afford any security issues, you are in the wrong business. 
>> There are *always* ways to break any security.  But the security of
>> msp430's, in common with the AVR and lots of other devices, is pretty good
>> - getting a copy of the code out of one of these chips (assuming you apply
>> the security options appropriately) involves cutting the chips open and
>> using specialist hardware like electron microscopes.  For most purposes,
>> the devices are not the weak link in the system - it is the developers and
>> others in the company producing the system.
>> 
>> 
>>>Thanks,
>>>HP
> 
> Thanks, David,
> 
> Let's not call it a back door, then. But it certainly is a flaw in the 
> design. Guessing a 256-bit password on random may take some time, but 

It's not a flaw in the design - it is a perfectly reasonable way to make
something secure enough for almost all uses, while being flexible and
convenient both for batch programming during production and for field
upgrades.  The same principle is used by other suppliers (such as
Freescale).  It is not designed for very high security - there are
specific micros (such as smart-card micros) designed for that.

> there are other methods available. Such methods include messing around
> with the supply voltage, temperature, and frequency. Well-known methods
> such as Differential Power Analysis (DPA) can be used to monitor the
> decoding of the password. Other methods exist. The MSP430 is not
> designed around the same principles as, say, smart card microcontrollers
> and leaves many security issues wide open. In addition, the bootstrap
> loader is ROM-coded, which  means it is the same in all devices and the
> password is always stored at the same location and is always the same
> length. Sounds very risky to me.
> 

There are a great many methods of attack, requiring varying levels of
equipment and expertise.  The msp430 is secure enough that it is unlikely
to be worth the effort for a competitor to spend the time and money
hacking the device with a typical program instead of simply monitoring its
functionality and re-implementing the functionality.  That's called "an
appropriate level of security".  Of course, if you are storing something
in the chip that is worth significantly more than the value of the code,
then that does not apply - you find an alternative security system.

> Now compare this to an AVR, where the same bootstrap functionality is
> achieved with a fully custom and customisable boot loader. The loader
> and any password can be resized, reallocated or reprogrammed during any
> firmware update. And even in between, thanks to self-programming.

Compare this to a mask-programmed chip that can't be re-programmed at all.
Or compare it to a custom-made processor core in an fpga with AES
decryption of the code.  Compare it to whatever you like - you are the
only one who knows what effort is worth making to protect the contents of
your chip.

> 
> I think the AVR would let me sleep my nights better.
> 

I don't think the AVR would be significantly more secure in reality - but
it's not me that is going to lie awake thinking about it.  But if I had
doubts about the security of something like the msp430, then I would not
be looking at a slightly more secure AVR - I'd be jumping to a
security-specific solution like a smart card, or thinking harder about
what I want to protect.  I'd also be thinking about more complete security
- once a certain level is reached in the hardware, you need to be thinking
about the dangers of rubber-hose cryptoanalysis, and the three B's of
hacking (bulgery, bribery, and blackmail).  I'd also study Keven Mitnick's
book "The Art of Deception" - their is no point in making the device
secure if the code can be viewed by someone fooling your secretary into
giving out your server's password.


> BTW, you cannot read the firmware out from a Flash microcontroller using
> an electron microscope.

No, with flash you have to cut open the chip and connect wires to the
flash block.  It can be done, but needs a well-equiped lab.  An electron
microscope is good for reading out rom code.

> 
> Cheers,
> HP

HP wrote:
<snip>
> Let's not call it a back door, then. But it certainly is a flaw in the 
> design. Guessing a 256-bit password on random may take some time, but 
> there are other methods available. Such methods include messing around 
> with the supply voltage, temperature, and frequency. Well-known methods 
> such as Differential Power Analysis (DPA) can be used to monitor the 
> decoding of the password. Other methods exist. The MSP430 is not 
> designed around the same principles as, say, smart card microcontrollers 
> and leaves many security issues wide open. In addition, the bootstrap 
> loader is ROM-coded, which  means it is the same in all devices and the 
> password is always stored at the same location and is always the same 
> length. Sounds very risky to me.
> 
> Now compare this to an AVR, where the same bootstrap functionality is 
> achieved with a fully custom and customisable boot loader. The loader 
> and any password can be resized, reallocated or reprogrammed during any 
> firmware update. And even in between, thanks to self-programming.
> 
> I think the AVR would let me sleep my nights better.

But would it make your hackers toss and turn more ?

There are far more attack points than boot loaders!

It sounds like you really need :
a) more than one point of security - try adding crypto memory, or
a smart-card processor.

b) A CPU that is designed to be hard to crack. Look at Dallas Secure uC, 
for example.

You should also read up on Smart Card uC - their protection feature 
lists show attack points of lesser processors.

> 
> BTW, you cannot read the firmware out from a Flash microcontroller using 
> an electron microscope.

  No, there are plently of easier ways to try first.

-jg

> To my mind guessing sixteen 16 bit numbers before being able to read
> the code comes in the pretty difficult category.  Judging by the number
> of smartcard based systems that have been hacked - conditional access
> TV, PAYG mobile phones among others the security on these is not
> exactly bullet proof.
>
> Ian

Cracking a system is not the same as cracking a chip though.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

In article <1115902448.534450.225000@g43g2000cwa.googlegroups.com>,
ian_okey@hotmail.com writes
>
>To my mind guessing sixteen 16 bit numbers before being able to read
>the code comes in the pretty difficult category.  Judging by the number
>of smartcard based systems that have been hacked - conditional access
>TV, PAYG mobile phones among others the security on these is not
>exactly bullet proof.
>
>Ian
>

There are smart cards and there are smart cards... the serious use ones
usually resist attacks well. However the equipment they are part of is
another matter

-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> 
... snip ...
> 
> -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
> /\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

FYI a standard sig mark consists of "-- ", including the final
blank, and nothing else on a line.  Many systems recognize this and
will then automatically strip the sig from the reply quotation.  It
is not considered part of the signature proper, and thus does not
count toward the recommended 4 line maximum (which I am exceeding
below).

Thanks for making the correction.  Just a touch further to go :-)

-- 
 Some informative links:
   news:news.announce.newusers
   http://www.geocities.com/nnqweb/
   http://www.catb.org/~esr/faqs/smart-questions.html
   http://www.caliburn.nl/topposting.html
   http://www.netmeister.org/news/learn2quote.html