1

I am implementing external code execution for STM32F765VG with NOR flash (8/16 bit). The idea is to execute code from external flash memory. are there any ways to protect my code present in external memory from unauthorized access?

I have understood about following two methods presently. But, i am not sure whether i am thinking in right direction. Also, please guide me in right direction.

Method 1:
Encrypt whole code Hex file blockwise, before flashing to external memory. Load the blocks with normal read to the internal RAM, decrypt in the internal RAM and execute it from RAM. By this method, there will be no possibility for external parties to understand the code content of external flash memory.

Method2:
Recompile the software for every MCU and flash combination based on the unique hardware ID of flash memory and MCU ID. This way, even if the code is copied by third party, it will not execute as the IDs of new MCU will not match with the ID assumed in the code.

Please suggest if there are standard practices. Thank you in advance!

User323693
  • 9,151
  • 4
  • 21
  • 50
  • Why do you need code protection? Proprietary algorithms? Unauthorized changes to the code? Generally any shield can be broken these days, the only question how hard you want to make it to be broken, and do you need it at all (having other ways to identify unauthorized changes to the code). – Anonymous May 02 '17 at 09:52

1 Answers1

1

Well first of all: You've chosen the wrong chip for the job. If your this paranoid into securing your application code, you should get a chip that:
- supports storing crypto codes. (special masking layer is required for this)
- supports execution from encrypted memory. (special memory bus required)

But at least you can try:
Method 1 has most balance between secure and effort. However, it will add boot time since you don't have hardware accelerated crypto.
It's not hard to deploy, but it won't give absolute security. You'll need to store the decryption key on the same board.
Encrypt each device with a new random key. Don't base your key on the ID.

When anyone looks at the dissembler of the bootloader, it will be obvious where the key comes from. Make sure the key is gone when someone is looking at the bootloader.
This will get you more returned devices.

Method 2 is hard to deploy. It could require you to distribute your objects to any subcontractor doing assembly and testing. However, you can't prevent anyone who really wants to have the code to read it. And anyone looking into the dissembler can easily remove the instructions since the ID locations are known.

Jeroen3
  • 21,976
  • 36
  • 73
  • Thanks for your reply. In method 1, if I disable jtag and debug access, how can anybody access boot loader code still? – User323693 May 03 '17 at 13:19