Side-Channel-Angriff - Spectre, Meltdown und physische Seitenkanalangriffe - Definition & Erklärung

Side-Channel-Angriffe umgehen mathematische Sicherheit und greifen auf Informationen zu, die durch die physische Implementierung eines Systems preisgegeben werden: Zeit, Strom, Wärme, Strahlung oder Geräusche. Der Algorithmus selbst bleibt dabei unberührt.

Arten von Seitenkanälen

Timing-Angriffe: Wie lange dauert eine Operation? Die Antwortzeit verrät Rückschlüsse auf geheime Daten. Beispiel: AES mit Cache-Hits vs. Cache-Misses. Berühmtester Fall: Spectre/Meltdown (CPU-Caches).

Power Analysis:

SPA (Simple Power Analysis): Stromverbrauch direkt ablesen
DPA (Differential Power Analysis): statistisch über viele Messungen
Ziel: Private Keys aus Smartcards, HSMs, Mikrocontrollern

Elektromagnetische Analysen (EM): Ohne physischen Zugang möglich (bis ca. 1 Meter Distanz). Van-Eck-Phreaking: Bildschirminhalt aus elektromagnetischer Strahlung rekonstruieren. TEMPEST (NATO-Standard) definiert Anforderungen für EM-Abschirmung bei Hochsicherheitssystemen.

Akustische Analyse: Lüftergeräusche, Spulenfiepen, Tastaturtöne. Das Genua Paper (2013) zeigte: RSA-Key aus PC-Lüftergeräusch extrahierbar. Acoustic Cryptanalysis: 4096-Bit RSA in 1 Stunde via Mikrofon möglich.

Cache-Angriffe:

FLUSH+RELOAD: teilt Cache-Lines mit Opfer-Prozess
PRIME+PROBE: Cache-Set belegen, Aktivität messen
Rowhammer: DRAM-Bits durch häufige Zugriffe kippen → Privilege Escalation

Spectre und Meltdown

Die größten CPU-Sicherheitsschwachstellen der Geschichte wurden 2018 öffentlich bekannt.

Speculative Execution - Hintergrund

Moderne CPUs führen Instruktionen voraus aus (Spekulation). Wenn falsch spekuliert wurde, wird das Ergebnis verworfen und der CPU-Zustand zurückgesetzt - aber der Cache-Zustand bleibt! Das ermöglicht einen Timing-Seitenkanal.

Meltdown (CVE-2017-5754)

User-Space-Prozesse können Kernel-Speicher lesen. Betroffen: Intel (fast alle), ARM Cortex-A (teilweise). AMD: nicht betroffen.

Meltdown Pseudocode (vereinfacht):

// Spekulativer Zugriff auf Kernel-Adresse:
kernel_byte = *kernel_addr;  // Normal verboten! CPU führt spekulativ aus
// Timing-Kanal: cache-line basierend auf Wert laden:
dummy = array[kernel_byte * 4096];  // FLUSH+RELOAD-Technik
// CPU erkennt Zugangsfehler, wirft Spekulation zurück
// ABER: Cache ist heiß für den richtigen array-Index!
// Messung: welcher Index ist cache-warm? → kernel_byte rekonstruiert!

Patch: KPTI (Kernel Page Table Isolation) - Kernel- und User-Space-Page-Tables werden getrennt. Performance-Overhead: 5-30% je nach Workload.

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

Schwieriger zu patchen als Meltdown. Missbraucht Branch Predictor-Training. Kann andere Prozesse ausspionieren. Betrifft: Intel, AMD, ARM (viele Varianten).

Spectre Variante 1 - Bounds Check Bypass:

# Trainiere Branch Predictor:
for i in range(0, 100):
    if i < len(array):
        access(array[i])  # Trainiert Predictor: "Bedingung ist wahr"

# Angriff: out-of-bounds i:
i = secret_addr - array_base  # Außerhalb array!
if i < len(array):  # Predictor sagt JA (spekulativ!)
    access(array[array[i] * 4096])  # Spekulativer OOB-Zugriff!

Spectre-Patches: Retpoline (Return Trampolines, Google 2018), IBRS/IBPB (Indirect Branch Restricted Speculation), Microcode-Updates aller CPU-Hersteller. Performance-Impact: 2-15%.

Spectre-Varianten im Überblick

Variante	CVE	Mechanismus	Mitigation
Spectre v1	CVE-2017-5753	Bounds Check Bypass	SW-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 auf Kryptohardware

Differential Power Analysis (DPA)

Ziel: Private Key aus Smartcard, HSM oder Mikrocontroller extrahieren.

Voraussetzungen:

Physischer Zugang zur Hardware
Strommessung möglich (Shunt-Widerstand im Pfad)
Viele Messungen (typisch: 10.000-100.000)

Methode (AES-Beispiel):

10.000 Plaintexts verschlüsseln
Stromverbrauch pro Plaintext aufzeichnen
Hypothese aufstellen: Key-Byte[0] = 0x00
Hamming-Gewicht des ersten AES-SubBytes berechnen
Korrelation zwischen Hypothese und Stromkurven messen
Höchste Korrelation → richtiger Key-Byte-Wert
Für alle 16 Key-Bytes wiederholen → vollständiger AES-Key

Gegenmaßnahmen:

Masking: zufälliges Rauschen zum Zwischenwert addieren
Hiding: zufällige Delays, zufällige Operationsreihenfolge
Hardening: spezielle “constant-time” Implementierungen
Certified Hardware: Common Criteria EAL4+ (Smartcards)

Bekannte DPA-Erfolge:

DECT-Telefone (2009): Private Key in unter 1 Stunde
EMV-Kreditkarten (verschiedene Studien)
Secure Boot Keys aus Mikrocontrollern (IoT-Kontext)

Rowhammer

DRAM als Angriffsfläche

DRAM-Zellen sind so eng angeordnet, dass häufige Zugriffe Nachbar-Bits kippen können - ein Bit-Flip von 0 auf 1 oder umgekehrt in fremdem Speicher. CVE-2016-6728, Exploit “Drammer” erzielte root auf Android.

Mechanismus: Normaler DRAM-Refresh erfolgt alle 64ms. Rowhammer führt 100.000+ Zugriffe auf dieselbe Row durch und nutzt so induktive Koppelung aus.

# Rowhammer-Schleife (vereinfacht):
for _ in range(1_000_000):
    *addr_a = 1   # Zeile A hammern
    *addr_b = 1   # Zeile B hammern (beide flankieren Ziel-Row C)
    clflush(addr_a)  # Cache leeren → erzwingt DRAM-Zugriff
    clflush(addr_b)

Exploitation-Möglichkeiten:

Page Table Entry im Kernel umschreiben → Privilege Escalation
Browser (JS): Bit-Flip in JIT-Compiler-Output → Code Execution
“GLitch” (2018): GPU-Rowhammer via WebGL

Schutzmaßnahmen:

ECC RAM: korrigiert 1-Bit-Fehler (nicht ausreichend für alle Varianten!)
TRR (Target Row Refresh): Intel/AMD/Micron Refresh-Mechanismus
BIOS-Update: erhöhte Refresh-Rate
Cloudflare, Google: Rowhammer-Prüfung in Hypervisoren implementiert

Praktische Relevanz und Abwehr

Hochrisiko-Szenarien

Cloud-Umgebungen: VMs teilen CPU und DRAM mit anderen Kunden
Kryptographische Hardware: HSM, Smartcards, TPM
Browser-basierte Angriffe: Spectre über JavaScript
IoT-Geräte ohne physische Sicherheit

JavaScript/Browser - Spectre-Mitigationen

Browser haben umfangreiche Schutzmaßnahmen eingeführt:

SharedArrayBuffer deaktiviert (wird für Präzisions-Timing benötigt)
performance.now() Auflösung reduziert (5µs statt 1ns)
COOP/COEP Headers für SharedArrayBuffer Re-Aktivierung:

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

Entwickler: Constant-Time-Implementierungen

# FALSCH (timing-anfällig):
def compare_password(a, b):
    if len(a) != len(b):
        return False  # Timing-Leak: Länge wird verraten!
    for i in range(len(a)):
        if a[i] != b[i]:
            return False  # Früher Abbruch = Timing-Leak!
    return True

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

Sprachspezifische Funktionen:

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

OS/Hypervisor-Mitigationen

Linux - Status aller Mitigationen prüfen:

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

Mitigationen deaktivieren (nur für isolierte/vertrauenswürdige Systeme):

# Kernel cmdline:
mitigations=off
# Performance-Gewinn: 10-30% in I/O-intensiven Workloads

Cloud-Empfehlungen

Dedizierte Hosts (Bare Metal) für hochsensible Workloads
AMD EPYC: einige Spectre-Varianten nicht betroffen
AWS Nitro System: Hypervisor-Isolation auf Hardware-Ebene
Azure Confidential Computing (SGX/SEV-SNP): hardwarebasierte Isolation