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

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