New vuln in Apple M-series allowing secret keys extraction can't be patched

Original Article ↗ Hacker News Discussion ↗

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.