A semiconductor passport for every device
Unique identity (UID) is the identifier typically stored on each chip and an essential part of a Hardware Root of Trust.
Today, it is important to have in place a robust identification/authentication process to verify Today, networks require a robust identification/authentication process to verify data and the authenticity of each device’s identity. A UID acts as a passport for a semiconductor as it connects with a network or another device. It serves as the chip’s primary identifier and, for example, establishes an auditable trail during its journey in the supply chain that verifies its origin.
With a UID, chips can generate an internal secret as a seed for key generation or a root key and an external plaintext number for chip identification or product series number. UID can also be used as the device’s identity by authentication and authorization algorithms to protect it from unauthorized access or cloning.
Key Injection
The most frequently used process to generate a UID is key injection, which has three major steps: enrollment, authentication, and provisioning. The main goals for a UID are to uniquely identify and reliably authenticate each chip, track a chip, and create an audit trail that establishes its origin. To keep the secret UID safe, with the key injection method, an expensive security facility and a standard set of operating procedures are required to perform this process. Injected UIDs also run the risk of leaked secrets and product cloning.
Inborn Keys
An inborn UID can be derived from a PUF and is a safer alternative against identifier cloning. This is because it can complete each stage (enrollment, authentication, and provisioning) internally within the chip and doesn’t need to store secrets externally. Therefore, hardware-generated inborn UIDs eliminate the risk of exposure during the injection process. They also significantly reduce fabrication costs by eradicating the need for key injection and external key management.
The PUF-based UID is the identifier for the follow-up authentication and authorization to an external network node, e.g., the host server shown in this figure below.
