Arria10 Secure Boot : unable to boot SPL FUSE

ChristianMS · ‎07-16-2025

On the Arria10, a signed SPL using the FUSE method does not boot at all, but it does boot when using the USER method. The behavior is the same as if we had not programmed the fuses.

Details :

Using the alt_authtool.py utility found in the repository, the SPL is signed.
The tool accepts the following options:

- fuse: embed root pubkey in image. BootROM verifies its hash against device fuses.
- fpga: fetch trusted root pubkey from location in FPGA memory.
- user: embed root pubkey in image. BootROM does not verify.

read EC key
Private-Key: (256 bit)
priv:
9e:e1:55:ec:b6:be:bd:15:22:80:73:3a:66:ee:07:
fa:58:26:1f:d0:13:c8:e5:6a:b0:05:bc:23:f7:dc:
58:46
pub:
04:0d:b3:cf:29:e9:54:60:7a:1c:d2:99:ca:5e:dd:
d0:72:98:0c:5f:89:33:2c:16:35:24:4f:65:ad:ba:
23:45:9d:ec:5e:22:06:9f:b6:b2:bd:d0:19:8c:53:
aa:af:20:1c:df:72:0f:02:e9:44:b0:86:1a:d5:b5:
7a:2c:81:65:dd
ASN1 OID: prime256v1
NIST CURVE: P-256

First, we generate the SPL using the user option, then follow the Application Note, and the Arria10 board boots correctly.

python3 -B -E $(which alt_authtool.py) sign -t user -k ${ROOT_KEY_PEM} -i ${DEPLOYDIR}/u-boot-spl-public-key.sfp -o ${DEPLOYDIR}/u-boot-spl-public-key-signed.sfp --fuseout ${DEPLOYDIR}/u-boot-spl-public-key-signed.fuse

The following text is displayed:

SHA256 digest of root public key: 3dfe63cab8b3657db2ebdeaca234f0d6ec3744a3905d7e04dfa63a5a6721dfe7

==> The SPL with USER option boots correctly.

Next, we generate the SPL using the fuse option. With this, the FPGA should only be able to boot if the fuses are programmed (volatile or non-volatile). When alt_authtool.py is executed, it displays the SHA256 hash of the public key. We use this public key to construct a file containing:

key1 3DFE63CAB8B3657DB2EBDEACA234F0D6EC3744A3905D7E04DFA63A5A6721DFE7

Using this key file, we generate an EKP file with Quartus (compressed into a zip and attached to the present message).

In the end, using the Quartus Prime Programmer, we program the Arria10 board with EKP file (this takes less than one second).

Immediately after programming the volatile fuses, the board resets (the power supply current drops from 1A to 0.8A, and then returns to 1A), and the fan stops and restarts.

==> However, on the serial console, the SPL signed with the FUSE method does not display any messages, and neither U-Boot nor the kernel is loaded.

On the other hand, the SPL signed with the USER method is still able to boot, even with the volatile fuses programmed (boot messages appear, and both U-Boot and the kernel are loaded).

Question:

Can you help us to solve this boot issue with the FUSE method ? The behavior is like volatile fuses are not programmed !

If you need more information and details, please tell us.

Thanks in advance.

Christian & Baptiste

nareshrkumar · ‎07-17-2025

Hi Christian

Thanks for bringing the issue to our notice.

I have internally started working on it; will keep you posted on the progress.

Kind Regards

Naresh

nareshrkumar · ‎07-21-2025

Hi Christian

Immediately after programming the volatile fuses, the board resets (the power supply current drops from 1A to 0.8A, and then returns to 1A), and the fan stops and restarts.

Preliminary impressions of the issue are, since the board resets after programming the volatile fuses, the saved hash is also lost. Hence, the hash comparison step fails, leading to no prints on the console.

So, basically we need to avoid reset once the fuse is flashed, this I believe is happening because reset is initiated by the Quartus tool or your programmer.

There are 2 points for us to check, one with Quartus tool and the other with your programmer:

From my end, I am checking whether Quartus is initiating the reset, and if there is a way to avoid it.
I believe you are using JTAG as your programmer, can you please check if the programmer is initiating the reset?

Thanks

Naresh

ChristianMS · ‎07-23-2025

Thank you for your involvement.

Just for your information, I was using the Programmer from Quartus Prime 23.1 (Standard Edition), while the EKP file was generated using Quartus Prime 24.2 (Pro Edition). I will try installing the same version to ensure compatibility.
We are using the "JTAG Altera USB Blaster." We’ll investigate the reset pin behavior, but if the reset does not occur, there should be an alternative way to boot the SPL (such as jumping to the entry address directly).

Best regards,

Christian & Baptiste

ThFo · ‎07-25-2025

Hi @nareshrkumar,

Thanks you for your feedback.

I'm working with Christian and Baptiste. Without further information, the project, that we working on is currently at a deadlock situation.
Do you have new information about how to bypass the reset that can be triggered by quartus ?

- Have you encountered/known issues with certain Quartus version ? (standard, pro or specific version number)
- If the USB blaster forces the reset, is there a method to bypass it using Quartus?

Thanks,
Théo

nareshrkumar · ‎07-28-2025

Hi Theo, Christian and Baptiste

Thank you for the information shared.

As of today, I am not aware of any known issues with a Quartus version.

As the issue involves multiple components, U-Boot, Quartus, programmer and signing tool etc., I am working with different teams internally to get definitive information. Please give me some more time, I will update you on the status.

Thanks

Naresh

ThFo · ‎07-28-2025

Hi nareshrkumar,

Thank you for your help, we are still listening.

Christian & Baptiste & Théo

nareshrkumar · ‎07-30-2025

Hi Theo, Christian and Baptiste

Thank you for the wait.

I have collected the information relevant to various use cases for Secure Boot in A10 but I need the below information to narrow it to your use case and help with the same.

My questions:

1. What is your objective with the Secure Boot in A10, is it for image authentication, encryption or both?

2. Also, can you please share all the steps you have run for the "fuse" use case?

Thanks

Naresh

ThFo · ‎07-31-2025

Hi @nareshrkumar , @Jeet14

Thank you for your help

About your previous questions :

1. What is your objective with the Secure Boot in A10, is it for image authentication, encryption or both?
Our objective is to enable image authentification only.

2. Also, can you please share all the steps you have run for the "fuse" use case?
The steps followed for the "fuse" use case are identical to those for "user" mode (first post), except that when executing "alt_authtool.py", we use the "sign -t fuse" option instead of "sign -t user".

If you have any further questions, please don't hesitate to ask.

Thanks,

Christian & Baptiste & Théo

nareshrkumar · ‎07-31-2025

Hi Christian & Baptiste & Théo

Thanks for sharing the information.

As you might already know A10 Secure boot supports both authentication and encryption use cases. We can use one of them or both of them based on the security needs.

Now, a) Image Authentication and Verification key can be sourced in three ways, (options here refer to python script ones):

User option --> primarily used for testing purposes, volatile and reprogrammable; public key hash check is not performed by Secure Manager in HPS
Fuse option --> Key Authorization Key (KAK) hash is programmed in User Access Fuses (UAF), non-volatile and one time programmable (OTP)
FPGA option --> fetched from FPGA OCRAM

Note: Need to use “sign” option with the python tool for image authentication use cases

b) Image Encryption and Decryption key can be stored as:

Volatile --> external battery source must be connected to VccBat to retain the key during reset, reprogrammable
Non-volatile --> fuses blown and OTP

Note: Need to use “encrypt” option with the python tool for image encryption use cases

You have mentioned you are using "sign" and "fuse" options with the python tool, so I am confused why you are loading ekp file to the board?

If your intention is to use authentication --> fuse option described above, you need to copy SHA256 of the public key to a text file and load it to the board.

The KAK key hash has a defined format by Altera. I need to check with the team to share this information, please let me know if this is your requirement.

Here are some documentation resources which might help you:

AN 759: Using Secure Boot in Intel® Arria® 10 SoC Devices
A10 Technical Reference Manual --> refer to Chapter 7 SoC Security

Kind Regards

Naresh

ThFo · ‎07-31-2025

Hello,

Thank you very much for your answer.
We are starting to understand that we misunderstood the process…

We indeed want to only use *authentication* (without encryption).

We succeeded in signing our SPL, and booting it. For this, we use the 'sign' and '-user' options.
This validates the fact that our SPL is correctly signed with our key, but as expected, does NOT check that the key is trusted (because its hash is not verified).

We thought that the EKP file could be used to inject the SHA256 hash of the signing key into *volatile* memory, so that we could validate the whole process before flashing in OTP. In fact, your explanation seems to confirm that the EKP file is only useful to inject key used when encrypted SPL is selected. In our case, the EKP file seems useless.

Question 1: Can you confirm this understanding?

If this is the case, we understand that the next step in our case is to flash the OTP fuses for authentication only:
- Flashing the SHA256 hash of the signing key (i.e., the KAK key hash?)
- Flashing the fuses that says that the signature must be check (bit authen_en_f, kak_len_f, kak_src_f, ...)

Question 2 : Can you confirm that? How can we do that?

Best regards,

Christian & Baptiste & Théo

nareshrkumar · ‎07-31-2025

Hi Christian & Baptiste & Théo

Thank you for your response.

Your understanding with respect to Question 1 is correct.

Regarding your further questions related to flashing hash and fuse bits, I have already informed the concerned people at Altera. I am waiting for their response, once I have I will share it at the earliest.

Kind Regards

Naresh

nareshrkumar · ‎08-03-2025

Hi Christian & Baptiste & Théo

I got information saying, we need NDA to share the secure fuse flashing information. If you don't mind, can you please share your company name and whether it has NDA with Altera?

Meanwhile, I have asked for a contact at Altera to connect with your team on email and help you with the NDA and sharing of fuse information.

Thank you for your patience

Naresh

nareshrkumar · ‎08-05-2025

Hi Christian & Baptiste & Théo

I have got confirmation from my team that they have initiated communication via email to help you with NDA and sharing the relevant fuse flashing information accordingly. I believe you should have received the email by now.

Hope this helps!

Kind Regards

Naresh

ThFo · ‎08-21-2025

Hello

Sorry for the delay, we were on vacation.
We sent a response to the email regarding the NDA on the 19th (Tuesday) and are now waiting for the document.

Best regards,

Christian & Baptiste & Théo

ThFo · ‎08-26-2025

Hello @nareshrkumar , @Jeet14,

We haven’t received much information about the NDA since the email sent on the 19th. Do you have any updates regarding the NDA document?

Best regards,

Christian & Baptiste & Théo

nareshrkumar · ‎08-26-2025

Hi Christian & Baptiste & Théo

I will check with the respective team and get back to you.

Kind Regards

Naresh

nareshrkumar · ‎08-28-2025

Hi Christian & Baptiste & Théo

I have got a response from the team that they received your NDA and currently, it is being validated. The team has been notified about the urgency and I have been informed, they will respond to you at the earliest; it could be as early as this week.

Thank you for your patience

Naresh

Jeet14 · ‎07-31-2025

Hi Theo & Christian,

Any update on the previous post by Naresh Kumar.

Regards

Tiwari