This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FR5720 Bootstrap Loader Question

Other Parts Discussed in Thread: MSP430F2012, MSP430FR5720

Hello all,

I am currently migrating from F2012 to FR5720.

My interpretation of the MSP430F2012 datasheet leads me to believe that there is no bootstrap loader code in this device and that when the JTAG fuse is blown the firmware and all internal memory is no longer accessible. Is this true or false?

The MSP430FR5720 has a bootstrap loader and I need to provide optimum security for the device firmware.

I know that there is a disable code and various methods of password protection but I have been given this link http://events.ccc.de/congress/2008/Fahrplan/attachments/1191_goodspeed_25c3_bslc.pdf that indicates the BSL can be hacked.

Can you comment on this BSL hack?

Is there a way of erasing or corrupting the BSL code?

What are the security measures in place or available for this device?

Any direction here would be very much appreciated.

  • MSP430F2012 don't have BSL, and if JTAG fuse is blown, there is no way to do anything with firmware.

    MSP430FR devices have ROM BSL (that can't be changed), and software fuse is located in FRAM at 0FF80h. AFAIK, only BSL command (regarding FRAM access) that is working without knowing BSL password is mass erase. If you know BSL password fuse can be unblown by changing values at 0FF80h. If you don't know BSL password mass erase will unblow the fuse, but also delete FRAM area (set to 0FFFFh).

    http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/265600.aspx

    Don't know anything about BSL hacking.

  • Tim,

    Tim Reyes said:

    My interpretation of the MSP430F2012 datasheet leads me to believe that there is no bootstrap loader code in this device and that when the JTAG fuse is blown the firmware and all internal memory is no longer accessible. Is this true or false?

    You are correct, checking the device specific datasheet of MSP430F2012, there is nothing mentioned about BSL. So thus, this feature is not available for the whole MSP430F20xx. If you disable the JTAG, the internal shall not be more accessible unless you implement feature this in your application code.

    Tim Reyes said:

    The MSP430FR5720 has a bootstrap loader and I need to provide optimum security for the device firmware.

    I know that there is a disable code and various methods of password protection but I have been given this link http://events.ccc.de/congress/2008/Fahrplan/attachments/1191_goodspeed_25c3_bslc.pdf that indicates the BSL can be hacked.

    Can you comment on this BSL hack?

    Is there a way of erasing or corrupting the BSL code?

    What are the security measures in place or available for this device?

    My opinion about this is as follows:

    - The document that Mr. Goodspeed wrote mentions about MSP430F2273 which is a flash based device. I am not really sure about this, but from what i understand/read before, Mr Goodspeed does the following: he tries to give any random password and detect the power consumption of the device while doing that. If there is an increase of power consumption/voltage glitch, this should mean that the given password is wrong, and the BSL will activate the flash memory controller module to erase the flash content -> which leads to increasing power consumption (flash operation really draws lot of current than normal operation).

    I think this is not valid for devices with FRAM. With FRAM devices, i don't expect any difference in power consumption when trying to read or write the FRAM content (you might read this somewhere else, but actually read operation in FRAM is write operation - but content is secured by an internal capacitor for re-writing cycle to guarantee the FRAM content). So i don't think this method by Mr Goodspeed will work with FRAM devices (but i haven't really tested this with real hardware).

    But anyway, if you want to make it really secure: on MSP430FR57xx, it is basically possible to disable the BSL. Please refer to the Family User's Guide chapter 1.11   "Bootstrap Loader (BSL)". For changing the BSL signature, you can just define the BSL signature in your code (i think this is the most convenient way to do it), and please refer to this wiki to do so: http://processors.wiki.ti.com/index.php/Placing_Variables_in_Specific_Memory_Location_-_MSP430#Generating_JTAG_Lock (It is written of JTAG lock, but the same method should also apply for this purpose).

    Hope this helps.

  • Hey Leo,

    I'd like to follow up with some additional questions.

    - You mention that disabling the BSL is an option. In case we do not want to go this route, is it possible to somehow hack the BSL or step around it without disabling it on the FR57xx parts? I need to address any potential compromise in this situation.

    - If the only sure solution for security will be to disable the BSL, I'd like to know that as well.

    Thank you very much for your insight on this so far. Your help here is very much appreciated. 

  • Hi Tim,

    The following is taken from the MSP430FR57xx Family User's Guide - chapter 1.11 "BSL":

    Two BSL signatures, BSL Signature 1 (memory location 0FF84h) and BSL Signature 2 (memory location 0FF86h) reside in FRAM and can be used to control the behavior of the BSL. Writing 05555h to BSL Signature 1 or BSL Signature 2 disables the BSL function and any access to the BSL memory space causes a vacant memory access as described in Section 1.9. Most BSL commands require the BSL to be unlocked by a user-defined password. An incorrect password erases the device memory as a security feature. Writing 0AAAAh to BSL Signature 1 or BSL Signature 2 disables this security feature. This causes a password error to be returned by the BSL, but the device memory is not erased. In this case, unlimited password attempts are possible.

    As described above, for disabling BSL you just need to write 0x5555 to BSL signature 1 & 2. If your application provide a mechanism to revert this, the BSL can then be-reenabled.

  • Tim,

    To max security for FRxx, you should disable both JTAG and BSL access. But this will lockup the chip forever.

    I think the following is secure enough and leave the option that the chip can be reused later.

    1) Fill all unused Interrupt Vectors with different meaningless numbers. (; And swallow the key ;)

    2) Enable BSL

    3) Disable JTAG access.

    A Mass Erase will wipe out your code and re-enable JTAG access so the chip can be reused.

    -- OCY

  • Leo Hendrawan said:

    My opinion about this is as follows:

    - The document that Mr. Goodspeed wrote mentions about MSP430F2273 which is a flash based device. I am not really sure about this, but from what i understand/read before, Mr Goodspeed does the following: he tries to give any random password and detect the power consumption of the device while doing that. If there is an increase of power consumption/voltage glitch, this should mean that the given password is wrong, and the BSL will activate the flash memory controller module to erase the flash content -> which leads to increasing power consumption (flash operation really draws lot of current than normal operation).

    I think this is not valid for devices with FRAM. With FRAM devices, i don't expect any difference in power consumption when trying to read or write the FRAM content (you might read this somewhere else, but actually read operation in FRAM is write operation - but content is secured by an internal capacitor for re-writing cycle to guarantee the FRAM content). So i don't think this method by Mr Goodspeed will work with FRAM devices (but i haven't really tested this with real hardware).

    It doesn't matter whether it is FRAM or FLASH: with all newer BSL versions (those on all 5xx/6xx, FR5xx, and ROM BSLs version 2.00 and higher) the part will be mass erased on the first bad password attempt. (see www.ti.com/lit/pdf/slau319 section 2.7) So with these newer BSLs (including FR5720) if you don't get the password right on the very first try, the part will be mass erased so your code is no longer even there for someone to try to read out - they can't try to figure out the password by providing bad passwords as that paper you linked described, because these bad passwords will result in the part being mass erased.

    I highly recommend keeping the BSL enabled as old_cow_yellow suggested - this will make your life easier down the road if you are ever having issues with your product in the field because you can do field updates as well as being able to load test code to see what might be going wrong.

    Regards,

    Katie

  • Hi Katie,

    Katie Enderle said:

    It doesn't matter whether it is FRAM or FLASH: with all newer BSL versions (those on all 5xx/6xx, FR5xx, and ROM BSLs version 2.00 and higher) the part will be mass erased on the first bad password attempt. (see www.ti.com/lit/pdf/slau319 section 2.7) So with these newer BSLs (including FR5720) if you don't get the password right on the very first try, the part will be mass erased so your code is no longer even there for someone to try to read out - they can't try to figure out the password by providing bad passwords as that paper you linked described, because these bad passwords will result in the part being mass erased.

    What i understand/i have read is that what Mr. Goodspeed tries to do, is measuring the current consumption of MSP430 target in BSL mode. If the BSL receives wrong password, it shall then start mass erase operation, this will be indicated by higher power consumption. And what he will do is, before the BSL has the chance to really do the mass erase, he will reset/power down the MSP430 target with the hope that the mass erase operation hasn't been executed yet. Then he can start from beginning again to give another password.

    So this is true for flash memory, but not for FRAM, at least i think so.

  • Leo Hendrawan said:
    So this is true for flash memory, but not for FRAM, at least i think so.

    I'll second that. Mostly.
    There is no difference in operating current between reading an FRAm cell or writing to it (actually, writing could even consume a bit less, as it skips the reading part).

    However, the BSL runs from ROM, which consume sless current for fetching instructions than it would form FRAM. Except for erasing the device, there is no reason for the BSL to access FRAm at all, so in theory, the change in current could be noticeable. However, once it occurs, the first bytes have already been erased. And I doubt it can be told apart from the normal noise floor of the MSP operating current - especially if there is any blocking capacitor on the supply road.

    And for what it's worth, this approach to break the BSL password has been discussed in the forum about 3 yeas ago. So it's not a new idea. And apparently it hasn't been used for successful attacks since.
    Considering the size of the password and the time it takes to reset the MSP, establish a BSL connection and try a password, it will in average take an eternity until success - and it cannot be accelerated by a faster computer because the BSL serial speed is fixed.

  • Thanks for all the great info.  This answers my questions and concerns that I had.

    -Dave