XCore Exchange

The security mechanism is designed to make it hard to reverse engineer, copy or inject unwanted images at boot time - it uses a secure boot mechanism to encrypt the data stored in the external flash. In addition, JTAG and link access can be disabled, which effectively leaves you with a secure island. This was designed as a low-level generic security mechanism with a whole range of applications in mind.

However, an authentic image running on the secured chip can do whatever it likes (except modify OTP if that is disabled in HW) - it's completely controlled by what got flashed on to the chip by the user.

Your factory image is an authentic binary. However, it has DFU enabled. The USB Audio DFU has not been designed to be aware of security - it just handles binaries which are CRC checked to check for errors.

I understood.
This job DFU doing well, but any case there is a way to fraud by unscrupulous user.
Especially, using CPU with internal Flash (XUF) and JTAG disabled.

"fraud by unscrupulous user."

This is not impossible - I guess it will be important to make sure the user only obtains images from a trustworthy source.

We'll add a feature/enhancement request to our dfu development for authentication on the lines of secure boot.

The DFU mechanism is provided as source so perhaps you could prepend a header or append a tail to the DFU image (which could be some secret hash of the rest of image) and use that to abort the DFU attempt if it is not authentic?

infiniteimprobability wrote:

"fraud by unscrupulous user."

This is not impossible - I guess it will be important to make sure the user only obtains images from a trustworthy source.

Easy - user even without fraud intentions can make a mistake and burn the image from another device.

And I think, there is a simple solution to prevent this - just to add second CRC to the source image (not encrypted) and let bootloadet to check it after decryption.
So, it will be 2 stages:
1) Bootloader check 1st CRC of the encrypted image in flash. If OK - decrypt it to RAM, otherwise - use previous image in flash.
2) Bootloader check 2nd CRC of the image in RAM. If OK - run it, otherwise - got to item 1 and use previous image in flash.

Item 1 even can be omitted, but better to keep it to have double protection.

Honorably speaking, it is not clear for me.
It is written in XComposer Studio User Manual:

1. Selects the image with the highest number that validates against its CRC.
2. Authenticates the selected image header using its CMAC tag and authentication
key. If the authentication fails, boot is halted.
3. Authenticates, decrypts and loads the table of program/data segments into
memory. If any images fail authentication, the boot halts.
4. Starts executing the program.

So if there is an alien image in flash, or not encrypted - item 2 will not pass and bootloadel is halted?
Why first not to try the previous image?
If it also fails (or there is no previous image in flash) - use factory image, which must be OK by default?

I see your point. I checked in more detail and the first CRC check is done on the first page only (to save reading the entire image each time) which then decides the final boot image to load. The CMAC check and loading (with decryption etc.) is done streaming as the image is written to RAM.
However I guess the behaviour of halting boot rather than falling back to the previous (or factory image) is the issue for you here. We discussed this and can see that it may be advantageous to have a fallback mechanism in many cases, just like the CRC check does:

By default, the flash loader boots the image with the highest version with a valid CRC.

It's a fairly big deal to change the behaviour of a published security mechanism and regress it (so cannot commit a schedule) but nevertheless I'll add a feature enhancement to that product.

Hi infiniteimprobability,

it will be very good!

And I'll be very glad if my topic can help to increase the usability of XMOS devices!


P.S. You are right - it can be the halted boot, but to user it doesn't matter - in any case he got the brick...

And I'll be very glad if my topic can help to increase the usability of XMOS devices!

Of course! Feedback from this forum does make it directly into engineering at Xmos.

I have a question along the lines of this thread, so I will ask it here instead of starting a new one.

What would a "factory button" need to do, from the standpoint of the reference design software, to revert to say a factory image if a DFU .bin without a keyfile was loaded?

OK, after some reading, I realize it can be implemented in a flash loader, however wouldn't that still need to be programmed into the DFU .bin with a proper keyfile? Maybe there can at most be only one Flash Loader programmed with the factory image?