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: 
Observer martin6314
Observer
762 Views
Registered: ‎02-16-2018

Authentication of secondary images: XFSBL_ERROR_SPK_RSA_DECRYPT

Jump to solution
Hello,
 
We have a problem on authenticated boot of secondary images on the SDK2018.1 FSBL and bootgen on a Zynq ultraScale+ MpSoc device.
 
If we authenticate only the bootloader (with fuses), the authentication passes and images boot as expected.
 
If we turn on authentication of the rest of the images, we observe that during FPGA partition read, the FSBL tries to (re-?) check the primary public key hash and the "Ppk Modular START" shows all zeros. Then the partition stage fails with
    XFsbl_SpkVer: XFSBL_ERROR_SPK_RSA_DECRYPT
    XFSBL_ERROR_BITSTREAM_AUTHENTICATION
    Partition 1 Load Failed, 0x2F
 
Is there anything wrong with our bif file (attached)?
See also the attached log of the FSBL.
 
The call stack of the error:
    XFsbl_PartitionValidation
    XFsbl_SecPlPartition
    XFsbl_PlBlockAuthentication
    XFsbl_SpkVer
 
We would appreciate very much any hints on what we are doing wrong.

Best regards
Martin
0 Kudos
1 Solution

Accepted Solutions
Observer martin6314
Observer
845 Views
Registered: ‎02-16-2018

Re: Authentication of secondary images: XFSBL_ERROR_SPK_RSA_DECRYPT

Jump to solution
We found a solution:
 
If the option bh_auth_enable is set, the FSBL correctly authenticates the keys.
This is ok for a first check of an image but the rsa-hash is not checked in this case.
(see UG1137, page 106: "... where actual PPK hash is not compared with the eFUSE stored value.")
 
If the option bh_auth_enable is not set, the FSBL will behave correctly if the Enforce-RSA fuse is burned.
However, in a test setup we want to check the FSBL behavior without having to blow the Enforce-RSA fuses first.
Because ones the fuses are burned we are in trouble if anything fails.
 
So our scenario is AES and RSA-hash fuses are burned, but the Enforce-RSA-fuse is not burned yet.
Now, we would like to check authentication including the rsa-hash so we turn off bh_auth_enable
and set authentication=rsa in the bootloader image.
 
In this case, the FSBL does not copy the EfusePpkKey, because XFsbl_ValidateHeader will not call XFsbl_BhAuthentication.
So it starts as if there was no key. But later, when treating the partitions, it wants to check
the PPK hash anyway. It finds a zero key and aborts booting.
 
We solved the problem, by changing the behavior of XFsbl_ValidateHeader such, that it will call
XFsbl_BhAuthentication not only when RSA fuses are set or bh_auth_enable is set, but also when
AcOffset is not zero. See attachment based on the 2018.1 version of the sample code.
 
This solved our problem but this seems to be a use case that xilinx did not assume.
With this approach we can validate the image and the rsa-hash fuses before closing the device. 

View solution in original post

0 Kudos
4 Replies
Xilinx Employee
Xilinx Employee
739 Views
Registered: ‎10-11-2011

Re: Authentication of secondary images: XFSBL_ERROR_SPK_RSA_DECRYPT

Jump to solution

Which eFUSE did you program on the device? PPK0, SPK_ID, anything else?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Observer martin6314
Observer
719 Views
Registered: ‎02-16-2018

Re: Authentication of secondary images: XFSBL_ERROR_SPK_RSA_DECRYPT

Jump to solution
Hi Denis,
 
We programmed PPK0, SPK_ID=0x584C4E58, the AES fuses and USER2=0x3. We did not program any other fuses (yet) because we want to test with and without authentication until we send the device to the first customer.
 
Thank you very much for considering our problem.
 
Best regards
Martin
0 Kudos
Xilinx Employee
Xilinx Employee
706 Views
Registered: ‎10-11-2011

Re: Authentication of secondary images: XFSBL_ERROR_SPK_RSA_DECRYPT

Jump to solution

Are you using the attribute bh_auth_enable in your .bif.

That's the way to test AUTH without programming RSA_EN,

See UG1085 and UG1137 for more info.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Observer martin6314
Observer
846 Views
Registered: ‎02-16-2018

Re: Authentication of secondary images: XFSBL_ERROR_SPK_RSA_DECRYPT

Jump to solution
We found a solution:
 
If the option bh_auth_enable is set, the FSBL correctly authenticates the keys.
This is ok for a first check of an image but the rsa-hash is not checked in this case.
(see UG1137, page 106: "... where actual PPK hash is not compared with the eFUSE stored value.")
 
If the option bh_auth_enable is not set, the FSBL will behave correctly if the Enforce-RSA fuse is burned.
However, in a test setup we want to check the FSBL behavior without having to blow the Enforce-RSA fuses first.
Because ones the fuses are burned we are in trouble if anything fails.
 
So our scenario is AES and RSA-hash fuses are burned, but the Enforce-RSA-fuse is not burned yet.
Now, we would like to check authentication including the rsa-hash so we turn off bh_auth_enable
and set authentication=rsa in the bootloader image.
 
In this case, the FSBL does not copy the EfusePpkKey, because XFsbl_ValidateHeader will not call XFsbl_BhAuthentication.
So it starts as if there was no key. But later, when treating the partitions, it wants to check
the PPK hash anyway. It finds a zero key and aborts booting.
 
We solved the problem, by changing the behavior of XFsbl_ValidateHeader such, that it will call
XFsbl_BhAuthentication not only when RSA fuses are set or bh_auth_enable is set, but also when
AcOffset is not zero. See attachment based on the 2018.1 version of the sample code.
 
This solved our problem but this seems to be a use case that xilinx did not assume.
With this approach we can validate the image and the rsa-hash fuses before closing the device. 

View solution in original post

0 Kudos