S32K1xx Series MCU CSEc Hardware Cryptographic Module User Manual

By: China AMP GPIS AE

Revision History

Version	Date	Modifier	Content
Rev_1.0	2019.06.25	Yunchuan.wang@nxp.com	Initial version, including complete application guide content, internal review.
Rev 2.0	2019.07.22	Yunchuan.wang@nxp.com	Second internal review version.
Rev 2.1	2019.08.01	Yunchuan.wang@nxp.com	Release version, corrected typos and ambiguous content.
Rev 2.2	2019.08.08	Yunchuan.wang@nxp.com	Updated secure boot related content.

1. Introduction

The S32K1xx series MCU's CSEc module is a hardware cryptographic module, officially named Cryptographic Service Engine – Compressed. It complies with the HIS-SHE specification 1.1 rev 439 and GM-SHE+ safety standards. This document does not provide an introduction to these specifications themselves; please refer to the relevant protocol specifications for more details.

The CSEc hardware cryptographic module (hereinafter referred to as CSEc module) in the S32K1xx series MCUs is widely used in automotive electronic systems. Below are five typical applications:

Mileage Data Protection: Before storing mileage data, it is encrypted using the CSEc module and then stored in devices like EEPROM or Flash. When needed, this encrypted data is retrieved and decrypted by the CSEc module, thus protecting important data such as mileage.
Vehicle Anti-theft: The CSEc module's true random number and encryption/decryption functions can be used to implement a simple vehicle anti-theft function. When any device attempts to start the vehicle, it requires the CSEc module to generate a random number, encrypt it with a mutually known key, and send it to the vehicle. Only when the correct key is used can the vehicle decrypt the correct data, thus achieving anti-theft.
Electronic Component Verification and Protection: The CSEc module has a unique 15-byte UID (Unique ID) embedded within it. This UID can be used to achieve protection and verification of automotive electronic components, preventing unauthorized devices from accessing the vehicle and also preventing the illegal outflow of vehicle components into the aftermarket.
Firmware Update Protection: The CSEc module supports secure Flash programming by calculating the Message Authentication Code (CMAC). The application calculates the CMAC value of the received firmware data and compares it with the CMAC value calculated offline to verify each program block that needs updating. The comparison will only match if the same key is used for CMAC calculation. For details, please refer to Application Note AN4235-Using CSE to protect your application via a circle of trust.
Secure Communication Protection: When a central ECU (Electronic Control Unit) needs to communicate with any other ECU, the central ECU sends a random number generated by its CSEc module to another ECU. The other ECU receives the random number, encrypts it along with the data, and sends the encrypted message back to the central ECU. The central ECU decrypts the received data and compares the received random number with the previously generated one to verify its correctness. Random numbers can prevent replay attacks, and communication encryption can prevent communication eavesdropping, thus the entire mechanism ensures data integrity and authenticity.

Before formally introducing the CSEc module of the S32K1xx series, the terms used in this document will be uniformly introduced. They will also be annotated when first appearing in the main text.

Term	Description
CSEC	Cryptographic Service Engine - Compressed
HIS	Hersteller Initiative Software
SHE	Secure Hardware Extension
AES	Advanced Encryption Standard
CMAC	Cipher-based Message Authentication Code
ECB	Electronic Code Book
CBC	Cipher Block Chaining
FTFC	Flash Memory Module of S32K1xx devices
CCOB/FCCOB	Flash Common Command Object
PRAM	Parameter space Random Access Memory
SRAM	System Random Access Memory
PGMPART	Program Partition Command
EEEPROM	Emulated Electrically Erasable Programmable Read-Only Memory
Emulated-EEPROM
RNG	Random Number Generator
PRNG	Pseudo Random Number Generator
TRNG	True Random Number Generator
SFE	Security Flag Extension

2. S32K1xx Series MCU CSEc Hardware Cryptographic Module Introduction

2.1 CSEc Hardware Cryptographic Module Function Overview

The CSEc hardware cryptographic module of the S32K1xx series MCU has the following functions:

Complies with HIS-SHE specification 1.1 rev 439 and GM-SHE+ safety standards.
Supports up to 17 user key storage locations.
Supports AES (Advanced Encryption Standard)-128 encryption and decryption algorithms.
Supports AES-128 CMAC (Cipher-based Message Authentication Code) generation and verification.
Supports ECB (Electronic Cypher Book) mode encryption and decryption.
Supports true and pseudo-random number generation.
Provides Miyaguchi-Preneel compression algorithm API.
Supports three secure boot modes:
- Sequential Boot Mode.
- Strict Sequential Boot Mode (cannot be changed after setting).
- Parallel Boot Mode.

Note: The CSEc module does not protect data and code stored in Flash. For Flash data and code encryption, please refer to the Flash security documentation.

2.2 Relationship between CSEc Module and FTFC Module

The CSEc module is integrated within the FTFC (Flash Memory Module). Both the Flash module and the CSEc module are controlled and managed by the FTFC module. The relationship between the CSEc module and the FTFC module is shown in the figure below:

[Diagram showing FTFC Core with components like Status and Control Registers, AES-128, RAM, Program Flash, FlexNVM, KEYS, CSEC, PRAM, Flash Controller, PRAM Controller, and connections to Peripheral Bridge, Interrupt, and MPU.]

The functions of the modules in the figure above are as follows:

FTFC Core: The core of the FTFC module, containing the hardware core and FTFC software algorithms.
Host Interface: The communication interface between the system and the FTFC module.
AES-128: A hardware sub-module that provides AES-128 encryption, decryption, and CMAC generation/verification algorithms.
RAM (FTFC Core): A RAM area invisible to the user, used to improve the performance of FTFC Core algorithms.
Flash Controller: Provides the interface for accessing Flash. Since CSEc keys are stored in E-Flash (emulated EEPROM) and Program Flash data is verified using CMAC during secure boot, the Flash controller provides the interface for accessing Flash.
PRAM (Parameter space Random Access Memory) Controller: The communication interface between the application and the CSEc module. The application loads commands and data to the FTFC module, and the FTFC module returns operation results and data to the application through the PRAM interface.
Program Flash: Program memory, used to store application code.
FlexNVM: Configurable Flash memory. It can be configured as normal Flash memory for storing data or application code, or it can be configured as emulated EEPROM for data storage.
FlexRAM: Flexible RAM that can be configured as normal RAM, used like SRAM (System Random Access Memory) during program execution, or it can be configured as emulated EEPROM. Since RAM data is lost when power is off, when FlexRAM is configured as emulated EEPROM, a region in FlexNVM needs to be configured as emulated EEPROM data storage to work together with FlexRAM. When writing and reading data, hardware automatically synchronizes FlexRAM and FlexNVM emulated EEPROM data by operating on RAM.

Using the Host Interface, the partition operation command PRGPART (Program Partition Command) of the FTFC module can be used to allocate the size of emulated EEPROM according to user needs, including the size of emulated EEPROM in FlexRAM and FlexNVM. Executing FTFC commands is done through the FCCOB (Flash Common Command Objects) register.

2.3 CSEc Module Key Details

This section provides a detailed introduction to the CSEc module keys, mainly covering key types, key IDs, key counters, and key attributes.

2.3.1 CSEc Module Key Overview

Encryption and decryption keys are required for encryption and decryption operations. The CSEc module can store a total of 24 keys. The keys and RAM_KEY of the CSEc module are shown in the table below.

Key Name	Key ID	KBS	Storage	Key Length (Bytes)	Key Counter Length (Bits)	Key Attributes	Usage	Boot Protection	Debug Protection	Key Usage	Wildcard Protection	Factory Status	NXP Defined
Secret_Key	X	0x0	ROM	16	-	-	-	√	√	√	√	√	NXP Defined
UID	X	0x0	ROM	15	-	-	-	-	-	-	-	-	NXP Defined
MASTER_E	X	0x1	Non-Volatile	16	28	√	√	√	√	√	√	Empty
CU_KEY	X	0x2	Non-Volatile	16	28	√	√	√	√	√	√	Empty
BOOT_MA C_KEY	X	0x3	Non-Volatile	16	28	√	√	√	√	√	√	Empty
BOOT_MA C	X	0x4	Non-Volatile	16	28	√	√	√	√	√	√	Empty
KEY_01- KEY_10	0x4- 0xD	Non-Volatile	16	28	√	√	√	√	√	√	Empty
KEY_11- KEY_17	0x4- 0xA	Non-Volatile	16	28	√	√	√	√	√	√	Empty
Reserved	1'b1 0xE	-	16	-	-	-	-	-	-	-	Empty
Reserved	1'b0 0xE	-	16	-	-	-	-	-	-	Empty
RAM_KEY	X	0xF	Volatile	16	-	-	-	-	-	-	Empty

Key Name	Address	Storage Type	Length (Bytes)
PRNG_KEY	N/A	RAM	16
PRNG_STATE	N/A	RAM	16

Note: '√' indicates an available attribute.

The FTFC module provides secure and reliable storage for cryptographic keys as described in the HIS-SHE functional specification. The first five keys in the table above have dedicated functions, while the remaining keys are user keys used by the application. RAM_KEY has the attribute of a plaintext key and is used by loading the key into the RAM_KEY area when plaintext keys are needed. RAM_KEY is stored in plaintext in the RAM_KEY area. However, the RAM_KEY area is still invisible to the user. The CSEc module's keys are explained in detail below:

SECRET_KEY: A random value written during device manufacturing, its value is invisible and cannot be changed. It is used internally to derive special keys, such as the key for the pseudo-random number generator (PRNG_KEY).
UID: A unique identifier for each chip, written at the factory. This value can be queried using CSEc module commands but cannot be changed.
MASTER_ECU_KEY: Can be used as an authorization key to update all other user keys and restore the CSEc module keys to their factory state.
BOOT_MAC_KEY: Used to calculate and verify the MAC value of the Bootloader code for Secure boot functionality.

2.3.2 CSEc Module Key ID

Each key has its own identifier, the Key ID. The Key ID is composed of two parts: KBS (Key Block Number) and Key ID. When using, updating, or authorizing key updates, the CSEc module uses the Key ID to determine which key stored in the memory is to be used. Since the S32K1xx series MCU CSEc module has more keys than specified in the HIS-SHE standard, KBS is introduced to select the key block where the key is located. Using KBS and Key ID allows indexing all 17 keys.

Keys 1 to 10 are in block 0 (Bank0) area, and keys 11 to 17 are in block 1 (Bank1) area. The Key ID for key 1 is 0x04 (0x0, 0x4), and the Key ID for key 11 is 0x14 (0x1, 0x4). The upper 4 bits represent the KBS, and the lower 4 bits represent the Key ID.

2.3.3 CSEc Module Key Counter

Each user key has a 28-bit counter (Key Counter) to record each update. The counter value must be incremented each time a key is updated. This counter value is included in the calculation during key updates. If the counter value is not updated simultaneously with the key, it will result in an error.

2.3.4 CSEc Module Key Attributes

Each key has 6 configurable attributes. These attributes determine how and under what conditions the key can be used. These attributes will be used when loading and updating keys.

Write Protection (WRITE_PROT): If write protection is enabled (set to 1), the key cannot be changed again. Therefore, extreme caution must be exercised when enabling this function, as it is irreversible. Once enabled, the key cannot be changed or erased by any means, not even by restoring the CSEc module to its factory state. Furthermore, since CSEc keys are stored in the chip's emulated EEPROM, once this attribute is set, D-Flash partitioning and erasing cannot be performed (P-Flash operations are not affected). Therefore, exercise extreme caution when setting the write protection attribute!
Boot Protection (BOOT_PROT): If the Boot Protection attribute is enabled (set to 1), the key cannot be used if the MAC value calculated during the secure boot process does not match the BOOT_MAC value stored in the CSEc module. In other words, if secure boot fails, all keys marked as BOOT_PROT will remain locked (invalid) and cannot be used by the application.
Debug Port Protection (DEBUG_PROT): If the DEBUG_PROT attribute is enabled (set to 1), the key cannot be used after the next reset if a debugger is connected (or has been connected) to the MCU.

2.4 CSEc PRAM Interface Introduction

PRAM is the interface for data exchange between the CSEc module and the application, making access to the CSEc module more secure. CSEc's PRAM consists of 8 128-bit RAM pages, supporting access of one word (4 bytes) or one byte at a time.

CSEc General PRAM Interface
Bits	31:24	23:17	15:8	7:0
Word	Word 0	Word 1	Word 2	Word 3
Byte	3	2	1	0

[Diagram showing PRAM interface with fields like Page, WD, Byte, Word, and Command Specific.]

The data in Page 0 is detailed as follows: The first 6 bytes are the Command Header, followed by 10 bytes for control fields. The remaining pages are used for input/output data. When the command header is written, PRAM is locked, and the CSEc module reads the PRAM interface data to execute the input command. Therefore, before sending a CSEc command, input the data information first, then the data message length, and finally write the command header to trigger the CSEc operation.

2.4.2 Command Header (Command Header) Format Explanation

All CSEc module commands must include a 6-byte command header. The meaning of each byte in the command header is shown in the figure below:

[Diagram showing Command Header format with fields like Page 0, Func ID, Func format, CallSeq, KEYID, Error Bits, and various Func IDs and CallSeq values.]

FuncID: An 8-bit function identifier. According to the HIS-SHE command definition, it specifies the command to be executed by the CSEc module. For example, if FunID is 0x01, it means encryption operation in ECB mode. Valid values range from 0x01 to 0x16.
FuncFormat: FuncFormat specifies how data is transferred between the CSEc module and the application. A value of 0x00 means using the most common method: all data and commands are passed to the CSEc module by copying. A value of 0x01 means passing data and commands using pointers (only applicable to the two commands GENERATE_MAC and VERIFY_MAC for CMAC operations).
CallSeq: CallSeq is used when the data amount exceeds the PRAM size (128 bytes) and the data needs to be written multiple times to PRAM. It specifies whether the current data is the first write or a subsequent write. The values are as follows:

First data write: 0x00

Second to nth data write: 0x01

For example, if you need to perform CMAC verification on 128 bytes of data, since only 112 bytes of data can be passed to the CSEc block at a time (excluding the command header and message control fields in Page 0), it needs to be passed twice. In the first write, set the CallSeq field to 0x00, and in the second write, set it to 0x01. Other information must remain unchanged.

KeyID: {KBS, KeyIDx}: It is divided into two parts. KeyIDx is the value pointing to the key to be used (4 Bits), and KBS is the selection of the key block where the key is located. The bit definition is as follows:

[Table showing KeyID bit definitions.]

It should be noted here that Bits [7-5] must always be 0. Writing 1 will cause addressing errors. If KBS is not used for a specific key, the user must write 0 to Bits [4].

Error Bits: All error information will be returned in these 16 bits after the command is executed. After checking that the command execution is complete, check the error information field of these 16 bits to see if any errors occurred during execution.

2.4.3 CSEc Module Status, Error, and Interrupt Information

Before the CSEc module starts executing a command, it clears the FSTAT[CCIF] flag and sets the FSTAT[CCIF] flag upon completion. An interrupt can be generated upon completion of the CSEc module operation by setting the Flash Configuration Register (FCNFG[CCIE]).

Any errors occurring during the CSEc module command execution are recorded in the 'Error Bits' field of the command header.

The CSEc status register (FCSESTAT) of the FTFC module records the status of the CSEc module. The IDB and EDB bits are used to set whether internal and external debugging functions are enabled. The RIN bit is set during the initialization of the random number generator. The BSY bit is set when the CSEc module is executing a command. The BOK, BFN, BIN, and SB bits are specific to the secure boot function and are described in detail in section 4.5.3.2 Automatic Boot MAC Addition.

Bits	7	6	5	4	3	2	1	0
Field	IDB	EDB	RIN	BOK	BFN	BIN	SB	BSY

3. CSEc Module Application Development Explained

The previous chapters have introduced the functions and keys of the CSEc module. This chapter begins by explaining how to apply the CSEc module in an engineering project. Before using the CSEc module functions, Flash should be partitioned first, and then keys should be loaded. Loading keys is not like storing data in Flash; it requires a series of encryption calculations to ensure the security of the keys themselves.

3.1 CSEc Module Application Development Steps

The following steps should be followed when using the CSEc module:

Flash Partitioning: Since the keys used by the CSEc module are actually stored in the emulated EEPROM area (see Section 2.2 CSEc Module and FTFC Module Relationship), but this area is managed by the CSEc module to ensure key security, an EEPROM area must be allocated in D-Flash before using the CSEc module, and the CSEc key storage area must be enabled.
Loading Keys into the CSEc Module: For initial use, user keys are blank and must be loaded into the CSEc module first. Otherwise, user keys cannot be directly used for subsequent operations. It is very important to note that since CSEc keys are stored in E-Flash (emulated EEPROM) and are invisible to the user, only the CSEc module can operate on them. Therefore, once the CSEc module key storage area is enabled, D-Flash cannot be erased using Flash commands. This means that after enabling the CSEc module key storage area, D-Flash cannot be erased using any commands other than those from the CSEc module. If you need to repartition, you must use the command provided by CSEc to restore Flash (D-Flash) to its factory state.
Perform encryption/decryption, random number generation, CMAC generation/verification, etc., using the loaded keys.

3.2 CSEc Module Authorization Key Usage

To ensure key security, the HIS-SHE standard requires an authorization key to be provided before attempting to update a key. This key can be the original value of the key or the MASTER_ECU_KEY (either one is sufficient). The MASTER_ECU_KEY can serve as the authorization key for all keys and is used to operate on other keys (updating RAM_KEY does not require an authorization key). For example, the MASTER_ECU_KEY can be used as the authorization key to update BOOT_MAC_KEY, BOOT_MAC, and user keys KEY_1 to KEY_17. The authorization keys for each key are shown in the table below.

Key to be Updated	Authorization Key
	MASTER_ECU_KEY	BOOT_MAC_KEY	BOOT_MAC	KEY_<N>	RAM_KEY
MASTER_ECU_KEY	√
BOOT_MAC_KEY	√	√
BOOT_MAC	√		√
KEY_<N>	√			√
RAM_KEY					√

3.3 CSEc Module M1~M5 Calculation Method

When loading user keys into the CSEc module, the keys are not loaded directly as plaintext (except for RAM_KEY). To ensure the confidentiality, integrity, and authenticity of the keys, and to prevent replay attacks, key loading must use the protocol defined in the HIS-SHE specification (HIS-SHE Functional Specification, v1.1, 9.1 Description of memory update protocol). A series of calculations are performed on the original key to generate 5 sets of data: M1, M2, M3, M4, and M5. M1 to M3 are loaded into the CSEc module. After loading, the CSEc module returns M4 and M5. By comparing the returned M4 and M5 with the previously calculated M4 and M5, if the returned data matches the previously calculated data, it indicates that the key has been successfully loaded into the CSEc module.

Since the process of calculating M1~M5 values from the original key is irreversible, the entire process is secure. For example, if a whole vehicle manufacturer defines its own CSEc key and provides it to a supplier for development or mass production, the plaintext key cannot be disclosed. However, the M1~M5 values of the key can be calculated offline. Since the calculation process is irreversible, the supplier cannot deduce the plaintext key. This greatly prevents the leakage of the whole vehicle manufacturer's key.

4. CSEc Module Application Development Based on SDK

4.1 SDK API Introduction

This section uses the SDK3.0.0RTM version as an example to introduce the functions of some APIs in the SDK. For a detailed introduction to the APIs, please refer to Appendix 4 SDK 3.0.0RTM Version API Description.

4.2 D-Flash Partitioning API

Before using the D-Flash partitioning API, the Flash component of the SDK needs to be configured and added. After initializing the Flash, partitioning can be performed. The D-Flash partitioning APIs for the Flash module are as follows:

status_t FLASH_DRV_DEFlashPartition(const flash_ssd_config_t * pSSDConfig, uint8_t uEEEDataSizeCode, uint8_t uDEPartitionCode, uint8_t uCSEcKeySize, bool uSFE, bool flexRamEnableLoadEEEData);

The detailed parameters for the D-Flash partitioning function are shown in the table below:

Parameter Description

uEEEDataSizeCode

Configures the size of emulated EEPROM.

For MCUs with 2KB FlexRAM:
- 0x0F: Does not configure emulated EEPROM function; FlexRAM is used as system RAM.
- 0x03: Configures 2KB FlexRAM as emulated EEPROM function.
For MCUs with 4KB FlexRAM:
- 0x0F: Does not configure emulated EEPROM function.
- 0x02: Configures 4KB FlexRAM as emulated EEPROM function.

uDEPartitionCode

Configures D-Flash partitioning.

For MCUs with 128KB and 256KB P-Flash space (S32K11x series), 32KB FlexNVM:
- Partition Parameter | D-Flash Size (Kbytes) | E-Flash Size (Kbytes)
- 0x00 | 32 | 0
- 0x03 | 0 | 32
- 0x08 | 0 | 32
- 0x09 | 8 | 24
- 0x0B | 32 | 0
For MCUs with 256KB, 512KB, and 1MB P-Flash space (S32K14x series), 64KB FlexNVM:
- Partition Parameter | D-Flash Size (Kbytes) | E-Flash Size (Kbytes)
- 0x00 | 64 | 0
- 0x03 | 32 | 32
- 0x04 | 0 | 64
- 0x08 | 0 | 64
- 0x0A | 16 | 48
- 0x0B | 32 | 32
- 0x0C | 64 | 0
For MCUs with 2MB P-Flash space (S32K148), 64KB FlexNVM:
- Partition Parameter | D-Flash Size (Kbytes) | E-Flash Size (Kbytes)
- 0x00 | 64 | 0
- 0x04 | 32 | 32
- 0x0F | 0 | 64

uCSEcKeySize

Sets the number of CSEc keys:

0x00: No CSEc keys used, does not occupy emulated EEPROM space.
0x01: Uses 1 to 5 keys, occupies 128 bytes of emulated EEPROM space.
0x02: Uses 1 to 10 keys, occupies 256 bytes of emulated EEPROM space.
0x03: Uses 1 to 24 keys, occupies 512 bytes of emulated EEPROM space.

uSFE

Sets the Verify Only attribute:

0x1: Enables the Verify Only attribute configuration function for keys.
0x0: Disables the Verify Only attribute configuration function for keys.

flexRamEnableLoadEEEData

Whether to automatically load E-Flash data into FlexRAM upon MCU startup. This must be set to automatic loading mode when using the CSEc module function.

0x1: Automatically loads E-Flash data into FlexRAM upon MCU startup.
0x0: Does not automatically load E-Flash data into FlexRAM.

Using the CSEc function requires automatic loading to be enabled.

When partitioning D-Flash, the size of the emulated EEPROM backup should be at least 16 times the size of EEERAM. For more information on configuring emulated EEPROM, please refer to the chip manual and related application notes (AN11983). This document does not provide detailed information on this topic.

4.3 CSEc Module Key Management

Key management includes operations such as adding, updating, and deleting keys in the CSEc hardware module. The area where CSEc stores keys can only be accessed by the CSEc module; no other modules have access permissions.

4.3.1 Loading Keys

When using some functions of the CSEc module, keys must be loaded into the CSEc module first. Using the method described in the previous chapters, after calculating M1~M5, call the CSEc module API:

status_t CSEC_DRV_LoadKey(csec_key_id_t keyId, const uint8_t *m1, const uint8_t *m2, const uint8_t *m3, uint8_t *m4, uint8_t *m5);

Check the returned status_t to determine if the function executed successfully. Compare the returned m4 and m5 with the calculated M4 and M5. If they match, it means the key has been successfully loaded into the CSEc module. If they do not match, it indicates an error in loading the key, which may be due to an incorrect method of calculating M1~M5.

Note: If the key to be updated does not have wildcard protection (WILDCARD == 0), you can use UID=0 when generating M1~M5. Otherwise, you need to obtain the actual UID of the MCU and use it for the M1~M5 calculation. The UID value can be obtained as described in section 4.4.1 Obtain UID.

The default keys provided by the factory are blank keys (blank key), where all bits are 1. In this case, the authorization key value is also a blank key. For example, when initially adding the MASTER_ECU_KEY, use the blank key as the authorization key for addition. At all other times, the authorization key should be the current key or a non-blank MASTER_ECU_KEY.

Please refer to the Demo Project in this document for the detailed process.

4.3.2 Updating Keys

When changing a key that has already been loaded into the CSEc module, unlike loading keys, the key counter must be incremented each time a key is updated. If the key has the write protection (WRITE_PROT) attribute enabled, this key cannot be changed again. Therefore, be cautious when setting key attributes! Refer to section 2.3.4 CSEc Key Attributes.

Please refer to the Demo Project in this document for the detailed process.

4.3.3 Deleting Keys

Individual keys cannot be erased separately. Only the CSEc module's factory reset command can erase all keys. See section 4.6 Factory Reset Programming.

4.4 CSEc Module Basic Function Usage

This section introduces some basic operations of the CSEc module, such as UID retrieval, AES-128 encryption and decryption, CMAC generation and verification, and random number generation.

4.4.1 Obtain UID

The Unique Identifier (UID) is unique to each S32K1xx MCU and is written into the CSEc module at the factory. The UID is 120 bits long. During communication between ECUs, the UID can be used to confirm the uniqueness of a component. The UID is also used for resetting CSEc module keys to the factory state. The MCU's UID can be obtained using the CSE_GET_ID command or the SDK API CSEC_DRV_GetID().

However, when MASTER_ECU_KEY is blank, the obtained UID is 0. When using the CSEc module, it is recommended to load MASTER_ECU_KEY first.

4.4.2 AES-128 Encryption and Decryption

The CSEc module supports AES-128 encryption and decryption in ECB (Electronic Codebook) and CBC (Cipher Block Chaining) modes. For encryption and decryption operations, one key from the CSEc module (KEY_USAGE = 0) must be selected as the encryption/decryption key.

If no keys have been added, you can also use the CMD_LOAD_PLAIN_KEY command or API to load plaintext keys into RAM_KEY and use RAM_KEY as the key for encryption and decryption. However, this method implies potential security risks and may only be useful for development or debugging.

Since the command length is processed in page units, data length is processed in 128-bit units. If it is not met, the application should fill it. For example, when using commands like CMD_ENC_ECB, CMD_ENC_CBC, CMD_DEC_ECB, and CMD_DEC_CBC. When using the SDK, you can directly call the corresponding API.

4.4.3 Generate Random Number

PRNG derives a key for generating random numbers from SECRET_KEY and then uses the AES module to generate pseudo-random values. The RND command is used to update the PRNG state and return a 128-bit random number. The CMD_EXTEND_SEED command can be used to add a seed to the PRNG state. After each reset, the PRNG must be initialized using the CMD_INIT_RNG command. After initialization, FCSESTAT[RIN] will be set to '1'. This command uses the internal TRNG to generate a 128-bit seed for the PRNG. According to HIS-SHE specifications and AIS20 standards, PRNG uses PRNG_STATE/KEY and seeds. Use the CMD_RND command to generate random numbers.

Note: Before initializing PRNG, CMD_EXTEND_SEED, CMD_RND, and CMD_DBG_CHAL commands must be initialized. When using the SDK, you need to call the CSEC_DRV_InitRNG() API first to initialize the random number generator in the CSEc module.

4.4.4 CMAC Value Generation and Verification

The CSEc module uses the AES-128 CMAC algorithm for message authentication. Select one key from the CSEc module's keys (KEY_USAGE = 1) as the key for generating CMAC.

If no keys have been added, you can also use the CMD_LOAD_PLAIN_KEY command to load plaintext keys into RAM_KEY and use RAM_KEY as the key for CMAC operations. However, this method implies potential security risks and may be more suitable for development and debugging phases.

The CMD_VERIFY_MAC command is used to compare the calculated MAC with the input MAC value.

4.5 Secure Boot Program

The CSEc module allows users to verify boot code in Flash. By configuring the MCU, a specific piece of code (e.g., Bootloader) can be verified each time the MCU starts, ensuring that the program has not been tampered with. It should be noted that CSEc only verifies whether the data in the designated area has been tampered with. If tampering is detected, the CSEc module determines whether to interrupt program execution based on the configured secure boot mode. It can also be configured to invalidate certain keys if the CSEc module detects tampering with the code in the designated area. See section 2.3.4 CSEc Key Attributes.

4.5.1 Several Secure Boot Program Modes

The S32K1xx series processors support 3 secure boot program modes:

A. Sequential Boot Mode: After reset or power-on, the CSEc module's secure boot related code is executed first. After verification, the user code is executed according to the normal process. If verification fails, keys marked with BOOT_PROT attribute cannot be used in the user code. The application will not be interrupted.

B. Strict Sequential Boot Mode: After reset or power-on, the CSEc module's secure boot related code is executed first. After verification, the user code is executed according to the normal process. If verification fails, the CPU will remain in a reset state (the application will not continue to execute). Note: This mode setting is irreversible. Once set to Strict Sequential Boot Mode, it cannot be changed to other boot modes. Before setting this mode, the BOOT_MAC value must be calculated and stored, otherwise the device will remain in a reset state. (Automatic BOOT_MAC calculation cannot run in this mode)

C. Parallel Boot Mode: After reset or power-on, the CSEc module executes the secure boot related code, and the CPU executes the application simultaneously without affecting each other. After the secure boot verification is complete, the CSEc module sets the corresponding status register. By reading the status value, you can check whether the secure boot verification was successful. If verification fails, keys marked with BOOT_PROT attribute cannot be used in the user code. The application will not be interrupted.

Note: The secure boot function is only used to verify programs in Flash.

4.5.2 Enable Secure Boot Program

The CMD_BOOT_DEFINE command or the SDK's CSEC_DRV_BootDefine() API is used to configure the effective secure boot program mode and the size of the Boot program.

BOOT_MAC_KEY is the key used to verify the boot code. If BOOT_MAC_KEY is not added, the device will abort the secure boot process and clear the FCSESTAT[SB] bit.

Once secure boot is configured, each time the device is reset, the secure boot module calculates the MAC value of the code from address 0 to the specified end area and compares it with the BOOT_MAC stored in the CSEc module. If BOOT_MAC is blank, the CSEc module will automatically store the calculated BOOT_MAC_KEY (Section 4.5.3.2 Automatic Boot MAC Addition) and abort the current secure boot process, setting FCSESTAT[BIN] to 1.

If the calculated MAC value matches the BOOT_MAC stored in the CSEc module, FCSESTAT[BOK] will be set to 1.

After the secure boot process is complete, the application should execute the CMD_BOOT_OK command (or the SDK API CSEC_DRV_BootOK()). This sets FCSESTAT[BFN] to 1 to mark the end of the secure boot process.

In the user program, FCSESTAT[BOK] should be checked. If it is not 1, it means the code in the specified secure boot area has been tampered with. In this case, the CMD_BOOT_FAILURE command (or API CSEC_DRV_BootFailure()) should be executed to invalidate all keys in the CSEc module to ensure security. CMD_BOOT_FAILURE and CMD_BOOT_OK should be executed immediately after secure boot completion upon each power-on/reset, based on the secure boot result.

If the secure boot process is successful, the application can use all keys normally. Otherwise, all keys marked with the BOOT_PROT attribute will remain locked and cannot be used by the application.

Note: The automatic secure boot process can verify a maximum of 512KB of code. However, you can follow the 'circle of trust' method described in Application Note AN4235: use CSEc to verify the entire application code (which can be larger than 512 KB) through a circular verification method.

4.5.3 First Time Adding BOOT_MAC

The BOOT_MAC can be added to the CSEc module in two ways:

Manual addition of BOOT_MAC value.
Automatic addition of BOOT_MAC value by CSEc.

4.6 Factory Reset Programming

The HIS-SHE specification includes a mechanism to restore the security module keys to their factory state. However, this mechanism is only applicable to user keys that are not write-protected. Therefore, if any key is set with the write protection attribute, the key cannot be reset to its factory state.

The CSEc module implements this mechanism through two commands: CMD_DEBUG_CHAL and CMD_DEBUG_AUTH. However, since a random number generated by PRNG is required for this operation, PRNG must be initialized before using the CMD_DEBUG_CHAL command. The specific steps for restoring CSEc module keys to their factory state are as follows:

Request a 128-bit random number using the CMD_DBG_CHAL command.
Calculate the authorization code
- K = KDF(KEYMASTER_ECU_KEY, DEBUG_KEY_C)
- KEYMASTER_ECU_KEY: MASTER_ECU_KEY.
- KEY_UPDATE_MAC_C: 0x01035348 45008000 00000000 000000B0 (HIS-SHE specification definition).
- AUTHORIZATION = CMAC(CHALLENGE × UID).
Refer to Appendix 3 Reference Function for Calculating Recovery Authorization Code for reference code for calculating the authorization code.
Request to restore the CSEc module to its factory state using the CMD_DBG_AUTH command and the authorization code.
Reset the chip.

The CMD_DBG_CHAL command must be followed by the CMD_DBG_AUTH command. If any other command is used in between, the CMD_DBG_CHAL command must be sent again before sending the CMD_DBG_AUTH command. The same applies when using SDK APIs.

After the above operations are successful and the device is reset:

All keys are cleared.
FlexRAM is reset to normal RAM function (FCNFG[RAMRDY] == 1).
FlexNVM is reset to DFlash (FCNFG[EEERDY] == 0).

If programming using the SDK, call the CSEC_DRV_DbgChal() and CSEC_DRV_DbgAuth() APIs sequentially. Please refer to the Demo Project in this document for the detailed process.

5. Example Project Introduction

To facilitate user evaluation and use of the CSEc hardware cryptographic module functions, this document is accompanied by five example projects based on S32K1xx SDK RTM3.0.0:

Example1_Configure_part_and_Load_keys_SDK3_0_0
Example2_Update_user_keys_sdk_SDK3_0_0
Example3_Basic_operations_SDK3_0_0
Example4_secure_boot_add_BOOT_MAC_manual_SDK3_0_0
Example5_Resetting_flash_to_the_factory_state_SDK3_0_0

When using the Demo projects, you should first use Example1 to partition and load keys, and then use other CSEc module functions. If you need to restore D-Flash to factory settings using Example5, ensure that keys have been loaded into the CSEc module.

The utility functions related to the CSEc module are located in the root directory/Sources/CSEcFunctions. If you do not want to program using the SDK, you can refer to the Demo Project in document AN5401. For details, see Section 6 Reference Documents.