HSE FW ATTRIBUTES

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 HSE Demo Application and the following structure definition from hse
interface: hseAttrMUConfig_t.
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, however independent of MU.
To partition the host RAM space per MU instance (i.e. obtain isolation between applications),
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 hseAttrAllMuMemRegions_t, hseAttrMemRegion_t and
hseAttrMuMemRegions_t structures in 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 than can be configured using
HSE_APP_DEBUG_KEY_ATTR_ID attribute. ADK/P can be written only once (UTEST attribute),
and the operation is allowed only in 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 HSE Demo Application
and the following structure definition from hse interface and API RM: hseAttrApplDebugKey_t,
hseAttrDebugAuthMode_t.
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 UTEST area. The 128-bit value set with 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 hseAttrExtendCustSecurityPolicy_t attribute (enableADKm is enabled)
• • Set hseAttrApplDebugKey_t attribute.

• Note that hseAttrExtendCustSecurityPolicy_t security policy must be set before hseAttrApplDebugKey_t

attribute, and these attributes can be set only once (UTEST attributes)
• Q: How can I know whether application password has been programmed
successfully?
• User can initiate the GetAttribute service for reading the ADKP attribute. HSE FW in response to this
service will return the SHA224(ADKP) to host application. User should also calculate the SHA 224 HASH of
ADKP at its end to verify that HSE FW has correctly programmed the ADKP in 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 CUST_DEL lifecycle. The Lifecycle should be advanced using
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. Lifecycle can be advanced to OEM_PROD and
IN_FIELD lifecycle. For more details, refer to HSE Demo Application and attribute definition from the HSE
interface.
• Q: What attributes are stored in UTEST area?
• The attributes from the categories OTP-ATTR or OTP-ADVANCE-ATTR are stored in 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. Customer has the option to
configure the device with 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 application to use. But if customer wants to use HSE FW feature on the device then
customer has to 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 area.
• For some custom firmware versions, this step might not be required. Please refer to
annexure document of custom firmware for more details.
Q: How do I install HSE FW on a virgin device without secure boot?
Firmware feature flag must be enabled before installing the firmware. HSE FW can be
installed in the system using three methods:
• • Method 1: Program the encrypted image of HSE FW at start location of code flash
area i.e. 0x00400000 and give a reset. SBAF installs the HSE FW after reset.
• • Method 2: Program the address encrypted image of HSE FW in IVT and program the
encrypted HSE FW image at the provided address. After programming, provide a reset.
• • Method 3: Installing the HSE FW through MU interface. Refer to HSE FW reference
manual for more details. The advantage of this approach is that user doesn’t need to
program the encrypted image in flash. It can be saved in RAM also.

HSE FW installation status can be checked by Application by polling the bit number 24
at FSR register in MU at address 0x4038C108
For more details, refer to HSE Firmware Reference Manual.
Q: How do I update the HSE FW image?
Program the HSE FW encrypted image in host code flash area or ram area and issue a
firmware update request to HSE firmware with the address where new image is
programmed. The firmware update operation can be performed in one shot or in
streaming mode. For more details refer to the structure hseFirmwareUpdateSrv_t in
hse_interface.h file.
Q: What is the advantage of using the streaming mode in firmware update command?
The advantages of streaming mode is that 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 command with chunk size multiple of 64 bytes,
user can perform firmware update operation. For smaller memory footprint devices
like S32K3x2 and S32K3x1 variants, this feature can be very useful.
Q: What do 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 Life cycle (LC):
• • if the Life Cycle is CUST_DEL, CUST SuperUser rights are granted
Q: How do I install HSE FW on a virgin device without secure boot?
Firmware feature flag must be enabled before installing the firmware. HSE FW can be
installed in the system using three methods:
• • Method 1: Program the encrypted image of HSE FW at start location of code flash
area i.e. 0x00400000 and give a reset. SBAF installs the HSE FW after reset.
• • Method 2: Program the address encrypted image of HSE FW in IVT and program the
encrypted HSE FW image at the provided address. After programming, provide a reset.
• • Method 3: Installing the HSE FW through MU interface. Refer to HSE FW reference
manual for more details. The advantage of this approach is that user doesn’t need to
program the encrypted image in flash. It can be saved in RAM also.

HSE FW installation status can be checked by Application by polling the bit number 24
at FSR register in MU at address 0x4038C108
For more details, refer to HSE Firmware Reference Manual.
Q: How do I update the HSE FW image?
Program the HSE FW encrypted image in host code flash area or ram area and issue a
firmware update request to HSE firmware with the address where new image is
programmed. The firmware update operation can be performed in one shot or in
streaming mode. For more details refer to the structure hseFirmwareUpdateSrv_t in
hse_interface.h file.
Q: What is the advantage of using the streaming mode in firmware update command?
The advantages of streaming mode is that 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 command with chunk size multiple of 64 bytes,
user can perform firmware update operation. For smaller memory footprint devices
like S32K3x2 and S32K3x1 variants, this feature can be very useful.
Q: What do 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 Life cycle (LC):
• • if the Life Cycle is CUST_DEL, CUST SuperUser rights are granted
• Q: How do I install HSE FW on a virgin device without secure boot?
• Firmware feature flag must be enabled before installing the firmware. HSE FW can be
installed in the system using three methods:
• • Method 1: Program the encrypted image of HSE FW at start location of code flash
area i.e. 0x00400000 and give a reset. SBAF installs the HSE FW after reset.
• • Method 2: Program the address encrypted image of HSE FW in IVT and program the
encrypted HSE FW image at the provided address. After programming, provide a reset.
• • Method 3: Installing the HSE FW through MU interface. Refer to HSE FW reference
manual for more details. The advantage of this approach is that user doesn’t need to
program the encrypted image in flash. It can be saved in RAM also.
•
• HSE FW installation status can be checked by Application by polling the bit number 24
at FSR register in MU at address 0x4038C108
• For more details, refer to HSE Firmware Reference Manual.
• Q: How do I update the HSE FW image?
• Program the HSE FW encrypted image in host code flash area or ram area and issue a
firmware update request to HSE firmware with the address where new image is programmed.
The firmware update operation can be performed in one shot or in streaming mode. For more
details refer to the structure hseFirmwareUpdateSrv_t in hse_interface.h file.
• Q: What is the advantage of using the streaming mode in firmware update command?
• The advantages of streaming mode is that 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 command with chunk size multiple of 64 bytes, user can
perform firmware update operation. For smaller memory footprint devices like S32K3x2 and
S32K3x1 variants, this feature can be very useful.
• Q: What do 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 Life cycle (LC):
• • if the Life Cycle is CUST_DEL, CUST SuperUser rights are granted
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).
Q: What does Basic Secure Boot (BSB) mean? How can I use it?
Basic Secure Boot (BSB) is a simplified boot scheme supported within 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, only difference being that HSE FW (not SBAF) manages it
Q: Can I update the Core Reset (CR) and SMR in IN_FIELD Life cycle?
To change a Core Reset entry, 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 IN_FIELD LC without authorization by providing different values only for the following
parameters: pSmrSrc, smrSize, pInstAuthTag. Otherwise, host needs SuperUser rights (needs to perform
system authorization).
Q: Can I boot encrypted application images securely?
Yes. SMR supports an encryption scheme such confidentiality is also provided for the secure memory region.
The encryption can be carried out in two ways:
• • Using AEAD-GCM with null AAD. In this scheme, the generated GMAC tag over the encrypted image
must also be provided with the SMR.
• • Using AES-CTR. In this case HSE will generate at installation time the authenticity over the encrypted
image. 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, checkout hseSmrDecrypt_t structure and its usage within hseSmrEntry_t in the HSE
interface, along with SMR chapter in HSE RM.
Q: Is there a way to improve the secure boot performance on default clock?
• Yes. Default Secure Boot is executed by HSE Core on 48MHz. To enable the PLL
configuration, 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 SoC Reference Manual, Clocking Chapter. As a
prerequisite, 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 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).
Q: What does Basic Secure Boot (BSB) mean? How can I use it?
Basic Secure Boot (BSB) is a simplified boot scheme supported within
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, only difference being that HSE
FW (not SBAF) manages it
Q: Can I update the Core Reset (CR) and SMR in IN_FIELD Life cycle?
To change a Core Reset entry, 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 IN_FIELD LC without authorization by providing different values only
for the following parameters: pSmrSrc, smrSize, pInstAuthTag. Otherwise, host needs
SuperUser rights (needs to perform system authorization).
Q: Can I boot encrypted application images securely?
Yes. SMR supports an encryption scheme such confidentiality is also provided for the secure
memory region. The encryption can be carried out in two ways:
• • Using AEAD-GCM with null AAD. In this scheme, the generated GMAC tag over the
encrypted image must also be provided with the SMR.
• • Using AES-CTR. In this case HSE will generate at installation time the authenticity
over the encrypted image. 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, checkout hseSmrDecrypt_t structure and its usage within hseSmrEntry_t in
the HSE interface, along with SMR chapter in HSE RM.
Q: Is there a way to improve the secure boot performance on default clock?
Yes. Default Secure Boot is executed by HSE Core on 48MHz. To enable the PLL configuration,
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 SoC Reference Manual, Clocking Chapter. As a prerequisite, 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 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).
Q: What does Basic Secure Boot (BSB) mean? How can I use it?
Basic Secure Boot (BSB) is a simplified boot scheme supported within
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, only difference being that HSE
FW (not SBAF) manages it
Q: Can I update the Core Reset (CR) and SMR in IN_FIELD Life cycle?
To change a Core Reset entry, 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 IN_FIELD LC without authorization by providing different values only
for the following parameters: pSmrSrc, smrSize, pInstAuthTag. Otherwise, host needs
SuperUser rights (needs to perform system authorization).
Q: Can I boot encrypted application images securely?
Yes. SMR supports an encryption scheme such confidentiality is also provided for the secure
memory region. The encryption can be carried out in two ways:
• • Using AEAD-GCM with null AAD. In this scheme, the generated GMAC tag over the
encrypted image must also be provided with the SMR.
• • Using AES-CTR. In this case HSE will generate at installation time the authenticity
over the encrypted image. 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, checkout hseSmrDecrypt_t structure and its usage within hseSmrEntry_t in
the HSE interface, along with SMR chapter in HSE RM.
Q: Is there a way to improve the secure boot performance on default clock?
Yes. Default Secure Boot is executed by HSE Core on 48MHz. To enable the PLL configuration,
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 SoC Reference Manual, Clocking Chapter. As a prerequisite, 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 SoC Reference Manual, Boot Chapter
Q: How are the keys used with a crypto operation?
All keys used with crypto operation are referenced by a unique Key Handle. The Key Handle
is defined
as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
1. Shared secret computation:
a. generate a pair of ephemeral keys using 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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
2. Derive the TLS keys:
a. derive the TLS the master secret, the key block and the verify data using the
hseKdfTLS12PrfScheme_t scheme from key derivation service (hseKeyDeriveSrv_t).
This service must be call multiple time to generate:
i. the master secret from pre-master secret (the shared secret compute above)
ii. the TLS key_block from 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
temporary slot.
To be able to use the generated keys with crypto operations, the application has to use
hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and encryption keys to
RAM key
slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined
as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
1. Shared secret computation:
a. generate a pair of ephemeral keys using 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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
2. Derive the TLS keys:
a. derive the TLS the master secret, the key block and the verify data using the
hseKdfTLS12PrfScheme_t scheme from key derivation service (hseKeyDeriveSrv_t).
This service must be call multiple time to generate:
i. the master secret from pre-master secret (the shared secret compute above)
ii. the TLS key_block from 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
temporary slot.
To be able to use the generated keys with crypto operations, the application has to use
hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and encryption keys to
RAM key
slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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

temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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

temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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
temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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

temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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

temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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

temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. 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 crypto operation are referenced by a unique Key Handle. The Key Handle
is defined as a 32-bit value as follow:
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 identified the index of 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 CUST_DEL lifecycle. In this case, the life
cycle 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 the steps below:
• 1. Shared secret computation: a. generate a pair of ephemeral keys using
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 hseImportKeySrv_t. 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
hseDHComputeSharedSecretSrv_t service.
•
一 2. Derive the TLS keys: a. derive the TLS the master secret, the key block and the
verify data using the hseKdfTLS12PrfScheme_t scheme from key derivation service
(hseKeyDeriveSrv_t). This service must be call multiple time to generate: i. the master secret
from pre-master secret (the shared secret compute above)
一 ii. the TLS key_block from 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

temporary slot. To be able to use the generated keys with crypto operations, the application
has to use hseKeyDeriveCopyKeySrv_t service to copy (one-by-one) each MAC and
encryption keys to RAM key slots of a certain key type (e.s. AES key slots).
Note: Client authentication is mandatory for any TLS session supported by HSE