Exploiting Truth Tables: Side Channel Attacks

The truth table for an AND gate is clean:

At the logical abstraction level, nothing happens when you compute 0 AND 0. The output is 0, the inputs are 0, and no information appears to leak.

But at the physical level, computing 0 AND 0 is not silent. Transistors switch. Capacitors charge and discharge. Electrons move through silicon. These physical processes consume power, take time, and respond to voltage fluctuations.

The gap between the logical abstraction and the physical implementation creates a class of vulnerabilities called side-channel attacks. These attacks exploit information that leaks from the physical behavior of the system: information that is invisible at the abstraction layer but measurable in the real world.

This post explains three major categories of side-channel attacks: power analysis, timing attacks, and fault injection. Each exploits a different aspect of how logic gates physically implement Boolean functions.

The Foundation: Physical Implementation Leaks

In the companion post Truth Tables and Physical Implementation, we established that:

Logic 1 and 0 are voltage states, not abstract symbols
Gates are transistor arrangements that respond to voltage
Switching a gate from one state to another is a physical process

Every physical process has observable characteristics. In CMOS circuits, these characteristics include:

Power consumption varies based on state transitions
Propagation delay depends on circuit complexity
Voltage thresholds determine when a signal is interpreted as 0 or 1

Side-channel attacks measure these physical characteristics to infer information that should remain hidden.

Power Analysis Attacks

The Physical Basis

CMOS transistors consume power when they switch states. When a gate transitions from 0 to 1, current flows to charge the output capacitance. When it transitions from 1 to 0, that capacitor discharges through the pull-down network.

Critically: The power consumption pattern depends on what data is being processed.

Consider an 8-bit register storing the value 0xFF (binary 11111111). If you load 0x00 into that register, all eight bits transition from 1 to 0. Each transition consumes a measurable amount of power.

Now load 0x01 instead. Only seven bits transition. The power consumption is detectably different.

This is the foundation of Simple Power Analysis (SPA) and Differential Power Analysis (DPA).

Simple Power Analysis (SPA)

SPA exploits visible patterns in power consumption traces.

Target scenario: A smart card implementing RSA encryption.

RSA uses modular exponentiation. A common implementation is the square-and-multiply algorithm:

def modular_exponentiation(base, exponent, modulus):
    result = 1
    for bit in exponent:
        result = (result * result) % modulus  # square
        if bit == 1:
            result = (result * base) % modulus  # multiply
    return result

Notice the conditional multiply. If the exponent bit is 1, the code performs an extra multiplication. If the bit is 0, it skips it.

Multiplication consumes more power than a conditional branch that doesn't execute. An attacker with a high-speed oscilloscope on the power line can see:

Square → Square → Square (three square operations, exponent bits are 0, 0, 0)
Square → Multiply → Square → Multiply (alternating pattern, exponent bits are 1, 0, 1)

By analyzing the power trace, the attacker recovers the secret exponent bit-by-bit.

Differential Power Analysis (DPA)

DPA is more sophisticated. It uses statistical analysis to extract secrets even when individual operations are hard to distinguish.

The attack:

Capture thousands of power traces while the device processes different inputs
Hypothesize a key byte (e.g., "what if the first byte is 0x42?")
Predict power consumption for each input based on that hypothesis
Compute correlation between predicted and actual power traces
Repeat for all possible key bytes (0x00 through 0xFF)
The hypothesis with the highest correlation is likely correct

Why this works:

Power consumption correlates with the Hamming weight of the data being processed. Hamming weight is simply the count of bits set to 1 in a binary value. If the key byte is 0x42 (binary 01000010, Hamming weight = 2), operations on that byte will have a different power signature than operations on 0xFF (binary 11111111, Hamming weight = 8). More bits set to 1 means more transistors switching, which means higher power consumption.

DPA averages out noise and isolates the correlation between specific data values and power consumption. Even if the power difference per operation is tiny, statistical analysis makes it measurable.

Real-World Impact

Power analysis has been demonstrated against:

Smart cards (credit cards, SIM cards, secure elements)
Hardware wallets (cryptocurrency storage devices)
Embedded systems (IoT devices, industrial controllers)
Cryptographic accelerators (AES-NI and similar hardware)

Countermeasures include:

Power randomization: Add random delays and dummy operations
Balanced circuits: Design gates so transitions always consume similar power
Masking: XOR data with random values during processing, unmask at the end
Physical shielding: Make power measurements harder (but not impossible)

Timing Attacks

The Physical Basis

Propagation delay is the time it takes for a signal to propagate through a gate or circuit. This delay depends on:

Gate complexity: XOR gates (which require more transistors) are slower than NAND gates
Fanout: Driving more inputs increases delay
Voltage and temperature: Environmental factors affect transistor switching speed

Most critically for security: Execution time often depends on the data being processed.

String Comparison Attack

Consider a naive password check:

int check_password(const char* input, const char* secret) {
    for (int i = 0; i < strlen(secret); i++) {
        if (input[i] != secret[i]) {
            return 0;  // FAIL
        }
    }
    return 1;  // SUCCESS
}

This function compares characters one-by-one and exits immediately on mismatch.

Timing behavior:

If input[0] is wrong, the function returns instantly
If input[0] is correct but input[1] is wrong, the function takes slightly longer
If the first N characters are correct, the function runs for N+1 comparison cycles

An attacker can measure this:

import time

def guess_character(position, known_prefix):
    best_char = None
    longest_time = 0
    
    for char in string.printable:
        attempt = known_prefix + char
        start = time.perf_counter()
        server.check_password(attempt)  # network request
        elapsed = time.perf_counter() - start
        
        if elapsed > longest_time:
            longest_time = elapsed
            best_char = char
    
    return best_char

# Attack
password = ""
for position in range(password_length):
    password += guess_character(position, password)

Instead of brute-forcing 62^10 combinations for a 10-character alphanumeric password, the attacker makes 62 × 10 = 620 attempts.

Countermeasure: Constant-time comparison.

int check_password_safe(const char* input, const char* secret) {
    int diff = 0;
    for (int i = 0; i < strlen(secret); i++) {
        diff |= input[i] ^ secret[i];
    }
    return diff == 0;  // Always compares all characters
}

This version always runs the full loop regardless of where the mismatch occurs.

Cache Timing Attacks

Modern CPUs use cache hierarchies (L1, L2, L3) to speed up memory access. Accessing data in cache is fast (~1-4 cycles). Accessing data in RAM is slow (~200+ cycles).

The vulnerability: Cache access patterns leak information about what memory addresses were accessed.

Prime+Probe attack:

Prime: Fill the cache with attacker-controlled data
Wait: Let the victim process run
Probe: Access the primed data and measure time
If access is fast, the data is still in cache (victim didn't touch it)
If access is slow, the data was evicted (victim accessed nearby memory)

By monitoring which cache sets are evicted, an attacker infers which memory addresses the victim accessed, even across process boundaries, even across VMs.

Real-world examples:

Spectre/Meltdown: Cache timing side-channels that read kernel memory from user space
AES cache timing: Recover AES keys by observing cache access patterns during S-box lookups
RSA cache timing: Extract private keys from modular exponentiation by monitoring which memory regions are accessed

Network Timing Attacks

Timing attacks work over networks too.

SSH timing attack (Albrecht et al., 2009):

OpenSSH used to process password characters sequentially in the authentication handshake. By measuring packet timing, attackers could infer password length and reduce the search space for brute-force attacks.

TLS padding oracle (Lucky 13, POODLE, BEAST):

TLS implementations sometimes leak timing information during padding validation. By measuring how long it takes the server to reject a malformed packet, attackers can decrypt ciphertext byte-by-byte.

Countermeasures

Constant-time algorithms: Ensure execution time is independent of secret data
Blinding: Randomize intermediate values during computation
Cache partitioning: Isolate processes at the cache level
Add random delays: Make timing measurements noisier (defense in depth, not a primary solution)

Fault Injection Attacks

The Physical Basis

Logic gates interpret voltage states based on thresholds:

Voltage below ~0.8V → Logic 0
Voltage above ~2.0V → Logic 1
Voltage between → undefined behavior

Under normal operation, digital circuits stay in the defined ranges. But what if an attacker deliberately pushes the circuit into the undefined region?

Voltage Glitching

Attack setup: The attacker controls the power supply to the target device.

Attack execution:

Let the device boot and start running
At a precise moment, drop the supply voltage from 5V to 1.5V for 100 nanoseconds
Restore voltage to 5V

What happens:

The CPU continues executing, but some logic gates misinterpret signals during the glitch:

A critical comparison (if (password_correct)) might flip from 0 to 1
A counter might skip a value
A cryptographic operation might produce an incorrect result

Example: Bypassing secure boot

Many embedded systems have a secure boot flow:

if (verify_signature(bootloader)) {
    load_bootloader();
} else {
    halt();
}

The verify_signature function computes a cryptographic hash and compares it to a signature. If an attacker glitches the power supply during the comparison, the result might flip from "invalid" to "valid."

Now the device boots unsigned code.

Clock Glitching

Instead of varying voltage, the attacker injects extra clock cycles or removes expected cycles.

CPUs rely on a clock signal to coordinate operations. Each instruction takes a fixed number of clock cycles. If the attacker briefly doubles the clock frequency or injects a spurious edge, the CPU might:

Skip an instruction
Execute an instruction twice
Corrupt a register value

Example: Skipping loop iterations

for (int i = 0; i < 1000000; i++) {
    hash = update_hash(hash, data[i]);
}

If the attacker glitches the clock during the loop counter increment, the loop might exit early. The resulting hash is based on incomplete data. In a signature verification context, this might allow a forged signature to pass.

Differential Fault Analysis (DFA)

DFA combines fault injection with cryptographic analysis.

Target: AES encryption

AES processes data in multiple rounds. If an attacker can inject a fault during the second-to-last round, the fault propagates to the final output in a predictable way.

Attack steps:

Encrypt the same plaintext multiple times
Inject faults at precise moments during execution
Collect both correct and faulted ciphertexts
Analyze differences between correct and faulted outputs
Use cryptographic analysis to reverse-engineer the key

DFA has been demonstrated against AES, DES, RSA, and elliptic curve cryptography.

Rowhammer

Rowhammer exploits DRAM physics rather than logic gates, but the principle is similar.

DRAM stores bits in tiny capacitors. Each cell is a "bucket" holding a charge (1) or no charge (0). Reading a row of DRAM ("activating" it) causes electrical interference with adjacent rows. The problem is a physical one: as DRAM cells have shrunk with each process node, the insulation between cells has become thinner. When you activate a row repeatedly, electromagnetic coupling causes charge to leak between adjacent cells. You can flip bits in nearby rows without directly accessing them by literally disturbing the charge stored in neighboring capacitors.

Security impact:

Escalate privileges by flipping bits in page table entries
Escape virtual machine sandboxes
Bypass cryptographic checks by corrupting keys in memory

Mitigation is hard: Rowhammer is a hardware vulnerability in commodity DRAM. Software mitigations include:

Memory refresh rate increases (performance cost)
ECC memory (detects/corrects some bit flips)
Kernel-level access restrictions (slow down attacks)

Countermeasures

Sensors and monitoring: Detect abnormal voltage or clock signals
Redundant execution: Run critical checks multiple times
Error detection codes: Use checksums and parity to detect corruption
Physical tamper resistance: Encapsulate chips in epoxy, use mesh layers to detect physical intrusion
Secure elements: Use dedicated hardware designed to resist fault injection

Why Side-Channels Matter

Traditional security assumes the abstraction is perfect. Cryptographic proofs assume:

AES operations take zero time
Power consumption is constant
Gates don't flip when glitched

These assumptions break in the physical world.

Side-channel attacks exploit the gap between the logical model (truth tables, algorithms, cryptographic proofs) and the physical implementation (transistors, voltage, timing).

The Adversarial Perspective

Every abstraction boundary is a potential vulnerability. If you understand only the high-level behavior, you miss attack surface.

Understanding physical implementation reveals:

What leaks: Power, timing, EM radiation, acoustic signals
What's exploitable: Conditional branches, data-dependent operations, unvalidated inputs
What's measurable: Microsecond timing differences, millivolt power fluctuations

Modern attacks combine side-channels with other techniques:

Spectre: Uses speculative execution + cache timing
Plundervolt: Undervolts the CPU to corrupt SGX enclave memory
VoltJockey: Exploits DVFS (dynamic voltage/frequency scaling) to inject faults

The Defender's Challenge

Defending against side-channels is hard because:

Physics is unavoidable: Every operation consumes power and takes time
Abstractions hide the problem: Compilers and high-level languages don't expose timing or power characteristics
Attacks improve continuously: New techniques emerge as hardware evolves

Defense requires:

Designing constant-time algorithms
Using dedicated cryptographic hardware
Implementing physical tamper resistance
Monitoring for abnormal behavior

But even with all these measures, perfect side-channel resistance is impossible. Physics constrains what's achievable.

Practical Implications

For Developers

When writing security-critical code:

Use constant-time comparison for secrets (passwords, keys, tokens)
Avoid branching on secret data
Use cryptographic libraries designed for side-channel resistance (libsodium, BearSSL)
Test on actual hardware, not just in theory

What to avoid:

# VULNERABLE: Early exit leaks timing
if user_input == secret_token:
    grant_access()
else:
    deny_access()

What to use:

# SAFER: Constant-time comparison
import hmac
if hmac.compare_digest(user_input, secret_token):
    grant_access()
else:
    deny_access()

Note: hmac.compare_digest is implemented in C specifically to avoid timing leaks. The Python language maintainers recognized that even at the abstraction layer, you cannot ignore the physics. The C implementation ensures that comparison time depends only on length, not on where the first difference occurs.

For System Architects

When designing systems:

Isolate sensitive operations in secure enclaves (Intel SGX, ARM TrustZone)
Use hardware security modules (HSMs) for key storage
Implement rate limiting to slow down timing attacks
Monitor for abnormal power consumption patterns

For Researchers and Red Teams

When analyzing targets:

Map the abstraction stack: What is the high-level behavior? What is the physical implementation?
Identify data-dependent operations: Loops with early exits, conditional branches on secrets
Measure observable behavior: Timing, power, EM emissions
Correlate observations with hypotheses about internal state

Conclusion

Truth tables describe perfect logic. Physical circuits are messy.

Gates consume power when they switch. Operations take time. Voltage thresholds can be manipulated. Every physical characteristic is potentially observable.

Side-channel attacks exploit these observations to extract information that should remain hidden. Power analysis recovers cryptographic keys. Timing attacks break authentication. Fault injection bypasses security checks.

The gap between abstraction and reality is not a flaw in the abstraction. It's an inherent property of physical implementation. Logic is clean. Physics is observable.

Understanding this gap transforms how you think about security.

When you see a truth table, you no longer see just a grid of 0s and 1s. You see voltage states, power consumption, timing characteristics, and exploitable physical behavior.

The abstraction is useful. The implementation is vulnerable.

Security lives in the space between them.