Security issue with MSP430?

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.

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.

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.

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

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

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

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 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.

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 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.

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.

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.

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

-jg

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

In article , ian snipped-for-privacy@hotmail.com writes

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

... snip ...

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 :-)

... snip ...

Bingo.