How to securely blow the BSL *and* security fuse?

All MSP430 have JTAG "fuse". Some reversible, some irreversible.

Some MSP430 do not have BSL, but most of them do.

All TI supplied BSL use password for protection.

Leo's answer above is the one I wanted....just some general guideline on when you want to use the "erase the BSL" workaround to make sure that people can undo the electronic security fuse.

IMHO the USB FET software should be modified to use this workaround when people blow the fuse.  Most people will think "I blew the security fuse so my code is safe" without realizing there's a backdoor ;-)

The BSL "backdoor" is password protected. There are other backdoors to access code.

I thought the BSL backdoor was known (i.e., is the same password for all chips?).

And what other backdoors exist?  I thought the BSL one was the only one :-P

The BSL password is known to everyone when the entire Flash is erased. You change the password together with your code. Like many other password protection, people may guess your BSL password, especially when you use c to generate your code. Some version of BSL has the feature that if someone guessed wrong, the entire Flash is erased. Other version may let others to keep trying indefinitely. Thus BSL is somewhat secure, but not entirely secure.

Personally, I do not know other backdoors. But I think they exist.

Hi Ken,

Which MSP430 are you using?

Jens-Michael Gross gave a pretty good explanation on how the BSL password protection works in this post: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/83912/289220.aspx#289220

You will only be able to read code out of your part if you know the unique BSL password - and if the incorrect password is used on the first try then a mass erase is performed, so then your code is no longer there to be read out. This prevents a brute-force of the password by trying every combination, because after the first try the part is erased and your code is gone. (This is described in SLAU319)

I'd be reluctant to blow away the BSL completely if I were you. If you have blown both the JTAG fuse and the BSL, you will not be able to perform any firmware updates on already programmed parts if you find an issue with your code at a later date - the parts would essentially be "bricked."

In addition, if you have issues with your parts at some later date and need to send them to TI support for analysis we won't be able to do very much because we won't be able to get into the parts at all. Whereas if you leave the BSL in place, we would still be able to trigger a mass erase by sending a bad password and then get into the (now-empty) part with the default password (as I said before, at that point your code has already been erased). Then we can write test programs into the part via the BSL to help us analyze if there is anything wrong with it.

That's really all someone can do with your part if they don't know your BSL password - they can just erase your code and then write different code in, but they won't be able to read out your code via BSL if they don't know your unique password.

I hope this clarifies your options and give you a heads up on what to expect if you still decide you want to disable BSL completely. Some people choose to do this still, but I wanted to make sure you knew all the factors to decide what's best for your situation.

Regards,

Katie

Hi everyone,

I am raising the question of security for the msp430 again because I can see that there has been some revisions of the msp430G2553 and it now has BSL feature. 

Is blowing the security fuse of the msp430g2553 enough to secure the code on the chip ? Or do I need to also set a password for the BSL? Can I simply bow the BSL?

I am looking for the easiest and simplest way to secure the msp430g2553 code. I am not planning on doing updates later on or anything.

Thanks

Thomas Mauchien1 said:

Is blowing the security fuse of the msp430g2553 enough to secure the code on the chip ? Or do I need to also set a password for the BSL? Can I simply bow the BSL?

Blowing JTAG fuse on MSP430x2xx will disable SBW / JTAG access to device. There is no BSL fuse that can be blown. Flash vector table is BSL password, so it is exist, but you can make stronger password if full vector table is generated, even all interrupts are not used. If wrong BSL password is supplied, mass erase will be executed, so your code is protected, but device is not protected from erasing.

Thomas Mauchien1 said:

I am looking for the easiest and simplest way to secure the msp430g2553 code. I am not planning on doing updates later on or anything.

With blown JTAG fuse, and BSL password your code is protected. If there is no need for later updates, but you want to have also protected device (no mass erase), for project can be selected MSP430x2xx device without BSL.

Hi Thomas,

What zrno soli mentioned is correct - if someone puts a wrong password the device will be mass erased, so your code will no longer be there for someone to read out.

Looking in the BSL User's Guide www.ti.com/lit/pdf/slau319, in section 5.1, you can see that the G2xx3 device has version 2.03 of the BSL. In section 2.7, "Password protection", it describes how in BSL versions 2.00 and higher have more features, that can be controlled by the flash data word located beneath the interrupt vector table addresses. If you write 0xAA55 to this word, you can completely disable the BSL so that it won't be initiated even if someone does the BSL entry sequence on RST and TEST pins. So in addition to having the BSL password, you could disable the BSL too.

One potential disadvantage is that if you have both blown the fuse and disabled BSL (instead of just a password), if for example you get some field returns of your product and need to run tests on failing devices, you aren't going to have any way back in to do this. Similarly, if you send parts to TI for some failure analysis, we aren't going to be able to do any tests on those failing parts where we'd need to be able to load test code into them to see how they are behaving, if BSL access is disabled. Versus if you leave the BSL with a password, your team doing the failure analysis would be able to read out failing units by supplying your password, or at least you could erase the devices by sending a bad password and load in some test code to exercise the devices for analysis. This may not be a big deal for you, just trying to make sure you are aware of this.

Regards,

Katie

Hi Katie,

Thank you for your help. I would like to thank zrno too.

I like the idea of having a password but the BSL sounds confusing to me. How to set this password ? I read slau319 and slaa553 but still don't know how to set the password up. Do I just need to add a line in CCS to set it up and then I can blow the fuse ?

I wished there was a how to guide that would explain how to set this password and maybe out to test it. 

Regards,

Thomas

Leo,

Thanks for your reply!

I have tried OpenBSL program and was able to run OpenBSL Host demo on windows PC successfully (Toggling the LEDs). Thanks for setting this up. I realized you are the owner :) This was really helpful.

So if I understand well, by writing in TIMER_A0.txt:

@FFE0
01 02 03 04 05 06 07 08
q

And running OpenBSL host demo again, instead of loading the LED program into the MSP430g2553 I will write at the adress FFE0 (which is the location of the password) the password 01 02 03 04 05 06 07 08, Is that right ?

Now if I run the demo again after that this won't work anymore because the password will have changed to 01 02 03 04 05 06 07 08.

And if I want to run the BSL again I need to replace {'M', 'Y', 'P', 'A', 'S', 'S', 'W', 'D'} in OpenBSL_Config.h by

{'01', '02', '03', '04', '05', '06', '07', '08'} 

I am not sure if all of this is right ?

That would be awesome if you could set up another demo guide in the wiki on how to set up your own password for msp430g2553.

Thank you in advance for your kind help.

Thomas

Thomas,

it has been a while since I finished the first version of OpenBSL, so I need to dig in again :-)

Anyway, it is correct that the password is hard-coded in memory and can be configured during compile time by changing the OPEN_BSL_CONFIG_PASSWORD in OpenBSL_Config.h, however the location of this password is not fixed. If I compile the OpenBSL code and look into the MAP file, I can see that the password is located by the linker at address 0xFEF0-0xFEF7:

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
........................
.const     0    0000fef0    00000010     
                  0000fef0    00000008     OpenBSL_Core.obj (.const:.string:OpenBslPasswd)
                  0000fef8    00000008     OpenBSL_Mem.obj (.const:MemInfo)

Theoretically (I don't remember this exactly, but looking into the code), you shall not be able actually to write to address 0xFFE0 since it is not a valid address which is defined in the MemInfo[] table (per default for MSP430G2553, only the INFO memory and between 0xC000 - 0xF7FF as defined in OpenBSL_Device.h) -actually I think the MemInfo[] should like this instead:

// memory sections on MSP430G2553
const OpenBSL_MemSect_t MemInfo[OPEN_BSL_NUM_OF_MEM_SECTIONS] = {
  // first section: InfoB-D - start address: 0x1000, end address : 0x10BF
  {
    INFO_MEM_START_ADDR, INFO_MEM_END_ADDR
  },
  // second section: Code memory - start address: 0xC000, end address : 0xFBFF
  {
    APP_MEM_START_ADDR, APP_MEM_END_ADDR
  }
};

and if you look into the implementation of OpenBSL_ProcDnldSegment() function which is used to download data to certain memory segment, it will call the OpenBSL_MemChkSection() first to make sure that the given memory segment is valid as defined in the MemInfo[] table.

So basically I wonder why did you succeed to write into address 0xFFE0 by downloading your TIMER_A0.txt above.

Leo,

I did not succeed to write to 0xFFE0 by modifying TIMER_A0.txt. I was asking to know if it was possible. Thank you for letting me know that it is not possible.

So you say that to set up the password I can change {'M', 'Y', 'P', 'A', 'S', 'S', 'W', 'D'} to let say {'01', '02', '03', '04', '05', '06', '07', '08'} in OpenBSL_Config.h and change the address in the map file ?

I have this in the map file:

.const 0 0000feea 00000010 
0000feea 00000008 OpenBSL_Core.obj (.const:.string:OpenBslPasswd)
0000fef2 00000008 OpenBSL_Mem.obj (.const:MemInfo)

Thanks,

Thomas

Everyone,

If I include this 4 lines at the beginning of my code in CCS:

#include <msp430g2533.h>
 
#pragma RETAIN(BSL_lock)
#pragma location=0xFFDE
const unsigned long int BSL_lock = 0xAA55;

Will this disable the BSL ?

Thomas