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 15780 points

Replies: 20

Views: 2842

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

  • In reply to 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).

    However, the first law of computer security is:"If one has access to the data, everyone can gain access. If you want it safe, allow no access at all." Applies to firmware updates as well.

    _____________________________________

    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 Jens-Michael Gross:

    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

  • Guru 15780 points

    In reply to Luis RC:

    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.

    Thx,

    MikeH

     

  • In reply to MikeH:

    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

  • In reply to MikeH:

    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.

    Like the updater requests the encryption key form the MSP, using an asymmetrical key pair. So nobody can sniff the key when it is requested by the updated and on-the-fly calculated by the BSL based on some unique data like MSP wafer ID etc. Or a completely random value.

    Quite some effort. And it can still be hacked as long as someone has access to both, the updater program and its target MSP.

    I think the only way is to have a firmware that is encrypted with a secret key that is sored in each device individually, and kept in an manufacturer database. The drawback is that an individual firmware file needs to be produced for each individual device then.

    _____________________________________

    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.

  • Guru 15780 points

    In reply to Jens-Michael Gross:

    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.

    Thx,

    MikeH

     

  • 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

  • In reply to Jens-Michael Gross:

    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 

  • In reply to Luis RC:

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

     After all, this problem has been addressed by many companies so far. Garmin, for example, makes the installation process a real challenge with all their encryption and dangling and device and serial numbers and license numbers and whatever. Yet there are still cracked versions of their map updates available in the net. And I know several people who actually have an update license and still load the cracked software. Just to avoid all the update hassle with the ‘anti-piracy mechanisms’. When my dad calls me for an update of his Garmin navigator, I know that this will be another wasted evening.

    _____________________________________

    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 Luis RC:

    Luis RC

    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>

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.