• State TI Thinks Resolved
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 55 subscribers
  • Views 164 views
  • Users 0 members are here
Support feedback
Options
Options
Related

LP-AM261: LP-AM261: Secure Boot

Payal Deshmukh
Prodigy 10 points

Part Number: LP-AM261

Hello everyone,

I am currently working on the AM261x-LP platform and trying to enable and understand the secure boot flow on my system.

I have been referring to the official documentation: https://software-dl.ti.com/mcu-plus-sdk/esd/AM261X/latest/exports/docs/api_guide_am261x/SECURE_BOOT.html

Here is what I have done so far:

  1. I built the SBL image using the following make command:
    make -s -C examples/drivers/boot/sbl_ospi_multicore_elf/am261x-lp/r5fss0-0_nortos/ti-arm-clang all DEVICE=am261x DEVICE_TYPE=HS
    This produced the file: sbl_ospi_multicore_elf.Release.hs.tiimage 

    1. Similarly, I built the application image using the command:
      make -s -C examples/drivers/gpio/gpio_led_blink/am261x-lp/r5fss0-0_freertos/ti-arm-clang all DEVICE=am261x DEVICE_TYPE=HS
      This produced the file: gpio_led_blink.mcelf.hs 
  2. I successfully flashed (non-secure images) sbl_ospi_multicore_elf.tiimage and gpio_led_blink.mcelf. Both the OSPI bootloader and the application boot and print output on the serial console correctly.
  3. However, when I flash (secure images) sbl_ospi_multicore_elf.Release.hs.tiimage and gpio_led_blink.mcelf.hs, I do not see any output on the serial console.
  4. I have not converted the device to HS-SE device yet. Do I need to convert the device to HS-SE?
  5. Is there any way to test the secure boot without converting the device to HS-SE? (Secure boot on HS-FS / GP device).
  6. How to convert device to HS-SE type? I have requested for AM261X-TIFS-SDK, but not received yet.
  7. Is there any way, to test secure boot without burning the keys?

In one post on TI forum, I read about the trial run mode. Does this also need the burning of the keys? How to execute trial mode?

I have read about enabling secure boot and understand that when building the SBL and application using the make commands, the generated binaries (with the extension .hs) are already signed. From what I gather, these images use a TI-dummy key for signing by default. Is that correct? 

Could anyone please help me understand the process to test and verify secure boot process?

Also I want to understand the following topics:

  1. What is the difference between device type HS-FS and GP?
  2. When I build the example code or SBL without setting DEVICE_TYPE=HS, gpio_led_blink.mcelf and sbl_ospi_multicore_elf.tiimage are generated. Are these images unsigned? and thse images are generated for which device type HS_FS or GP?
  3. How to identify the device type (GP/HS-FS/HS-SE) and the generated imgage is for which device type?

Thanks,

Payal

  • 0
    TI__Guru* 89131 points

    Hi Payal,

    Payal Deshmukh said:
    I have not converted the device to HS-SE device yet. Do I need to convert the device to HS-SE?

    Yes.

    Payal Deshmukh said:
    Is there any way to test the secure boot without converting the device to HS-SE? (Secure boot on HS-FS / GP device).

    Secure boot can only be tested on HSSE

    Payal Deshmukh said:
    How to convert device to HS-SE type? I have requested for AM261X-TIFS-SDK, but not received yet.

    Using OTP Keywriter firmware in the TIFS SDK path. May I know if an NDA is established with TI with your ORG to procure the same? If not, please contact your local field support for the same.

    Payal Deshmukh said:
    Is there any way, to test secure boot without burning the keys?

    No

    Payal Deshmukh said:
    n one post on TI forum, I read about the trial run mode. Does this also need the burning of the keys? How to execute trial mode?

    Sorry, Do you mean Dry-run mode of OTPKW? If yes, this is just to check the functioning of SBL OTP KW functionality without actually burning the keys. This will parse the certificate sent to HSM and show that the this process is successful so that you can go ahead and fuse the keys. This has nothing to do with Secure boot.

    Payal Deshmukh said:
    I have read about enabling secure boot and understand that when building the SBL and application using the make commands, the generated binaries (with the extension .hs) are already signed. From what I gather, these images use a TI-dummy key for signing by default. Is that correct? 

    Yes, before building the SBL you would have to build the TIFS-SDK as well to generate HS-SE HSMRT image, which will be loaded by SBL on HS-SE device. This will be signed by TI dummy keys, and used only if you have converted the device to HS-SE using OTP KW using same OOB dummy keys

    Payal Deshmukh said:
    Could anyone please help me understand the process to test and verify secure boot process?

    1. Convert the device to HS-SE using OTP KW firmware (Available in same path as TIFS-SDK), check readme of package for instruction. Use dummy keys if you are just testing the firmware

    2. After converting, build the updated HSMRT from the TIFS SDK package

    3. Build HS image of SBL and image as you have already done.

    4. flash the contents and boot (This is secure boot)

    Payal Deshmukh said:
    What is the difference between device type HS-FS and GP?

    TI do not ship out GP devices. You would be having an HSFS device at your end

    Payal Deshmukh said:
    When I build the example code or SBL without setting DEVICE_TYPE=HS, gpio_led_blink.mcelf and sbl_ospi_multicore_elf.tiimage are generated. Are these images unsigned? and thse images are generated for which device type HS_FS or GP?

    This will be signed with TI dummy keys for HS-SE device

    Payal Deshmukh said:
    How to identify the device type (GP/HS-FS/HS-SE) and the generated imgage is for which device type?

    Power up in UART boot mode and observe the hex value printed on the terminal. Use the below tool in SDK with that data to get the device state

    AM263Px MCU+ SDK: Booting Tools

    Thanks and Regards,

    Nikhil Dasan

  • 0 in reply to Nikhil Dasan
    Prodigy 10 points

    Hi Nikhil,

    I got the access to OTP keywriter and TIFS SDK, build the code.

    <MCU_PLUS_SDK_INSTALL_DIR>/source/security/sbl_keywriter/am263px/r5fss0-0_nortos/ti-arm-clang and flashed sbl_keywriter_am261x_r5fss0-0_nortos_ti-arm-clang.tiimage via tera Term. Below are the logs I see after flashing this image.

    Starting KeyWriter Bootloader ...
INFO: Bootloader_socLoadOTPHsmRtFw:67: Key Writer HSMRT Size in Bytes : 81364
INFO: Bootloader_socLoadOTPHsmRtFw:68: Key Writer hsm runtime firmware load complete
INFO: Bootloader_socLoadOTPHsmRtFw:69: Below Device DETECTED
Device Type : HSFS
SR version 1.0

 [HSM_CLIENT] New Client Registered with Client Id = 2
 [HSM CLIENT] OTP-KW 64bit version string = 0x0013306000b0001

 [HSM CLIENT] OTP-KW Information
[Soc Type]          = AM261X
[Device Type]       = HS-FS
[HSM Type]          = HSM_V1
[Bin Type]          = OTPKW
[OTP-KW Version]    = 11.0.1

#
# Validating certificate..
#

BMPK Key Type : RSA Key


SMPK Key Type : RSA Key


#
# Decrypting extensions..
#

 * MPK Options: 0x0

 * MEK Options: 0x0

 * MPK Opt P1 : 0x0

 * MPK Opt P2 : 0x0

 * MEK Opt    : 0x0

* SMPKH Part 1 BCH code: 0x20f65682


* SMPKH Part 2 BCH code: 0x000f704c


* SMPK Hash (part-1,2):

0xce0c44734447afec12ba0b2226c3bdbc15576d212323ece46a9c4ccd6a463e41

0x7086083fee572a09a9496dbed447a9f13f9cf535fad75b18e0ee095a4e783c62

* SMEK Hash: 0x716ded828b2731a19c961aa866ca07fcb99603d52ea1b3fa9d5b23c19e99c60a

0x2ca76a82e34fa0a12cfc4d7cc5352bb0ec74e313ddd42edfda52832055b662bf



* BMPKH Part 1 BCH code: 0x4006cd64


* BMPKH Part 2 BCH code: 0x806234dd


* BMPK Hash (part-1,2):

0xc090ae52abdb03fee89446518eb34f23c971fe29c0094e52d0a4f303fc8d7c75

0x6ae38cc1830a7aa8bd5abc2901d76bf7f7780544543f136eb6b67069af7d1bf1

* BMEK Hash: 0x83b1b25a53f4863a27d4e2ddc496771d31a3b131bc74b959eecc3475900ff19a

0xc82c062da18e8cb0b646219b379d987392b3df7919c666fd3fa14952552e699e



EXT OTP extension disabled

[uint32_t] MSV     : 0xF1E22D

[uint32_t] MSV_BCH : 0x11

* APP SWREV: 0x000000000000000000000001000000000000000000000001


* SBL SWREV: 0x0000000100000001


* HSM SWREV: 0x0000000100000001



[u32] key_cnt : 0x303


[u32] key_REV : 0x101

#
# Programming Keys..
#

MSV:
block: 1, row: 11 data: 0x0


MSV_BCH:
block: 1, row: 12 data: 0x0


Error detected: 13 bit(s) mismatch

Dry run mode: Skipping error correction

Final: 13 bit(s) failed to program in this row

Programmed 0/1 rows successfully

[HSM CLIENT] OTP-KW Error encountered in OTP Keywriter

[HSM CLIENT] OTP-KW debugResponse = 0x0070a023
[HSM CLIENT] OTP-KW Error phase = 0x3
[HSM CLIENT] OTP-KW Error module = 0x02
[HSM CLIENT] OTP-KW Error stage = 0x0a
[HSM CLIENT] OTP-KW Error customer key extension = 0x7

KPI_DATA: [BOOTLOADER_PROFILE] CPU Clock        : 500.000 MHz
KPI_DATA: [BOOTLOADER_PROFILE] Boot Media       : undefined
KPI_DATA: [BOOTLOADER_PROFILE] Boot Image Size  : 0 KB
KPI_DATA: [BOOTLOADER_PROFILE] Cores present    :
KPI_DATA: [BOOTLOADER PROFILE] System_init                      :        339us
KPI_DATA: [BOOTLOADER PROFILE] Drivers_open                     :         17us
KPI_DATA: [BOOTLOADER PROFILE] Board_driversOpen                :        180us
KPI_DATA: [BOOTLOADER PROFILE] LoadHsmKeyWriterRtFw             :      35548us
KPI_DATA: [BOOTLOADER PROFILE] Enable Vpp                       :      28494us
KPI_DATA: [BOOTLOADER PROFILE] LoadHsmCustomerKeyCertificate    :    1433670us
KPI_DATA: [BOOTLOADER PROFILE] KeyWriter SBL End                :     850707us
KPI_DATA: [BOOTLOADER_PROFILE] SBL Total Time Taken             :    2348959us

KeyWriter Bootloader Execution Complete...

    In these logs we can see some errors like 

    Error detected: 13 bit(s) mismatch

    Dry run mode: Skipping error correction

    [HSM CLIENT] OTP-KW Error phase = 0x3
    [HSM CLIENT] OTP-KW Error module = 0x02
    [HSM CLIENT] OTP-KW Error stage = 0x0a
    [HSM CLIENT] OTP-KW Error customer key extension = 0x7

    Can you help me understand what are these errors, and if SBL OTP KW functionality is working? 

    How to determine SBL OTP KW functionality is working?

    Thanks,

    Payal

  • 0 in reply to Payal Deshmukh
    TI__Guru* 89131 points

    Dry run mode: Skipping error correction

    This means you are running in Dry run mode. 

    This is to verify if the contents of the certificate is correctly parsed by HSM by seeing the prints.

    To do the actual conversion, as stated in the OTP KW Documentation, please change the mode to certHeader.reserved = KEYWRITER_MODE in the file ${SDK}\source\security\sbl_keywriter\am261x\r5fss0-0_nortos\main.c and rebuild the SBL and flash again. 

    Here you should see the success log after repearting the same procedure.

    Thanks and Regards,

    Nikhil Dasan

  • 0 in reply to Nikhil Dasan
    Prodigy 10 points

    Hi Nikhil,

    Till now I have understood for DRYRUN_MODE,

    1. Before loading the OTP keywriter image on the device, we need to generate x.509 Certificate with all the required fields (MSV, SMPK, SMEK, BMPK, BMEK, KEY_COUNT and KEY_REVISION).

    2. Then build and load the OTP kewiter image on the device.

    3. OTP keywriter in the DRYRUN_MODE will, Parse the certificate generated in first step and linked while building the OTP kewiter image , Decrypt certificate, Extract keys, Compute hashes, Prepare OTP programming, and Simulate OTP write.

    Is my understanding correct, am I missing any conceptual understanding?

    I have tested DRYRUN_MODE with both TI keys and custom keys.

    I have below queries:

    1. What is the role of HSMRT in DRYRUN_MODE?

    2. After changing the OTP keywriter  mode to the KEYWRITE_MODE, public keys will be burnt on the OTP. So only public keys will be burnt or any other data along with the keys will also be burnt or the generated certificate will be burnt?

    3. After the keys are burnt, when device boots / reset, who and how verifies the SBL and application images against the burnt keys, how this process takes place?

    4. 

    Nikhil Dasan said:
    Yes, before building the SBL you would have to build the TIFS-SDK as well to generate HS-SE HSMRT image, which will be loaded by SBL on HS-SE device. This will be signed by TI dummy keys, and used only if you have converted the device to HS-SE using OTP KW using same OOB dummy keys

    While using custom keys, does TIFS-SDK also needs to be signed with custom keys? What changes I will need to do in TIFS-SDK for HS-SE device with custom keys?

    5. What will be the role of HSMRT image, on HS-FS device with custom keys?

    6.  The custom keys are burnt on the device, the gets compromised or I want to change those burnt keys for some reason. Is there any provision to change the burnt keys?

    Thanks

    Payal

  • 0 in reply to Payal Deshmukh
    Prodigy 10 points

    Hello Team,

    Any update on the above queries?

  • 0 in reply to Payal Deshmukh
    TI__Guru* 89131 points
    Payal Deshmukh said:
    Is my understanding correct, am I missing any conceptual understanding?

    Correct

    Payal Deshmukh said:
    What is the role of HSMRT in DRYRUN_MODE?

    HSMRT will Parse the certificate generated in first step, Decrypt certificate, Extract keys, Compute hashes, Prepare OTP programming, and Simulate OTP write

    Payal Deshmukh said:
    After changing the OTP keywriter  mode to the KEYWRITE_MODE, public keys will be burnt on the OTP. So only public keys will be burnt or any other data along with the keys will also be burnt or the generated certificate will be burnt?

    All the field data printed in Dryrun mode will be efused. Please refer the Readme of OTP KW to understand what are the different fields available

     

    Payal Deshmukh said:
    After the keys are burnt, when device boots / reset, who and how verifies the SBL and application images against the burnt keys, how this process takes place?

    ROM verifies SBL and HSMRT verifies APP. Please refer the below.

    Secure Boot Flow in AM26x devices

    Payal Deshmukh said:
    While using custom keys, does TIFS-SDK also needs to be signed with custom keys? What changes I will need to do in TIFS-SDK for HS-SE device with custom keys?

    If using dummy keys, then build the TIFS Firmware again and it will fetch the keys from the default TIFS SDK location. Way to build TIFS firmware mentioned in the Readme of the TIFS SDK.

    If using your own keys, then replace the path of the keys in the SDK devconfig.mak file so that during the build, these keys are fetched.

    Payal Deshmukh said:
    What will be the role of HSMRT image, on HS-FS device with custom keys?

    HSFS do not have custom keys. It only has TI internal MPK and MEK, which is not accessible by customers. So HSMRT has very limited functionalities in HS-FS as mentioned in the below table

    AM261x MCU+ SDK: HSM client

    Payal Deshmukh said:
    The custom keys are burnt on the device, the gets compromised or I want to change those burnt keys for some reason. Is there any provision to change the burnt keys?

    Burning keys to Efuse is a One time activity. So we have 2 pairs of keys to be efused i.e. Secondary (SMPK and SMEK) and Back-up keys (BMPK and BMEK) in the OTP.

    So if SMPK/SMEK is compromised then you can switch to BMPK/BMEK (Again it is one-time switch)

    Thanks and Regards,

    Nikhil Dasan

  • 0 in reply to Nikhil Dasan
    Prodigy 10 points

    Hi Nikhil

    Thanks for your help till now. I have one more query regarding the use of Back-up keys. 

    Nikhil Dasan said:
    Burning keys to Efuse is a One time activity. So we have 2 pairs of keys to be efused i.e. Secondary (SMPK and SMEK) and Back-up keys (BMPK and BMEK) in the OTP.

    I understand when I want to use Back-up keys as a root of trust, I will have to change the key revision. My query is how to change the key revision? Do I need to use keywriter firmware again to update key revision?

    Thanks,

    Payal

  • 0 in reply to Payal Deshmukh
    Prodigy 10 points

    Hi Nikhil,

    One more query on the key updation.

    If both of the primary and back-up keys get compromised and the device is brought back to the factory. Will we be able to fully clean the privious keys and write new keys using the keywriter?

    Thanks,

    Payal

  • 0 in reply to Payal Deshmukh
    TI__Guru* 89131 points
    Payal Deshmukh said:
    I understand when I want to use Back-up keys as a root of trust, I will have to change the key revision. My query is how to change the key revision? Do I need to use keywriter firmware again to update key revision?

    No, You have to do this using the TIFS SDK. 

    We have an example for Root of trust Switching in the TIFS SDK. Please refer the same.

    {TIFS_SDK)C:\ti\tifs_am263x_11_01_01_00\examples\rot_switching_service

    Payal Deshmukh said:
    If both of the primary and back-up keys get compromised and the device is brought back to the factory. Will we be able to fully clean the privious keys and write new keys using the keywriter?

    No, this is not possible. Key-writing process is a one-time activity in the lifetime of the device.

    Thanks and Regards,

    Nikhil Dasan