The Ghost in the Prefetcher: How GoFetch Breaks Constant-Time Cryptography on Apple Silicon Without a Single Software Bug

In modern computer security, there is one sacred covenant that software cryptographers rely upon above all others: the constant-time execution model. For twenty years, software engineers knew that writing cryptographic code meant avoiding secret-dependent branching. If an encryption algorithm checks secret key bits using `if/else` statements or accesses memory arrays based on private keys, CPU cache timing reveals the secret. So cryptographers wrote rigorous, mathematically verified “constant-time” algorithms—like OpenSSL, RSA, and post-quantum Kyber—where execution always takes the exact same number of clock cycles regardless of whether a key bit is a `0` or a `1`.

On Apple Silicon MacBooks and iPads, that sacred covenant has been shattered. A team of academic security researchers unveiled GoFetch: an astonishing microarchitectural vulnerability in Apple’s M1, M2, and M3 processor architectures. Without exploiting a single software bug, memory overflow, or operating system loophole, an unprivileged user process can silently extract 2048-bit RSA keys, 256-bit elliptic curve private keys, and post-quantum cryptographic secrets in under an hour.

The culprit is not a software flaw. It is a hardware optimization feature hardwired directly into Apple’s silicon execution engine called the Data Memory-Dependent Prefetcher (DMP). In its relentless pursuit of CPU performance, Apple built a prefetcher so aggressive that it literally mistakes cryptographic secret numbers for virtual memory pointers—and leaks your private keys straight through the CPU cache.

How Prefetchers Work: The Speed vs. Security Gamble

To understand why GoFetch is such an architectural earthquake, you have to look at the latency chasm between CPU execution cores and main system RAM. A modern Apple M-series core can execute dozens of arithmetic operations per nanosecond. But fetching a piece of data from system memory takes 70 to 100 nanoseconds. If the CPU has to wait for RAM on every memory load, it spends 95% of its time sitting completely idle.

To mask this memory latency, modern processors use hardware prefetchers. Classical prefetchers (like stream prefetchers and stride prefetchers) analyze the history of memory access patterns. If a program reads memory address `0x1000`, `0x1008`, and `0x1010`, the stride prefetcher detects the sequential pattern and proactively pulls `0x1018` into the L2 cache before the CPU explicitly asks for it.

Crucially, classical prefetchers only look at addresses, never at data. They don’t care what numbers are stored inside the cache line; they only care where the program is looking.

The Fatal Optimization: Apple’s Data Memory-Dependent Prefetcher

In Apple Silicon (starting with the original M1 and inherited by M2 and M3), Apple’s chip architects implemented an exotic, hyper-aggressive prefetcher: the Data Memory-Dependent Prefetcher (DMP).

Apple recognized that in complex modern software—like web browsers, JavaScript engines, and compiled Objective-C/Swift runtimes—programs spend immense time “pointer-chasing”: reading an object in memory, extracting a pointer stored inside that object, and following that pointer to another object. A traditional stride prefetcher is completely useless for pointer-chasing because object pointers are scattered randomly across memory.

Apple’s DMP solved this by doing something radical: it inspects the actual data values inside loaded cache lines!

When data arrives in the L1/L2 cache, the DMP hardware scans the 64-byte cache line and examines every 64-bit integer. If an integer looks like a valid virtual memory address within the application’s memory space, the DMP autonomously issues an out-of-order speculative memory read for that address! It doesn’t wait for a CPU `LOAD` instruction; it just grabs the data proactively.

The Trap: When Numbers Look Like Pointers

In normal software, the DMP is an engineering triumph that accelerates complex application workloads by up to 15%. But in cryptographic software, it is a catastrophic security disaster.

When an encryption algorithm computes RSA, Elliptic Curve, or post-quantum Kyber handshakes, it multiplies large multi-precision integers. Those intermediate mathematical secrets are stored in memory arrays. To the programmer and the operating system, those numbers are pure data—scalar coefficients, polynomials, or private keys.

The DMP hardware has no idea what cryptography is. It cannot distinguish between a memory pointer pointing to a web page element and a mathematical private key number. If a secret key number happens to match a valid virtual address, the DMP treats it as a pointer and speculatively loads that address from memory!

The GoFetch Attack: Weaponizing Chosen Ciphertexts

How does GoFetch turn this speculative prefetcher behavior into an exploit that steals complete private keys?

The researchers discovered that while an attacker cannot directly view secret key bits, they can supply chosen-ciphertext inputs to the victim’s cryptographic routine (for example, sending specially crafted encrypted messages to an SSH daemon or web server):

1. Input Crafting: The attacker crafts a ciphertext designed to mathematically interact with the victim’s secret key during decryption.
2. Bit Conditioning: If a specific secret key bit is a `1`, the mathematical result generates a number that matches a valid virtual memory address monitored by the attacker. If the key bit is a `0`, the result is a random number that does not match a valid address.
3. The DMP Trigger: If the bit is a `1`, the DMP activates, speculatively reading the address and evicting an existing cache line from the shared CPU L2 cache.
4. Cache Prime+Probe: The attacker monitors the L2 cache using standard Prime+Probe timing. If the attacker’s cache line was evicted (fast access vs. slow access), the attacker knows with 100% certainty that the secret bit was a `1`!

By repeating this process across thousands of decryption queries, GoFetch reconstructs the private key bit by bit. In empirical laboratory tests, GoFetch extracted:

• 2048-bit RSA Private Keys: Completely recovered in under 54 minutes.
• 256-bit ECDSA Keys: Completely recovered in under 18 minutes.
• CRYSTALS-Kyber-512 (Post-Quantum): Completely extracted in under 140 minutes!

The Unfixable Silicon: Why Software Cannot Patch M1 and M2

When the cybersecurity world discovered vulnerabilities like Meltdown and Spectre in Intel chips, operating system vendors rolled out microcode and kernel patches. Why can’t Apple simply patch GoFetch with a macOS software update?

Because on the M1 and M2 processor families, the DMP cannot be disabled in hardware! Apple did not include a hardware configuration register to turn off the Data Memory-Dependent Prefetcher on performance cores. The feature is permanently etched into the silicon.

Software developers and macOS updates have only two painful workarounds on M1 and M2:

• Offload Cryptography to Efficiency Cores: The low-power Icestorm/Blizzard E-cores on Apple Silicon do not contain a DMP. Operating systems can force all cryptographic libraries to execute exclusively on E-cores. However, E-cores have significantly lower clock speeds and narrower execution widths, causing cryptographic operations to slow down by up to 300%.
• Defensive Blinding Instructions: Cryptography developers can inject random mathematical masking (blinding) before every operation and unblind afterwards. This prevents intermediate secrets from mirroring predictable virtual addresses, but adds massive computational overhead.

On newer M3 and M4 chips, Apple added a special architectural register called the DIT (Data-Independent Timing) bit that allows developers to disable the DMP selectively during cryptographic loops. But enabling DIT disables Apple’s pointer prefetching optimizations, leaving performance on the table.

The Broader Warning: Silicon Complexity vs. Zero-Trust Security

Much like our examination of LeftoverLocals GPU memory leaks, GoFetch exposes the growing chasm between software abstractions and hardware reality. Modern microarchitectures have become so extraordinarily complex—with speculative branch predictors, memory-dependent prefetchers, and out-of-order execution windows hundreds of instructions deep—that hardware designers can no longer anticipate every side-channel leak.

For everyday Mac users, GoFetch does not mean your laptop is immediately infected; an attacker must still convince you to run a malicious native binary on your machine. But for cloud providers, financial institutions, and cryptocurrency platforms processing millions of automated transactions on Apple Silicon hardware, GoFetch is a chilling reminder that in hardware engineering, speed and security are forever locked in a zero-sum game.

Frequently Asked Questions