Industry Expert Blogs

Introduction: The Critical Role of Keys in SoC/ASIC Security

Have you ever wondered how secure critical systems, like medical devices, aerospace systems or autonomous cars, really are when it comes to data protection? One point of the answer lies in effective and robust key management. Cryptographic keys are the digital secrets underpinning device identity, data confidentiality, secure communication, and overall system trustworthiness.

Securing these keys within the hardware environment presents unique challenges, distinct from traditional IT security, due to the intersection of hardware, firmware, and software, exposing them to physical attacks and supply chain vulnerabilities. A robust key management—handling keys throughout their existence—is not just important; it's the fundamental bedrock of chip security. 

In our previous post, we provided an overview of secure SoC architecture, highlighting its critical components. This post dives deeper into one of the most critical components: Key management and its aspects within SoC ASICs: the key lifecycle, secure generation and storage, threats, and the role of standards.

---

When Keys Come Under Attack: Common Threats

Keys in SoCs face software threats and potent hardware-specific attacks that bypass conventional defenses.

Key physical attacks include:

• Side-Channel Analysis (SCA): Passively exploiting physical leakage (power consumption  EM emissions, timing) correlated with secret data. Includes Simple Power Analysis (SPA) and the more powerful Differential Power Analysis (DPA).
• Fault Injection Attacks (FIA): Actively inducing errors (voltage/clock glitching, laser, EMFI) to bypass security checks or corrupt crypto operations to leak keys.

Supply chain risks include hardware Trojans, counterfeiting/cloning, and tampering. Reverse engineering can also expose vulnerabilities. These threats demonstrate that software security alone is insufficient. Hardware-level defenses (RoT, tamper resistance, physical sensors, crypto countermeasures like masking/shuffling) are crucial.

---

The Cryptographic Key Lifecycle: A NIST Perspective

The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-57 provides foundational guidance for key management, emphasizing its criticality: "The proper management of cryptographic keys is essential... Poor key management may easily compromise strong algorithms". NIST SP 800-57 outlines  comprehensive phases of key management: 

1. Pre-Operational Phase: Key Generation & Provisioning/Distribution Creating keys using secure methods, approved algorithms, and sufficient randomness and secure distribution of keys
2. Operational Phase: Key Storage & Usage & Rotating: Protecting keys "at rest" against unauthorized access or modification, applying keys correctly for their specific, intended cryptographic purpose (encryption or signature, not both) and periodically replacing old keys with new ones.
3. Post-Operational Phase: Revocation/Destruction: Securely removing keys from use when compromised or no longer needed, ensuring they cannot be recovered.
4. Destroyed Phase: Destruction must ensure keys cannot be recovered or misused.

These stages are interconnected; failure at any point undermines the entire security framework. Generating a strong key is useless if stored insecurely. Effective key management requires a holistic strategy addressing the entire lifecycle.

Key-Management-Lifecycle

---

Pre-Operational Phase: Key Generation & Distribution/ Provisioning 

Generating Strong Roots: Keys Born Inside the Silicon

Generating cryptographic keys directly within the chip's secure boundaries minimizes exposure compared to injecting external keys. This leverages the hardware's physical properties for randomness (entropy).

Two primary hardware primitives are used:

• True Random Number Generators (TRNGs): Harvest dynamic entropy from unpredictable physical phenomena like thermal noise, shot noise, or clock jitter. TRNGs produce non-deterministic random bits crucial for seeding and cryptographic operations.
• Physically Unclonable Functions (PUFs): Exploit static entropy from uncontrollable microscopic manufacturing variations. These variations create a unique, stable "fingerprint" for each chip, generated via a challenge-response mechanism. PUFs can derive keys on demand, avoiding persistent storage in non-volatile memory (NVM).

PUF effectiveness relies on:

1. Uniqueness: Each PUF instance produces a distinct response.
2. Reliability (Stability): Consistently reproduces the same response under varying conditions and over time.
3. Unpredictability: Computationally infeasible to predict responses.

Achieving PUF reliability despite sensitivity to environmental factors and aging often requires complex error correction (ECC) or helper data schemes, adding overhead and potentially reducing entropy. PUFs also face modeling attacks (potentially using ML) aiming to predict responses. Robust PUF implementation requires careful design, balancing security benefits with costs and risks.

---

Getting Keys Onboard: The Secure Provisioning Process

Injecting initial keys and configuration data securely during manufacturing is vital, especially with complex, potentially untrusted supply chains. Insecure provisioning risks key theft, cloning, and malware insertion.

Secure methods include:

• Secure Factory Provisioning: Uses dedicated infrastructure linking factory equipment to a central key management service, often leveraging a hardware Root of Trust (RoT) within the SoC as the secure endpoint. Allows secure provisioning at various manufacturing stages.
• Device Self-Provisioning: The SoC generates its unique keys internally upon first power-up, preventing external exposure during manufacturing.

A Hardware Root of Trust (RoT) is essential in either case. The RoT is the immutable security foundation for storing critical keys, secure boot, and crypto operations. Secure provisioning is linked to SoC lifecycle management, transitioning the chip through states (e.g., 'Blank' to 'Provisioned') with increasing security restrictions, like locking key storage and debug access