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

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.