AM2434: Enable encryption on hf_fs file from CCS

Hello Prashant, is possible to describe process of creating hsse file for am2434 device? 

In documentation is:
If the secure device received is an HS-FS subtype, it needs to be converted to an HS-SE variant with the customer keys burnt into the device eFUSEs.
If we will try to use generic keys from TI to understand process, what is necessary to edit?

In our current devconfig/devconfig.mak file is encryption of application disabled, we will rewrite to enable encryption:

# Encryption option for application (yes/no)
ENC_ENABLED?=yes

Are there any other steps?



Actually we have encrypted second bootloader:

# Encryption option for SBL (yes/no)
ENC_SBL_ENABLED?=yes

What are differences between encryption of SBL or application? Isn't application part of SBL?


Thank you.

Hello,

As mentioned in the previously shared guide, if the DEVICE_TYPE is set to HS then the images are built for HSSE device type. If the ENC_SBL_ENABLED and ENC_ENABLED are set to "yes" then the images are encrypted as well.

The SBL is a bootloader that boots an application and so both are different.

Regards,

Prashant

Hello Prashant,

thank you for explanation, 

We will generate our own sign .pem and encrypt keys and enter own paths to keys in devconfig.mak, and after that we will also rewrite these lines:

# Device type (HS/GP)
DEVICE_TYPE?=HS

# Encryption option for application (yes/no)
ENC_ENABLED?=yes

are these steps correct?


Also our current apiimage.hs_fs file have about 580KB and we are worried about limitation which is described in document you shared: Decryption of application image size greater than 256kb is not possible in SBL OSPI. We hope that encrypted file will be smaller, but what can we do if our apiimahe file will be greater than 256kb, and we need to encrypt and secure our code?

Thank you, Matej.

Hello,

Matej Liska said:

are these steps correct?

Those steps are correct.

Matej Liska said:

Decryption of application image size greater than 256kb is not possible in SBL OSPI.

The limitation comes from the fact that the encrypted image is loaded into MSRAM for decryption and the free space in the MSRAM is limited to 256KB only according to the following layout:

https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/10_01_00_32/exports/docs/api_guide_am243x/MEMORY_MAP.html

If you have DDR available then you could modify the SBL OSPI source code to use DDR for decryption.

Regards,

Prashant

Hello Prashant,

currently we don't have DDR in our design, and from cybersecurity view, it is not possible to use external part for decryption.

Is there any possibilities to encrypt only our intellectual property on one core and other cores use only signed?

Currently we are using 4cores of AM2434 - M4F, R5 _0_0, R5 _0_1, R5 _1_0, and we will need to encrypt only one of R5 cores.

Thank You.

Hi Matej,

Matej Liska said:

Is there any possibilities to encrypt only our intellectual property on one core and other cores use only signed?

It is possible by creating one appimage for the R5_0_0 core and another appimage for all the other cores.

Please have a look at the SBL_OSPI_MULTI_PARTITION bootloader which expects separate appimages for different cores:

https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/10_01_00_32/exports/docs/api_guide_am243x/EXAMPLES_DRIVERS_SBL_OSPI_MULTI_PARTITION.html

Regards,

Prashant

Hello Prashant,

thank you for explanation of this, we are currently have our system project with 4cores, and we want to encrypt only one, how could we make it in easiest way? How could we modify devconfig.mak file, to ENC_ENABLED?=yes for only one core of system project?

Thank you.

Hi Matej,

Matej Liska said:

How could we modify devconfig.mak file, to ENC_ENABLED?=yes for only one core of system project?

That is not possible.

Prashant Shivhare said:

It is possible by creating one appimage for the R5_0_0 core and another appimage for all the other cores.

This is the only solution to your use case.

BR, Prashant

Hello Prashant,
To clarify our understanding correctly, we will need to create two separate projects for each core with separate apiimages?
Specifically, for one of the cores, (such as R5_0_0), we will need to modify the devconfig.mak file to set ENC_ENABLED?=yes.
Following this, we will flash the resulting multicore apiimages into the flash memory.

However, I have a couple of questions regarding this process:
In the MCU_PLUS_SDK, I noticed there is only one devconfig.mak file available. How should we modify this file to ensure that we only enable encryption for one specific type of core?

Regarding firmware upgrades, if we are saving new API images into flash, how will this process work when managing two separate cores? Will each core independently handle its own upgrade, or is there a synchronization mechanism in place to ensure both cores are kept in sync during the upgrade process?

I appreciate your insights on these matters.

Thank you, BR,
Matej.

Hello,

I would recommend you to once go through the SBL_OSPI_MULTI_PARTITION botloader. It expects separate appimages for different cores. This way you can encrypt the appimage for the required core by modifying its makefile like so:

diff --git a/examples/hello_world/am243x-evm/r5fss0-0_nortos/ti-arm-clang/makefile b/examples/hello_world/am243x-evm/r5fss0-0_nortos/ti-arm-clang/makefile
index 15d269dd..df5067a0 100644
--- a/examples/hello_world/am243x-evm/r5fss0-0_nortos/ti-arm-clang/makefile
+++ b/examples/hello_world/am243x-evm/r5fss0-0_nortos/ti-arm-clang/makefile
@@ -2,6 +2,7 @@
 export MCU_PLUS_SDK_PATH?=$(abspath ../../../../..)
 include $(MCU_PLUS_SDK_PATH)/imports.mak
 include $(MCU_PLUS_SDK_PATH)/devconfig/devconfig.mak
+ENC_ENABLED=yes
 
 CG_TOOL_ROOT=$(CGT_TI_ARM_CLANG_PATH)
 

As for the firmware update, it's just flashing to the media. The core handling the firmware upgrade can receive all the appimages and flash them to their respective offsets.

Regards,

Prashant

Hello Prashant,
Thank you for your previous guidance regarding the SBL_OSPI_MULTI_PARTITION bootloader.
I would like to request further clarification on a few specific points to ensure a smooth integration process.

Makefile Identification: You mentioned modifying the makefile for encrypting the app image for the required core. Could you please clarify which specific makefile we need to modify? Is it the makefile associated with each core, or is there a centralized makefile in the boot folder?

System Folder Usage: Do we need to use the system folder in our implementation? If so, how should we structure it within the context of the bootloader?

Inter-Core Communication: Will there still be communication capabilities between cores in this setup? If so, could you provide guidance on how to achieve this without the system folder?

Makefile Generation: Since makefiles for the cores are auto-generated, how should this impact our modifications? Should we incorporate any specific directives to ensure our changes persist after regeneration?

Step-by-Step Guidance: Lastly, could you provide a detailed step-by-step solution or guidelines for implementing these changes? This would greatly assist us in aligning with best practices.

I appreciate your support and guidance on these matters, and look forward to your prompt response.

BR, Matej.

Hello,

I wanted to follow up on this.

I understand that you may be busy, but any updates or information you could provide would be greatly appreciated.