Modern SoC Design · 07

Security in
SoC Design

Hardware root of trust · Secure boot · TrustZone · Side-channel countermeasures · Physical Unclonable Functions · Crypto accelerators · Supply-chain security
22 slides Modern SoC Design Series ← → to navigate · Esc overview · F fullscreen
Motivation

Why Hardware Security Matters

$8TProjected global cybercrime cost 2025
~40%Attacks exploit hardware/firmware, not software alone
∞Hardware vulns often unpatchable in field

The Threat Landscape

  • Software security depends on hardware trust — if silicon is compromised, all SW protections fail
  • Side-channel attacks extract secrets without breaking algorithms (Spectre, Meltdown, power analysis)
  • Supply-chain attacks: counterfeit ICs, malicious foundry modifications, Trojan insertion
  • Physical attacks: fault injection, probing, reverse engineering of packaged die
  • AI/ML inference models are high-value IP requiring protection at inference time

Why SW-Only Security Fails

  • DRAM cold-boot: keys extracted from powered-off DRAM at −20 °C
  • DMA attacks via PCIe/Thunderbolt bypass OS memory protection
  • Hypervisor exploits: VM escape breaks confidential compute guarantees
  • Rowhammer: bit-flip via DRAM access patterns bypasses privilege separation
  • Hardware root of trust is the only reliable anchor for the chain of trust

Regulation is hardening requirements: PSA Certified, FIPS 140-3, Common Criteria EAL5+, DO-326A for avionics, and the EU Cyber Resilience Act mandate hardware security attestation for connected products.

Architecture
02

SoC Security Architecture Overview

A secure SoC is built in concentric rings of trust anchored in immutable hardware.

Hardware (immutable)

  • Root-of-Trust silicon block
  • OTP/eFuse key storage
  • True random number generator (TRNG)
  • Crypto engine (AES, SHA, RSA/ECC)

Firmware (attested)

  • Secure Boot ROM (immutable)
  • Trusted Firmware-A / OP-TEE
  • Measured boot, PCR extension
  • Secure OS / TEE runtime

Software (isolated)

  • TrustZone Secure World apps
  • Hypervisor confidential VMs
  • OS kernel, user apps (Normal World)
  • Remote attestation endpoint
Hardware Root of Trust
03

Hardware Root of Trust (HRoT)

The HRoT is a dedicated, tamper-resistant hardware block that provides the first and most fundamental layer of security. Its code and keys are immutable after manufacture.

Core Components

  • Boot ROM — factory-programmed, immutable first-stage code; measured and verified before any mutable code runs
  • OTP / eFuse array — one-time-programmable cells store device keys, lifecycle state, feature fuses
  • TRNG — entropy source for key generation; ring oscillator or shot noise based
  • Crypto engine — AES-256-GCM, SHA-2/3, RSA-4096, ECC-P384 in dedicated logic
  • Secure key vault — isolated SRAM for runtime key material; cleared on tamper detect
  • Tamper detection — voltage, frequency, temperature, and light sensors; active mesh

Lifecycle States

  • TEST — manufacturing JTAG open
  • PROVISIONING — key injection
  • PRODUCTION — debug locked
  • FIELD_RETURN — limited RMA access
  • END_OF_LIFE — irreversible brick fuse

Commercial HRoT IPs

  • Arm CryptoIsland / RSS
  • Rambus RT-630 / RT-660
  • Synopsys tRoot HSM
  • Google Titan M2
  • Apple Secure Enclave Processor
  • Microsoft Pluton
Secure Boot
04

Secure Boot & Chain of Trust

Secure boot cryptographically verifies each stage of firmware before execution, forming an unbroken chain of trust anchored in immutable hardware.

Boot Sequence Detail

  • Stage 0 — BootROM: Immutable; reads BL1 from flash, verifies ECDSA signature against OTP public key hash; no fallback
  • Stage 1 — BL1/BL2: Trusted Firmware-A first-stage; initialises DRAM, verifies BL31/BL32
  • Stage 2 — BL31: EL3 runtime firmware; sets up PSCI, SMC dispatch
  • Stage 3 — BL33: Normal world bootloader (U-Boot / UEFI); Secure World TEE (OP-TEE)

Measured vs Verified Boot

  • Verified boot — each stage halts on signature failure; enforces exact known-good images
  • Measured boot — hashes are recorded in PCRs (TPM / TEE) but execution is not blocked; enables remote attestation
  • Production systems use both: verify for policy enforcement, measure for audit
  • Rollback protection via monotonic counter in OTP; minimum version number enforced
Isolation
05

Arm TrustZone & Confidential Compute

TrustZone Fundamentals

  • Hardware-enforced CPU mode: Secure World (EL3/EL1-S/EL0-S) vs Normal World (EL2/EL1/EL0)
  • NS-bit propagated on AXI bus; interconnect and memory controllers enforce partition
  • Secure Monitor at EL3 handles world switches via SMC instruction
  • TZASC (TrustZone Address Space Controller) partitions DRAM regions
  • TZPC (TrustZone Protection Controller) marks peripherals Secure/Non-Secure
  • OP-TEE OS provides POSIX-like Trusted Application (TA) runtime in Secure World

RME: Realm Management Extension

  • Armv9 adds a 4th security state: Realm
  • Realm VMs isolated from both Secure World and Normal World hypervisor
  • Enables confidential VMs without trusting the hypervisor (CCA)
  • Four security states: Non-Secure / Secure / Root / Realm; Monitor firmware runs in Root (EL3); Realm Management Monitor (RMM) runs at R_EL2 implementing the Arm RMM Specification
Device Identity
06

Physical Unclonable Functions (PUFs)

PUFs exploit uncontrollable manufacturing variations to create a unique, unclonable device fingerprint — a hardware "DNA" that cannot be cloned even with identical masks.

How PUFs Work

  • Apply a Challenge (stimulus) → measure Response determined by random process variation
  • Same challenge always yields same response on a given device (reproducible)
  • Different devices give uncorrelated responses to same challenge (unique)
  • Response cannot be predicted without physically probing the device (unclonable)
  • Key derived from PUF eliminates storing secrets in NVM — key exists only when needed

PUF Failure Modes

  • Temperature/voltage instability → error-correcting codes (BCH, polar) required
  • Aging degrades response reliability — helper data algorithms compensate
  • Machine-learning modelling attacks on APUF with large CRP sets
  • Side-channel leakage during PUF evaluation

PUF Taxonomy

  • SRAM PUF — power-up state of SRAM cells; strong, widely deployed (Intrinsic ID SRAM PUF)
  • Ring Oscillator PUF — frequency mismatch between matched RO pairs; simple but moderate uniqueness
  • Arbiter PUF (APUF) — race condition in matched delay paths; large CRP space but ML-vulnerable
  • Butterfly PUF — bistable latch metastability; strong, FPGA-friendly
  • Oxide Breakdown PUF — irreversible; write-once identity

Key Applications

  • Device-unique key derivation (no NVM storage)
  • Anti-counterfeiting / IC authentication
  • IP protection (bitstream encryption on FPGAs)
  • Remote attestation anchor
Entropy
07

True Random Number Generators (TRNG)

Cryptographic security ultimately depends on unpredictable entropy. A compromised TRNG undermines all downstream key material.

Entropy Sources

  • Thermal noise (Johnson-Nyquist) — resistor shot noise amplified and sampled; high quality but large area
  • Ring oscillator jitter — clock jitter from process/thermal noise; compact, most common in SoCs (NIST SP 800-90B compliant)
  • Metastability harvesting — sampling SR-latch in metastable state; compact but lower throughput
  • Quantum noise — photon shot noise in reverse-biased photodiode; highest quality, rarely on-chip

TRNG Architecture

  • Raw entropy source → digitiser → health tests (NIST SP 800-90B)
  • Conditioning with SHA-3 or AES-CBC-MAC to whiten output
  • DRBG (CTR-DRBG or Hash-DRBG per NIST SP 800-90A) seeds from conditioned entropy
  • Continuous health tests detect failure: repetition count, adaptive proportion test
  • Stall or alarm on failure; never output from failed generator

Standards & Certification

  • NIST SP 800-90A/B/C — DRBG, entropy source, conditioning
  • BSI AIS 20/31 — German certification class PTG.2/PTG.3
  • FIPS 140-3 — mandatory TRNG self-test at power-on
  • CC EAL — entropy assessment for high-assurance products
// Minimal ring-oscillator TRNG cell (illustrative)
module ro_trng_cell (
  input  wire clk_sys,       // slow system clock (sampling)
  output reg  raw_bit        // raw entropy output
);
  // Free-running ring oscillator (odd number of inverters, no reset)
  (* KEEP = "TRUE" *) wire [4:0] ro;
  assign ro[0] = ~ro[4];
  genvar i;
  generate for(i=1;i<5;i=i+1) assign ro[i] = ~ro[i-1]; endgenerate
  // Sample RO with slow clock — captures jitter as LSB
  always @(posedge clk_sys) raw_bit <= ro[0];
endmodule
Crypto Hardware
08

Cryptographic Accelerator Architecture

Symmetric — AES Engine

  • 128/192/256-bit key; modes: ECB, CBC, CTR, GCM, XTS, CCM
  • Pipelined round implementation: 1 round/cycle × 10–14 rounds, or fully unrolled (1 block/cycle)
  • Key schedule hardware or pre-expanded key RAM
  • GCM requires parallel GHASH: carry-less multiply (CLMUL) in GF(2¹²⁸)
  • XTS mode for storage encryption (two AES keys, ⊕ tweak)
  • Throughput: 100 Gbps+ in TSMC N5 unrolled AES-GCM-256

Hash Engines

  • SHA-256/384/512 — 64/80 round iterative or folded pipeline
  • SHA-3/SHAKE — Keccak-f[1600] permutation; 24 rounds, 5×5×64 state
  • HMAC: H(K⊕opad ∥ H(K⊕ipad ∥ m)) — two hash passes
  • Combined AES-SHA co-processor saves DMA overhead for TLS record processing

Asymmetric — PKA Engine

  • RSA 2048–8192: Montgomery modular multiply; hardware for large-integer arithmetic
  • ECC P-256/P-384/P-521, Curve25519: point multiplication via double-and-add; constant-time essential
  • EdDSA / Ed25519: hardware point addition in twisted Edwards coordinates
  • ECDH key exchange: dominated by scalar multiplication (~10 ms SW → ~0.1 ms HW in N7)

Post-Quantum (PQC) Engines

  • FIPS 203 (ML-KEM / Kyber) — finalised 13 Aug 2024; NTT-based polynomial multiply
  • FIPS 204 (ML-DSA / Dilithium) — finalised 13 Aug 2024; lattice signature
  • FIPS 205 (SLH-DSA / SPHINCS+) — finalised 13 Aug 2024; hash-based, no lattice
  • FIPS 206 (FN-DSA / FALCON) — draft pending
  • HQC — selected March 2025 as backup KEM; draft 2026, final ~2027
  • Number Theoretic Transform (NTT) is shared accelerator primitive across ML-KEM and ML-DSA
  • Hybrid classical+PQC operation during migration period
Side-Channel Attacks
09

Side-Channel Attack Taxonomy

Side-channel attacks exploit physical information leakage rather than cryptographic weaknesses. Hardware countermeasures are essential — software alone cannot fully protect against them.

Power Analysis

  • SPA — simple power analysis; visual inspection of single trace reveals algorithm flow
  • DPA — differential power analysis; statistical correlation across many traces extracts key bits (Kocher 1999)
  • CPA — correlation power analysis; Hamming weight model improves DPA efficiency
  • Template attacks — profiling phase; near-optimal Bayesian classifier

EM & Timing

  • DEMA — differential EM analysis; local probe targets specific module; no access to power rail needed
  • Timing attacks — variable-time implementations leak secret-dependent branches (RSA square-and-multiply)
  • Cache-timing — Flush+Reload, Prime+Probe; exploits shared LLC in multi-tenant SoCs
  • Spectre/Meltdown — microarchitectural side-channels via speculative execution

Fault Injection

  • Voltage glitching — brief supply undershoot skips instructions or corrupts computation
  • Clock glitching — short/long clock pulse causes setup/hold violation
  • Laser fault injection — focused photon beam flips specific bits; precise but expensive
  • EM pulse injection (EMFI) — local coil induces transient; cheaper than laser
  • Differential fault analysis (DFA) extracts AES key from two ciphertexts with 1-byte fault
Countermeasures
10

Hardware Side-Channel Countermeasures

Power / EM Countermeasures

  • Masking — secret d split into d+1 shares; each share individually processed; XOR recombined only at output. Breaking requires correlation across all shares simultaneously (order-d DPA resistance)
  • Hiding — randomise power: random pre-charge, dual-rail logic (SABL/WDDL), constant-weight encode
  • Power supply filtering: on-die decoupling capacitors, LDO regulation before crypto core, differential power distribution
  • EM shielding: active mesh, metal-fill power guard rings, module-level metal lid

Timing & Microarchitecture

  • Constant-time implementation: no secret-dependent branches or memory addresses
  • ECC: Montgomery ladder (uniform point operations); Curve25519 by design constant-time
  • AES: bit-sliced software or hardware S-box with uniform activity
  • Cache partitioning / flushing for side-channel isolation between security domains
  • Spectre mitigations: serialising barriers, SB flush on domain switch, retpoline

Fault Injection Countermeasures

  • Voltage/frequency monitors: always-on sensors halt/reset/zeroize on out-of-spec conditions
  • Temporal redundancy: compute twice, compare; or compute-compare-compute
  • Spatial redundancy: dual-rail or TMR for critical paths (key loading, secure boot checks)
  • Error detection codes: parity on secure SRAM, ECC on crypto state registers
  • Infective computation: random errors propagate throughout to prevent DFA

Physical Security

  • Active tamper-detection mesh: fine wire grid detects probing
  • Temperature, light, and X-ray sensors trigger zeroisation
  • Metal shield layers over crypto and key storage cells
  • Passivation layer over top metal; bus scrambling in layout
  • Package-level: opaque epoxy, gravel-fill, anti-delayering treatments
Key Management
11

Secure Storage & Key Management

Key Hierarchy

  • Root key (RK) — derived from PUF or burned into OTP at provisioning; never leaves HRoT; 256-bit AES or ECC key
  • Device Identity Key (DIK) — derived from RK + device serial via HKDF; used for attestation certificates
  • Content Encryption Key (CEK) — wraps media/model IP; encrypted under KEK stored in NVM
  • Session keys — ephemeral; derived per TLS session via ECDHE; never stored
  • Key wrapping: AES-256-KeyWrap (RFC 3394) or AES-SIV for key transport between security contexts

OTP / eFuse Provisioning

  • Anti-fuse OTP: poly/diffusion breakdown; irreversible; secure against most probing
  • eFuse: electromigration blows link; cheaper but lower density
  • Typical budget: 4–16 Kbit for keys + lifecycle + feature fuses
  • Provisioned in secure facility; hash only stored (full key in HSM)
  • Redundant rows for ECC on stored key bits

Secure NVM Encryption

  • Flash encrypted with AES-XTS-256; key derived from PUF at boot
  • DRAM encryption: inline AES-128 between memory controller and PHY
  • Integrity tree (Merkle tree) over DRAM for replay and tampering detection
  • AMD SME / Intel TME: total memory encryption in x86 SoCs

Key Zeroisation

  • On tamper detect: active zeroisation of all key registers within microseconds
  • Zeroisation bus from security controller to all crypto and key-holding flip-flops
  • FIPS 140-3: demonstrated zeroisation under power loss required
  • Secure SRAM: cells scrambled and power-cycled; capacitive coupling prevents remanence
Debug Security
12

JTAG & Debug Security

JTAG/SWD interfaces are the most powerful attack vector on a produced device. Debug access must be tightly controlled without preventing legitimate failure analysis.

Attack Surface

  • JTAG boundary scan reads/writes all chip pins and internal scan chains
  • CoreSight debug port grants full CPU register, memory, and breakpoint access
  • JTAG debug allows bypassing secure boot (halt-and-modify attack)
  • Production boards with exposed test points enable probing and glitching
  • SoC debug unlock codes leaked from firmware allow persistent debug access

Secure Debug Architecture

  • Debug authentication: challenge-response using device private key; unlock token signed by OEM private key — device verifies against OEM certificate chain
  • Lifecycle-gated access: JTAG disabled in PRODUCTION lifecycle; re-enabled only after authenticated RMA unlock
  • Granular port control: secure JTAG can allow customer debug (EL0/EL1 access) without Secure World access
  • One-time debug fuse: single-use unlock; logged in OTP counter; auditable
  • Arm CoreSight authentication signals: DBGEN, NIDEN, SPIDEN, SPNIDEN

Implementation: Secure Debug Protocol (SDP)

HRoT generates a 256-bit nonce → sent to debugger → OEM signs (nonce ∥ target scope ∥ expiry) with OEM private key → token returned to device → HRoT verifies signature → asserts debug enables for granted scope only. Arm DesignStart and Rambus both supply certified SDP IP.

Peripheral Isolation
13

DMA Security & IOMMU / SMMU

The DMA Attack Problem

  • DMA masters (network, USB, PCIe, GPU) access physical memory directly, bypassing CPU MMU
  • Malicious PCIe device can scan and read all DRAM regardless of OS page tables
  • Thunderbolt DMA historically allowed complete DRAM access within seconds
  • GPU compute DMA can escape sandbox and read host memory (cross-VM leakage in CSPs)
  • DMA coherency issues create TOCTOU (time-of-check-time-of-use) vulnerabilities

Threat Scenarios

  • Rogue Thunderbolt/USB4 device: plug-in DMA attack in <60 s
  • Compromised NIC firmware reading TLS keys from host DRAM
  • PCIe ATS abuse: device-side address translation bypass
  • GPU-side DMA attacks in confidential compute environments

Arm SMMU (System MMU)

  • Intercepts all DMA transactions; provides per-device virtual address space
  • Stage-1 translation: device VA → IPA (controlled by OS driver)
  • Stage-2 translation: IPA → PA (controlled by hypervisor)
  • StreamID (RID equivalent) identifies bus master; assigned per peripheral
  • Arm SMMU v3.2: PCIe ATS/PRI support; SVA (shared virtual addressing)
  • Fault on unauthorised access: abort + interrupt; no silent data corruption

PCIe ACS & ARI

  • PCIe Access Control Services (ACS): blocks peer-to-peer DMA between endpoints
  • P2P peer-to-peer disabled unless explicitly enabled — isolates GPU↔NIC paths
  • Requester ID (RID) + PASID tag: fine-grained per-process isolation for SR-IOV VFs
  • CXL.mem confidentiality uses the Trusted Security Protocol (TSP): introduced in CXL 3.1, substantially enhanced in CXL 3.2 (Dec 2024) — essential for multi-tenant accelerator pools. CDAT describes latency/BW attributes, not security.
Memory Protection
14

Memory Encryption & Integrity

Off-chip memory (LPDDR5, HBM, NVMe) is physically accessible; inline encryption and integrity protection are essential for confidential computing and edge AI deployments.

Inline Memory Encryption

  • AES-XTS-128/256 between memory controller and PHY — transparent to CPU and DMA masters
  • XTS tweak = physical address; each 512B sector uniquely encrypted
  • AMD SME (Secure Memory Encryption): C-bit in page table enables per-page encryption
  • AMD SEV-SNP: full VM memory encrypted + integrity protected; hypervisor cannot read VM memory
  • TDISP (PCI-SIG TEE Device Interface Security Protocol): standard protocol binding accelerators to CPU TEEs (TDX, SEV-SNP, CCA) — the mechanism used by NVIDIA Blackwell Confidential Computing to attest GPU + encrypt NVLink/PCIe traffic
  • Intel TDX (Trust Domain Extensions): hardware-isolated Trust Domains with encrypted DRAM
  • HBM encryption: AXI encryption layer inside PHY straddle; no external side-channel

Memory Integrity

  • Encryption alone does not prevent replay or bitflip attacks
  • MAC tags stored alongside ciphertext (ECC bits repurposed, or separate tag DRAM)
  • Merkle tree (Counter tree) over memory blocks: root in trusted hardware; tamper-evident
  • Arity-8 tree over 4 GB DRAM requires ~67 MB metadata overhead
  • AMD SEV-SNP Reverse Map Table (RMP) maps each 4K page to owning VM; hardware-enforced
  • Tree traversal adds 2–5% latency; caching upper tree nodes reduces overhead

Storage Encryption

  • NVMe inline encryption: TCG Opal 2.0 / NVMe Base Specification §16
  • Key per namespace; hardware engine inside NVMe controller
  • eMMC/UFS: JEDEC full-device hardware encryption (RPMB secure replay-protected area)
  • Flash Translation Layer (FTL) encryption: AES-XTS with sector address tweak; wear-levelling transparent
  • Secure erase: cryptographic erase (key destruction) vs physical overwrite
Remote Attestation
15

Remote Attestation & DICE

Remote attestation allows a verifier to cryptographically confirm what software is running on a device — essential for zero-trust deployments and confidential cloud.

DICE: Device Identifier Composition Engine

  • DICE (TCG standard) provides a hardware-rooted identity that evolves with measured boot
  • UDS (Unique Device Secret) — seeded by PUF or OTP; never leaves device
  • CDI (Compound Device Identifier) — HMAC(UDS, H(firmware)) — unique per UDS+firmware combination
  • CDI seeds an asymmetric key pair; public key forms an alias certificate
  • Certificate chain: Alias Cert → DevID Cert → OEM Root CA — all bound to specific firmware measurements
  • DICE layer N passes CDI₍ₙ₎ = HMAC(CDI₍ₙ₋₁₎, H(layer_N_firmware)) up the boot chain

TPM 2.0 & fTPM

  • Discrete TPM or firmware TPM (fTPM in TrustZone Secure World / AMD PSP)
  • PCR (Platform Configuration Register) — extend-only SHA-256 register; records boot measurements
  • PCR[0] = UEFI firmware; PCR[4] = bootloader; PCR[7] = Secure Boot policy
  • Sealed storage: TPM releases secret only if PCRs match expected values
  • Remote attestation: TPM signs PCR quote with AIK (Attestation Identity Key); verifier checks against golden values

Confidential Computing Attestation

  • AMD SEV-SNP: attestation report signed by VCEK (Versioned Chip Endorsement Key) derived from chip-unique fuse + SVN
  • Intel TDX: TD Quote signed by Intel DCAP (Data Center Attestation Primitives)
  • Arm CCA: Realm attestation token signed by RMM; verified by Veraison service
  • IETF RATS architecture: Attester → Verifier → Relying Party token flow
  • IETF RATS Architecture (RFC 9334, 2023) + Entity Attestation Token (EAT) formats (CBOR/JSON); Intel Trust Authority provides managed DCAP attestation; Arm Veraison is the reference verifier for CCA tokens
Supply Chain
16

IC Supply Chain Security

The global semiconductor supply chain introduces attack surfaces at every stage — from RTL design through wafer fabrication, packaging, PCB assembly, and field deployment.

Threat Vectors

  • Hardware Trojans — malicious circuits inserted at RTL, synthesis, or mask level; activated by rare trigger conditions
  • Counterfeit ICs — recycled, remarked, or cloned chips; performance/reliability degraded
  • IP theft — RTL or GDSII stolen from design house or EDA tool server
  • Overproduction — foundry produces excess dies without OEM knowledge; grey-market sales
  • FPGA bitstream theft — bitstream cloned to clone product; IP extracted by partial readback

Trojan Detection Techniques

  • Gate-level netlist verification against trusted golden reference
  • Side-channel fingerprinting: power/timing deviation from Trojan activity
  • Formal verification of security properties post-synthesis
  • Built-In Self-Test (BIST) coverage of rare state spaces where Trojans hide
  • X-ray / SEM cross-section destructive analysis (sampling)

Counterfeit Countermeasures

  • PUF-based authentication — unique fingerprint verified at incoming inspection
  • Secure provisioning — OEM private HSM provisions unique key at secure facility; key linked to serial + PUF response
  • Monotonic counter — eFuse counter incremented on each firmware update; reused parts detected by stale counter
  • Electrical characterisation at assembly: I(V) curves reveal recycled/remarked parts
  • SEMI T20 supply chain standard; IPC-1782 traceability

Split Manufacturing

  • FEOL (transistors) at untrusted foundry; BEOL (metal interconnect) at trusted facility
  • Proximity attack vulnerability: adversary infers connections from component placement
  • Layout camouflage: indistinguishable gate styles; makes reverse engineering harder
  • Logic locking: XOR/AND key gates inserted; chip functional only with correct key loaded post-manufacture
AI / ML Security
17

Securing ML Models on SoCs

Inference SoCs deploy high-value model IP to potentially hostile environments (edge devices, shared cloud). Hardware protections are required to prevent theft, tampering, and adversarial attack.

Model IP Protection

  • Model weights represent massive training investment ($10M–$100M+); must be treated as crown-jewel IP
  • Weights encrypted at rest with AES-256-XTS on flash; decrypted inline to NPU SRAM only
  • CEK (Content Encryption Key) wrapped under device-unique key derived from PUF
  • Encrypted transfer from cloud to device: TLS + attestation-verified recipient
  • DRAM encryption prevents cold-boot extraction of weights from off-chip LPDDR/HBM

Model Integrity

  • Signed model manifest: SHA-3-256 hash over each weight tensor; ECDSA-P384 signature
  • NPU verifies manifest before loading any layer weights into execution SRAM
  • Weight poisoning attacks: adversary flips bits in stored weights to backdoor model — DRAM integrity tree detects this
  • Secure version number in OTP prevents rollback to exploitable model version
  • TEE-hosted inference for sensitive applications: Apple Private Cloud Compute model

Adversarial & Privacy Attacks

  • Model extraction — repeated black-box queries reconstruct model; rate limiting + output perturbation countermeasures
  • Membership inference — determines if a sample was in training data; differential privacy during training
  • Adversarial inputs — imperceptible perturbations cause misclassification; input pre-processing filters (feature squeezing)
  • Prompt injection — LLM jailbreaks; sandboxed inference environments on-chip
  • Secure enclaves for inference: weights and activations never in plaintext outside TEE SRAM
Interactive Demo
18

Power Analysis Attack Visualiser

Simulated DPA attack on an AES S-box implementation. Observe how correlation builds over increasing trace count.

Controls



Result

Run simulation…

Standards
19

Security Standards & Certification

FIPS 140-3

  • NIST standard for cryptographic modules; four security levels (1–4)
  • Level 2: tamper-evident coatings/seals; role-based authentication
  • Level 3: tamper-responsive with zeroisation; identity-based auth; physical protection
  • Level 4: complete physical protection envelope; operates in unprotected environment
  • Mandatory for US federal procurement; de facto global standard for HSMs
  • Testing by NVLAP-accredited labs; CMVP certificate required
  • FIPS 140-2 sunset: all existing 140-2 certificates move to Historical on 21 September 2026; new federal procurement from that date must use 140-3 validated modules. CMVP stopped accepting 140-2 submissions in 2022.

Common Criteria (CC)

  • ISO/IEC 15408; EAL 1–7 (assurance levels); Protection Profiles define product requirements
  • EAL4+: methodically designed, tested, reviewed — typical for smartcard ICs and HSMs
  • EAL5–7: semi-formally or formally verified design; required for high-security SoCs
  • PP-0084/0117: Platform Security Requirements for IoT; PP-0035: SmartCard IC
  • Mutual recognition via CCRA and SOGIS arrangements

PSA Certified

  • Arm's Platform Security Architecture framework; three levels (L1–L3)
  • L1: questionnaire-based; L2: lab-tested (independent); L3: resistance against scalable attacks
  • PSA-RoT API: standardised interface to HRoT services for OS/middleware
  • Widely adopted in IoT MCUs (STM32, nRF9160, LPC55S)

Industry Standards

  • ISO/SAE 21434 — automotive cybersecurity engineering
  • IEC 62443 — industrial control system security
  • DO-326A / ED-202A — airborne system security
  • SESIP — Security Evaluation Standard for IoT Platforms; maps to CC EAL
  • EU CRA — Cyber Resilience Act; mandatory CE marking with security requirements for all connected products
Case Studies
20

Security Architecture Case Studies

Apple Secure Enclave (SEP)

  • Dedicated ART (ARMv8.3) secure processor; fully isolated from Application Processor
  • Unique UID key fused at manufacture; inaccessible to Secure Boot firmware, Apple, or any software
  • Secure Element (SE) for payment keys (NFC); separate from SEP silicon
  • Inline AES engine between DRAM and SEP; memory encryption at full bandwidth
  • Effaceable Storage: fast cryptographic erase of NAND encryption key on "Erase All"
  • Touch ID / Face ID biometric data encrypted and only interpretable inside SEP

AMD EPYC — SEV-SNP

  • AMD Secure Processor (PSP): ARM Cortex-A5 dedicated security core on same die
  • SME: all DRAM encrypted with single key; transparent, ~0.5% performance overhead
  • SEV: per-VM DRAM encryption; hypervisor cannot read VM memory
  • SEV-SNP adds memory integrity (RMP table) and attestation; defends against hypervisor-level attacker
  • VCEK (Versioned Chip Endorsement Key): attestation signature bound to chip UID + firmware version

Google Titan M2

  • Custom RISC-V security chip on Pixel; separate from Application Processor
  • Secure boot: immutable ROM verifying Titan firmware; separate from AP boot
  • Stores Android Verified Boot keys; Pixel lock/unlock state
  • Anti-rollback: cryptographic enforcement of minimum OS version
  • Strongbox Keymaster: Android keystore backed by Titan hardware
  • FIPS 140-2 Level 2 certified; physical tamper resistance

NVIDIA H100 — Confidential Computing

  • Hopper GPU adds hardware confidential compute support (first GPU CC implementation)
  • CC mode: PCIe/NVLink traffic encrypted; GPU DRAM encrypted; attestation via NVIDIA RIM
  • Firmware attestation: GPU firmware measurements signed by NVIDIA PPCIE key
  • TEE integration: AMD SEV-SNP or Intel TDX VM can attest GPU as trusted accelerator
  • RoT: on-die GSP (GPU System Processor) acts as secure management controller
  • Blackwell (B200/B300) extends this with multi-tenant TEE isolation, TDISP/TSP integration, and encrypted NVLink 5 — enabling confidential inference at rack scale (GB200/GB300 NVL72)
Summary
21

Security in SoC Design — Key Takeaways

Hardware Foundation
  • HRoT is the non-negotiable anchor — all software security inherits trust from hardware
  • PUF-based keys eliminate NVM key storage; derived secrets exist only transiently
  • TRNG quality is fundamental — a weak entropy source undermines all cryptography
  • Secure boot chain: each stage verified before execution; measured boot enables attestation
Attack Resistance
  • Side-channel attacks require hardware countermeasures: masking, hiding, constant-time logic
  • Fault injection demands voltage/clock monitoring + temporal/spatial redundancy
  • IOMMU / SMMU essential: DMA masters are as powerful as CPUs without isolation
  • Memory encryption + integrity tree for DRAM protects against physical and software attacks
Ecosystem & Compliance
  • Debug access requires authentication protocol; lifecycle gating is non-optional in production
  • Supply chain threats are real: PUF authentication + secure provisioning defend against counterfeits and Trojans
  • FIPS 140-3 / CC EAL / PSA Certified define the certification ladder; know which your market requires
  • ML model IP protection requires hardware encryption + integrity + attestation from storage to NPU SRAM

Next: CXL in ML Accelerator SoCs — coherent memory expansion, Type 1/2/3 devices, and fabric switch architectures

Key references: NIST SP 800-90A/B · FIPS 203/204/205 · TCG DICE · Arm TrustZone / CCA · AMD SEV-SNP Architecture · Kocher et al., "Differential Power Analysis," CRYPTO 1999 · Mangard, Oswald & Popp, Power Analysis Attacks, Springer 2007

Modern SoC Design Series · Presentation 07/13 · Navigate: ← → · Overview: Esc · Fullscreen: F