https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
That's on the local network. I remember a paper doing this over the internet, but couldn't find it. A similar one over the internet:
https://www.usenix.org/conference/usenixsecurity20/presentat...
But in practice it's going to be malicious JS running in your browser: https://www.schneier.com/blog/archives/2021/03/exploiting-sp...
> The GoFetch attack is based on a CPU feature called data memory-dependent prefetcher (DMP), which is present in the latest Apple processors. We reverse-engineered DMPs on Apple m-series CPUs and found that the DMP activates (and attempts to dereference) data loaded from memory that "looks like" a pointer. This explicitly violates a requirement of the constant-time programming paradigm, which forbids mixing data and memory access patterns.
> To exploit the DMP, we craft chosen inputs to cryptographic operations, in a way where pointer-like values only appear if we have correctly guessed some bits of the secret key. We verify these guesses by monitoring whether the DMP performs a dereference through cache-timing analysis. Once we make a correct guess, we proceed to guess the next batch of key bits. Using this approach, we show end-to-end key extraction attacks on popular constant-time implementations of classical (OpenSSL Diffie-Hellman Key Exchange, Go RSA decryption) and post-quantum cryptography (CRYSTALS-Kyber and CRYSTALS-Dilithium).
It sounds like the OpenSSL code is still constant time (it doesn't expect pointers in the intermediate values, to OpenSSL it is just data, not something it will ever dereference) but the attacker-controlled "monitoring" code's runtime changes based on whether the DMP ran or not.
If that's right, then the attacker still needs to run their monitoring code on the target, it isn't sufficient to just run OpenSSL etc itself.
Edit: it is more explicit in the paper, they assume that OpenSSL (the victim) is still constant time:
> In this paper we assume a typical microarchitectural attack scenario, where the victim and attacker have two different processes co-located on the same machine.
> For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform private key operations. Next, we assume that the victim is constant-time software that does not exhibit any (known) microarchitectural side-channel leakage. Finally, we assume that the attacker and the victim do not share memory, but that the attacker can monitor any microarchitectural side channels available to it, e.g., cache latency.
But I think you might overall be right that this requires two colocated processes: the paper talks about how the DMP breaks assumptions made by "the constant-time programming model", and I took this to mean that constant-time algorithms aren't constant-time any more. Reading more closely, I think maybe the issue is that "the constant-time programming model" was also assumed to make secrets safe from cache timing side-channels leaking the secrets to other processes on the same CPU, and this seems like it might be the assumption that's broken by the DMP...
I'll have to read more, I've just skimmed the abstract and introduction so far.
In any case, the stack of "this could not possibly be workable / but with enough statistics it can, and computers are plenty fast to generate statistically useful case numbers" is truly mindboggling with these attack vectors.