03-09-2018 12:34 AM
I try to implement RSA authentification on a Zynq 7030 device with 2017.4 version of tools. I use XAPP1775, XAPP1278, UG821, UG585 as reference documents.
I have done all the step in the XAPP1175 for generate MCS files in "Bootgen Debug Mode Step" and "Bootgen Release Mode Step". I use "diff" tools to compare the MCS file. It result that the files as not the same.
I'have tried differents methods to generate the RSA keys, but only one give me the same MCS file :
- Method 1 : the keys was generate with openSSL in pem format : the MCS files was not the same.
- Method 2 : the keys was generate with bootgen with the option "-generate_keys auth rsa" : the MCS files was not the same.
- Method 3 : the keys was generate with bootgen with the option "-generate_keys auth pem" : the MCS files was not the same.
- Method 4 : the keys was generate with bootgen with the option "-generate_keys auth pem", then keys are converted with the perl script "convert_key.pl" in rsa format (N, E, D, P, Q coeff). With this method the MCS files was the same.
With the option "-generate_keys auth rsa", bootgen generate the secret keys files with N, E D coeff only.
The XAPP1175 design files contains secret keys in rsa format (N, E, D, P, Q coeff) and if I use this keys, the MCS files are the same for my design.
So what is the good method to generate the keys and the MCS/binary with the RSA authentification ?
03-09-2018 10:29 PM
I am working on bootgen and authentication in xapp1175.
On page 29 ,
bootgen -image generate_aeskey.bif -o temp.mcs -encrypt bbram
It lets me add -p
bootgen -image generate_aeskey.bif -o temp.mcs -encrypt bbram -p xc7z010
but it always stop working. I have tried -p to xc7z010clg400 , ...
Have you meet such case？
10-11-2019 06:33 AM - edited 10-13-2019 10:14 PM
Have you found anything so far? I'm facing the same issue and it seems the issue is not attractive enough for Xilinx employees.
I'm following UG1283 which is mostly same and duplicate with other secure boot documents Xilinx published. My release and debug mode images come out to be different, as well and I'm investigating the images.
What I've found so far:
I'm comparing the images byte-by-byte using "vbindiff" tool. Both images are mostly the same EXCEPT the signatures. I'm giving the same public and private keys to the bootgen for debug and release modes, as you did, but I saw that while I can see my own signatures (spk.pub.sha256.sig) in the release image, the signatures I found in the debug mode is not from me. This causes release image to be invalid. The debug mode image is booting however release mode image fails booting the ZYNQ.
Again; have you found anything so far?
Dosto the embedder
10-14-2019 09:37 AM
A mismatch between the signatures usually indicates a misstep somewhere in the flow.
Short of double checking every single step, I am not sure what to suggest.
Maybe try to simplify as much as possible your image and make the debug vs release mode matching with (for example) RSA only.
Once you have a simple use case working, add more complexity to it.
The debug mode is your reference and the one you need to be able to match 100% in order to boot.
NOTE: Are you using bootgen_utility to compare the images? It's a nice tool and might give you more insigh on the differences.
10-14-2019 10:22 AM
Question: Are you using openSSL or xil_rsa_sign to sign your partititons/hashes in the HSM flow?
10-15-2019 07:08 AM
Thanks for the reply. I'm using openSSL to sign. That's because the xil_rsa_sign just crashes with a segfault (64 bit ubuntu). Something is wrong with xil_rsa_sign tool, is it still being maintained? The command line args stated in the XAPP1175 (2019.2) don't exist in xil_rsa_sign (downloaded from link in that document). For example: "-sk" is is written in xapp however xil_rsa_sign tool wants either "-psk" or "-ssk". It's hard to guess which one is more up-to-date: xapp1175 or the tool. It would be nice to have a working xil_rsa_tool.
I found something remarkable: I've learned that sha256 hashes must 256-bit-reversed before being signed; and then re-reversed after signed (using objdump). I've noticed that in the latest "bat" script found in the xapp1175's examples and dealing with that example flow right now (unfortunately the guy who prepared the example loves mixing up the things and not gifting a ready-to-run example to his/her readers; folder structure used in the script doesn't exists and you have to guess, rename and move that files into right folders...).
I did the same with the "release_mode_OPENSSL_HSM.bat" and problem 1/2 is solved: Now. spk.pub.sha256.sig and ImageHeaderTable.sha256.sig are the same in final debug and release images. Problem 2 is: Partion signatures are still different (fsbl.elf.0.sha256.sig, system.bit.0.sha256.sig...).
In the bat file, he/she first reverses the bytes of all hashes (ImageHeaderTable, fsbl, etc.) and signs and then reverses-back. I'm doing that for all signature operations but as I said, fsbl, bitstream and u-boot comes different.
Working on it, and looking for any reply.
10-18-2019 01:07 AM - edited 10-18-2019 01:10 AM
10-18-2019 08:39 AM - edited 10-18-2019 08:55 AM
The only issue I am aware of in the openSSL flow is described in https://www.xilinx.com/support/answers/67075.html
NOTE: The AR is temporarly off-line but it should be back up in few days.
Signing the FSBL partititon HASH shuoudl look like this:
#Swap the bytes in FSBL hash
objcopy -I binary -O binary --reverse-bytes=256 zynq_fsbl_0.elf.0.sha256
#Generate FSBL signature using OpenSSL
openssl rsautl -raw -sign -inkey secondary.pem -in zynq_fsbl_0.elf.0.sha256
#Swap the bytes in FSBL signature
objcopy -I binary -O binary --reverse-bytes=256 zynq_fsbl_0.elf.0.sha256.sig
10-23-2019 12:30 AM - edited 10-23-2019 12:31 AM
I am eagerly waiting for that AR to be up. If you have access, or if you remember it, could you please briefly say what was that issue about? We are stuck, as I said, and any information is so much valuable now.
10-23-2019 02:14 AM - edited 10-23-2019 05:49 AM
I finally made xil_rsa_sign ran; my mistake was I didn't convert my openssl keys to xilinx key format in my past tries, which caused segmentation fault.
Now I confirm that both openssl and xil_rsa_sign produce the same signature (they are different from what bootgen produces, though) so what I did using openssl was not wrong.
It looks I am stuck more than ever. No way.
I can send you a postcard if you solve my issue.
10-24-2019 06:20 AM
Hello all but Xilinx documentation team,
My issue is solved. Please refer https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/FSBL-won-t-boot-in-secure-boot-with-HSM-mode/m-p/1030581/highlight/false#M3777 for more.