It looks like it targets AES and keystrokes if they're processed on the GPU. They detect which parts of AES lookup tables (T-Tables) are getting added to the cache, which gives information about the key (section 6).
> Despite the high recall, with the low precision, we can consider this attack mostly failed or severely degraded
And in to what I said originally (who is actually doing AES on a GPU?) it sounds like the key recovery is also impractical:
> In order to implement a last-round attack, we assume the attacker has access to the victim’s ciphertexts, but not the plaintext or the key.
How exactly is a browser supposed to get access to the ciphertext in the first place?
MITM attacks are usually considered relatively easy to pull off. Run a fake wifi-hotspot in an airport, use the "login portal" to get access to their browser, use the hotspot itself to get access to the cipher texts when they visit other https page (edit: I suppose those would be decrypted on the CPU... but when they use whatever odd program that thought decrypting messages to it on the GPU is a good idea).
It's obvious they accomplished something, but the scenario they set up simply isn't something that is practical in the real world
Modern CPUs can decrypt AES with specialized instructions at a rate that's practically measured in GB/s. Especially for streaming video that doesn't need to decrypt the full stream at once (and where you're probably already using the GPU to, you know, render the video) why would you use the GPU for AES?
Even then, the best that I know of for password recovery from timing is "Timing Analysis of Keystrokes and Timing Attacks on SSH", which relies on having data about the user in advance, and they only manage to reduce the search space by about 50x. I'm sure the state of the art is probably a bit better, but that's still assuming a lot: key press timing (that's probably noisy) isn't going to be a meaningful attack vector for arbitrary users online.
that said, I don't expect to see any of these attacks in the wild. they're primarily demonstrations of the technique and to show that the channel is there
as is often the case with side-channel attacks, a serious attacker would much more likely go for un-/recently patched traditional vulnerabilities
We tried to walk the line between enough information and not overwhelming, but it doesn't always work out :D Luckily there's always the paper.
This article also did a pretty good job of a high-level summary imo https://www.securityweek.com/new-attack-shows-risks-of-brows...
> The team was able to track changes in the cache by filling it themselves using code in the JavaScript via WebGPU and monitoring when their own data was removed from the cache by input. This made it possible to analyse the keystrokes relatively quickly and accurately. By segmenting the cache more finely, the researchers were also able to use a second attack to set up their own secret communication channel, in which filled and unfilled cache segments served as zeros and ones and thus as the basis for binary code. They used 1024 of these cache segments and achieved transfer speeds of up to 10.9 kilobytes per second, which was fast enough to transfer simple information. Attackers can use this channel to extract data that they were able to attain using other attacks in areas of the computer that are disconnected from the internet.
I don't understand which cache they're talking about, and why this has anything to do with keystrokes. And suggesting the use of cache invalidation to transmit information from one process to the browser doesn't really sound like a very concerning attack vector (how did you get a process running on the host computer in the first place, but without Internet access?)
> The third attack targeted AES encryption, which is used to encrypt documents, connections and servers. Here, too, they filled up the cache, but with their own AES encryption. The reaction of the cache enabled them to identify the places in the system that are responsible for encryption and access the keys of the attacked system.
Sorry, what? No part of this tracks for me. Who is even using the GPU for AES encryption? Or is this looking at the CPU cache by way of webgpu?
If there's good work being done here, this article is frankly doing it a massive disservice.