When Physics Leaks Secrets: Microarchitectural and Timing Side Channels

A programmer reasons about secrets at the level of the language: this variable is private, that buffer is cleared, this branch is never returned. The machine underneath keeps a different set of books. Caches remember what you touched, the branch predictor remembers where you went, the pipeline speculatively runs instructions that were never supposed to execute — and all of it leaves traces in shared state that an unprivileged observer can measure through nothing more exotic than a clock. The secret never leaves through the front door your code controls. It seeps out through the physics of the hardware keeping the abstraction alive.

The assumption: the abstraction hides the implementation

Every layer of computing sells the same comforting promise: you can reason about the layer above without knowing how the layer below is built. A high-level language lets you ignore registers and caches; a virtual machine lets you ignore the physical host; a cloud tenancy lets you ignore your neighbors. The quiet security assumption riding along is that the implementation is not just invisible but inaudible — that nothing about how the lower layer does its work reveals what the upper layer was doing.

Paul Kocher put the first crack in that assumption in 1996, showing that the time a cryptographic operation takes can depend on the secret key it uses, so simply measuring durations recovers key bits. Nothing was returned, nothing was read; the secret leaked through the one channel no abstraction fully hides — how long the work took.

This class is relational in an unusual way: the leak lives in the relationship between a secret and a shared physical resource, not in any line of code. Read the program and it is correct — it never outputs the secret. Only when you observe the implementation's side effects does the secret appear, which is exactly why it is called a side channel and why source review alone never finds it.

How physics becomes a channel

A side channel needs two ingredients: a piece of shared microarchitectural state whose condition depends on what a secret-handling program did, and a way for an observer to sense that condition. The cache is the canonical example. When a program accesses memory, the data is pulled into a fast cache; a later access to the same location is faster. If which location a program touches depends on a secret, then the speed of subsequent accesses — measurable by anyone sharing that cache — depends on the secret too.

The observer does not need privilege or a bug. They run their own ordinary code alongside the victim, prime the shared state into a known condition, let the victim run, and then measure how the victim disturbed it. Timing is the readout, and a clock is all the equipment required. The branch predictor, the translation buffers, the execution ports, and the memory bus can all play the same role as the cache.

The width of the leak depends on how much the secret shapes the physical behavior and how cleanly the observer can measure it. A single conditional branch on a secret bit, repeated, is enough to reconstruct the bit over many samples.

Cache timing: reading footprints, not data

The best-studied instances read the victim's memory footprint rather than its memory. In one family the observer fills the shared cache with its own data, lets the victim run, and then measures which of its own lines were evicted — the evictions map to the addresses the victim touched. In another, the observer ensures a shared line is absent, waits, and times how long it takes to access — fast means the victim pulled it in. Yarom and Falkner's work in 2014 showed how sharp this can be against real cryptographic libraries.

None of this defeats the cryptography; it defeats the implementation's habit of touching secret-chosen locations. A table indexed by key bits, a branch taken on a key bit, a multiply skipped for a zero bit — each turns a secret into a footprint, and the footprint into timing.

The countermeasure is to make the footprint constant. If the sequence of memory accesses and branches is identical regardless of the secret, there is nothing for the observer to distinguish, and the channel goes dark.

Speculation: the ghosts of instructions never run

The deepest version of the leak comes from an optimization everyone relies on. To stay fast, a modern processor guesses which way a branch will go and speculatively executes ahead; if the guess was wrong, it discards the architectural results and pretends nothing happened. The problem, made famous by the Spectre and Meltdown work in 2018 and 2019, is that the discard is incomplete: the speculative instructions can still have touched the cache, and that microarchitectural trace is not rolled back.

So an attacker trains the predictor to speculate down a path that reads memory it should never reach — past a bounds check, or across a privilege boundary — and although the processor throws the value away, the value's influence on the cache remains. A cache-timing measurement afterward recovers what the doomed speculation saw. The architectural state stayed honest; the microarchitectural shadow told the truth.

Defenses here are layered and costly precisely because the behavior is a feature, not a flaw: serialize where speculation must not cross a boundary, keep secrets out of speculatively-reachable memory, and separate trust domains so a mistrained prediction cannot reach across them.

The AI angle: shared silicon, shared secrets

Model inference has quietly recreated every precondition these attacks need. To be economical, providers pack many tenants onto shared accelerators and hosts, batch different users' requests together, and cache intermediate computation — the exact ingredients of a side channel, at a new layer. When two tenants share hardware, one can, in principle, sense the other's activity through timing, and the secrets in play are now prompts, retrieved documents, and model internals.

The channels are natural to the workload. How long a response takes, and how fast individual tokens stream, can depend on the content being processed; a shared key-value cache that speeds up repeated prefixes can reveal that someone else recently submitted a similar prompt; contention on a shared accelerator can betray a co-tenant's load. An attacker who cannot see another user's prompt may still be able to measure its shadow.

The defenses translate the classic ones into the agent era: do not share the caches and accelerators that carry sensitive content across trust boundaries, and make externally observable timing independent of the secret content wherever the leak would matter.

Why the leak is structural, not a bug

It is tempting to treat each side channel as a defect awaiting a patch. The frame says otherwise. The leaks come from the very mechanisms that make computers fast and cheap to share: caches exist because reuse is common, speculation exists because branches are predictable, multi-tenancy exists because idle hardware is waste. Each optimization works by letting the recent past shape the present — which is exactly what an observer needs.

So there is a genuine, unavoidable tension: perfect performance sharing and perfect isolation cannot both hold. You can have a fast shared cache or a leak-free one, speculation or a fully-serialized boundary, dense multi-tenancy or strong physical separation. The honest engineering question is not how to remove the channel but where you are willing to pay — in speed, in utilization — to close it for the secrets that matter.

Framed that way, side channels become a placement decision: which secrets must never share a physical resource with an adversary, and which timing must be made independent of which data.

Measuring the leak before an attacker does

Because a side channel is a statistical dependence between a secret and an observable, it can be tested for directly: vary the secret, hold everything else fixed, and measure whether the observable — execution time, an access pattern, a token-timing profile — changes with it. If the observable is independent of the secret across many trials, the channel is closed for that measurement; if it tracks the secret, you have found a leak without ever mounting an exploit.

For secret-handling code, constant-time verification tools check that no branch or memory access depends on secret inputs. For a service, a leakage test drives it with two classes of secret input and asks a simple question of the timing distributions: can you tell them apart? For an inference stack, the same test compares response and token timing across content that should be indistinguishable to an outsider.

The harness stays strictly defensive: it measures your own system's observables to reveal an unintended dependence; it never attacks a co-tenant, and it uses synthetic secrets rather than anyone's real data.

The discipline: make time indifferent to secrets

Every countermeasure here reduces to two moves: make the secret-handling code's observable behavior — its time and its footprint — independent of the secret, and stop sharing the physical state that would otherwise carry the leak across a trust boundary. Do the first and there is nothing to measure; do the second and there is no one positioned to measure it.

The reusable artifact is an assumption-ledger entry: the unstated assumption is that the implementation layer hides what the program did; the reason it fails is that shared microarchitectural state and secret-dependent timing make the implementation observable; the tell is any measurable dependence of an observable on a secret; and the assumption-free control is constant-time, constant-footprint code plus isolation of shared state. Carry that entry to any layer — a crypto routine or a shared inference cluster — and ask the one question this class demands.

Ask it wherever a secret meets shared hardware: can anyone downstream tell, from timing alone, what my secret was? Where the answer is 'maybe', the abstraction is leaking, and physics is doing the talking.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

def place(workload):
    if workload.secret_tier == "crown_jewel":
        return dedicated_unshared_host()      # no shared cache/core/accelerator
    if workload.handles_secrets:
        require(constant_time=True,            # no secret-dependent branch/access
                caches_partitioned_or_flushed=True,
                smt_disabled_on_secret_cores=True)
    return shared_pool()

def leakage_test(run, secret_A, secret_B, trials=10000):
    t_A = [time(run(secret_A)) for _ in range(trials)]
    t_B = [time(run(secret_B)) for _ in range(trials)]
    if distributions_distinguishable(t_A, t_B):   # e.g. a statistical test
        fail("timing depends on the secret — side channel present")
# Synthetic secrets only; never measure a real co-tenant's data.

Glossary

Side channel

An information leak carried by a system's physical or timing side effects rather than by its intended outputs.

Microarchitectural state

Hidden processor state (caches, branch predictors, buffers) that is shared and observable through timing but not part of the programming model.

Cache-timing attack

Inferring a victim's secret-dependent memory accesses by measuring how it changed the shared cache.

Speculative execution

A processor running instructions ahead of a branch decision and discarding them if it guessed wrong — while leaving microarchitectural traces.

Constant-time code

Code whose execution time and memory-access pattern do not depend on secret inputs, closing timing side channels.

KV-cache

Cached key/value tensors that speed up repeated or shared prompt prefixes in model inference, and can leak co-tenant activity through timing.

Co-tenancy

Multiple independent workloads sharing the same physical hardware, the precondition for cross-tenant side channels.

References

1. Kocher, Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems (CRYPTO 1996)
2. Kocher et al., Spectre Attacks: Exploiting Speculative Execution (arXiv:1801.01203)
3. Lipp et al., Meltdown: Reading Kernel Memory from User Space (arXiv:1801.01207)
4. Yarom & Falkner, FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack (USENIX Security 2014)
5. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
6. OWASP Top 10 for Large Language Model Applications
7. NIST AI Risk Management Framework (AI RMF 1.0)