• State Resolved
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 154 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

TMS320F28386D: How to protect the keys and passwords in DCSM OTP in .out/.hex file

jinzj39
Prodigy 70 points
Part Number: TMS320F28386D

Hi 

We are preparing to enable the JTAG LOCK and secure boot function in F28386D chip. The configured OTP data of DCSM zone1 will be added into the .out or .hex of our bootloader, then these function can be enabled after the flashing in our plant. 

Are these keys and passwords in plaintext format in .out or .hex file? If yes, how to protect them from leakage? Does IT's tool already consider this and have solution?

Thanks in advance!

Best Regards,

Jason

  • 0
    TI__Genius 10840 points

    Hi Jason,

    What do you mean by leakage? Are you asking if the JTAG passwords and CMAC keys can be extracted from the .out or .hex file? I'm not exactly how this would be done, but if someone had access to the .out file, they could simply program a device with that .out file and read the OTP to determine the CMAC keys and JTAG passwords. Let me know if this answers your question.

    Thank you,

    Luke

  • 0
    TI__Guru* 94025 points

    Jason,

       The .out file is binary and cannot be directly read. However, someone could extract the needed information by programming the .out file into a device, as Luke pointed out. The .hex file is a text file that can be opened in any ASCII editor like Notepad or Wordpad.

  • 0 in reply to Luke Jones
    Prodigy 70 points

    Hi Jones,

    Yes, leakage means that the paswords and keys can be read from the .out or .hex file.  

    After programming a device with the .out file, the OTP shall not be able to read out, right?  Do you mean it could be read before reset ? 

    Actually, I want to prevent the leakage during distributing the out file or hex file. One solution might be to encrypt the out file or hex file with one additional key; then decrypt it before programming. 

    Do you have better solution(to protect the keys and passwords) which already be supported by TI's tool?

  • 0 in reply to Hareesh Janakiraman
    Prodigy 70 points

    Hi Janakiraman,

    Yes, I know that the .out file is binary, but if someone knows the format of data in .out file, due to it's not encrypted, the paswords and keys can be exacted.

  • 0 in reply to jinzj39
    TI__Genius 10840 points

    Hi Jason,

    I meant someone could program the same .out file on another device. More specifically, they could program everything except for the CSM passwords using a feature in CCS that prevents programming of specified memory addresses. This would leave all of your OTP exposed on the hacker's device that they're programming the .out file on.

    I don't believe TI has any tools for encrypting the .out file for distribution but I will check with other experts on this.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 70 points

    Hi Jones,

    Thanks in advance! Looking forward to your information.

  • 0 in reply to jinzj39
    TI__Genius 10840 points

    Hi Jason,

    I heard back from our security experts, providing their feedback here:

    "Our C28 products do not have the capability to securely provision secrets (e.g., crypto keys, passwords) into the device. The user must have a secure or trusted factory where they program the device for production. If they want to be able to securely provision secrets in a non-trusted environment, they must move to a high security device. Future C2000 devices will have that capability but the AM263 device has it as well.

    A .out file can be translated to a hex file and easily read. What the user needs to do is:

    1. Keep the password protected in his factory (limit the number of people who can see it – possibly even making it zero if they want to involve a secure server).
    2. Encrypt the .out file with their choice of method.
      1. They could encrypt it with a secret AES key, then encrypt that key with a public key that only the programming line knows the private counterpart. You don’t need a special tool to encrypt files.
    3. The programming line would decrypt the AES key using their private key and then decrypt the whole image with the decrypted AES key.
    4. Then program the decrypted image. Its best to limit who can see steps 3 and 4. Since we don’t have HW support for secure provisioning, the line operator will have the ability to snoop and see the final image being programmed. That is why they must be trusted. But by following the steps above, they can at least limit the people that can see this to the small number of people in the factory owning the code and doing the original encryption plus the operator(s) doing the final programming. They can keep the encryption keys secure and only store/transmit the encrypted image."

    Let me know if you have any further questions.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 70 points

    Got your information, thanks!