Drive-by Key-Extraction Cache Attacks from Portable Code

Daniel Genkin Lev Pachmanov Eran Tromer Yuval Yarom
University of Pennsylvania
University of Maryland
Tel Aviv University Tel Aviv University
Columbia University
The University of Adelaide
This research was conducted at Tel Aviv University's Laboratory for Experimental Information Security (LEISec), in collaboration with the Centre for Distributed and Intelligent Technologies (CDIT) at the University of Adelaide.



We show how malicious web content can extract cryptographic secret keys from the user's computer. The attack uses portable scripting languages supported by modern browsers to induce contention for CPU cache resources, and thereby gleans information about the memory accesses of other programs running on the user's computer. We show how this side-channel attack can be realized in both WebAssembly and PNaCl; how to attain very fine-grained measurements; and how to use these to extract ElGamal, ECDH and RSA decryption keys from various cryptographic libraries.

The attack does not rely on bugs in the browser's nominal sandboxing mechanisms, or on fooling users. It applies even to locked-down platforms with strong confinement mechanisms and browser-only functionality, such as Chromebook devices.

Moreover, on browser-based platforms the attacked software too may be written in portable JavaScript; and we show that in this case even implementations of supposedly-secure constant-time algorithms, such as Curve25519's, are vulnerable to our attack.

Here is an example of an attack setup that can be used to attack a user's computer.

Screenshot of the attack scenario
Screenshot of the attack scenario. The target user opens an online streaming web-site in Tab . Pressing somewhere in this tab (for example to start a movie), causes a pop-under to open up as Tab . The malicious advertisement in Tab then monitors the cache activity on the target machine. When an encrypted email is received and decrypted using Google's encrypted email extension (in Tab ), the malicious advertisement in Tab learns information about the user's secret key.


Q1: What are some examples of attack scenarios?

The main attack scenario we investigate is a "drive-by" web attack, where the attacker's code is embedded in a web page and is automatically activated when this web page is rendered by the target's browser. This can happen when the targeted user explicitly visits the attacker's web page (e.g., enticed by phishing), or a web page into which the attacker can inject HTML code (e.g., by a cross-site scripting attack).

Most deviously, the attack can be automatically triggered when the user visits unrelated third-party web sites, if those sites display advertisement from a web advertising service that support non-static ads (whether as pop-under ads, IFRAME ads, or JavaScript).

One of the attack steps involved guessing which part of memory (cache set) leaks the key, and in the worst case this requires monitoring a thousand decryption operations. However, occasionally the attacker will be lucky in this guess and then extract the full secret key by monitoring as few as 4 decryption operations. If the attack is deployed en masse (via a web ad campaign or masse phishing) then 10 decryptions will suffice on about 1/1000 of the victims.

Q2: Does the attack require special equipment or software?

No, our attack does not require installing any software on the target machine, or modifying the browser's default configuration. Instead, it gleans information from outside the browser's sandbox purely by inducing and measuring timing variability related to memory accesses outside its sandbox.

Q3: How vulnerable are other algorithms and cryptographic implementations?

This is an open research question. Our attack requires careful analysis of the cryptographic implementation, which we conducted for End-to-End's implementation of ElGamal and RSA and Elliptic's implementation of Curve25519 ECDH.

Q4: What countermeasures are available?

Vendors of cryptographic software can, and already do, try to write their code in a way that minimizes side effects that can be observed by low-level side channels. But this is very difficult, and requires assumptions on the underlying hardware that are often proven false. Worse yet, on browser-based platforms, the vendor's cryptographic code itself is often implemented in portable code (e.g. JavaScript), which makes it impossible to control what will be the resulting machine code and what will be its observable side effects. This is actually shown in one of the libraries we attack, which tries to use such countermeasures, but implement them in JavaScript, and turns out to be still leaky.

A second approach is trying to eliminate the channel themselves, either by avoiding sharing of resources (this is expensive and wasteful), or by hampering the attacker's ability to measure time. Indeed, one timing source we used was removed as a response to the Spectre attack, for precisely this reason — to hamper the cache timing analysis component of those attacks. However, there are numerous alternative ways to measure time from within portable code, some of which are indirect and difficult to block.

We argue that the only secure way to perform cryptographic operations in JavaScript is to perform them using a native code implementation, running inside the browser. Indeed, modern browsers are equipped with WebCrypto API that allows JavaScript to execute cryptographic operations (though not, yet, elliptic-curve cryptography) using native, carefully designed and deterministically compiled implementations, such as BoringSSL used by Google Chrome.

Q5: What is new in this version of the paper compared to the version from 22 Aug 2017?

Q6: How do cache timing attacks work?

Over the years, memory speed has not kept pace with the speed of the processor. To bridge the speed gap, processor designs include caches which are small banks of memory that store the contents of recently accessed memory locations. Caches are much faster (up to two orders of magnitude) than main memory, because they are smaller and closer to the processor. Each cache is divided into fixed-size blocks called lines. When a CPU core accesses a memory location, the corresponding line is fetched from the lowest cache level containing it among the caches belonging to the same core. If the value is not contained in any of the cache levels, it is loaded into the cache from the main memory. Further access to memory addresses within the line will be served from the cache, reducing the time the processor needs to wait for the data to become available.

Cache timing attacks exploit timing differences between accessing cached vs. non-cached data. Since accessing cached data is faster, a program can check if its data is cached by measuring the time it takes to access it. In one form of a cache timing attack, the attacker fills the cache with its own data. When a target that uses the same cache accesses data, the target's data is brought into the cache. Because the cache size is finite, loading the target's data into the cache forces some of the attacker's data out of a cache. The attacker then checks which sections of its data remain in the cache, deducing from this information what parts of the target's memory were accessed.

Cache Hierarchy
Cache Hierarchy in Intel's CPUs

Q7: What information is leaked?

Portable code (WebAssembly or PNaCl) uses the underlying micro-architectural resources of the CPU it is executing on, and in particular the data cache. Thus, it can induce memory-contention effects that are required by cache side-channel attacks. Using these memory-contentions, and additional techniques, the portable code can executes a variant of the Prime+Probe attack and monitors memory accesses performed by other processes running on the target machine. In the case of End-to-End's implementation, these memory accesses reveal information about the secret key.

Cacheogram of ElGamal decryption
Cache accesses as detected by the attacker during ElGamal decryption. The intensity of the green color represents the number of cache misses. Notice traces 3 and 19, which contain cache misses observed by the attacker during the decryption operation.

Q8: What if I cannot even get the target to visit my website or see my ad?

Physical proximity to the target device can be used to launch side-channel attacks on cryptographic software.