• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 328 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280041: Advice for code security, given the need for customers being able to update firmware...

Darron Black
Prodigy 75 points
Part Number: TMS320F280041


So... our devices end up in locations that are really only accessible to the end users.  We need to provide the ability to do firmware updates in the field, without compromising code security.

The user receives an Intel HEX file of the firmware which has been rewritten with all the data regions XOR'd with a fixed pseudorandom sequence from a modified RNG.  We have a bootloader in the devices that descrambles the incoming firmware image as it's received.   There are unlikely to be many updates... so there aren't going to be many samples to work with if anyone wants to figure out the RNG sequence.

We are next going to work on configuring DCSM zone 1 to secure all RAM, FLASH and JTAG access.

Are we missing anything?   This is obviously not GREAT security, but we just want to make it difficult enough that our customers are unlikely to attempt to copy our product.

  • 0
    TI__Guru** 115881 points

    Hi,

    Darron Black said:
    We are next going to work on configuring DCSM zone 1 to secure all RAM, FLASH and JTAG access.

    What you have should be good. Below are few points to pay attention to on this  -

    1. Boot loader code which does the firmware update should be in secure flash of Z1 only which need to be copied into secure RAM of Z1 and get executed to perform any flash operation.
    2. USER OTP (Security settings) can only be updated only after unlocking the zone so I am assuming these settings will not be changed as part of firmware upgrade ever.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 75 points

    #1) So, I was wondering about that.

    I find it odd that the FLASH API documentation doesn't mention anything at all about HOW to link the library or specific functions in the API to copy to RAM.  I had to look into FLASH API example project file to just now find the CMD file in device_support/.../common/cmd/..., (before I was just looking at the examples' source code)

    Of course, since it's already in ROM... it seems like a missed opportunity that it wasn't possible to make the ROM version work from secure memory.  Perhaps I could examine the MAP file from a ROM-based link and identify locations of some functions that do not deal with secure memory and mark them in the CMD file as linking to DSECT ROM regions?  Then I could avoid having to copy those specific functions into FLASH or RAM.  I'd just have to make sure the API's .bss region was in unsecure memory (maybe M0?).

    I've asked another question about CMD PAGE definitions that I've run into trying to sort this out.  (Edit: if the PAGE issue can be resolved I won't need to do weird tricks to save RAM)

    #2) Well, yes... apart from possibly a bootloader function to create the secure zones in the first place...  we're not sure how we want to program the devices in production currently.  We probably wouldn't need that.. if we go the SCI-boot way we could just have that as part of the boot stream.  I mean, currently every memory region that's possible to secure under DCSM zone 1 is secured that way.  About the only thing I can think of changing would be setting some regions to EXEONLY... and while I'd like to use that I'm just not brave enough currently.  We could leave changes like that to manufacturing processes only and not something to done in the field updates.

  • +1 in reply to Darron Black
    TI__Guru** 115881 points
    Darron Black said:
    Well, yes... apart from possibly a bootloader function to create the secure zones in the first place

    By default device will be unlocked so you should be able to create secure zone Ist time without any issue.

    Darron Black said:
    We could leave changes like that to manufacturing processes only and not something to done in the field updates.

    Yes, that would be good.

    Regards,

    Vivek Singh