• State Resolved
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 128 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM2434: FW update image authentication

Zoltan Nagy
Prodigy 10 points

Part Number: AM2434

Hi, 

We would like to perform digital signature verification of the signed fw image created by the appimage_x509_cert_gen.py tool already at the stage, when the device receives the image through a REST-API interface, that the device can easily inform the user about the correctness of the provided image. 

We have already made some trials with TISCI_MSG_PROC_AUTH_BOOT, but we do not really know, whether this service is capable of authenticating the image only, or it is always connected to the following booting process. Since this sciclient service does not reveal the reason why it does not set the ACK, it is hard to debug :)  We always used the ti-sitara-support-package\utils\development_keys\rom_degenerateKey.pem for our HS-FS device.

We already tried the TISCI_MSG_MCELF_PROC_AUTH_BOOT_INIT service as well, which is probably not connected to booting, but again ACK was never set. Is this functionality even supported by AM2434 HS-FS? In the docs, there is an attention: TISCI_MSG_MCELF_PROC_AUTH_BOOT_INIT API is currently supported by am275x. Exclusively? Do these services need preceding processor request and control?

The documentation suggests to enable logging (tracing) in system fw to get more info about rejection. Can you please help us how to achieve that?

With AM2434 HS-FS, is it possible to authenticate any binary (and not only the secure boot appimage) against the rom_degenerateKey (or public key hash saved in eFuse in case of HS-SE device)?

Thanks.

  • 0
    TI__Guru* 83911 points

    Hello,

    It is possible to authenticate any generic image signed by the RoT keys using the TISCI_MSG_PROC_AUTH_BOOT message. In fact, the SBL uses this API for authentication only of the application image. Once the authentication is successful, the SBL itself parses and loads the application image.

    If you are getting the failure, please share the relevant code snapshots and logs.

    Thanks!

  • 0
    Prodigy 10 points

    Hi,

    Thanks for your feedback. To verify the image I use the folowing code in the running fw application (not SBL):

    void verify(uint8_t* appImageBuffer)
    {
        struct tisci_msg_proc_auth_boot_req  req {};
        struct tisci_msg_proc_auth_boot_resp response {};

        req.certificate_address_hi = 0U;
        req.certificate_address_lo = (uint32_t) appImageBuffer;

        const Sciclient_ReqPrm_t reqPrm =
        {
            TISCI_MSG_PROC_AUTH_BOOT,
            TISCI_MSG_FLAG_AOP,
            (const uint8_t*) &req,
            sizeof(req),
            SystemP_WAIT_FOREVER
        };

        Sciclient_RespPrm_t respPrm =
        {
            0,
            (uint8_t*) &response,
            sizeof(response)
        };

        int32_t retVal = Sciclient_service(&reqPrm, &respPrm);

        platformLog("[WRN] SciClient status: %d %d\r\n", retVal, respPrm.flags);
    }
    which is probably the same as int32_t Bootloader_socAuthImage(uint32_t certLoadAddr) in bootloader_soc.c, just a compacted version.

    After calling the function retVal equals 0, which means SUCCESS, but respPrm.flags is also 0, but should be ACK (2).

    appImageBuffer contains first the signature and then the image file - created by calling appimage_x509_cert_gen.py \
    --bin test.appimage \
    --authtype 1 \
    --key ${KEY} \
    --output test.signed.appimage

    where KEY is the ti-sitara-support-package/utils/development_keys/rom_degenerateKey.pem, but also tried ti-sitara-support-package/ti-sdk/ind_comms_sdk_am243x/mcu_plus_sdk/source/security/security_common/tools/boot/signing/rom_degenerateKey.pem.

    Thanks for your help.


  • +1 in reply to Zoltan Nagy
    TI__Guru* 83911 points

    Hello,

    For calling the PROC_AUTH_BOOT from the application, you would need to apply the following patch

    diff --git a/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c b/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c
index eca61e919dc..78d13db2455 100644
--- a/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c
+++ b/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c
@@ -979,7 +979,7 @@ int32_t Bootloader_socCpuResetReleaseSelf(void)
         }
         if(status==SystemP_SUCCESS)
         {
-            status = Bootloader_socSecHandover();
+            // status = Bootloader_socSecHandover();
         }
         if(status==SystemP_SUCCESS)
         {

    Zoltan Nagy said:
    where KEY is the ti-sitara-support-package/utils/development_keys/rom_degenerateKey.pem, but also tried ti-sitara-support-package/ti-sdk/ind_comms_sdk_am243x/mcu_plus_sdk/source/security/security_common/tools/boot/signing/rom_degenerateKey.pem.

    And the key you would need to use is "app_degenerateKey.pem" (or any random valid RSA 4K key) for the HSFS device while it must be the active RoT key for the HSSE devices.

  • 0 in reply to Prashant Shivhare
    Prodigy 10 points

    Hi Prashant,

    Thanks for the explanation regarding the usage of app_degenerateKey or any other RSA 4K key in case of HS-FS. I tried to use this key (and also a newly generated one) to certify the binary, and applied also the recommended patch, but unfortunately, without success. In our app, when we want to verify the integrity of the provided binary (immediately upon reception of the file), we do not use the Bootloader_socCpuResetReleaseSelf(void) method or any other bootloader-related one, so probably commenting out the call of Bootloader_socSecHandover() has no effect at all.
    What we use is the direct call to scliclient_service with the message type of TISCI_MSG_PROC_AUTH_BOOT. What is your advice, how could we know what is the reason behind rejection? Thx.

  • 0 in reply to Zoltan Nagy
    TI__Guru* 83911 points
    Zoltan Nagy said:
    so probably commenting out the call of Bootloader_socSecHandover() has no effect at all.

    Please keep the previous patch as it is required to avail the security services, like PROC_AUTH_BOOT, from the SYSFW.

    Could you please try authenticating the following signed binary

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/tmp_5F00_signed.bin

    It is created with the following commands

    ❯ dd if=/dev/urandom of=tmp.bin count=64 bs=1K
64+0 records in
64+0 records out
65536 bytes (66 kB, 64 KiB) copied, 0.000256765 s, 255 MB/s
❯ python3 source/security/security_common/tools/boot/signing/appimage_x509_cert_gen.py --bin tmp.bin --authtype 1 --key source/security/security_common/tools/boot/signing/app_degenerateKey.pem --output tmp_signed.bin
Generating certificate for tmp.bin ...

    This will help confirm if the issue is in your signed binary or the code you have to authenticate the image.

  • 0 in reply to Prashant Shivhare
    Prodigy 10 points

    Thanks for the signed binary. I followed my usual path - converted it to c-style array by ind_comms_sdk_am243x/mcu_plus_sdk/tools/bin2c/bin2c.py, and performed verification - again without success. But now, as you mention that the patch is necesssary, should it be incorporated into our bootloader?

  • 0 in reply to Zoltan Nagy
    TI__Guru* 83911 points
    Zoltan Nagy said:
    mention that the patch is necesssary, should it be incorporated into our bootloader?

    Yes, the patch is necessary and would need to be incorporated into the bootloader driver.

  • 0 in reply to Prashant Shivhare
    Prodigy 10 points

    Hi Prashant,

    Yes, it seems that commenting Bootloader_socSecHandover() out from the bootloader code solves the issue.

    I also noticed that this TISCI authentication check does not work when the image is in DDR memory allocated from the heap using new. Is there any restriction on this pointer? Thx.

  • +1 in reply to Zoltan Nagy
    TI__Guru* 83911 points
    Zoltan Nagy said:
    I also noticed that this TISCI authentication check does not work when the image is in DDR memory allocated from the heap using new. Is there any restriction on this pointer? Thx.

    There is no restriction. The issue could be because of the cache. You might have to do the cache writeback and invalidation to make sure the DDR physical memory has the full image for the SYSFW to authenticate it.

  • 0 in reply to Prashant Shivhare
    Prodigy 10 points

    Thank you, all issues solved :)