Side-Channel-Angriff - Spectre, Meltdown und physische Seitenkanalangriffe

Side-channel attacks circumvent mathematical security and exploit information revealed by a system’s physical implementation: time, power, heat, radiation, or noise. The algorithm itself remains unaffected.

Types of Side Channels

Timing Attacks: How long does an operation take? The response time reveals insights into secret data. Example: AES with cache hits vs. cache misses. Most famous case: Spectre/Meltdown (CPU caches).

Power Analysis:

SPA (Simple Power Analysis): Directly reading power consumption
DPA (Differential Power Analysis): Statistical analysis across many measurements
Target: Private keys from smart cards, HSMs, microcontrollers

Electromagnetic Analysis (EM): Possible without physical access (up to approx. 1 meter distance). Van-Eck phreaking: Reconstructing screen content from electromagnetic radiation. TEMPEST (NATO standard) defines requirements for EM shielding in high-security systems.

Acoustic Analysis: Fan noise, coil whine, keyboard sounds. The Genoa Paper (2013) demonstrated: RSA key extractable from PC fan noise. Acoustic Cryptanalysis: 4096-bit RSA possible in 1 hour via microphone.

Cache attacks:

FLUSH+RELOAD: shares cache lines with victim process
PRIME+PROBE: populate cache set, measure activity
Rowhammer: flip DRAM bits through frequent accesses → privilege escalation

Spectre and Meltdown

The largest CPU security vulnerabilities in history were made public in 2018.

Speculative Execution - Background

Modern CPUs execute instructions in advance (speculation). If the speculation is incorrect, the result is discarded and the CPU state is reset—but the cache state remains! This enables a timing side channel.

Meltdown (CVE-2017-5754)

User-space processes can read kernel memory. Affected: Intel (almost all), ARM Cortex-A (some). AMD: not affected.

Meltdown pseudocode (simplified):

// Speculative access to kernel address:
kernel_byte = *kernel_addr;  // Normally prohibited! CPU executes speculatively
// Timing channel: load cache line based on value:
dummy = array[kernel_byte * 4096];  // FLUSH+RELOAD technique
// CPU detects access error, aborts speculation
// BUT: Cache is warm for the correct array index!
// Measurement: which index is cache-warm? → kernel_byte reconstructed!

Patch: KPTI (Kernel Page Table Isolation) - Kernel and user-space page tables are separated. Performance overhead: 5-30% depending on workload.

Spectre (CVE-2017-5753, CVE-2017-5715)

Harder to patch than Meltdown. Exploits branch predictor training. Can spy on other processes. Affects: Intel, AMD, ARM (many variants).

Spectre Variant 1 - Bounds Check Bypass:

# Train branch predictor:
for i in range(0, 100):
    if i &lt; len(array):
        access(array[i])  # Trains predictor: &quot;Condition is true&quot;

# Attack: out-of-bounds i:
i = secret_addr - array_base  # Outside the array!
if i &lt; len(array):  # Predictor says YES (speculatively!)
    access(array[array[i] * 4096])  # Speculative OOB access!

Spectre Patches: Retpoline (Return Trampolines, Google 2018), IBRS/IBPB (Indirect Branch Restricted Speculation), microcode updates from all CPU manufacturers. Performance impact: 2–15%.

Overview of Spectre Variants

Variant	CVE	Mechanism	Mitigation
Spectre v1	CVE-2017-5753	Bounds Check Bypass	Software Mitigations
Spectre v2	CVE-2017-5715	Branch Target Injection	Retpoline + Microcode
Spectre v3	= Meltdown	Rogue Data Cache Load	KPTI
SpectreRSB	-	Return Stack Buffer	Microcode
MDS (RIDL, Fallout, ZombieLoad)	2019	Microarchitectural Data Sampling	Microcode + Flush
SWAPGS	CVE-2019-1125	SWAPGS Timing	Kernel Patch

Power Analysis on Cryptographic Hardware

Differential Power Analysis (DPA)

Goal: Extract a private key from a smart card, HSM, or microcontroller.

Prerequisites:

Physical access to the hardware
Ability to measure current (shunt resistor in the path)
Many measurements (typically: 10,000–100,000)

Method (AES example):

Encrypt 10,000 plaintexts
Record power consumption per plaintext
Formulate hypothesis: Key-Byte[0] = 0x00
Calculate Hamming weight of the first AES subbyte
Measure correlation between hypothesis and power curves
Highest correlation → correct Key-Byte value
Repeat for all 16 key bytes → complete AES key

Countermeasures:

Masking: Add random noise to the intermediate value
Hiding: Random delays, random operation order
Hardening: Special "constant-time" implementations
Certified Hardware: Common Criteria EAL4+ (smart cards)

Known DPA successes:

DECT phones (2009): Private key in under 1 hour
EMV credit cards (various studies)
Secure boot keys from microcontrollers (IoT context)

Rowhammer

DRAM as a Vulnerability

DRAM cells are arranged so closely together that frequent accesses can flip neighboring bits—a bit flip from 0 to 1 or vice versa in adjacent memory. CVE-2016-6728, the "Drammer" exploit, achieved root access on Android.

Mechanism: Normal DRAM refresh occurs every 64 ms. Rowhammer performs 100,000+ accesses to the same row, thereby exploiting inductive coupling.

# Rowhammer loop (simplified):
for _ in range(1_000_000):
    *addr_a = 1   # Hammer row A
    *addr_b = 1   # Hammer row B (both flank target row C)
    clflush(addr_a)  # Flush cache → forces DRAM access
    clflush(addr_b)

Exploitation possibilities:

Overwrite page table entry in the kernel → privilege escalation
Browser (JS): Bit flip in JIT compiler output → code execution
"GLitch" (2018): GPU Rowhammer via WebGL

Protective measures:

ECC RAM: corrects 1-bit errors (not sufficient for all variants!)
TRR (Target Row Refresh): Intel/AMD/Micron refresh mechanism
BIOS update: increased refresh rate
Cloudflare, Google: Rowhammer checking implemented in hypervisors

Practical Relevance and Mitigation

High-Risk Scenarios

Cloud environments: VMs share CPU and DRAM with other customers
Cryptographic hardware: HSM, smart cards, TPM
Browser-based attacks: Spectre via JavaScript
IoT devices without physical security

JavaScript/Browser - Spectre Mitigations

Browsers have introduced extensive protective measures:

SharedArrayBuffer disabled (required for precision timing)
performance.now() resolution reduced (5µs instead of 1ns)
COOP/COEP headers for SharedArrayBuffer re-activation:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Developers: Constant-Time Implementations

# WRONG (timing-vulnerable):
def compare_password(a, b):
    if len(a) != len(b):
        return False  # Timing leak: Length is revealed!
    for i in range(len(a)):
        if a[i] != b[i]:
            return False  # Early termination = timing leak!
    return True

# CORRECT (constant-time):
import hmac
def compare_password(a, b):
    return hmac.compare_digest(a, b)  # Constant-time!

Language-specific functions:

Python: secrets.compare_digest()
Node.js: crypto.timingSafeEqual()
Java: MessageDigest.isEqual()

OS/Hypervisor Mitigations

Linux - Check status of all mitigations:

cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
# → &quot;Mitigation: Enhanced / IBRS, IBPB: conditional, RSB filling&quot;

Disable mitigations (only for isolated/trusted systems):

# Kernel command line:
mitigations=off
# Performance gain: 10–30% in I/O-intensive workloads

Cloud recommendations

Dedicated hosts (bare metal) for highly sensitive workloads
AMD EPYC: some Spectre variants not affected
AWS Nitro System: hardware-level hypervisor isolation
Azure Confidential Computing (SGX/SEV-SNP): hardware-based isolation