Soc Life Cycle Security Management
Ron Keidar, Rambus, December 2020
Over the course of its life, a SoC (system on chip) goes through multiple life cycles states which are different in character, and have varying and even contradicting security requirements. In each state, the SoC is subject to a different set of possible attacks, which should all be addressed with the help of a solution that is easy to manage and track. It is the goal of Life Cycle Management to allow a strong hardware enforcement of these requirements.
Figure 1: schematic representation of the states in which a SoC may be found during his life cycle.
a. Blank – This is the initial state of the SoC. In this state, the SoC has no personalized identity and no secrets provisioned; all SoCs are the same and all test interfaces are open to allow maximum coverage of the silicon health.
Despite the lack of secrets or ID, this is a sensitive state; Intellectual Property in the silicon logic could be stolen, or the entire die could be reverse-engineered or over-produced. Therefore, transitioning to the next life cycle state is required.
b. Tested – Once tested, all hardware testing capabilities are locked and the device initiates its way into provisioning and field deployment.
At this state, the SoC gets its personalization, in which a unique ID code is written into the device’s OTP (one time programmable [memory]) or captured through an unclonable function.From this point forward, each device is unique and different, even though they were produced in the same batch and bare the identical product numbers. Now, we have traceability to track for stolen parts and over-production.
c. Provisioned – Here, unique primary keys, typically created by the silicon OEM, are provisioned into the device into a known secure area. At the end of provisioning process, the secure area is locked against further access from the outside. This state may be divided into sub-states, with the OTP split into controlled regions, each managed by a different entity in the supply chain. At any such sub-state, keys are provisioned and checked, and then that region is locked against external access (reads or writes).
So far, provisioning and life-cycle management have occurred hand-in-hand. Now, with the deployment of the device, the focus of security shifts to the protection of on-chip software and application code.
d. Mission – Until now, software developers could develop and debug their code freely. Now, with the parts deployed to the field, the device prohibits debug and enforces a Secure Boot.
In the Mission state, the application software becomes an important asset to protect. It must be proven to be owned and signed by the OEM (Authentication), unmodified (Integrity-checking) and very likely, encrypted (Confidentiality). These checks are implemented by the Secure Boot process. In addition, access to the software from the debug port must be blocked as a condition for the deployment in Mission state.
e. Re-sale – At times, chips can be re-sold, in which case ownership rights should be transitioned to the new owner. In some cases, ownership transition involves obliterating or replacing the OTP keys initially provisioned. As examples: in certain Data Center environments, the servers may be re-sold to enterprises as the Data Center acquires newer and more powerful equipment. In this case, typically the OTP needs to be cleaned up from secrets. Another example is the selling of an autonomous car to a new owner. In this case (as well as others such as laptops, cell phones and their likes), typically a ‘factory reset’ procedure must be run to clean up secrets prior to the handing to the new owner.
This state is a unique case where previous secrets are replaced in an operational situation and OTP keys are securely replaced.
f. Field Return (RMA) – This state is used whenever a malfunction is uncovered after deployment, and the device is returned to the original manufacturer to debug the malfunction. When transitioning to this state, debug is re-enabled, but secrets that can be linked to the user’s account and privacy are destroyed.
g. End of Life (Decommissioned) – Here product service comes to an end. The equipment is decommissioned altogether, and all secrets are destroyed before the device is discarded.
The procedure to transition to a new life-cycle state must be very secure. Hackers may try to physically roll back a single device to an early state to extract software and keys, or remotely try to move a device to end of life and bring the entire deployment down.
Any physical attempt to tamper with the life cycle state should cause the device to transition to the End-of-Life (EOL) state. Likewise, any remote attacks must be detected, blocked, and reported as security events. Thus, a lot of attention is needed to protect the life cycle state data.
As we can see, many security mechanisms are tightly entangled with the life cycle state. In order to keep them well orchestrated and functioning, Life Cycle Management must be centralized and easy to understand, program and follow.
Last but not least, life cycle state must be securely attested to the cloud – but this is already a whole different story…
Figure 2: Securing devices with Rambus’ CMRT
Introducing the CMRT – Rambus Security’s Crypto Manager Root-of-Trust:
The Rambus CryptoManager Root of Trust is a family of fully programmable FIPS 140-2 compliant, embedded HSM silicon IP blocks that offers layered security by design. It protects the SoC against a wide range of hardware and software attacks with state-of-the-art anti-tamper and security techniques.
Featuring a custom-designed RISC-V siloed and layered secure co-processor and dedicated secure memories, the CryptoManager Root of Trust family provides a variety of cryptographic accelerators, including all commonly used algorithms for encryption, authentication, key derivation and more. The hardware Root of Trust can also be offered as a DPA (Differential Power Analysis) protected solution, providing additional side channel attack resistance. The secure life cycle management module in the CMRT is responsible to smoothly manage the life cycle features and transitions along the life of the SoC.
Ideal for security-sensitive applications like AI/ML, automotive, and government, the CryptoManager Root of Trust is the most secure hardware root of trust available on the market.
For more information on the CMRT, look here:
Introducing Secure Provisioning and Cloud Key Management:
The CryptoManager Infrastructure complements the CMRT in enabling the secure insertion of cryptographic keys and other sensitive data throughout a distributed supply chain, including both captive and 3rd party (untrusted) manufacturing locations. CryptoManager Provisioning capabilities cover a broad range of secure operations, including key delivery and programming, protection of debug and other sensitive ports, and feature configuration for chips and devices. It supports provisioning of device-specific information to any on-chip secure enclave, including the Rambus family of CryptoManager Root of Trust cores.
We will discuss the CryptoManager Infrastructure in a subsequent blog. For now, you can find information here:
Over the course of its life, a SoC goes through multiple ownerships and multiple operative states which are different in character and have different or even contradicting security requirements. To manage the security requirements for each of the states, a centralized security design is necessary to maintain a well-orchestrated control of the device’s life while allowing a smooth understanding, programming, and monitoring of the tasks. Rambus Security’s CMRT is best equipped to allow a thorough management of the SoC’s life cycle, from production and all the way to end-of-life.
In addition to the CMRT, Rambus offers a large portfolio of Security IP and a complete provisioning solution to support the SoC manufacturing and manage its life cycle.
For more information on the Rambus Security IP offer, give me a call or visit: rambus.com/security/