1RSE key management 2================== 3 4The RSE has a set of hardware components that act together to prevent hardware 5protected keys being disclosed to compromised software. This chain involves the 6LifeCycle Manager "LCM", the Key Management Unit "KMU", and the cryptographic 7accelerator in the integration layer of the RSE (which in reference RSE builds 8is a CryptoCell-3XX series accelerator). 9 10Hardware protected keys (henceforth "Hardware Keys") are stored in the LCM, in 11protected keyslots. On production-mode "PCI" chips these slots are write-only. 12They are protected during provisioning from disclosure by Secure Provisioning 13"SP" mode disabling debug, and the encryption with either the RTL key or the CM 14provisioning key. On boot, the LCM checks the integrity of the stored hardware 15keys by comparing the amount of zeroes with a stored zero-count which, because 16of the property of the OTP that does not allow 1-bits to be set to 0-bits, 17allows detection of any changes in the keys. If the check succeeds it exports 18the keys to the KMU over a private memory bus (one that is not accessible 19programs running on the RSE' CPU or other controllers on the main bus such as 20the DMA). 21 22The KMU has between 2 and 32 hardware keyslots, which are 256 bit (32 byte) in 23size. Between 0 and 8 of these are hardware keyslots, and correspond to the 24hardware keyslots in the LCM. These slots are filled by the key export from the 25LCM, and have their permissions preconfigured so they are not readable or 26writable by software. Software KMU keyslots (keyslots that are not defined in 27hardware as hardware keyslots) can be read and written, and then subsequently 28locked to prevent reading and writing, so that they behave like hardware 29keyslots. This allows trusted immutable firmware to set up keys for less-trusted 30later stage code, which can be used but cannot be read. KMU keyslots can be 31exported over another private bus to the cryptographic accelerator. Hardware 32keyslots can be invalidated, making them unusable until a hard reset. 33 34The cryptographic accelerator receives the key into a write-only key register, 35and then can use it to perform cryptographic operations. For the CryptoCell-3XX 36series, this is limited to AES. As with the previous stages, software cannot 37retrieve the key, only use it. Note that currently this can only be used with 38the cc3xx_rom_lib driver, not the cryptocell-312-runtime driver, as the latter 39requires modification. Note that this path is the only way to use hardware 40protected keys on the RSE, they cannot be used by software cryptographic 41libraries that require key material to be accessible by software. 42 43The RSE uses this functionality to allow key derivation (based on NIST SP800-108 44with an RSA-based PRF that can utilise the hardware keys as described above) 45from the HUK and GUK. This allows the derivation of the CCA platform attestation 46key / delegated attestation root key without allowing access to the GUK 47directly. As a further security measure, these keys are derived by ROM/OTP code, 48and the HUK and GUK are then invalidated so they cannot be used by the runtime 49firmware and BL2. 50 51-------------- 52 53*Copyright (c) 2022-2023, Arm Limited. All rights reserved.* 54
