• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 106 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA821U-Q1: About Secure Boot

user4852186
Intellectual 340 points
Part Number: DRA821U-Q1
Other Parts Discussed in Thread: J7200XSOMXEVM

Tool/software:

Hi,

We have designed a custom board based on the J7200XSOMXEVM reference design.

Thanks to the following forum We were able to make our custom board an HSSE device:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1542364/dra821u-q1-about-keywriter-application-error-codes/5941929?tisearch=e2e-sitesearch&keymatch=%20user%3A298257#

The next step is to perform a secure boot authentication check.

Therefore, we tested the booting of the following software combinations:
- Bootloader and FitImage generated using the default custMpk.*
- Bootloader and FitImage generated using a custom custMpk.*

The test results are listed below.

Bootloader FitImage Result
default custMpk.* default custMpk.* The bootloader won't start
default custMpk.* custom custMpk.* The bootloader won't start
custom custMpk.* default custMpk.* The kernel starts
custom custMpk.* custom custMpk.* The kernel starts

We assumed that "FitImage authentication failed" in the red area.

Is our understanding wrong? Also, how can I cause an authentication error in FitImage that is not properly signed?

Regards
mizutani

  • +1
    TI__Guru 57115 points

    Hi mizutani

    Couple question here.

    • What is the boot flow you are using ?
    • How you are authenticating the fitimage?
    • What components your fit image contains?
    user4852186 said:

    We assumed that "FitImage authentication failed" in the red area.

    Your understanding is right.

    user4852186 said:
    Is our understanding wrong? Also, how can I cause an authentication error in FitImage that is not properly signed?

    From the table i see your board is flashed with the custom public key. That is the reason whenever you are using default key image is failing for you due to authentication failure.

    user4852186 said:
     Also, how can I cause an authentication error in FitImage that is not properly signed?

    You are already having the failed image right, if you are singing the image with the wrong key, you will get authentication failure.

    Regards
    Diwakar

  • 0 in reply to Diwakar Dhyani
    Intellectual 340 points

    Hi

    Sorry, I accidentally clicked "This resolved my issue."

    Diwakar Dhyani said:
    What is the boot flow you are using ?

    What does "boot flow" refer to? Our software is based on "PROCESSOR-SDK-LINUX-J7200".

    Diwakar Dhyani said:
    What components your fit image contains?

    FitImage contains the kernel and device tree.

    Diwakar Dhyani said:
    How you are authenticating the fitimage?

    In u-boot, run the following command:
    bootm ${addr_fit}#conf-<custom-board>.dtb

    The authentication log is shown below (FitImage built with "default custMpk.*").

    ## Loading kernel from FIT Image at 90000000 ...
   Using 'conf-<custom-board>.dtb' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x900000e0
     Data Size:    22573568 Bytes = 21.5 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x81000000
     Entry Point:  0x81000000
     Hash algo:    sha512
     Hash value:   8bcf61cb5e6b011ef674910e00883b03ce1374cd960c8fd3914db382515feee9360c08d3e3ae858a4893c71fdd6aa4b24ca47b5f525cc05053176f1aee59f2dc
   Verifying Hash Integrity ... sha512+ OK
## Loading fdt from FIT Image at 90000000 ...
   Using 'conf-<custom-board>.dtb' configuration
   Verifying Hash Integrity ... OK
   Trying 'fdt-<custom-board>.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x91587418
     Data Size:    75061 Bytes = 73.3 KiB
     Architecture: AArch64
     Load Address: 0x83000000
     Hash algo:    sha512
     Hash value:   5301fcccdfa3d7794ac5dec6fb313ffe4d4df06da92d71e7ed172034e7a9bb35270c67e9926487a6412ada2e6c724bc4f56c9d979373a9f6c03b6ef7414b8690
   Verifying Hash Integrity ... sha512+ OK
   Loading fdt from 0x91587418 to 0x83000000
   Booting using the fdt blob at 0x83000000
Working FDT set to 83000000
   Loading Kernel Image to 81000000
   Loading Device Tree to 000000008ffea000, end 000000008ffff534 ... OK
Working FDT set to 8ffea000

    I want the authentication of the FitImage built with "default custMpk.*" to fail, but the authentication is successful.

    Do you know why the authentication is successful?

    Regards
    mizutani

  • 0 in reply to user4852186
    TI__Guru 57115 points

    HI mizutani

    The way we verify the early bootloader image like tiboot3.bin, tispl or uboot,img is different from that of ftimage.

    Image like tispl make use of TIFS services to authenticate the image against the key flashed into the effuses. The public key for the fitimage verification is stored in the FDT. 

    To get the detail on fitimage verification, I would suggest you to go through below documentation.

    https://docs.u-boot.org/en/latest/usage/fit/signature.html#u-boot-fit-signature-verification

    Do let me know if you still have questions.

    Regards
    Diwakar