Drive-by Key-Extraction Cache Attacks from Portable Code

Paper

• Latest version: [PDF] (updated 2018-01-31)
• Daniel Genkin, Lev Pachmanov, Eran Tromer, Yuval Yarom, Drive-by Key-Extraction Cache Attacks from Portable Code, proc. Applied Cryptography and Network Security (ACNS) 2018, to appear
• Daniel Genkin, Lev Pachmanov, Eran Tromer, Yuval Yarom, Drive-by Key-Extraction Cache Attacks from Portable Code, IACR Cryptology ePrint Archive, https://eprint.iacr.org/2018/119

Summary

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. 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.

Q&A

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?

• We extended our techniques to the more common WebAssembly, supported by all modern web browsers, instead of PNaCl supported just by the desktop version of Chrome browser
• We demonstrated our attack in cross-browser scenario, i.e. we attacked a JavaScript code running inside Chrome from a malicious advertisement displayed in Firefox

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 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.

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.

• Laptop-chassis potential, measured from the far end of virtually any shielded cable connected to the laptop (such as Ethernet, USB, HDMI and VGA cables), can be used for key-extraction, as we demonstrated in a paper presented at CHES'14.
• Acoustic emanations (sound), measured via a microphone, can also be used to extract keys from a range of several meters, as we showed in a paper presented at CRYPTO'14 .
• Electromagnetic leakage, measured though the wall, can be used for key extraction from laptops, as we showed in a paper at CT-RSA'16.
• Power analysis, which monitors the phone's power consumption, can be used to extract the signing keys as well. In principle, any charger, battery or even charging station can be augmented with the required equipment in order to extract the key, as we demonstrated in a paper presented at CCS'16

Acknowledgments