Queries regarding code protection of XMOS L1 chip from unaut

[jagspaul]

I am familiar with ATMEL & PIC controller. In this Controller code protection is very simple. Just program the security bit during programming the internal code flash. The main beauty is that with a chip erase the security bit can be erase and new code can be re-program.

Now my question is:
In case of XMOS L1 controller if security bit of the AES module is programmed with proper authentication and description key after encrypted image is burned on external flash then how the chip can be re-used for different image with code protection security active?

From this document (http://www.xmos.com/safeguard-ip-and-de ... ?support=1) I came to know about XMOS code protection. But still now I have lots of confusion. Actually I need to know for enabling code protection if any one do some mistake then what will happed? The chip will be unused or the same can be reused. Actually I have only one L1 board and I afraid to do the code protection experiment. If my board becomes unused my R&D will be stopped. So before going for this I want to clear all the confusion first.

Secure boot procedure
1. The device loads the primary bootloader from its ROM, which detects that the secure boot bit is set in the OTP and then loads and executes the AES Module from OTP.
My question:
What is primary bootloader? Is it user build or pre loaded during fabrication of the chip.

2. The AES Module loads the flash loader into RAM over SPI.
3. The AES Module authenticates the flash loader using the CMAC-AES-128 algorithm and the 128-bit authentication key. If authentication fails, boot is halted.
4. The AES Module places the authentication key and decryption key in registers and jumps to the flash loader.

My question:
What is flash loader? Is it user build or it is build by XMOS programming tools?

Develop with the AES module enabled
We can activate the AES Module at any time during development or device manufacture. In a development environment, you can activate the module but leave the security bits unset, enabling:
• XFLASH to use the device to load programs onto flash memory,
• XGDB to debug programs running on the device, and
• XBURN to later write additional OTP bits to protect the device.

My question:
If the security is unset then what is the purpose to activate the AES Module as we leave the security bit unset?

To program the AES Module into the XMOS device we have to give the following commands on XMOS command prompt.
1) xburn –genkey keyfile
2) xburn –l
3) xburn –id ID –lock keyfile –target-file target.xn –enable-jtag –disable-master-lock
To encrypt the program and write it to flash memory, the command needs to be entered
xflash –id ID bin.xe –key keyfile
To protect the XMOS device, preventing any further development, enter the command:
xburn –id ID –target-file target.xn –disable-jtag –lock keyfile

My question:
After preventing the XMOS chip with protection active if any one want to change the code, then how he will burn the new code?

Thanks & Regards
Jags

[rp181]

What is primary bootloader? Is it user build or pre loaded during fabrication of the chip.

What is flash loader? Is it user build or it is build by XMOS programming tools?

Not sure about this, but I think the bootloader is the pre-loaded flash loader to read the flash chip over SPI from the system partition. I believe this can be customized for some specialized purposes (e.g., reading a different place on the flash chip).

If the security is unset then what is the purpose to activate the AES Module as we leave the security bit unset?

The security bit isn't actually for encryption (which is what the AES module is), but bits to prevent bypassing code loading. When the security bits are set, the cores will only boot from the OTP, not JTAG. During development, you wan't to be able to re-program it, so you leave the OTP alone, but can still use the encryption with XFlash, XRun, and XGDB. XBurn will blow the security bits.

After preventing the XMOS chip with protection active if any one want to change the code, then how he will burn the new code?

Once the OTP is burned, the code cannot be changed. You would have to use another processor.

I don't have a lot of experience with XMOS low level function/security, but this is how I understand it to be.

[jagspaul]

After preventing the XMOS chip with protection active if any one want to change the code, then how he will burn the new code?

Once the OTP is burned, the code cannot be changed. You would have to use another processor.

Please remember that I am asking about binary. The encryption code and security bit are programed on OTP and binary is loaded on external SPI flash. Now if the user modify the user code and build the binary image with the same encryption code file which is programed on OTP and reload the binary image on external SPI flash with third party SPI flash programmer.
As per my view technically it is possible.

Now my question is:
In this case can it possible to load the new binary image on external SPI flash through XMOS jtag debugger?

[jagspaul]

If the security is unset then what is the purpose to activate the AES Module as we leave the security bit unset?

The security bit isn't actually for encryption (which is what the AES module is), but bits to prevent bypassing code loading. When the security bits are set, the cores will only boot from the OTP, not JTAG. During development, you wan't to be able to re-program it, so you leave the OTP alone, but can still use the encryption with XFlash, XRun, and XGDB. XBurn will blow the security bits.

I understand during development , having AES module active and security bit unset I can reload my binary with XFlash.

xflash –id ID bin.xe –key keyfile

But I dont know in this situation how to use XRun, and XGDB

[jagspaul]

After waiting a long time I have not received any faithful reply which can clear all my doubts regarding code protections.
Actually without this we can't protect our code from unauthorized copy. So commercially we can't take XMOS in our production as long as we do this.

Hope XMOS employee will come forward to help there customer & developer to make there product more populer.

regards
jags

[Bianco]

After waiting a long time I have not received any faithful reply which can clear all my doubts regarding code protections.
Actually without this we can't protect our code from unauthorized copy. So commercially we can't take XMOS in our production as long as we do this.

Hope XMOS employee will come forward to help there customer & developer to make there product more populer.

regards
jags

If you require fast answer and confirmation of things you need to create a support ticket on the XMOS website. Xcore is supported by XMOS on best effort.