Randomness & Entropy — Hardware Perspective
Overview
Cryptographic systems rely on true randomness to generate secure keys, nonces, salts, and initialization vectors. In a modern SoC, randomness is produced by a True Random Number Generator (TRNG) and conditioned by hardware logic before being consumed by:
- the HSM
- key derivation functions
- MACsec / IPsec engines
- secure boot
- attestation mechanisms
This page focuses on the hardware architecture of entropy generation, conditioning, distribution, and monitoring.
Entropy Sources in Hardware
A TRNG relies on physical phenomena that exhibit unpredictable behavior. Common entropy sources include:
1. Thermal Noise (Resistor Noise)
- Gaussian distribution
- stable and well‑understood
- widely used in silicon TRNGs
2. Ring Oscillator Jitter
- phase noise due to thermal and flicker noise
- easy to integrate in digital designs
- requires careful de‑biasing
3. Metastability (NOT a valid entropy source)
Metastability is not a true entropy source because it is:
- influenced by layout
- predictable under voltage/temperature manipulation
- vulnerable to fault injection
(As explained in the conceptual page Metastability — Why It Cannot Be Used as a True Entropy Source.)
4. Avalanche Noise
- high entropy density
- requires analog circuitry
- sensitive to aging and temperature
5. RF Noise / EM Noise
- used in specialized secure elements
- requires shielding and filtering
TRNG Architecture
A typical TRNG consists of:
Raw Entropy Capture
Digitizes the physical noise source:
- oversampling
- jitter measurement
- analog‑to‑digital conversion (for avalanche noise)
Conditioning (Whitening)
Removes bias and correlations:
- XOR folding
- Von Neumann corrector
- LFSR scramblers
- SHA‑based conditioning
- AES‑CTR DRBG as conditioner
Health Tests
Required by NIST SP 800‑90B:
- Repetition Count Test
- Adaptive Proportion Test
- Startup tests
- Continuous monitoring
If a test fails → entropy source is disabled and the HSM is notified.
Entropy Distribution Network
Once entropy is validated, it must be distributed securely to consumers:
Key consumers include:
- HSM (for KEK, SAK, IKE keys, device keys)
- MACsec engine (SAK generation)
- IPsec engine (Child SA keys)
- Secure Boot (nonce, anti‑rollback)
- Attestation logic
- Randomized memory layouts
- ASLR in secure firmware
Security requirements:
- no CPU access to raw entropy
- no debug access
- no DMA access
- no shared buffers
- no deterministic fallback
Entropy must remain inside secure hardware boundaries.
HSM Integration
The HSM is the central consumer and distributor of entropy.
HSM responsibilities:
- request entropy from TRNG
- perform key derivation (HKDF, KDFa, SP800‑108, etc.)
- wrap keys
- inject keys into crypto engines
- enforce entropy usage policies
- block CPU access to raw entropy
Entropy flow inside the HSM
The DRBG (Deterministic Random Bit Generator) ensures:
- high throughput
- uniform distribution
- forward/backward secrecy
Entropy Quality and Threats
Threats to entropy:
| Threat | Description | Mitigation |
|---|---|---|
| Bias | Non‑uniform distribution | Conditioning, whitening |
| Correlation | Predictable patterns | SHA‑based conditioning |
| Aging | Entropy source degradation | Health tests |
| Voltage/Clock Glitching | Manipulating jitter | Tamper sensors |
| Temperature attacks | Freezing or heating entropy source | Thermal monitoring |
| EM injection | Forcing deterministic behavior | Shielding, filtering |
| Side‑channel leakage | Observing entropy source behavior | Balanced logic |
Critical rule:
👉 If entropy quality drops, the HSM must stop key generation immediately.
Entropy in Crypto Pipelines
Integrity and confidentiality engines rely on entropy for:
- nonces (GCM, ChaCha20)
- IVs
- salts
- ephemeral keys (ECDH, IKE)
- replay protection randomness
- key diversification
Example: AES‑GCM Nonce Generation
If the nonce is predictable → catastrophic key recovery.
Entropy in Secure Boot
Secure Boot uses entropy for:
- anti‑rollback counters
- randomized challenges
- attestation tokens
- secure firmware updates
Entropy must be available before firmware execution begins.
Hardware Entropy vs Software RNG
| Feature | Hardware TRNG | Software RNG |
|---|---|---|
| Source | Physical noise | Algorithmic |
| Predictability | Unpredictable | Predictable if compromised |
| Throughput | Medium | High |
| Security | Strong | Depends on seed |
| Attack surface | Physical | Software/Memory |
Software RNGs are not acceptable for cryptographic key generation unless seeded by a TRNG.
