• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 33 subscribers
  • Views 301 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.

AM263P4: Secure Boot Flow issues with the SBL and HSM programs of AM263P4

mingzhe dai
Prodigy 180 points

Part Number: AM263P4
Other Parts Discussed in Thread: SYSCONFIG, AM2634

image.png

I have roughly described the complete secure boot flow of the AM263P4 using the flowchart above:

  1. Power on

  2. R5 RBL and HSM RBL run

  3. R5 SBL loads the SBL from external flash into L2 (0x70002000) via boot mode

  4. The HSM RBL uses the SMPK and SMEK injected by Keywriter to verify the signature and decrypt the SBL loaded into L2. If the verification passes, it first copies the SBL's IVT and Initialization Code to TCMA (0x20000), then eclipses (masks) the R5 RBL at ROM address 0x0, and remaps the SBL's IVT and Initialization Code to address 0x0 (this address then effectively becomes a RAM address). The remaining SBL program continues to run at 0x70002000.image.png

  5. After the SBL runs successfully, the SBL reads the HSM firmware from a specified location in flash and loads it into a designated location in L2 RAM (configurable in SysConfig). The SBL calls the Hsmclient_loadHSMRtFirmware function to load the HSM firmware. At this point, the HSM RBL uses the SMPK and SMEK injected by Keywriter to verify and decrypt the HSM firmware loaded into L2. If verification passes, the HSM RBL moves the HSM program to the HSM core's RAM region (memory view / virtual address 0x20000-0x60000). It then eclipses (masks) the HSM RBL in ROM (0x0-0x40000) and remaps the HSM program to the virtual address region 0x0-0x40000 (which now effectively becomes RAM), and then runs it, ensuring that the HSM program starts executing from RAM address 0x0.image.png

Question :

  1. Is the above flow correct? If there are any issues, please specify them .In this flow, are the SBL and HSM firmware first loaded into L2 RAM, then verified, and finally remapped to the specified locations? Or are they first loaded into L2 RAM, then remapped to the specified locations, and then verified?

  2. Is the above flow the same regardless of whether the SBL and HSM are separated or not?

 
  • 0
    TI__Guru* 90421 points

    Hi,

    mingzhe dai said:
    Is the above flow correct? If there are any issues, please specify them .In this flow, are the SBL and HSM firmware first loaded into L2 RAM, then verified, and finally remapped to the specified locations? Or are they first loaded into L2 RAM, then remapped to the specified locations, and then verified?

    Yes, this flow is correct, but a small updation.

    There are 2 ways.

    1. As you mentioned RBL loads SBL and then SBL loads HSMRT from flash to ram

    2. RBL loads combined (SBL + HSMRT) to RAM. Here, the SBL binary consists of HSMRT firmware in it,  so RBL loads one binary.

    ROM first copies the certificate to RAM and then HSM authenticates the same.

    mingzhe dai said:
    Is the above flow the same regardless of whether the SBL and HSM are separated or not?

    SBL and HSM are always separated, i.e. RBL loads SBL (or SBL and HSM), then SBL is follows the whole above process, then SBL lets HSM ROM know about HSM (if not already in RAM, it brings the same to RAM), and HSM ROM follows the above for HSMRT.

    There is only one process.

    Thanks and Regards,

    Nikhil Dasan

  • 0 in reply to Nikhil Dasan
    Prodigy 180 points

    Thank you very much for your reply. I have a few more questions:

    Question 1:
    So do you mean that the RBL always loads the SBL (either standalone SBL or SBL+HSMRT) from Flash into RAM? After the verification passes:
    ① For standalone SBL, the SBL loads the HSMRT from the specified location into RAM and verifies it;
    ② For SBL+HSMRT, the SBL loads the HSMRT (which is already included in the SBL binary) into RAM and verifies it (in fact, both SBL and HSMRT have already been loaded into RAM in the previous step).
    Essentially, there is no difference in the flow—one is a separate load, the other is a combined load. Is that correct?

    Question 2:
    Is the slower Secure Boot speed of the combined SBL+HSMRT compared to the separated SBL and HSMRT (fastboot) simply due to the larger size of the combined image (approx. 300KB) versus the total size of the separated images (60KB + 80KB)?

    Question 3:
    Will the L2 RAM space occupied by the HSMRT during the early verification phase be automatically released after the verification passes and the HSMRT is written to the HSM core's dedicated RAM?

  • 0 in reply to mingzhe dai
    TI__Guru* 90421 points
    mingzhe dai said:
    So do you mean that the RBL always loads the SBL (either standalone SBL or SBL+HSMRT) from Flash into RAM?

    Yes

    mingzhe dai said:
    ① For standalone SBL, the SBL loads the HSMRT from the specified location into RAM and verifies it;
    ② For SBL+HSMRT, the SBL loads the HSMRT (which is already included in the SBL binary) into RAM and verifies it (in fact, both SBL and HSMRT have already been loaded into RAM in the previous step).
    Essentially, there is no difference in the flow—one is a separate load, the other is a combined load. Is that correct?

    Correct

    mingzhe dai said:
    Is the slower Secure Boot speed of the combined SBL+HSMRT compared to the separated SBL and HSMRT (fastboot) simply due to the larger size of the combined image (approx. 300KB) versus the total size of the separated images (60KB + 80KB)?

    It depends on where is your endpoint of secure boot. If you measurement of secure boot is only loading SBL, then first one (standalone SBL) is faster, because of the smaller size. 

    If you measurement is from application is loaded, then, in both cases, it is almost the same, as same operation happen for SBL and HSMRT

    mingzhe dai said:
    Will the L2 RAM space occupied by the HSMRT during the early verification phase be automatically released after the verification passes and the HSMRT is written to the HSM core's dedicated RAM?

    It can be overwritten once the HSMRT is loaded, as the HSMRT will be copied to HSM RAM upon verification. Then the area of OCRAM keep HSMRT is free to use 

    Thanks and Regards,

    Nikhil Dasan

  • 0 in reply to Nikhil Dasan
    Prodigy 180 points

    Regarding the boot time comparison:
    "Our time reference starts from power-on and ends at the jump to the application (BOOT). On the AM2634, the boot time for the non-separated SBL (260KB) is about 75ms, while that for the separated SBL+HSM (60KB+80KB) is about 50ms. I understand that the additional time is likely caused by the larger image size, which leads to longer hash calculation for signature verification or longer decryption time. Is that correct?"

    Regarding the size discrepancy between non-separated and separated images:
    "We have another question: why is there such a large size difference between the non-separated and separated images? We compared the fastboot SBL (separated) and the normal SBL (non-separated) and found that the functions called are identical. I think the only difference is whether the HSM firmware is included or not. In the non-separated SBL, the HSM firmware is included as a header file. I would expect this data to be roughly the same size as the standalone HSM firmware, but in reality it seems much larger. Why is that?"

  • 0 in reply to mingzhe dai
    TI__Guru* 90421 points
    mingzhe dai said:
    Is that correct?"

    Yes, that is correct. Hash is performed on a larger SBL compared to small SBL in later case.

    mingzhe dai said:
    would expect this data to be roughly the same size as the standalone HSM firmware, but in reality it seems much larger. Why is that?"

    Apart from hsmrt, fastboot also has below, causing more size reduction.

    • No Profiling infrastructure (AddProfilePoint)
    • Lesser UART logging (DebugP_log + printf machinery)
    • No RPRC image loader (Bootloader_rprcImageLoad) vs. only ELF-only loader (Bootloader_parseAndLoadMultiCoreELF)

    Thanks and Regards,

    Nikhil Dasan

  • 0 in reply to Nikhil Dasan
    Prodigy 180 points

    Regarding the content discussed above:

    1. What is the default signature verification algorithm for SBL and HSMRT? Does it only support RSA4096_PSS + SHA512?
    2. Is the default decryption algorithm for SBL and HSMRT limited to AES256_CBC only?

    Additionally, what is the difference between the Keyring mentioned below and the signature verification (secure boot) described above? What are the specific use cases for Keyring?

  • 0 in reply to mingzhe dai
    TI__Guru* 90421 points

    Hi,

    mingzhe dai said:
    1. What is the default signature verification algorithm for SBL and HSMRT? Does it only support RSA4096_PSS + SHA512?
    2. Is the default decryption algorithm for SBL and HSMRT limited to AES256_CBC only?

    Yes

    Please refer to the TIFS product brief on the same 

    AM26xx Family TIFS-SDK Product Brief

    mingzhe dai said:
    Additionally, what is the difference between the Keyring mentioned below and the signature verification (secure boot) described above? What are the specific use cases for Keyring?

    Keyring is the process of getting the Auxiliary keys for authentication or checking the integrity at the application stage (i.e. in TIFS HSMRT).

    So if user do not want to use Root of Trust keys for their application, they can use the auxillary keys from keyring instead.

    Thanks and Regards,

    Nikhil Dasan