Test summary on i.MX93 HSM keystore

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Test summary on i.MX93 HSM keystore

100% helpful (1/1)

Test summary on i.MX93 HSM keystore

Device: i.MX93 A1.

ELE FW version: 0.0.10

Some new test scripts are added to secure enclave library, please refer to attached files.

Please note: the scripts attached are for internal test/debug purpose only. The summary is from our test results and understanding, it's preliminary and may have changes later. 


1. All current and all GA Sentinel FWs do not use lifecycle for key derivation of HSM keystore.

Keystore created in OEM_OPEN lifecycle can be directly used in OEM_CLOSED lifecycle. 

A-> Different from previous SECO devices

2. Key has lifecycle attribute. This attribute defines in which device lifecycle the key is usable.

This attribute is set at key creation operation (generate key, import key, key exchange …). Before executing a key depending cryptographic or data storage (export option) operation the key lifecycle is compared with the current device lifecycle. Operation is executed only if the key lifecycle includes the current device lifecycle.

When mentioned in the API command message description, the key lifecycle could be set to the current device lifecycle if the value is set to 0x0.

Lifecycle values are encoded as bitfield. Multiple values could be set. The key could be used in several lifecycles.



Tested cases:



The key lifecycle attribute is verified during the key usage, not when the key is created.

If the key operation doesn’t match device lifecycle, it will report 0xe29 - The key is not usable in the current lifecycle.

 Please see attached hsm_generate_key.c / hsm_generate_key_signature.c  for reference.


3. SYNC operation and MC increase are separate flag.

The previous STRICT operation is used to store persistent key, during which the monotonic counter will increase if the device is closed.

For ELE device, two flags are used: SYNC flag and MC flag.

The ELE SYNC pushes persistent key(s) in the NVM. Without executing this operation, even if the key attribute is set as persistent at the key creation the key will not be stored in the NVM. This operation is set through a flag in key management operations arguments. SYNC is applicable only for persistent key/permanent key.

MC flag is new on ELE device. When used in conjunction with SYNC, the request is completed only when the monotonic counter has been updated.

MC flag can be used both in OPEN and CLOSED lifecycle and increase the monotonic counter value. -> different from previous SECO device.

Note: MC flag is not defined in 0.0.10 secure enclave library, but user can test it by directly setting the corresponding bit of the flag.


4. If the generated key store is deleted accidently and the monotonic counter is not 0, reprovisioning function is needed.

 This is applied to both OPEN and CLOSED device.

We cannot directly create a keystore again. Reprovisioning method is not supported yet.


5. One keystore can store 100 key groups at most.

100 groups are available per key store. It must be a value in the range [0; 99].

The key group ID should be 0~99, or it will report 0x429- MU sanity check failed / Invalid parameters.

To push persistent keys in the NVM, a flag (SYNC) needs to be set during key management operations (generate, import, manage, …). Pushing a key to the NVM will also push all the key group data.

When in use, a key group is loaded from the NVM to the internal secure RAM. The number of key group present is limited (depends on the device). A key group present in internal memory and not used, can be swapped out and replaced by a new key group containing the key to be used when there is no more free space.

Note that only key 2 groups per key store can be stored in the internal secure RAM.

Note that volatile keys cannot be in the same key group than persistent keys.


One assumption based on tests: It looks that each key group has its own SW counter, which may record update time of this key group.

This is the test on i.MX93: If we delete the key group #2 file 0000abcd00020004 only from NVM manually, then we cannot create key of group #2 again, but we can create key of group #1.

The process might be: Try to create key in group #2 -> checked the counter value is not 0 -> try to import the chunk from NVM -> fail because the chunk is deleted.

Each key group has its own counter, so key group #1 is not affected.



6. Key size in one keystore

One key group can store 16 ECC(p256) keys, or 1 RSA 2k key, or 1 RSA 4k key.

Size of key group on i.MX93 = 8448 bits (size defined to allow 4k modulus+ 4k private exponent + header). Storage file in NVM will have additional overhead, the 8448 size is purely related to key data storage.

For ECC keys, only private keys are stored (public key can be derived from private key), so P256 key only needs 256 bits of key storage + 256 bits header = 512 bits.

16 * 512 = 8192 => fits within 8448.


 7. Delete key

To delete the key from the NVM, an SYNC operation (in “Flags” field) must be done. To delete a key, user need to provide the key identifier which is generated when creating this key. There is also “MC” flag which should can be used for anti-rollback protection.

Deleting key will not decrease the size of key group file directly, but the space in the key group will be covered by new key generated later.

 Please see attached hsm_delete_key.c for reference.


8. Generic API

Generic API is not supported on i.MX93 A0 due to a lack of RAM, it is supported on i.MX93 A1.

In lf-6.1.22_2.0.0 ELE library, the generic feature is set as none supported, need to change the src/plat/ele/sab_msg.def file as below to test it on i.MX93 A1 chip.

+MT_SAB_GC_AKEY_GEN     :=      ${FMW}
+MT_SAB_GC_ACRYPTO      :=      ${FMW} 

Generic cryptographic APIs can be used to perform cryptographic operation without using the FW key store. The key buffer, in plaintext, is an input parameter of the API. No need to open hsm keystore before using generic APIs. Because it will not save the key to key store, so NVM thread is also not necessary.

Please see attached hsm_generic_api.c for reference.

  • Asymmetric key generate:

Only RSA is supported on S401 for now. It will return the address of output RSA key modulus /output RSA private exponent /input RSA public exponent

  • Asymmetric crypto

User can choose different operation mode for Encryption / Decryption / Signature generation / Signature verification.


 9. How to get chip MC value?

Command “Get device information” can be used to get generic information regarding the user, the chip and the EdgeLock Enclave FW. It can return Chip UUID/lifecycle/monotonic counter etc.

User can run this API before and after some MC operation to check if the counter value is increased.

Please see the attached hsm_get_info.c for reference.


Best Regards,


Version history
Last update:
‎10-08-2023 11:23 PM
Updated by: