The ROT_STATE is provided to support applications where the security of the system needs to be much stronger than in EH_STATE.
ROT_STATE Features
The ROT_STATE provides:
- A managed life cycle for devices, ensuring that only specific functionality is available in each life cycle state (LCS)
- Some features, such as debug access, are turned off by default in certain life cycle states.
- If a feature is required in a specific LCS that has been disabled, it can be granted using cryptographically secure certificates.
- A secure boot facility whereby any firmware being executed by the ROM must be cryptographically verified and authenticated
- Secure debug facilities where the debug port can only be enabled via the use of cryptographically secure certificates
- A secure storage area for assets that are used to control the LCS behavior, and includes such items as:
- The RoT hash, provisioning key, and code encryption key are specific to each RoT in the system.
- RSL15 supports two distinct Roots of Trust.
- The Root of Trust (RoT) hash value, which allows for certificate authentication (HBK0/1)
- The storage of provisioning keys, to allow secure assets to be introduced to the system (Kpicv/Kcp)
- The storage of code encryption keys, allowing code to be decrypted from flash to RAM during the ROM startup (Kceicv/Kce)
- The Hardware Unique Key (HUK), which is an identifier unique to each device
- The SOC ID is an externally visible identifier that can be used to uniquely identify the device. This is a 128-bit value derived from other properties of the device. The SOC ID can be used in two different ways, depending on the device state.
- A secure mechanism to introduce debug certificates to the system, and the ability to revoke their use
- Anti-rollback measures to ensure older software cannot be executed on the device
The ROT_STATE cannot be revoked once a device has been transitioned into it. The device cannot be reverted back to EH_STATE.
Chip Manufacture State (LCS_CM)
LCS_CM is defined as the chip manufacture state, and is the default state when the NVM is empty. In this state, the debug port is open and firmware may be loaded to the board. There is no Root of Trust programmed in the system, so applications can not yet be authenticated against a known identity. However, it is possible to ensure that they are internally consistent and have not been corrupted.
This state has features very similar to the EH_STATE/LCS_EH, but has no facility to lock the debug port yet. It is not intended for delivery to end users; it is for performing initial application debugging and testing, and allows initial provisioning of the Initial Chip Vendor (ICV) Root of Trust.
The act of provisioning the ICV (Initial Chip Vendor) data establishes the first Root of Trust in the system.
LCS_CM to LCS_DM Transition
To transition a device from LCS_CM to LCS_DM, specific information needs to be created and written to the NVM. Once this data is written, the device powers up in the device manufacture state (LCS_DM), when the device is reset.
Once the device is transitioned to LCS_DM, no further provisioning of the LCS_CM information is possible.
The following data items are required when provisioning the ICV data:
- HBK0: This is a 128-bit hash value generated by truncating to use the top 128 bits of a SHA-256 signature of an RSA public key.
- The RSA public key is used to authenticate the first key certificate in any authentication operation.
- The first key certificate is signed by the RSA private key corresponding to the public key.
- This use of an asymmetric key pair allows authentication of the key certificate provider as the owner of the key pair.
- Kpicv: This is a 128-bit AES key used when introducing secure assets to the device.
- A secure asset is any unit of data that has been encrypted using the AES key and is being provided for storage on the device in a secure manner.
- Kceicv: This is a 128-bit AES key, used when encrypting application data that needs to be decrypted to RAM prior to execution.
- RSL15 provides a mechanism to allow secure components of the system to be stored encrypted in flash, and then decrypted during the secure boot process.
In addition to these items, additional flag information and consistency bits are written to the NVM during the provisioning process.
The hardware unique key (HUK) is also calculated at this time, and stored in the NVM.
More details regarding these items are provided in Provisioning CM to DM.
Device Manufacture State (LCS_DM)
LCS_DM is defined as the device manufacture state, and is the only valid state after LCS_CM. In this state, the debug port is locked by default, and debug certificates must be provided to open the debug port. The use of debug certificates is explained in Secure RoT Resources.
It is expected in LCS_DM that the ICV Root of Trust has been programmed in the system. In this state, any application firmware being executed as part of the secure boot process must be validated and authenticated against the HBK0 identity. This state is not intended for delivery to end users. It is provided for performing initial application debugging and testing, and to allow initial provisioning of the Original Equipment Manufacturer (OEM) Root of Trust.
The act of provisioning the OEM data establishes the second Root of Trust in the system.
LCS_DM to LCS_SE Transition
This transition is very similar to the LCS_CM to LCS_DM transition and requires very similar data to be provided. In order to transition a device from LCS_DM to LCS_SE, specific information needs to be created and written to the NVM. Once this is done, the device is reset and powers up in LCS_SE. When the device has transitioned to LCS_SE, no further provisioning of the LCS_DM information is possible.
The following data items are required when provisioning the OEM data:
- HBK1: This is a 128-bit hash value generated by truncating a SHA-256 signature of an RSA public key.
- The RSA public key is used to authenticate the first key certificate in any authentication operations.
- The first key certificate is signed by the RSA private key corresponding to the public key.
- This use of an asymmetric key pair allows authentication of the key certificate provider as the owner of the key pair.
- Kcp: This is a 128-bit AES key, used when introducing secure assets to the device.
- A secure asset is any unit of data that has been encrypted using the AES key and is being provided for storage on the device in a secure manner.
- Kce: This is a 128-bit AES key, used when encrypting application data that needs to be decrypted to RAM prior to execution.
- RSL15 provides a mechanism to allow secure components of the system to be stored encrypted in flash,and then decrypted during the secure boot process.
In addition to these items, more flag information and consistency bits are written to the NVM during the provisioning process.
More details regarding these items are provided in .
Secure State (LCS_SE)
The LCS_SE or secure state is the expected state for devices being delivered to final customers. In this LCS, all debug port is locked by default and application firmware must be authenticated prior to execution. Verification or authentication failures result in the device entering a failure state and no application being executed.
The only valid life cycle transition from this state is to LCS_RMA, which requires authentication from both the ICV and OEM RoTs.
LCS_SE to LCS_RMA and LCS_DM to LCS_RMA
The transition to LCS_RMA state follows the same process, whether it originates from LCS_DM or LCS_SE. This transition is handled after the devices have been manufactured, so the process is different from the provisioning processes outlined for previous LCS transitions. When transitioning to LCS_RMA, the expectation is that the device has an issue and must be returned to the manufacturer for fault analysis.
The device could be coming from the secure state, so its firmware might not be able to be updated; in such a case, some other mechanism needs to be employed to manage the transition. Since the debug port is likely to be locked, the transition can be handled via the introduction of special debug certificates that force the LCS transition instead of unlocking the device.
The return to RMA state requires acknowledgement from both possible RoTs in the system, so two debug certificates need to be loaded: one for the ICV RoT and one for the OEM RoT.
This transition is a multi-stage process:
- RMA Debug Enable certificates need to be generated for both ICV and OEM RoTs. These each contain a reference to the current LCS which must match the device LCS.
- For each RMA Debug Enable certificate, a new RMA Debug Developer certificate needs to be created.
- The OEM RMA Debug certificate needs to be loaded to the device, and the device then reset to allow the ROM to process the certificate.
- The ICV RMA Debug certificate needs to be loaded to the device, and the device then reset to allow the ROM to process the certificate.
- At this stage the device will boot into LCS_RMA on future resets.
Return Merchandise Authorization State (LCS_RMA)
In the RMA LCS, the device is destined to be returned to the manufacturer.
- This state is irrevocable; the device must not be used when in this state.
- This state allows application firmware to be executed if it can be verified and authenticated via one of the RoTs.
- Any secret keys stored in the NVM have been erased, so it is not possible to perform any application decryption or use any secured assets.
- Debug port is opened to allow fault analysis by the manufacturer.
If a device manufacturer wishes to ensure that the application code cannot be executed in RMA, the device certificates which form the RoT verification must be erased.
If a device manufacturer wishes to ensure that the application code cannot be read, the flash memory must be erased once the device has transitioned to the RMA state.
ROT_STATE Constraints
Because of the nature of the ROT_STATE design, there are several constraints that need to be considered:
- The authentication and verification of firmware executing on the device is a fairly complex process, and as such, slows down the system’s initial boot time.
- This does not affect wakeup time from sleep modes.
- Only signed code can be executed by the ROM; if the verification or authentication fails, the ROM enters a failure state.
- The Secure Boot features are embedded in the ROM and hardware of the system; they can only be changed on a cold reset of the device.
- Therefore, it is not possible to start a debug session on an active device if the debug certificates have not already been loaded.
- Life cycle state changes can only occur on a cold reset of the system.
- The managed life cycle model ensures that once a life cycle transition has been made, it cannot be reversed.
- The managed life cycle model includes a Return to Manufacture (RMA) state. This requires authorization from all Roots of Trust in the system.
- Corruption of the LCS configuration data causes the device to revert to a locked state, where there is no access from the debug port and firmware on the device cannot be executed.
- This is an expected outcome from the security implementation.
- Management of the life cycle states using the included tools ensures that the configuration data is maintained consistently.
Roots Of Trust (RoTs)
Overview
RSL15 provides facilities to support two independent hardware Roots of Trust (RoTs).
A Root of Trust provides a secure mechanism to verify that code being executed on the device has been verified and authenticated.
- Verification involves checking that the firmware image being executed has not been corrupted. It uses a cryptographic signature to verify that the code is correct.
- Authentication involves checking that the firmware image has been provided by a trusted party, by ensuring that the key used to sign the image is actually owned by the firmware provider.
- The authentication process uses asymmetric encryption where the public key is known to the device and the private key is used to sign the image.
- In this way, the system can guarantee that the image has been signed by someone authorized to sign the firmware, and that the image has not been tampered with or corrupted.
In RSL15, the information required to enable this process is held in hardware and in the secure processing element.
- The ROM manages the boot process and ensures that an application has been signed and authenticated using assets stored in secure storage on the device.
- The ROM is immutable, hence the secure boot process can be trusted to verify the application firmware.
- The keys and other assets used to enable this process are held in NVM memory in a secure fashion, with anti-tamper detection to ensure consistency. This is achieved by the inability to overwrite ones with zeros in this area of NVM which behaves like OTP. Therefore, counting the zeros in the protected areas combined with accessing only through the secure IP block, provides anti-tamper protection.
Having the ROM manage the boot process, with immutable keys and assets ensures that the RoT is embedded in the hardware of the device. As indicated, RSL15 maintains two sets of RoT keys and assets allowing for two independent Roots of Trust. These can be enabled and used as required.
Since the specific parameters controlling the RoT are stored in NVM, these must be provisioned as part of the initial device setup. It is possible to use a single set of RoT parameters across a family of devices. Alternatively, unique parameters can be allocated to each individual device. The device manufacturer decides this based on their specific use cases.
Root of Trust: The Mechanics
In its simplest terms, the Root of Trust consists of a known protocol to follow when authenticating information, combined with some token used for proving authenticity.
This protocol is implemented by the device’s ROM and the token is stored in NVM memory—which is configured such that corruptions can be detected. This provides a high level of security for the initial application, which can then perform further validations if required.
The system uses asymmetric cryptography for the tokens, storing a representation of an RSA public key on the device. Specifically, a 128-bit hash of the public key is stored in the NVM, together with metadata to ensure that corruptions can be detected.
This public key hash is then used to verify and authenticate certificates that accompany the firmware application. The use of certificates to introduce key information is common in security, and the processes employed in ROM follow standard techniques.
Self-Signed Certificates
The device uses self-signed certificates based on an RSA key hash to authenticate and, if necessary, unencrypt assets. Such an asset could be a binary application for the device to execute, or a debug certificate provided to unlock debug functionality.
A self-signed certificate consists of four distinct parts:
- A header defining the type of the certificate, with any additional metadata the certificate provides to allow it to be understood
- A public key, used to verify the signature of the certificate
- A certificate data section containingthe information that the certificate is delivering
- A signature of the certificate, signed using a secure private key that corresponds to the public key above
By knowing the public key, it is possible to verify that the contents of the certificate have not been corrupted, and that the certificate is internally consistent.
Authenticity can be proven by verifying that the hash of the public key matches some known data. In the simplest form of a single certificate, the public key hash is compared against the hash stored in the RoT. (See the "Self-Signed Certificate Verification" figure.)
Types of Certificate
There are four types of certificate used as part of the secure boot process, each one providing a different function:
- Key certificates are used to build certificate chains, by providing a payload consisting of the hash of the public key contained in the next certificate.
- Content certificates are used to identify the secure parts of an image to be executed by the Boot ROM. These are validated and, if necessary, decrypted.
- Debug enabler certificates are provided by the owner of the Root of Trust—this could be the device manufacturer or chip manufacturer—and are used to specify the precise debug features that can be enabled by a developer. These settings can be applied to a range of devices.
- Debug certificates are used by developers to enable the allowed debug features on a specific device.
Certificate Chains
It is possible to chain certificates so that the first certificate provides information allowing subsequent certificates to be authenticated. This provides a flexible way of changing keys if one key becomes compromised.
In the ROM protocol, two or three certificates can be used in any authentication operation.
Authenticating an Application to be Executed
When an application is loaded into the device for execution by the Boot ROM, the application must be packaged with at least two certificates: a key certificate and a content certificate (see the "Two-Certificate Authentication" figure). The certificate chain can also be extended by using two key certificates and a content certificate (see the "Three-Certificate Authentication" figure).
The ROM processes each certificate in order and the application is executed only if all verification and authentication steps are valid.
Roots of Trust Summary
The establishment of a secure Root of Trust relies on the device having the public key associated with the first asymmetric key pair. As the public key itself is quite large, a truncated hash of the public key is stored on the device NVM; this is then used to authenticate the first key certificate in a chain of certificates.
Each certificate can be verified in isolation, as the public key forms part of the certificate contents; therefore, the information is available to check that the certificate is valid. Each key certificate allows the authentication of the next certificate in the chain, using the hashed public key. This ensures that the final application has been verified as original, and has been provided by an authenticated party.
|
IMPORTANT: The private keys must be kept strictly secure. |
Secure RoT Resources
Certain configuration items are required for supporting the correct operation of the Secure RoT.
These are split into three broad categories, as follows:
- Configuration items held in secure NVM storage
- Certificates and other configuration items supporting secure boot
- Certificates required to support secure debug
Understanding how these items relate to each other, and what is needed at which stage of the product life cycle, is important to your implementation of the security system.
NVM Storage
The NVM is protected by the Arm CryptoCell-312 security block; only certain parts of the NVM can be read or written at any given point in the device life cycle.
This is normally managed during device provisioning either from LCS_CM → LCS_DM, or from LCS_DM → LCS_SE.
The "Asset Storage in NVM" table describes the assets that are stored in NVM.
Additional Information
For both the ICV and OEM provisioning operations, the following items are required:
- RSA Public/Private key pair
- This forms the basis of the secure boot and secure debug processes.
- The truncated SHA-256 of the public key is stored in the HBK0/1 locations in the NVM.
- The private key is used to sign the first key certificate in the secure chain of trust.
- This RSA key pair belongs to either the ICV or OEM, and the private key must be kept secure.
- A 128-bit AES provisioning key
- This is required if any secure asset provisioning is performed.
- A 128-bit AES code encryption key
- This is required if there is any code decrypted as part of the secure boot process.
- If all code is unencrypted and executing from flash, this may be omitted.
The RSLSec tool, which is explained in detail in a later part of the document, can be used to generate all of these keys and hashes if required.
Secure Provisioning
A user may need to secure the keys and hashes before loading them to the device. For instance, if a third party is performing the provisioning of the device, it is necessary to provision it without revealing the keys to the third party. In this case, the RTL key (Krtl) can be used to securely wrap the various assets before provisioning them.
This Krtl is a common key embedded in the hardware of the device and is never visible to application firmware. This is the same key in all RSL15 devices.
|
IMPORTANT: This key value can be provided by onsemi in an encrypted form on request. |
The Krtl is only used when provisioning the devices. After provisioning, the Krtl is no longer necessary when using the device.
Application Certificates and Configuration Items
In order to configure an application for use, it must be securely signed, and appropriate key and content certificates must be provided.
RSL15 uses a proprietary format for the certificates in the Root of Trust. These are similar in content to standard X.509 certificates, but are in a more compact form, with only the core information.
Key Certificate Generation
A key certificate securely provides a public key hash for the next certificate in the chain. The next certificate might be another key certificate, or a content certificate describing an application; in either case, the process is the same.
To create a new key certificate, the following items are required:
- The RSA key pair to sign the key certificate in privacy-enhanced mail (PEM) format
- If the private key is encrypted, the password of the PEM file is also needed.
- The public key of the next certificate in the chain of trust, again in PEM format
Content Certificate Generation
A content certificate describes an application image. It defines the areas of program memory that must be verified and authenticated, and defines whether any of the application is encrypted and needs to be loaded to RAM prior to execution.
To create a new content certificate where the application, or part of the application, is stored unencrypted and executes from flash memory, the following items are required:
- The RSA key pair to sign the key certificate in PEM format
- If the private key is encrypted, the password of the PEM file is also needed.
- The image that is executed when the content certificate has been verified and authenticated
To create a new content certificate where the application is stored encrypted in flash and needs to be decrypted into RAM for execution, the following items are required:
- The RSA key pair to sign the key certificate in PEM format
- If the private key is encrypted, the password of the PEM file is also needed.
- The image that is executed when the content certificate has been verified and authenticated
- The AES key used for performing the encryption operation, with the password if required
- A mapping table to allow the translation of flash addresses to RAM, used when decrypting and loading the image
Execution of encrypted images in this way is possible, but less practical due to the relative flash and RAM sizes. Generally, the application is stored in plain text in flash and executed directly from there.
Application Signing
A secure application can be thought of as having the following components:
- A configuration block which can be used to locate the various certificates associated with the RoT
- One or two key certificates which are used to authenticate the application
- A single content certificate which is used to verify and authenticate the image being loaded
- The application image itself
All of these component parts are combined into a single load module which can be stored in the flash of the device.
The configuration block holds the base addresses of each of the key and content certificates and for the purposes of RSL15 is always stored at a fixed location in flash. The certificates and application may reside anywhere in the free flash memory.
Debug Certificates and SOC ID
In order to unlock the debug features of a device, another form of debug certificate must be presented to the ROM during system power-up.
Again, the debug certificate is verified using the RoT associated with the certificate. This makes it possible to have debug certificates with different properties provided by different owners of the RoT.
There are two forms of debug certificate used in the system, and one of each is required for enabling the debug facilities.
- Debug enabler certificate
- This certificate is specified for a distinct RoT owner, and must match the RoT owner that is specified in the first key certificate establishing the RoT.
- The debug enabler certificate is provided by the owner of the RoT and identifies the specific debug features that can be opened by a developer.
- Debug facilities are controlled by the debug control unit (DCU), and specific bits are set in the debug mask to enable those features during debug.
- The debug enabler certificate also allows the owner of the RoT to lock specific bits of the DCU so that they cannot be re-opened after the boot process has completed. This ensures that any items the ICV or OEM do not want to provide access to can be locked out regardless of the developer’s wishes.
- Debug enabler certificates are also associated with a specific LCS, and they limit the effect of the certificate to devices which are that specific LCS. This allows an enable certificate to be safely issued for LCS_DM, as it cannot be used to open a secure device.
- The debug enabler certificate is also used to specify the transition to RMA for a given device.
- This is a general certificate, applying to a range of devices that have the same RoT, so a single enabler certificate can be used with multiple discrete devices.
- Debug developer certificate
- The debug developer certificate is used to open up the debug port on a specific device.
- It references an enabler certificate, and can open up DCU bits which have not been locked by the enabler certificate.
- This allows only a subset of the features provided by the enabler certificate to be used by a developer.
- Different enabler certificates can be provided to different developers, giving them different limitations of access.
- The debug developer certificate references a device by its SOC ID.
- This is a unique value for a given device, which can be retrieved from the device to create the certificate.
As an example of the relationship between the enabler and developer certificates, consider a device that is secured, with the debug port locked.
The "Unlocking the Debug Port on a Secure Device" figure demonstrates the unlocking process:
Points to Note:
- The RoT Hash HBK0 refers to the ICV key pair used to sign the first key certificate.
- This is the same HBK ID indicated in the debug enabler certificate.
- If the RoT keys used to sign the key certificate do not match the HBK ID, the enabler certificate is invalid.
- The SOC ID of the device is used in the debug developer certificate to allow the device to unlock.
- If the SOC ID does not match, the device does not unlock.
- The debug mask applied to the device is the logical AND of the debug masks defined in the enabler certificate and the developer certificate.
- Only bits allowed by the enabler certificate can be enabled by the developer.
- The resultant mask enabled in the "Unlocking the Debug Port on a Secure Device" figure example is 0xF0F00000 0x00000000 0x00000000 0x00000000.
Secure Boot Flow
The secure boot process in ROT_STATE follows a similar structure to the boot process in EH_STATE, but adds verification and authentication steps to the flow.
Application Signing
Application signing, described in Application Signing, provides the basic components that allow the ROM to verify and authenticate the application. The flow chart in the "Secure Boot Process" figure gives a high level overview of this process.
As can be seen from the flow, any failures in the verification and authentication stages result in the device being locked and no application code being executed.
This ensures that the device only operates correctly if valid application code is loaded.
Note that the 'No' path following the "LCS Valid?" check, as shown in the "Secure Boot Process" figure, causes the system to lock up completely in situations where the security block cannot be initialized correctly or the LCS is in an invalid state.
In these situations the device has detected a corruption in the NVM, in which case the device does not have a valid configuration, or the security IP has detected some other situation that prevents the security block from being used. To prevent the exposure of secret information or incorrect application behavior, the device enters an unrecoverable error state.
Secure Debug Flow
The mechanisms for handling debug certificates are very similar to the mechanisms for handling the key and content certificates mentioned in Secure Boot Flow.
However, in this case, rather than deciding if an application is valid to be executed, the purpose of the debug certificate chain is to configure the debug port and other features governed by the Debug Control Unit (DCU).
As indicated in Secure RoT Resources, the debug certificate chain normally consists of the following:
- A key certificate which has been signed with a private key associated with a specific RoT in the system
- The key certificate is optional, as it is possible instead to sign the debug enabler certificate with the RoT private key. However, this is not recommended.
- A debug enabler certificate that identifies which specific DCU bits can be unlocked, and the LCS of the device being debugged
- A debug developer certificate that identifies the requested DCU bits being unlocked and the SOC ID of the device being debugged
The flow chart in the "Secure Debug Flow" figure shows the stages of verification debug certificate chains.
At the end of the secure debug flow, the DCU mask bits and DCU lock bits are both set to one of three conditions:
- If there are no debug certificates, the default states for the DCU Mask and lock bits are set.
- If there is a problem with the provided debug certificates, or a request to transition to LCS_RMA, the DCU mask bits are cleared and all lock bits are set.
- If there is a valid set of debug certificates, the DCU mask and lock bits are set based on the values in the certificates.
Secure Applications
Application Signing
Application signing is described in Application Signing. The Key and Content certificates are described in Types of Certificate.
Application Configuration Block
The application configuration block is a single contiguous block of memory at a fixed location in flash. For RSL15 this is located at the base of the data flash, at address 0x00158000.
The layout of the configuration block is shown in the "Application Configuration Block Layout" figure:
Where:
- Address of first key certificate
- Defines the base address of the first key certificate in a three-certificate Root of Trust chain
- If the system is using a two-certificate Root of Trust chain, this address value needs to be set to 0xFFFFFFFF.
- Address of second key certificate
- Defines the base address of the second key certificate in the Root of Trust chain
- Address of content certificate
- Defines the base address of the content certificate associated with the application
- Application start address
- Defines the start address of the application. This points to the base address of the interrupt vector table of the application so that the stack pointer and reset vector can be located.
- Initial memory configuration
- Defines the initial memory configuration being enabled by the ROM
- Only used on cold boot of the system. Defines the data written to the SYSCTRL_MEM_POWER_STARTUP and SYSCTRL_MEM_POWER_ENABLE registers. (See the RSL15 Hardware Reference for more register information.)
- Memory retention configuration
- Defines the memory retention policy the ROM needs to apply
- Only used on cold boot of the system and defines the data written to the SYSCTRL_MEM_RETENTION_CFG register.
- CRC of other fields
- Defines a CCITT CRC calculated over the other six words of the configuration block
- If this does not match the calculated CRC during power-up, the configuration block is deemed unusable.
Application Image
The application image is any valid RSL15 image that can be stored in flash on the device.
Normally it is expected to execute completely from flash. However, it is possible to store an encrypted image in flash and have the ROM decrypt it to RAM prior to execution.
At present, any application must execute wholly from flash or from RAM. There is no option to have the ROM load portions of the application to RAM for execution. If partial execution from RAM is required, this needs to be handled at the application level.