i.MX93 Field Return Lifecycle Update#
This documentation covers the field return OEM lifecycle update for the i.MX93 with EdgeLock Secure Enclave. For detailed information about lifecycle management, please consult the reference manual.
1. Prerequisites#
SPSDK is needed with examples extension.
pip install spsdk[examples](Please refer to the installation documentation.)This demo was tested with i.MX93 EVK board
The target device must be in OEM_CLOSED lifecycle state to successfully request a field return update.
YamlDiffWidget("inputs/return_lifecycle_update_req.diffc").html
nxpimage signed-msg get-template -f mx93 -o workspace/return_lifecycle_update_req.yaml -m return_lifecycle_update_req --force
Creating workspace/return_lifecycle_update_req.yaml template file.
Configuration Differences
# ====================== Signed message Configuration template for mimx9352, Revision: latest. =======================
# ======================================================================================================================
# == General Options ==
# ======================================================================================================================
# -------------------------------------===== The chip family name [Required] =====--------------------------------------
# Description: NXP chip family identifier.
family: mimx9352
# -----------------------------------------===== MCU revision [Optional] =====------------------------------------------
# Description: Revision of silicon. The 'latest' name, means most current revision.
# Possible options:
revision: latest
# ---------------------------------------===== Output file name [Required] =====----------------------------------------
# Description: Output Signed Message file name
output: signed_message.bin
output: ../outputs/signed_msg_fr_oem.bin
# ======================================================================================================================
# == Settings of Signed Message ==
# ======================================================================================================================
# -----------------------------------===== Super Root Key (SRK) set [Required] =====------------------------------------
# Description: Defines which set is used to authenticate the signed message.
# Possible options:
srk_set: oem
# -------------------------------------------===== Used SRK [Required] =====--------------------------------------------
# Description: Which key from SRK set is being used.
used_srk_id: 0
# ----------------------------------------===== SRK revoke mask [Required] =====----------------------------------------
# Description: Bitmask to indicate which SRKs to revoke. Bit set to 1 means revoke key. Bit 0 = revoke SRK_0, bit 1 =
# revoke SRK_1 etc.
srk_revoke_mask: 0
# -----------------------------------------===== Fuse version [Required] =====------------------------------------------
# Description: The value must be equal or greater than the version stored in fuses to allow loading this container.
fuse_version: 0
# ---------------------------------------===== Software version [Required] =====----------------------------------------
# Description: Number used by Privileged Host Boot Companion (PHBC) to select between multiple images with same Fuse
# version field.
sw_version: 0
# --------------------------------===== Signed Message container signer [Required] =====--------------------------------
# Description: Signature provider configuration in format 'type=; = ; = ' or a
# private key used for sign the container header. Header can be signed by SRK. The referenced SRK must not have been
# revoked.
signer: type=file;file_path=my_prv_key.pem Add private key or signer
signer: ../../../_data/keys/ecc384/srk0_ecc384.pem
# ======================================================================================================================
# == Configuration of Signed Message SRK table ==
# ======================================================================================================================
# -------------------------------------------===== SRK Table [Required] =====-------------------------------------------
# Description: SRK (Super Root key) table definition.
srk_table:
# -------------------------------------------===== CA Flag [Optional] =====-------------------------------------------
# Description: CA Flag is used by HAB to indicate if the SRK is allowed to sign other keys. In AHAB CA Flag only
# affects the final SRKH (Super Root Key Hash) value burned into chip fuses. It is not used in the AHAB signing
# process itself. This option exists only for compatibility with systems where fuses are already programmed. In most
# cases, this should remain false.
flag_ca: false
# ---------------------------------------===== Hash Algorithm [Optional] =====----------------------------------------
# Description: Hash algorithm used for SRK records. If not specified, default algorithm based on key type will be
# used.
# Possible options:
hash_algorithm: default
# ---------------------------------===== Super Root Key (SRK) table [Required] =====----------------------------------
# Description: Table containing the used SRK records. All SRKs must be of the same type. Supported signing algorithms
# are: RSA-PSS, ECDSA, Dilithium or SM2. Supported hash algorithms: sha256, sha384, sha512, sha3_256, sha3_384,
# sha3_512, sm3. Supported key sizes/curves: prime256v1, sec384r1, sec512r1, rsa2048, rsa4096, dilithium3, sm2.
# Certificate may be of Certificate Authority. Dilithium algorithms are supported just in new type of AHAB container
srk_array: Add your SRK public keys
- my_srk_public_key0.pub
- my_srk_public_key1.pub
- my_srk_public_key2.pub
- my_srk_public_key3.pub
- ../../../_data/keys/ecc384/srk0_ecc384.pub
- ../../../_data/keys/ecc384/srk1_ecc384.pub
- ../../../_data/keys/ecc384/srk2_ecc384.pub
- ../../../_data/keys/ecc384/srk3_ecc384.pub
# ======================================================================================================================
# == Optional configuration of AHAB Container Certificate (if not used, erase the section) ==
# ======================================================================================================================
# -------------------------------------===== The AHAB certificate [Optional] =====--------------------------------------
# Description: The file that contains AHAB certificate. It could be used already prepared binary form signed by SRK, or
# it is possible to use configuration YAML file of certificate and the AHAB export process it will export it itself.
certificate: my_ahab_certificate.bin
# -----------------------------------------===== IV file path [Optional] =====------------------------------------------
# Description: Used only for encrypted messages. Fixed size at 256 bits. If defined the encryption is used for this
# Signed message. The HEX format is accepted.
iv_path: my_IV.txt
# ======================================================================================================================
# == Settings of Message ==
# ======================================================================================================================
message:
# -------------------------------------===== Certificate version [Optional] =====-------------------------------------
# Description: Certificate version
cert_version: 0
# -----------------------------------===== Certificate permission [Optional] =====------------------------------------
# Description: Certificate permission, to be used in future. The stated permission must allow the operation requested
# by the signed message.
cert_permission: 0
# -----------------------------------------===== Issue date [Optional] =====------------------------------------------
# Description: Optional Issue date of message, if not defined the current date is used. The format must be following:
# 'YYYY-MM'
issue_date: 2022-10
# -----------------------------------------===== Device UUID [Optional] =====-----------------------------------------
# Description: Unique identifier of the chip. It could be retrieve by BLHOST command from chip or also the debug
# authentication protocol could provide this value. Hex string format (hexadecimal string without '0x'). In case that
# the restriction on UUID is not needed the field could be omitted.
uuid: '0000000000000000' UUID can be optionally specified
command:
# ----------------------------------------===== Life Cycle [Required] =====-----------------------------------------
# Description: Value of life cycle to be moved on. The value 16 is used for OEM keys (FIELD_RETURN_OEM) and 32 for
# NXP keys(FIELD_RETURN_NXP).
RETURN_LIFECYCLE_UPDATE_REQ: 16 Specify number 16 to indicate FIELD OEM RETURN request
# ====================== Signed message Configuration template for mimx9352, Revision: latest. =======================
# ======================================================================================================================
# == General Options ==
# ======================================================================================================================
# -------------------------------------===== The chip family name [Required] =====--------------------------------------
# Description: NXP chip family identifier.
family: mimx9352
# -----------------------------------------===== MCU revision [Optional] =====------------------------------------------
# Description: Revision of silicon. The 'latest' name, means most current revision.
# Possible options:
revision: latest
# ---------------------------------------===== Output file name [Required] =====----------------------------------------
# Description: Output Signed Message file name
output: ../outputs/signed_msg_fr_oem.bin
# ======================================================================================================================
# == Settings of Signed Message ==
# ======================================================================================================================
# -----------------------------------===== Super Root Key (SRK) set [Required] =====------------------------------------
# Description: Defines which set is used to authenticate the signed message.
# Possible options:
srk_set: oem
# -------------------------------------------===== Used SRK [Required] =====--------------------------------------------
# Description: Which key from SRK set is being used.
used_srk_id: 0
# ----------------------------------------===== SRK revoke mask [Required] =====----------------------------------------
# Description: Bitmask to indicate which SRKs to revoke. Bit set to 1 means revoke key. Bit 0 = revoke SRK_0, bit 1 =
# revoke SRK_1 etc.
srk_revoke_mask: 0
# -----------------------------------------===== Fuse version [Required] =====------------------------------------------
# Description: The value must be equal or greater than the version stored in fuses to allow loading this container.
fuse_version: 0
# ---------------------------------------===== Software version [Required] =====----------------------------------------
# Description: Number used by Privileged Host Boot Companion (PHBC) to select between multiple images with same Fuse
# version field.
sw_version: 0
# --------------------------------===== Signed Message container signer [Required] =====--------------------------------
# Description: Signature provider configuration in format 'type=; = ; = ' or a
# private key used for sign the container header. Header can be signed by SRK. The referenced SRK must not have been
# revoked.
signer: ../../../_data/keys/ecc384/srk0_ecc384.pem Add private key or signer
# ======================================================================================================================
# == Configuration of Signed Message SRK table ==
# ======================================================================================================================
# -------------------------------------------===== SRK Table [Required] =====-------------------------------------------
# Description: SRK (Super Root key) table definition.
srk_table:
# -------------------------------------------===== CA Flag [Optional] =====-------------------------------------------
# Description: CA Flag is used by HAB to indicate if the SRK is allowed to sign other keys. In AHAB CA Flag only
# affects the final SRKH (Super Root Key Hash) value burned into chip fuses. It is not used in the AHAB signing
# process itself. This option exists only for compatibility with systems where fuses are already programmed. In most
# cases, this should remain false.
flag_ca: false
# ---------------------------------------===== Hash Algorithm [Optional] =====----------------------------------------
# Description: Hash algorithm used for SRK records. If not specified, default algorithm based on key type will be
# used.
# Possible options:
hash_algorithm: default
# ---------------------------------===== Super Root Key (SRK) table [Required] =====----------------------------------
# Description: Table containing the used SRK records. All SRKs must be of the same type. Supported signing algorithms
# are: RSA-PSS, ECDSA, Dilithium or SM2. Supported hash algorithms: sha256, sha384, sha512, sha3_256, sha3_384,
# sha3_512, sm3. Supported key sizes/curves: prime256v1, sec384r1, sec512r1, rsa2048, rsa4096, dilithium3, sm2.
# Certificate may be of Certificate Authority. Dilithium algorithms are supported just in new type of AHAB container
srk_array: Add your SRK public keys
- ../../../_data/keys/ecc384/srk0_ecc384.pub
- ../../../_data/keys/ecc384/srk1_ecc384.pub
- ../../../_data/keys/ecc384/srk2_ecc384.pub
- ../../../_data/keys/ecc384/srk3_ecc384.pub
# ======================================================================================================================
# == Optional configuration of AHAB Container Certificate (if not used, erase the section) ==
# ======================================================================================================================
# -------------------------------------===== The AHAB certificate [Optional] =====--------------------------------------
# Description: The file that contains AHAB certificate. It could be used already prepared binary form signed by SRK, or
# it is possible to use configuration YAML file of certificate and the AHAB export process it will export it itself.
# certificate: my_ahab_certificate.bin
# -----------------------------------------===== IV file path [Optional] =====------------------------------------------
# Description: Used only for encrypted messages. Fixed size at 256 bits. If defined the encryption is used for this
# Signed message. The HEX format is accepted.
# iv_path: my_IV.txt
# ======================================================================================================================
# == Settings of Message ==
# ======================================================================================================================
message:
# -------------------------------------===== Certificate version [Optional] =====-------------------------------------
# Description: Certificate version
cert_version: 0
# -----------------------------------===== Certificate permission [Optional] =====------------------------------------
# Description: Certificate permission, to be used in future. The stated permission must allow the operation requested
# by the signed message.
cert_permission: 0
# -----------------------------------------===== Issue date [Optional] =====------------------------------------------
# Description: Optional Issue date of message, if not defined the current date is used. The format must be following:
# 'YYYY-MM'
issue_date: 2022-10
# -----------------------------------------===== Device UUID [Optional] =====-----------------------------------------
# Description: Unique identifier of the chip. It could be retrieve by BLHOST command from chip or also the debug
# authentication protocol could provide this value. Hex string format (hexadecimal string without '0x'). In case that
# the restriction on UUID is not needed the field could be omitted.
uuid: '0000000000000000' UUID can be optionally specified
command:
# ----------------------------------------===== Life Cycle [Required] =====-----------------------------------------
# Description: Value of life cycle to be moved on. The value 16 is used for OEM keys (FIELD_RETURN_OEM) and 32 for
# NXP keys(FIELD_RETURN_NXP).
RETURN_LIFECYCLE_UPDATE_REQ: 16 Specify number 16 to indicate FIELD OEM RETURN request
2. Generation of signed message#
The command generates the signed message for the return lifecycle request.
%! nxpimage -v signed-msg export -c inputs/return_lifecycle_update_req.yaml
nxpimage -v signed-msg export -c inputs/return_lifecycle_update_req.yaml
INFO:spsdk.apps.nxpimage_apps.nxpimage_signed_msg:Created Signed message Image:
Name: Signed Message Image
Starts: 0x0
Ends: 0x277
Size: Size: 632 B
Alignment: 8 B
Execution Start Address: Not defined
Pattern:zeros
Signed Message Image for mimx9352, Revision: latest
INFO:spsdk.apps.nxpimage_apps.nxpimage_signed_msg:Created Signed message Image memory map:
+==0x0000_0000= Signed Message Image ==+
| Size: 632 B |
| Signed Message Image for mimx9352, |
| Revision: latest |
| Pattern: zeros |
|+==0x0000_0000= Signed Message ======+|
|| Size: 632 B ||
|| Signed Message for ||
|| RETURN_LIFECYCLE_UPDATE_REQ ||
|+==0x0000_0277=======================+|
+==0x0000_0277=========================+
INFO:spsdk.apps.nxpimage_apps.nxpimage_signed_msg:SRK hash:772e1009c66d2dd57ab25dc6a20409b686676463983e7e54cf24e55b38644f37
Success. (Signed message: outputs/signed_msg_fr_oem.bin created.)
3. Requesting Lifecycle update#
NOTE: Please note this is ONE TIME OPERATION (when lifecycle is moved to FR_OEM it cannot be moved back to OEM_CLOSED lifecycle).
nxpele --family mimx9352 signed-message --binary ./outputs/signed_msg_fr_oem.bin