Security issue with MSP430?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Security issue with MSP430?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: Security issue with MSP430?

Quoted text here. Click to load it

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






Re: Security issue with MSP430?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: Security issue with MSP430?
<snip>
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

-jg


Re: Security issue with MSP430?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Security issue with MSP430?

Quoted text here. Click to load it
a
MSP430s
include
quick
choice
on


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


Re: Security issue with MSP430?
Quoted text here. Click to load it

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

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Security issue with MSP430?
ian snipped-for-privacy@hotmail.com writes
Quoted text here. Click to load it

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     /\/\/\/\/
/\/\/ snipped-for-privacy@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/




Re: Security issue with MSP430?
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Security issue with MSP430?
Quoted text here. Click to load it

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Security issue with MSP430?
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Bingo.

--
 Some informative links:
   news:news.announce.newusers
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline