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.

if we erase Flash Sector A to delete CSM passwords: do we expose the code in sector B?

Other Parts Discussed in Thread: CONTROLSUITE

The subject line has the whole question, but a little background...I need an air-tight, rock solid, secure way to update a 28069, in the field, without ever exposing the CSM passwords, or any code.  My plan is to keep the bootloader and encryption code in sector A.  I'll have application code in Sector B &C.  In theory,  my sequence will look like this:

  1. bootloader  copies the Flash API to secure RAM area 1 (because the ROM can't access secured RAM)
  2. for each sector...
    1. bootloader will get encrypted source for Sector B over CAN/serial, and places encrypted code buffer in an unsecure SARAM area
    2. sector A code decrypts that buffer  to secure RAM area 2
    3. Flash API executes from secure RAM area1  to Erase Sector B, then programs unencrypted code from secure area RAMarea2 into Sector B
  3. and we never, ever, unlock the CSM in the field.

Another post indicated that one could clear the CSM passwords to 0sFFFF by erasing sector A only, but leaving the other sectors alone.  Doesn't that then expose my unencrypted source in sectors B-H?

Thanks in advance...

  • Hi,

    Yes, erasing Flash Sector A to delete the CSM passwords will expose content of all the Flash Sectors as well as secure RAMs. Device security gets enable by programming the passwords in Flash Sector A and if it's erased then device is no more secure.

    Regards,

    Vivek Singh

  • So does that mean that to protect my code, it must reside, entirely, in Sector A? Since anyone could just erase Sector A and get at all the other code?

    Thanks
  • Hi,

    To erase any sector on secure device, the API need to be run from secure RAM and if you think someone could use your bootloader and follow the step you mention and then erase the Sector A, then yes you are right.  BTW, letting anyone download a code into SECURE RAM using your bootloader is not good.

    Regards,

    Vivek Singh

  • I don't ever intend to unlock in the the field, or allow anyone access to the part, for that matter.  My concern was more about malicious attempts: say someone erasing Sector A via the boot ROM and/or unsecure RAM, (or through the JTAG/emulator), and then stealing our code from the other sectors.  If I read your last post correctly that isn't possible, once the device has been locked?

    (I do intend to run everything from secure RAM, but want to be sure that all backdoor approaches to stealing our code were blocked.  If I'm not sure about the security being completely secure, we might just disallow field firmware updates altogether, rather than potentially risk exposing the code to any reverse engineering attempts)

    Thanks again,

    SPG

  • You need to incorporate the flash APIs and reprogramming kernel into your secondary bootloader in sector A. Sector A is NEVER erased. Your main application goes in the other flash sectors. When it is time to re-flash the main app, the secondary bootloader copies the APIs and kernel into secure on-chip RAM, and executes the code from there. It never needs to unlock the CSM, and again you NEVER erase sector A. This will re-flash the main app under secure conditions. You could even incorporate a decryption algorithm if necessary into the secondary bootloader, and decrypt the incoming new main app image as it comes in (over a serial port I assume).

    You mentioned the boot ROM or unsecure RAM, and someone running code from their to erase sector A. Can't happen if the CSM is locked. Code in the boot ROM or unsecured RAM is not CSM secure, and cannot operate on the flash.

    Regards,
    David
  • Hi,

    I understand that you'll not be unlocking the device in field for the upgrade but how are you planning to prevent someone else from using following method to download the code into SECURE RAM area?

    bootloader  copies the Flash API to secure RAM area 1 (because the ROM can't access secured RAM)

    Reagrds,

    Vivek Singh

  • Vivek,

    My plan is to load the FLASH APIs from Sector A(secured) to secure RAM. Based on your input above(and David's), if we can never erase SectorA, then the attacker can't ever load code into any secure area, only the bootloader can(and I suppose other securely programmed sectors as well, but not the boot ROM or other unsecured spaces). The communication with my boot code in sector A will be encrypted, so the code is never broadcast "in the clear".

    Because I can't copy from Boot ROM, either, all of this depends on me getting the flash API source (and hopefully an AES example) from the marketing email, as per this post : e2e.ti.com/.../170158

    If the attacker also has access to the flash API source, I still hope I will be safe, because my comms code won't expose the API calls directly, but rather will only allow a program or erase operation if the decrypted code checks out. I also plan to explicitly deny any Sector A erase in my boot code. So even if they could decrypt the traffic, they still can't use trick my boot code into wiping the CSM passwords.

    I'm never done a bootloader or encryption before, so let me know if I still have holes in my plan.

    Thanks,
    SPG
  • Hi,

    Ok, I mis-understood that your bootloader is getting the API from outside. This look fine to me.

    Regards

    Vivek Singh  

  • Yes.  That may still be a problem.  I followed the instructions in that earlier thread, but the email was bounced back to my junk folder yesterday.

    Is there another point-of-contact for getting the relocatable/securable API source?

    Thx,

    SPG

    (I'm in Texas, if that affects who the contact is)

  • Hi,

    You should be able to find the API in controlSUITE release, under folder "<controlSUITE_Install_Folder>\libs\utilities\flash_api\2806x\v100\lib\".

    Regards,

    Vivek Singh