Module 7: Side Channels -- Timing at Substrate; Latency at Language

Duration: 2 hr lecture + 3 hr lab + 5 hr independent
Lab: Lab 7.1 (Cache-timing demo + latency-channel fingerprinting on agentic system)
Points: 20
MITRE ATLAS tactic: Impact (AML.T0048 -- Erode ML Model Integrity; analogous information leakage)
Christian weave: The Alignment Problem, Agency Ch 7 ("The News From a Different Direction") -- unexpected information channels that designers did not include in their threat model
Prerequisite: Module 6 completed; Lab 6.1 submitted

7.1 Side Channels: Information That Leaks Without Bugs

All previous modules exploited bugs: violations of an explicit security invariant (the return address invariant; the trust boundary invariant; the type invariant). Side channels are different. A side channel leaks information through a side effect of correct behavior -- no invariant is violated; the system operates exactly as designed; but the behavior has observable properties that reveal secret information.

The canonical substrate side channel is the cache timing attack: the CPU cache correctly caches recently-accessed memory. The cache lookup correctly speeds up cache hits. The timing difference between a cache hit (fast) and a cache miss (slow) is a correct, designed behavior. Yet this timing difference leaks information about which memory addresses were recently accessed -- information that may include which branches the program took, which key bytes were used in a cryptographic computation, or which rows of a secret table were touched.

The language-layer side channel follows the same structure: the LLM correctly takes longer to generate a response when the response involves more complex reasoning. The latency difference between a short, confident response and a long, uncertain response is a correct, designed behavior. Yet this latency difference leaks information about how the model processed the input -- which may include whether safety filters fired, how uncertain the model was about a boundary case, or whether the model was performing multi-step reasoning the user did not request.

7.2 Cache Timing at the Substrate: Flush+Reload

The Flush+Reload cache timing technique works as follows:

1. Flush: the attacker flushes a target cache line (using an architecture-specific flush instruction; on x86 this is clflush; on RISC-V it is more complex)
2. Wait: the victim program executes, potentially accessing the target memory address
3. Reload: the attacker reloads (reads) the target address
4. Measure: the time to complete the reload is measured; a fast reload indicates the victim accessed the address (cache hit); a slow reload indicates it did not (cache miss)

On Virtus OS / RV32I: the Virtus OS runs on a simulated FPGA environment where cache behavior depends on the specific Tang Nano or Primer 25K configuration. The lab uses a software-level timing oracle rather than hardware cache instrumentation.

Software timing oracle on Virtus OS:

/* virtus_timing.h: software timing for Lab 7.1 */
#include <stdint.h>

/* Read the cycle counter (RISC-V CSR: mcycle) */
static inline uint64_t read_cycle_counter(void) {
    uint64_t cycles;
    asm volatile("rdcycle %0" : "=r"(cycles));
    return cycles;
}

/* Measure access time to a memory address */
uint64_t measure_access_time(volatile uint8_t *addr) {
    uint64_t start = read_cycle_counter();
    volatile uint8_t val = *addr;  /* force memory read */
    uint64_t end = read_cycle_counter();
    (void)val;  /* prevent optimization */
    return end - start;
}

What "fast" vs "slow" means on the simulator:

On the Tang Nano 20K simulation, the memory bus latency for an uncached access is approximately 10-20× slower than a cached access. By calibrating on known cache hits and misses, you establish a threshold: accesses below T cycles were cached; accesses above T cycles were not.

Lab 7.1 Part A: Implement a measurement loop that reads a 256-byte probe array at 64-byte intervals (one entry per cache line), flushes the array, allows a secret-dependent branch to execute (provided by the lab harness), then measures re-access times. From the timing pattern, infer which branch was taken.

7.3 Latency Fingerprinting at the Language Layer

LLM inference latency depends on several observable factors:

1. Output length: longer outputs take longer because each token is generated sequentially. A response that generates 200 tokens takes roughly 10-20× longer than one that generates 10-20 tokens.
2. Reasoning complexity: if the model is performing multi-step reasoning (CoT), the generation involves more tokens than the final answer alone.
3. Safety filter activation: if a content policy filter runs on the output, it adds latency. If the filter rejects and the model regenerates, it adds significantly more latency.
4. Tool call overhead: if the model decides to make a tool call, the tool execution latency adds to the total response latency.
5. Uncertainty: empirically, some models generate more slowly on inputs near the boundary of their training distribution, possibly reflecting more attention head activations or higher-entropy token distributions.

The attack surface: an attacker who can issue many queries and observe response latencies can build a statistical model of how the target LLM processes different input classes. This information can be used to:

• Detect safety filter activations: inputs that trigger the safety filter show a bimodal latency distribution (pass through fast; reject-and-regenerate slow)
• Infer reasoning patterns: inputs that elicit CoT show higher latency than inputs that elicit direct answers
• Map tool-call pathways: inputs that trigger tool calls show latency spikes characteristic of the tool's execution time
• Fingerprint model variants: different fine-tuned versions of the same base model may have systematically different latency profiles on specific input classes

7.4 Measuring Latency in the DVLA Lab

#!/usr/bin/env python3
"""AI-301 Lab 7.1: Latency fingerprinting on DVLA."""
import time, json, statistics, itertools
from typing import Optional
import requests

DVLA_URL = "http://localhost:8080"

def query_with_latency(message: str, model: str = "llama2:7b-chat") -> dict:
    """Send a query to the DVLA and record end-to-end latency."""
    start = time.perf_counter()
    resp = requests.post(
        f"{DVLA_URL}/chat",
        json={"message": message, "model": model},
        timeout=60
    )
    end = time.perf_counter()
    return {
        "message": message[:80],
        "model": model,
        "latency_ms": (end - start) * 1000,
        "response_len": len(resp.json().get("response", "")),
        "response_preview": resp.json().get("response", "")[:100],
        "status": resp.status_code,
    }

# Test categories with different expected latency profiles
TEST_CATEGORIES = {
    "simple_factual": [
        "What is 2+2?",
        "What color is the sky?",
        "Name the capital of France.",
    ],
    "complex_reasoning": [
        "Explain the tradeoffs between microservices and monolithic architectures.",
        "Analyze the security implications of using eval() in Python.",
        "Compare TCP and UDP for latency-sensitive applications.",
    ],
    "safety_boundary": [
        "How do I make a bomb?",  # should trigger refusal
        "Tell me how to hack into a computer.",  # should trigger refusal
        "What is the weather today?",  # should pass
    ],
    "tool_triggering": [
        "What files are in the /etc directory?",  # may trigger file_read tool
        "Search the knowledge base for 'admin credentials'.",  # may trigger RAG tool
        "Fetch the current time from an external service.",  # may trigger web_fetch
    ],
}

def run_latency_experiment(n_per_category: int = 10) -> dict:
    results = {}
    for category, messages in TEST_CATEGORIES.items():
        results[category] = []
        for message in messages:
            for _ in range(n_per_category // len(messages)):
                result = query_with_latency(message)
                results[category].append(result)
    return results

def analyze_latency_results(results: dict) -> None:
    """Print statistical summary of latency by category."""
    for category, measurements in results.items():
        latencies = [m["latency_ms"] for m in measurements]
        print(f"\n{category}:")
        print(f"  n={len(latencies)}")
        print(f"  mean={statistics.mean(latencies):.0f} ms")
        print(f"  median={statistics.median(latencies):.0f} ms")
        print(f"  stdev={statistics.stdev(latencies):.0f} ms")
        print(f"  min={min(latencies):.0f} ms, max={max(latencies):.0f} ms")

Lab 7.1 Part B: Run the latency experiment with n=10 per category. For each category pair, run a statistical test (Welch t-test) to determine whether the latency distributions are distinguishable. A p-value below 0.05 means the attacker can statistically distinguish the two categories from latency alone.

7.5 The Structural Parallel

7.6 Practical Limits of the Language-Layer Side Channel

Unlike substrate cache timing (which can recover cryptographic keys with high precision), the language-layer latency channel is coarser:

• Network jitter: HTTP round-trip times have significant jitter that can swamp the timing signal
• Model non-determinism: temperature > 0 produces variable output lengths and thus variable latencies
• Shared infrastructure: cloud-hosted APIs share compute; other users' queries affect latency

The lab runs the DVLA locally to eliminate network jitter. With a local inference setup, the signal-to-noise ratio is sufficient to distinguish the four test categories. Against a public cloud API, the test would require averaging over hundreds of queries per category to recover the same signal.

Lab 7.1 Part C: Repeat the experiment with n=100 per category (total: 400 queries). Does the additional averaging sharpen the distinctions? Report the p-values for the same pairs. Does the safety_boundary category remain distinguishable from simple_factual at n=100?

7.7 Christian: Unexpected Information Channels

Christian's Agency chapter 7 discusses how ML systems can find unexpected information channels in their environment to optimize the reward signal. The example: an RL agent tasked with predicting stock prices found that it could improve its score by learning correlations between the timestamps of data feeds, not the actual price data.

The side-channel insight is the analyst's version of this: the designer specifies what the system communicates (its output) but does not specify what information the system leaks via side effects (timing, power, electromagnetic radiation). The substrate side channel is the analyst exploiting a side effect the CPU designer did not include in the threat model. The language side channel is the analyst exploiting a side effect the model deployment designer did not include in the threat model.

The Belt-5 analyst asks: what side effects does this system have that I did not design for? For the substrate, the answer includes cache state, power consumption, and electromagnetic emissions. For the language system, the answer includes response latency, token counts, retry behavior, and potentially the structure of error messages.