System Security Architecture

Overview

Modern SoCs rely on a layered security architecture where the CPU, the Hardware Security Module (HSM), cryptographic accelerators, the secure boot ROM, and the TRNG cooperate to enforce confidentiality, integrity, authenticity, and lifecycle control.

Security is not provided by a single block. It emerges from the interaction between:

• the CPU, which executes firmware and enforces policies
• the HSM, which protects keys and performs sensitive operations
• crypto accelerators, which handle high‑throughput encryption and hashing
• the TRNG, which provides entropy for key generation
• the secure boot ROM, which anchors the chain of trust
• the data path engines (e.g., MACsec), which protect high‑speed traffic

This page provides a high‑level view of how these components fit together.

High‑Level Architecture Diagram

---

Control Path vs Data Path

Security architectures distinguish two fundamental flows:

Control Path

• Commands, policies, key requests
• CPU → HSM communication
• Low bandwidth, high security
• Mailbox / dual‑port RAM interface
• Used for: key derivation, signatures, authentication, secure boot

Data Path

• High‑speed packet or stream processing
• Crypto accelerators and MACsec engines
• High bandwidth, deterministic latency
• Keys are injected once, then used internally
• Used for: AES‑GCM line‑rate, hashing pipelines, packet encryption

The HSM lives in the control path. High‑speed crypto engines live in the data path.

This separation is essential for both performance and security.

Role of the HSM in the System

The HSM is the trust anchor of the system. Its responsibilities include:

• Key derivation and key hierarchy management
• Key wrapping/unwrapping
• Secure boot signature verification
• Attestation and identity management
• Policy enforcement (who can use which key, for what, and when)
• Secure lifecycle (provisioning, rotation, revocation)
• Protection against physical and logical attacks

The HSM does not process high‑speed data streams. It protects the keys that other engines use.

Role of Crypto Accelerators

Crypto accelerators are designed for throughput, not isolation.

Typical capabilities:

• AES pipelines (ECB, CBC, CTR, GCM)
• SHA pipelines (SHA‑2, SHA‑3)
• ECC accelerators (ECDSA, ECDH)
• RSA engines
• DMA integration for zero‑copy data movement

They operate inside the data path, where performance is critical.

The HSM may internally contain some accelerators, but system‑level accelerators are separate blocks optimized for line‑rate processing.

Interaction Between CPU, HSM, and Accelerators

Communication between components follows strict rules:

CPU → HSM

• Mailbox or dual‑port RAM
• Commands, key requests, signatures
• No direct access to internal registers
• No raw key extraction

HSM → Accelerators

• Key injection
• Policy‑controlled access
• Keys never leave the secure boundary in plaintext

CPU → Accelerators

• Configuration
• Data movement via DMA
• No access to HSM secrets

Memory Isolation

• Secure vs non‑secure regions
• TrustZone‑M / TrustZone‑A
• MPU / MMU enforcement

TRNG and Entropy Flow

A secure system requires high‑quality entropy.

TRNG → HSM

• Raw entropy
• Health tests
• Conditioning (whitening, hashing)
• Seed for DRBG

HSM → System

• Session keys
• Nonces
• Random challenges

Entropy never flows directly to the CPU without validation.

Secure Boot and Firmware Trust Chain

The secure boot chain typically follows this sequence:

1. ROM
   • Immutable
   • Verifies Stage 1 using a root key (often in the HSM)
2. HSM
   • Provides root keys
   • Verifies signatures
   • Enforces anti‑rollback
3. Bootloader Stage 1
   • Verifies Stage 2
4. Bootloader Stage 2
   • Verifies OS / firmware image
5. OS / Application
   • Runs only if all previous stages are trusted

The HSM ensures that no unauthorized firmware can execute.

Example System Architecture (Simplified)

---

This diagram highlights the separation between control and data domains.

Security Domains and Isolation

A robust system security architecture enforces:

• Secure vs Non‑secure world separation
• Memory isolation (MPU/MMU)
• Bus isolation (firewalls, access control)
• Debug lockdown (JTAG/SWD restrictions)
• Anti‑tamper protections (voltage, clock, light, probing)
• Key usage policies (who can use what key, for which algorithm)

Isolation is the foundation of trust.

Typical Threats and Mitigations

Threat	Mitigation
Key extraction	HSM isolation, PUF, encrypted storage
Fault injection	Tamper sensors, redundancy, constant‑time logic
Side‑channel attacks	Masking, balancing, noise injection
Firmware compromise	Secure boot, signature verification
Replay attacks	Nonces, counters, freshness checks
Entropy manipulation	TRNG health tests, conditioning

Related Pages

• Hardware Security Modules and PUFs
• HSM Levels and Architectural Evolution
• Secure Boot and Key Management
• Anti‑Tamper and Fault Injection Protection
• Lifecycle and Provisioning Security
• Data Integrity — Overview
• Randomness & Entropy — Overview

Child Pages

• MACsec Engine and Key Hierarchy
• IPsec Engine and Key Hierarchy
• Data Integrity — Hardware Perspective
• Randomness & Entropy — Hardware Perspective
• PUF‑based Key Derivation
• Secure Debug and JTAG Lockdown
• Bus Firewalls and Memory Isolation
• DMA Security and IOMMU