Q: How do I configure/enable more Message Units (MUs)?

By default, only MU0 is enabled and it can't be disabled. To enable more MUs,
the hseSetAttrSrv_t service can be used with the HSE_MU_CONFIG_ATTR_ID attribute
ID. For more details, refer to the HSE Demo Application and
the hseAttrMUConfig_t structure definition from the HSE interface.
Q: How can I partition the application domain RAM to be accessible only to
certain MU instances?
By default, HSE restricts the address space for where the data for service requests
can be provided to its own address space and other reserved areas, independent of
MU. To partition the host RAM space per MU instance (i.e., obtain isolation between
applications), the hseSetAttrSrv_t service can be used to allocate for each MU
instance the allowed list of address ranges from which data can be provided to HSE.
For more details, refer to the hseAttrAllMuMemRegions_t, hseAttrMemRegion_t,
and hseAttrMuMemRegions_t structures in the HSE interface and API RM.
Q: How do I configure the ADK/P (debug key or password)?
The debug key/password (ADK/P) is a 128-bit value that can be configured using
the HSE_APP_DEBUG_KEY_ATTR_ID attribute. ADK/P can be written only once (UTEST
attribute), and the operation is allowed only in the CUST_DEL Life Cycle. By default,
application debug authorization mode is password-based. To enable the challenge-
response debug authorization mode (based on the key), the application shall use
the HSE_DEBUG_AUTH_MODE_ATTR_ID attribute.
For more details, refer to the HSE Demo Application and
the hseAttrApplDebugKey_t and hseAttrDebugAuthMode_t structure definitions from
the HSE interface and API RM.
Q: What does ADKm mean? How can I configure it?
The Application debug key/password (ADK/P attribute) can be diversified with UID
before being written in the UTEST area. The 128-bit value set with
the HSE_APP_DEBUG_KEY_ATTR_ID attribute will be interpreted as ADKPm
(customer's master key/password). The following derivation is used:
 hUID = SHA2_256(UID)
 hADKPm = SHA2_256(ADKPm)
 ADKP {for debugger} = AES256-ECB(hUID(16 bytes..0 to 15)), where the key
is hADKPm; {ADKPm = customer's master key/password}
The following attributes must be set to enable ADKPm usage:
 Set the hseAttrExtendCustSecurityPolicy_t attribute (enableADKm is enabled)
 Set the hseAttrApplDebugKey_t attribute
Note that the hseAttrExtendCustSecurityPolicy_t security policy must be set before
the hseAttrApplDebugKey_t attribute, and these attributes can be set only once
(UTEST attributes).
Q: How can I know whether the application password has been
programmed successfully?
The user can initiate the GetAttribute service for reading the ADKP attribute. HSE
FW, in response to this service, will return the SHA224(ADKP) to the host
application. The user should also calculate the SHA224 HASH of ADKP at their end to
verify that HSE FW has correctly programmed the ADKP in the UTEST area. The
firmware only returns the first 16 bytes of the SHA224(ADKP).
Q: How do I advance the Life Cycle?
SOC is delivered in the CUST_DEL lifecycle. The lifecycle should be advanced using
the HSE_SECURE_LIFECYCLE_ATTR_ID (see hseAttrSecureLifecycle_t). The Life Cycle
attribute can be set only once (UTEST attribute) and only if the ADK/P is already set
in UTEST. The lifecycle can be advanced to OEM_PROD and IN_FIELD lifecycle. For
more details, refer to the HSE Demo Application and the attribute definition from
the HSE interface.
Q: What attributes are stored in the UTEST area?
The attributes from the categories OTP-ATTR or OTP-ADVANCE-ATTR are stored in
the UTEST area. This means that they can only be set once, advanced respectively,
in the UTEST area. One can find more information on the attributes classification in
the HSE interface.
HSE FW Administrative and Installation
Q: What is the firmware feature flag? How do I enable it?
K3xx family devices are delivered with only secure BAF programmed. Customers
have the option to configure the device with the secure firmware feature enabled or
disabled. By default, it is assumed that HSE FW will not be used by the user, hence
all the resources (HSE code flash area, HSE data flash area) required by HSE FW are
free for the application to use. However, if the customer wants to use the HSE FW
feature on the device, they must program the location 0x1B000000 with 8 bytes of
random value and give a reset. After the reset, secure BAF will reserve the 176KB
area of code flash and 168KB of data flash area for HSE.
For some custom firmware versions, this step might not be required. Please refer to
the annexure document of custom firmware for more details.
Q: How do I install HSE FW on a virgin device without secure boot?
The firmware feature flag must be enabled before installing the firmware. HSE FW
can be installed in the system using three methods:
 1. Method 1: Program the encrypted image of HSE FW at the start location of
the code flash area, i.e., 0x00400000, and give a reset. SBAF installs the HSE
FW after the reset.
2. Method 2: Program the address of the encrypted image of HSE FW in IVT
and program the encrypted HSE FW image at the provided address. After
programming, provide a reset.
3. Method 3: Install the HSE FW through the MU interface. Refer to the HSE FW
reference manual for more details. The advantage of this approach is that the
user doesn’t need to program the encrypted image in flash; it can be saved in
RAM.
HSE FW installation status can be checked by the application by polling bit number
24 at the FSR register in MU at address 0x4038C108. For more details, refer to the
HSE Firmware Reference Manual.
Q: How do I update the HSE FW image?
Program the HSE FW encrypted image in the host code flash area or RAM area and
issue a firmware update request to HSE firmware with the address where the new
image is programmed. The firmware update operation can be performed in one shot
or in streaming mode. For more details, refer to
the hseFirmwareUpdateSrv_t structure in the hse_interface.h file.
Q: What is the advantage of using the streaming mode in the firmware
update command?
The advantage of streaming mode is that the user can perform the firmware update
operation without the need to store the full image (i.e., 128KB size) in RAM or flash
area. By issuing multiple firmware update commands with chunk sizes multiple of
64 bytes, the user can perform the firmware update operation. For smaller memory
footprint devices like S32K3x2 and S32K3x1 variants, this feature can be very
useful.
Q: What does the term "pink firmware image" mean?
The HSE Firmware pink image is the encrypted and authenticated image provided
by NXP and encrypted with NXP keys.
Q: What is SYS-Authorization and how can I use it?
The execution of certain HSE services is conditioned by the execution rights granted
to the host:
 SuperUser (OEM or CUST) rights: High execution privileges and no
limitation on service requests.
 User rights: Restricted execution privileges.
After reset, the SYS rights are synchronized with the Life Cycle (LC):
 If the Life Cycle is CUST_DEL, CUST SuperUser rights are granted.
HSE FW Administrative and Installation
Q: What does Basic Secure Boot (BSB) mean? How can I use it?
Basic Secure Boot (BSB) is a simplified boot scheme supported within
the hseBootDataImageSignSrv_t service. BSB can boot only one core (the booted
core can start other cores). The application image should contain the header that
includes all information needed for BSB (i.e., same as in un-secure boot). The
signature should be appended to the end of AppBL and generated using a key
derived from ADK/P. The securing process is similar to IVT authentication
generation/verification starting from revision 2, with the only difference being that
HSE FW (not SBAF) manages it.
Q: Can I update the Core Reset (CR) and SMR in the IN_FIELD Life Cycle?
To change a Core Reset entry, the host needs to have SuperUser access rights
(IN_FIELD LC). To gain SuperUser rights, the host must perform the system
authorization procedure using an authorization key (installed before). If there is no
authorization key installed, CR cannot be changed. SMR can be updated in the
IN_FIELD LC without authorization by providing different values only for the
following parameters: pSmrSrc, smrSize, pInstAuthTag. Otherwise, the host needs
SuperUser rights (needs to perform system authorization).
Q: Can I boot encrypted application images securely?
Yes. SMR supports an encryption scheme such that confidentiality is also provided
for the secure memory region. The encryption can be carried out in two ways:
1. Using AEAD-GCM with null AAD: In this scheme, the generated GMAC tag
over the encrypted image must also be provided with the SMR.
2. Using AES-CTR: In this case, HSE will generate the authenticity over the
encrypted image at installation time. The pGmacTag field is not used.
The encrypted SMR is a generic mechanism and works for any memory region that
is loaded (pSmrDest address is provided), independent of the scope (i.e., not only
for boot images). For more details, check out the hseSmrDecrypt_t structure and its
usage within hseSmrEntry_t in the HSE interface, along with the SMR chapter in the
HSE RM.
Q: Is there a way to improve the secure boot performance on the default
clock?
Yes. Default Secure Boot is executed by HSE Core on 48MHz. To enable the PLL
configuration, the host must enable the PLL enable bit in BCW in the IVT. HSE
Firmware enables the PLL in two modes, Option A (only on supported devices) and
Option B. For more details on these clocking options, refer to the SoC Reference
Manual, Clocking Chapter. As a prerequisite, the host is expected to enable FXOSC
via SBAF by configuring the UTEST at location 0x1B000050. For more details on
FXOSC configuration by SBAF, refer to the SoC Reference Manual, Boot Chapter.
On SMR installation (see hseSmrEntryInstallSrv_t), only the following parameters
can be updated: pSmrSrc, smrSize, pInstAuthTag. Any other parameters
(e.g., keyHandle, configFlags, etc.) cannot be updated in User mode; these
parameters can be updated only by having SuperUser rights.
HSE FW Administrative and Installation
Q: What does Basic Secure Boot (BSB) mean? How can I use it?
Basic Secure Boot (BSB) is a simplified boot scheme supported within
the hseBootDataImageSignSrv_t service. BSB can boot only one core (the booted
core can start other cores). The application image should contain the header that
includes all information needed for BSB (i.e., same as in un-secure boot). The
signature should be appended to the end of AppBL and generated using a key
derived from ADK/P. The securing process is similar to IVT authentication
generation/verification starting from revision 2, with the only difference being that
HSE FW (not SBAF) manages it.
Q: Can I update the Core Reset (CR) and SMR in the IN_FIELD Life Cycle?
To change a Core Reset entry, the host needs to have SuperUser access rights
(IN_FIELD LC). To gain SuperUser rights, the host must perform the system
authorization procedure using an authorization key (installed before). If there is no
authorization key installed, CR cannot be changed. SMR can be updated in the
IN_FIELD LC without authorization by providing different values only for the
following parameters: pSmrSrc, smrSize, pInstAuthTag. Otherwise, the host needs
SuperUser rights (needs to perform system authorization).
Q: Can I boot encrypted application images securely?
Yes. SMR supports an encryption scheme such that confidentiality is also provided
for the secure memory region. The encryption can be carried out in two ways:
1. Using AEAD-GCM with null AAD: In this scheme, the generated GMAC tag
over the encrypted image must also be provided with the SMR.
2. Using AES-CTR: In this case, HSE will generate the authenticity over the
encrypted image at installation time. The pGmacTag field is not used.
The encrypted SMR is a generic mechanism and works for any memory region that
is loaded (pSmrDest address is provided), independent of the scope (i.e., not only
for boot images). For more details, check out the hseSmrDecrypt_t structure and its
usage within hseSmrEntry_t in the HSE interface, along with the SMR chapter in the
HSE RM.
Q: Is there a way to improve the secure boot performance on the default
clock?
Yes. Default Secure Boot is executed by HSE Core on 48MHz. To enable the PLL
configuration, the host must enable the PLL enable bit in BCW in the IVT. HSE
Firmware enables the PLL in two modes, Option A (only on supported devices) and
Option B. For more details on these clocking options, refer to the SoC Reference
Manual, Clocking Chapter. As a prerequisite, the host is expected to enable FXOSC
via SBAF by configuring the UTEST at location 0x1B000050. For more details on
FXOSC configuration by SBAF, refer to the SoC Reference Manual, Boot Chapter.
Q: How are the keys used with a crypto operation?
All keys used with crypto operations are referenced by a unique Key Handle. The
Key Handle is defined as a 32-bit value as follows:
 keyHandle = 0x00(byte3) || key catalog id(byte2) || key group index(byte1) ||
keys slot index(byte0)
Where:
 key catalog id identifies the key catalog: ROM, NVM, RAM
 key group index identifies the index of the group defined in the catalog
 keys slot index is between 0 and (p-1), where p is the maximum number of
keys defined in the group.
Q: Can I avoid using OEM keys (including OEM Life Cycle)?
Yes. This means that all NVM keys are provisioned in the CUST_DEL lifecycle. In this
case, the lifecycle will be advanced from CUST_DEL directly to IN_FIELD.
Q: How can I generate the TLS session keys using HSE services?
To generate the TLS session keys for a session using ephemeral (elliptic curve)
Diffie-Hellman key negotiation, the application must follow these steps:
1. Shared secret computation: a. Generate a pair of ephemeral keys using
the hseKeyGenerateSrv_t service (e.g., generate an ECC key pair exporting
the public key to the host). b. Sign
the server_key_exchange/client_key_exchange message with the key
corresponding to the authentication certificate of the device. c. Import the
other party’s certificate public key from the certificate message. d. Import the
other party’s Diffie-Hellman public key from
the client_key_exchange/server_key_exchange message using
the hseImportKeySrv_t service. The key signature must be verified using the
other party’s certificate public key (the key container will consist of the entire
key_exchange message). e. Compute the Diffie-Hellman shared secret (in a
SHARED_SECRET slot) using the hseDHComputeSharedSecretSrv_t service.
2. Derive the TLS keys: a. Derive the TLS master secret, the key block, and
the verify data using the hseKdfTLS12PrfScheme_t scheme from the key
derivation service (hseKeyDeriveSrv_t). This service must be called multiple
times to generate: i. The master secret from the pre-master secret (the
shared secret computed above). ii. The TLS key_block from the master (for
TLS key expansion step). iii. Client/server verify_data for TLS Finished
messages.
The key material (key_block) is generated in a SHARED_SECRET slot, which is used
as a temporary slot. To be able to use the generated keys with crypto operations,
the application has to use the hseKeyDeriveCopyKeySrv_t service to copy (one-by-
one) each MAC and encryption key to RAM key slots of a certain key type (e.g., AES
key slots).
Note: Client authentication is mandatory for any TLS session supported by HSE.

Q: How are the keys used with a crypto operation?

All keys used with a crypto operation are referenced by a unique Key Handle. The
Key Handle is defined as a 32-bit value as follows:
keyHandle = 0x00(byte3) || key catalog id(byte2) || key group index(byte1) || keys
slot index(byte0)
Where:
 key catalog id identifies the key catalog: ROM, NVM, RAM
 key group index identifies the index of the group defined in the catalog
 keys slot index is between 0 and (p-1), where p is the maximum number of
keys defined in the group
Q: Can I avoid using OEM keys (including OEM Life Cycle)?
YES. This means that all NVM keys are provisioned in the CUST_DEL lifecycle. In this
case, the lifecycle will be advanced from CUST_DEL directly to IN_FIELD.
Q: How can I generate the TLS session keys using HSE services?
To generate the TLS session keys for a session using ephemeral (elliptic curve)
Diffie-Hellman key negotiation, the application must follow these steps:
1. Shared Secret Computation:
 a. Generate a pair of ephemeral keys using
the hseKeyGenerateSrv_t service (e.g., generate an ECC key pair and
export the public key to the host).
 b. Sign the server_key_exchange/client_key_exchange message with
the key corresponding to the authentication certificate of the device.
 c. Import the other party’s certificate public key from the certificate
message.
 d. Import the other party’s Diffie-Hellman public key from
the client_key_exchange/server_key_exchange message using
the hseImportKeySrv_t service. The key signature must be verified
 using the other party’s certificate public key (the key container will
consist of the entire key_exchange message).
 e. Compute the Diffie-Hellman shared secret (in a SHARED_SECRET
slot) using the hseDHComputeSharedSecretSrv_t service.
2. Derive the TLS Keys:
 a. Derive the TLS master secret, the key block, and the verify data
using the hseKdfTLS12PrfScheme_t scheme from the key derivation
service (hseKeyDeriveSrv_t). This service must be called multiple times
to generate:
 i. The master secret from the pre-master secret (the shared
secret computed above).
 ii. The TLS key_block from the master (for the TLS key expansion
step).
 iii. Client/server verify_data for TLS Finished messages.
The key material (key_block) is generated in a SHARED_SECRET slot, which is used
as a temporary slot. To use the generated keys with crypto operations, the
application must use the hseKeyDeriveCopyKeySrv_t service to copy (one-by-one)
each MAC and encryption key to RAM key slots of a certain key type (e.g., AES key
slots).
Note: Client authentication is mandatory for any TLS session supported by HSE.
How are the keys used with a crypto operation?
All keys used in a crypto operation are referenced by a unique Key Handle. The Key
Handle is defined as a 32-bit value as follows:
keyHandle = 0x00(byte3) || key catalog id(byte2) || key group index(byte1) || key
slot index(byte0)
Where:
 Key catalog id identifies the key catalog: ROM, NVM, RAM.
 Key group index identifies the index of the group defined in the catalog.
 Key slot index is between 0 and (p-1), where p is the maximum number of
keys defined in the group.
Can I avoid using OEM keys (including OEM Life Cycle)?
Yes. This means that all NVM keys are provisioned in the CUST_DEL lifecycle. In this
case, the lifecycle will be advanced from CUST_DEL directly to IN_FIELD.
How can I generate the TLS session keys using HSE services?
To generate the TLS session keys for a session using ephemeral (elliptic curve)
Diffie-Hellman key negotiation, the application must follow these steps:
 1. Shared Secret Computation:
 a. Generate a pair of ephemeral keys using
the hseKeyGenerateSrv_t service (e.g., generate an ECC key pair and
export the public key to the host).
 b. Sign the server_key_exchange/client_key_exchange message with
the key corresponding to the authentication certificate of the device.
 c. Import the other party’s certificate public key from the certificate
message.
 d. Import the other party’s Diffie-Hellman public key from
the client_key_exchange/server_key_exchange message using
the hseImportKeySrv_t service. The key signature must be verified
using the other party’s certificate public key (the key container will
consist of the entire key_exchange message).
 e. Compute the Diffie-Hellman shared secret (in a SHARED_SECRET
slot) using the hseDHComputeSharedSecretSrv_t service.
2. Derive the TLS Keys:
 a. Derive the TLS master secret, key block, and verify data using
the hseKdfTLS12PrfScheme_t scheme from the key derivation service
(hseKeyDeriveSrv_t). This service must be called multiple times to
generate:
 i. The master secret from the pre-master secret (the shared
secret computed above).
 ii. The TLS key_block from the master secret (for the TLS key
expansion step).
 iii. Client/server verify_data for TLS Finished messages.
The key material (key_block) is generated in a SHARED_SECRET slot, which is used
as a temporary slot. To use the generated keys with crypto operations, the
application must use the hseKeyDeriveCopyKeySrv_t service to copy each MAC and
encryption key to RAM key slots of a certain key type (e.g., AES key slots).
Note: Client authentication is mandatory for any TLS session supported by HSE.