Forum Discussion

ChristianMS's avatar
ChristianMS
Icon for New Contributor rankNew Contributor
5 months ago

Arria10 Secure Boot : unable to boot SPL FUSE

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 : Usi...
Hps Boot
ThFo's avatar
ThFo
Icon for New Contributor rankNew Contributor
4 months ago

Hi nareshrkumar,

Thank you for your help, we are still listening.

Christian & Baptiste & Théo

nareshrkumar's avatar
nareshrkumar
Icon for New Contributor rankNew Contributor
4 months ago

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's avatar
    ThFo
    Icon for New Contributor rankNew Contributor
    4 months ago

    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's avatar
      nareshrkumar
      Icon for New Contributor rankNew Contributor
      4 months ago

      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):

      1. User option --> primarily used for testing purposes, volatile and reprogrammable; public key hash check is not performed by Secure Manager in HPS
      2. Fuse option --> Key Authorization Key (KAK) hash is programmed in User Access Fuses (UAF), non-volatile and one time programmable (OTP)
      3. 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:

        1. Volatile --> external battery source must be connected to VccBat to retain the key during reset, reprogrammable
        2. 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:

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

      Kind Regards

      Naresh

      • ThFo's avatar
        ThFo
        Icon for New Contributor rankNew Contributor
        4 months ago

        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