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.

Securing Code?

Guru 15720 points

Replies: 20

Views: 2788

I am getting ready to release a product to production which uses the MSP430F5515. I would like to secure the code and do understand how to "blow" the JTAG fuse. However, since I will be providing firmware updates to customers, and my firmware update process uses the BSL, what good does it do me to blow the JTAG fuse if my customers have a firmware update file that is plain text (TI.TXT format)? Am I missing something?

Thx,

MikeH

 

20 Replies

  • MikeH

    I am getting ready to release a product to production which uses the MSP430F5515. I would like to secure the code and do understand how to "blow" the JTAG fuse. However, since I will be providing firmware updates to customers, and my firmware update process uses the BSL, what good does it do me to blow the JTAG fuse if my customers have a firmware update file that is plain text (TI.TXT format)? Am I missing something?

    There is JTAG soft fuse on MSP430F5xx family that can be blown by LP, changing fuse values inside BSL area.

    http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/?p=44019

    Blowing JTAG fuse will disable JTAG / SBW access to device, but BSL will still work. If you want to have protected bin file ( TXT / HEX) delivered to costumer that will update device by BSL, you must make your own customized BSL that will work with encoded (use what you want) bin files (TXT / HEX / whatever).

  • Guru 15720 points

    In reply to zrno soli:

    Zrno,

    Thanks for your thoughts. However, I'm very surprised that TI's MSP group is not following the lead of TI DSP group by providing a TI-developed secure code tool for the MSP products. I, for one, do not have the time nor expertise to develop a rock solid encryption/decryption tool. My DSP code is secure, my MSP code is not.

    TI, any thoughts? This would be helpful.

    Thx,

    MikeH

     

  • Mike,

    the BSL is password protected, so this should help to secure the firmware inside the device. 

    Regards,

    Leo Hendrawan

  • Guru 15720 points

    In reply to Leo Hendrawan:

    Leo,

     this should help to secure the firmware inside the device

    I think you missed my point. I am worried about giving customers (competitors) a non-encrypted copy of my firmware (i.e. firmware upgrade) since the BSL only reads text files. The TI DSP BSL reads encrypted files. It would be highly desirable for the MSP BSL to read encrypted files.

    Thx,

    MikeH

     

  • In reply to MikeH:

    Mike,

    sorry for this. Zrno is right, the only way to do this is to "extend" the code from SLAA450, by building a decryption mechanism of the BSL data sent by the host to the MSP430 before writing it to the MSP430 flash.

    Regards,

    Leo Hendrawan

  • Guru 15720 points

    In reply to Leo Hendrawan:

    Could we get TI to develop this code?

    Thx,

    MikeH

     

  • In reply to MikeH:

    Mike,

    I am not sure about this, I will need to forward this first to the team taking care of the BSL.

    Regards,

    Leo Hendrawan

  • Guru 15720 points

    In reply to Leo Hendrawan:

    Leo,

    I'm sure many folks would appreciate TI developing this capability. 

    FYI, the DSP group has a secure hex encryption tool as well as the BSL's ability to load either an encrypted or non-encrypted file. This is very important for those of us offering field upgradable firmware.

    Thanks~

    Thx,

    MikeH

     

  • In reply to MikeH:

    Mike, on the smaller MSPs, there is barely enough ram to execute the BSL code. And the BSL area isn’t large too. So you can’t put decryption into the BSL and you can’t upload an encryption extension.
    Sure, on the newest MSPs, it could be implemented. Especially on the USB devices which already load the main BSL functionality. (but then, this would be a risk again, as one could hack the uploaded BSL extension and use it to echo the decrypted binary)

    Well, you can receive the updated firmware with your own application and encrypt/decrypt it every way you want. You then don’t even need a special BSL connection – the normal communication channels of your application will do.

    _____________________________________

    Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.

    Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.
    I'm sorry that  I can no longer provide help  in the forum or by private conversation.

  • In reply to MikeH:

    Hi MikeH,

    I used to give the firmware to my assembly team, but of course, not in any standard format.

    Instead of giving a 'programmer + MSP-Flash-Tool + Firmware", I used to give "Programmer + Windows Application". The windows application was written in C#, which used the entire MSP-Firmware within the c# code, so that no body can see it after it is used for building the GUI application.

    I utilized some part of the source code from "MSPdebug" to download the firmware and MSP430 standard DLL files to communicate with the target. Both those files were used to make a .dll file. The GUI called its programming function through .dll file. That worked very fine and requires much less time than using a Firmware+FlashTool. MSPdebug files permit its reuse/modification by its license terms. This is very useful for repetitive programming as it displays a dialog to "continue with programming with another device".

    In my second revision, I completely removed this GUI part. Instead I developed a standalone tool with a MSP430 containing necessary firmware for the target device. It has LCD, buttons and LED indications for user interface. The code I utilized is a modified version of SLAU320. Whenever a firmware update is needed my representative used to reach the factory (assembly) and reprogram the programming unit with the updated firmware. But this method may not helpful in your case because you may need to supply it through soft-mediums (I mean internet, CD, etc.)

    If you are interested in any of the above methods, please let me know for more details, if needed.

    Regards,

    Binoy Raphael.

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.