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.
Problem with DFU in XUF208
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
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.
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.
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
This is not impossible - I guess it will be important to make sure the user only obtains images from a trustworthy source."fraud by unscrupulous user."
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?
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
Easy - user even without fraud intentions can make a mistake and burn the image from another device.infiniteimprobability wrote:This is not impossible - I guess it will be important to make sure the user only obtains images from a trustworthy source."fraud by unscrupulous user."
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.
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
Honorably speaking, it is not clear for me.
It is written in XComposer Studio User Manual:
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?
It is written in XComposer Studio User Manual:
So if there is an alien image in flash, or not encrypted - item 2 will not pass and bootloadel is halted?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.
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?
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
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:
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:
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.By default, the flash loader boots the image with the highest version with a valid CRC.
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
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...
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...
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
Of course! Feedback from this forum does make it directly into engineering at Xmos.And I'll be very glad if my topic can help to increase the usability of XMOS devices!
-
- XCore Addict
- Posts: 189
- Joined: Tue Jan 17, 2017 9:25 pm
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?
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?
-
- XCore Addict
- Posts: 189
- Joined: Tue Jan 17, 2017 9:25 pm
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?