Securing Code?

MikeH said:

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).

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.

Mike,

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

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.

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.

Could we get TI to develop this code?

Mike,

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

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~

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)

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.

The idea of an ‘update application’ is nice.
It could be put one step further if the application requests permanent unique data (such as wafer ID from the TLV structure, or other permanent identification) through the bootloader, verifies it with an internal table, encrypts the data before sending, and after sending the new firmware, a decryption code is sent to the device that decrypts the data from flash to flash, using the same internal data as key.
This way, the firmware cannot be captured by sniffing the serial transfer (individual encryption), and cannot be uploaded to foreign hardware (ID missing or not in table).

Hi all,

Just FYI, we are discussing the possibility to publish a custom BSL which can do AES128 decryption. 

As Jens-Michael Gross mentions, the 2KB limitation is an important consideration but we can make it fit in the BSL Area + 3 sectors of Info Memory. 

I'm glad to hear your feedback about the importance of this tool, but unfortunately I can't promise any dates yet. I can only estimate that we could have it ready by Q4 2014.

Regards,

Luis R

Luis,

This is very good news.

As an example, take a look at the Secure Boot Utility developed by the TI DSP group. The boot utility encrypts the .out file into a .bin file, and the BSL detects the encrypted or non-encrypted .bin file when it reads the file header. It is a good model to follow for your development.

Thanks for considering this development.

Thank you for the feedback MikeH.

Our memory restrictions will probably limit the scope of our BSL and there will be several trade-offs, but we'll try our best to make it secure and easy-to-use

Regards,

Luis R

A problem is the encryption/decryption key. Since the BSL code will be known, it must be a key that is device-specific – and known to the utility. And not known to anyone else who might have access to the MSP (so it cannot be requested from the MSP itself).
Seems for making the encryption worth the effort, there needs to be some “security through obscurity”, or else anyone could decrypt what is sent.

Jens,

All of the issues you mention have been addressed by TI in their DSP group.

http://processors.wiki.ti.com/index.php/C5000_Creating_Boot-Images

I can tell you from experience, the system works well.

MikeH,

I do not know if you are aware of the so-called IP Encapsulation feature on some of the newer MSP430FR devices. It locks up part of the memory as execute only. This feature can be used on top of the other security measures or no other security measure at all. I think it is a very good thing to have on other MSP430 too.

-- OCY

Hi Jens-Michael.

Good comments. Creating a unique key for each device would certainly increase the security, but would it be enough to assign a key per product?

• It's expected that the JTAG fuse will be blown and the device is pre-programmed with the BSL and a Key.
• The BSL would not allow any read accesses.
• The BSL would not allow any write accesses to the BSL area (including Key), RAM, registers, etc.
• Any Write access to "valid" flash area will be decrypted using the Key
• If the programmer tool doesn't know the key, then the data will be decrypted to gibberish. The MSP430 could validate the image using CRC (or something similar) and it won't execute the new image

The BSL programming tool (which can be on the field) doesn't need to know the key, because it won't encrypt/decrypt the image, it will just dumbly send the data.

The developer (who, in theory is the single person who knows the key) would encrypt the application before sending it to the field.  The application can include random data, be filled with different patterns, etc in order to generate more randomness on the image.

So,even if someone else has the same BSL image and the encrypted application image, but not the Key, then it won't be easy to find the key, or will it?

I guess developers could also add some randomness to their BSL image in order to make it different from the rest. 

Now, if the key for the product leaks, then it's game over, so it would be very important to keep the key safe. 

But in such case, it would help to have a key for each individual device as you mention. 

Do you agree? I would really like to know your feedback to see if I'm missing something. 

Regards,

Luis R 

The application must include random parts. Because if you have the same update file encrypted for two devices, it is by several magnitudes easier to decrypt it by assuming that two different keys for two different files must result in the same output. It'S almost as good as knowing the decrypted message to get the key from the encrypted one.
This allows to limit the branches of a brute-force attack (whose outcome then needs to be checked for a valid file) to a few decryption steps. If the two outputs do not match, then one of the keys is wrong.

It would also help if the destination of the decrypted data is scrambled (not linear) by a random pattern in each different file. Like having chunks of address/length/data in a random order. (for writing it into flash, the order doesn't matter)

 Once one key has been cracked, it is simple to clone the device hardware and give them all the same key. Then a future update for the original will also upload to all clones. Or it can be decrypted and the clones will accept a non-encrypted file (which can be decrypted with the once-cracked key). Which is the worst case: since there is no key anymore, it is unknown which device has been used to do the original hack - and therefore cannot be excluded from future updates.

 The most secure option is the requirement to send the device in for updates. :)

Luis RC said:

Hi all,

Just FYI, we are discussing the possibility to publish a custom BSL which can do AES128 decryption. 

As Jens-Michael Gross mentions, the 2KB limitation is an important consideration but we can make it fit in the BSL Area + 3 sectors of Info Memory. 

I'm glad to hear your feedback about the importance of this tool, but unfortunately I can't promise any dates yet. I can only estimate that we could have it ready by Q4 2014.

Regards,

Luis R

Well, I am finishing mine this days, and it takes only 1900 bytes ;) It is minimal USB CDC BSL with AES decryption, without any commands, just for firmware updates, nothing else. I used logging during development, and size was over 2K, so didn't use BSL area. After BSL is flashed to main flash, it is copied to RAM and executed from there. Block write, is used and rate including mass erase and decryption is about  24 KB/s. "test_msp430f5510_enc.txt" is encrypted "test_msp430f5510.txt" file.

D:\msp430>flash -p com14 -f bsl.txt -e -ws -v

File: "bsl.txt"
Address: 08000  Words: 952
Address: 0FFFE  Words: 1
Size: 1906 bytes

Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
0  91   OK   3180  1104  12   12  34449346 2200 3600

Erase

Write Smart
Time: 42 ms  Speed: 44,0 KB/s

Verify
Time: 23 ms  Speed: 79,7 KB/s

Release Device

Total Time: 140 ms

D:\msp430>flash -p com15 -f test_msp430f5510_enc.txt -upd

File: "test_msp430f5510_enc.txt"
Address: 08000  Words: 16384
Size: 32768 bytes

Update

Total Time: 1328 ms

D:\msp430>flash -p com14 -f test_msp430f5510.txt -v

File: "test_msp430f5510.txt"
Address: 08000  Words: 16384
Size: 32768 bytes

Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
0  91   OK   3180  1104  12   12  34449346 2200 3600

Verify
Time: 157 ms  Speed: 203,2 KB/s

Release Device

Total Time: 266 ms

D:\msp430>