• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 1117 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.

F28069U: Code Security Module [CSM]

Vishwanatha Manevarthe
Expert 1080 points

Hello Community,
I am using F28069U controller and would like to use the CSM feature to lock the device from tampering.
After going through the reference manual (SRUH18D), this is what I have understood:
1.  There are two categories of memory: a) affected by CSM b) unaffected by CSM (section 1.2.2)
2.  After reset, memory will be unsecured only if password given matches the password present in specific locations (0x3F7FF8).
    Otherwise, CSM-affected-memory can not be read/written.
3.  Password match algorithm in the Boot ROM code performs the match upon reset.
4.  Password is written into address 0x3F7FF8 using F2806x_CSMPasswords.asm

My questions:
1.  In the latest F2806x manual, sectors H to E are not mentioned in both tables (Table 1-10 and 1-11).
    Is this just accidental?
2.  It is mentioned that I need to write the password into the KEY registers to unlock the device.
    What is the means to feed the password to the system? Where does this password match logic reside? Do I need to write?
3.  I have a bootloader code that uses USB to program the device. This bootloader code is part of the secure zone.
    Hence it can access other secured memory while it is executing. Doesn't this pose security risk as anyone who has access
    to the protocol used can erase/reprogram the device? How do I avoid this?
    
thank you,
Vishwanatha

  • 0
    TI__Guru 61235 points

    Vishwanatha,

    Vishwanatha Manevarthe said:

    1.  In the latest F2806x manual, sectors H to E are not mentioned in both tables (Table 1-10 and 1-11).
        Is this just accidental?

    Table 1-10 is in error in SPRUH18C.  It lists flash as 64Kx16 and 32Kx16.  It should be 128Kx16 and 64Kx16.  All flash in the device is secured by the CSM.

    Vishwanatha Manevarthe said:

    2.  It is mentioned that I need to write the password into the KEY registers to unlock the device.
        What is the means to feed the password to the system? Where does this password match logic reside? Do I need to write?

    The unlocking procedure is to perform dummy reads of the passwords in flash (dummy read means just read the addresses), and then write the correct passwords to the CSM KEY registers.  This is what is described in section 1.2.3.2 of SPRUH18C.

    Vishwanatha Manevarthe said:

    3.  I have a bootloader code that uses USB to program the device. This bootloader code is part of the secure zone.
        Hence it can access other secured memory while it is executing. Doesn't this pose security risk as anyone who has access
        to the protocol used can erase/reprogram the device? How do I avoid this?

    This depends on what you are doing with the bootloader.  If the bootloader is for your use only (and not for your customers use), then the customer wouldn't know the USB interface command sequence that triggers the bootloader.  You could think of that command sequence as another password.  How would the customer know it?  Guard it the same as the CSM passwords.

    If your intent is to send flash upgrades to your customers for in-field updates, then you would need to encrypt whatever you send them, right?  Otherwise the customer wouldn't need to hack in to the flash.  You'd be sending him your code!  You'd embed the decryption algo with your bootloader and the bootloader would decrypt the new flash contents as it transfered in over USB, prior to flashing it.

    Just some thoughts.

     

    Regards,

    David

     

     

  • 0 in reply to David M. Alter
    Expert 1080 points

    David M. Alter said:
    If your intent is to send flash upgrades to your customers for in-field updates, then you would need to encrypt whatever you send them, right?

    Yes, the intent is to have field updates of the firmware. First, Our idea was to use the built-in feature instead of spending effort on encryption algorithms. If the memory can not be accessed using any mechanism when CSM is locked, why do we require encryption? Second, is this statement correct? "when CSM is locked and user bootloader is running, it can still access other memory areas. there is no way we can block bootloader from accessing other memory areas."

    Vishwanatha

  • 0 in reply to Vishwanatha Manevarthe
    TI__Guru 61235 points

    Vishwanatha Manevarthe said:

    Yes, the intent is to have field updates of the firmware. First, Our idea was to use the built-in feature instead of spending effort on encryption algorithms. If the memory can not be accessed using any mechanism when CSM is locked, why do we require encryption?

    That depends on who is doing the upgrade.  If it is a service technician from your company, then you don't need the encryption (assuming you trust your own service technician!).  But if it is your customer, then you cannot exactly just give him the new code executable (since you'd be giving him the code that you are trying to protect).  When I hear USB based flash upgrade, I start thinking you want to post the new code image on a website that your customer downloads and flashes himself over USB.  If that is the case, you need to encrypt the code image because you're giving it to the customer.

    Vishwanatha Manevarthe said:

    Second, is this statement correct? "when CSM is locked and user bootloader is running, it can still access other memory areas. there is no way we can block bootloader from accessing other memory areas."

    Correct.  If your bootloader is executing from secure memory, then it has access to all secure memory.  The F2806x devices only have a single security zone.

    To be clear, note that I said "Your" bootloader, which is different from the ROM bootloader that TI provides.  The ROM is not secure memory.  Therefore, the TI bootloader cannot access any secure memory.

     

    Regards,

    David