Are AES X86 Cache Timing Attacks Still Feasible?
Total Page:16
File Type:pdf, Size:1020Kb
Are AES x86 Cache Timing Attacks Still Feasible? ∗ Keaton Mowery, Sriram Keelveedhi, and Hovav Shacham Department of Computer Science and Engineering University of California, San Diego La Jolla, California, USA ABSTRACT several recent changes to the x86. Some of these changes We argue that five recent software and hardware develop- have already been mentioned in work on side-channel at- ments | the AES-NI instructions, multicore processors with tacks; others are well known by architects but less so in the per-core caches, complex modern software, sophisticated pre- security community. Taken together, these changes make it fetchers, and physically tagged caches | combine to make it much more difficult to mount side-channel attacks on AES. substantially more difficult to mount data-cache side-channel Our contribution in this paper is to describe the new chal- attacks on AES than previously realized. We propose ways lenges to AES cache attacks and to propose ways in which in which some of the challenges posed by these developments they might be overcome. We also consider scenarios where might be overcome. We also consider scenarios where side- side-channel attacks are attractive, and whether our pro- channel attacks are attractive, and whether our proposed posed workarounds might be applicable to these scenarios. workarounds might be applicable to these scenarios. The new challenges to AES side-channel attacks are: • The AES-NI instruction set, which moves AES data Categories and Subject Descriptors structures out of the cache; • multicore processors with per-core L1 and L2 caches; D.4.6 [Software]: Security and Protection|Cryptographic Controls; E.3 [Data]: Data Encryption • the complexity of modern software and the pressure that it places on caches; Keywords • the increasingly sophisticated and poorly documented prefetcher units on modern processors; and AES, x86, Cache Timing, Side Channels, AES-NI • the switch from virtually tagged to physically tagged caches. 1. INTRODUCTION The first two of these can make AES cache attacks impossi- Side-channel attacks are a classic topic in computer secu- ble; the last three increase the difficulty of AES cache attacks rity. But are they still feasible on modern x86 machines? and make them inapplicable in some settings. In a side-channel attack, an attacker recovers secret in- Architectural side-channel attacks are enabled when shared formation from his victim by observing or manipulating a hardware between two mutually distrusting principals is in- shared resource. The most attractive channels for such at- completely virtualized by the supervisor. Traditionally, the tacks are shared hardware resources such as the data cache, principals were users on a timesharing system and the super- and the most devastating attacks recover cryptographic keys. visor was the OS kernel. We believe that today there are (at Even as the traditional scenario for side channel attacks | least) three scenarios where architectural side-channel at- multiuser timesharing on workstation systems | has fallen tacks are a threat: (1) infrastructure-as-a-service cloud com- into decline, other attractive attack scenarios have arisen. puting [22], with virtual machines as principals; (2) client- This paper arises from our unsuccessful attempt at ex- side in the Web browser and its plugins, with Web origins ploiting one such scenario: compromising Chrome browser as principals; and (3) smartphones and tablets, with apps as SSL keys from a Native Client control, using AES cache principals. (Mobile devices mostly use ARM chips, not x86.) timing as a channel. In our attempt, we ran up against Cache side-channel attacks on AES were first demonstrated ∗Supported by the MURI program under AFOSR Grant by Bernstein [6], Tromer, Osvik, and Shamir [23], and Bon- No. FA9550-08-1-0352. neau and Mironov [8]. These attacks were compared and analyzed by Canteaut [11], and were recently improved by Gullasch, Bangerter, and Krenn [15]. Proposed mitigations include cache-oblivious AES algorithms [9], the AES-NI in- Permission to make digital or hard copies of all or part of this work for struction set [16], deterministic computing environments [4], personal or classroom use is granted without fee provided that copies are and fuzzy timing channels [24]. not made or distributed for profit or commercial advantage and that copies In this paper, we argue that mounting AES (data) cache bear this notice and the full citation on the first page. To copy otherwise, to attacks on modern systems is more difficult than previously republish, to post on servers or to redistribute to lists, requires prior specific realized. This does not, of course, mean that they are im- permission and/or a fee. CCSW’12, October 19, 2012, Raleigh, North Carolina, USA. possible. In addition, our results do not rule out attacks on Copyright 2012 ACM 978-1-4503-1665-1/12/10 ...$15.00. other cryptographic primitives, such as RSA [21], nor at- 1 tacks that rely on other architectural channels, such as the 2.2 Multicore Processors instruction cache [1, 2] or the branch prediction unit [3], In the pursuit of performance, processor designers are in- nor timing attacks that do not depend on an architectural creasingly adding multiple physical cores to each die. For channel [10, 7]. In addition, while we have considered the example, currently Intel is almost exclusively shipping mul- x86, other architectures may still be vulnerable. Viewed ticore chips, with a few single core holdouts in the Celeron another way, our results suggest that other cryptosystems and Atom lines. The Atom N270 on which we conducted than AES, other microarchitectural features than the data our experiments contains only a single core, but newer pro- cache, and other architectures than the x86 should be con- cessors in the Intel Atom line (designed to be minimal and sidered in future side-channel research. The recent paper of power{efficient) now contain multiple cores. Even mobile Zhang et al. [26] partly corroborates this positive view of our devices are touting dual (or quad) cores as a major selling claims. Zhang et al. mount a cross-VM side-channel attack point. Multicore is here to stay, and, in order to remain a on cryptographic keys; but they target public-key crypto threat, cache timing attacks must be proven to work under rather than AES, and use the instruction cache rather than the new hardware regime. the data cache. The mere inclusion of multiple cores complicates cache at- tacks immensely. First, the attack must be aware of processor- 2. COMPLETE MITIGATION specific multicore cache behavior. For example, Intel Sandy First, we identify two trends in processor development Bridge processors have a per-core L1 and L2 cache, but all which have the potential to completely prevent AES cache cores share L3. The attacker must also understand the evic- timing attacks: AES-NI and multicore processors. These tion policy: can data remain in a L2 cache if it is evicted recent phenomenon represent material change in the hard- from L3 by another core? Further complicating matters, an ware capabilities underlying our computer systems, and will attacking thread might be rescheduled onto another physi- almost certainly grow for the forseeable future. cal core at any time, physically separating it from its care- fully manicured test data. Therefore, the best approach 2.1 AES-NI might take cues from Gullash's attack: create many at- Cache timing side channel attacks depend solely on mea- tacker threads, and trust that attacker threads will prob- suring the processor's use of memory during encryption. abilistically control every core most of the time. Under this Without these cache-changing accesses, the entire class of scheme, cross-thread communication is vital: the attacker, attacks is mitigated. when communicating with herself, must take care to avoid Intel processors that support AES-NI [14] provide hard- the cache lines she's trying to measure. While a solution ware implementations of key generation, encryption rounds, to each of these problems is imaginable, none of the exist- and decryption rounds. The cryptographic operations are ing cache timing attacks are directly applicable to multicore moved out of RAM and into custom hardware, improving processors, and further work would definitely be needed to performance and eliminating cache side channels. indicate that such attacks remain viable in the multicore paradigm. 2.1.1 Hardware Prevalence Recent work by Xu et al. on L2 cache timing side chan- Intel shipped the first AES-NI{supporting processor in Q1 nels in virtualized environments show that the upper bound 2010 [17]. All Sandy Bridge i7 and all but two Sandy Bridge on side channel bandwidth in EC2 is just over 10 bits per i5 support AES-NI, while all announced Ivy Bridge i5 and i7 second [25]. A covert channel consists of communication processors support it. Though Intel is still producing a few between two cooperating principals; it is not clear that Xu processors without AES-NI, presumably it will shortly be et al.'s analysis can be applied to adversarial side channels, supported throughout the entire lineup (akin to the MMX let alone to the very specific side channels required for at- or SSE extensions). AMD is introducing AES-NI support as tacking AES using the data cache. well, with Bulldozer, the first supported microarchitecture, Furthermore, core \pinning" is becoming an extremely released in October 2011 [13]. popular technique to manage load and scheduling behav- Therefore, many consumer-facing systems built in the past ior. Essentially, the operating system assigns a thread to two years are inoculated against AES cache timing attacks, one or more physical cores, and guarantees that it will never and we posit that this number will grow with time. execute anywhere else. With this in mind, we observe that Even on processors that do not implement AES-NI, al- a pinned attacker thread (even if pinned to n − 1 cores) ternative AES implementations exist that keep AES data physically cannot perform cache timing attacks against an outside of RAM; see, e.g., [19].