UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant toxup_1
Participant
586 Views
Registered: ‎02-12-2016

Zynq fallback with new encryption key

Jump to solution

I'm implementing a system where I want to perform remote upgrades. I imagine years from now wanting to push a boot image with new keys. How would I go about doing this?
If I have something like the following partition table:

0: Primary boot
1: Primary boot update
2: Fallback boot
3: Fallback boot update

So the system receives new boot images (primary and fallback updates) to be written to 1 and 3. How can these be encrypted with new keys?

Thanks a lot for any guidance!

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
319 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

Suggestion:

If you don't force the encryption programming the eFUSE you can boot securely or non-securely depending on the boot header.

Let's say you have a working encrypted image first and a non-secure image for fallback.

In this case the update should look like this:

1- Erase the boot header of the secure image first.

2- Erase the whole secure image

3- Update the key

4- Write the new secure image except the boot header

5- Write the boot header of the new secure image

6- Issue a POR_B

If anything goes wrong you should be able to temporary boot into the non-secure fallback image.

the boot header is the key to avoid try to boot securely and fallback non securely. Does that make sense?

 

 

 

0 Kudos
12 Replies
Participant toxup_1
Participant
539 Views
Registered: ‎02-12-2016

Re: Zynq fallback with new encryption key

Jump to solution
I realize I'm not completely able to distinguish the difference between multiboot and fallback. Now a solution such as the following i desired:
- Primary boot encrypted and key stored in BBRAM
- Fallback/golden boot encrypted and key stored in eFUSE
How would a rough outline of the .bif file look like?
0 Kudos
Xilinx Employee
Xilinx Employee
520 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

You need two separate .bif. One for your primary image and the other one for fallback.

The boot header will tell the key source to the ROM.

NOTE: If the device try to boot using the key from eFUSE, it cannot fallback to an image with key in BBRAM.

You need a POR in between, so this method only work if the device doesn't see the primary image at all (the boot header is corrupt).

I don't think this is the right way to fallback.

Participant toxup_1
Participant
500 Views
Registered: ‎02-12-2016

Re: Zynq fallback with new encryption key

Jump to solution
With Multiboot, as one boot image fails to load, e.g. the decryption fail, the CSU boot room searches for another valid boot image, updates the Multiboot offset and initiates a soft system reset (NOT POR).

Does this mean that the boot header of the backup boot image (at a higher multiboot offset) is ignored? After all the boot header specifies the device key source.

This is also what I've understood from your reply. I need to find some way of perhaps renaming the boot images so that the primary boot image header is not read at all.
For instance: changing boot0000.bin to boot0001.bin and vice versa.

Thanks.
0 Kudos
Xilinx Employee
Xilinx Employee
477 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

Your understanding is correct. If the ROM try to boot with an image encrypted, the possible fallback needs to have the same key source.

If not the ROM won't fallback and will throw this error:

0x52 = Changing the key source is not allowed while in the secure state.

0 Kudos
Participant toxup_1
Participant
472 Views
Registered: ‎02-12-2016

Re: Zynq fallback with new encryption key

Jump to solution

What if the fallback is not encrypted?

0 Kudos
Xilinx Employee
Xilinx Employee
351 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

Same concept. You cannot try to boot securely and then fallback to non-secure.

0 Kudos
Participant toxup_1
Participant
328 Views
Registered: ‎02-12-2016

Re: Zynq fallback with new encryption key

Jump to solution

That also makes sense. Now what if I have 1000 units Im pushing remote updates to, with a new key written to BBRAM. If anything goes wrong in that process, I have nothing to fall back to. The whole fall-back concept is useless in this scenario unless I'm able to fall back to an image encrypted(or just authenticated) with a key in eFUSE.

My experience now from trying this with a dev board is that my 1000 units will practically brick in such a scenario. I'll have to bring in all those decices and reconfigure them by hand.

0 Kudos
Xilinx Employee
Xilinx Employee
320 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

Suggestion:

If you don't force the encryption programming the eFUSE you can boot securely or non-securely depending on the boot header.

Let's say you have a working encrypted image first and a non-secure image for fallback.

In this case the update should look like this:

1- Erase the boot header of the secure image first.

2- Erase the whole secure image

3- Update the key

4- Write the new secure image except the boot header

5- Write the boot header of the new secure image

6- Issue a POR_B

If anything goes wrong you should be able to temporary boot into the non-secure fallback image.

the boot header is the key to avoid try to boot securely and fallback non securely. Does that make sense?

 

 

 

0 Kudos
Participant toxup_1
Participant
260 Views
Registered: ‎02-12-2016

Re: Zynq fallback with new encryption key

Jump to solution

Yes it really does. I just didn't think of this being doable at all. How easy is it to separate the header from the boot image? A header transplant basically.

Edit: So to clarify my question, will the boot header always be as in Table 11-4 of UG1085?

0 Kudos
Xilinx Employee
Xilinx Employee
235 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

It has been done before. You really just need to "corrupt" the synchword in the header of your BOOT.bin.

Write it up and, as last step, write the correct synch word.

0 Kudos
Xilinx Employee
Xilinx Employee
234 Views
Registered: ‎10-11-2011

Re: Zynq fallback with new encryption key

Jump to solution

- Will the boot header always be as in Table 11-4 of UG1085?

Yes, the format won't change.

The synch word I was refering to is at 0x24 "Image identification".

0 Kudos
Participant toxup_1
Participant
199 Views
Registered: ‎02-12-2016

Re: Zynq fallback with new encryption key

Jump to solution
Thank you dentist! Really appreciate the help.
0 Kudos