ARM Security components - LCM

Origin:  https://developer.arm.com/documentation/107616/0000/Functional-description-of-the-LCM/Lifecycle-states?lang=en

LCM overview

The Arm® Lifecycle Manager (LCM) is a security component that is intended for use in Trusted Execution Environments, such as Armv8-M architectures.

The LCM is aimed at the IoT market or security subsystems that are part of infrastructure, client, or automotive markets. The LCM provides foundational security functions for the system, such as Root-of-Trust (RoT) key management, lifecycle management, and Secure debug domain control. These functions allow you to build security services such as Secure boot, Secure firmware update, attestation, Secure storage, and Secure partitioning (for example, Arm Trusted Firmware). The LCM is a critical component for a system that aims for PSA Level 2+ certification.

The LCM hardware core integrates with the hosting platform using APB3 interfaces, including manager ports and a subordinate port. Other interfaces provide more specialized functionality by indicating the current security state of the LCM to the system and controlling the system behavior. 

LCM features and assets

The LCM provides the following security features.

• Secure lifecycle states
• Persistent storage of RoT keys
• Secure export of RoT keys through the APB interface.
• Debug control and hardware feature enable signals, with properties dependent on LCS
• OTP programmer (user) partition for read and write access
• Secure provisioning for manufacturer asset provisioning in a Non-trusted environment

The LCM manages the following assets and Roots-of-Trust:

• The Secure lifecycle states, which are encoded and stored securely in the OTP memory
• The device owner’s hash of the Root of Trust Public Key (ROTPK), which is stored securely in the OTP memory
• The device Hardware Unique Key (HUK)
• The Group Unique Key (GUK)
• A set of two keys owned by the chip vendor, typically used for code encryption and provisioning
• A set of two keys owned by the Original Equipment Manufacturer (OEM) typically used for code encryption and provisioning
• General-purpose OTP flags and signals intended to be used by the chip vendor
• An RTL secret key for Secure provisioning in a Non-trusted environment
• An RTL secret mask to protect confidential fields of the OTP memory
• General-purpose OTP memory partition (code or data), which the programmer can use

Topology

The following top-level figure shows an example system that includes an LCM.

 

Figure 1. LCM top-level diagram

Abbreviations:

Lifecycle state and debug control unit

The LCM defines a set of lifecycle states (LCS). The LCM also includes a mechanism for controlling debugging capabilities and HW feature enablement, which is defined by the LCS. For more information, see Lifecycle states and Debug Control Unit.

OTP manager

The LCM includes an OTP manager that is responsible for controlling the OTP assets. The OTP manager uses the OTP APB3 manager interface that is connected to the OTP. For more information, see OTP manager.

Read Integrity Checker:

Part of the OTP manager. An engine (state machine) that performs integrity checks on the fields in the OTP that are used to store keys and to determine the LCS.

Key mask

The secret OTP keys are protected using an RTL mask. For more information, see OTP keys integrity protection.

DRBG

The LCM includes a Deterministic Random Bit Generator (DRBG) that is used to generate masking values and random delay values. For more information, see DRBG module.

LCM APB3 subordinate interface

The LCM includes an APB3 subordinate interface which is used to control the LCM operations, read the LCM FSM state and the LCS, and read and write to the OTP memory. For more information, see LCM APB3 subordinate interface.

Direct key APB3 manager interface

The LCM includes a direct key APB3 manager interface that exports the LCM keys to an external peripheral for key management. For more information, see Direct key APB3 manager interface.

Clock, reset

The LCM requires a single clock input and reset signal that is controlled by the system. For more information, see Clock logic and reset signals.

　　Scan　　

The LCM supports scan cell insertion methodology for SoC DFT strategy. For more information, see Scan signals.

 

Functional description of the LCM

The LCM manages the security of the device by using security modes and states to control its behavior and its debug control capabilities.

The chip vendor first defines the Test or Production Mode (TP mode) of the device, depending on whether the device is intended for testing purposes (TCI TP mode) or is part of a fully secured production batch (PCI TP mode).

The LCM uses lifecycle states (LCS) to control which features of the device are enabled during the various stages of its life. The chip vendor and the OEM can use Secure provisioning to load their secret keys to the LCM during Chip Manufacturing (CM) LCS and Device Manufacturing (DM) LCS. In Secure Enable LCS Secure provisioning is disabled. Debug features are also disabled in SE LCS, unless the the device is in TCI TP mode. The LCM also includes a Return Merchandise Authorization (RMA) LCS, which is a terminal state for devices that are returned to the manufacturer for analysis of fatal errors.

Within the lifecycle states, the LCM Finite State Machine (FSM) uses Reset, Ready, and Fatal Error FSM states to control the behavior of the LCM depending on its internal state and whether any errors have been detected.

The following figure shows the relationships between the security modes and states.

Figure 1. LCM security modes and states

The following figure shows a simplified lifetime flow for a device which includes the LCM. At any point in the lifetime of the device, the LCS can be changed to RMA LCS.

Figure 2. LCM simplified flow

To protect the assets and hardware keys stored in the OTP memory when the device is in PCI TP mode, the LCM uses OTP masking. Keys stored in the OTP memory are further protected with built-in integrity checking functionality.

 

 

Lifecycle states

The LCM defines four Lifecycle States (LCS). The lifecycle states enable the device (both hardware and software) to behave differently in various stages of its life, depending on whether it is in production or in the field. These changes in device behavior protect any security assets after they have been introduced into the device and reduce the risk of IP theft and reverse engineering. The lifecycle states only apply if the TP mode of the device is in Virgin, TCI, or PCI.

The lifecycle states are:

• Chip Manufacturing LCS
• Device Manufacturing LCS
• Secure Enable LCS
• Return Merchandise Authorization LCS

The following figure shows the possible transitions between the lifecycle states.

Figure 1. LCM lifecycle states

The LCM determines the LCS by reading the OTP fields immediately after reset. The LCS must not be affected by any input to LCM, other than the OTP memory-related values. The calculation of the LCS depends on the values of the following fields in OTP memory:

• CM Configuration 1
• CM Configuration 2
• DM Configuration
• CM RMA OTP flag
• DM RMA OTP flag

After the LCS is calculated according to the OTP fields, the LCM stores it in the LCS_VALUE register.

An integrity error or any invalid LCS state in the OTP memory that does not map to the CM, DM, SE, or RMA lifecycle states, causes the LCM to leave the lcs_is_valid signal deasserted and also assert the fatal_err signal. When the fatal_err signal is asserted, LCM is disabled, and the keys are invalidated and not exported.

The following table describes how the lifecycle states defined by this specification map to the PSA lifecycle states.

Table 1. LCM lifecycle states and PSA lifecycle states

LCM lifecycle state	PSA lifecycle state
Chip Manufacturing (CM)	Device Assembly and Test
Device Manufacturing (DM)	Provisioning
Secure Enable (SE)	Secured
Return Merchandise Authorization (RMA)	Decommissioned

Manufacturing test access is not blocked in the DM LCS.

 

Key Management Unit

SSE-315 uses a Key Management Unit (KMU). The KMU is a centralized function that stores symmetric key material for the distributed hardware countermeasures and for the use of software with the different crypto devices.

The KMU is a Secure only accessible device. Non-secure software must call Secure software to set or use a key. After a key slot is loaded, Secure software can lock it to prevent accidental reload or malicious overriding it.

The KMU implements hardware key slots and software key slots. The keys of the hardware key slots can only be set through a Private APB HW keys Port which connects point to point using IMPLEMENTATION DEFINED address to the Lifecycle Manager. A software or other hardware entity cannot write to this private port. Once the LCM populates the hardware key slots, software can start using them in the same way as it uses a locked software key slot.

The context of Key Management Unit, must be saved and restored (retained) over HIBERNATION0.

All signals that are driving PD_AON logic have to be latched and hold during HIBERNATION0.

The KMU interfaces integrated in SSE-315 are as follows:

• APB3 subordinate interface to program the KMU registers:

  • This interface is PPC protected, always Secure access only and the Privileged/Unprivileged access is configurable through PERIPHSPPPC1.

  • Sparse writes are not allowed and must result in error response and memory intact.

  • The programming base address is defined in the Peripheral Region.

• The direct key APB3 subordinate interface.

  • This interface is used by the LCM hardware to load hardware keys to the hardware key slots of the KMU. This interface is connected in a point-to-point fashion to the Lifecycle Manager in a way that it is not accessible to software or any other hardware.

  • The memory map exposed in the direct key APB3 subordinate port is IMPLEMENTATION DEFINED for LCM. The only registers in the KMU which are accessible through this interface are the hardware key slots.

• AHB5 Manager interface:

  • This interface is used by the KMU to export keys to the target crypto devices.

  • The transaction attributes that the KMU provides through this interface are Secure, and the Privileged is configurable through PERIPHSPPPC1.

  • Additional transaction attributes that the KMU provides through this interface are defined in Arm® Key Management Unit Specification.

  • This interface is connected to top level as a dedicated Key Management Unit Interface. Key Management Unit Interface..

• Parity Error interface. This interface is used by the KMU to generate alarm on detection of internal parity error. This signal is connected to the subsystem's Security Alarm Manager (SAM).

• Interrupt interface. This interface is used by the KMU to interrupt the software. This is connected to system Interrupts.

KMU details

Clock

KMU clock is synchronous to MGMTSYSCLK.

Power domain

KMU resides in the PD_MGMT power domain.

Reset

KMU reset is primarily nCOLDRESETMGMT. However, during Secure Asset Provisioning Flow, when LCMRSTREQ is asserted, the nWARMRESETMGMT also resets the KMU. For more details of these signals, see Reset distribution.