Hardware Security

A side channel is an unintended information leakage path that does not use the normal input/output interface of a system.

Characteristics:

• Non-invasive: Does not require physical modification of the hardware
• Stealthy: Hard to detect — the attacker uses normal instructions
• Hard to fix: The leakage is inherent in how hardware optimizations work (caches, branch predictors, etc.)
• Exploits shared resources between attacker and victim

Common side channels in hardware:

• Timing: Measure how long an operation takes (cache hit vs. miss, branch prediction hit vs. miss)
• Power: Measure power consumption patterns (different instructions consume different power)
• Electromagnetic: Measure EM emissions from the chip

In CS 450, we focus on timing-based microarchitectural side channels — specifically cache and memory side channels.

Cache side channels exploit the fact that cache hit/miss timing is observable and depends on what the victim has accessed.

General procedure:

1. Set cache to a known state
2. Wait for victim to execute
3. Check what changed in the cache (via timing)

Prime+Probe:

1. Prime: Attacker fills specific cache sets with their own data (accesses enough addresses to fill every way in target sets)
2. Wait: Victim runs and potentially evicts some of the attacker's data
3. Probe: Attacker re-accesses their data and times each access. If an access is slow (cache miss), the victim must have accessed that set → information leaked!

Flush+Reload: (requires shared memory, e.g., shared libraries)

1. Flush: Attacker uses clflush to evict a shared cache line
2. Wait: Victim runs
3. Reload: Attacker accesses the same line and times it. If fast (cache hit), the victim accessed it. If slow (miss), the victim didn't.

Flush+Reload has higher resolution (per cache line vs. per set) but requires shared memory pages.

The DRAMA attack exploits DRAM row buffer timing as a side channel:

• A row buffer hit is faster than a row buffer miss/conflict
• If the attacker and victim share a DRAM bank, the attacker can detect which row the victim accessed by observing row buffer hit/miss timing

Attack procedure:

1. Attacker accesses an address that maps to a specific bank and row (opens that row)
2. Victim accesses memory
3. Attacker re-accesses the same address. If fast (row hit), the victim did NOT access a different row in that bank. If slow (row conflict), the victim accessed a different row in the same bank → leaked info.

This is harder to mitigate than cache side channels because you cannot easily "flush" a row buffer, and DRAM is even more fundamental than caches.

Rowhammer is a hardware vulnerability where repeatedly activating (hammering) a DRAM row causes bit flips in adjacent rows.

Mechanism:

• When a row is activated, the electrical disturbance affects neighboring rows
• A single activation causes negligible disturbance, but thousands of rapid activations (within a refresh interval) can cause enough charge leakage in adjacent cells to flip bits
• The attacked row is called the aggressor row; the row with bit flips is the victim row

Why it's dangerous:

• An unprivileged user program can flip bits in memory it does NOT own
• Can flip bits in page tables → privilege escalation
• Can flip bits in other processes' data → data corruption
• Demonstrated: user-level program gaining kernel privileges by flipping page table bits

Root cause: Electromagnetic interference between adjacent DRAM rows, worsened by smaller cell sizes and tighter row spacing in modern DRAM.

Mitigations: Increased refresh rate (but costs energy/performance), targeted row refresh (refresh victim rows when aggressor is hammered), ECC (but multi-bit flips can bypass it).

Spectre exploits speculative execution combined with a cache side channel to leak secret data.

Key insight: When the CPU speculatively executes instructions down a mispredicted path, those instructions can access secret data. Even though the architectural results are rolled back, the cache state changes persist (cache is not rolled back on a squash).

Spectre v1 (Bounds Check Bypass) — simplified:

if (x < array1_size) {         // branch mispredicted as taken
    y = array2[array1[x] * 256]; // speculatively executed
}
        

1. Attacker trains the branch predictor to predict "taken"
2. Attacker provides a malicious x that is out-of-bounds (reads secret data from array1[x])
3. The speculative load array2[secret * 256] brings a cache line into the cache that depends on the secret value
4. Even after the branch resolves and speculative results are squashed, the cache line remains
5. Attacker uses Flush+Reload or Prime+Probe on array2 to determine which cache line was loaded → reveals the secret value

Why it's hard to fix: Speculative execution is fundamental to performance. Preventing all speculative side effects would severely degrade performance.