New vuln in Apple M-series allowing secret keys extraction can't be patched
A newly disclosed “GoFetch” side‑channel vulnerability in Apple’s M‑series chips can leak cryptographic keys from user‑space software by abusing a data-dependent prefetcher, and appears unfixable in existing M1 and M2 hardware. Commenters note that keys stored in the Secure Enclave remain safe, but any crypto done in normal CPU code — including TLS or password managers — could in theory be at risk if an attacker can run code locally and trigger repeated operations. The finding reignites broader concerns over speculative and prefetch optimizations, the trend of centralizing identity and payments on a single device, and the trade‑off between performance, security, and the long hardware replacement cycles for consumers.
Nature of the vulnerability
- Side‑channel attack, dubbed GoFetch, on Apple M‑series data memory‑dependent prefetcher (DMP).
- Breaks assumptions of constant‑time crypto by speculatively prefetching data that “looks like” pointers.
- Allows extraction of keys from common crypto implementations (OpenSSL DH, Go RSA, Kyber, Dilithium) when attacker can feed chosen inputs and monitor cache timings.
- Works on M1 and M2; M3’s DIT bit can disable the problematic behavior when libraries opt in.
- Secure Enclave keys are reported as unaffected; attack targets user‑/kernel‑space crypto, not enclave‑stored keys.
Practical exploitability & threat models
- Requires: unprivileged attacker code on the same machine and the ability to trigger repeated private‑key operations for a long period.
- Discussion emphasizes co‑located processes; remote‑only attacks over a network are viewed as impractical due to tiny timing deltas and noise, though some cite prior remote timing work in general.
- Possible vectors debated: malicious JavaScript in browsers, shared servers, password managers, TLS session keys, client certs. Realistic end‑to‑end scenarios remain unclear.
Impact on average users
- One side: “total non‑issue” for most; risk far outweighed by social engineering, password reuse, and unpatched software.
- Other side: dismissing it repeats early Spectre/Meltdown attitudes; JS proofs‑of‑concept eventually appeared there too.
Centralization of identity, payment, and apps
- Strong critique of phones as single points of failure for identity, payments, and app auth.
- Preference for physically separate tokens (bank hardware devices, smartcards) with legally backed responsibilities and distinct “rituals” for high‑value actions.
- Counter‑view: mobile‑centric ecosystems with biometrics (Apple Pay, passkeys) have significantly improved security/convenience and are widely accepted by banks and regulators.
Speculation, prefetching, and CPU design
- Broader worry that speculative techniques and prefetchers are inherently risky for crypto.
- Suggestions: hardware flags or modes for constant‑time crypto, dedicated secure hardware (TPM, Secure Enclave, HSMs, hardware keys), or even cores/CPUs dedicated to “trusted vs untrusted” code.
- Others argue speculation is essential for modern performance; the real gap is a formal side‑channel model.
Other reactions
- Some accuse the “can’t be patched” framing of being clickbait; others note lack of any known M1/M2 mitigation despite coordinated disclosure.
- Debate over “security through obscurity” and whether more open architectures (e.g., RISC‑V) improve trust in the hardware root.