armageddon: last-level cache attacks on mobile devices · 2018-11-09 · mobile devices in general....
TRANSCRIPT
ARMageddon: Last-Level Cache Attacks on MobileDevices
Moritz LippGraz University of Technology, Austria
Daniel GrussGraz University of Technology, Austria
Raphael SpreitzerGraz University of Technology, Austria
Stefan MangardGraz University of Technology, Austria
Abstract—In the last 10 years cache attacks on Intel CPUshave gained increasing attention among the scientific community.More specifically, powerful techniques to exploit the cache sidechannel have been developed. However, so far only a fewinvestigations have been performed on modern smartphones andmobile devices in general. In this work, we describe Evict+Reload,the first access-based cross-core cache attack on modern ARMCortex-A architectures as used in most of today’s mobile devices.Our attack approach overcomes several limitations of existingcache attacks on ARM-based devices, for instance, the require-ment of a rooted device or specific permissions. Thereby, webroaden the scope of cache attacks in two dimensions. First, weshow that all existing attacks on the x86 architecture can alsobe applied to mobile devices. Second, despite the general beliefthese attacks can also be launched on non-rooted devices and,thus, on millions of off-the-shelf devices.
Similarly to the well-known Flush+Reload attack for thex86 architecture, Evict+Reload allows to launch generic cacheattacks on mobile devices. Based on cache template attackswe identify information leaking through the last-level cachethat can be exploited, for instance, to infer tap and swipeevents, inter-keystroke timings as well as the length of wordsentered on the touchscreen, and even cryptographic primitivesimplemented in Java. Furthermore, we demonstrate the appli-cability of Prime+Probe attacks on ARM Cortex-A CPUs. Theperformed example attacks demonstrate the immense potentialof our proposed attack techniques.
I. INTRODUCTION
Cache attacks represent a powerful means of exploitingthe different access times within the memory hierarchy ofmodern system architectures. Until recently these attacks ex-plicitly targeted cryptographic implementations. The seminalpaper of Yarom and Falkner [58], however, introduced theso-called Flush+Reload attack, which allows an attacker toinfer which specific parts (instructions as well as data) of abinary (shared object or executable) are accessed by a victimprogram. Thereby, Flush+Reload allows more fine-grainedattacks than previous approaches like, for instance, plain timingattacks [8], or the well-known Evict+Time and Prime+Probetechniques [42]. Recently, Gruss et al. [18] even demonstratedthe possibility to use Flush+Reload to automatically exploitcache-based side channels by so-called cache template attackson Intel platforms. Flush+Reload does not only allow forefficient attacks against crypto implementations (cf. [7], [24],[55]) but also to infer keystroke information and even to
build keyloggers on Intel platforms [18]. Thus, cache attacksrepresent a significant threat to today’s computing platforms.
Although a few publications about cache attacks againstAES T-table implementations on mobile devices exist (cf.[9], [49]–[51], [56]), the recent advances in terms of highlyaccurate and generic attacks have been demonstrated on x86platforms only. More specifically, open challenges caused bythe significant differences in terms of cache architecture andprivileged instructions on modern x86 and ARM architectureshave prevented these attacks from being mounted on ARM-based devices for years. Therefore, we investigate these openchallenges in more detail and show that all of these issuescan be overcome in practice. Thereby, we demonstrate that allexisting cache attacks proposed for x86 architectures can alsobe applied on ARM architectures, which allows for real-worldattack scenarios on millions of off-the-shelf Android deviceswithout any special privileges or permissions.
As smartphones continue to evolve as the most importantpersonal computing platform, the investigation of more genericcache attacks on mobile devices is of utmost importance. Basedon related work in this area of research, we found that cacheattacks are not practically relevant on ARM because of thefollowing issues, which we overcome in this work.
1) Random replacement policy: The random replacementpolicy—used to replace specific cache lines within acache set—has been mentioned as one possible sourceof noise in case of time-driven cache attacks [49], [51].Furthermore, due to the random replacement policy, theEvict+Time approach is so far considered more appropri-ate than the Prime+Probe approach [50].
2) Precise timing: So far, precise timings on the ARM plat-form relied on the cycle count register (PMCCNTR) [3]that is only accessible in unprivileged mode if access isexplicitly granted by a privileged application. Thus, theseattacks assume that the Android device is rooted and theexploitation of cache attacks on non-rooted devices hasbeen mentioned as an interesting open challenge [50].
3) Flush instruction: In contrast to Intel x86 platforms,ARM restricts the usage of dedicated flush instructionsto privileged mode only. Thus, the device needs to berooted and the attacker needs to permanently install akernel module. However, an attacker can also performcache eviction by accessing multiple congruent addresses
arX
iv:1
511.
0489
7v1
[cs
.CR
] 1
6 N
ov 2
015
to evict all data from a specific cache set. Due to improvedreplacement policies previously published eviction is notpractical anymore on more recent CPUs.
4) Cache architecture: One of the prerequisites of theFlush+Reload attack is an inclusive shared last-levelcache. Inclusive means that data which is present in thelower cache levels, e.g., L1 cache, must also be presentwithin higher cache levels and shared means that the last-level cache is shared among all cores. These propertiesallow any process to evict specific data from anothercore’s L1 cache. However, ARM Cortex-A processors didnot support an inclusive shared last-level cache until theARM Cortex-A53/A57 generation.
The above mentioned challenges show the significant dif-ferences between modern Intel platforms and ARM platforms.Eventually, we show how to tackle these challenges and ourinsights clearly demonstrate the feasibility of highly efficientcache attacks on ARM platforms. Thereby, we do not restrictour investigations to cryptographic implementations but alsoconsider cache attacks as a means to infer inter-keystroketimings or the length of swipe actions. In addition, our in-vestigations show that our attack approach allows a maliciousapplication to determine when a specific library is used. Forinstance, the presented attack can be used to determine whetherthe GPS sensor is active, or whether other features like themicrophone or the camera are used. This information furtherallows an adversary to infer privacy-sensitive informationabout the user.
We do not aim to list the possible exploits exhaustively butonly demonstrate the immense attack potential of our proposedEvict+Reload attack. Given this powerful technique, we be-lieve that many sophisticated cache attacks will be presentedin the future. We address this to the fact that Evict+Reloadcan be used to scan any library or program binary for possibleinformation leaks resulting from the cache side channel.
Contributions. The contributions of this work can be summa-rized as follows.
• We are the first to successfully perform highly efficientand accurate cache attacks on ARM CPUs, which so farhave only been shown for x86 platforms. More specif-ically, we demonstrate that the Evict+Reload approachcan be used to apply Flush+Reload-like attacks. Fur-thermore, we are the first to demonstrate the feasibilityof Prime+Probe attacks on ARM. Our attacks are thefirst access-driven cache attacks that exploit the last-levelcache and, thus, work across CPU cores.
• Our attack is the first to demonstrate that local instructioncaches can be attacked via data memory accesses, evenif the last-level cache is only inclusive on the instructionside but not on the data side.
• We show that cache-based covert channels significantlyoutperform existing covert channels on Android.
• We show that cache template attacks can be used to launchsophisticated attacks on mobile devices, including attacksagainst cryptographic implementations used in practicebut also more fine-grained attacks like inter-keystroketimings and swipe actions on the touchscreen.
Outline. The remainder of this paper is structured as follows.In Section II, we start with basic information about CPU
caches and shared memory in general. Furthermore, we coverrelated work in this area of research. Section III presents amore realistic adversary model with fewer assumptions thanexisting attacks and identifies the challenges that need tobe solved for such an adversary model. We describe theEvict+Reload attack in Section IV and we also state solutionsto the previously identified challenges on ARM platforms.In Section V, we evaluate the performance of a cross-corecovert channel between two Android applications based onour Evict+Reload attack. In Section VI, we demonstrate cachetemplate attacks on Android based on our Evict+Reload ap-proach. In Section VII, we describe how the eviction fromthe Evict+Reload attack can be used to build a Prime+Probeattack. We discuss possible countermeasures against the iden-tified weaknesses in Section VIII and we discuss interestingopen research challenges in Section IX. Last but not least, weconclude this work in Section X.
II. BACKGROUND AND RELATED WORK
In this section, we give a basic introduction to the conceptof CPU caches and compare modern Intel CPU caches tomodern ARM CPU caches. We discuss the basics of sharedmemory. Furthermore, we provide a basic introduction to cacheattacks on ARM and Intel architectures.
A. CPU Caches
Today’s CPU performance is influenced not only by theclock frequency but also by the latency of instructions, operandfetches, and other interaction with internal and external de-vices. All CPU computations require data from the systemmemory, but reducing the latency of system memory is diffi-cult. Instead, CPUs employ caches to buffer frequently useddata in smaller and faster internal memories, effectively hidingthe latency of slow accesses to the system memory.
Modern caches are organized in sets of cache lines, whichis also known as set-associative caches. Each memory addressmaps to one of these cache sets and memory addresses thatmap to the same cache set are considered as being congruent.Congruent addresses compete for cache lines within the sameset. Therefore, CPUs implement replacement policies, forexample, least-recently used (LRU) eviction which is commonon Intel CPUs. However, these replacement policies are widelyundocumented [17].
CPU caches can be virtually indexed and physically in-dexed caches, which derive the index from the virtual orphysical address, respectively. Virtually indexed caches aregenerally faster because they do not require virtual to physicaladdress translation before the cache lookup. However, usingthe virtual address leads to the situation that the same physicaladdress might be cached in different cache lines, which againintroduces performance penalties. In order to uniquely identifythe actual address that is cached within a specific cache line,a so-called tag is used. This tag again can be based on thevirtual or physical address. Most modern caches use physicaltags because they can be computed simultaneously to locatingthe cache set.
CPUs have multiple cache levels, with the lower levelsbeing faster and smaller than the higher levels. If all cachelines from lower levels are also stored in a higher-level cache
line, we call the higher-level cache inclusive. If a cache linecan only reside in one of the cache levels at any point intime, we call the caches exclusive. The last-level cache isoften shared among all cores to enhance the performance upontransitioning threads between cores and to simplify cross-corecache lookups. However, with shared last-level caches that areexclusive or inclusive, one core can (intentionally) influencethe cache content of all other cores. This is the basis for cacheattacks such as the Flush+Reload [58] attack.
In this paper we focus on two CPUs, a Qualcomm Krait400 and an ARM Cortex-A53, both very common quad-coreCPUs used in today’s smartphones.
The Qualcomm Krait 400 runs at 2.88 GHz. It has two16 KB L1 caches—one for data and one for instructions—percore, with a cache line size of 64 bytes. The L1 caches arephysically indexed and physically tagged and have 4 ways and64 cache sets. The L2 cache is shared among all cores, but itis neither inclusive nor exclusive [3]. The L2 cache has a sizeof 2 MB and is divided into 2 048 sets, each with 8 cache linesand a cache line size of 128 bytes.
The more recent ARM Cortex-A53 runs at 1.2 GHz. Ithas two 4-way 32 KB L1 caches—one for data and one forinstructions—per core, with a cache line size of 64 bytes. TheL1 caches are again physically indexed and physically taggedand have 128 cache sets. The L2 cache is shared among allcores and inclusive with respect to the L1 instruction cachebut exclusive with respect to the L1 data cache [1], [5]. It hasa total size of 512 KB and is divided into 512 sets with 16cache lines each and a cache line size of 64 bytes.
B. Shared Memory
While writeable shared memory can be used as a meansfor communication between two processes, read-only sharedmemory can be used as a means of memory optimization. Incase of shared libraries this does not only reduce the memoryfootprint of a system but also enhances the speed as sharedcode is kept only once in memory and in CPU caches as wellas address translation units. The operating system implementsthis behavior by mapping the same physical memory into theaddress space of each process.
When executing self-modifying code or just-in-time com-piled code, this advantage cannot be used in general. Androidapplications are usually implemented in Java and thereforewould incur just-in-time compilation. However, there havebeen several approaches to improve the performance, first withoptimized virtual machine binaries and more recently withnative code binaries that are compiled from Java byte codeusing ART [2] (Android Runtime).
The operating system employs the same memory sharingmechanism when opening a file as read-only and mapping itinto memory using system calls like mmap. Thus, an attackercan map code or data of a shared library or any accessiblebinary into its own address space, resulting in read-only sharedmemory, even if the program is statically linked.
Content-based page deduplication is another form of sharedmemory. Here, an operating system service scans the entiresystem memory for identical physical pages. Identical pages
are merged to the same physical page and marked as copy-on-write. This mechanism can enhance system performance incases where system memory is scarce, such as cloud systemswith a high number of virtual machines or smartphones withlimited physical memory.
Processes can retrieve information on virtual and phys-ical address mappings using operating-system services like/proc/<pid>/maps or /proc/<pid>/pagemap, bothon Linux and on Android. While Linux gradually restrictsunprivileged access to these resources, these patches have notyet been merged into stock Android kernels. Thus, a processcan retrieve a list of all loaded shared-object files and theprogram binary of any process and even perform virtual tophysical address translation without any privileges.
C. Cache Attacks
In the groundbreaking work of Kocher [30] about timingattacks on cryptographic implementations, the CPU cachehas been first mentioned as possible information leak. Later,Kelsey et al. [28] observed that cache-hit ratios can be ex-ploited in order to break ciphers employing large S-boxes.Based on these theoretical observations, more practical attacksagainst DES have been proposed by Page [43] and also byTsunoo et al. [54]. With the standardization of the AdvancedEncryption Standard (AES) [14], [37], cache attacks againstthis block cipher have been investigated, i.e., Bernstein [8]presented the well-known cache-timing attack against AES thathas been further analyzed by Neve [38] and Neve et al. [40].
While Bernstein’s cache-timing attack exploited the overallexecution time of the encryption algorithm, more fine-grainedexploitations of the memory accesses to the CPU cache havebeen proposed by Percival [44] and also by Osvik et al.[42]. More specifically, Osvik et al. formalized two concepts,namely Evict+Time and Prime+Probe, to determine whichspecific cache sets have been accessed by a victim program.Both of these approaches consist of three basic steps whichare outlined within the following paragraphs.
Evict+Time:
1) Measure the execution time of the victim program.2) Evict a specific cache set.3) Measure the execution time of the victim program again.
Prime+Probe:
1) Occupy specific cache sets.2) The victim program is scheduled.3) Determine which cache sets are still occupied.
Both approaches, Evict+Time and Prime+Probe, allow anadversary to determine which cache sets are used duringthe victim’s computations and have been exploited to attackcryptographic implementations (cf. [23], [32], [42], [53]) butalso to build cross-VM covert channels (cf. [35]).
A significantly more powerful, i.e., more fine-grained,attack approach denoted as Flush+Reload has been proposedby Yarom and Falkner [58] in 2014. This sophisticated tech-nique exploits three fundamental concepts of modern systemarchitectures. First, the availability of shared memory betweenthe victim process and the adversary. Second, last-level caches
are typically shared among all cores. Third, Intel platformsuse inclusive last-level caches, meaning that the eviction ofinformation from the last-level cache leads to the eviction ofthis data from all lower-level caches of other cores, whichallows any program to evict data from other programs on othercores. While the basic idea of this attack has been proposedby Gullasch et al. [20], Yarom and Falkner extended this ideato shared last-level caches which allows for cross-core attacks.The basic working principle of Flush+Reload is as follows.
Flush+Reload:
1) Map binary (shared object or program) into address space.2) Flush a specific cache line (code or data) from the cache.3) Schedule the victim program.4) Check if the corresponding code from step 2) has been
loaded by the victim program.
Thereby, the Flush+Reload approach allows an attacker todetermine which specific instructions are executed and alsowhich specific data is accessed by the victim program. Thus,rather fine-grained attacks are possible and have already beendemonstrated against cryptographic implementations (cf. [21],[25], [26]). Furthermore, Gruss et al. [18] demonstrated thepossibility to automatically exploit cache-based side-channelinformation based on the Flush+Reload approach. Besidesattacking cryptographic implementations like AES T-table im-plementations, they showed how to infer keystroke informationand even how to build a keylogger according to the cache sidechannel. Similarly, Oren et al. [41] demonstrated the possibilityto exploit cache attacks on Intel platforms from JavaScript andshowed how to infer visited websites and to track the user’smouse activity.
While the above discussed attacks have been proposed andinvestigated for Intel processors, only few studies consider thepossible exploitation of cache-based side-channel informationon modern smartphones. So far, these investigations on modernsmartphone platforms, like ARM Cortex-A processors, onlyconsidered the exploitation of cache attacks in order to attackcryptographic implementations. For instance, Weiß et al. [56]investigated Bernstein’s cache-timing attack on a Beagleboardemploying an ARM Cortex-A8 processor. As Weiß et al.claimed that noise makes the attack difficult, Spreitzer andPlos [51] investigated the applicability of Bernstein’s cache-timing attack on different ARM Cortex-A8 and ARM Cortex-A9 smartphones running the Android operating system. Bothinvestigations [51], [56] confirmed that timing informationis leaking, but two major drawbacks restrict the practicalapplication of this attack. First, many measurement samplesare required, e.g., about 230 AES encryptions, and second, thekey space could only be reduced to about 65 bits which isstill rather impractical. Later on, Spreitzer and Gerard [49]improved upon these results and managed to reduce the keyspace to a complexity which is practically relevant.
Besides Bernstein’s cache-timing attack, another attackagainst AES T-table implementations has been proposed byBogdanov et al. [9], who exploited so-called wide collisionson an ARM9 microprocessor. In addition, power analysisattacks [16] and also electromagnetic emanations [15] havebeen shown to be powerful techniques to visualize cacheaccesses during AES computations on ARM microproces-sors. Furthermore, Spreitzer and Plos [50] implemented the
Evict+Time [42] approach in order to attack an AES T-tableimplementation on Android-based smartphones. However, sofar only cache attacks against the AES T-table implementationhave been considered on smartphone platforms and none ofthe most recent advances has been evaluated and investigatedon mobile devices. As mobile devices advance to be themajor computing platforms, we consider it especially importantto further investigate the possible threat arising from cacheattacks. In this paper, we aim to close this gap.
III. ADVERSARY MODEL AND ATTACK SCENARIO
As we consider a scenario where an adversary attacks asmartphone user, we obviously require the user to install amalicious application. Nevertheless, we consider this a realisticassumption due to the following reasons.
1) Non-rooted smartphones: Our application does not requirea rooted smartphone as the malicious application can beexecuted in unprivileged userspace.
2) No permissions: Our application does not require anypermission at all, which means that users will not be ableto notice any suspicious behavior due to the presentedpermissions during the install process.
3) Malicious app can be spread through popular app mar-kets: Based on the above mentioned advantages, we notethat such a malicious application can be spread easilyvia available app markets, such as Google Play and theAmazon Appstore. An adversary only needs to convincethe user to install our application, which can be donethrough a useful tool or an addictive game.
4) Independent of Android version: Our presented attackdoes not rely on a specific Android version and workson all stock Android ROMs as well as customized ROMsin use today.
We derive the prerequisites for our Evict+Reload attackaccording to the challenges identified in Section I.
1) Efficient eviction without a dedicated flush instruction: OnARM platforms we are facing two obstacles that needto be overcome. First, the dedicated flush instruction isrestricted to privileged mode only. As our attack shouldbe deployable without any privileged instructions, i.e.,on non-rooted devices, we need to rely on memoryaccesses to congruent addresses in order to evict datafrom the cache. Second, due to the random replacementpolicy current attacks on ARM platforms [50] rely on anumber of memory accesses which is two to three timesthe number of ways. Thus, we optimize the number ofmemory accesses, i.e., a more efficient cache eviction.
2) Precise timings without performance monitor registers:Cache attacks on ARM use the PMCCNTR register [3],which allows for cycle-accurate timing measurements.However, access to this register must be granted by a priv-ileged application, which means that a rooted smartphoneis required for state-of-the-art cache attacks. Even thoughthe challenge of launching cache attacks on non-rooteddevices has been mentioned by Spreitzer and Plos [50] asinteresting future work, it has not been solved yet.
3) Shared memory between applications: The Flush+Reloadattack proposed by Yarom and Falkner [58] requiresread-only shared memory between a spy process and a
victim process. This ensures that both processes workon the same physical addresses and the spy process candetermine the victim’s memory accesses by means ofcache hits and cache misses, respectively.
4) Shared inclusive/exclusive last-level cache: TheFlush+Reload attack also relies on a shared inclusivelast-level cache. The most recent ARM Cortex-A53/A57generation has a unified shared last-level cache that isinclusive on the instruction side and exclusive on the dataside. We investigate how this cache can be instrumentedto implement Flush+Reload-like attacks. In addition, weshow how to launch our presented attack even againstshared last-level caches that are neither inclusive norexclusive and, thus, our attack can be used to attackolder ARM Cortex-A8 and ARM Cortex-A9 devices aswell.
The same prerequisites also apply for the Prime+Probeattack, except that the spy and the victim process do not needto share memory.
Within the next Section we show how to fulfill all theseprerequisites and how an adversary can exploit these featuresin order to launch generic cache template attacks as describedby Gruss et al. [18].
IV. THE EVICT+RELOAD ATTACK
In this section we present Evict+Reload, a highly accurateaccess-based cross-core cache side-channel attack. It is avariant of the Flush+Reload attack proposed by Yarom andFalkner [58] and has been first mentioned by Gruss et al.[18] as an alternative to Flush+Reload. Instead of usingan instruction to flush data from the cache, Evict+Reloadevicts data from the cache by performing memory accesses,similarly as in Evict+Time or Prime+Probe attacks. However,Gruss et al. observed that Evict+Reload has no practical useon x86 platforms as the clflush instruction is available inunprivileged mode on Intel platforms. While the ARMv7-Aand the ARMv8-A instruction sets support various privilegedflush instructions, there is no flush instruction that is accessiblefrom userspace [3]. Thus, we need to rely on memory accessesfor eviction purposes.
The Evict+Reload attack as described by Gruss et al. isspecifically tailored to the x86 architecture and assumes theavailability of several x86 instructions, such as rdtsc. There-fore, it is not directly applicable to ARMv7-A and ARMv8-A architectures. We first describe Evict+Reload in a genericway and subsequently we show how it can be implemented onARMv7-based architectures.
Similarly to the Flush+Reload attack, Evict+Reload relieson the availability of shared memory between the attacker andthe victim, e.g., shared libraries or program binaries. Followingthe notion of Flush+Reload, the attacker process maps thelibrary or binary under attack into its own virtual addressspace. The attacker then “probes” addresses within this sharedmemory area. More specifically, for each address a withinthe shared memory area, the attacker evicts address a fromthe CPU cache, waits for the victim process to be scheduled,and finally the attacker determines whether the victim fetchedaddress a into the CPU cache again. Algorithm 1 summarizesthe single steps for a specific address a.
Algorithm 1: Evict+Reload attackInput: Address a of mapped shared memory mOutput: Cache hit/miss on address a after victim has
been scheduledEvict address a from cacheWait for victim to be scheduledCheck whether or not victim loaded a into the cacheif Victim loaded a into the cache then
return Hitelse
return Missend
The basic idea is that depending on whether or not thevictim process accessed the memory region (instruction ordata) corresponding to address a, the attacker either observesa cache hit or a cache miss when accessing address a again.Therefore, either timing information, a cycle counter, an in-struction counter, or a cache-miss counter can be employed.In case the attacker observes a cache hit, the victim processmust have loaded the memory address a into the cache before.Otherwise, the attacker learns that the victim most likely didnot access this address. The Evict+Reload attack has a highaccuracy as it is highly unlikely that exactly one cache lineis evicted by other system activity before the attacker is ableto reload it. However, if the victim’s access happens after thereload step and before finishing eviction in the next iteration,the cache line can be evicted by the attacker accidentally. Theexecution time of this code fragment is always below 1µs. Bychoosing the duration of the waiting step, the attacker choosesa trade-off between the temporal resolution and the probabilityof missing an event. For instance, a waiting duration of 1 msyields a probability below 0.1% to miss an event while stillbeing accurate enough for most use cases. In other scenariosspy and victim might be synchronized as the spy triggers thevictim computation. In this case the probability of missing acache hit is even lower.
As already mentioned above, an attacker can rely onvarious mechanisms, e.g., timing information or a performancecounter like a cache-miss counter, in order to distinguishbetween cache hits and cache misses. In this work we employa cycle-accurate timer in order to distinguish between a cachehit and cache miss. Figure 1 illustrates a histogram for memoryaccesses resulting in a cache hit and memory accesses resultingin a cache miss. Based on this histogram, an attacker canreliably determine a threshold to distinguish between cachehits and cache misses, which is then used in Algorithm 1.The plot in Figure 1 is based on the privileged cycle counterregister (PMCCNTR). However, we will demonstrate a meansto overcome this privileged register in Section IV-B.
As already mentioned in Section III, a few challenges needto be overcome in order for Evict+Reload to be applicablefor our adversary model. Within the following subsections weinvestigate how to fulfill all the requirements for our attackstrategy. First, we discuss the technicalities in order for ourattack to work on shared inclusive as well as shared exclusivelast-level caches. Afterwards, we show how to get rid of theprerequisite of a rooted smartphone in order to get cycle-accurate timings. Last but not least, we show how to evict
0 50 100 150 200 250 3000
2
4
·104
Execution time in cycles
Num
ber
ofca
ses
HitMiss
Fig. 1. Histogram of access times for cache hits and cache misses on theARM Cortex-A53 test device.
specific cache sets without relying on the privileged flushinstruction.
A. Shared Cache Lines on ARM CPUs
Sharing memory between victim and spy process is straightforward on Linux and Windows. As the operating systemtries to minimize the memory footprint, binaries and sharedobjects are always mapped as read-only shared memory intoall processes. Since Android is based on Linux, the sameconcepts also apply to the Android OS. Even though mostAndroid applications are implemented in Java and, thus, shar-ing memory between a spy and a victim process is moredifficult, the underlying system employs shared memory just asin Linux. Hence, we target shared libraries or program binarieson Android as well.
When it comes to caches, ARMv7-A and ARMv8-A CPUsare very heterogeneous compared to Intel CPUs. Whether aCPU has a second-level cache can be decided by the manu-facturer. As we only consider multi-core CPUs with a second-level cache as they are predominant in Android smartphones,there is only a limited number of properties that influencewhether cache lines are shared and to what extent. The last-level cache on ARMv7-A and ARMv8-A devices is usuallyshared among all cores. However, the last-level cache can beinclusive to lower-level caches, that is every cache line inany core’s lower-level cache is also contained in the last-levelcache. It can also be exclusive, that is no cache line can bein two cache levels at the same time. ARMv7-A CPUs, i.e.,ARM Cortex-A8 and ARM Cortex-A9 processors, are usuallyneither inclusive nor exclusive. Thus it is difficult to performcross-core attacks. However, in this scenario an attacker canrun the spy process on all cores simultaneously and thus fallback to a same-core attack. This changed with the ARMv8-A architecture, e.g., ARM Cortex-A53 and ARM Cortex-A57processors. On this architecture the last-level cache is inclusiveon the instruction side and exclusive on the data side [1], [5].
To perform a cross-core attack we do not execute theinstructions we want to spy on. Instead we load enough datainto the cache to fully evict the corresponding last-level cacheset. Thereby, we exploit that the last-level cache is inclusive onthe instruction cache side and can evict instructions from theother core’s local caches. Figure 2 illustrates such an eviction.In step 1, an instruction is allocated to the last-level cache andthe instruction cache of one core. In step 2, a process fills
Core 0
L1I
Sets
L1D
Core 1
L1I L1D
L2 Unified Cache
Sets
(1) (2)
(3)
Fig. 2. Cross-core instruction cache eviction through data accesses.
its core’s data cache, thereby evicting cache lines into the last-level cache. In step 3, the process has filled the last-level cacheset using only data accesses and thereby evicts the instructionsfrom other core’s instruction caches as well.
Although the data caches are exclusive, we observe thatwe can perform cross-core attacks on these caches as well.After evicting data from the last-level cache using memoryaccesses we measure higher access times. When anotherprocess running on a different core reaccesses the data weobserve a lower access time again. These timing measurementswould suggest an inclusive cache architecture although it isexclusive according to the documentation [1], [5]. We assumethat this is due to the cache-coherency protocol between theCPU cores. If remote-core data fetches are performed insteadof accesses to physical memory it might be fast enough to beobserved as a cache hit. However, this attack is generally notpossible on exclusive last-level caches. Further investigationson exclusive last-level caches and the influence of cache-coherency protocols are beyond the scope of this work andwe consider these investigations as possible future work.
On the Krait 400 the L2 cache is neither inclusive on thedata side nor on the instruction side. However, we observedthat cross-core cache attacks are still possible in most cases.The reason for this could be the cache-coherency protocolbetween the CPU cores. In cases where the Evict+Reloadattack did not work on the Krait 400 we found that launchingthe attack in parallel on all CPU cores allows to performEvict+Reload in a local-core attack. Thus, the attack can beapplied to older devices with non-inclusive caches as well.
B. Distinguishing Cache Hits and Cache Misses
In order to distinguish cache hits and cache misses, timingsources or dedicated performance counters can be used, i.e.,anything that captures the difference between cache hits andcache misses. We focus on timing sources as cache misseshave a significantly higher access latency. While cache attackson x86 CPUs employ the rdtsc instruction—which providessub-nanosecond resolution timestamps—that can be accessedby any unprivileged user program, the ARMv7-A architecturedoes not provide an instruction for this purpose. Instead, theARMv7-A architecture has a performance monitoring unit thatallows to monitor CPU activity. One of these performancecounters—denoted as cycle count register (PMCCNTR)—canbe used to distinguish between a cache hit and a cache missby relying on the number of CPU cycles that passed during amemory access. However, the performance monitoring unit isnot accessible from userspace by default.
0 50 100 150 200 250 3000
2
4
·104
Access time in cycles
Num
ber
ofac
cess
esHit (PMCCNTR) Hit (syscall)
Miss (PMCCNTR) Miss (syscall)
Fig. 3. Histogram of cache hits and cache misses on the ARM Cortex-A53according to the PMCCNTR register and the perf_event_open interface.
Previous work assumed that an attacker is able to enableuserspace access to these performance counters by setting acertain register while running in privileged mode. In order todo so, it is required to obtain root privileges on the deviceand to load a kernel module. While this is possible on rooteddevices if specific applications are installed and executed, thevast majority of Android smartphones are not rooted.
Thus, in order to broaden the attack surface, we do notwant to rely on root privileges in order for our attack to work.Our observations showed that in Linux kernel version 2.6.31the perf_event_open syscall has been introduced as anabstract layer to access runtime performance information inde-pendent of the underlying hardware. It allows to access perfor-mance counters on different CPUs through a unified interface.In our case we use the PERF_COUNT_HW_CPU_CYCLESperformance counter that returns an accurate cycle count justas the privileged instructions. However, due to the fact thatthis approach relies on a syscall to acquire the cycle countervalue, a latency overhead can be observed.
In Figure 3 we show the cycle count distribution asmeasured using the perf_event_open interface and viaaccess to the privileged PMCCNTR register. Although thesystem call introduces latency and noise, cache hits and cachemisses are still clearly distinguishable. Thus, even with thislatency overhead we are able to exploit this syscall in order tosuccessfully launch our proposed Evict+Reload attack.
Through this syscall interface, it is possible to get the CPUcycle counter value from userspace without privileged access.Since only Android 1.0 used a kernel version below 2.6.31and more recent Android versions deploy kernel versions 3.4or 3.10, the perf_event_open interface is available onall Android devices above Android 1.0. Furthermore, todaythe number of devices running Android 1.0 is negligibleand, therefore, we assume that about 1.4 billion Androiddevices [33] are affected.
C. Unprivileged Cache Eviction
As described in Section II-A, modern CPUs employ set-associative caches. Multiple cache lines comprise one cacheset and addresses that map into the same set are consideredas congruent. These congruent addresses compete for cachelines in this set. If a cache line has to be allocated for data
fetched from the physical memory, an existing cache line needsto replaced, i.e., evicted according to a predefined replacementpolicy. The ARMv7-A architecture defines two different cachereplacement policies, namely round-robin and pseudo-randomreplacement policy. In practice only the pseudo-random re-placement policy is used for reasons of performance and sinceswitching the cache replacement policy is only possible inprivileged mode.
In order to intentionally evict a specific cache set withouta dedicated flush instruction, an attacker needs to accesscongruent memory addresses that map to the same cache set.This has already been proposed by Osvik et al. [42]. Similarly,Hund et al. [22] flush the whole CPU cache on an olderIntel CPU without using cache maintenance operations byaccessing a physically consecutive memory buffer which islarger than the cache. Although this also evicts the targetedaddress it is definitely not the fastest approach, as it wouldbe sufficient to access only addresses which are congruent tothe address to be evicted. Cache eviction has recently beeninvestigated in more detail for the x86 architecture [32], [35],[41] in order to perform Prime+Probe attacks. However, asalready observed by Spreitzer and Plos [50], on ARMv7-ACPUs it is necessary to access more addresses than thereare cache lines per cache set, because of the pseudo-randomreplacement policy. We improve these eviction strategies byapplying methods of Gruss et al. [17].
While the cache replacement on ARM Cortex-A processorsis described as a pseudo-random replacement policy, there areno details on the actual implementation. Gruss et al. [17]recently proposed an algorithm to find access patterns thatachieve a high eviction rate and a low execution time on IntelCPUs. Although they claim that their algorithm works on anyarchitecture, they only examined different Intel architectures.While their algorithm is very slow and computes both, congru-ent addresses and an access pattern, we only need to search forthe access pattern. This is due to the fact that Android providesaccess to the mapping of virtual to physical addresses through/proc/self/pagemap. Although access to this mappinghas already been identified as a potential security issue onx86 [47] and recent Linux kernels [29] restrict access to thismapping, current Android versions still allow access to anyunprivileged application. Therefore, we can compute congruentaddresses directly and only use their algorithm to evaluate theaccess patterns using our set of congruent addresses.
We applied the algorithm of Gruss et al. [17] to the setof congruent addresses—which has been established via theaccess to /proc/pid/pagemap—for our two test devices.Figure 4 shows the best access pattern for the Krait 400CPU. On the y-axis we illustrate the different (but congruent)addresses and on the x-axis we illustrate the memory accessesover time. Hence, for the Krait 400, which has a 4-way L1cache and an 8-way L2 cache, our eviction set consists of atotal of 12 congruent addresses. These addresses are accessedusing read accesses within a loop of 10 rounds, with 3 memoryaccesses per round, and theses accesses are shifted by 1 afterevery round. Based on this eviction strategy, we measured aneviction rate of 100% and an average execution time of 599cycles if performed in an Evict+Reload attack. Although astrategy accessing every address in the eviction set only oncewould perform significantly less memory accesses, it consumes
Time
Add
ress
Fig. 4. Optimal access pattern on our Krait 400 test device.
TABLE I. DIFFERENT EVICTION STRATEGIES ON THE KRAIT 400
N A D Cycles Rate
- - - 549 100.00%6 1 3 32 0.00%
12 1 3 599 100.00%13 1 2 582 50.03%32 3 2 16689 99.97%
more CPU cycles. For an eviction rate of 100% the eviction setsize is at least 16 and the execution time at least 1460 cyclesin the same attack scenario.
Table I summarizes different eviction strategies for theKrait 400. The first column indicates the total eviction set sizeN . A denotes the shift offset to be applied after each round andD indicates the number of memory accesses in each iteration.The column cycles states the execution time for the evictionand the last column indicates the eviction rate. For instance, astrategy with the same loop as before, but only 2 accesses todifferent addresses per round over 13 rounds has an averageexecution time of only 582 cycles but the eviction rate drops to50%. The first line in Table I states the execution time and theeviction rate for the privileged flush instruction, which givesthe best result in terms of execution time (549 cycles). Ourbest identified eviction strategy also achieves an eviction rateof 100% but takes 599 cycles. Thus, there is a small trade-offbetween using the optimal but privileged flush instruction andthe unprivileged eviction strategy which takes slightly moretime.
We performed the same evaluation on our ARM Cortex-A53 test system. Figure 5 shows an excerpt of the best evictionpattern we found for this CPU. The access pattern consists ofa loop of 18 rounds, each with 4 repeated memory accesses tothe same 6 addresses and where theses accesses are shifted by1 in each iteration. Thus the eviction set contains 23 differentaddresses for the ARM Cortex-A53 with a 4-way L1 cacheand a 16-way L2 cache. Based on this eviction strategy, wemeasured an eviction rate of 99.86% and an average executiontime of 8789 cycles. Again accessing every address only oncein the eviction set only once is much less efficient although itinvolves significantly less memory accesses. For this strategy,we had to increase the eviction set size to 800 to achieve aneviction rate of 99.04%. Eviction then takes 131804 cycles,which is 15 times as much as with the best strategy we found.We suspect the reason for this in exclusiveness of the L2 cacheon the data side. We can only fill an L2 cache set by evictingdata from L1. Therefore, it is better to reaccess the data thatis already in the L2 cache and gradually add new addresses tothe set instead of accessing more different addresses.
Time
Add
ress
Fig. 5. Excerpt of the optimal access pattern on our Cortex-A53 test device.
078232431
Send SequenceNumber
Payload CRC
02310
Response SequenceNumber CRC
Fig. 6. Format of send data frames (above) and response data frames (below).
V. A HIGH PERFORMANCE CACHE COVERT CHANNEL
In this Section we describe a high performance cross-core cache covert channel on modern smartphones usingEvict+Reload. A covert channel enables two unprivileged ap-plications on a system to communicate with each other withoutusing any data transfer mechanisms provided by the operatingsystem. This communication evades the sandboxing conceptand the permission system. Particularly on Android this is aproblem, as this covert channel can be used to exfiltrate privatedata from the device that the Android permission system wouldnormally restrict. An attacker could use one application thathas access to the personal contacts of the owner of the device tosend data via the covert channel to another application that hasInternet access (cf. collusion attacks [34]). In such a scenarioan adversary can steal personal information.
Our covert channel is established on addresses of a sharedlibrary that is used by both, the sender and the receiver. Whileboth processes have read-only access to the shared library, theycan transmit information by loading addresses from the sharedlibrary into the cache or evicting it from the cache.
We implement the covert channel using a simple protocol.Data is transmitted in n bits, an additional s-bit sequence num-ber, and a c-bit checksum that is calculated over the payloadand the sequence number. The sequence number is used todistinguish consecutive packages and the checksum is used tocheck the integrity of the payload and the sequence number.If a received data package is valid, the s-bit sequence numberis sent back accompanied with an additional x-bit checksumcalculated over the returned sequence number. By adjustingthe sizes of checksums and sequence numbers the error rateof the covert channel can be controlled. Figure 6 illustrates thedata frames for sending data and the corresponding responses.
Each bit is represented by one address in the shared library,while no two addresses are chosen that map to the same cacheset. In order to transmit a bit value of 1, the sender accessesthe corresponding address in the shared library. To transmit abit value of 0, the sender does not access the correspondingaddress, resulting in a cache miss on the receiver’s side. Thus,the receiving process observes a cache hit or a cache missdepending on the memory access performed by the sender. Thesender then checks whether the acknowledge bit has been setby the receiver. If it is set, the response sequence number willbe measured on the corresponding cache sets. If the response
sequence number and the response checksum are valid, thesender continues with the next packet and resends the currentpacket otherwise. Algorithm 2 and Algorithm 3 provide a moreformal description of the sender and the receiver, respectively.
Algorithm 2: Sending dataInput: Mapped shared library mInput: Data to send dsn← Initial sequence number;for fn ← 1 to number of frames do
p← Current package (sn, dx, CS(fn, dx));received← false;do
Access sending bit address;Access or evict packet bit addresses;ack ← Access Acknowledge bit address;if ack ≡ true then
Measure response data addresses;snm, csm ← Response seq. number, CRC;if CS(sn, dx) ≡ csm and sn ≡ snm then
received← true;end
endwhile received ≡ false;sn← sn+ 1;
end
Algorithm 3: Receiving dataInput: Mapped shared library mwhile true do
received← false;do
sn← Initial sequence number;sending ← false;do
sending ← Measure sending bit address;while sending ≡ false;Measure packet data addresses;snm, dm, csm ← Sequence number, data, CRC;if CS(snm, dm) ≡ csm then
if sn ≡ snm thenreceived← true;Report dm;sn← sn+ 1;
endAccess acknowledge bit address;Access or evict response data bit addresses;
elseEvict acknowledge bit address;
endwhile received ≡ false;
end
We implemented this covert channel on our ARM Cortex-A53 device with the following parameters. We use an 8-bitchecksum, a 64-bit payload, and an 8-bit sequence number.According to these parameters, we achieve a transmission rateof 18 534 bps. A practical evaluation of our implementation ofthe proposed covert channel with these parameters yields anerror rate of 0%, which indicates that further improvements
TABLE II. COMPARISON OF COVERT CHANNELS ON ANDROID
Work Type Permission Bandwidth [bps]
Ours Cache - 18 534Marforio et al. [34] Type of Intents - 4 300Marforio et al. [34] UNIX socket discovery - 2 600Schlegel et al. [46] File locks - 685Schlegel et al. [46] Volume settings - 150Schlegel et al. [46] Vibration settings - 87Schlegel et al. [46] Screen wake lock WAKE_LOCK 5
might be possible. In particular the packet payload size can beincreased or checksum and sequence number size decreaseduntil the error rate reaches 1% while increasing the overalltransmission rate. However, the comparison in Table II showsthat our covert channel clearly outperforms existing covertchannels by a factor of 4 in terms of bandwidth. In addition,Marforio et al. [34] also reported that the XManDroid frame-work [10], [11] is able to detect the Type of Intents covertchannel as well as the UNIX socket discovery channel, whichindicates that the previously fastest covert channels can alreadybe prevented.
VI. SIDE-CHANNEL ATTACKS ON MOBILE DEVICES
In this section we demonstrate access-driven cache side-channel attacks on mobile Android devices. We implementcache template attacks as described by Gruss et al. [18] tocreate and exploit accurate cache-usage profiles using theEvict+Reload attack. Cache template attacks consist of aprofiling phase and an exploitation phase. In the profilingphase, a template matrix is computed that represents howmany cache hits occur on a specific address after triggeringa specific event. The exploitation phase uses this matrix toinfer events from cache hits. For further details about cachetemplate attacks we refer to Gruss et al. [18].
To perform cache template attacks, an attacker has to beable map shared binaries or shared libraries as read-only sharedmemory into its own address space. We have already shownthat this is possible in the previous section. By using sharedlibraries, the attacker bypasses any potential countermeasurestaken by the operating system, such as restricted access toruntime data of other apps or address space layout random-ization (ASLR). The attack can even be performed online onthe device under attack if the event can be simulated. Weexemplary show how to simulate these events in case of touchactions below.
Within the following subsections we show how cache tem-plate attacks can be used to infer touch actions and keystrokeson Android-based smartphones. Furthermore, we demonstratean effective attack against the AES T-table implementation,which is still deployed on all smartphones running stockversions of Android.
A. Inferring Touch Actions and Keystrokes
We launched cache template attacks on user input events inorder to find addresses in shared libraries that are responsiblefor user input handling. After identifying such addresses, theidea of cache template attacks is to monitor these addresses inorder to infer user input events. Just as Linux, Android usesa large number of shared libraries, each with a size of up toseveral megabytes. We inspected all available libraries on the
0x84
0
0x88
0
0x32
80
0x77
00
0x80
80
0x81
00
0x81
40
0x88
40
0x88
80
0x89
00
0x89
40
0x89
80
0x11
000
0x11
040
0x11
080
Addresses
text
tap
swipe
longpress
keyE
vent
Fig. 7. Cache template matrix for libinput.so.
system by manually scanning the names and identified librariesthat might be responsible for handling user input, e.g., like thelibinput.so library.1
After we identified libinput.so2 as our main targetlibrary, we launched the profiling phase of the cache templateattack. Thus, we simulated the user input events like tappingor swiping on the screen as well as sending text and keyevents to applications. We simulated these events via theandroid-debug bridge (adb shell) with two different methods.3The first method uses the input command line tool tosimulate user input events. The second method is writing eventmessages to /dev/input/event*. As the second methodonly requires a write() statement it is significantly faster,but it is also more device specific. Therefore, we used theinput command line tool in most scenarios. While simulatingthese events, we simultaneously probed all addresses within thelibinput.so library, i.e., we measured the number of cachehits that occurred on each address after triggering a specificevent.
Figure 7 shows the cache template matrix for thelibinput.so library. We triggered the following events:key events including the power button (key), long touch events(longpress), swipe events, touch events (tap), and text inputevents (text) via the input command line tool as often aspossible and measured each address for one second. The cachetemplate matrix clearly reveals addresses with high cache-hitrates for the corresponding events. More specifically, squareswith a darker color represent addresses with a higher cache-hit rate for the corresponding event, whereas lighter colorsrepresent addresses with lower cache-hit rates. Hence, thecache template matrix reveals addresses that can be used todistinguish different events.
We also verified the previously revealed addresses bymonitoring the identified addresses while operating the smart-phone manually, i.e., we touched the screen and our at-
1Note that we only restricted the set of possible libraries since testing alllibraries would have taken a significant amount of time. Yet, an adversary canalso exhaustively probe all available libraries.
2We considered this library as being responsible for processing input eventsdue to its name.
3Observe that triggering the actual event which an attacker wants to spy on,might require either (1) an offline phase or (2) privileged access. For instance,in case of a keylogger, the attacker can gather a cache template matrix offlinefor a specific version of a library, or the attacker relies on privileged access ofthe application (or a dedicated permission) in order to be able to simulate theevent for gathering the cache template matrix. However, the actual exploitationof the cache template matrix to infer the events does neither require privilegedaccess nor any permission.
0 5 10 15
50
100
150
200
Tap Tap Tap Swipe Swipe Swipe Tap Tap Tap Swipe Swipe
Time in seconds
Acc
ess
time
incy
cles
Fig. 8. A user input sequence of 3 tap events, 3 swipe events,3 tap events, and 2 swipe events measured on address 0x11040 of/system/lib/libinput.so on our ARM Cortex-A53 test device.
tack application reliably reported cache hits on the mon-itored addresses. For instance, on address 0x11040 of/system/lib/libinput.so tap actions and swipe ac-tions on the screen can be distinguished. Tap actions cause asmaller number of cache hits than swipe actions. Swipe actionscause cache hits in a high frequency as long as the screen istouched. In order to illustrate this, Figure 8 shows a sequenceof 3 tap events, 3 swipe events, 3 tap events, and 2 swipeevents. These events can be clearly observed by the fast accesstimes. The gaps mark periods of time where our program wasnot scheduled on the CPU. Events that would occur in thoseperiods can be missed by our attack.
Due to the fact that we are able to determine how long aswipe action lasts, we are able to infer the length of the enteredword on Android keyboards that use the so-called swipe inputmethod. Swipe input allows a user to enter words by swipingover the soft-keyboard and thereby connecting the singlecharacters to form a word. Since we are able to determinethe length of swipe movements, it is possible to correlate thelength of the swipe movement with the actual length of theword. Furthermore, for the pattern-unlock mechanism we candetermine the actual length of the unlock pattern.
In addition it is also possible to apply this attack to opti-mized virtual machine binaries or more recently used ahead-of-time compiled ART (Android Runtime) executables [2].We have used this attack on the AOSP Android Keyboardand evaluated the number of accesses to every address in theoptimized executable that responds to a tap of every letter onthe keyboard. It is possible to find addresses that correspondto a key press and more importantly to distinguish betweenthem. In Figure 9 we observe addresses where no hits occurredand addresses where the hit distribution is almost uniformfor every letter. These addresses can be used to monitor keypresses on the keyboard. In addition we identified an addressthat corresponds only to letters on the keyboard and hardly onthe space bar or the Enter button. With this information it ispossible to precisely determine the length of single words.
Similar to the attack on the libinput.so, we are ableto infer the length of words when the user simply taps on thecharacters of the soft-keyboard. This is due to the fact that weare able to distinguish taps on characters and taps on the spacebar. We illustrate an example of this observation in Figure 10.The red dots highlight the lower peaks of the red curve, thatis the spaces. The plot shows that we can clearly determinethe length of entered words and monitor user input accurately
0x45
140
0x56
940
0x57
280
0x58
480
0x60
280
0x60
340
0x60
580
0x66
340
0x66
380
Addresses
backspacespaceenter
zyxwvutsrqpon
ml
kji
hgfedcba
Inpu
t
Fig. 9. Cache template matrix for addresses in the AOSP keyboard.
0 1 2 3 4 5 6 7
100
200
300
t h i s Space i s Space a Space m e s s a g e
Time in seconds
Acc
ess
time
SpaceKey
Fig. 10. A user types the sentence “this is a message” on the Androidkeyboard. Key presses and spaces are monitored by performing Evict+Reloadon 2 addresses in custpack@app@[email protected]@classes.dex on our ARM Cortex-A53 test device.
over time.
While our proof-of-concept attack shows that any librarycan be attacked on Android smartphones, we want to pointout the impact of this finding. Table III lists libraries thathandle different hardware modules and software events on thedevice. An attacker can perform a cache template attack onany of these libraries and spy on the user’s interaction with thephone and learn the user’s behavior. For instance, our attackcan be used to reveal when the user uses the GPS sensor, whenbluetooth is active, or when the camera is used. Knowledgeabout the user’s activities can then be used to establish specificuser profiles.
Enhancing existing attacks. Considering the fact that ourattack allows to establish accurate inter-keystroke timings, wepoint out that this information can be used to infer enteredwords. The exploitation of inter-keystroke timings has been
TABLE III. LIBRARIES RESPONSIBLE FOR DIFFERENT HARDWARE ANDSOFTWARE
Library Responsible for
gps.msm8974.so GPScamera.vendor.bacon.so Cameralibnfc-nci.so NFCvibrator.default.so Vibratorlibavcodec.so Audio/Videolibstagefright.so Audio/Videolibwebviewchromium.so Websiteslibpdfium.so PDF library
shown by Zhang et al. [59]. Furthermore, even though ourevaluations so far did not reveal any addresses that leakentered keys directly, we can distinguish between keystrokeson the soft-keyboard and generic touch actions outside thesoft-keyboard. This information can be used to enhance exist-ing sensor-based keyloggers. Sensor-based keyloggers exploitsensors in mobile devices in order to infer the users’ input onthese devices. Examples include, for instance, the exploitationof the accelerometer and the gyroscope [6], [12], [13], [36],[57], and also the ambient-light sensor [48]. However, manyof these attacks suffer from a lack of knowledge when exactlya user touches the screen. Based on our attack, an attackercan improve upon these sensor-based keyloggers as our attackallows to infer (1) the exact time when the user touches thescreen, and (2) whether the user touches the soft-keyboard orany other region of the display.
B. Attack on Mobile AES Implementations
Cache attacks against AES T-table implementations havealready been demonstrated extensively. Eventually, counter-measures against these types of attacks have already beenproposed in order to prevent these attacks against AES. Amongthese countermeasures are, for instance, so-called bitslicedimplementations [27], [31], [45]. Furthermore, Intel addressedthe problem by adding dedicated instructions for AES [19],and also ARM follows the same direction with the ARMv8 in-struction set [4]. Thus, the academic community seems to agreethat attacking AES T-table implementations has become irrel-evant. However, our investigations showed that the OpenSSLlibrary as well as the Bouncy Castle crypto implementation onAndroid devices still use the T-table implementation, whichmight be due to performance reasons. These T-tables containthe precomputed round transformations SubBytes, ShiftRows,and MixColumns. The most-widely employed implementationuses five T-tables Ti, whereas T0 to T3 are used during thefirst 9 rounds, and the last round uses T4 due to the factthat the last round omits the MixColumns transformation.However, variants of this implementation with fewer tablesalso exist. The appealing benefit of T-table implementationsis that encryption and decryption operations can be computedby simple XOR operations. For instance, let pi denote theplaintext bytes, ki the initial key bytes, and si = pi ⊕ ki theinitial state after the first AddRoundKey transformation. Theinitial state is then used to retrieve the precomputed elementsvia Tj [si], where i ≡ j mod 16, which are then used to formthe state for the next round.
Now, if an attacker knows the plaintext as well as thecorresponding entries of the T-table that have been accessed,parts of the key bytes can be recovered via ki = si ⊕ pi.
0x00
0x10
0x20
0x30
0x40
0x50
0x60
0x70
0x80
0x90
0xA
0
0xB
0
0xC
0
0xD
0
0xE
0
0xF
0
Key byte values
0x424524000x424523c00x424523800x424523400x424523000x424522c00x424522800x424522400x424522000x424521c00x424521800x424521400x424521000x424520c00x424520800x424520400x42452000
Add
ress
es
Fig. 11. Attack on Bouncy Castle’s AES using Evict+Reload. The plaintextis fixed to 0x00.
For further details about this attack we refer to the workOsvik et al. [42], [53]. For the sake of simplicity—and sincewe only want to compare our results with related work—weconsider a first-round attack only. However, more sophisticatedattacks considering the first two rounds and also attacksconsidering the last round also exist [39], [53].
Stock Android versions ship OpenSSL 1.0.1 or earlier. Thisversion provides an optimized AES implementation for ARMusing a single 1KB S-Box. If certain flags during compile timeare not set it will fall back to the default vulnerable T-tableimplementation of AES. We have successfully performed atemplate attack on such an OpenSSL library using AES withT-tables to show that our attack works. The first round attackrequires as little as 224 encryptions per key byte to reduce thekey space to 64 bits. Similarly, the OpenSSL library shippedwith stock Android versions could be attacked by means of alast-round attack. However, to perform a more realistic attackwe need to attack an implementation that is widely used inpractice.
In order to do so, we focus on the Bouncy Castle AESimplementation, which is the default cryptographic providerfor Android apps. Bouncy Castle is implemented in Java anduses an AES T-table implementation by default, although T-table implementations are known to be vulnerable against side-channel attacks. Our attack of Bouncy Castle therefore affectsup to 1.4 billion Android users. Furthermore, we are the firstto show that even Java implementations can be attacked.
When the Bouncy Castle library is initialized in an Androidapplication, copies of the T-tables are created. These copiesare local and therefore not shared among multiple processes.Thus an Evict+Reload attack would only be possible withinthe same process but not in any real-world attack. However, toinvestigate the Evict+Reload attack and whether the BouncyCastle library is generally susceptible to cache side-channelattacks we perform an attack within the same process usingthe Evict+Reload attack. Figure 11 shows a template matrixof the first T-table for all 256 values for key byte k0 and afixed plaintext 0 while the remaining key bytes are random.
We can see that the correct value of the upper 4 bits ofthe key byte can clearly be determined from the observed
cache hits (cf. [42], [50]). The first round attack requires only512 encryptions per key byte to reduce the key space to 64bits. However, we also see that the T-table is not aligned. Wefound that the T-tables are placed on a different boundary everytime the process is started. If it is possible to trigger a restartof the victim application, it is possible to find an arbitrarydisalignment.
As shown by Spreitzer and Plos [50], disaligned T-tablesleak additional information as a smaller set of look-up indicessi = ki ⊕ pi map to cache lines at the beginning and theend of the T-tables. They observed that on average only 20bits of the key need to be searched exhaustively and specificdisalignments even allow full-key recovery without a singlebrute-force computation. Later, Takahashi et al. [52] theoret-ically investigated this information leak. Thus, the BouncyCastle crypto provider, which is the standard crypto provideron Android smartphones, is highly insecure.
In a real-world attack on Bouncy Castle an attacker hasno access to the memory and thus is not able to performan Evict+Reload attack on the corresponding memory region.However, a Prime+Probe attack is still possible as we describein the next section.
VII. THE PRIME+PROBE ATTACK ON ARM
The eviction used in our Evict+Reload attack also enablesimplementing Prime+Probe attacks. While apps can accessexecutable files of other apps and shared libraries likewisethis does not mean that an attack is always possible. Forinstance, in case of the Bouncy Castle AES implementation,the T-tables are copied to a local memory. Therefore, theattacker has no way to share this memory region with thevictim. For such scenarios we implemented Prime+Probe toperform cross-core last-level attacks without shared memory.Inherently a Prime+Probe side channel is more noisy andthus less accurate. Still it enables monitoring cache hits andmisses even on dynamically generated data. The possibilityof a Prime+Probe attack also shows that disabling sharedmemory does not prevent cache attacks on ARM.
Before performing a Prime+Probe attack, the attackerneeds to identify the CPU cache sets to be attacked. Inthe first step of the attack, the attacker “primes”, i.e., oc-cupies, the cache set by running the same eviction loopas in Evict+Reload. The attacker then waits for the victimto perform a computation. In the second step, the attacker“probes” the cache set by accessing all addresses from theeviction set in reverse order once again. Osvik et al. [42] haveshown that the time to access the addresses in this step isdirectly related to the number of ways that have been replacedby the victim. If the victim replaced no ways, the “probe” stepwill take minimal time. If the victim replaced more ways, the“probe” step will take longer. On x86 the replacement policyfacilitates this attack and an attacker can even deduce thenumber of ways that have been replaced in the cache set. Thisseems to be much more difficult on ARM, due to the randomreplacement policy, as has also been observed by Spreitzer andPlos [50]. However, we managed to launch a Prime+Probeattack on ARM, even though it is not as accurate as on x86platforms. Still, we show that it can be used to spy on processesthat could not be attacked otherwise. Algorithm 4 summarizesthe single steps for a Prime+Probe attack on a cache set s.
Algorithm 4: Prime+Probe attackInput: Cache set sOutput: Time to probe cache set s after victim has
been scheduledPrime: Occupy cache set s any dataWait for victim to be scheduledProbe: Re-access the data from the prime step inreverse orderif Probe time below threshold then
return No victim access (Miss)else
return Victim access (Hit)end
1,500 2,000 2,500 3,000 3,5000
2,000
4,000
6,000
Execution time in cycles
Num
ber
ofca
ses
Victim accessNo victim access
Fig. 12. Histogram of Prime+Probe probe time distribution when the victimdoes or does not access congruent memory as measured on the ARM Cortex-A53 test device.
As we can see in Figure 12, we can distinguish whetherthe victim accessed a congruent memory location. The timingis lower if the victim performed no access and higher ifthe victim did perform a congruent memory access. Whilethe measurement based on Prime+Probe is significantly morenoisy than in the case of Evict+Reload, it is still sufficient toperform practical attacks.
Figure 13 shows a Prime+Probe attack on the BouncyCastle implementation of AES. For each combination of keybyte and offset we performed 100 000 encryptions for illustra-tion purposes. Although we face significantly more noise inthis attack than in the Evict+Reload attack presented in theprevious section, we can clearly determine the upper 4 bitsper key byte using the Prime+Probe attack. The number ofencryptions can even be reduced to less than 100 encryptionsif the system load is low. In such a case we could reduce thekey space to 64 bits within 25 600 encryptions.
VIII. COUNTERMEASURES
Our attack exploits weaknesses in hardware and in soft-ware. While building better hardware could completely preventattacks, software weaknesses can be fixed immediately oncommodity hardware and in commodity software environ-ments. The software weaknesses we exploit exist in older aswell as recent Android versions alike.
The first software weakness we exploit is the unprivilegedaccess to the perf_event_open syscall interface. Thisinterface allows access to an accurate cycle counter amonga variety of other accurate hardware performance counters. Inour attack we use this interface as a replacement to the x86
0x00
0x10
0x20
0x30
0x40
0x50
0x60
0x70
0x80
0x90
0xA
0
0xB
0
0xC
0
0xD
0
0xE
0
0xF
0
Key byte values
0x3C0
0x380
0x340
0x300
0x2C0
0x280
0x240
0x200
0x1C0
0x180
0x140
0x100
0x0C0
0x080
0x040
0x000
Off
set
Fig. 13. Attack on Bouncy Castle’s AES using Prime+Probe. The plaintextis fixed to 0x00.
rdtsc instruction. If an attacker would not be able to retrievean accurate cycle count it would be significantly harder todetermine whether a memory access has been a cache hit or acache miss. Therefore, we suggest making the syscall interfaceonly available to privileged processes and especially preventAndroid apps from accessing it. However, performing cacheattacks without accurate timing is possible by running a secondthread that increments a global variable all the time. By readingthe value of the variable an attacker can retrieve a timestamp.Thus, only restricting access to the perf_event_opensyscall interface is not sufficient to make the attack impossible.
The second software weakness we exploit is access to/proc/pid/ information for the own process as well asother processes. In our attack we use /proc/pid/pagemapto resolve virtual addresses to physical addresses. In March2015, Linux restricted access to /proc/pid/pagemap forother processes without elevated privileges to prevent leak-age of physical addresses to unprivileged processes. Later inMarch access to /proc/self/pagemap has been restrictedtoo, in order to prevent usage of virtual address resolutionfor Rowhammer attacks. However, the Android kernel hasnot yet integrated these patches. Our findings show thatcache attacks in general are another reason to restrict accessto /proc/pid/pagemap on all platforms. We also use/proc/pid/maps to determine shared objects mapped intothe virtual address space of a victim binary. We suggest torestrict access to /proc/pid/maps such that a processcan only see its own mappings and that elevated privilegesare required to access information of other processes. Thishowever, has to be fixed in the Linux kernel as well as inAndroid.
Third, we exploit the fact that access to shared librariesas well as dex and art optimized program binaries of otherapplications is only partially restricted. While we cannot re-
trieve a directory listing of /data/dalvik-cache/ all filescontained are readable for any process or Android application.We propose to restrict read access to the actual owner of thefile to prevent Evict+Reload attacks over these shared files.
In order to prevent cache attacks against AES T-table, abitsliced implementation could be employed. Since OpenSSL1.0.2 such a bitsliced implementation exists for devices capableof the ARM NEON instruction set. Furthermore, this OpenSSLversion also includes supports for the ARMv8 native AESinstructions. Thus, updating to this version of OpenSSL wouldrender our attacks infeasible.
IX. FUTURE WORK
Our work shows that powerful cache attacks are alsopossible on recent smartphones. While this insight significantlyadvances the state-of-the-art in the context of cache attackson mobile devices, we believe that this only scratches thesurface of possible attacks. First, in the mobile area we have avariety in hardware and operating systems. We believe that ourattack is possible on other mobile operating systems as wellas long as the underlying hardware is based on the ARMv7or ARMv8 architecture. Second, the smartphone is the mostpersonal computing device. Existing attacks focus on stealingcryptographic keys, session tokens or spying on user input.The possibility of profiling users and spying on user activitiesaround-the-clock shifts the focus of cache attacks to a newrange of potential malicious applications. For instance, cachetemplate attacks can be used to profile the users’ activities.The possibility of adversaries infiltrating the personal devicesof millions of users emphasizes the need to investigate andimplement effective countermeasures immediately.
Our attack requires the user to install a malicious appon the smartphone. However, as shown by Oren et al. [41],Prime+Probe attacks can even be performed from withinbrowser sandboxes through remote websites using JavaScripton Intel platforms. We believe that such an attack could beimplemented on smartphones as well.
Our attack on the ARM Cortex-A53 is facilitated bythe introduction of the inclusiveness of the last-level cache.Removing the inclusive property to prevent cross-core cacheattacks is ineffective. As we found on our Krait 400 test device,the cross-core attacks are still possible in most cases. We thinkthat this is due to a cache-coherency protocol between CPUcores. Remote-core data fetches are most likely faster thanaccesses to physical memory. Thus, we might observe theseremote-core data fetches as cache hits. However, this requiresa cache-coherency protocol that implements this behavior.Generally, our attack is not possible on exclusive last-levelcaches. Although it is possible to attack these architecturesby spawning one attack process per core, exclusive last-levelcaches should be investigated to find whether they can beattacked using cross-core cache attacks.
X. CONCLUSION
In this work, we proposed the first access-based cross-core cache attack on ARM-based mobile devices. Similarlyto the powerful Flush+Reload attack on the x86 architecture,Evict+Reload is a highly accurate and generic cache attack.Furthermore, we show that despite the random replacement
policy Prime+Probe attacks can be implemented to efficientlyperform attacks in all cases where Evict+Reload is not appli-cable. Our work is the first to provide a comprehensive studyof the Evict+Reload attack and the powerful applications ofEvict+Reload and Prime+Probe on Android smartphones.
Since smartphones have become the most important per-sonal computing devices, this work significantly broadens thescope of cache attacks. First, all cache attacks known forx86 CPUs can now be applied on ARM CPUs as well. Inorder to enable these attacks in a real-world scenario wehave overcome all challenges that prevented highly accuratecache attacks on ARM. Second, contrary to existing cacheattacks against cryptographic primitives on ARM CPUs, ourattack does not require any permissions and can be executedon any non-rooted device. Our attack works on millions ofoff-the-shelf Android smartphones. Furthermore, our attackis not specifically tailored for any cryptographic algorithmbut instead can be used to launch cache template attackson any target application, e.g., libraries or Android apps.More specifically, we demonstrated the immense power of theEvict+Reload attack by inferring specific user interactions withthe mobile device. This includes touch and swipe actions on thescreen, touch actions on the soft-keyboard, and inter-keystroketimings. In addition we present an efficient key-recovery attackon the default AES implementation that is part of the JavaBouncy Castle library.
The presented example attacks are by no means exhaustiveand launching our proposed attack against other librariesand apps will reveal further exploitable information leaks.Thus, our findings stress the urgent need to deploy effectivecountermeasures in order to protect millions of Android usersfrom being attacked.
REFERENCES
[1] Anand Lal Shimpi, “Answered by the Experts: ARM’s Cortex A53Lead Architect, Peter Greenhalgh,” http://www.anandtech.com/show/7591/answered-by-the-experts-arms-cortex-a53-lead-architect-peter-greenhalgh, Dec. 2013, retrieved on November 10, 2015.
[2] Android Open Source Project, “Configuring ART,” https://source.android.com/devices/tech/dalvik/configure.html, Nov. 2015, retrievedon November 10, 2015.
[3] ARM Limited, ARM Architecture Reference Manual. ARMv7-A andARMv7-R edition. ARM Limited, 2012.
[4] ——, ARM Architecture Reference Manual ARMv8. ARM Limited,2013.
[5] ——, ARM Cortex-A53 MPCore Processor Technical Reference Manualr0p3. ARM Limited, 2014.
[6] A. J. Aviv, B. Sapp, M. Blaze, and J. M. Smith, “Practicality ofAccelerometer Side Channels on Smartphones,” in Annual ComputerSecurity Applications Conference – ACSAC 2012. ACM, 2012, pp.41–50.
[7] N. Benger, J. van de Pol, N. P. Smart, and Y. Yarom, “”Ooh Aah...Just a Little Bit” : A Small Amount of Side Channel Can Go a LongWay,” in Cryptographic Hardware and Embedded Systems – CHES, ser.LNCS, vol. 8731. Springer, 2014, pp. 75–92.
[8] D. J. Bernstein, “Cache-Timing Attacks on AES,” 2004, URL:http://cr.yp.to/papers.html#cachetiming.
[9] A. Bogdanov, T. Eisenbarth, C. Paar, and M. Wienecke, “DifferentialCache-Collision Timing Attacks on AES with Applications to Embed-ded CPUs,” in Topics in Cryptology – CT-RSA, ser. LNCS, vol. 5985.Springer, 2010, pp. 235–251.
[10] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, and A.-R. Sadeghi,“XManDroid: A New Android Evolution to Mitigate Privilege Esca-lation Attacks,” CASED@TU Darmstadt, Tech. Rep., 04 2011.
[11] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A. Sadeghi, and B. Shas-try, “Towards Taming Privilege-Escalation Attacks on Android,” inNetwork and Distributed System Security Symposium – NDSS 2012.The Internet Society, 2012.
[12] L. Cai and H. Chen, “TouchLogger: Inferring Keystrokes on TouchScreen from Smartphone Motion,” in USENIX Workshop on Hot Topicsin Security – HotSec 2011. USENIX Association, 2011.
[13] ——, “On the Practicality of Motion Based Keystroke Inference At-tack,” in Trust and Trustworthy Computing – TRUST 2012, ser. LNCS,vol. 7344. Springer, 2012, pp. 273–290.
[14] J. Daemen and V. Rijmen, The Design of Rijndael: AES – The AdvancedEncryption Standard, ser. Information Security and Cryptography.Springer, 2002.
[15] J.-F. Gallais and I. Kizhvatov, “Error-Tolerance in Trace-Driven CacheCollision Attacks,” in COSADE, Darmstadt, 2011, pp. 222–232.[Online]. Available: http://cosade2011.cased.de/files/2011/cosade2011talk21 paper.pdf
[16] J. Gallais, I. Kizhvatov, and M. Tunstall, “Improved Trace-DrivenCache-Collision Attacks against Embedded AES Implementations,” inWISA 2010, ser. LNCS, vol. 6513. Springer, 2010, pp. 243–257.
[17] D. Gruss, C. Maurice, and S. Mangard, “Rowhammer.js: A Re-mote Software-Induced Fault Attack in JavaScript,” CoRR, vol.abs/1507.06955, 2015.
[18] D. Gruss, R. Spreitzer, and S. Mangard, “Cache Template Attacks: Au-tomating Attacks on Inclusive Last-Level Caches,” in USENIX SecuritySymposium 2015. USENIX Association, 2015, pp. 897–912.
[19] S. Gueron, “White Paper: Intel Advanced Encryption Standard (AES)Instructions Set,” 2010, URL: https://software.intel.com/file/24917.
[20] D. Gullasch, E. Bangerter, and S. Krenn, “Cache Games – BringingAccess-Based Cache Attacks on AES to Practice,” in IEEE Symposiumon Security and Privacy – S&P. IEEE Computer Society, 2011, pp.490–505.
[21] B. Gulmezoglu, M. S. Inci, T. Eisenbarth, and B. Sunar, “A Faster andMore Realistic Flush+Reload Attack on AES,” in Constructive Side-Channel Analysis and Secure Design – COSADE, ser. LNCS. Springer,2015, in press.
[22] R. Hund, C. Willems, and T. Holz, “Practical Timing Side ChannelAttacks against Kernel Space ASLR,” in IEEE Symposium on Securityand Privacy – S&P. IEEE, 2013, pp. 191–205.
[23] G. Irazoqui, T. Eisenbarth, and B. Sunar, “S$A: A Shared CacheAttack that Works Across Cores and Defies VM Sandboxing – andits Application to AES,” in IEEE Symposium on Security and Privacy– S&P. IEEE Computer Society, 2015.
[24] G. Irazoqui, M. S. Inci, T. Eisenbarth, and B. Sunar, “Wait a Minute!A fast, Cross-VM Attack on AES,” in Research in Attacks, Intrusionsand Defenses Symposium – RAID, ser. LNCS, vol. 8688. Springer,2014, pp. 299–319.
[25] ——, “Know Thy Neighbor: Crypto Library Detection in Cloud,”Privacy Enhancing Technologies, vol. 1, no. 1, pp. 25–40, 2015.
[26] ——, “Lucky 13 Strikes Back,” in ACM Computer and CommunicationsSecurity – ASIACCS 2015, 2015, pp. 85–96.
[27] E. Kasper and P. Schwabe, “Faster and Timing-Attack Resistant AES-GCM,” in Cryptographic Hardware and Embedded Systems – CHES,ser. LNCS, vol. 5747. Springer, 2009, pp. 1–17.
[28] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, “Side Channel Crypt-analysis of Product Ciphers,” Journal of Computer Security, vol. 8, no.2/3, pp. 141–158, 2000.
[29] Kirill A. Shutemov, “Pagemap: Do Not Leak Physi-cal Addresses to Non-Privileged Userspace,” https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce, Mar. 2015, retrievedon November 10, 2015.
[30] P. C. Kocher, “Timing Attacks on Implementations of Diffie-Hellman,RSA, DSS, and Other Systems,” in Advances in Cryptology – CRYPTO,ser. LNCS, vol. 1109. Springer, 1996, pp. 104–113.
[31] R. Konighofer, “A Fast and Cache-Timing Resistant Implementation ofthe AES,” in Topics in Cryptology – CT-RSA, ser. LNCS, vol. 4964.Springer, 2008, pp. 187–202.
[32] F. Liu, Y. Yarom, Q. Ge, G. Heiser, and R. B. Lee, “Last-Level CacheSide-Channel Attacks are Practical,” in IEEE Symposium on Securityand Privacy – SP 2015. IEEE Computer Society, 2015, pp. 605–622.
[33] N. Lomas, “Android now has 1.4 billion 30-day active usersglobally,” Sep. 2015, retrieved on Nov 11, 2015. [Online].Available: http://techcrunch.com/2015/09/29/android-now-has-1-4bn-30-day-active-devices-globally
[34] C. Marforio, H. Ritzdorf, A. Francillon, and S. Capkun, “Analy-sis of the communication between colluding applications on modernsmartphones,” in Annual Computer Security Applications Conference –ACSAC 2012, R. H. Zakon, Ed. ACM, 2012, pp. 51–60.
[35] C. Maurice, C. Neumann, O. Heen, and A. Francillon, “C5: Cross-Cores Cache Covert Channel,” in Detection of Intrusions and Malware,and Vulnerability Assessment – DIMVA 2015, ser. LNCS, vol. 9148.Springer, 2015, pp. 46–64.
[36] E. Miluzzo, A. Varshavsky, S. Balakrishnan, and R. R. Choudhury,“Tapprints: Your Finger Taps Have Fingerprints,” in Mobile Systems,Applications, and Services – MobiSys 2012. ACM, 2012, pp. 323–336.
[37] National Institute of Standards and Technology, “Advanced EncryptionStandard. NIST FIPS PUB 197,” 2001.
[38] M. Neve, “Cache-based Vulnerabilities and SPAM Analysis,” Ph.D.dissertation, UCL, 2006.
[39] M. Neve and J. Seifert, “Advances on Access-Driven Cache Attacks onAES,” in Selected Areas in Cryptography – SAC 2006, ser. LNCS, vol.4356. Springer, 2006, pp. 147–162.
[40] M. Neve, J. Seifert, and Z. Wang, “A Refined Look at Bernstein’sAES Side-Channel Analysis,” in ACM Computer and CommunicationsSecurity – ASIACCS 2006. ACM, 2006, p. 369.
[41] Y. Oren, V. P. Kemerlis, S. Sethumadhavan, and A. D. Keromytis,“The Spy in the Sandbox: Practical Cache Attacks in JavaScript andtheir Implications,” in Conference on Computer and CommunicationsSecurity – CCS 2015. ACM, 2015, pp. 1406–1418.
[42] D. A. Osvik, A. Shamir, and E. Tromer, “Cache Attacks and Counter-measures: The Case of AES,” in Topics in Cryptology – CT-RSA, ser.LNCS, vol. 3860. Springer, 2006, pp. 1–20.
[43] D. Page, “Theoretical Use of Cache Memory as a Cryptanalytic Side-Channel,” IACR Cryptology ePrint Archive, vol. 2002, p. 169, 2002.
[44] C. Percival, “Cache Missing for Fun and Profit,” 2005, URL: http://daemonology.net/hyperthreading-considered-harmful/.
[45] C. Rebeiro, A. D. Selvakumar, and A. S. L. Devi, “Bitslice Implementa-tion of AES,” in Cryptology and Network Security – CANS, ser. LNCS,vol. 4301. Springer, 2006, pp. 203–212.
[46] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X. Wang,“Soundcomber: A Stealthy and Context-Aware Sound Trojan for Smart-phones,” in Network and Distributed System Security Symposium –NDSS 2011. The Internet Society, 2011.
[47] M. Seaborn, “Exploiting the DRAM rowhammer bug to gain kernelprivileges,” http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html, March 2015, retrieved on June 26,2015.
[48] R. Spreitzer, “PIN Skimming: Exploiting the Ambient-Light Sensor inMobile Devices,” in Security and Privacy in Smartphones & MobileDevices – SPSM@CCS 2014. ACM, 2014, pp. 51–62.
[49] R. Spreitzer and B. Gerard, “Towards More Practical Time-DrivenCache Attacks,” in Information Security Theory and Practice – WISTP2014, ser. LNCS, vol. 8501. Springer, 2014, pp. 24–39.
[50] R. Spreitzer and T. Plos, “Cache-Access Pattern Attack on DisalignedAES T-Tables,” in Constructive Side-Channel Analysis and SecureDesign – COSADE 2013, ser. LNCS, vol. 7864. Springer, 2013, pp.200–214.
[51] ——, “On the Applicability of Time-Driven Cache Attacks on MobileDevices,” in Network and System Security – NSS 2013, ser. LNCS, vol.7873. Springer, 2013, pp. 656–662.
[52] J. Takahashi, T. Fukunaga, K. Aoki, and H. Fuji, “Highly AccurateKey Extraction Method for Access-Driven Cache Attacks Using Cor-relation Coefficient,” in Australasian Conference Information Securityand Privacy – ACISP 2013, ser. LNCS, vol. 7959. Springer, 2013, pp.286–301.
[53] E. Tromer, D. A. Osvik, and A. Shamir, “Efficient Cache Attacks onAES, and Countermeasures,” Journal Cryptology, vol. 23, no. 1, pp.37–71, 2010.
[54] Y. Tsunoo, T. Saito, T. Suzaki, M. Shigeri, and H. Miyauchi, “Crypt-analysis of DES Implemented on Computers with Cache,” in Crypto-graphic Hardware and Embedded Systems – CHES, ser. LNCS, vol.2779. Springer, 2003, pp. 62–76.
[55] J. van de Pol, N. P. Smart, and Y. Yarom, “Just a Little Bit More,” inTopics in Cryptology – CT-RSA 2015, ser. LNCS, vol. 9048. Springer,2015, pp. 3–21.
[56] M. Weiß, B. Heinz, and F. Stumpf, “A Cache Timing Attack on AESin Virtualization Environments,” in Financial Cryptography and DataSecurity – FC 2012, ser. LNCS, vol. 7397. Springer, 2012, pp. 314–
328.[57] Z. Xu, K. Bai, and S. Zhu, “TapLogger: Inferring User Inputs on
Smartphone Touchscreens Using On-board Motion Sensors,” in Securityand Privacy in Wireless and Mobile Networks – WISEC 2012. ACM,2012, pp. 113–124.
[58] Y. Yarom and K. Falkner, “FLUSH+RELOAD: A High Resolution,Low Noise, L3 Cache Side-Channel Attack,” in USENIX SecuritySymposium. USENIX Association, 2014, pp. 719–732.
[59] K. Zhang and X. Wang, “Peeping Tom in the Neighborhood: KeystrokeEavesdropping on Multi-User Systems,” in USENIX Security Sympo-sium. USENIX Association, 2009, pp. 17–32.