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.