• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 82 subscribers
  • Views 868 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.

TMS320F28388D: DCSM

Weiquan Feng
Prodigy 10 points

Part Number: TMS320F28388D
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Operation 

(1) The program can run normally without using DCSM;

(2) After using the Z1 of DCSM to encrypt all the RAM and FLASH that can be encrypted, the program cannot run normally;

(3) If DCSM_unlockZone1CSM is called at the beginning of the main function to decrypt, the program can run normally;

Question 1: Although using the above method (3) can make the program run normally, but does it pose a risk to code security?

① In this case (DCSM_unlockZone1CSM is called at the beginning of main function to decrypt), the code read back by UniFlash using JTAG is still all zero, unless UniFlash also enters CSMPSWD to unlock the chip; 

② Using CCS in this case (DCSM_unlockZone1CSM is called at the beginning of main function to decrypt), it is not possible to burn new programs without configuring passwords;

Does the test ①② indicate that the code is already secure? Are there other ways to read back the user's code under these conditions that pose a threat to code security?

Question 2: The cause of the above (2) is located as calling the code of the security zone in the non-security zone;

As shown in the figure below, GSRAM cannot be encrypted. When memcpy needs to be used to move part of the security FLASH code to GSRAM, if there is a need to call other code that is still in the FLASH security area and has not been moved to GSRAM code, It will cause an error that calls the code of the security zone in the non-security zone, so that the program cannot run normally. The best solution, of course, is to replace the GSRAM that carries the code to the destination with LSRAM that can be encrypted, but if the amount of code that needs to be carried to RAM is large, LSRAM alone cannot be loaded, how to solve the problem? In order to avoid calling the code of the secure area in the non-secure area, can only use LSRAM as the transport destination, and the storage of larger GSRAM can only store variables and other data, can not be used as the code running space?

memory map

sysconfig DCSM

CMD

  • 0
    TI__Mastermind 28580 points

    Hi Weiquan,

    Yes, unlocking the zone disables all security associated with that zone with the exception of JTAGLOCK, so your code will no longer be secure.

    If your software is not written with embedded security best practices taken into account, there are ways a hacker can gain access to your code such as through the comms peripherals of the device, even if security is enabled. If your application code unlocks the security zone, Uniflash should be able to read your code via the memory browser. It should not show up as all zeros unless the zone gets relocked by your application code or by a device reset(this could be triggered by Uniflash).

    Any functions that do not directly read or write to secure resources could be placed in GSRAM. These functions could still call other functions that need to access secure resources, so move as many of these child functions to LSRAM as possible. You're correct that only LSRAM can be secured while GSRAM is always unsecure. The amount of LSRAM is finite so you may have to reduce the length of some functions or place them in FLASH in order to fit all of your code into available securable memory.

    Let me know if you have additional questions.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    Your description of Uniflash does not seem to be consistent with the phenomena I experimented with. With DCSM enabled and the main function starting to call DCSM_unlockZone1CSM to unlock, the program works normally and the LED blinks normally. If Uniflash is connected to JTAG to read the memory at this time, the read back is indeed all zeros, and it is observed that the LED does not blink at this time, the program is not running, and the chip is suspected to be in the wait boot state.

    Similarly, using Uniflash to download a program without unlocking it by typing CSMPSW in Uniflash will also fail. Does this mean that even if the main function starts calling DCSM_unlockZone1CSM, the code is still safe? Without knowing the password, the hacker can neither access the chip memory through Uniflash nor write his own code to read back the memory data using the communication peripherals. Of course, the user's own code does not provide a way to access all of the chip's memory through the communication peripherals.

  • 0 in reply to Weiquan Feng
    TI__Mastermind 28580 points

    Hi Weiquan,

    What do you mean by "starting to call DCSM_unlockZone1CSM". Is the code halted at the function call? If so, the zone will still be locked, so reading the memory via Uniflash will return all zeros. After this function is called, the memory will be readable. If an attacker can get JTAG access to the device, they will be able to read the memory during runtime.

    If you want to download a new program, you will need to unlock the security zone. This is because the secured memory cannot be erased or reprogrammed when the zone is locked.

    Let me know if this answers your questions.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    My code has a problem accessing secure zones from unsecured zones, so I call DCSM_unlockZone1CSM at the beginning of the main() to unlock all secure zones. What I want to know is whether there is a risk of leakage of the chip code in this case. In my previous answer, I tested that under this approach, the code read back through UniFlash is still zero, and no new program can be downloaded. Does this mean that the code is still safe in this approach? You can check my previous reply for details.

  • 0 in reply to Weiquan Feng
    TI__Mastermind 28580 points

    Hi Weiquan,

    I will be out of office today, I will respond back by tomorrow.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    TI__Mastermind 28580 points

    Hi Weiquan,

    Are the JTAG pins accessible on your board? If so, a hacker could connect to your device via JTAG, halt the code after DCSM_unlockZone1CSM is called, and read any memory location they wish. The best protection against this would be enabling JTAGLOCK and zero-pin boot from flash (number of boot pins configured to zero, boot mode is flash boot).

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    As you said, after calling DCSM_unlockZone1CSM, the hacker can read any memory location through the JTAG connection. But my actual test results tell me that in this case, the chip memory read back by UniFlash tool is still zero, may I ask what is wrong with my operation?

  • 0 in reply to Weiquan Feng
    TI__Mastermind 28580 points

    Hi Weiquan,

    One of three things is happening here:

    1. DCSM_unlockZone1CSM is unsuccessful
    2. The device is being reset by Uniflash when you attempt to read from the memory browser, which relocks the zone
    3. DCSM_unlockZone1CSM has not been called yet when you attempt to read from the memory browser.

    Can you confirm 1 and 3 are not happening? If so, I believe this is an issue with Uniflash. It is either resetting the device and re-locking the zone or some other issue with Uniflash is causing all 0s to show up. I will loop in a Uniflash expert to explain this if you can confirm 1 and 3 are not occurring.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    1. When JTAG is not used to connect the chip, DCSM_unlockZone1CSM must be called successfully, otherwise my code will not run properly due to the problem of accessing the secure area from the non-secure area.

    2. When Uniflash is used to read or download programs to the chip, I suspect that as you said, the chip will be reset and stay in BootROM without executing DCSM_unlockZone1CSM in my code, so reading memory or downloading programs will fail. The program stays in BootROM judging that my LED is not blinking.

    Based on the above two points, can I confirm that even if I call DCSM_unlockZone1CSM in my code, the hacker will not be able to access chip memory from UniFlash?

  • +1 in reply to Weiquan Feng
    TI__Mastermind 28580 points

    Hi Weiquan,

    It's possible they will not be able to access your code through Uniflash but they could still access your code through JTAG, since the zone will be unlocked and security will be disabled. I would recommend one of the following:

    • Enable JTAGLOCK and zero-pin boot to flash to block a potential hacker from having JTAG access
    • Structure your code so that it is not necessary to call DCSM_unlockZone1CSM.

    It is up to your discretion how much security is necessary for your application. TI is only responsible for providing tools that will help secure your code and describing the function of those tools. Depending on how you use these tools and how you're code is written, a hacker may still be able to access your code.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    Thank you very much for your answers and suggestions in the past few days

  • 0 in reply to Weiquan Feng
    TI__Mastermind 28580 points

    You're welcome, I will close this thread.

    --Luke