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.

Program intellectual property protection on DM648

In my project DM648 is used, and it boots from external EEPROM via SPI interface. While for intellectual property protection reason after mass production, what kind of methodology could I use? My concern is about how to encrypt the data in EEPROM with the help of TI's development tool chain. However I found nothing about code security or anti-crack scheme at www.ti.com.

Can anyone tell me how to protect my design stored in the EEPROM in a convenient way?

  • Unfortunately we do not have a real comprehensive solution for this sort of thing, at least not for DM648. For the most part on these devices if someone can get a logic analyzer on the traces they can probably reverse engineer any encryption because there is no protected code inside the silicon itself for protected software. So while you could encrypt the code on the EEPROM, you would have to have the code to decrypt it stored somewhere in the system itself as well, and since there is no internal flash or writeable ROM inside the device that decryption code would have to be outside the part, and thus it would have to come across a bus into the device during boot which could potentially be tapped with a analyzer.

    This being said reverse engineering would still be difficult, getting a tap onto the proper lines with a logic analyzer and than collecting the data would still be difficult and tedious, and it would be more complex to get much out of it if you did put encryption on to the image (but not impossible). One suggestion for security once your device is going to production would be to hide the JTAG connections, as if a hacker can get onto the JTAG for the part they could just wait until any code is decrypted and loaded into RAM and then extract all of it with an emulator. The downside of doing this is that your board would be less debuggable, and potentially harder to reflash since the common reflashing utilities use JTAG, but once you have a known good firmware this is probably a good step to take if you are concerned about code security.

     I wish we had more to offer in this case (maybe someone else can comment on other ways to protect the code), hopefully these basic protections are suitable for your implementation.

  • Thank you very much for your detailed reply! I will put some mechanism in my system for IP protection on my own. After it is done, I will post my solutions in time for discussion. I hope then you can give me further suggestion.