MSP430 custom BSL password

By default it uses IRQ vector area at the password, so your password will change with every software reversion.

But as MSP430x5xx and MSP430x6xx Family  have rewritable BSL code, so you could change how and where it looks for password.

On ROM based BSL's, you could fix the vector table with rejumps (a IAR G2553 example , CCS have different pragma & linker)

static const unsigned int jumptable[48] @0xFFA0 = {  // not in order as to scramble password
  0x4210,0xFF80 +4,  // PORT1_ISR
  0x4210,0xFF80 +6,  // PORT2_ISR
  0x4210,0xFF80 +10, // ADC10_ISR
  0x4210,0xFF80 +12, // USCIAB0TX_ISR
  0x4210,0xFF80 +14, // USCIAB0RX_ISR
  0x4210,0xFF80 +16, // TIMER0_A1_ISR
  0x4210,0xFF80 +18, // TIMER0_A0_ISR
  0x4210,0xFF80 +24, // TIMER1_A1_ISR
  0x4210,0xFF80 +26, // TIMER1_A0_ISR
  0x4210,0xFF80 +20, // WDT     
  0x4210,0xFF80 +22, // COMPARATOR
  0x4210,0xFF80 +28, // NMI        (not used)
  0x4210,0xFF80 +30, // RESET to main
  0x0000,0x0000,     // dummy
  0x0000,0x0000,     // dummy
  0x0102,            // firmware reversion custom var
  0x0000,            // BSL signature
  // real intvec & static password (sent little endian)
  0x4150,0x5353,     // 'PASS' fill non-available vectors with ASCII
  0xFFA0,0xFFA4, 
  0x4457,0xFFA8,     // 'WD' 
  0xFFAC,0xFFB0,
  0xFFB4,0xFFB8,
  0xFFC4,0xFFC8,
  0xFFBC,0xFFC0,
  0xFFCC,0xFFD0  
}; 
#pragma required=jumptable  // tell compiler it's not a dead var, pragma RETAIN in CCS

And do some changes in  linker file
-Z(CODE)INTVEC=FF80-FF9F      // normally FFE0-FFFF but now bsl password stays same
-Z(CODE)RESET=FF9E-FF9F       // normally FFFE-FFFF

Hi Deepak,

You aren't doing anything wrong (other than it looks like you read out 31 bytes instead of 32?) - the result you are reading out of the device at 0xFFE0-FFFF is correct. The BSL user's guide www.ti.com/.../slau319 section 3.5.2 under RX Password notes that the password is the top 16 words of the device's interrupt vector table (IVT) at addresses 0xFFE0 to 0xFFFF. Further, if you check the datasheet www.ti.com/.../msp430fg6626 section 6.5 Interrupt Vector Addresses you can see that the addresses from FFE0h through FFFFh contain interrupt vector table entries, with FFFEh containing the reset vector for the device.

This means that if you have a program already present in the device, e.g. the program you loaded to read out these addresses, then you will already have values other than FFh present for the BSL password - the values will correspond to the addresses of the interrupt vectors used in your program. You will always at least have the reset vector at FFFEh populated, and the value there will point to the beginning of flash where the start of your program has been placed. CCS also generates a dummy ISR for any unused interrupt vectors, and so that is what the rest of your table is filled with. You can see that all the other entries in your example are reading back as 0x441C - this is going to be the address for the default dummy ISR that CCS generates in this particular program.

So basically, the only time the BSL password will actually be all FFh is if the part has not been loaded with a valid program (because you'll always have at least the reset vector at FFFEh populated or else your program could not run). In CCS it also fills any entries for unused interrupt vectors with the address of a dummy ISR. If your program used any of the ISRs with vector table entries between FFE0h-FFFEh as mentioned in the datasheet section 6.5 above, then there would also be some different values corresponding to wherever your ISRs for those interrupts in your code have been placed.

So with this you'll already have a password depending on whatever version of the code you load, made up of the dummy ISR address for your particular build and the addresses of any of the interrupt vectors used in a particular build of your code. You could adjust the password by defining and placing ISRs or dummy ISRs for the interrupt vectors between FFE0-FFFEh.

Regards,
Katie

Hi Kaite,

Thank you for your explanation. Yes, I got the information that I was looking for. We can close this thread.

Thank You,

Deepak

Deepak Yadav said:

What I am trying to accomplish is to have my own BSL password that I know so that whenever I do firmware upgrade I can provide the right password and if someone else tries to put a wrong password then it should NOT DO A MASS ERASE and instead ignore the user.

Yes, what you described can be accomplished on 5xx/6xx Flash MSP430 chips if you go through the trouble of writing your own Customized BSL. You can accomplish on some of the FRAM chips too, but with a different protection for the BSL code.

I think the fear of someone keep trying all combinations until they get in is baseless. Please check the following simple math.

Even for a shortish 32-byte (256-bit) password, there are 2^256 = 1.1E77 possible combinations. Assume that one can try a password in 1 usec (1E-6 seconds or 3.2E-16 year); and assume someone build 10 million (1E7) identical units to try them in parallel; it would take >3E54 years to go through all possible passwords.

Am I confuse with my math?

Writing your own Customized BSL is not a big deal and TI has guide lines and examples of how to do it. The only difficulty is, you should fit it in slightly less then 2KB of protected Flash (in the case of 5xx/6xx Flash based MSP430. In the case of some FRAM MSP430, the size could be any multiple of 4KB.

I do not work for TI but quite familiar with BSL. If you want, you are welcome to call me over the phone to discuss this (it is more effective as compared with e-mail/E2E-posting exchanges. 

Hello old_cow_yellow,

what about security concerns stated in the following papers?

https://events.ccc.de/congress/2008/Fahrplan/attachments/1191_goodspeed_25c3_bslc.pdf

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7489330&newsearch=true&queryText=Improving%20the%20security%20of%20wireless%20sensor%20networks%20in%20an%20IoT%20environmental%20monitoring%20system

These types of concerns are why it is generally best practice to have the mass erase on wrong password feature enabled. That way the first time something incorrect is provided, then your code is erased and no longer there to be read out. Since you are using a Flash-based BSL (F5xx/6xx devices) you can also change the default BSL to check other things too before allowing access or to add some of your own security features if you are concerned, by making a customized BSL.

Katie,

"Security" could also mean something other than protecting you code from being read by others.

Consider, for example, you have a electric meter at your customer's site. And you want to charge your customer according to their energy consumption. You made this possible by your code embedded in that meter.

Someone could  use BSL with a wrong password deliberately to erase your code. And they can then use the 32-bytes of 0xFFs to get full excess and re-programmed the meter to charge less for energy consumption. Was your meter "secure" in that sense?

They may not be interested in your code at all. They want to get control of your embedded system. Mass erase when wrong password is entered makes it extremely easy to do that. You "security" is made worthless in this sense.

Also, could you make an estimate of how many billions of years does it take to try all possible password? (I did that in my previous response, did I made mistakes there?)

--OCY

Hi old_cow_yellow,

Yes, this is why I said in general this is the case. But if you read the app note I linked in one of the earlier posts it does discuss that if you are concerned about someone being able to replace your firmware, a mass erase would not be helpful in that scenario. The papers this new poster linked (looks like someone different from the original poster) talk about people using not just straight using "brute force" but more intelligent methods to try to reduce the number of guesses that they have to make I believe. I don't know in practice how hard that still is to do but I can understand the concern. Mass erase is something that might be able to help with this kind of guessing if you are concerned about device readout rather than device reprogramming.
 
Ultimately, security comes down to whatever the user implements that makes sense in their particular application and use-case regarding what they are worried about happening (stealing their IP, gaining control of the device, etc). This is why doing your own customized BSL may be an option if you have more concerns as you can then implement whatever you would want for your particular needs. System-level solutions are also good to have in place - having layers of multiple methods is generally a good approach, although no security is perfect. We also have provided more features on newer devices like IPE/IPP on MSP430FR5xx and MSP432 to try to give you more options as one part of whatever you choose to implement at the system level.
 
Also just to note for everyone, MSP is not sold as a "secure" MCU, we simply provide some features to try to help with some basic concerns. In the end, security is typically a system-level matter you'll need to consider. There are some more resources here: http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/peripherals.page#security

-Katie

Hello Katie,

thanks for your reply. Actually I don't want to write my own BSL. I just want to protect my code and I think the mass-erase-on-wrong-password-feature is exactly what I want. I am just thinking about what would happen, when the voltage the BSL needs to operate is lower than the voltage the flash controller needs to erase the flash. If an attacker is operating with a voltage inbetween, he should be able to "deactivate" the mass-erase-feature. Am I wrong?

Best regards,

Sebastian

(PS: I don't mean the voltages given in the datasheet, I mean the "real minimum" voltages given by design.)