EH_STATE Security Features
Overview
Devices are delivered from manufacturing in the Energy Harvesting state (EH_STATE) by default, and hence also in the corresponding life cycle state LCS_EH.
When in LCS_EH, it is possible to implement a lightweight security model which allows the device to be locked, preventing unauthorized access to the code or stored secrets.
In order to lock a device in LCS_EH, a device must be provided with a key and the debug control unit (DCU) lock bit values. These two pieces of information combine to ensure only the required debug facilities are allowed in normal operation. At the same time, it still allows the device to be unlocked, which is achieved by providing the correct key through a defined port.
It is also possible to transition a device from LCS_EH to the more secure life cycle states by revoking the state.
When in LCS_EH, the following facilities are available:
- Configuration Updates
- Provide a key to the device allowing debug access when the device is locked.
- This is a 128-bit value, which can be unique to each device.
- Write the DCU values that specify the features available when the device is locked.
- Refer to the Arm CryptoCell-312 registers in the RSL15 Hardware Reference for the specific registers, bit positions, and values.
- Write a SOC ID to the device; this ID can be used later for identification.
- This is a 32-bit value, which can be unique to each device or made common for a family of devices.
- Provide a key to the device allowing debug access when the device is locked.
- Revocation
- Revoke the ability to use the LCS_EH, transitioning the device to the Secure life cycle model.
Locking Process
The flow chart in the "Locking Decision Process in Energy Harvesting State" figure describes the process employed when deciding how to lock a device in EH_STATE.
Locking a Device
A device is locked by ensuring that there is no access to the debug port. This is performed by the ROM during a system reset process and cannot be changed until the next system reset.
The ROM uses the contents of a specific part of the NVM to determine the state of a device. A signature word and consistency bits are used to identify whether a device is supposed to be in EH_STATE.
When in EH_STATE, the device is unlocked by default. To lock the device, a 128-bit key value must be provided, which is then stored in NVM along with some consistency bits.
On a cold boot, the ROM examines the signature word. If the device is found to be in EH_STATE, the ROM then looks for a key. If found, the key is used to determine the lock state of the device.
Properties of the key value:
- The key is a 128-bit value.
- It is not used in any cryptographic operations.
- It can be a designated value or a random sequence of bits that are known to the manufacturer.
- These bits are stored with associated consistency bits so that corruption can be detected.
- Anyone with the key can unlock the debug port of the device.
- The key can be the same value across a range of devices, or can be unique to each device. This is up to the device manufacturer to decide.
Setting the DCU Bits
To provide some finer control to the device locking process, it is possible to set individual features in the DCU to be locked or unlocked. For more details of the DCU feature, refer to the RSL15 Hardware Reference.
Due to the nature of the NVM, it is necessary to invert the DCU bits when writing to NVM. As such, we generally refer to nDCU bits.
Properties of the DCU bits:
- This is a 128-bit value, with the bits inverted.
- The inverted bits are written to the DCU registers, controlling the debug port access and other DCU-controlled features.
- These bits are stored with associated consistency bits so that corruption can be detected.
Setting the SOC ID
RSL15 provides a concept of SOC ID for EH_STATE. This is a 32-bit value which is designed to be unique for each device; however, it is an option for the SOC ID to be the same for a family of devices.
The SOC ID is designed specifically to allow a device to be identified when the debug port is locked. It is up to the device manufacturer to determine how to use it for their particular use cases.
The SOC ID can only be written when the device is unlocked. Once a device is locked, the SOC ID is readable via the data exchange unit.
By providing this feature it is possible for a device manufacturer to maintain a mapping between SOC ID and the key value written to a device. This can be used to ensure that a single key being compromised does not affect all devices.
Unlocking a Locked Device for Debug
Once a device is ready for release, the lock key is written and the device is deployed to the field with the debug port locked.
In this scenario, it is often the case that a bug or some unexpected behavior is found after deployment, and a locked device needs to be debugged. Therefore, some mechanism is needed to allow debug of a locked device.
This is a very similar process to that required when running in the ROT_STATE, so similar techniques can be used.
RSL15 provides the concept of a Data Exchange Unit (DEU), which allows some very limited interaction with the device even when the debug port is locked. Using this mechanism, it is possible to introduce a debug key to the device and then have that key control the state of the debug port. Once the debugging session has completed, the key can be erased and the device returns to the previous locked state.
To unlock the device for debugging, three pieces of information are required:
- The key to unlock the device. This must match the key stored in the device NVM; otherwise, the unlock request is ignored.
- The DCU values to be written when the device is being unlocked. This makes it possible to only unlock specific features. Refer to the RSL15 Hardware Reference for more information.
- The DCU Lock values to be written. This allows some DCU bits to be left unlocked after the boot process. Normally the DCU is locked on completion of the boot process, and application code cannot change it.
Each of these three items consist of 128-bit values.
Unlock
In general, the process of unlocking the device using the debug port consists of the following:
- Connect to the DEU, which causes a system reset allowing the ROM to manage the DEU interactions.
- Introduce the Key/DCU/Lock values to the devices; these are stored in RAM.
- Using RSLSec as described in Security Tool Support so that they can survive a system reset.
- Disconnect from the DEU; this causes another system reset, and the ROM interprets the flash contents and acts accordingly.
Relock
Erasing the debug key is very similar to unlocking the debug port using the unlock steps:
- Connect to the DEU which causes a system reset allowing the ROM to manage the DEU interactions.
- Erase the values in flash.
- Disconnect from the DEU; this causes another system reset, and the ROM interprets the flash contents and acts accordingly.
Revoking the EH_STATE
To transition from the EH_STATE to the ROT_STATE, it is necessary to invalidate the signature words held in NVM. As this is defined as one-time-programmable, it is a permanent state change that cannot be recovered from.
The NVM holds the following four items with corruption-detecting bits:
- Energy Harvesting Signature
- Lock Key
- nDCU Bits
- SOC ID
By invalidating one or all of these words, the device reverts to ROT_STATE and then follows the secure boot process. Once invalidated, the bits are unrecoverable, so this is a one-way transition.