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
Security issue with MSP430?
Started by ●May 12, 2005
Reply by ●May 12, 20052005-05-12
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
Reply by ●May 12, 20052005-05-12
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
Reply by ●May 12, 20052005-05-12
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, >>HPThanks, 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
Reply by ●May 12, 20052005-05-12
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 existsa> >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 earlierMSP430s> (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 makequick> >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 anychoice> 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 diligenceon> 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. > > JonI 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
Reply by ●May 12, 20052005-05-12
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, butIt'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
Reply by ●May 12, 20052005-05-12
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
Reply by ●May 13, 20052005-05-13
> 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. > > IanCracking 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
Reply by ●May 13, 20052005-05-13
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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●May 14, 20052005-05-14
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