LP-MSPM0G3519: How to Load Keys into Keystore (CSC + .secret vs other provisioning methods)

kasirajan chellaiah said:

(This is my understanding please correct it If I am wrong) 

Correct.

kasirajan chellaiah said:

Is hardcoding keys into .secret flash and then writing them into Keystore via CSC the only supported option, or are there alternatives? 

KETSTORE is some kind of peripherals, like normal UART/ADC, need to config after device reset.

So the only way is config it after reset during boot phase(CSC)

kasirajan chellaiah said:

For production, what is the recommended secure provisioning flow to ensure each device has unique keys without exposing plaintext keys in source code?

1. SWD disable or enable with password.

2. BSL read memory function is disable by default, also customer can directly disable all BSL function.

kasirajan chellaiah said:

My requirement is that I would like to store the key in flash in encrypted format, and then use a flash read API to read it and load it into the Keystore. Is this flow feasible/supported, or must the Keystore only accept plaintext keys at load time?

If you save your key in encrypted format, you need to decrypt it in ReadKey API, then write the plaintest key to KeyStore.

kasirajan chellaiah said:

On MSPM0G3507, I see that only the basic AES accelerator is available and there is no Keystore controller. What is TI’s recommended secure provisioning method in this case, since keys can only be loaded via software into AES registers?

In G3507, we can not protect AES or other security information read by app code.

Like this one: 4.4.3 Read-Execute Protection, you can not disable app code to read this region (Read API function and Key are here).

Also, there is no InitDone bit like G3519 does in G3507.

So, most of security function should be designed by customer, since there is limited security feature from G3507's hardware.

Hello Helic Chi,

Thanks for your detailed reply. I now understand that CSC runs after reset and its job is to:

• Read the key material from the .secret flash region

• Call DL_KEYSTORECTL_writeKey() to push those keys into the Keystore slots

I have a couple of follow-up clarifications:

1. Uniflash provisioning:
   Is it possible to program the .secret region directly using Uniflash with a separate hex/bin file (for example, containing up to four keys)? If so, do you have any reference or example flow for generating and flashing such a .secret file?

2. Encrypted key storage:
   You mentioned that if the key is saved in encrypted format, it must be decrypted in the ReadKey API before being written into the Keystore. Could you confirm if the TI SDK provides built-in support for decrypting keys inside the ReadKey API, or would we need to implement the decryption step ourselves before calling DL_KEYSTORECTL_writeKey()?

Thanks again for your guidance.

Best regards,
Kasirajan

kasirajan chellaiah said:

Uniflash provisioning:
Is it possible to program the .secret region directly using Uniflash with a separate hex/bin file (for example, containing up to four keys)? If so, do you have any reference or example flow for generating and flashing such a .secret file?

Possible, enable Uniflash's erase necessary memory region.

A key in your firmware can get access by a header address and it's length.

You can put the key directly with plaintext into the start address in .secret section.

Key can program into M0 with CSC code/firmware.

kasirajan chellaiah said:

would we need to implement the decryption step ourselves before calling DL_KEYSTORECTL_writeKey()?

You need to decrypt it, because you control your crypton algorithm.

Just makesure that the key written into KEYSTORE must be a plain text, MSPM0 KEYSTORE doesn't care about other parts.

Hi Helic Chi

Thanks for your earlier clarification. I want to confirm one more point regarding Confidentiality and Integrity of keys when provisioning with Uniflash.

From your response, I understand:

• The .secret region can be programmed via Uniflash with plaintext keys.

• At boot, CSC can call DL_KEYSTORECTL_writeKey() to move these keys into the Keystore.

• If we want to store keys in encrypted form in flash, we (the customer) must implement decryption in CSC before calling DL_KEYSTORECTL_writeKey(), since the Keystore only accepts plaintext.

My main concern is around Confidentiality and Integrity:

1. If we store keys in plaintext in flash (even in .secret), is disabling SWD/JTAG and enabling flash protections enough for confidentiality in production?

2. If we store keys in encrypted form in flash and decrypt inside CSC:

   • Do we need to implement both the decryption algorithm and integrity verification ourselves ? please provide some suggestion here 

   • Or does TI provide any built-in support to help ensure both confidentiality and integrity of the key material before loading to Keystore?

I want to confirm the recommended secure production flow:

• Plaintext keys in .secret + JTAG disabled?

• Or encrypted keys in .secret + customer-managed decrypt+verify in CSC?

This will help us decide the right balance between security and implementation effort.

Thanks,
Kasirajan

kasirajan chellaiah said:

If we store keys in plaintext in flash (even in .secret), is disabling SWD/JTAG and enabling flash protections enough for confidentiality in production?

Disable SWD, and BSL reading function is disabled by default.

There is no other way to access the device from external pin.

kasirajan chellaiah said:

Do we need to implement both the decryption algorithm and integrity verification ourselves ? please provide some suggestion here 

Yes, you need.

You can try to use AES module in M0 to decryption. Also, I think the decryption key of the encrypted key is also plaintext saved in Flash.

The encryption algorithm is depending on your own requirement.

kasirajan chellaiah said:

Or does TI provide any built-in support to help ensure both confidentiality and integrity of the key material before loading to Keystore?

The entire CSC code should be considerate as trust area.

Because by enabling nonmain Flash permission config and disable SWD, CSC area is protected.

And since M0 can only be start from address 0x0 and CSC controls this part.

This is why CSC and your load key function should be trusted and secured.

And the CSC code provide by MSPM0 SDK is "As is", we offer you a example code to show you how to handle this kind of things.

kasirajan chellaiah said:

Plaintext keys in .secret + JTAG disabled?

Actually M0 uses SWD interface.

Yes, Disable SWD, and put key into secret section.

Also you can choose disable BSL(bootloader used for firmware program).

And set static write protection in nonmain.

Also set Flash read/exe permission for CSC code in CSC.

kasirajan chellaiah said:

Or encrypted keys in .secret + customer-managed decrypt+verify in CSC?

This is a bit safer.

Two methods are both ok, because of above description, due to the access limitation, we can assume that CSC is secure because any illegal access will be blocked.