Problem with DFU in XUF208

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
infiniteimprobability
XCore Legend
Posts: 1049
Joined: Thu May 27, 2010 10:08 am

Re: Problem with DFU in XUF208

Postby infiniteimprobability » Wed Feb 14, 2018 9:10 am

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.
AlexAdvice
Experienced Member
Posts: 113
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Wed Feb 14, 2018 10:18 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.
User avatar
infiniteimprobability
XCore Legend
Posts: 1049
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Wed Feb 14, 2018 11:20 am

"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?
AlexAdvice
Experienced Member
Posts: 113
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Wed Feb 14, 2018 3:42 pm

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.
AlexAdvice
Experienced Member
Posts: 113
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Thu Feb 15, 2018 7:16 pm

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?
User avatar
infiniteimprobability
XCore Legend
Posts: 1049
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Mon Feb 19, 2018 12:09 pm

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.
AlexAdvice
Experienced Member
Posts: 113
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Mon Feb 19, 2018 6:03 pm

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...
User avatar
infiniteimprobability
XCore Legend
Posts: 1049
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Tue Feb 20, 2018 9:49 am

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.

Who is online

Users browsing this forum: No registered users and 29 guests