Hello, I am an RSE firmware developer currently working on the Neoverse Reference Design Platform (RD-V3-R1).

I have a few questions regarding the four hardware keys stored in OTP: KCE_CM, KP_CM, KCE_DM, and KP_DM.

My understanding is based on the following documents: - Arm® Lifecycle Manager Version 1.0 Specification   (Issue 02, 107616_0000_02_en) - RD-V3-R1 reference documentation – RSE / Keys section   (https://neoverse-reference-design.docs.arm.com/en/rd-infra-2025.07.03/shared...)

According to the LCM specification, KP_CM and KP_DM are described as "Provisioning Keys". However, in the RD-V3-R1 TF-M v2.1.1 implementation, these keys do not appear to be used. Additionally, KCE_DM is documented as "DM code encryption key, currently unused".

Q1. Is it valid and compliant with the intended reference design and     specification to provision KP_CM, KP_DM, and KCE_DM with dummy values?

Regarding KCE_CM:

Both the LCM specification and the RD-V3-R1 documentation describe KCE_CM as a "Code Encryption Key", but I could not find a clear specification defining which OTP assets are expected to be encrypted using this key.

In the current TF-M implementation, KCE_CM is used to encrypt: - KEY_BL2_ENCRYPTION - KEY_SECURE_ENCRYPTION - KEY_NON_SECURE_ENCRYPTION

Q2. Is KCE_CM intended to protect exactly these three items?     If so, which specification or document defines this behavior?

Q3. The LCM specification states that KCE_CM should be used for     key derivation purposes only.     However, in TF-M, KCE_CM does not appear to be used as an input to a KDF at all;      instead, it is used directly as an AES encryption key for protecting OTP-related assets.     Is this direct usage considered compliant with the intended LCM     security model, or is a product-grade implementation expected to     introduce an explicit key derivation step before using KCE_CM     for encryption?

Any clarification on the design intent would be greatly appreciated.

Thank you for your time and support.