Debug Certificate Loading Process And Constraints
In both the EH_STATE and ROT_STATE there are concepts of application configuration and debug certificates.
These are blocks of data in fixed locations which are reserved for use by the ROM. The actual usage and layout of these data blocks are different in the two states.
- EH_STATE
- In EH_STATE the application configuration is optional allowing the image to be located away from the base of flash.
- If the application configuration block is not available or not valid, the ROM boots by default from the base of flash memory if a suitable application exists there.
- The debug certificate in EH_STATE consists of a single reserved area of memory held in a single 256-byte sector of Data Flash.
- ROT_STATE
- The application configuration data is mandatory in ROT_STATE as it defines the memory locations of the various Root of Trust certificates and hence allows the RoT to be established.
- The debug certificates, if present, are stored in a reserved block of memory held in contiguous sectors of data flash.
Reserving Space for the Application Configuration Block and Debug Certificates
On RSL15, the application configuration and debug certificates are held in data flash in consecutive sectors. (Data flash in RSL15 has a sector size of 256 bytes.)
- One sector for the application configuration
- One sector for the EH_STATE debug certificate
- Ten sectors for the ROT_STATE debug certificates
Therefore, a total of 3 KB are reserved for use by the different security mechanisms.
The layout of this is shown in the "Reserved Space for Security Mechanisms" figure.
Figure: Reserved Space for Security Mechanisms
Loading Debug Certificates to a Device
When trying to debug a secure device, the initial condition is naturally that the debug port are locked; therefore some other mechanism is required in order to get the debug certificates into the device.
In normal operation, it is possible that the debug certificates could be loaded to the device via a serial port, via an over-the-air connection, or some other way specific to a users application. All these methods, however, require that the application firmware on the device is working well enough to support the transfer and storage of the certificates.
As a default mechanism, RSL15 allows the use of the Data Exchange Unit (DEU) to transfer data into and out of the device in a strictly controlled form.
This feature has been provided with the express purpose of being able to create debug developer certificates and have the packages loaded into the device in a securely managed manner.
The DEU may be used in either EH_STATE or ROT_STATE to perform the following operations:
- Retrieve the SOC ID from the device
- Load Debug Certificates to the correct location in the device depending on the EH_STATE/ROT_STATE
- Erase any debug certificate information hence re-locking the device
The Data Exchange Unit (DEU)
The DEU is explained in more detail in the Hardware Reference Manual, however for the purposes of this document it can be thought of as a secure communications channel which is managed by the hardware and ROM in the device.
It provides limited, strictly-controlled features and is not accessible outside of the ROM.
Data Exchange Flow
The DEU communication is managed by the ROM and the hardware in the device.
This is a secure channel that causes a cold reset on the first attempt to access it, hence passing control to the ROM to perform any interaction.
On completion of the interaction with the device it again causes a cold reset, allowing the ROM to re-evaluate the Root of Trust and debug requirements in the system.
In this way, no application code may access the DEU as the ROM ensures that the communication is controlled.
This process is demonstrated in the "Data Exchange Flow" figure:
Data Exchange Unit Protocols
As can be seen from the diagram above, the DEU allows a controlled interaction to take place to perform a limited number of operations.
In the general case, a sequence of commands would be provided to a device in order to perform a specific function. These are indicated in the "Loading a Debug Certificate" figure, the "Erasing a Certificate Area" figure, and the "Retrieving a Device SOC ID" figure.
Figure: Loading a Debug Certificate
Figure: Erasing a Certificate Area
