Operating SystemsHardware Security

Hardware Security Vulnerabilities

LevelAdvanced

Duration90 mins

TopicHardware Security

3 / 5

Side-Channel Attacks

When Implementations Betray Secrets

Throughout the history of cryptography and computer security, attackers have found that sometimes the easiest way to break a system isn't to attack its algorithms directly, but to attack its implementation. Even a mathematically perfect algorithm can leak secrets through the physical characteristics of its execution.

Side-channel attacks exploit information that leaks through unintended channels—timing variations, power consumption fluctuations, electromagnetic emissions, acoustic signals, or even the blinking of LED indicators. These attacks don't break the security of the algorithm itself; they break the security of the system running the algorithm.

The Spectre and Meltdown vulnerabilities we explored are cache timing side-channel attacks, but they represent just one category in a rich taxonomy of side-channel techniques that have evolved over decades of security research.

The Fundamental Challenge

Side-channel attacks are fundamentally difficult to defend against because they exploit the physical laws that govern computation. Every transistor switch consumes power. Every electron movement creates electromagnetic fields. Every computation takes time. These are not bugs—they are inherent properties of physical computing systems. Eliminating side-channels requires eliminating the physical signatures of computation itself.

The Theory of Side-Channel Information Leakage

What Is a Side-Channel?

A side-channel is any source of information that is not the intended output of a computation but is correlated with the internal state or secret data processed by that computation.

Consider a simple analogy: if you're playing poker and trying to hide your cards, your opponents might observe:

Your facial expressions (analog side-channel: emotional response)
The time you take to decide (timing side-channel: processing time)
How you handle your chips (behavioral side-channel: physical actions)

None of these reveal your cards directly, but they correlate with your hand and can be exploited by observant opponents.

Information-Theoretic Perspective

From an information-theoretic standpoint, a side-channel exists when:

H(Secret | Observation) < H(Secret)

That is, observing the side-channel reduces the entropy (uncertainty) about the secret. If measuring power consumption during an encryption operation reduces your uncertainty about the encryption key from 2^128 possibilities to 2^100 possibilities, you've extracted 28 bits of information through the side-channel.

Converting Mermaid diagram...

Categories of Side-Channels

Side-channels can be categorized in several ways:

By Physical Phenomenon:

Timing: Execution time variations
Power: Electrical power consumption
Electromagnetic: EM field emissions
Acoustic: Sound emissions
Thermal: Heat generation patterns
Optical: Light emissions (LEDs, monitors)
Cache/Memory: Microarchitectural state

By Attacker Position:

Local: Attacker has physical access to the device
Remote: Attacker operates over a network
Co-located: Attacker shares hardware resources (e.g., cloud VM)

By Information Source:

Direct: Side-channel directly correlates with secret
Indirect: Side-channel correlates with intermediate values

Timing Attacks: When Nanoseconds Leak Secrets

Timing attacks exploit variations in how long a computation takes depending on the secret data being processed. These are among the most studied and most practical side-channel attacks.

Classic Timing Attack: String Comparison

The simplest timing attack exploits naive string comparison. Consider password verification:

timing_vulnerable.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
/*
 * VULNERABLE: Variable-time password comparison
 */
bool check_password_vulnerable(const char* input, const char* correct) {
    size_t len = strlen(correct);
    
    // Length check - also leaks information!
    if (strlen(input) != len) {
        return false;
    }
    
    // Byte-by-byte comparison - TIMING LEAK!
    for (size_t i = 0; i < len; i++) {
        if (input[i] != correct[i]) {
            return false;  // EARLY EXIT reveals position of first difference!
        }
    }
    
    return true;
}
 
/*
 * THE ATTACK:
 * 
 * Password: "SECRET123"
 * 
 * Attack Phase 1: Discover password length
 *   - Try lengths 1, 2, 3, ... until timing changes
 *   - Length 9 takes slightly longer (passes length check)
 * 
 * Attack Phase 2: Discover characters one-by-one
 *   - Try "A________" (9 chars): FAST (fails at position 0)
 *   - Try "S________": SLIGHTLY SLOWER (fails at position 1)
 *   - Try "SA_______": FAST (fails at position 1)
 *   - Try "SE_______": SLIGHTLY SLOWER (fails at position 2)
 *   - ... continue until all characters discovered
 * 
 * With ~36 characters (a-z, 0-9), a 9-char password requires:
 *   9 * 36 = 324 attempts (instead of 36^9 ≈ 101 trillion)
 */
 
/*
 * SECURE: Constant-time password comparison
 */
bool check_password_constant_time(const char* input, const char* correct) {
    size_t correct_len = strlen(correct);
    size_t input_len = strlen(input);
    
    // Use the longer length to avoid length oracle
    size_t max_len = correct_len > input_len ? correct_len : input_len;
    
    // Accumulate difference without early exit
    volatile unsigned char result = 0;
    
    for (size_t i = 0; i < max_len; i++) {
        // Safe indexing using modulo (avoids buffer overread)
        unsigned char c1 = (i < input_len) ? input[i] : 0;
        unsigned char c2 = (i < correct_len) ? correct[i] : 0;
        
        // XOR accumulates differences without branching
        result |= c1 ^ c2;
    }
    
    // Also check length equality
    result |= (input_len != correct_len);
    
    // Single comparison at the end
    return result == 0;
}

Cache Timing Attacks

Cache timing attacks exploit the significant speed difference between cache hits and cache misses. This is the basis for Spectre, Meltdown, and many other microarchitectural attacks.

Key Techniques:

Prime+Probe:
- Attacker fills cache set with their own data (Prime)
- Victim executes
- Attacker accesses their data again, measuring time (Probe)
- Slow access means victim evicted attacker's data → victim accessed that cache set
Flush+Reload:
- Attacker flushes shared memory from cache (Flush)
- Victim executes
- Attacker accesses the shared memory (Reload)
- Fast access means victim loaded it → victim used that code/data
Evict+Time:
- Attacker evicts specific cache lines
- Victim executes (timed)
- Slower execution indicates the victim needed the evicted data

Cache Timing Attack Techniques Comparison
Technique	Requires	Precision	Noise Level	Use Case
Prime+Probe	Shared cache only	Cache set level	Medium	Cross-VM attacks, no shared memory
Flush+Reload	Shared memory (clflush)	Cache line level	Low	Same-process or shared libraries
Evict+Time	Shared cache only	Low	High	Environments without clflush
Flush+Flush	Shared memory	Cache line level	Low	Stealthier Flush+Reload variant
Prime+Abort	Intel TSX	Cache line level	Low	No timer needed

Remote Timing Attacks

Timing attacks can work over networks. In 2003, Brumley and Boneh demonstrated recovering RSA private keys from an OpenSSL server over a local network by measuring response times. With thousands of measurements and statistical analysis, the attacker could extract the key bit by bit. Network timing attacks are noisier but have been demonstrated even across the internet.

Power Analysis: Reading the Electrical Signature

Power analysis attacks measure the electrical power consumed by a device during cryptographic operations. Different operations and different data values consume different amounts of power, leaking information about the secret data being processed.

Simple Power Analysis (SPA)

SPA involves directly interpreting power consumption traces. If different operations produce visibly different power patterns, the attacker can read the sequence of operations.

Example: RSA Square-and-Multiply

RSA private key operations use a "square-and-multiply" algorithm where:

Processing a '0' bit requires a square operation
Processing a '1' bit requires a square AND multiply operation

Since multiplication takes more power than squaring alone, an attacker watching the power trace can directly read off the bits of the exponent (which is related to the private key).

power_analysis_vulnerable.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
"""
VULNERABLE: Standard square-and-multiply exponentiation
Power trace reveals the exponent bit-by-bit
"""
 
def modexp_vulnerable(base, exponent, modulus):
    """
    Computes: base^exponent mod modulus
    Used in RSA: ciphertext^d mod n (where d is private key)
    """
    result = 1
    
    for bit in binary_representation(exponent):
        # ALWAYS: Square operation (one power signature)
        result = (result * result) % modulus
        
        if bit == 1:
            # ONLY FOR '1' BITS: Multiply operation (additional power)
            result = (result * base) % modulus
    
    return result
 
# THE POWER TRACE MIGHT LOOK LIKE:
# 
# Bit:     0       1       1       0       1
#        +---+  +-----+  +-----+  +---+  +-----+
# Power: | S |  | S M |  | S M |  | S |  | S M |
#        +---+  +-----+  +-----+  +---+  +-----+
#          ^      ^        ^        ^       ^
#        Short  Long     Long    Short    Long
# 
# An attacker with an oscilloscope can directly read the exponent!
 
 
"""
SECURE: Montgomery ladder - constant-time exponentiation
Power trace is uniform regardless of exponent bits
"""
 
def modexp_constant_time(base, exponent, modulus):
    """
    Montgomery ladder: always performs both operations
    """
    r0 = 1
    r1 = base
    
    for bit in binary_representation(exponent):
        if bit == 0:
            r1 = (r0 * r1) % modulus    # Always computed
            r0 = (r0 * r0) % modulus    # Always computed
        else:
            r0 = (r0 * r1) % modulus    # Always computed
            r1 = (r1 * r1) % modulus    # Always computed
    
    return r0
 
# THE POWER TRACE NOW LOOKS UNIFORM:
# 
# Bit:     0       1       1       0       1
#        +---+   +---+   +---+   +---+   +---+
# Power: |S M|   |S M|   |S M|   |S M|   |S M|
#        +---+   +---+   +---+   +---+   +---+
#          ^       ^       ^       ^       ^
#        Same    Same    Same    Same    Same
# 
# Attacker cannot distinguish bit values!

Differential Power Analysis (DPA)

DPA is a more sophisticated attack that uses statistical techniques to extract keys even when the power differences are too small to observe directly.

The DPA Attack Process:

Collect traces: Record power consumption during many operations with known inputs
Hypothesize: Make a guess about a small portion of the key (e.g., one byte)
Predict: For each key hypothesis, predict what intermediate value the computation should produce
Correlate: Compute correlation between predicted intermediate values and actual power traces
Extract: The key hypothesis with highest correlation is likely correct

Why DPA works:

Even if individual power measurements are noisy, the correlation between data values and power consumption is consistent. By averaging over many traces, the noise averages out while the signal (correlation with the key) accumulates.

DPA can extract keys from devices thought to be secure against simple power analysis, and has been used to break smart cards, hardware security modules, and embedded systems.

Physical Access Required

Power analysis typically requires physical access to the device—attaching a probe to measure current drawn from the power supply. However, some research has demonstrated remote power analysis by measuring system-wide power consumption through software interfaces (like Intel RAPL) or by timing power management state changes.

Electromagnetic Emanations: Signals in the Air

Electromagnetic (EM) emanation attacks capture the electromagnetic radiation emitted by electronic devices during operation. Every wire carrying current acts as an antenna, broadcasting a weak signal that reveals information about the data being processed.

Advantages of EM Over Power Analysis

Non-invasive: Can be performed without physical contact with the device
Spatial resolution: Different parts of a chip emit different signals
No circuit modification: Doesn't require inserting probes into the power line
Bypass power filtering: Devices may filter power lines but cannot filter EM emissions

Historical Context: TEMPEST

EM side-channel attacks have a long history in signals intelligence. The NSA's classified TEMPEST program (dating to the 1950s) studied electromagnetic emanations from equipment. The name allegedly stands for "Transient Electromagnetic Pulse Emanation Standard."

During the Cold War, both US and Soviet intelligence agencies actively exploited EM emanations:

Monitoring typewriter emissions to reconstruct typed documents
Capturing display signals to reproduce monitor contents
Intercepting cryptographic machine operations

Types of EM Side-Channel Attacks

•Direct Emanations: Signals from the chip or circuit performing the computation; can reveal cryptographic keys similar to power analysis
•Conducted Emanations: Signals that travel along wires and cables; can be captured from power cables, network cables, or ground connections
•Modulated Emanations: Data signals that modulate carrier frequencies (like the video signal that modulates the refresh rate of a monitor)
•Reflected Emanations: Analyzing how external signals (like WiFi or radar) are reflected off devices differently based on their internal state

Modern EM Attacks

Screen Emanations: Researchers have demonstrated capturing monitor contents from the weak EM signals emitted by video cables (HDMI, DVI). Using software-defined radio and advanced signal processing, an attacker in an adjacent room can reconstruct what's displayed on a screen.

Keyboard Emanations: Each key press generates a unique EM signature due to the different lengths of matrix wires. Researchers have shown the ability to recover keystrokes from electromagnetic emissions captured several meters away.

Cryptographic Key Extraction: Using EM probes positioned near a laptop's CPU, researchers have extracted RSA and AES keys by analyzing emissions during cryptographic operations.

Rowhammer via EM: EM emissions have been used to detect when Rowhammer attacks (memory bit-flipping) are occurring by observing the characteristic memory access patterns.

Defense: Shielding and Noise

Defending against EM emanations is challenging. Faraday cages can block electromagnetic signals, but complete shielding is expensive and impractical for most devices. More practical defenses include adding noise to mask the signal, using balanced circuits that emit less differential EM, and designing algorithms that minimize data-dependent EM signatures.

Exotic Side-Channels: Acoustic, Thermal, and Beyond

Beyond timing, power, and EM, researchers have discovered numerous exotic side-channels that demonstrate the creativity of security researchers—and the difficulty of securing systems against determined attackers.

Acoustic Side-Channels

Computers make sounds. Keyboards click. Hard drives whir. CPUs generate high-frequency electrical noise that couples into speakers or is directly audible. These sounds can leak information.

Notable Acoustic Attacks:

Keyboard Acoustic Emanations: Each key on a keyboard produces a slightly different sound. Machine learning classifiers can distinguish keys with high accuracy, enabling keystroke recovery from audio recordings.
RSA Key Extraction: In 2013, Genkin et al. demonstrated extracting RSA keys by recording the high-pitched sounds emitted by CPU voltage regulators during cryptographic operations—using a smartphone microphone!
Printer Acoustic Attacks: The sound of dot-matrix printers can reveal printed content. Even modern printers emit characteristic sounds for different operations.
3D Printer Attacks: The sounds of stepper motors and other components leak information about what's being printed, potentially revealing proprietary designs.

Exotic Side-Channel Attack Summary
Side-Channel	Information Leaked	Attack Distance	Notable Research
Acoustic (CPU)	Cryptographic keys	~1 meter	Genkin et al. 2014: RSA via coil whine
Acoustic (Keyboard)	Keystrokes	~10 meters	Asonov & Agrawal 2004: 96% accuracy
Thermal	Computation patterns	Physical contact	Hutter & Schmidt 2014: AES key recovery
Optical (LED)	Data transmission	Line of sight	Loughry & Umphress 2002: LED surveillance
Optical (Screen)	Displayed content	Reflected light	Backes et al. 2008: Reading reflections
Power Line	Device activity	Same circuit	Clark et al. 2013: Appliance identification
Memory Bus	Memory contents	Physical probe	Halderman et al. 2009: Cold boot attack

Optical Side-Channels

LED Status Indicators: Many devices have LEDs that indicate activity (hard drive, network, power). These LEDs often flicker at frequencies corresponding to data being processed. Researchers have demonstrated reading the data being transmitted by monitoring the LED on a network card or router.

Screen Reflections: The content displayed on a screen can be reconstructed from reflections in nearby objects—eyeglasses, windows, teapots, or even the human eye. High-resolution cameras and image processing can extract surprising amounts of detail.

Photonic Emission: Transistors emit tiny amounts of light when they switch states. Using highly sensitive photodetectors, attackers can extract cryptographic keys by observing these emissions.

Other Exotic Channels

Thermal Imaging: After entering a password on a keypad, thermal cameras can detect which keys were pressed based on the residual heat from your fingertips.

Rowhammer: By repeatedly accessing memory rows, attackers can cause bit flips in adjacent rows due to electrical interference. This can be used to gain privileges or extract data.

Fault Injection: Deliberately introducing faults (via voltage glitches, clock manipulation, or lasers) can cause incorrect computations that leak key information through differential fault analysis.

The Cat-and-Mouse Game

Every defense against one side-channel potentially opens another. Adding random delays to defeat timing attacks may create new power patterns. Adding noise to mask EM might create acoustic signatures. Security researchers and designers are engaged in a continuous arms race, where attackers find new channels and defenders try to close them.

Microarchitectural Side-Channels: The CPU as Attack Surface

Microarchitectural side-channels exploit the internal structures of modern CPUs—caches, branch predictors, execution units, and buffers—to leak information. These attacks, including Spectre and Meltdown, represent the cutting edge of side-channel research.

The CPU's Hidden State

Modern CPUs maintain extensive internal state that is not directly visible to software but affects performance in measurable ways:

Caches (L1, L2, L3, TLB): Store recently accessed data and translations
Branch Predictor: Remembers branch outcomes to predict future branches
Execution Units: Pipelined resources that may have contention
Store Buffers: Hold pending writes before committing to cache
Line Fill Buffers: Hold in-flight cache line requests
Return Stack Buffer: Predicts return addresses for function calls

Each of these structures can be probed by software to infer information about what other code was doing.

Converting Mermaid diagram...

Beyond Spectre and Meltdown

The Spectre/Meltdown disclosure opened the floodgates for microarchitectural attack research:

MDS Attacks (Microarchitectural Data Sampling):

RIDL (Rogue In-Flight Data Load): Leaks data from Line Fill Buffers
Fallout: Leaks data from Store Buffers during write operations
ZombieLoad: Leaks data from fill buffers during aborted loads
TAA (TSX Asynchronous Abort): Exploits Intel TSX to leak data

Cache Attacks:

TLBleed: Extracts cryptographic keys through TLB timing
NetCAT: Leaks keystrokes from Intel DDIO (direct data I/O) over network

Speculative Execution Variants:

Spectre-BHB: Cross-privilege Branch History Buffer attacks
Retbleed: Exploits return instructions despite Retpoline
PACMAN: Defeats ARM Pointer Authentication via speculation

check_vulnerabilities.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#!/bin/bash
# Check system vulnerability status on Linux
 
echo "=== Microarchitectural Vulnerability Status ==="
echo ""
 
# Iterate through all vulnerability files
VULN_DIR="/sys/devices/system/cpu/vulnerabilities"
 
if [ -d "$VULN_DIR" ]; then
    for vuln in "$VULN_DIR"/*; do
        name=$(basename "$vuln")
        status=$(cat "$vuln")
        
        # Color coding
        if echo "$status" | grep -qi "not affected"; then
            color="\033[32m"  # Green
        elif echo "$status" | grep -qi "mitigation"; then
            color="\033[33m"  # Yellow
        elif echo "$status" | grep -qi "vulnerable"; then
            color="\033[31m"  # Red
        else
            color="\033[0m"   # Default
        fi
        
        printf "%-20s: ${color}%s\033[0m\n" "$name" "$status"
    done
else
    echo "Vulnerability sysfs not available"
fi
 
echo ""
echo "=== CPU Microcode Version ==="
grep -m1 "microcode" /proc/cpuinfo
 
echo ""
echo "=== Relevant Kernel Parameters ==="
cat /proc/cmdline | tr ' ' '\n' | grep -E "^(spectre|meltdown|l1tf|mds|tsx|mitigations)"
 
# Common vulnerabilities explained:
# - spectre_v1:  Bounds Check Bypass
# - spectre_v2:  Branch Target Injection  
# - meltdown:    Rogue Data Cache Load
# - l1tf:        L1 Terminal Fault
# - mds:         Microarchitectural Data Sampling
# - tsx_async:   TSX Asynchronous Abort
# - itlb_multi:  iTLB Multihit
# - srbds:       Special Register Buffer Data Sampling
# - mmio_stale:  MMIO Stale Data
# - retbleed:    Retbleed
# - gds:         Gather Data Sampling

The Growing List

The Linux kernel's vulnerability status interface (/sys/devices/system/cpu/vulnerabilities/) has grown from 2 entries in early 2018 to over 15 entries by 2024. Each new entry represents another attack class requiring mitigations that often impact performance. This trajectory has no apparent end.

Defending Against Side-Channel Attacks

Defending against side-channel attacks is challenging because the attacks exploit fundamental physical properties of computation. There is no single fix; instead, defenders must employ multiple techniques tailored to specific threat models.

Constant-Time Programming

The gold standard for cryptographic implementations is constant-time code: the execution path and timing must be independent of secret data.

Principles:

No secret-dependent branches
No secret-dependent memory access patterns
No secret-dependent instruction timing
Use bitwise operations instead of conditionals when possible

constant_time_examples.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
/*
 * Constant-Time Programming Patterns
 * 
 * These techniques avoid side-channels by ensuring
 * execution is independent of secret data.
 */
 
#include <stdint.h>
 
// ============================================
// PATTERN 1: Constant-time conditional selection
// ============================================
 
// VULNERABLE: Branch on secret
uint32_t select_if(uint32_t condition, uint32_t a, uint32_t b) {
    if (condition) return a;  // TIMING LEAK!
    return b;
}
 
// SECURE: Bitwise selection, no branches
uint32_t select_constant_time(uint32_t condition, uint32_t a, uint32_t b) {
    // Convert condition to all-ones or all-zeros mask
    uint32_t mask = -(uint32_t)(condition != 0);
    // Select: (mask & a) | (~mask & b)
    return (mask & a) | (~mask & b);
}
 
// ============================================
// PATTERN 2: Constant-time comparison
// ============================================
 
// VULNERABLE: Early exit on mismatch
int compare_if(const uint8_t *a, const uint8_t *b, size_t len) {
    for (size_t i = 0; i < len; i++) {
        if (a[i] != b[i]) return 0;  // TIMING LEAK!
    }
    return 1;
}
 
// SECURE: Always iterate all bytes
int compare_constant_time(const uint8_t *a, const uint8_t *b, size_t len) {
    volatile uint8_t result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];  // Accumulate differences
    }
    return result == 0;
}
 
// ============================================
// PATTERN 3: Constant-time table lookup
// ============================================
 
// VULNERABLE: Direct indexing leaks via cache
uint8_t lookup_table[256];
 
uint8_t lookup_direct(uint8_t secret_index) {
    return lookup_table[secret_index];  // CACHE TIMING LEAK!
}
 
// SECURE: Access all entries, select correct one
uint8_t lookup_constant_time(uint8_t secret_index) {
    uint8_t result = 0;
    for (int i = 0; i < 256; i++) {
        // Create mask: all-ones if i == secret_index, else all-zeros
        uint8_t mask = -((uint8_t)(i == secret_index));
        // Accumulate the correct value
        result |= (mask & lookup_table[i]);
    }
    return result;
}
 
// ============================================
// PATTERN 4: Avoiding variable shifts
// ============================================
 
// VULNERABLE: Variable shift amount may take variable time
uint32_t shift_variable(uint32_t value, uint32_t secret_amount) {
    return value >> secret_amount;  // May have timing difference!
}
 
// SECURE: Build shift using fixed operations (example for small shifts)
uint32_t shift_constant_time(uint32_t value, uint32_t amount) {
    // Works for amount 0-31
    uint32_t result = value;
    result = select_constant_time(amount & 16, result >> 16, result);
    result = select_constant_time(amount & 8, result >> 8, result);
    result = select_constant_time(amount & 4, result >> 4, result);
    result = select_constant_time(amount & 2, result >> 2, result);
    result = select_constant_time(amount & 1, result >> 1, result);
    return result;
}

Hardware and Architectural Defenses

Cache Partitioning:

Divide cache ways between security domains
Prevents cross-domain cache interference
Intel CAT (Cache Allocation Technology) provides some control

Memory Encryption:

Encrypt memory contents (Intel TME, AMD SME)
Even if leaked, data is encrypted
Doesn't prevent all attacks but raises the bar

Hardware-Based Isolation:

Intel SGX: Encrypted enclaves (though itself vulnerable to side-channels)
ARM TrustZone: Separate secure world
AMD SEV: VM memory encryption

Speculation Barriers:

LFENCE, CSDB: Block speculation past a point
Retpoline: Replace indirect branches with return-based sequences
IBRS/IBPB/STIBP: CPU controls for branch prediction isolation

Defense Layers Summary

•Algorithm level: Use constant-time algorithms; avoid secret-dependent branches and memory accesses
•Implementation level: Careful coding practices; verified constant-time libraries (e.g., libsodium, HACL*)
•Compiler level: Ensure compiler doesn't undo constant-time code; use barriers and volatile where needed
•OS level: KPTI, address space isolation, process scheduling isolation
•Hardware level: Microcode updates, speculation controls, future CPUs with side-channel resistance
•Physical level: Shielding, noise injection, air-gapping sensitive systems

Summary: The Invisible Attack Surface

Side-channel attacks reveal that computer security extends far beyond software correctness. The physical properties of computation—time, power, radiation, sound—create channels through which secrets can flow, regardless of the mathematical strength of cryptographic algorithms.

Key Takeaways

•Side-channels are unintended information leakage paths that correlate physical observables with secret data
•Timing attacks exploit execution time differences; defending requires constant-time implementations
•Power analysis reads electrical signatures; Simple Power Analysis (SPA) observes patterns directly, while Differential Power Analysis (DPA) uses statistical techniques
•Electromagnetic emanations broadcast computation state through the air; TEMPEST-level attacks have been known for decades
•Exotic channels include acoustic, thermal, and optical; any measurable physical property can potentially leak information
•Microarchitectural attacks (Spectre, Meltdown, MDS) exploit CPU internal structures like caches and predictors
•Defense requires layers: constant-time code, compiler support, OS isolation, hardware mitigations, and physical security
•Complete protection is impossible: new attacks will continue to be discovered; security is a continuous process

What's next:

In the next page, we'll examine hardware mitigations for microarchitectural vulnerabilities in detail. We'll explore the specific CPU features and microcode updates that Intel, AMD, and ARM have deployed to address Spectre, Meltdown, and related vulnerabilities—and understand the performance and security trade-offs inherent in each approach.

Page Complete

You now have a comprehensive understanding of side-channel attacks—from theoretical foundations through practical attack techniques to defense strategies. This knowledge is essential for anyone designing, implementing, or evaluating security-critical systems.

3 / 5

Loading learning content...

Operating SystemsHardware Security

Hardware Security Vulnerabilities

LevelAdvanced

Duration90 mins

TopicHardware Security

3 / 5

Side-Channel Attacks

When Implementations Betray Secrets

The Fundamental Challenge

The Theory of Side-Channel Information Leakage

What Is a Side-Channel?

A side-channel is any source of information that is not the intended output of a computation but is correlated with the internal state or secret data processed by that computation.

Consider a simple analogy: if you're playing poker and trying to hide your cards, your opponents might observe:

Your facial expressions (analog side-channel: emotional response)
The time you take to decide (timing side-channel: processing time)
How you handle your chips (behavioral side-channel: physical actions)

None of these reveal your cards directly, but they correlate with your hand and can be exploited by observant opponents.

Information-Theoretic Perspective

From an information-theoretic standpoint, a side-channel exists when:

H(Secret | Observation) < H(Secret)

Converting Mermaid diagram...

Categories of Side-Channels

Side-channels can be categorized in several ways:

By Physical Phenomenon:

Timing: Execution time variations
Power: Electrical power consumption
Electromagnetic: EM field emissions
Acoustic: Sound emissions
Thermal: Heat generation patterns
Optical: Light emissions (LEDs, monitors)
Cache/Memory: Microarchitectural state

By Attacker Position:

Local: Attacker has physical access to the device
Remote: Attacker operates over a network
Co-located: Attacker shares hardware resources (e.g., cloud VM)

By Information Source:

Direct: Side-channel directly correlates with secret
Indirect: Side-channel correlates with intermediate values

Timing Attacks: When Nanoseconds Leak Secrets

Timing attacks exploit variations in how long a computation takes depending on the secret data being processed. These are among the most studied and most practical side-channel attacks.

Classic Timing Attack: String Comparison

The simplest timing attack exploits naive string comparison. Consider password verification:

timing_vulnerable.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
/*
 * VULNERABLE: Variable-time password comparison
 */
bool check_password_vulnerable(const char* input, const char* correct) {
    size_t len = strlen(correct);
    
    // Length check - also leaks information!
    if (strlen(input) != len) {
        return false;
    }
    
    // Byte-by-byte comparison - TIMING LEAK!
    for (size_t i = 0; i < len; i++) {
        if (input[i] != correct[i]) {
            return false;  // EARLY EXIT reveals position of first difference!
        }
    }
    
    return true;
}
 
/*
 * THE ATTACK:
 * 
 * Password: "SECRET123"
 * 
 * Attack Phase 1: Discover password length
 *   - Try lengths 1, 2, 3, ... until timing changes
 *   - Length 9 takes slightly longer (passes length check)
 * 
 * Attack Phase 2: Discover characters one-by-one
 *   - Try "A________" (9 chars): FAST (fails at position 0)
 *   - Try "S________": SLIGHTLY SLOWER (fails at position 1)
 *   - Try "SA_______": FAST (fails at position 1)
 *   - Try "SE_______": SLIGHTLY SLOWER (fails at position 2)
 *   - ... continue until all characters discovered
 * 
 * With ~36 characters (a-z, 0-9), a 9-char password requires:
 *   9 * 36 = 324 attempts (instead of 36^9 ≈ 101 trillion)
 */
 
/*
 * SECURE: Constant-time password comparison
 */
bool check_password_constant_time(const char* input, const char* correct) {
    size_t correct_len = strlen(correct);
    size_t input_len = strlen(input);
    
    // Use the longer length to avoid length oracle
    size_t max_len = correct_len > input_len ? correct_len : input_len;
    
    // Accumulate difference without early exit
    volatile unsigned char result = 0;
    
    for (size_t i = 0; i < max_len; i++) {
        // Safe indexing using modulo (avoids buffer overread)
        unsigned char c1 = (i < input_len) ? input[i] : 0;
        unsigned char c2 = (i < correct_len) ? correct[i] : 0;
        
        // XOR accumulates differences without branching
        result |= c1 ^ c2;
    }
    
    // Also check length equality
    result |= (input_len != correct_len);
    
    // Single comparison at the end
    return result == 0;
}

Cache Timing Attacks

Cache timing attacks exploit the significant speed difference between cache hits and cache misses. This is the basis for Spectre, Meltdown, and many other microarchitectural attacks.

Key Techniques:

Prime+Probe:
- Attacker fills cache set with their own data (Prime)
- Victim executes
- Attacker accesses their data again, measuring time (Probe)
- Slow access means victim evicted attacker's data → victim accessed that cache set
Flush+Reload:
- Attacker flushes shared memory from cache (Flush)
- Victim executes
- Attacker accesses the shared memory (Reload)
- Fast access means victim loaded it → victim used that code/data
Evict+Time:
- Attacker evicts specific cache lines
- Victim executes (timed)
- Slower execution indicates the victim needed the evicted data

Cache Timing Attack Techniques Comparison
Technique	Requires	Precision	Noise Level	Use Case
Prime+Probe	Shared cache only	Cache set level	Medium	Cross-VM attacks, no shared memory
Flush+Reload	Shared memory (clflush)	Cache line level	Low	Same-process or shared libraries
Evict+Time	Shared cache only	Low	High	Environments without clflush
Flush+Flush	Shared memory	Cache line level	Low	Stealthier Flush+Reload variant
Prime+Abort	Intel TSX	Cache line level	Low	No timer needed

Remote Timing Attacks

Power Analysis: Reading the Electrical Signature

Simple Power Analysis (SPA)

SPA involves directly interpreting power consumption traces. If different operations produce visibly different power patterns, the attacker can read the sequence of operations.

Example: RSA Square-and-Multiply

RSA private key operations use a "square-and-multiply" algorithm where:

Processing a '0' bit requires a square operation
Processing a '1' bit requires a square AND multiply operation

Since multiplication takes more power than squaring alone, an attacker watching the power trace can directly read off the bits of the exponent (which is related to the private key).

power_analysis_vulnerable.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
"""
VULNERABLE: Standard square-and-multiply exponentiation
Power trace reveals the exponent bit-by-bit
"""
 
def modexp_vulnerable(base, exponent, modulus):
    """
    Computes: base^exponent mod modulus
    Used in RSA: ciphertext^d mod n (where d is private key)
    """
    result = 1
    
    for bit in binary_representation(exponent):
        # ALWAYS: Square operation (one power signature)
        result = (result * result) % modulus
        
        if bit == 1:
            # ONLY FOR '1' BITS: Multiply operation (additional power)
            result = (result * base) % modulus
    
    return result
 
# THE POWER TRACE MIGHT LOOK LIKE:
# 
# Bit:     0       1       1       0       1
#        +---+  +-----+  +-----+  +---+  +-----+
# Power: | S |  | S M |  | S M |  | S |  | S M |
#        +---+  +-----+  +-----+  +---+  +-----+
#          ^      ^        ^        ^       ^
#        Short  Long     Long    Short    Long
# 
# An attacker with an oscilloscope can directly read the exponent!
 
 
"""
SECURE: Montgomery ladder - constant-time exponentiation
Power trace is uniform regardless of exponent bits
"""
 
def modexp_constant_time(base, exponent, modulus):
    """
    Montgomery ladder: always performs both operations
    """
    r0 = 1
    r1 = base
    
    for bit in binary_representation(exponent):
        if bit == 0:
            r1 = (r0 * r1) % modulus    # Always computed
            r0 = (r0 * r0) % modulus    # Always computed
        else:
            r0 = (r0 * r1) % modulus    # Always computed
            r1 = (r1 * r1) % modulus    # Always computed
    
    return r0
 
# THE POWER TRACE NOW LOOKS UNIFORM:
# 
# Bit:     0       1       1       0       1
#        +---+   +---+   +---+   +---+   +---+
# Power: |S M|   |S M|   |S M|   |S M|   |S M|
#        +---+   +---+   +---+   +---+   +---+
#          ^       ^       ^       ^       ^
#        Same    Same    Same    Same    Same
# 
# Attacker cannot distinguish bit values!

Differential Power Analysis (DPA)

DPA is a more sophisticated attack that uses statistical techniques to extract keys even when the power differences are too small to observe directly.

The DPA Attack Process:

Collect traces: Record power consumption during many operations with known inputs
Hypothesize: Make a guess about a small portion of the key (e.g., one byte)
Predict: For each key hypothesis, predict what intermediate value the computation should produce
Correlate: Compute correlation between predicted intermediate values and actual power traces
Extract: The key hypothesis with highest correlation is likely correct

Why DPA works:

DPA can extract keys from devices thought to be secure against simple power analysis, and has been used to break smart cards, hardware security modules, and embedded systems.

Physical Access Required

Electromagnetic Emanations: Signals in the Air

Advantages of EM Over Power Analysis

Non-invasive: Can be performed without physical contact with the device
Spatial resolution: Different parts of a chip emit different signals
No circuit modification: Doesn't require inserting probes into the power line
Bypass power filtering: Devices may filter power lines but cannot filter EM emissions

Historical Context: TEMPEST

During the Cold War, both US and Soviet intelligence agencies actively exploited EM emanations:

Monitoring typewriter emissions to reconstruct typed documents
Capturing display signals to reproduce monitor contents
Intercepting cryptographic machine operations

Types of EM Side-Channel Attacks

•Direct Emanations: Signals from the chip or circuit performing the computation; can reveal cryptographic keys similar to power analysis
•Conducted Emanations: Signals that travel along wires and cables; can be captured from power cables, network cables, or ground connections
•Modulated Emanations: Data signals that modulate carrier frequencies (like the video signal that modulates the refresh rate of a monitor)
•Reflected Emanations: Analyzing how external signals (like WiFi or radar) are reflected off devices differently based on their internal state

Modern EM Attacks

Cryptographic Key Extraction: Using EM probes positioned near a laptop's CPU, researchers have extracted RSA and AES keys by analyzing emissions during cryptographic operations.

Rowhammer via EM: EM emissions have been used to detect when Rowhammer attacks (memory bit-flipping) are occurring by observing the characteristic memory access patterns.

Defense: Shielding and Noise

Exotic Side-Channels: Acoustic, Thermal, and Beyond

Acoustic Side-Channels

Computers make sounds. Keyboards click. Hard drives whir. CPUs generate high-frequency electrical noise that couples into speakers or is directly audible. These sounds can leak information.

Notable Acoustic Attacks:

Keyboard Acoustic Emanations: Each key on a keyboard produces a slightly different sound. Machine learning classifiers can distinguish keys with high accuracy, enabling keystroke recovery from audio recordings.
RSA Key Extraction: In 2013, Genkin et al. demonstrated extracting RSA keys by recording the high-pitched sounds emitted by CPU voltage regulators during cryptographic operations—using a smartphone microphone!
Printer Acoustic Attacks: The sound of dot-matrix printers can reveal printed content. Even modern printers emit characteristic sounds for different operations.
3D Printer Attacks: The sounds of stepper motors and other components leak information about what's being printed, potentially revealing proprietary designs.

Exotic Side-Channel Attack Summary
Side-Channel	Information Leaked	Attack Distance	Notable Research
Acoustic (CPU)	Cryptographic keys	~1 meter	Genkin et al. 2014: RSA via coil whine
Acoustic (Keyboard)	Keystrokes	~10 meters	Asonov & Agrawal 2004: 96% accuracy
Thermal	Computation patterns	Physical contact	Hutter & Schmidt 2014: AES key recovery
Optical (LED)	Data transmission	Line of sight	Loughry & Umphress 2002: LED surveillance
Optical (Screen)	Displayed content	Reflected light	Backes et al. 2008: Reading reflections
Power Line	Device activity	Same circuit	Clark et al. 2013: Appliance identification
Memory Bus	Memory contents	Physical probe	Halderman et al. 2009: Cold boot attack

Optical Side-Channels

Photonic Emission: Transistors emit tiny amounts of light when they switch states. Using highly sensitive photodetectors, attackers can extract cryptographic keys by observing these emissions.

Other Exotic Channels

Thermal Imaging: After entering a password on a keypad, thermal cameras can detect which keys were pressed based on the residual heat from your fingertips.

Rowhammer: By repeatedly accessing memory rows, attackers can cause bit flips in adjacent rows due to electrical interference. This can be used to gain privileges or extract data.

The Cat-and-Mouse Game

Microarchitectural Side-Channels: The CPU as Attack Surface

The CPU's Hidden State

Modern CPUs maintain extensive internal state that is not directly visible to software but affects performance in measurable ways:

Caches (L1, L2, L3, TLB): Store recently accessed data and translations
Branch Predictor: Remembers branch outcomes to predict future branches
Execution Units: Pipelined resources that may have contention
Store Buffers: Hold pending writes before committing to cache
Line Fill Buffers: Hold in-flight cache line requests
Return Stack Buffer: Predicts return addresses for function calls

Each of these structures can be probed by software to infer information about what other code was doing.

Converting Mermaid diagram...

Beyond Spectre and Meltdown

The Spectre/Meltdown disclosure opened the floodgates for microarchitectural attack research:

MDS Attacks (Microarchitectural Data Sampling):

RIDL (Rogue In-Flight Data Load): Leaks data from Line Fill Buffers
Fallout: Leaks data from Store Buffers during write operations
ZombieLoad: Leaks data from fill buffers during aborted loads
TAA (TSX Asynchronous Abort): Exploits Intel TSX to leak data

Cache Attacks:

TLBleed: Extracts cryptographic keys through TLB timing
NetCAT: Leaks keystrokes from Intel DDIO (direct data I/O) over network

Speculative Execution Variants:

Spectre-BHB: Cross-privilege Branch History Buffer attacks
Retbleed: Exploits return instructions despite Retpoline
PACMAN: Defeats ARM Pointer Authentication via speculation

check_vulnerabilities.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#!/bin/bash
# Check system vulnerability status on Linux
 
echo "=== Microarchitectural Vulnerability Status ==="
echo ""
 
# Iterate through all vulnerability files
VULN_DIR="/sys/devices/system/cpu/vulnerabilities"
 
if [ -d "$VULN_DIR" ]; then
    for vuln in "$VULN_DIR"/*; do
        name=$(basename "$vuln")
        status=$(cat "$vuln")
        
        # Color coding
        if echo "$status" | grep -qi "not affected"; then
            color="\033[32m"  # Green
        elif echo "$status" | grep -qi "mitigation"; then
            color="\033[33m"  # Yellow
        elif echo "$status" | grep -qi "vulnerable"; then
            color="\033[31m"  # Red
        else
            color="\033[0m"   # Default
        fi
        
        printf "%-20s: ${color}%s\033[0m\n" "$name" "$status"
    done
else
    echo "Vulnerability sysfs not available"
fi
 
echo ""
echo "=== CPU Microcode Version ==="
grep -m1 "microcode" /proc/cpuinfo
 
echo ""
echo "=== Relevant Kernel Parameters ==="
cat /proc/cmdline | tr ' ' '\n' | grep -E "^(spectre|meltdown|l1tf|mds|tsx|mitigations)"
 
# Common vulnerabilities explained:
# - spectre_v1:  Bounds Check Bypass
# - spectre_v2:  Branch Target Injection  
# - meltdown:    Rogue Data Cache Load
# - l1tf:        L1 Terminal Fault
# - mds:         Microarchitectural Data Sampling
# - tsx_async:   TSX Asynchronous Abort
# - itlb_multi:  iTLB Multihit
# - srbds:       Special Register Buffer Data Sampling
# - mmio_stale:  MMIO Stale Data
# - retbleed:    Retbleed
# - gds:         Gather Data Sampling

The Growing List

Defending Against Side-Channel Attacks

Constant-Time Programming

The gold standard for cryptographic implementations is constant-time code: the execution path and timing must be independent of secret data.

Principles:

No secret-dependent branches
No secret-dependent memory access patterns
No secret-dependent instruction timing
Use bitwise operations instead of conditionals when possible

constant_time_examples.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
/*
 * Constant-Time Programming Patterns
 * 
 * These techniques avoid side-channels by ensuring
 * execution is independent of secret data.
 */
 
#include <stdint.h>
 
// ============================================
// PATTERN 1: Constant-time conditional selection
// ============================================
 
// VULNERABLE: Branch on secret
uint32_t select_if(uint32_t condition, uint32_t a, uint32_t b) {
    if (condition) return a;  // TIMING LEAK!
    return b;
}
 
// SECURE: Bitwise selection, no branches
uint32_t select_constant_time(uint32_t condition, uint32_t a, uint32_t b) {
    // Convert condition to all-ones or all-zeros mask
    uint32_t mask = -(uint32_t)(condition != 0);
    // Select: (mask & a) | (~mask & b)
    return (mask & a) | (~mask & b);
}
 
// ============================================
// PATTERN 2: Constant-time comparison
// ============================================
 
// VULNERABLE: Early exit on mismatch
int compare_if(const uint8_t *a, const uint8_t *b, size_t len) {
    for (size_t i = 0; i < len; i++) {
        if (a[i] != b[i]) return 0;  // TIMING LEAK!
    }
    return 1;
}
 
// SECURE: Always iterate all bytes
int compare_constant_time(const uint8_t *a, const uint8_t *b, size_t len) {
    volatile uint8_t result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];  // Accumulate differences
    }
    return result == 0;
}
 
// ============================================
// PATTERN 3: Constant-time table lookup
// ============================================
 
// VULNERABLE: Direct indexing leaks via cache
uint8_t lookup_table[256];
 
uint8_t lookup_direct(uint8_t secret_index) {
    return lookup_table[secret_index];  // CACHE TIMING LEAK!
}
 
// SECURE: Access all entries, select correct one
uint8_t lookup_constant_time(uint8_t secret_index) {
    uint8_t result = 0;
    for (int i = 0; i < 256; i++) {
        // Create mask: all-ones if i == secret_index, else all-zeros
        uint8_t mask = -((uint8_t)(i == secret_index));
        // Accumulate the correct value
        result |= (mask & lookup_table[i]);
    }
    return result;
}
 
// ============================================
// PATTERN 4: Avoiding variable shifts
// ============================================
 
// VULNERABLE: Variable shift amount may take variable time
uint32_t shift_variable(uint32_t value, uint32_t secret_amount) {
    return value >> secret_amount;  // May have timing difference!
}
 
// SECURE: Build shift using fixed operations (example for small shifts)
uint32_t shift_constant_time(uint32_t value, uint32_t amount) {
    // Works for amount 0-31
    uint32_t result = value;
    result = select_constant_time(amount & 16, result >> 16, result);
    result = select_constant_time(amount & 8, result >> 8, result);
    result = select_constant_time(amount & 4, result >> 4, result);
    result = select_constant_time(amount & 2, result >> 2, result);
    result = select_constant_time(amount & 1, result >> 1, result);
    return result;
}

Hardware and Architectural Defenses

Cache Partitioning:

Divide cache ways between security domains
Prevents cross-domain cache interference
Intel CAT (Cache Allocation Technology) provides some control

Memory Encryption:

Encrypt memory contents (Intel TME, AMD SME)
Even if leaked, data is encrypted
Doesn't prevent all attacks but raises the bar

Hardware-Based Isolation:

Intel SGX: Encrypted enclaves (though itself vulnerable to side-channels)
ARM TrustZone: Separate secure world
AMD SEV: VM memory encryption

Speculation Barriers:

LFENCE, CSDB: Block speculation past a point
Retpoline: Replace indirect branches with return-based sequences
IBRS/IBPB/STIBP: CPU controls for branch prediction isolation

Defense Layers Summary

•Algorithm level: Use constant-time algorithms; avoid secret-dependent branches and memory accesses
•Implementation level: Careful coding practices; verified constant-time libraries (e.g., libsodium, HACL*)
•Compiler level: Ensure compiler doesn't undo constant-time code; use barriers and volatile where needed
•OS level: KPTI, address space isolation, process scheduling isolation
•Hardware level: Microcode updates, speculation controls, future CPUs with side-channel resistance
•Physical level: Shielding, noise injection, air-gapping sensitive systems

Summary: The Invisible Attack Surface

Key Takeaways

•Side-channels are unintended information leakage paths that correlate physical observables with secret data
•Timing attacks exploit execution time differences; defending requires constant-time implementations
•Power analysis reads electrical signatures; Simple Power Analysis (SPA) observes patterns directly, while Differential Power Analysis (DPA) uses statistical techniques
•Electromagnetic emanations broadcast computation state through the air; TEMPEST-level attacks have been known for decades
•Exotic channels include acoustic, thermal, and optical; any measurable physical property can potentially leak information
•Microarchitectural attacks (Spectre, Meltdown, MDS) exploit CPU internal structures like caches and predictors
•Defense requires layers: constant-time code, compiler support, OS isolation, hardware mitigations, and physical security
•Complete protection is impossible: new attacks will continue to be discovered; security is a continuous process

What's next:

Page Complete

3 / 5