Maria Mushtaq

Software-based Detection and Mitigation of Microarchitectural Attacks on Intel's x86 Architecture

Keywords:

The revelations of security and privacy vulnerabilities in microprocessors, both at hardware and software level, have shocked the world over the past few years. These vulnerabilities affect almost every processor, across virtually every operating system and architecture. The fundamental reason for existence of these vulnerabilities is that the evolution of computing architecture under Moore's law has been focused almost entirely on the performance enhancement and optimization over the past many decades. To this end, the gains are tremendous as many software and hardware optimization tools and techniques have been proposed to boost performance, such as: hierarchical and shared-memory architectures, pipelining, out-of-order execution, speculative execution, branch prediction, data/instruction de-duplication, shared libraries, compiler optimizations, use of virtual memory and use of specialized hardware accelerators and GPUs. In recent years, however, researchers have demonstrated that modern computing systems are vulnerable both from computational as well as storage perspectives and most of these performance optimizations can potentially expose the system to adversary and leak critical information. These existing vulnerabilities lead to side-channel information leakage in many different ways, such as: variation in physical parameters like power consumption, electromagnetic radiation and acoustic emanation as well as logical parameters like memory access pattern, access timing and fault occurrences. Moreover, new leakage channels keep appearing in existing architectures. Thus, as of today, the real attack surface is unknown, both at the software level and at the hardware level. Side-Channel Attacks (SCAs) exploit these vulnerabilities to extract privileged information both at computational and storage levels.

Access-driven cache-based side-channel attacks, a sub-category of SCAs, are strong cryptanalysis techniques that break cryptographic algorithms by targeting their implementations. Despite valiant efforts, mitigation techniques against such attacks are not very effective. This is mainly because most mitigation techniques usually protect against any given specific vulnerability and do not take a system-wide approach. Moreover, these solutions either completely remove or greatly reduce the prevailing performance benefits in computing systems that are hard-earned over many decades. Today, security and privacy is an added design constraint, along with the pre-existing performance requirements, for computing systems.

"The real challenge is to love the good and the bad together, not because you need to take the rough with the smooth, but because you need to go beyond such descriptions & accept love in its entirety!"

List of Figures

List of Tables

Relevant indicative parameters of cache in Intel x86 architectures (Intel Xeon

Processors) [START_REF] Costan | SGX Explained[END_REF], [START_REF]ARK-your source for Intel product specifications[END_REF], [START_REF] Disselkoen | Prime+Abort: A Timer-Free High-Precision L3 Cache Attack using Intel TSX[END_REF]

Motivation

Information security has become one of the paramount concerns with the evolution of computing and storage infrastructures. Over the past decade or so, there has been an explosion in the amount of digital data. The increased interaction of physical and cyber domains through Internet-of-Things (IoT) and Cyber-Physical Systems (CPS) and the emergence of new fields like autonomous vehicles and Blockchain technology has lead to an exponential increase in the amount of produced digital data over the past few years.

According to IBM Big Data Research [1], roughly 2.5 quintillion bytes of data is produced each single day. Other sources also report that, on average, 300 hours of video content is uploaded on YouTube every minute, 95 million and 300 million photos are uploaded daily on

Instagram and Facebook, respectively [2]. The information buried in these data is valuable to society, be it commercial, economic, environmental, governmental statistics, or concerning the health and privacy of individuals. Faced with this deluge of data, information processing infrastructures have evolved in order to increase their performance, energy efficiency, reliability, and safety. These platforms are now increasingly shifted from the end-user towards centralized computing facilities -thus, the concept of cloud computing, in order to liberate the end-user terminals from excessively high computational loads. Cloud Computing is the delivery of on-demand computing resources -including everything from applications to data centers over the internet. The issue of trust between end-users and cloud computing platforms is, however, a major concern that is preventing the acceptance of this new technological solution at large. Modern-day cloud computing solutions offer Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) for both public and private cloud [1]. These services provide virtualized system resources to the end-users that help in offering high utilization through resource sharing. Such systems usually co-host multiple Virtual Machines (VMs) on the same hardware platform, which is managed by Virtual Machine Monitors (VMMs) to insulate VMs and system resources.

While virtualization is supposed to provide insulation and exclusivity to resource access, in practice, the VMs are designed to share the same physical resources that creates a loophole for potential interference. The co-resident VMs that share physical resources are mutually distrusting. For instance, a malicious VM co-residing with a victim VM can get to know the information of other VM [3], [4], [5] through resource sharing and can cause greater damage by conducting a Side-Channel Attack (SCA) on the operations of victim VM [6], [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF]. Thus, exposing the system to the conventional challenges of information security represented through the classical CIA (Confidentiality, Integrity, and Availability) triad. Absolute system confidentiality, integrity, and availability cannot be achieved concurrently. Therefore, all systems will have design trade-offs resulting in inherent vulnerabilities and making system susceptible to attacks. Authors in [START_REF] Hughes | Quantitative Metrics and Risk Assessment: The Three Tenets Model of Cybersecurity[END_REF] essentially proposed another triad related to attacks and proposed a three tenets attack model as shown in Figure 1.1. Their model posits the necessary & sufficient conditions for a successful attack. The model suggests that a system's susceptibility, physical/logical accessibility, and attacker's capability in terms of resources, tools & techniques available to take advantage of two former conditions is necessary for any successful attack to occur. Systems, such as cloud computing platforms, offer huge value to the attacker in the form of access to privileged information. Thus, any vulnerabilities in such systems provide leakage channels. In the following sections, we discuss those vulnerabilities, particularly in Intel's x86 architecture, and the leakage channels created due to them. data/instructions, but at the same time, they allow distinction between execution time of different data/instructions (cache hit & miss times are different) as well as access patterns of processes. Software optimizations for storage, such as shared libraries, page sharing and de-duplication techniques offer better memory footprint for the running processes, but they also allow interference into restricted address space of mutually distrusting processes. Lastly, these memories are inclusive in order to maintain coherency, but inclusivity promotes the use of instruction privilege that can be misused by certain co-existing processes. The use of clflush instruction by certain attacks in Intel's x86 architecture is an example of this vulnerability.

From the computational perspective, modern processors use branch prediction units, out-of-order execution technique and speculative execution in order to minimize the wastage of important clock cycles. Some recent research works have demonstrated that, while doing so, these optimization techniques can allow a process to generate memory access requests to the privileged kernel address space of the operating system, which is otherwise an out-of-bound address for user space processes. Recent attacks like Spectre and Meltdown exploit these computational vulnerabilities in Intel's architecture and expose design flaws.

These existing computational and storage vulnerabilities lead to side-channel information leakage in many different ways. Moreover, new leakage channels keep appearing in existing architectures. Thus, a complete attack surface is yet to be fully known. Side-Channel Attacks (SCAs) exploit these vulnerabilities to extract privileged information both at computational and storage levels. Therefore, it is essential to elaborate the potential threats emanating from these SCAs, which is presented in the following sections.

Side-channel Attacks (SCAs)

Encryption has been used conventionally to secure important information. Significant amount of research has been performed in the field of cryptography, leading to the development of different crypto-algorithms like AES, RSA, ElGamal and ECC etc. Theoretically, these algorithms are very strong and they would require enormous computing power to break. Thus, they protect well the information theft or leakage from any brute-force attacks. The SCAs, however, are powerful cryptanalysis techniques that focus on the implementations of cryptographic cipher [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF] rather than attacking the underlying structure of cryptographic functions. Figure 1.2 illustrates how useful information related to the execution can leak through unintended side-channels during computation. SCAs use variation in physical parameters (like power consumption [START_REF] Paul | Differential Power Analysis[END_REF], electromagnetic radiation [START_REF] Quisquater | ElectroMagnetic Analysis (EMA): Measures and Counter-measures for Smart Cards[END_REF], acoustic emanation [START_REF] Daniel Genkin | RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis[END_REF], memory access pattern, access timing and fault occurrence [6], [START_REF] Gullasch | Cache Games -Bringing Access-Based Cache Attacks on AES to Practice[END_REF], [START_REF] Tromer | Efficient Cache Attacks on AES, and Countermeasures[END_REF], [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF], [START_REF] Gruss | Cache Template Attacks: Automating Attacks on Inclusive Last-level Caches[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Zhang | Cross-Tenant Side-Channel Attacks in PaaS Clouds[END_REF], [START_REF] Irazoqui | Wait a Minute! A fast, Cross-VM Attack on AES[END_REF]) generated by the execution of specific implementation of cipher to extract The scope of this thesis is limited to deal with the software SCAs mainly, which target timing and access pattern of cryptosystems to retrieve privileged information.

Problem Statement

Hardware is often considered as an abstract layer that behaves correctly -executing instructions and giving an output. However, side effects due to software implementation and its execution on actual hardware can cause information leakage from side-channels, resulting in critical vulnerabilities impacting both the security and privacy of these systems. At the software layer, modern cryptographic algorithms are theoretically sound to protect information and they require enormous computing power to break. For instance, for a 128-bit AES key, it would take 5.4 × 10 18 years to crack the AES using a computer capable of performing 10 6 decryption operations per µs [START_REF] Stallings | Cryptography and network security: principles and practice[END_REF]. However, many research works have shown that cryptosystems, such as AES and RSA, can be compromised due to the vulnerabilities of the underlying hardware on which they run as shown in Figure 1.5. The SCAs do not target the algorithm of cryptosystems itself. Rather, they target the underlying implementation of systems on which these cryptosystems execute [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF]. Figure 1.5 illustrates that, even though the system software does not allow two co-residing processes to directly communicate with each other, the shared memory between these coresiding processes provides an opportunity to interact and eventually access the otherwise privileged private data/instructions. As illustrated in Figure 1.5, if one of these processes happens to be a cryptosystem that is computing some secret key-dependent operations in a sequence, then shared memory can reveal the execution and access sequence of instructions. The baseline idea here is that the SCAs can analyze the variations in these parameters during the execution of cryptosystems on a particular hardware and can determine the secret information used by cryptosystems based on the observed parameters. The threat of side-channel leakage, thus, imposes a serious concern to data privacy as it can break the otherwise theoretically sound cryptographic algorithms at their implementation-level [START_REF] Lyu | A Survey of Side-Channel Attacks on Caches and Countermeasures[END_REF]. Modern-day processors do extensive sharing and de-duplication, like in case of Simultaneous Multi-Threading (SMT), for performance benefits that creates unindended side-channels and leaves system vulnerable. Such attacks can be prevented at various levels such as system-level, hardware-level and application-level [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF]. At the system level, physical and logical isolation approaches exist [START_REF] Jin | A Simple Cache Partitioning Approach in a Virtualized Environment[END_REF]. At the hardware level, mitigation techniques are rather difficult due to cost and complexity of their design. Hardware solutions, nevertheless, suggest having new secure caches, changes in prefetching policies and either randomization or complete removal of cache interference [START_REF] Liu | Random Fill Cache Architecture[END_REF]. At the application level, the proposed countermeasures tend to target the source of information leakage and mitigate it [START_REF] Kim | STEALTHMEM: System-Level Protection Against Cache-Based Side Channel Attacks in the Cloud[END_REF]. However, despite valiant efforts, mitigation techniques against SCAs are not very effective. This is mainly because mitigation techniques usually protect against any given specific vulnerability of the system and do not take a system-wide approach. Moreover, they either completely remove or greatly reduce the performance benefits of resource sharing. In addition to that, new attacks keep appearing that exploit new vulnerabilities and the attack surface keeps expanding. As of today, the real attack surface is unknown, both at the software level and at the hardware level. These attacks are becoming sophisticated and stealthier [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. Thus, they overcome statically applied mitigation techniques. Therefore, on the one hand, protection against these CSCAs needs to be applied across the entire computing stack and, on the other hand, mitigation strategies must not take away the hard-earned performance benefits of computing systems over past many decades.

The problem at large is to defend against side-channel information leakage in computing systems without compromising or removing the performance benefits that have been achieved through the evolution of computing architectures under Moore's law. There is a niche solution, which is often not the case for existing mitigation solutions. The state-of-the-art suggests that mitigation solutions are mostly designed to address a specific vulnerability at a particular cache level. One major issue with the existing detection and mitigation solutions, independently, is that they are not resilient to noise generated by the system under various realistic load conditions. In practice, however, attacks can occur under normal system load and in any temporal order. Although mitigation solutions can be envisioned at different levels, such as: at the hardware, system, or application level, but irrespective of their level, these countermeasures suffer from a general lack of adoption due to compromises between security and performance as well as the lack of resilience to system's noise. In this thesis, we answer these open research questions and provide extensive experimental evaluation to validate our arguments.

Contributions and Organization of Manuscript 1.5.1 Contributions

This thesis offers two major technical contributions: (1) a run-time detection framework for high resolution and stealthy CSCAs and (2) a detection-based mitigation mechanism against CSCAs as an operating system's service.

As part of the first contribution, this thesis addresses the problem of accurate & early detection of CSCAs at run-time. We propose to use machine learning for security. We demonstrate that intelligent performance monitoring of concurrent processes at hardwarelevel, coupled with machine learning methods, can enable early detection of high precision and stealthier CSCAs. The state-of-the-art, discussed in Chapter 2, suggests that there exist some solutions based on machine learning for detection of CSCAs such as: [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF], [START_REF] Bazm | Cache-Based Side-Channel Attacks Detection through Intel Cache Monitoring Technology and Hardware Performance Counters[END_REF], [START_REF] Mushtaq | NIGHTs-WATCH: a cache-based side-channel intrusion detector using hardware performance counters[END_REF], [START_REF] Mushtaq | Run-time Detection of Prime+ Probe Side-Channel Attack on AES Encryption Algorithm[END_REF], [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF]. However, there are two major limitations in the prior work. Firstly, the machine learning models used in these solutions are trained to classify one specific attack, or a subset of attacks, belonging to any one category. Thus, when exposed to other CSCAs, these models are required to be retrained. Secondly, even retraining of machine learning model may not yield the same accuracy because different CSCAs exploit different cache vulnerabilities and the same model might simply not be capable of accurately classifying the changed behavior. In practice, the system can be exposed to multiple attacks of different categories and in any temporal order. Thus, retraining or changing individual machine learning models may not be feasible, particularly for run-time detection.

We use behavioral data of concurrent processes running on Intel's x86 architecture for run-time detection. These data are collected from different hardware events using hardware performance counters, in near real-time, and used as features for selected machine learning 1.5 Contributions and Organization of Manuscript | 11 models. These data represent the pattern of memory accesses generated by data-dependent cryptographic operations that are being carried out by the underlying hardware. Since each CSCA generates a different interference with caches, therefore, the data being captured through HPCs at run-time can lead to miss-classification for a single machine learning model. An Ensemble model, instead, incorporates multiple best-performing models and performs a majority-vote before classifying a given situation as Attack or No-Attack. Thus, it is capable of accurately detecting a larger set of attacks. Through extensive experiments and results, we demonstrate that the proposed detection framework is capable of detecting 9 different variants of the state-of-the-art CSCAs and Covert Channel Attacks (CCAs), namely: Flush+Reload, Flush+Flush, Prime+Probe, Spectre and Meltdown. These experiments illustrate that the proposed detection framework is capable of detecting almost all major known attack categories that are based on cache access and timing patterns.

As part of the second contribution in this thesis, we propose an OS-level run-time detection-based mitigation mechanism. In this work, we advocate for the use of need-based protection mechanisms, which are imperative to effectively mitigate CSCAs without sacrificing the performance benefits. Our arguments are in favor of enhancing the capability of Operating System (OS) by using a detection-based mitigation approach that would help the OS to apply mitigation only after successful detection of a CSCA. Thus, detection can serve as the first line of defense against such attacks. Such a solution would incur as little overhead as possible without significant performance or monetary cost. Rather than applying a static mitigation against CSCAs, which is active all the time and thus performance costly, a detection-based mitigation would be dynamic and it would neutralize the side-channel threat as and when it happens. The proposed mechanism is capable of detecting and subsequently mitigating a large set of known CSCAs belonging to Prime+Probe, Flush+Reload and Flush+Flush attack classes. The mechanism works in two stages: In the first stage, it detects if any malicious process is trying to manipulate the encryption process to extract information. If no malicious activity is reported, all processes run as normal at their pre-assigned privilege levels. However, if a malicious activity is detected, in the second phase, the mechanism protects the encryption process immediately and removes malicious process(es) from the system. Though the mechanism is scalable on other operating systems, we demonstrate its effectiveness on Linux, which is one of the fastest growing OS in general-purpose, embedded and super-computing markets. The proposed mitigation mechanism intends to enhance the capability of Linux general-purpose distributions for its widespread use in commodity hardware in order to extend their security features. To the best of our knowledge, this is the first research work that provides a run-time detection-based mitigation against CSCAs for Linux general-purpose distributions.

Organization

Rest of this document is organized as following. In Chapter 2, our main focus is to establish a detailed background on the state-of-the-art related to CSCAs, their detection mechanisms and proposed mitigation techniques. In Chapter 3, we present the state-of-the-art CSCAs, their implementation details on different cryptosystems and we provide an analysis on the use of Hardware Performance Counters (HPCs) and Machine Learning (ML) as a novel direction toward security. In Chapter 4, we present the first detection framework against CSCAs, called NIGHTs-WATCH, which couples with HPCs and Machine Learning to detect stealth attacks. In Chapter 4, we also present the WHISPER tool, which uses an Ensemble approach for detecting all the aforementioned CSCAs together by using a one-time training of ML models. In Chapter 5, we provide a demonstration of detection mechanism toward recent Covert Channel Attacks (CCAs) i.e. Spectre and Meltdown, which also use CSCAs for their execution. We provide experimental results, to show that our proposed detection mechanism covers a large scope of complex attacks effectively. In Chapter 6, we present Kingsguard, a detection-based mitigation mechanism that works as a service to Operating System (Linux). This chapter explains the thorough threat model, run-time detection and online mitigation module along with experimental results on the mitigation of simultaneously running CSCAs. In the second part of this Chapter, we also show the efficacy of noise-based countermeasures toward CSCAs. Chapter 7 provides conclusive remarks on our findings in this thesis and future research perspectives.

Summary

This chapter provides introduction and basic foundational understanding required to follow the presented work in this thesis. This chapter discusses the vulnerabilities in modern computing systems, followed by a discussion on the side-channel information leakage and attacks. It deliberates on the gaps in mitigation solutions provided against CSCAs and the ever-expanding attack surface. The chapter provides discussion on security and privacy issues at large and specifies the exact problem statement for this PhD thesis.

Chapter 2

Background and State-of-the-art

This chapter provides the background knowledge required for understanding the side channel information leakage in modern processors. At first, the chapter provides essential concepts of Intel x86 architecture and microarchitecture that lead towards the creation of information leakage channels (side and covert channels). Based on that knowledge, a classification and state-of-the-art on cache-based attacks is provided. The chapter then provides detailed discussion and state-of-the-art on existing CSCA detection techniques and their evaluation metrics for comparison of the effectiveness of existing solutions. Lastly, this chapter provides extensive state-of-the-art on mitigation techniques and their classification with respect to CSCAs. The chapter concludes with a discussion on lessons learnt from the existing work in literature.

Contents

Background and Concepts

Cache-based SCAs are strong cryptanalysis techniques that exploit critical vulnerabilities in modern processors. These hardware vulnerabilities of contemporary processors allow programs to steal data, which are currently processed on the computers. Programs are typically not permitted to read data of other programs, however, a vulnerable program can exploit and leak information by unintended side channels. This secret information can be cryptographic operations, a password stored in a password manager or browser, personal photos, emails, and instant messages or business critical documents. CSCAs are able to work on personal computers, mobile devices and even clouds too. CSCAs are able to exploit such private information of users and have proved to be a very strong and powerful threat of modern days. A couple of recent research surveys in literature [START_REF] Lyu | A Survey of Side-Channel Attacks on Caches and Countermeasures[END_REF], [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Anwar | Cross-VM cache-based side channel attacks and proposed prevention mechanisms: A survey[END_REF], identify a wide range of cache-based side-channel attacks and countermeasures on contemporary hardware. In [START_REF] Lyu | A Survey of Side-Channel Attacks on Caches and Countermeasures[END_REF], [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], a range of cache-based timing attacks and countermeasures on contemporary hardware is listed. Whereas, [START_REF] Anwar | Cross-VM cache-based side channel attacks and proposed prevention mechanisms: A survey[END_REF] also provides a hierarchy of hardware and software attacks. This study later analyzed the performance degradation in most of the countermeasures proposed for AES cryptosystem mainly. Studies in [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF] and [START_REF] Anwar | Cross-VM cache-based side channel attacks and proposed prevention mechanisms: A survey[END_REF] provide a wide list of diverse cryptographic algorithms used in different attacks and a mix of software and hardware countermeasures.

[34] provides a discussion on systematic classification of side-channel attacks for mobile devices. [START_REF] Oswald | A survey on passive side-channel attacks and their countermeasures for the Nessie public-key cryptosystems[END_REF] discusses only passive side-channels and their countermeasures for Nessie public key cryptography. [START_REF] Mantel | A systematic study of cache side channels across AES implementations[END_REF] provides a systematic study which only targets cache side-channels implemented on AES cryptosystem. This chapter discusses the details of state-of-the-art in three parts; 1) detailed state-of-the-art on CSCAs including information channels, classification of CSCAs, Vulnerabilities of Intel x86 Architecture, 2) state-of-the-art on detection techniques and comparison of them using a common set of parameters and 3) state-of-the-art on mitigation mechanisms.

Intel x86 Cache Architecture and Principles

To-date, Intel documentation states that CPU cores can process data 200 times faster than DRAM approximately [START_REF] Costan | SGX Explained[END_REF]. This gap has been filled thanks to stealth caches and their hierarchical design, which is smaller but faster in an order of magnitude from DRAM to Register level. Caches are fast memory type which efficiently hides the latency of huge and steady memory. Caches have an impact on security of a software system in two ways. Firstly, Intel architecture depends on system software to arrange address translation of caches, which becomes a threat for security. Secondly, Intel architecture allows resource sharing among all user software/processes running on a processor. This opens up the question of security in terms of cache timing attacks that is a complete class of software attacks [6], [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. This section provides a background knowledge on caching concepts and security issues that arise in Intel processors due to cache architecture.

Cache is a tiny storage unit of stealth memory in which processor saves the values of recently accessed memory cells. It fills the breach between the processing speed of processor and data recovery of memory [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF]. In contemporary architectures, processes which are operating on Intel processor, always share the cache. Due to the recently accessed localities, recently used values have a tendency to be recycled. Getting these values directly from the cache saves time and there is no need to access the value from memory. By this way the number of cache hit increases and eventually rate of miss decreases. That is why caches are crucial feature of contemporary processors. The timing clock of CPU's processor and the latency of memory shows a dramatic curve in the previous years. That is one reason that very small variation of hit rate can influence the performance. In the past researches, this point has been raised to be an effective way to perform side-channels once the contention of space is found in the cache [6], [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. In principal, caches try to resolve the problem of high locality in memory and hide the huge latency rate from main memory. By storing/caching recently accessed data, the problem of latency by main memory is satisfied up to 90-99% [START_REF] Costan | SGX Explained[END_REF]. Intel processors offer different levels of cache. The first level of cache is L1, which consists of separate data (L1-D) and instruction (L1-I) caches. Fetching and decoding of instruction is directly associated with L1-I cache, while operations that require read/write access from memory are directly associated with L1-D cache. Caches are all inclusive with private L1, L2 and shared L3 or LLC (Last Level Cache) among all cores as shown in Figure 2.1. Two processes running on the same core or across-core share the inclusive LLC by design, which is the core problem of sharing in contemporary architectures. Two processes that are not supposed to share their data are sharing the data due to inclusive caches. Access of priviledge instructions in Intel x86 like clflush and prefetch instructions, allow the attacker process to know the state of victim process due to inclusivity property. Inclusive caches exist in Intel x86 for lot of optimization and performance reasons, but it causes a criticality of sharing, which becomes a potential problem of security. Cache properties, like inclusivity and flushing, have been exploited in many cache-based timing attacks such as [6], [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. Figure 2.1 provides a general illustration of Intel's cache architecture. For performance reasons, Intel architecture includes an arrangement that provides some control to performance-sensitive applications over other applications. For instance, PREFETCH instruction prefetches a specific memory address to be used in future and CLFLUSH instruction evicts any cache line that has specific address from entire hierarchy of cache (L1, L2, and LLC). These instructions are available to software applications running at all privilege levels in order to provide high performance and optimization characteristics vis-a-vis caches. Cache architecture constitutes larger cache level (i.e., LLC) in lower hierarchy and smaller cache levels (L1, L2) in the upper hierarchy for efficiency. Moreover, the farther the cache from processing element, the slower it becomes. Therefore, the size of each cache level is chosen with care to mediate the next level that is faster. According to latest Intel processors documentation [START_REF]ARK-your source for Intel product specifications[END_REF], [START_REF] Levinthal | Performance analysis guide for intel R core i7 processor and intel R xeon 5500 processors[END_REF], [START_REF]Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide[END_REF] and some researches [START_REF] Costan | SGX Explained[END_REF], [START_REF] Disselkoen | Prime+Abort: A Timer-Free High-Precision L3 Cache Attack using Intel TSX[END_REF], the approximate indicative parameters of Intel x86 architectures (Intel Xeon Processors, Core i7) are described in Table 2.1. It approximates the associativity, sharing, size of cache line, size of each level and access time of caches but the memory sizes and access time may vary in terms of magnitude across different levels of hierarchy.

Background and Concepts | 17

architectures are multi-way set-associative with direct set indexing. Therefore, a W-way set associative cache contains its own memory, which is divided in sets. Each set consists of W lines in, which memory location can be cached. Whereas, LLC is divided into per core slices. Each slice is allocated to a separate core and it can be utilized as unified as well as separate cache [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [START_REF] Qian | Contemporary Processors Are Leaky -and There's Nothing You Can Do About It[END_REF] as described in Figure 2.1. Intel's documentation states that the hashing scheme maps physical addresses to LLC. It was designed to distribute memory circulation. Hashing scheme is not publicly available and reverse-engineered in past research work [START_REF] Sinan | Co-location Detection on the Cloud[END_REF], [START_REF] Maurice | Reverse Engineering Last-Level Cache Complex Addressing Using Performance Counters[END_REF], [START_REF] Yarom | Mapping the Last-Level Cache[END_REF].

Information Leakage Channels

In the discussion above, the features of cache behavior and to some extent problems of such behaviors have been explained. These behaviors create a state, which initiates a level of distrust between different processes and causes serious issues of confidentiality and integrity. These confidentiality problems are based on preceding computation of operations or sometimes by caching some useless data etc. In fact the process is always transparent and it does not have any impact on the outcomes or results of operations (either the victim is running or the attacker). It does have two problems, 1) the confidentiality of process is lost and 2) overall performance has been compromised because of an illegal process running in parallel and delaying the execution of victim program. These issues reveal the state of operation timing and are evident by disparity of timing in program executions.

Covert Channel

Covert channels are exploited by Trojans to leak the information intentionally. Covert channels are interesting for those systems who have very restrictive flow of information (highly secure policies), while, such systems do not rely on its internal constituents and modules. A Trojan from its execution tries to force hardware into a specific state and let the spy observe this state. The spy tests its own progress against the real time. Covert channels are not a direct method to spy and observe information. They are potential enough to connect with unintended processes, which are not allowed to (or do not) communicate with each other and therefore, form a channel to seep all secure information. Covert channels are frequently discussed in multilevel security systems (MLS) [START_REF] Landwehr | Formal Models for Computer Security[END_REF]. The execution and implementation of covert channels strictly depend on the micro-architecture on which it is processing to abuse the information. Implementations of covert channels have been estimated in recent researches too [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Kocher | Spectre Attacks: Exploiting Speculative Execution[END_REF], [START_REF] Lipp | Meltdown[END_REF], [START_REF] Evtyushkin | Covert Channels Through Random Number Generator: Mechanisms, Capacity Estimation and Mitigations[END_REF], [START_REF] Evtyushkin | Jump over ASLR: Attacking branch predictors to bypass ASLR[END_REF], [START_REF] Maurice | Hello from the Other Side: SSH over Robust Cache Covert Channels in the Cloud[END_REF].

Side-Channels

Side-channel is an event where it permits the attacker to run a spy program to retrieve sensitive information from non participating victim. Side-channel is considered to be an unintended leakage of sensitive data by a reliable program i.e. encryption key. Due to this reason, side-channels tend to have grave threat to secrecy of encryption [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF]. Universally, sharing allows enhanced utilization of underlying hardware mechanism and it provides a lot of better performance and efficiency to systems but it is proved to be a major threat to security and confidentiality of the systems too. Attacks that use side-channels extract unprivileged information by monitoring time and cache behavior in a shared computing environment. The SCAs are powerful cryptanalysis techniques. Rather than attacking the underlying structure of cryptographic functions, SCAs focus on the implementations of cryptographic cipher [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF]. All side-channels concerned with the behavior of caches and timing are cache-based timing side-channels, which lead to a rather bigger class of software/logical attacks. Cache-based Side-Channel Attacks (CSCAs) exploit the vulnerability of cache in terms of minute variation of timing to detect contention of space in cache that can be with different processes or within a process. Now, when all the resources reside on different cores in modern Intel processors, we have a threat that different resources leak some information at the time of execution. Attackers exploit these behaviors of cache in terms of precise timing to perform cache-based timing side-channels. We have detailed the further classification of side-channels as cache-based timing channels separately with their types in Section 2.1.3. However, the overall focus of the thesis is also on cache-based timing side-channels.

Cache-based Timing Side-Channels

Observing and revealing minute timing variations is an important aspect of timing channels, which can exploit a lot of secret operations like in context switching, preemptive scheduling, hyper-threading, simultaneous multi-threading and threats in multi-cores [START_REF] Bernstein | Cache-timing attacks on AES[END_REF], [START_REF] Gullasch | Cache Games -Bringing Access-Based Cache Attacks on AES to Practice[END_REF], [START_REF] Garcıéa | Make Sure DSA Signing Exponentiations Really Are Constant-Time[END_REF], [START_REF] Gruss | Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR[END_REF], [START_REF] Schaefer | Program Confinement in KVM/370[END_REF]. When the state of cache is shared between two different programs for execution, there might be a potential risk of timing channel as the victim and attacker might be sharing the same resources and attacker can observe the victim's execution with minute timing variations because the timing of one program is dependent on the execution of the other program [START_REF] Hu | Reducing Timing Channels with Fuzzy Time[END_REF], [START_REF] Tsunoo | Cryptanalysis of Block Ciphers Implemented on Computers with Cache[END_REF]. Cache-based side-channels are also possible even if we are trying to do some strict partitions (attacker and victim running on separate cores). Usually, normal flushing of cache can also reveal the timing information by simply observing the timing of victim's program to fetch the addresses of interest. Exploiting timing channels requires some methods to really count the time to perform the operations. These properties can be achieved by using some quick and efficient counters like pair of clocks [START_REF] Wray | An Analysis of Covert Timing Channels[END_REF], which shows if there exists a timing difference between two clocks, there is some timing channel lying in between.

attacks. Access driven attacks are considered fine-grained because they provide with specific information related to addresses of interest of victim's access.

Detection Techniques

This section discusses in detail the surveyed literature about detection of cache-based sidechannel attacks.

Evaluation Metrics for Comparison of CSCA Detection Techniques

Based on our study, in this thesis, we provide a number of important evaluation metrics that can be used to compare and characterize any proposed CSCA detection technique. It should be noted that following is not an exhaustive list of such metrics, but a list of most important ones that we could establish based on the studies of CSCA detection techniques.

Detection Accuracy

Detection accuracy should be considered to be the primary metric to judge any intrusion detection mechanism. Since, detection of side-channel attacks is a binary classification problem, detection inaccuracy can be further divided into false positives (cases when a noattack condition is detected as an attack) and false negatives (cases when an attack condition is detected as no-attack) to analyze detection results in details. Two of the commonly used metrics that have been used to represent detection accuracy in the reviewed literature are Percentage Accuracy and F-score [START_REF] Vickery | Reviews: van Rijsbergen, CJ Information retrieval[END_REF]. F-score is a statistical analysis of binary classification to measure the test accuracy. F-score can be interpreted as a weighted average of precision and recall where F-score reaches its best value at 1 and worst at 0. The reason for using F-score often over Percentage Accuracy is following: F-score is generally not influenced by data sets in which one class might have much more number of samples (also known as skewed class) than the other classes.

Detection Speed

The speed with which an attack is detected is another important indicator for evaluating any detection proposal. Detection speed is usually a trade-off between overhead of a detection system and timely intrusion detection. Detection speed is a function of the cryptosystem (which the attack is targeting) and the attack itself and should be considered accordingly. For example, Flush+Reload on RSA is a single-encryption attack and for detection to be useful the attack should be detected before half of the total bits are encrypted. On the other hand, Flush+Flush on AES requires hundreds of encryptions to be successful, so its detection can be useful even if it is done after number of encryptions. Few of the mostly used metrics to indicate detection speed in literature include: the absolute time, the number of encryptions being performed by the cryptosystem and the number of bits being encrypted by the cryptosystem by which a detection mechanism is capable of detecting an attack.

Detection Overhead

A detection mechanism always incur some performance overhead depending on its complexity and the level of implementation. Detection overhead can be defined as the slowdown of the process to be protected due to the implemented detection mechanism. The detection overhead will be determined by the detection granularity, which specifies how often the detection mechanism would be activated to make a decision based on the information provided. Secondly, the perceivable detection overhead is related to the implementation of the detection mechanism as well.

Used Attacks

There are various techniques to perform cache side-channel attacks (CSCAs) and covert channel attacks (CCAs) based on caches, such as Flush+Reload (F+R), Flush+Flush (F+F), Prime+Probe (P+P), Prime+Abort (P+A), Evict+Time (E+T), Evict+Reload (E+R), Spectre and Meltdown (these techniques are detailed in next Chapter 3 with their implementations. Whereas, these terminologies with their acronyms will be called alternatively many times in the thesis). The difficulty of detection of a CSCA varies depending on the used technique and the cryptosystem under consideration. For example, Flush+Flush attack is considered to be more stealthier compared to Flush+Reload attack. Therefore, in order to perform a comparison of CSCA detection techniques it is essential to identify particular attack techniques along with the cryptosystems that were used to evaluate the working of a detection mechanism for CSCA.

Implementation Level

CSCA detection mechanism can be implemented at different levels in a computer system. The possible implementation levels include: victim application (cryptosystem) itself, as a separate application/process, within the operating system, inside each Virtual Machine (VM) or directly inside the hardware. It is important to compare CSCA detection techniques based on how they are physically implemented as each level of implementation will have its own strengths and weaknesses. For example, implementing a CSCA detection mechanism as a separate application can be slow, but such a solution can work with legacy systems/hardware.

On the other hand, a detection mechanism implemented inside the hardware will be fast but will not be portable to legacy systems/hardware.

Design Category

Most of the side-channel detection techniques can be divided into two basic categories based on their design: Signature-based detection and Anomaly-based detection. Signature-based detection approaches rely on signature of "known side-channel attacks", which usually consists of selected hardware events that will be affected by those attacks. At run-time, program execution is compared with the already generated signatures and in case of a match an attack is detected. Such detection approaches usually show very good accuracy in detection of known attacks [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF]. However, they might suffer from low accuracy for detection of unknown or modified attacks [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF]. Anomaly-based detection approaches generate model of the behavior of normal/benign applications. Any significant "deviation" from such model will be considered an attack. Anomaly-based detection techniques are capable of identifying unknown or modified attacks [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF]. However, they can have high false positive rates [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF] as it is hard to build models including every possible benign application and many benign applications can resemble cache-based side-channel attacks due to their high memory usage. Some research works [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF], [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF] have also combined both anomaly and signature-based detection designs to achieve better results.

State-of-the-art on CSCA Detection Techniques

Table 2.2 (toward the end of this section) presents a comparison of all surveyed CSCA detection techniques on a common set of parameters. This table shows the extent to which proposed CSCA detection mechanisms have been evaluated by the studied papers. As discussed in the previous section, CSCA detection techniques either employ anomaly-based detection, signature-based detection or a combination of both. Majority of the CSCA detection techniques are signature-based techniques: [START_REF] Mushtaq | NIGHTs-WATCH: a cache-based side-channel intrusion detector using hardware performance counters[END_REF], [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF], [START_REF] Demme | On the feasibility of online malware detection with performance counters[END_REF], [START_REF] Allaf | ConfMVM: A Hardware-Assisted Model to Confine Malicious VMs[END_REF], [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF], [START_REF] Peng | Detection of Cache-based Side Channel Attack Based on Performance Counters[END_REF], [START_REF] Briongos | Modeling side-channel cache attacks on AES[END_REF], [START_REF] Chouhan | Adaptive detection technique for Cachebased Side Channel Attack using Bloom Filter for secure cloud[END_REF], [START_REF] Raj | Keep the PokerFace on! Thwarting cache side channel attacks by memory bus monitoring and cache obfuscation[END_REF] or a combination of both signature and anomaly-based techniques [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF], [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF], [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF]. Figure 2.4 shows a classification of CSCA detection techniques based on their fundamental design type.

Signature-based Detection Techniques

One of the earliest CSCA detection works was done by Demme et al [START_REF] Demme | On the feasibility of online malware detection with performance counters[END_REF] who tried to detect malwares and CSCAs based on signatures. Demme et al [START_REF] Demme | On the feasibility of online malware detection with performance counters[END_REF] claimed to use hardware performance counters (HPCs) for the first time to solve the problem of malware and side-long (notable irregularities when trace exceeds a certain size), which renders the solution not suitable for run-time detection.

Allaf et al [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF] also presented a signature-based CSCA detection mechanism that uses Machine Learning (ML) to generate signatures, which are representative of attacks. Allaf et al [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF] used three ML algorithms namely Neural Networks [START_REF] Lippmann | An introduction to computing with neural nets[END_REF], Decision Trees [START_REF] Quinlan | Induction of decision trees[END_REF] and K-Nearest Neighbor (KNN) [START_REF] Cover | Nearest neighbor pattern classification[END_REF] to detect cache-based side-channel attack specifically on AES cryptosystem. The particular side-channel attacks used in their work are Flush+Reload and Prime+Probe. A data set containing values of seven different hardware performance counters, which include core cycles, reference cycles, core instructions and other four features having the best effect on classification of attack and no-attack scenarios for the used attacks is collected during execution of processes (attacks and benign processes). This data set is used for both training and validation of machine learning algorithms. The data set covers two scenarios: with and without any noise in the background when attacks and victim programs are running. Integer and Floating-point categories of SPEC-CPU2006 benchmarks (SPEC-int and SPEC-fp) [85] are executed in the background to simulate noise/load conditions. The data set is split randomly into 20-folds for purposes of cross-validation [START_REF] James | An introduction to statistical learning[END_REF].

Allaf et al [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF] also processed training data before using it to train ML classifiers. The dimensions of training data are first reduced using a technique of Principal Component Analysis (PCA) [START_REF] Jolliffe | Principal components in regression analysis[END_REF], which is a famous data-dimension reduction technique. The data is then passed through a well-known optimization algorithm called L-DFGS [START_REF] Dean | Large scale distributed deep networks[END_REF], which is known for its affinity towards smaller data sets. The particular Decision Tree used in their work is C4.5 [START_REF] Ross | C4. 5: programs for machine learning[END_REF], which is a famous tree-based statistical classifier. Evaluation of the proposed technique on an Intel Xeon (X5650) processor shows that the best classification success rate is shown by Decision Tree, which is 97% for Flush+Reload and 98% for Prime+Probe attacks in case of no SPEC benchmarks in the background. The accuracy is reduced in case of background SPEC benchmarks (specially in case of SPECfp benchmarks, which according to authors' claim make heavier use of CPU components specially caches compared to the integer benchmarks). However, Decision Trees still have better accuracy compared to other methods under noisy conditions. Results further show that the detection framework (which learns at run-time) is able to learn the behaviour of malicious process in less than 1 second in worst case, which authors claim is very fast in comparison to 50 seconds required for retrieval of entire key bits by Flush+Reload attack implementation done by [START_REF] Irazoqui | Wait a minute! A fast, Cross-VM attack on AES[END_REF] on the used machine. Results also show that decision trees are less efficient (have low detection speed) compared to the other methods but shows better accuracy. Later, Allaf et al [START_REF] Allaf | ConfMVM: A Hardware-Assisted Model to Confine Malicious VMs[END_REF] used Machine Learning to generate signatures of malicious loops of attack processes to detect them at run-time. Allaf et al [START_REF] Allaf | ConfMVM: A Hardware-Assisted Model to Confine Malicious VMs[END_REF] specifically used K-Nearest Neighbor (KNN) classifier to detect malicious loop activity within Flush+Reload attack to detect attacks without the need of observing any synchronization between attacker and victim processes as some other techniques [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF], [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF] do. The used machine learning model is trained using three features of L1, L2 and last-level cache (LLC) misses. Selected benchmarks (bzip2, gcc, bwaves, dealII ) from SPEC-CPU2006 [85] benchmark suite are executed in the background to create realistic system conditions. Programs are profiled by reading performance counters at time intervals of 0.02 ms, which is the time that a single run of malicious loop of Flush+Reload attack takes. N number of profiled samples are grouped together and are represented by the average of those samples. These representative samples are fed to K-NN classifier to make classification decision. The experimental evaluation of the presented model on an Intel Xeon system shows that it can achieve an accuracy of 99% on native system and 96% on a cloud system, without any extra overhead on cloud system. However, authors declare that this mechanism would not work for other attacks like Prime+Probe considering the differences in working of malicious loop in the attack. Moreover, authors claim that the trained classifier does not need to be re-trained to detect hostile processes in a new environment. Some of the signature-based detection techniques don't rely on Machine Learning to learn attack signatures. Rather they use thresholds of particular hardware events to determine if an attack is in place. Examples of such works include: [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF], [START_REF] Peng | Detection of Cache-based Side Channel Attack Based on Performance Counters[END_REF], [START_REF] Briongos | Modeling side-channel cache attacks on AES[END_REF], [START_REF] Raj | Keep the PokerFace on! Thwarting cache side channel attacks by memory bus monitoring and cache obfuscation[END_REF]. One of these works, done by Mathias Payer [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF], utilizes the values of cache miss rates and page faults of processes to detect an attack. Mathias Payer [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF] proposed an attack detection framework HexPADS, which can detect cache-based side-channel attacks along-with rowhammer [START_REF] Seaborn | Exploiting the DRAM rowhammer bug to gain kernel privileges[END_REF] and CAIN [START_REF] Barresi | CAIN: Silently Breaking ASLR in the Cloud[END_REF] attacks. HexPADS reads status of different performance counters like total executed instructions, total LLC accesses and total LLC misses. It also uses kernel information of processes like total page faults. Same type of detection technique is used for both rowhammer and cache side-channel attacks and does not distinguish between the two. The proposed detection mechanism basically continuously monitors the cache accesses and misses of all processes. If cache miss rate of a process is found to be higher than 70% i.e. greater than 70% of cache accesses results into misses, and the same process has a low number of page-faults, the process is detected to be an attack. The evaluation of the proposed detection technique is done using following attacks: cache template attacks [START_REF] Gruss | Cache Template Attacks: Automating Attacks on Inclusive Last-Level Caches[END_REF] based on Flush+Reload and an enhanced version of C5 [START_REF] Maurice | C5: cross-cores cache covert channel[END_REF] based on Prime+Probe attack. Performance overhead of the detection framework is measured by executing SPEC-CPU2006 [85] and PARSEC [START_REF] Bienia | The PARSEC benchmark suite: Characterization and architectural implications[END_REF] benchmark suites when detection framework is active, indicating that the mean of overhead (loss in performance of executed benchmarks) is less than 2%. Experiments show that HexPADS can detect both attacks successfully. However, it is not evaluated using any realistic load/noise conditions. Another threshold based technique, which is similar to the one proposed by Mathias Payer [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF] has been presented by Peng et al [START_REF] Peng | Detection of Cache-based Side Channel Attack Based on Performance Counters[END_REF]. Peng et al [START_REF] Peng | Detection of Cache-based Side Channel Attack Based on Performance Counters[END_REF] used cache miss rates and data-TLB miss rates to recognize cache side-channel attacks. They showed that cache side-channel attacks like Flush+Reload have high cache miss rates but low dTLB (Data Translation Lookaside Buffer) miss rates. The detection mechanism scans all running processes on a system and observes the values of performance events specifically cache and dTLB miss rates for these processes. A detection flag is raised if the cache miss rate is found to be above and dTLB miss rate below a particular threshold. Variants [6], [START_REF] Maurice | C5: cross-cores cache covert channel[END_REF], [START_REF] Gruss | Cache Template Attacks: Automating Attacks on Inclusive Last-level Caches[END_REF] of Flush+Reload type of CSCA are used for evaluation of the proposed technique. Experimental results show that this technique is able to discriminate cache-based side-channel attacks from benign processes and other timing attacks accurately. Experimental analysis does not present other run-time detection evaluation metrics like speed and overhead. The work of Briongos et al [START_REF] Briongos | Modeling side-channel cache attacks on AES[END_REF] also depends on the comparison (of encryption times) with set thresholds to determine the occurrence of CSCA. Briongos et al [START_REF] Briongos | Modeling side-channel cache attacks on AES[END_REF] built a timing model to discriminate if a process is being attacked or not. Cache-based side-channel attacks on AES encryption system are considered in this work. As shown in [START_REF] Briongos | Modeling side-channel cache attacks on AES[END_REF], the distribution of AES encryption times under attack and no-attack cases shows an observable distinction when no other processes are executing on the CPU. Authors conclude that in such a case encryption times above a threshold would be highly indicative of an attack. To create a realistic scenario, authors experimented with running of other workloads in the background along-with an attack. The first case involves running Lookbusy program [START_REF] Carraway | lookbusy -a synthetic load generator[END_REF] in the background, which is a CPU-centric workload designed to stress computational capability of a processor. The distribution of encryption times in this case shows that the peak heights indicating non-attack cases rise. In the second case, a memory benchmark RandMem2 [START_REF] Longbottom | Roy Longbottom's PC Benchmark Collection[END_REF] is used to stress memory system by performing random accesses to memory. The results in this case showed that this process only caused a single cache miss for one encryption at maximum and affects lower than 1% of encryptions. This infers that the CPU consumption will have more effect on time distribution (which is to be used in the detection process). Based on these observations, the proposed cache side-channel attack detection algorithm uses the time distribution of encryption algorithm. The method uses last 200 samples of encryption times at any time instance. From these samples, a histogram is created (using time intervals of 20 cycles). Peaks of this histogram are found using a windowing operation. The height of these peaks are used to decide if an attack is active or not. Experimental results show that the proposed detection algorithm achieves a detection accuracy greater than 96% (false positive rate of 5%). It is shown that the false positive rate can be further reduced to 0% if initializing stage of victim process is ignored. [START_REF] Raj | Keep the PokerFace on! Thwarting cache side channel attacks by memory bus monitoring and cache obfuscation[END_REF] presented PokerFace to identify and mitigate cache attacks, which compares the memory bus bandwidth with a threshold level to detect a CSCA. The proposed framework consists of two components: Poker and Face (both are implemented as single threads in guest VM). Poker is responsible for detection of attacks, which triggers Face upon an attack detection. Face then performs cache obfuscation to make the attack unsuccessful. The attacks are detected at the level of VM. Poker works by observing memory bus bandwidth to obtain information regarding cache accesses. The working of Poker is based on the fact that during a cache attack the victim VM suffers from significant degradation in memory bus bandwidth. The evaluation of the proposed framework is done using Prime+Probe and Flush+Reload types of cache side-channel attacks. Performance overhead of PokerFace using STREAM [START_REF] John D Mccalpin | STREAM benchmark[END_REF], Sysbench [START_REF] Kopytov | SysBench: a system performance benchmark[END_REF] and PARSEC [START_REF] Bienia | The PARSEC benchmark suite: Characterization and architectural implications[END_REF] benchmark suites is found to be less than 8%.

Raj and Dharanipragada

Intel introduced an extension to their instruction set architecture (ISA) named Intel Software Guard Extension (SGX) to protect the execution of unprivileged programs inside secure enclaves. Still the privileged programs with malicious intent can perform side-channel attacks on programs inside a secure enclave. The work of Chen et al [START_REF] Chen | Detecting privileged side-channel attacks in shielded execution with Déjá Vu[END_REF] employs a threshold based design to detect a special case of cache side-channel attacks. Chen et al [START_REF] Chen | Detecting privileged side-channel attacks in shielded execution with Déjá Vu[END_REF] proposed Deja-Vu to detect side-channel attacks on programs guarded by SGX. Privileged attacker regulary preempts the shielded execution of victim process, which is executing inside an enclave. This leads to unanticipated enclave exits, which are known as Asynchronous Enclave Exits (AEXs). These preemptions can be observed by the operating system (OS) and a higher frequency of such preemptions indicates the presence of an attack. Deja-Vu detects the existence of AEXs to identify the presence of an attack. Deja-Vu needs a reference clock, that cannot be compromised, to measure the execution time of SGX application to be protected. The execution time of the application at run-time when detection mechanism is active is compared with the normal run-time (run-time of the process when no-attack is in place). A time difference above a threshold indicates the possibility of enclave exits and a possible attack. To make sure that the used reference clock is trust-worthy, it is protected by Intel's hardware transactional memory (TSX) support. The run-time overhead of Deja-Vu is found to be less than 5% using nbench [102] benchmark suite. However, the required instrumentation can increase the size of enclave binaries by approximately 64%.

An example of the signature-based CSCA detection approaches that uses special data structures is the work of Chouhan and Hasbullah [START_REF] Chouhan | Adaptive detection technique for Cachebased Side Channel Attack using Bloom Filter for secure cloud[END_REF]. Chouhan and Hasbullah [START_REF] Chouhan | Adaptive detection technique for Cachebased Side Channel Attack using Bloom Filter for secure cloud[END_REF] used bloom filters [START_REF] Burton | Space/time trade-offs in hash coding with allowable errors[END_REF] to propose a detection for cache-based side-channel attacks in cloud systems. The use of bloom filters is motivated by the need to reduce the performance overhead of the detection mechanism. They fed cache miss time mean values read from performance counters to bloom filters, which detect if the values belong to an attack condition or not. They showed that the proposed method does not lead to any false negatives. Bloom filters are used to decide if a certain element is a member of a particular set. Once, certain index values are generated after an hash function is computed on elements of set under consideration, bits in Bloom filter corresponding to those index values are set to true. For any new element (for which decision about its membership to the set under consideration is to be made), it is passed to the hash functions and it's seen if bit indexes corresponding to hash functions' outputs are set to 1 (membership would be true if outputs are set to 1 and false otherwise). Bloom filters can also lead to cases of false positives. Bloom filters are supposed to be very efficient to find memberships of elements in a set as they don't rely on actual comparisons, rather use hash functions. The proposed detection technique first records the cache miss patterns of processes with the help of performance profiling tools like perf. Cache miss times (CMT) for these patterns are also calculated with the help of a timer. Mean of the differences of each successive CMT is calculated and formed signatures are stored in Bloom filter. At run-time the detection mechanism calculates such signatures again and pass them to Bloom Filter to check membership of the signatures under consideration. If set membership is found to be true, it indicates a high probability of an attack. The methodology is evaluated with the help of a cache simulator. Experimental results indicate that the proposed solution takes around 6 seconds to execute on the used machine in comparison to 17-25 seconds required to execute the Flush+Reload attack. The authors claim that the proposed mechanism should also work for the detection of unknown cache-based side-channel attacks.

Signatures based on KVM (Kernel Virtual Machine) events have also been used in the detection of CSCA. Paundu et al [START_REF] Wahyudi | Leveraging KVM Events to Detect Cache-Based Side Channel Attacks in a Virtualization Environment[END_REF] proposed a CSCA detection technique in a virtualized environment using the information of KVM events. KVM events are collected using ftrace utility [START_REF]Ftrace kernel hooks, more than just tracing[END_REF] in Linux OS, and they provide information about the host kernel operations when a guest system is running on it (i.e. they monitor the guest activity). A machine learning model SVM (with RBF kernel) is trained using the KVM events data for specific time sequences. A set of normal applications (including idle VM, web and mail server applications) forms the no-attack data set needed to train the SVM. Experimental evaluation shows a performance overhead of 0.7% for a host system based on Intel Xeon processor (set up with 8 VMs). All three classes of CSCA techniques (Prime+Probe, Flush+Reload and Flush+Flush) are used to evaluate the proposed CSCA detection technique. ROC (Receiver Operating Characteristic) curve of the trained classifier shows an AUC (Area Under the Curve) value of 0.99 while classifying attack and no-attack scenarios.

Yu et al [START_REF] Yu | An approach with two-stage mode to detect cache-based side channel attacks[END_REF] also presented a signature-based two-stage CSCA detection technique named as CSDA (Cache-based Side-Channel Attack Detection Approach). CSDA focuses on detection of CSCAs in cloud systems. The two stages of CSDA include detection at the level of host and guest respectively. CSDA makes use of shape and regulatory tests, which are significant methods used to analyze detection in covert channels. Shape tests utilize first order statistics like mean, variance and entropy to describe different features. Regulatory tests utilize second order or higher statistics like correlations and mutual information found in data. In CSDA, at the level of host detection, shape tests are executed to reveal the features of attack using CMS (Cache Miss Sequence). Whereas, guest detection is the second phase, which is dependent on the results of host detection. During guest level detection, regulatory tests are conducted to obtain the features of attack, which are extracted from virtual CPU and memory utilization. Two-stage detection technique of Yu et al [START_REF] Yu | An approach with two-stage mode to detect cache-based side channel attacks[END_REF] extracts the features of attack from host and guest and then uses pattern recognition techniques to distinguish attacker VMs from non-attacker VMs. Experiments reveal that CSDA is able to detect malicious VMs efficiently in cloud setup. Whereas, no empirical results on performance overhead, detection accuracy or detection speed has been found in this paper.

Anomaly-based Detection Techniques

There are a few recently proposed research works [START_REF] Bazm | Cache-Based Side-Channel Attacks Detection through Intel Cache Monitoring Technology and Hardware Performance Counters[END_REF], [START_REF] Briongos | CacheShield: Detecting Cache Attacks through Self-Observation[END_REF], [START_REF] Kulah | SpyDetector: An approach for detecting side-channel attacks at runtime[END_REF] that rely solely on Anomaly Detection for recognition of CSCAs. Bazm et al [START_REF] Bazm | Cache-Based Side-Channel Attacks Detection through Intel Cache Monitoring Technology and Hardware Performance Counters[END_REF] relied on Intel Cache Monitoring Technology (CMT) [START_REF]Benefits of Intel Cache Monitoring Technology in the Intel Xeon Processor E5 c3 Family[END_REF] and hardware performance counters and used Gaussian Anomaly detection [110] for detection of cache-based side-channel attacks at the level of VMs in IaaS Cloud platforms. The proposed mechanism shows very good accuracy in isolated conditions but suffers from high false positives in noisy conditions. Intel Cache Monitoring Technology provides "fine-grained" information of behavior of caches in virtualized environment. CMT also monitors the use of shared resources such as last level caches (LLC) in modern processors and provides statistics like occupancy of LLC by VMs on a particular physical machine. The information provided by CMT can be used to improve the detection of side-channel attacks in VMs. The proposed approach to detect cache side-channel attacks uses some hardware performance counters (LLC misses and references, iTLB cache misses and accesses) along with the information provided by CMT. The model used for detection of anomalies i.e. Gaussian Anomaly Detection is trained on the data of counters by estimating Gaussian distribution of all features (after calculating their mean and variance). Each virtual machine on the physical host acts as a single data point in this work and values of performance counters and LLC-occupancy act as features of that data point.

The proposed framework of Bazm et al [START_REF] Bazm | Cache-Based Side-Channel Attacks Detection through Intel Cache Monitoring Technology and Hardware Performance Counters[END_REF] consists of multiple threads: first thread probes the entire system to gather statistics (performance counters and LLC occupancy) of all VMs, second thread provides a list of active VMs. Third thread runs Gaussian anomaly detection using the gathered statistics to make any detection decisions. The proposed framework is evaluated using an experimental system based on Intel Xeon running 6 VMs. The particular cache side-channel attack used in their work is an implementation of Prime+Probe provided by [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF] [START_REF] Peng | Detection of Cache-based Side Channel Attack Based on Performance Counters[END_REF] and Payer [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF] found as well. Further, it is shown that the proposed detection module incurs around 2% performance overhead to the hypervisor. However, this overhead might increase with an increase in the number of VMs.

Briongos et al [START_REF] Briongos | CacheShield: Detecting Cache Attacks through Self-Observation[END_REF] proposed CacheShield to detect cache side-channel attacks on legacy software (victim applications) by monitoring hardware performance events during their execution. The proposed method is implemented at user level and does not require any help from the OS/hypervisor and would be applicable in cloud environments. As indicated by the authors, this effort is motivated by two main problems of the other detection mechanisms: high detection performance overheads for VMs and requirement of monitoring of both attacker and victim at the same time. The proposed attack detection technique, CacheShield, uses an unsupervised anomaly detection algorithm Cumulative Sum Method (CUSUM) proposed by Page et al [START_REF] Page | Continuous inspection schemes[END_REF]. CUSUM belongs to the category of change point detection (CPD) [START_REF] Basseville | Detection of abrupt changes: theory and application[END_REF] algorithms. CPD algorithms determine when their is a major change in the characteristic parameters of the system under consideration. Using the infoGain function of WEKA tool [START_REF] Hall | The WEKA data mining software: an update[END_REF] and relief algorithm [START_REF] Kira | The feature selection problem: Traditional methods and a new algorithm[END_REF] on a number of hardware performance events collected for RSA crypto-algorithm under attack, Briongos et al [START_REF] Briongos | CacheShield: Detecting Cache Attacks through Self-Observation[END_REF] found that the most relevant/meaningful event is L3 cache misses. CacheShield monitors performance counters in parallel to any victim application making it possible to detect attacks that will be successful during working of a single call of the "sensitive function". Using two clustering algorithms Expectation Maximization (EM) [START_REF] Jin | Expectation maximization clustering[END_REF] and Self Organizing maps [START_REF] Kohonen | Self-Organizing Map[END_REF] from WEKA tool, authors show that these algorithms are successfully able to classify attack samples using L3 cache misses counter. For evaluation of CacheShield, few applications with high memory usage like Yahoo Cloud Serving Benchmark, Video Streaming, Randmem Benchmark are selected to create noisy conditions. Three crypto-algorithms of AES, ESA and ElGamal are used with three famous cache side-channel attacks: Flush+Reload, Flush+Flush and Prime+Probe. Experimental results indicate that for all attacks CacheShield shows a detection rate of 100%. Moreover, the attacks against ElGamal are detected before 37% execution of the encryption in worst-case. For RSA, detection is achieved before 50% of the execution of decryption algorithm in worst case.

Another anomaly-based CSCA detection solution has been proposed by Kulah et al [START_REF] Kulah | SpyDetector: An approach for detecting side-channel attacks at runtime[END_REF]. Kulah et al [START_REF] Kulah | SpyDetector: An approach for detecting side-channel attacks at runtime[END_REF] presented a semi-supervised method, SpyDetector, to detect cache-based SCAs at run-time under variable load conditions. Detection mechanism is focused on the spy process, which disputes on the shared resources used by the victim process. SpyDetector determines the shared resources, which are used by the victim process. It uses different useful features of HPC's to quantify between normal and abnormal contentions, correlates victim process associated with these resources or all the processes, which are using the shared resource of interest and uses anomaly-based machine learning approaches to detect abnormal level of contention. SpyDetector has been validated on CSCAs such as Prime+Probe on AES, Flush+Reload on AES & ECDSA and Flush+Flush on AES. Experiments revealed that SpyDetector can perform at run-time under variable load conditions in both physical and cross-VM configurations. Experimental evaluation shows that SpyDetector detects Prime+Probe attack with an average F-score of 0.83, Flush+ Reload with an average F-score of 0.99 for physical system and 0.97 for cross-VM setup and Flush+Flush with an average F-score of 0.82 for physical and 0.96 for cross-VM setup. The overall performance overhead for the system is between 0.49% to 3.58%.

Anomaly + Signature-based Detection Techniques

As discussed earlier, some of the cache side-channel detection techniques use a combination of both signature and anomaly-based techniques. Examples of such techniques include: [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF], [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF], [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF]. In the following, we discuss these techniques in detail.

Chiappetta et al [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF] proposed machine learning-based detection of cache-based sidechannel attacks. This work used three different approaches for detection of cache-based side-channel attacks. The first approach is based on correlation. If a correlation is found between a particular process and a victim process, it is an indication of an attack. The motivation behind this approach is that both victim and malicious processes act in similar ways (similar loops with similar operations). Experiments show that the number of last level cache accesses acts as a good parameter to detect an existing correlation. The second approach is based on Anomaly Detection. The particular method used is Gaussian Anomaly Detection [110]. In this work, authors build a model for malicious processes considering them normal and treat all other processes as anomalies. Authors state that the reason of doing this is that it is practically impossible to build a model including all possible benign processes that can run on a system. The third approach is based on Neural Networks. Authors trained Neural Networks based on collected performance counters values (instruction and cache related events) for benign and malicious applications (responsible for attacking through side-channels). The machine learning methods (anomaly detection and neural network) rely on following hardware performance counters: executed instructions, total execution cycles, L2 cache hits, Last Level Cache (L3) accesses and misses. These events are selected based on experimental evidence. Chiappetta et al [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF] performed the assessment of Neural Network and Anomaly Detection using a metric of F-score [START_REF] Vickery | Reviews: van Rijsbergen, CJ Information retrieval[END_REF]. The experimental results on Intel Xeon while evaluating this proposed CSCA detection mechanism shows that the proposed technique can detect spy processes performing Flush+Reload [6] type of side-channel attacks with very high accuracy i.e. an F-score of 0.93 and 1.0 on AES and ECDSA cryptosystems by Neural Network. All three proposed methods are able to detect an attack in 1/5th of the time of attack completion. Another technique, which utilizes both signature and anomaly-based detection has been proposed by Zhang et al [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF]. Zhang et al [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF] correlated execution of cryptographic application on a virtual machine (VM) with the anomalous behaviour of caches to detect cache side-channel attacks in cloud systems. The proposed mechanism, CloudRadar, combines anomaly-based and signature-based attack detection techniques. Once an attack is detected, VM migration is performed as a countermeasure. CloudRadar serves as a lightweight patch to the cloud system under consideration.

Zhang et al [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF] also identified that the two most important requirements for a signature to identify crypto-application's execution are that it should be unique and should be repeatable. They used different types of events like CPU events, cache events and kernel software events to generate signature of applications. It is found that some events (like instructions, branches and mispredicted branch instructions, L1 instruction cache misses) are better for signature generation compared to others because of their uniqueness and ability to repeat. Their experiments showed that only a single feature of total number of branch operations out of the previously identified features was good enough to generate signatures and was used for further experiments. This work uses Dynamic Time Warping (DTW) [START_REF] Sakoe | Dynamic programming algorithm optimization for spoken word recognition[END_REF] algorithm to find distance between two sequences that represent signature and run-time measurements of performance counter values from untrusted VMs. When CloudRadar detects the execution of cryptographic application on the victim VM, the detection framework selects two short sub-sequences from the runtime sequence of performance counter values (cache misses and hits) being monitored on untrusted VMs. These sub-sequences correspond to "data points of size w" before and after the point of minimum DTW distance (DTW distance is used to detect the cryptographic application's execution and minimum DTW distance would correspond to the point when crypto-application starts executing). If the difference between the values of the selected sub-sequences is found to be larger than a threshold, possibility of a side-channel attack is detected.

CloudRadar is evaluated using a system consisting of a controller server, a client server and two hosts cloud servers. Six different crypto-applications belonging to category of symmetric and asymmetric cryptosystems are used for experiments (ElGamal and DSA from GnuPG, AES and 3DES from OpenSSL and hash: HMAC from OpenSSL and SHA512 from GnuPG). The proposed mechanism is tested using Prime+Probe and Flush+Reload cache-based sidechannel attacks. Cloud-Radar is shown to have a 100% true positive rate (with no false positives) when performance counters are sampled at intervals of 100µs and DTW threshold is kept between 0.3 and 0.4. Sampling frequency of 1ms shows worse results while detecting execution of cryptographic applications. With a window size of w=5 (w is discussed in previous paragraph), CloudRadar is able to achieve a false positive rate of 0% with a true positive rate of 100% at a sampling rate of 1ms. At lower values of w, the false positive rate is much higher (e.g. false positive rate is 20%-30% at w=1). Detection latency/speed of CloudRadar is in the "order of milliseconds" on the used machine. Performance overhead of CloudRadar measured using a set of crypto-applications, SPEC2006 [85] and CloudSuite [START_REF] Michael Ferdman | Clearing the clouds: a study of emerging scale-out workloads on modern hardware[END_REF] benchmarks is found to be little. The worst case performance overhead is within 5%.

A three-step detection method for cache and branch predictor based side-channel attacks proposed by Alam et al [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF] also combines Anomaly and Signature-based detection. The first step is used to detect the anomaly, the second step finds the class of anomaly (either related to branch or cache attacks) and the third step correlates malicious process with the victim. This correlation is performed to reduce the number of False Positives. At the first step of the method presented by Alam et al [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF], eight different performance events (branch instructions retired, branch instructions misses, Last Level Cache References, Last Level Cache Misses, Instruction Retired, UnHalted Core Cycles, UnHalted Reference Cycles, Bus Cycles) are monitored in parallel for a set of benign and malicious applications. The benign applications include commonly used Linux tools like cd, gzip, mv etc.. The data is then smoothed by using a finite impulse response filter known as Simple Moving Average (SMA) [START_REF] Ya Lun Chou | Statistical analysis[END_REF]. This filter calculates the "unweighted mean of an equal number of data on either side of an intermediate value". Next, the data is scaled with the help of Standardization [START_REF] Theodoridis | Pattern recognition[END_REF] such that it achieves a mean of zero and a variance of one. Importance of features is then calculated using the technique of Standard Stability Selection [START_REF] Meinshausen | Stability selection[END_REF]. This data is then used to train a semi-supervised anomaly detection mechanism known as One-Class Support Vector Machine (OC-SVM) [START_REF] Schölkopf | Estimating the support of a high-dimensional distribution[END_REF], which is configured with a non-linear kernel (RBF). For the purpose of learning, this algorithm uses data with only one label. In other words, only the data belonging to one of the classes is labelled (also known as normal class).

If any abnormality/anomaly is detected using this anomaly detector (OC-SVM), the process under consideration is passed to the already trained classifiers to determine the category of anomaly. The used classifiers in this work include: Random Forest [START_REF] Lippmann | An introduction to computing with neural nets[END_REF], Adaboost [START_REF] Freund | A decision-theoretic generalization of on-line learning and an application to boosting[END_REF], Multi-layer perceptron [START_REF] Block | The perceptron: A model for brain functioning. i[END_REF], Naive Bayes [START_REF] Murphy | Naive bayes classifiers[END_REF] and Support Vector Machine [START_REF] Hearst | Support vector machines[END_REF]. These classifiers are trained using the data from execution traces of different side-channel attacks that include different hardware events affected by those attacks.

Finally to perform the third step of the proposed approach (correlation of the malicious process and the victim process), Fast Dynamic Time Warping (fast-DTW) [START_REF] Salvador | Toward accurate dynamic time warping in linear time and space[END_REF] is used. If similarity between two temporal sequences composed of performance events is found to be above a threshold, the abnormal process would be detected as a side-channel attack. The proposed approach is validated experimentally with the help of cache side-channel attacks on cryptosystems of AES [START_REF] Daniel | Cache-timing attacks on AES[END_REF] and Clefia [START_REF] Rebeiro | Cache timing attacks on Clefia[END_REF] using two different hardware environments (Intel Core i5-4570 and Intel Xeon E5-2630 v3). The best accuracy for anomaly detection module is found to be 100% and 97% for both setups at a sampling granularity of 1ms. The best classification accuracy is shown by Adaboost classifier, which is above 99% for both setups at sampling frequencies of 10 and 1 ms. The best accuracy of correlation module for setup 1 (AES) is found to be 83% at sampling frequency of 1ms with a DTW window of size w=5 and for setup 2 (Clefia) it is 74% at sampling frequency of 1ms with a DTW window of size w=5.

Possibility of side-channel attacks can also be identified by detecting the presence of multiple VMs on same hardware in cloud systems as done by Zhang et al [START_REF] Zhang | Homealone: Co-residency detection in the cloud via side-channel analysis[END_REF] and Inci et al [START_REF] Sinan | Cache Attacks Enable Bulk Key Recovery on the Cloud[END_REF]. In a public cloud, same physical machine may be shared by many VMs. Co-residency of different VMs on the same physical machine increases the risk of security breakdown. A VM with malicious intent can use the shared resources (like caches) on the same physical machine to attack a victim VM. Zhang et al [START_REF] Zhang | Homealone: Co-residency detection in the cloud via side-channel analysis[END_REF] proposed HomeAlone to detect cross-VM side-channel attacks by first detecting the existence of untrusted VM on the same physical server. HomeAlone is implemented at the level of hypervisor/VM. It works by observing the cache memory activity on the victim VM. HomeAlone works in three steps: First step (PRIME) fills up a portion of the shared cache by reading data from main memory. In the second step (IDLE), it waits for a specific amount of time while other VMs are running. In the third step (PROBE), HomeAlone reads the same cache section and uses time of the reading to determine if this portion is overwritten by another VM. Any time difference indicates the presence of shared resources and possibility of side-channel attacks. Experimental evaluation of HomeAlone is performed using an adversary VM running Prime+Probe attack. The evaluation shows that the detection accuracy is improved with the increase in frequency of Prime+Probe attack or with increase cache sets monitored by HomeAlone, which overlap with malicious VM's activity region. A true detection rate of 85% is observed when 1/16th of cache scanned by HomeAlone overlaps with malicious VM's activity region. Further, the maximum performance overhead (using PARSEC benchmarks [START_REF] Bienia | The PARSEC benchmark suite: Characterization and architectural implications[END_REF]) is found to be equal to 4.6% (with most of the cases around 2%).

Inci et al [START_REF] Sinan | Co-location Detection on the Cloud[END_REF] also focused on the problem of detecting co-location required to perform cross-VM attacks such as Prime+Probe and Flush+Reload in enterprise clouds. This work demonstrates three co-location detection methods named as; cooperative last-level cache covert channel, software profiling on LLC and memory bus locking. Co-location problem is analyzed on threat models of Amazon EC2 Cloud, Google Cloud Engine and Microsoft Azure. Contribution of this work includes; devising a new LLC software profiling tool, which is able to detect application by non-collaborating co-located victims in cloud. This tool is able to detect without the help of memory de-duplication and any other sharing mechanism and describing three co-location methods and discussing their success on popular clouds (considered as a threat model). Threat model considers two attack scenarios for cross-VM on public clouds i.e., the target victim is predefined or the target victim is unknown. Targeted co-location includes identification information of the victim e.g. IP address. Attacker reforms instances on the cloud until the targeted victim is co-located on the same physical machine. Using the IP, attacker can check the server, which is creating CPU load and then co-location tests can be run to verify the presence of victim. It is very easy to achieve co-location detection in this case but one needs to run many tests on the same physical machine as of victim. One can perform targeted co-location by only searching the region where victim instance is publicly utilizing AWS IP lists. Fine grain information on target can be achieved by executing traceroute or tracepath on victim's IP. For random victim co-location detection, attacker sends instances on cloud until it is confirmed that instance is not alone e.g. is co-located with any other VM. The goal is to get maximum likelihood and reduction in the cost of co-locating with viable target. Less costly instances use less CPU cores, which tend to share same hardware at maximum. That is why such instances have bright chance of co-location. Results explain that collaborative and non-collaborative co-location to certain clouds is possible on major cloud services. Proposed mechanism was able to achieve targeted co-location in Amazon EC2 with the help of LLC software profiling (for RSA and AES cryptosystems). For memory bus locking mechanism, memory accesses lead to major degradation while in covert channel, the method achieves high accuracy. It is demonstrated in the work that LLC software profiling mechanism can be used for co-location detection without use of memory de-duplication and any other sort of sharing from victim side. There exist other techniques as well [START_REF] Joseph Dean | Ubl: Unsupervised behavior learning for predicting performance anomalies in virtualized cloud systems[END_REF], [START_REF] Doelitzscher | Anomaly detection in iaas clouds[END_REF], [START_REF] Dolan-Gavitt | Leveraging forensic tools for virtual machine introspection[END_REF], [START_REF] Amr S Abed | Applying bag of system calls for anomalous behavior detection of applications in linux containers[END_REF] to monitor executing guest VMs, which can be used for detection of co-residency and eventually side-channel attacks.

As discussed, Younis et al [START_REF] Younis | Preventing and Detecting Cache Side-channel Attacks in Cloud Computing[END_REF] surveyed and compared two CSCA mitigation techniques (cache flushing [START_REF] Godfrey | Preventing Cache-Based Side-Channel Attacks in a Cloud Environment[END_REF] and noise injection [START_REF] Zhang | DüPpel: Retrofitting Commodity Operating Systems to Mitigate Cache Side Channels in the Cloud[END_REF]) and two CSCA detection techniques (HomeAlone [START_REF] Zhang | Homealone: Co-residency detection in the cloud via side-channel analysis[END_REF] and a two-stage detection technique proposed by Yu et al [START_REF] Yu | An approach with two-stage mode to detect cache-based side channel attacks[END_REF]). These CSCA detection techniques have already been discussed in this section. Younis et al [START_REF] Younis | Preventing and Detecting Cache Side-channel Attacks in Cloud Computing[END_REF], on comparing these CSCA detection and prevention mechanisms, found out that Flushing technique was able to mitigate all the three attacks but injecting noise was unable to detect Prime+Probe & Flush+Reload (4-10 times out of 20), which reduces their detection accuracy to half. For preventing context-switching, cache flushing also induces a high affect on cache efficiency. It is discussed that all prevention and detection mechanisms affect the cache usefulness e.g. solution proposed by Yu et al [START_REF] Yu | An approach with two-stage mode to detect cache-based side channel attacks[END_REF] slows the CPU operations to count cache misses, which significantly reduces the effectiveness of cache whereas, HomeAlone solution flushes the data every time and forces CPU cache to write it back from main memory, which degrades the effectiveness of cache. The work further observes that flushing and injecting noise can prevent cache at all levels. Two-stage detection solution [START_REF] Yu | An approach with two-stage mode to detect cache-based side channel attacks[END_REF] can detect CSCAs at all levels, whereas HomeAlone detects attack at only L2 cache level. available on all modern processors. A few works [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF], [START_REF] Chouhan | Adaptive detection technique for Cachebased Side Channel Attack using Bloom Filter for secure cloud[END_REF], [START_REF] Chen | Detecting privileged side-channel attacks in shielded execution with Déjá Vu[END_REF], [START_REF] Sinan | Cache Attacks Enable Bulk Key Recovery on the Cloud[END_REF] don't use HPCs but still rely on hardware timers provided by the processor vendor. • Machine learning is also proven effective for CSCA detection as 50% of the studied techniques use machine learning models to recognize cache side-channel attacks. • It is generally believed that anomaly-based detection techniques are capable of detecting unknown or zero-day attacks [START_REF] Zhang | Cloudradar: A real-time sidechannel attack detection system in clouds[END_REF]. However, none of the surveyed research works has shown any empirical evidence of the capability of detecting unknown or modified attacks. • We found that almost all of the CSCA detection solutions are purely software-based and there is only a single work [START_REF] Demme | Rapid Identification of Architectural Bottlenecks via Precise Event Counting[END_REF] that also proposed a hardware implementation of the proposed detection technique. • We also observed that there are many research papers that missed one or more important evaluation parameters while evaluating their CSCA detection proposals as shown in Table 2.2. We observed by literature that detection mechanism are rather new direction to CSCAs. Machine learning and hardware performance counters have also been proved effective for detection mechanisms. We argument that detection-based mechanisms can serve as first line of defense. By detection, we only apply mitigation when it is required, which also reduces the effect of system-wide overhead. In the next section, we provide state-of-the-art on mitigation mechanisms, which have already been applied in literature.

We will analyse and debate the effectiveness of these mitigaitions and we will also argue the important steps to be taken toward mitigation mechanisms.

Mitigation Techniques

There has been extensive research work on countermeasure techniques to mitigate cache-based side-channel attacks. These countermeasure techniques can be broadly classified into three categories; mitigation techniques based on new hardware design [START_REF] Domnitser | Non-monopolizable Caches: Low-complexity Mitigation of Cache Side Channel Attacks[END_REF], [START_REF] Kong | Deconstructing New Cache Designs for Thwarting Software Cache-based Side Channel Attacks[END_REF], [START_REF] Kong | Hardware-software integrated approaches to defend against software cache-based side channel attacks[END_REF], [START_REF] Wang | Covert and Side Channels Due to Processor Architecture[END_REF], [START_REF] Wang | A Novel Cache Architecture with Enhanced Performance and Security[END_REF], application-specific (software) mitigation techniques [START_REF] Tromer | Efficient Cache Attacks on AES, and Countermeasures[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Müller | AESSE: A Cold-boot Resistant Implementation of AES[END_REF] and compiler-based mitigation techniques [START_REF] Coppens | Practical Mitigations for Timing-Based Side-Channel Attacks on Modern x86 Processors[END_REF]. Table 2.3 constitutes a detailed representation of software and hardware mitigation techniques that have been proposed so far with respect to cache hierarchy. The table also includes architecture and application-specific features of these techniques.

Countermeasures in Table 2.3 are categorized according to different types and levels of cache along with description. Unfortunately, there are not many general hardware-based mitigation techniques for classical systems, which can be adopted for mainstream processors. These mitigation techniques offer huge performance overhead that makes their adaptation nearly impossible in practice [START_REF] Kim | STEALTHMEM: System-level Protection Against Cache-based Side Channel Attacks in the Cloud[END_REF], [START_REF] Aciicmez | Cheap Hardware Parallelism Implies Cheap Security[END_REF].

In this section, we discuss several software mitigation techniques, which have been proposed over the last decade or so. Since these mitigation techniques often exploit architecture-specific or application-specific features, therefore, we cannot suggest one recipe for all type of implementations. There are different mitigation techniques, which deal with different levels of threat at application and architecture levels. Classification of to-date countermeasures with respect to hardware and software are mentioned in Table 2.3. Whereas, they have been identified in major class as hardware threading (core-shared state at L1-L2 level of cache due to hyper-threading/simultaneous multi-threading), time slicing (Core-shared state on L1-L2 level of cache due to timing variation and self-contention) and multicore (package-shared state on LLC creating side-channels and covert channels) [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF].

We intend to discuss some practical techniques along with their merits and demerits in this section. Table 2.4 presents an exhaustive list of software-based countermeasures published to-date. These countermeasures are divided into sub-categories so that it may be easy to distinguish the class of related software countermeasure. Table 2.5 lists all software countermeasures w.r.t the cache hierarchy to which the mitigation can be imposed, threat level (Uni-Processor, Hyper-Threading, Multicore, Simultaneous multithreading). Software countermeasures are not restricted to solve one type of problem in one type of cryptographic algorithm. Rather these countermeasures are used in a generic sense to mitigate cache-based side-channel attacks.

Modern architectures are complex in nature, therefore, mitigation techniques proposed for a specific leakage may not fully protect the system. Hardware and software developers must consider entire threat model that can possibly be exploited by the malicious applications. While discussing already proposed mitigation techniques, we also carefully review the architectural features that are exploited and their effects on these mitigation techniques. We also discuss security critical parameters both at application layer and architectural layer that can be used in mitigation without changing the underlying architectural features.

L1

Disable Hardware Threading [START_REF] Percival | Cache missing for fun and profit[END_REF], [START_REF] Marshall | Security best practices for developing windows azure applications[END_REF],

Way to reduce the cost flushing

2005, 2010

Hardware Threading Newcache [START_REF] Liu | Newcache: Secure cache architecture thwarting cache side-channel attacks[END_REF] Dynamic randomised memory-to-cache mapping 2016

Auditing [START_REF] Tan | The micro-architectural support countermeasures against the branch prediction analysis attack[END_REF] Detecting malicious behaviors 2014

Increasing bandwidth of Cache [START_REF]Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide[END_REF], [START_REF]Intel 64 and IA-32 Architectures Optimization Reference Manual[END_REF] Reducing Contentions 2014, 2012

Constant-Time Techniques [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF], [START_REF] Andrysco | On Subnormal Floating Point and Abnormal Timing[END_REF], [START_REF] Rane | Secure, Precise, and Fast Floating-Point Operations on x86 Processors[END_REF] Fixed time instructions 2017, 2015, Time Slicing

Cache Flushing [START_REF] Zhang | DüPpel: Retrofitting Commodity Operating Systems to Mitigate Cache Side Channels in the Cloud[END_REF], [START_REF] Varadarajan | Scheduler-based Defenses against Cross-VM Side-channels[END_REF], [START_REF] Godfrey | A Server-Side Solution to Cache-Based Side-Channel Attacks in the Cloud[END_REF] No privilege to flush specific lines 2014, 2013,

L2

Hardware Cache Partition [START_REF] Domnitser | Non-monopolizable Caches: Low-complexity Mitigation of Cache Side Channel Attacks[END_REF], [START_REF] Wang | New Cache Designs for Thwarting Software Cache-based Side Channel Attacks[END_REF], [START_REF] Colp | Protecting Data on Smartphones and Tablets from Memory Attacks[END_REF], [START_REF] Page | Partitioned Cache Architecture as a Side-Channel Defence Mechanism[END_REF] Paritioning cache for security sensitive applications 2012,2007,2015,2005 Hardware Threading RP Cache [START_REF] Kong | Hardware-software integrated approaches to defend against software cache-based side channel attacks[END_REF], [START_REF] Wang | New Cache Designs for Thwarting Software Cache-based Side Channel Attacks[END_REF] Random Indexing of lines

2009,2007

Disable Hardware Threading [START_REF] Percival | Cache missing for fun and profit[END_REF], [START_REF] Marshall | Security best practices for developing windows azure applications[END_REF] Way to reduce the cost flushing

2005, 2010

Minimum Timeslice [START_REF] Varadarajan | Scheduler-based Defenses against Cross-VM Side-channels[END_REF] Preventing attacker to observe cache state in preemptions 2014

Cache Flushing [START_REF] Zhang | DüPpel: Retrofitting Commodity Operating Systems to Mitigate Cache Side Channels in the Cloud[END_REF], [START_REF] Varadarajan | Scheduler-based Defenses against Cross-VM Side-channels[END_REF], [START_REF] Godfrey | A Server-Side Solution to Cache-Based Side-Channel Attacks in the Cloud[END_REF] No privilege to flush specific lines • Cache Coloring [START_REF] Godfrey | Preventing Cache-Based Side-Channel Attacks in a Cloud Environment[END_REF], [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF], [START_REF] Shi | Limiting Cache-based Side-channel in Multi-tenant Cloud Using Dynamic Page Coloring[END_REF], [START_REF] Bershad | Avoiding Conflict Misses Dynamically in Large Direct-mapped Caches[END_REF] • Migration of VMs [START_REF] Moon | Nomad: Mitigating Arbitrary Cloud Side Channels via Provider-Assisted Migration[END_REF] • STEALTHMEM [START_REF] Kim | STEALTHMEM: System-level Protection Against Cache-based Side Channel Attacks in the Cloud[END_REF] • CacheBar [START_REF] Zhou | A Software Approach to Defeating Side Channels in Last-Level Caches[END_REF] Noise-based Countermeasure Techniques (Section 2.4.2)

• Fuzzy Time [START_REF] Hu | Reducing Timing Channels with Fuzzy Time[END_REF] • Eliminating Fine Grained Timers [START_REF] Bhanu | Eliminating Fine Grained Timers in Xen[END_REF] • Bystander Workloads [START_REF] Zhang | On Mitigating the Risk of Cross-VM Covert Channels in a Public Cloud[END_REF] • Anti-correlated Noise [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF] Scheduler-based Countermeasure Techniques (Section 2.4.3)

• Scheduling-based Obfuscation [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF], [START_REF] Liu | Mitigating Cross-VM Side Channel Attack on Multiple Tenants Cloud Platform[END_REF], [START_REF] Liu | Shuffler: Mitigate Cross-VM Side-Channel Attacks via Hypervisor Scheduling[END_REF] • Leakage Feedback [START_REF] Biondi | Information Leakage as a Scheduling Resource[END_REF], [START_REF] Mohan | Real-time systems security through scheduler constraints[END_REF], [START_REF] Pellizzoni | A generalized model for preventing information leakage in hard real-time systems[END_REF] • Retired Instruction [START_REF] Stefan | Eliminating cache-based timing attacks with instruction-based scheduling[END_REF] • Minimum Timeslice [START_REF] Varadarajan | Scheduler-based Defenses against Cross-VM Side-channels[END_REF] • Cache Flushing [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF], [START_REF] Zhang | DüPpel: Retrofitting Commodity Operating Systems to Mitigate Cache Side Channels in the Cloud[END_REF], [START_REF] Godfrey | A Server-Side Solution to Cache-Based Side-Channel Attacks in the Cloud[END_REF] Partitioning-Time Countermeasure Techniques (Section2.4.4)

• Server Side Defenses (cache Flushing) [START_REF] Godfrey | A Server-Side Solution to Cache-Based Side-Channel Attacks in the Cloud[END_REF] • Kernel Space Isolation [START_REF] Gruss | Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR[END_REF] Constant Time Countermeasure Techniques (Section 2.4.5)

• CacheAudit [START_REF] Doychev | CacheAudit: A Tool for the Static Analysis of Cache Side Channels[END_REF] • FlowTracker [START_REF] Bruno R Silva | Uma Técnica de Análise Estática para Detecç ao de Canais Laterais Baseados em Tempo[END_REF], [START_REF] Köpf | Automatic Quantification of Cache Side-channels[END_REF] • Valgrind [179], [180]

Logical/Physical Isolation-based Mitigation Techniques

Disabling resource sharing and executing applications in complete physical and/or logical isolation to protect against adversaries has been conceptually trivial yet a popular mitigation technique. In this section, we present software mitigation techniques that are based on partitioning/isolation to counter recent cache-based side-channel attacks.

Cache Coloring

Cache Coloring is a mechanism to partition the cache with the help of software implementation. Cache coloring is proposed to overall enhance the cache performance in real time and reduce cache contention [START_REF] Bershad | Avoiding Conflict Misses Dynamically in Large Direct-mapped Caches[END_REF], [START_REF] Kessler | Page Placement Algorithms for Large Real-indexed Caches[END_REF], [START_REF] Liedtke | OS-controlled cache predictability for realtime systems[END_REF]. Cache coloring has proved to be an important mitigation technique against cache-based timing SCAs. Cache coloring segregates the memory into colored pools and assign memory from distinct pools to transform into a security restricted domain. Physical frames whose addresses differ from the colored bits are never mapped to the similar cache set. There are many implementations for cache coloring such as static and dynamic cache coloring [START_REF] Godfrey | Preventing Cache-Based Side-Channel Attacks in a Cloud Environment[END_REF], [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF], [START_REF] Shi | Limiting Cache-based Side-channel in Multi-tenant Cloud Using Dynamic Page Coloring[END_REF], [START_REF] Bershad | Avoiding Conflict Misses Dynamically in Large Direct-mapped Caches[END_REF].

In static coloring, some static colors are allocated for security critical applications. If the number of security demanding applications increases, static coloring is unable to respond all the requests dynamically. That is why, approach for dynamic coloring was introduced, which represents dynamic number of secure colored pages to the security critical applications at run-time. One such approach is discussed in [START_REF] Shi | Limiting Cache-based Side-channel in Multi-tenant Cloud Using Dynamic Page Coloring[END_REF], which proposes non-intrusive and low overhead technique of page coloring named as Chameleon. The Chameleon technique provides secure color to the secure process so that a strict isolation in virtualized environment could be maintained. Before a process goes to a security critical section, hypervisor is notified and during that section, the secure color is only available for security critical operation and can not be used by any other co-located VMs of the same hardware platform. This technique provides both full mode and selective mode protection mechanism, but it did not compare the results with other dynamic coloring approaches to review the performance parameters. Furthermore, the impact of this approach to stop any kind of cache-based side-channel attacks has not been documented in the work.

Another form of cache coloring has been discussed into the XEN's memory management tool in [START_REF] Godfrey | Preventing Cache-Based Side-Channel Attacks in a Cloud Environment[END_REF]. This technique demonstrates a complete closure of side-channel between different virtual machines by the help of cache coloring. The authors also managed to analyze the performance cost that is 50% for Apache-2013 benchmark and there was very less penalty with small working sets. One problem seen with cache coloring in this technique was the inability to use large pages whereas, many processors are able to use large pages in x86 architectures. One benefit of having large pages would be the reduction of overlapping pages and requirement for colored pages will be reduced to a very short number.

The effectiveness of using cache coloring to reduce the impact of cache-based covert channels has been described in [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF]. This mechanism has been proved to be more efficient on cores with simpler structures in comparison with cores having complex structures because of TLB contention that can be solved by flushing TLBs on a context switch of VMs. Furthermore, a rather new challenge is to move from directly-mapped cache to cache sets. While, we know that LLC is divided among cores connected with a ring bus as illustrated in Figure 2.1. Locating the physical address for cache line depends on addressing a cache block and addressing a set in that block. The newer Intel micro-architectures contain a hash function to locate these blocks. Without having prior knowledge of hash functions, the available colors are confined within cache block [START_REF] Yarom | Mapping the Last-Level Cache[END_REF]. Several research efforts have reverse-engineered the hash function of multiple processor models that support the use of multiple colors [START_REF] Sinan | Co-location Detection on the Cloud[END_REF], [START_REF] Maurice | Reverse Engineering Last-Level Cache Complex Addressing Using Performance Counters[END_REF], [START_REF] Yarom | Mapping the Last-Level Cache[END_REF], [START_REF] Irazoqui | S$A: A Shared Cache Attack That Works Across Cores and Defies VM Sandboxing -and Its Application to AES[END_REF], [START_REF] Hu | Lattice Scheduling and Covert Channels[END_REF] but this might not be possible for future CPUs [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF].

STEALTHMEM

STEALTHMEM [START_REF] Kim | STEALTHMEM: System-level Protection Against Cache-based Side Channel Attacks in the Cloud[END_REF] is a software mitigation approach that uses a limited principle of cache coloring to mitigate cache-based side-channel attacks with three different perspectives; it checks the impact of its proposed stealth pages on case of context switch, hyperthread and sharing the LLC and analyzed its performance with dynamic cache coloring. It provides a small amount of colored memory, which was targeted to avoid contention and flushing in the LLC. The target of this approach is to provide stealth pages to security critical data that is encrypted. This specific approach reserves stealth pages for each core, on which, each VM is residing. Usage of same stealth page for two different cores is made impossible in this approach and a regular check system is maintained that calls PTA (Page Table Alert) scheme. PTA scheme ensures that the cache implements K-LRU mechanism, in which a cache miss is declared not to flush any of the K lines from recently accessed lines. This mitigation technique ensures usage of small number of stealth pages and locks them for each core in the LLC, respectively. Therefore, an attempt to access any other page that is reserved, triggers a page fault that is invoked in the form of STEALTHMEM. Pre-arranging cache colors minimizes the number of cache sets that are utilized. This mechanism has been analyzed against the probability of context switch and sharing cores but for hyper-threading only disabling hyper-threading has been suggested as a straightforward solution. The performance of STEALTHMEM has been analyzed, which shows relatively small overhead for SPEC-2006 benchmark, around 5.9% for STEALTHMEM and 7.2% for PTA due to having extra faults. The overall performance degradation of using this mitigation is around 2 -5% for three encryption algorithms namely; DES, AES and Blowfish.

Migration of VMs

Information leakage in co-residing VMs has become a major threat to cloud environments. To mitigate such channels, Nomad [START_REF] Moon | Nomad: Mitigating Arbitrary Cloud Side Channels via Provider-Assisted Migration[END_REF], has implemented a software-base solution to mediate the migration of VM workloads. Migration-as-a-Service cloud computation model believes in placement algorithm of VMs. Past and current VM assignments are saved in epochs as input and the next placement of VMs is decided on this information. It identifies providerassisted VM migration as a novel defense strategy for information leakage happening due to side-channels. The system is analyzed on a scalable online VM migration where it has shown that this heuristic is able to handle massive data center workloads. For minimizing the effect of services running on each VM, Nomad provides client API, which allows clients to monitor non-relocatable VMs. This mitigation technique provides performance overhead for traditional cloud applications such as web services and Hadoop MapReduce.

Quasi-partitioning

Manipulation on resources, helps the attacker to attain information of victim and conducting effectively an access-driven side-channel attack. CacheBar [START_REF] Zhou | A Software Approach to Defeating Side Channels in Last-Level Caches[END_REF], is a mitigation against access-driven side-channel attacks that targets last-level caches (LLCs) that are shared across cores in processors. The property of sharing helps to leak information between security domains such as clouds and tenants in a big picture. CacheBar arranges physical memory pages in a dynamic fashion to prevent sharing of LLC lines and preventing the side-channels occurring due to Flush+Reload techniques in LLCs. Whereas, it also creates a cacheability mechanism of memory pages to work against Prime+Probe attacks happening in LLCs. CacheBar is a memory management subsystem within linux kernel to effectively work on such side-channels. It allocates a budget in cache for the security sensitive applications to execute.

Noise-based Mitigation Techniques

All the attacks except Prime+Abort, we have analyzed in Section 3.2, refer to the accuracy of measurement of minute timing variations by the attacker, whether it is encryption itself or the accesses to the attackers memory. A suggestion to counter timing attacks is to introduce noise to the observed timings by executing random delays to the operations being performed. This slows down the attacker to perform and attacker will average many executions and measurements all together. Theoretically, it was suggested to prevent the exploitation of timing channels with increase in contention. It ensures that the attacker's measurements have lot of noise that was actually useless for the attacker to monitor. This theory has been implemented in fuzzy time approach [START_REF] Hu | Reducing Timing Channels with Fuzzy Time[END_REF], which introduced noise into all the events that are visible to a process. Modification of XEN hypervisor to inject noise as eliminating fine grained timers is explained in [START_REF] Bhanu | Eliminating Fine Grained Timers in Xen[END_REF], where noise is injected into high resolution timing measurements in VMs by modifying results of RDTSC instruction. This mitigation technique addresses some potential research questions of other sources of fine-grained timers.

A bystander VM for injecting noise on the cross-VM L2-cache covert channel is described with a configurable workload in [START_REF] Zhang | On Mitigating the Risk of Cross-VM Covert Channels in a Public Cloud[END_REF]. This technique uses a Time Markov process to check the effect of bystanders on cross-VM covert channel. The effect is analyzed in two terms; scheduling of the virtualization platform and intensity of workload (bystanders). By this study, influential factors affecting covert channels in Prime+Probe attacks are analyzed by scheduling on XEN (to evaluate the error rate of bystander VM). By checking this, authors were able to detect that, as long as, bystander VMs tune the consumption time of CPU, they are unable to affect cross-VM covert channel. It is demonstrated in this attack that injecting noise into Prime+Probe channels, bystander VMs need to modulate their working sets and memory access patterns. The efficiency of said mechanism is evaluated through trace-driven simulations in which VMs are provisioned for applied strategy. Anti-corelated noise has been suggested in [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF], which can principally close the channel completely. The rate of noise (uncorrelated) rises while decreasing the channel capacity dramatically. But formation of such mechanisms have significant performance overhead and it is considered infeasible to reduce bandwidth of channel in such magnitudes [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF]. Approaches for eliminating hardware timing channels enforce a new hardware design architecture to minimize the risk of sharing or loosely-coupled architectures to minimize the availability of shared resources. System designers are trying to achieve highly secure systems and such approaches can be a drawback in terms of performance degradation [START_REF] Hu | Reducing Timing Channels with Fuzzy Time[END_REF]. Abandoning contemporary processors means abandoning the installed application layer and OS too that makes processors more expensive. So, the existence of hardware timing channels is a major threat. Introducing noise to have highly secure systems is proven to be inefficient [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF], whereas, previous techniques are proven to be insufficient to deal with them because closing the signal for the channel is a difficult task and those who can be closed, have a dramatic performance degradation [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF].

Scheduler-based Mitigation Techniques

Scheduling is another effective technique to mitigate the timing channel attacks. Such attacks are passive so it's not trivial to deal with them. Although the hypervisor scheduler can not differentiate the malicious and victim VMs. But we may limit the information leakage using novel scheduling schemes to minimize the attacking VMs intervention into the victim's memory accesses. One way of scheduling is to minimize the overlapping time of VMs but it comes with a major performance cost by excessive context switching. The time overlapping can be limited by introducing some noise by hypervisor before the timeout for each VM that can interrupt the transmission of data to an attacker VM through a timing side-channel. Attacks having concurrent or consecutive access that share the same hardware resources can be mitigated by two ways; either provide exclusive time sliced accesses or manage the transition with care between each time-slice.

Scheduling-based Obfuscation

Hypervisor scheduler can call obfuscation functions in order to inject noise to the potential side-channel. In [START_REF] Liu | Mitigating Cross-VM Side Channel Attack on Multiple Tenants Cloud Platform[END_REF], authors modified the XEN scheduler and proposed a new scheme that uses two parameters: overlap_cap and noise_function. overlap_cap is the ceiling value for overlapping time of execution of two VMs and noise_function is injected noise for different side-channels. For example, in order to cater the memory bus contention based side-channel attacks [START_REF] Wu | Whispers in the hyper-space: highbandwidth and reliable covert channel attacks inside the cloud[END_REF], the administrator can induce the noise function as some atomic memory access. Hence the attacker will not be able to differentiate whether the signal is from the victim or caused by hypervisors's noise. These parameters could be used to achieve the pertinent security/performance trade off according to the administrator preferences. Authors in [START_REF] Liu | Shuffler: Mitigate Cross-VM Side-Channel Attacks via Hypervisor Scheduling[END_REF] propose a scheduler based technique called as Shuffler, which efficiently limits the vulnerable probability of attacks in VMs. The solution claims to distribute CPU time to vCPUs with equal probability, which would reduce the overall vulnerable probability of the system. Shuffler scheduler, hence, shows minimum information leakage to mitigate cross-VM SCAs with negligible performance penalty while preserving high resource utilization.

Leakage Feedback

Schedulers are unaware of any security related task that may leak the information. If however, schedulers are designed in a way to be conscious about the sensitivity of a process, information leakage can be minimized. Some approaches like [START_REF] Mohan | Real-time systems security through scheduler constraints[END_REF] and [START_REF] Pellizzoni | A generalized model for preventing information leakage in hard real-time systems[END_REF] have utilized the flushing memory at the end of every sensitive operation to remove the footprints of traces. But such frequent flushing operations render schedulability at stake and can be expensive especially for real-time tasks in meeting their deadlines. Schedulers can be designed such that the information leakage can be quantified to be used as a feedback to suppress it. The authors in [START_REF] Biondi | Information Leakage as a Scheduling Resource[END_REF] follow a workflow model used in real-time systems in which jobs are periodically produced to be scheduled and to be completed before assigned deadlines. The tasks are divided into steps that individually consist of three parameters: execution time, leakage value and security level. The steps consist of atomic operations independent of scheduler preemption and help in assessing the behavior of the tasks. The authors propose a heuristic approach to use flushing operation to achieve zero leakage while still achieving acceptable schedulability.

Retired Instructions

Another way of secure scheduling can be on the basis of retired instructions (RI) count. RI is a parameter available in the hardware performance counters (HPC) in modern CPUs. In [START_REF] Stefan | Eliminating cache-based timing attacks with instruction-based scheduling[END_REF], authors suggest instruction based scheduler that does not impact timing in hardware in terms of cache, TLB and CPU buses. The authors claim that the impact of their implementation on performance is minimal when compared to time-based scheduling. Their solution, however, needs to be tested for multicore architectures.

Minimum Timeslice

This mitigation has investigated the principle of soft-isolation to minimize the risk of sharing by providing sophisticated scheduling mechanism. A minimum run-time (MRT) that confines the occurrence of preemptions for VMs can effectively prevent existing Prime+Probe cachebased side-channel attacks [START_REF] Varadarajan | Scheduler-based Defenses against Cross-VM Side-channels[END_REF]. Determining minimum timeslice for exploitable component inhibits the attacker to scrutinize the state in middle of any sensitive operation at the cost of increased latency. Attacks containing the approach of Prime+Probe [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF], are dependent on the ability to inspect the state of victim by targeting preemptions frequently. While, the approach of soft-isolation increases the latency to such a mediation point that interval of preemption increases and attacker could not inspect the state of victim. This defense mechanism is particular to one approach (Prime+Probe) that can likely be exploited by more sophisticated attacks such as Flush+Flush, Flush+Reload, etc. [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF].

Cache Flushing

The obvious problem to context switching is that, the attacker VM is able to observe the state of victim VM during switch. The evident solution to this problem is flushing the data of victim VM before every switch. By this mechanism, it is hard for the attacker VM to observe the state of victim VM. Flush on switching has been proposed in a technique named as Düppel in [START_REF] Zhang | DüPpel: Retrofitting Commodity Operating Systems to Mitigate Cache Side Channels in the Cloud[END_REF]. This defense system includes mitigation for time-shared caches such as L1 and L2, TLB and BTB. In this mechanism a tenant can construct its VM to introduce additional noise to the timings that attacker might observe from the cache. Since, this timing information is very important for the attacker because it allows infering the sensitive information of victim, injecting noise makes this job more difficult. Düppel modifies the guest OS Kernel and does not need to change hypervisor or cloud providers. Unlike the noise producing techniques, Düppel repeatedly cleans the L1 cache along with the execution of tenant workload. But this mitigation has a performance overhead to flush local state of cache.

The above proposed solutions effectively mitigate the attacks on time shared caches by flushing but they have a cost to pay in terms of performance overhead. The effect of flushing L1 cache has been analyzed in [START_REF] Varadarajan | Scheduler-based Defenses against Cross-VM Side-channels[END_REF]. It has been benchmarked that 17% latency increase when these types of mitigations are proposed. Flushing the upper levels of cache in VM switch is not inappropriate if it gives less performance degradation. Size of L1 level cache is relatively small (32 KB in x86 architectures) [START_REF]Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide[END_REF] and the typical expected context switch rate is also low. The normal switching rate of schedulers in XEN to make scheduling decisions is after every 30ms [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF]. So, there is low probability of newly scheduled VM finding any data or instruction in the cache and it means that indirect cost of flushing the L1 caches on switching the VMs is insignificant [START_REF] Qian | Contemporary Processors Are Leaky -and There's Nothing You Can Do About It[END_REF]. But for the lower level of caches that are larger, flushing leads to a significant performance degradation.

There are some server-side defenses proposed that suggest flushing at all levels of cache during the context switch of VMs in cloud computing. It is a server-side approach implemented to improve security without providing any inconvenience to the cloud [START_REF] Godfrey | A Server-Side Solution to Cache-Based Side-Channel Attacks in the Cloud[END_REF]. This research has motivated two perspectives; 1) cloud's architecture is particularly susceptible to cache-based side-channel attacks and 2) attacks in clouds can not be solved without interfering in cloud model. Proposed technique is a server (hypervisor) based solution in an entire cloud system with no interference in cloud mode of operation (requires no changes in client or underlying hardware).

Partitioning Time Mitigation Techniques

Kernel Address Space Isolation

Prefetch side-channel attacks have been proposed as a new class to exploit potential weaknesses in prefetch instructions [START_REF] Gruss | Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR[END_REF], which allows unauthorized attackers to obtain address information to compromise the whole system. Prefetch instruction can fetch unreachable confidential memory into caches in Intel x86. Whereas, Meltdown attack [START_REF] Lipp | Meltdown[END_REF] also targets the memory addresses in kernel address space and one phase of the attack uses CSCA technique (Flush+Reload) to retrieve information on victim addresses. As a mitigation, some strong kernel isolations at OS level have also been proposed in [START_REF] Gruss | Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR[END_REF], to reduce the impact of prefetch instruction that exploit information. Due to this reason, distinct kernel threads do not run in the similar address space as user threads. This mitigation requires some modifications in OS kernels. This type of mitigation is useful for the attacks on time shared caches that follow prefetch instructions. The performance cost appears in this mitigation technique but it appears to be low from 0.06 to 5.09%. Another kernel isolation is also proposed for meltdown attack name KAISER [START_REF] Gruss | Kaslr is dead: long live kaslr[END_REF], which isolates kernel from user address space totally so that no exception can lead to memory addresses of kernel space.

Constant-Time Mitigation Techniques

A well known approach for mitigating information leakage is to focus on cryptographic operations by constant-time techniques. They are mathematically sound but when we implement them to some hardware, they tend to leak information in different ways. There must be some changes introduced to these cryptographic algorithms such as; use of fixed time instructions that depend on secret data, there should be no conditional branches that lead to secret data and there should be no memory access patterns that lead to secret data. There is high level of difficulty and complexity involved to change cryptographic operations for remote attacks and contention-based attacks [START_REF] Bernstein | Cache-timing attacks on AES[END_REF]. In [START_REF] Brickell | Technologies to improve platform security[END_REF], it has been suggested not to provide secret dependent accesses at coarser grain than cache line granularity that proved the fact that such an implementation can leak secret information. It has been warned by Osvik in [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF] that processors can still leak information of address bits and a proof to this statement has been provided in CacheBleed [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF]. It has been red flagged consistently that these problems can evolve in Intel processors as described in [START_REF] Daniel | A Word of Warning[END_REF]. If we consider a fact, that secret memory accesses should not be dependent on secret information that might be leaked, then it is still not sufficient to mitigate such leaks. There are many possible leaks that have been demonstrated such as instructions that are data dependent, timing of execution and memory dependent data [START_REF] Coppens | Practical Mitigations for Timing-Based Side-Channel Attacks on Modern x86 Processors[END_REF]. Many tools and frameworks have been developed to provide mitigation by constant-time techniques [START_REF] Köpf | Automatic Quantification of Cache Side-channels[END_REF], [179], [180]. [180], presented an analysis tool, which was modification of [179]. It presented a formal framework to design a constant-time code, which is able to detect the flow of secret information. [START_REF] Köpf | Automatic Quantification of Cache Side-channels[END_REF], described an upper bound of information that can leak from an implementation of cryptographic algorithm. Some approaches like CacheAudit [START_REF] Doychev | CacheAudit: A Tool for the Static Analysis of Cache Side Channels[END_REF] and FlowTracker [START_REF] Bruno R Silva | Uma Técnica de Análise Estática para Detecç ao de Canais Laterais Baseados em Tempo[END_REF] have contributed to provide security at better level of abstraction and modified existing compilers to get track of flow of information for detection of channels. But the main disadvantage of constant-time implementations is that they work on one hardware deployment constantly but not on other hardware platform. e.g. [START_REF] Cock | The Last Mile: An Empirical Study of Timing Channels on seL4[END_REF], is a constant-time mitigation to Lucky 13 attack [START_REF] Nadhem | Lucky thirteen: Breaking the TLS and DTLS record protocols[END_REF], but it is not applicable on ARM platforms (AM3358). It is just an example of different attacks not working on different processors such as CacheBleed [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF], works only on sandy bridge processors and can not work on other processors due to not having multi-threading in them. Work in [6], does not work on ARM architectures because ARM processors do not have inclusive caches. So, this is same for constant-time techniques that they are really specific to a certain hardware platform and we need to develop different parameters of constant-time implementations for different hardware platforms. s

Lessons Learned

In the last decade or so, substantial research efforts have been made to provide mitigation techniques through resource isolation. Both software and hardware based cache partitioning strategies have been proposed as countermeasures against cache-based SCAs [START_REF] Kim | STEALTHMEM: System-level Protection Against Cache-based Side Channel Attacks in the Cloud[END_REF], [START_REF] Domnitser | Non-monopolizable Caches: Low-complexity Mitigation of Cache Side Channel Attacks[END_REF], [START_REF] Page | Partitioned Cache Architecture as a Side-Channel Defence Mechanism[END_REF], [START_REF] Wang | New Cache Designs for Thwarting Software Cache-based Side Channel Attacks[END_REF], [START_REF] Liu | CATalyst: Defeating last-level cache side channel attacks in cloud computing[END_REF]. These strategies, however, introduce significant performance degradation because of cache reservation. Moreover, hardware-based partitioning techniques require specialized features, such as proposed in [START_REF] Liu | CATalyst: Defeating last-level cache side channel attacks in cloud computing[END_REF] that uses Cache Allocation Technology (CAT) for partitioning. Software-based techniques like page coloring for instance requires systemlevel modifications, which potentially raises an issue of incompatibility with architectural features [START_REF] Liu | CATalyst: Defeating last-level cache side channel attacks in cloud computing[END_REF]. The objective of achieving strong isolation seems to be attainable to some extent. Though the hardware developers are able to hide CPU's internal hierarchy but somehow the internal timing leakage is still very visible, which can be exploited to observe cryptographic implementations as demonstrated in virtual machines set up [6], [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [START_REF] Bernstein | Cache-timing attacks on AES[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF], [3], [START_REF] Zhang | Cross-Tenant Side-Channel Attacks in PaaS Clouds[END_REF]. Recently, some more sophisticated attacks such as Spectre [START_REF] Kocher | Spectre Attacks: Exploiting Speculative Execution[END_REF], Meltdown [START_REF] Lipp | Meltdown[END_REF] and some covert channel attacks [START_REF] Daniel Genkin | May the Fourth Be With You: A Microarchitectural Side Channel Attack on Several Real-World Applications of Curve25519[END_REF] have been launched, which are more critical in their nature and hard to detect and mitigate using present solutions.

Although a lot of research efforts have been done to propose novel mitigation techniques against malicious side-channel attacks, such techniques still need improvements. Mitigation techniques generally focus on a specific vulnerability and do not provide an all-weather protection as it can be expensive and complex. At the same time, there has been a continuous progress in the domain of attacks, which keep on getting complicated and stealthier. Therefore, the gap between the demands of a CSCA mitigation technique and what they offer is increasing as well. We argue that in this scenario, CSCA detection techniques can work in synergy with CSCA mitigation and prevention techniques to simplify their design and performance cost. CSCA mitigation and prevention techniques would be activated only if a detection technique raises an alarming flag. CSCA detection techniques have to be accurate and fast in order to be useful when coupled with CSCA mitigation techniques. Researchers have proposed various techniques to detect cache-based side-channel attacks [START_REF] Mushtaq | NIGHTs-WATCH: a cache-based side-channel intrusion detector using hardware performance counters[END_REF], [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF], [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF], [START_REF] Bazm | Cache-Based Side-Channel Attacks Detection through Intel Cache Monitoring Technology and Hardware Performance Counters[END_REF], [START_REF] Mushtaq | Run-time Detection of Prime+ Probe Side-Channel Attack on AES Encryption Algorithm[END_REF], [START_REF] Mushtaq | Machine Learning For Security: The Case of Side-Channel Attack Detection at Run-time[END_REF], [START_REF] Demme | On the feasibility of online malware detection with performance counters[END_REF]. It is important to understand the existing CSCA detection mechanisms and identify any improvements that can be done.

Summary

This chapter provides a global perspective on cache-based side-channel attacks, along with the microarchitectural details, detection and mitigation techniques that have been proposed in the past. Our particular focus has been on the identification of vulnerabilities in hardware particularly Intel x86, which leak information when cryptographic implementations are deployed on such platforms. It also provides a classification of these attacks based on the source of information leakage. The main focus of this chapter has been on the qualitative analysis of existing attacks on target cryptosystems. We have also provided an extensive study on the mitigation and detection techniques being proposed against such attacks in the similar fashion and classified them based on their effectiveness at various levels in cache hierarchy and leveraged features.

The chapter provides discussion on future research trends, challenges, and directions for cache-based side-channel attacks, detection techniques, as well as for mitigation techniques. The chapter advocates in favor of a holistic approach to counter SCAs through secureby-design approach from hardware perspective and need-based protection approach from software perspective. We conclude that future trends in SCAs are moving towards stealthier approaches as the defenses are getting stronger. Moreover, resource isolation-based mitigation will not be viable in future from economical and performance perspectives as resource sharing tends to increase in modern computing infrastructure to sustain performance benefits. The chapter also highlights the importance of high resolution detection techniques using hardware performance monitoring to detect more sophisticated and stealthier attacks in future.

Publications related to this chapter

Cache-based Side-Channel Attacks as Use-cases

This section elaborates different CSCA techniques along with the uses cases considered for this thesis. We explain the working principle and implementation of each attack. These implementations are part of our contributions as we have reproduced some of the latest CSCA techniques and, in some cases, modified them for better efficiency. Moreover, understanding of these attack techniques is essential to understand and appreciate the details of proposed detection and mitigation solutions.

Use-cases: Selected CSCAs & CCAs

We have selected 9 different implementations of Cache-Based Side-Channel Attacks (CSCAs) and Covert Channel Attacks (CCAs) as use-cases for the validation of our detection-based mitigation mechanism. These attacks cover 5 main categories of CSCAs and CCAs, i.e., Flush+Reload (F+R), Prime+Probe (P+P) and Flush+Flush (F+F), Spectre and Meltdown.

We have validated our results by running these use-cases on RSA and AES cryptosystems, whereas, selected CCAs are independent of any cryptosystem. Moreover, for validation, we have used 2 different versions of OpenSSL on which the attacks are demonstrated in the state-of-the-art. We have performed the attack implementations on Linux Ubuntu 16.04.1 with kernel 4.13.0 -37 running on Intel's core i7 -4770 CPU at 3.40-GHz. Table 3.1 provides details on these use-cases along with the OpenSSL versions being used and the time to recover the key by each of these attacks. We also modified some attacks for faster and full key recoveries, mentioned in Section 3.6.

In order to facilitate the community, the source code and experimental data related to all these CSCAs (along with modified attack implementations) and CCAs are provided at our Github repository [198], which can be used, distributed and reproduced freely.

Leakage Exploitation Techniques and Implementations

This section presents the understanding on techniques that are used to demonstrate cachebased attacks using leakage channels in various cache levels as discussed in previous chapter. This section also provides the implementation detail on 9 attacks we have used for demonstration of our proposed mechanism in this thesis. List of those attacks are discussed in Table 3.1. Please note that all the figures used in this section, AAS & VAS correspond to attacker and victim address space.

Prime+Probe (P+P) Technique

LLC based cross-core attacks are usually Prime+Probe attacks [START_REF] Sinan | Co-location Detection on the Cloud[END_REF] which come under the classification of trace-driven attacks, in which the attacker process gets to know which cache sets have been acquired by the victim process. Attackers initiate a spy program to observe cache contention of victim process as shown in Figure 3.1. In the prime step, attacker process fills different cache sets with its own code as shown in Figure 3.1a. Attacker goes into idle state in which it lets the victim program to run and execute its code as described in Figure 3.1b. Whereas, in probe phase, attacker program observes its own filled cache and continues to execute normally. Meanwhile, attacker observes the time to load each set of its data that it already placed in the cache (primed). Some of the cache sets will be evicted from cache and will take long time to fetch, which will be observed by attacker program by latency of fetching that data. By this way, attacker program gets the information of addresses which are sensitive for the victim, described in Figure 3.1c. In Prime+Probe attack technique, victim and attacker do not share their address space by shared libraries. Prime+Probe works on cross-core and same-core exploitation techniques, hence, it is capable of synchronous and asynchoronous attacks which are very powerful in nature.

Prime+Probe attacks are actually harder to perform in LLC than L1 level of cache. It is due to perceptibility of processor-memory activity at LLC [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], difficult to Prime+Probe all LLC [3], [4], [5], [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF], [START_REF] Percival | Cache missing for fun and profit[END_REF], [START_REF] Billy | Cache-Timing Template Attacks[END_REF], [START_REF] Aciicmez | New Results on Instruction Cache Attacks[END_REF], classifying cache sets related to security critical program of victim and probing resolution. Prime+Probe technique [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Percival | Cache missing for fun and profit[END_REF] to perform attacks are usual way of exploiting contemporary set associative cache. This technique has been used to exploit different levels of cache such as L1-data (L1-D) cache [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Percival | Cache missing for fun and profit[END_REF] , L1-instruction (L1-I) cache [START_REF] Aciicmez | A Vulnerability in RSA Implementations Due to Instruction Cache Analysis and Its Demonstration on OpenSSL[END_REF] and Last Level Cache (LLC) [START_REF] Bhanu | Eliminating Fine Grained Timers in Xen[END_REF]. There are many other attacks that are performed by this way [6], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [START_REF] Qian | Contemporary Processors Are Leaky -and There's Nothing You Can Do About It[END_REF], [START_REF] Gruss | Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR[END_REF]. From the understanding of the attack, we analyzed that timing in CPU cycles is very important factor for the attacker which comes from rdtsc instructions. Attacker observes the timing of victim thread before and after execution and compares it with a predetermined

Flush+Reload (F+R) Technique

Flush+Reload [6], is a different mechanism than Prime+Probe and Evict+Time as shown in Figure 3.5 and it falls under the classification of trace-driven attacks, because it relies on presence of page sharing, as shown in Figure 3.5a. To add to the problem of inclusive caches, x86 architecture provides privileged instructions, such as clflush instruction, for flushing the memory lines from all cache levels, including the last level cache (LLC), which proves to be a major threat and core advantage for attacks using Flush+Reload technique. In the first phase of flushing, the attacker flushes (evicts a shared cache line) using Clflush instruction, described in Figure 3.5b. After flushing the cache line, attacker remains in the idle state and lets the victim operate as shown in Figure 3.5d. In the step of Reload, it observes the timing information by reloading the shared cache line as shown in Figure ??. The timing information reveals the interest of victim program. Stealth reload indicates that this cache line was affected by victim and slow reload shows that it was not accessed by the victim. Contemporary x86 architectures have the ability to use Flush+Reload mechanism to measure the time of clflush instruction. The benefit of this technique is that the attacker is able to aim a precise cache line [6], [START_REF] Gruss | Cache Template Attacks: Automating Attacks on Inclusive Last-level Caches[END_REF], [START_REF] Irazoqui | Wait a Minute! A fast, Cross-VM Attack on AES[END_REF], [START_REF] Yarom | Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack[END_REF], [START_REF] Gullasch | Cache Games -Bringing Access-Based Cache Attacks on AES to Practice[END_REF], [START_REF] Garcıéa | Make Sure DSA Signing Exponentiations Really Are Constant-Time[END_REF], [START_REF] Joop Van De Pol | Just a Little Bit More[END_REF], [START_REF] Zhang | Cross-Tenant Side-Channel Attacks in PaaS Clouds[END_REF], [START_REF] Allan | Amplifying Side Channels Through Performance Degradation[END_REF], [START_REF] Benger | Just a Little Bit": A Small Amount of Side Channel Can Go a Long Way[END_REF], [START_REF] Lipp | ARMageddon: Cache Attacks on Mobile Devices[END_REF] instead of whole

Meltdown Attack

Meltdown is a Covert Channel Attack (CCA) which follows the principle of out-of-order execution. For understanding of attack, we first explain the concept of out-of-order execution.

Out-of-order execution

Out-of-order execution is an optimization method used by modern processors to achieve maximum utilization of execution units available in a CPU. In Out-of-order execution, instructions are fetched in compiler generated sequence. But instructions can be executed in order or Out-of-order depending on the data hazards and structural hazards between instructions. Instructions can execute Out-of-order, but they complete in order only [208]. A processor having out-of-order execution functionality does not wait for the instructions to complete their execution in sequential order. Preceding instructions start executing if all necessary operands and functional units are available without waiting for the previous instructions to complete their execution. Meltdown attack exploits this feature of modern processors by using out-of-order memory lookups. prediction units of almost all processors. Branch predictor is used for prediction of conditional branch instruction, indirect branch instructions and return stack buffer. Spectre variants are available for all three types of branch instructions. For condition branches, branch predictor predicts whether a conditional branch, such as if-else instructions, will be taken or not taken. Branch predictor guesses the direction of conditional branch depending on the history of branches. Similarly, branch predictor makes guess for indirect branches and calls [208]. All these branch instructions are exploited by Spectre attack to leak secret information.

Understanding on Spectre Attack

Spectre attack is also a two-step attack. In step one, attacker misstrains the branch predictor of CPU to speculatively execute unprivileged instructions. In second step, it performs cache-based side-channel attack to leak information unauthorized reference memory. Listing 2 shows the code snippet of Spectre variant 1 whereas, Figure 3.16 represents the steps of attack completion. In variant 1 of Spectre attacks, the attacker misstrains the branch predictor unit of CPU's to miss-predicting the direction of conditional branches. Attacker misstrains the CPU's branch Addressing in Look-up Tables [START_REF] Tromer | Efficient Cache Attacks on AES, and Countermeasures[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF] L1-D AES 2010, Preemption of RSA in Minute Intervals [START_REF] Aciicmez | Yet Another MicroArchitectural Attack:: Exploiting I-Cache[END_REF] L1-I RSA 2007

Spy Process Entry in RSA as a routine [START_REF] Aciicmez | New Results on Instruction Cache Attacks[END_REF] L1-I RSA 2010

Symmetric Multi-threading [START_REF] Billy | Cache-Timing Template Attacks[END_REF] L1-D ECDSA 2009

Symmetric Multi-threading [START_REF] Aciicmez | New Results on Instruction Cache Attacks[END_REF] L1-I DSA 2010

Interprocessor Interrupts [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF] L1-I ElGamal 2012

Huge Page [START_REF] Liu | Last-Level Cache Side-Channel Attacks Are Practical[END_REF], [ important point to highlight here is, performance counters are of very significant importance for analysing the program state of the processes which are under execution. Either software or hardware performance counters brief us a lot about the behavior of running processes and performance counters are a new direction of research in security for detection purposes. In this thesis, we provide proof of concept on variable attack techniques of different categories that how performance counters can be useful for detection of several CSCAs. In this thesis, we prove that experiemental set up of different performance counters can reveal a lot about behavior of the system and combinations of these performance counters can be very helpful direction toward security which is a rather new research area.

HPC monitoring tools

Processors based on Intel's x86 architecture [START_REF]Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide[END_REF] provide access to hundreds of hardware events that can reveal valuable information of the system using HPCs but all of them are not read and write-able (programable). The HPCs with access to read/write, however, are limited in number. Therefore, there are few events that can be monitored concurrently (ranging between 4-8 events). There are many high-level libraries and APIs that can be used to configure and read HPCs such as: PerfMon [223], OProfile [224], Perf [START_REF] Carvalho | The new linux perf tools[END_REF], Perftool [225], Intel Vtune Analyzer [226] and PAPI [227] etc. Many detection techniques use HPCs to detect different CSCAs as discussed in detail in Chapter 2. Selection of most appropriate and minimum number of hardware events that could help revealing the attack behavior remains an important capability of detection tools. HPC tools allow the measurement of events at three levels; 1) Coarse-grain measurement, which logs the aggregate occurence of configured events, 2) Snippet-grain measurement, which analyzes events only related to a particular section of program rather than entire program execution and 3) Fine-grain measurement, which samples configured events using an interrupt-based mechanism. Fine-grain measurement can give precise information of anomaly in the program execution but it also can provide heavy performance cost due to interrupting execution at a fine granularity.

Issues and limitations of HPCs

Selected HPCs used as hardware events should be dealt with care while we want to sample them. They can have certain issues in their measurement such as non-determinism, overcounting, multiplexing and lack of portability. In this subsection, we will talk about the problems which can occur while selection and sampling of events.

Non-determinism

Non-deterministic results mean two identical runs of same program with exactly same inputs, may not produce same results of monitored events. Hardware performance counters produce deterministic results when run in a strictly controlled environment [START_REF] Weaver | Can hardware performance counters produce expected, deterministic results[END_REF]. Deterministic results of hardware performance counters also depend on the tools which you use for measurement of results. Non-determinism varies values of hardware performance counters from 1-10% [START_REF] Weaver | Can hardware performance counters produce expected, deterministic results[END_REF]. Only few hardware performance counters can produce deterministic results like retired instruction when measurements are taken with a tool which can remove sources of contaminations from HPCs measurements. Most potentially deterministic events on Intel x86 are affected by the hardware interrupt count [START_REF] Weaver | Can hardware performance counters produce expected, deterministic results[END_REF]. Many important hardware events, such as cache and cycle counts, are not deterministic on modern out-of-order machines. This severely limits the usefulness of events in situations where exact deterministic behavior is necessary. Some sources are; changes in events values due to operating system activity, changes due to context switching, sources of hardware interrupts, cost of measuring hardware performance counters, variations in tools for measurement.

Hardware events like cache accesses, total cycles are non-deterministic on modern out-of-order processors. Therefore, to use hardware performance counters for security applications, we need to find deterministic HPCs from available hundreds of counters. We also need to remove sources of contamination from hardware performance counters during measurement.

Multiplexing issues

Multiplexing allows more counters to be used simultaneously than are physically supported by the hardware. With multiplexing, the physical counters are time-sliced, and the counts are estimated from the measurements. There was concern that naive use of multiplexing could lead to erroneous results that would not be detected by the user. Erroneous results can occur when the runtime is insufficient to permit the estimated counter values to converge to their expected values [START_REF] Dongarra | Experiences and lessons learned with a portable interface to hardware performance counters[END_REF]. [START_REF] Mytkowicz | Time interpolation: So many metrics, so few registers[END_REF] also study the accuracy of performance counter-based measurements. However, their focus is on the accuracy of measurements when the number of events to measure is greater than the number of the available performance counter registers. They compare two "time interpolation" approaches, multiplexing and trace alignment, and evaluate their accuracy. Their work does not address the measurement error caused by any software infrastructure that reads out and virtualizes counter values.

Performance Overhead

The overhead comes from collecting data of hardware performance counters during start/ stop and reading of data. The counter interfaces necessarily introduce overhead in the form of extra instructions, including system calls, and the interfaces cause cache pollution that can change the cache and memory behavior of the monitored application. The cost of processing counter overflow interrupts can be a significant source of overhead in sampling-based profiling.

A lack of hardware support for precisely identifying an event's address may result in incorrect attribution of events to instruction addresses on modern super-scalar, out-of-order processors, thereby making profiling data inaccurate. The PAPI project is concerned with all these possible sources of errors and is addressing them. PAPI is being redesigned to keep its runtime overhead and memory footprint as small as possible. Hardware support for interrupt handling and profiling is being used if possible [START_REF] Dongarra | Experiences and lessons learned with a portable interface to hardware performance counters[END_REF]. Moore [START_REF] Shirley | A comparison of counting and sampling modes of using performance monitoring hardware[END_REF] distinguishes between the accuracy of two distinct performance counter usage models: counting and sampling. The counting accuracy presents the cost for start/stop and for read as the number of cycles on five different platforms: Linux/x86, Linux/IA-64, Cray T3E, IBM POWER3, and MIPS R12K. On Linux/x86, it reports 3524 cycles for start/stop and 1299 for read numbers. Dongarra et al. [START_REF] Dongarra | Experiences and lessons learned with a portable interface to hardware performance counters[END_REF] mention potential sources of inaccuracy in counter measurements. They point out issues such as the extra instructions and system calls required to access counters, and indirect effects like the pollution of caches due to instrumentation code, but they do not present any experimental data. Besides using the libperfex library, Korn et al. [START_REF] Korn | Just how accurate are performance counters?[END_REF] also evaluate the accuracy of the perfex command line tool based on that library. To no surprise, this leads to a huge inaccuracy (over 60000% error in some cases), since the perfex program starts the micro-benchmark as a separate process, and thus includes process startup (e.g. loading and dynamic linking) and shutdown cost in its measurement. We have also conducted measurements using the standalone measurement tools available for our infrastructures (perfex included with perfctr, pfmon of perfmon2, papiex available for PAPI), and found errors of similar magnitude. Since our study focuses on fine-grained measurements we do not include these numbers. Maxwell et al. [START_REF] Maxwell | Accuracy of performance monitoring hardware[END_REF] broaden Kron et al.'s work by including three more platforms: IBM POWER3, Linux/IA-64, and Linux/Pentium3. They do not study how the factors a performance analyst could control (such as the measurement pattern) would affect accuracy. They report on performance metrics such as cycles and cache misses.

Use of HPCs in security

It has been very clear till now that obtaining accurate and reliable counter information can be very important for solving security issues but in parallel it can be tricky if we do not keep into account the above mentioned problems in analysing counters. To lessen the burden on programmers, number of utilities and tools are available to obtain HPC information on variable platforms. As mentioned in Chapter 2 we also analyzed the papers which use HPCs as a new dimension to security. It has been observed that HPC monitoring has been proved very helpful in detection of CSCAs in last 10 years. As it can be seen in Table 3.3, we have gathered papers which take into account rise of HPC in security [START_REF] Das | SoK: The challenges, pitfalls, and perils of using hardware performance counters for security[END_REF]. Table 3.3 lists the papers in security specially related to different SCAs who used HPCs. Whereas, Table 3.3 also explains, the number of papers who acknowledged and addressed about the problems while sampling HPCs (we also listed the specific problem which occured). It can be seen that all of the papers recommended using HPCs as an important artefact of security. We extended our analysis for the use of HPC as a strong parameter for detection of CSCAs because we also tested some of hardware counters for examining the behavior of particular attacks. It can be seen in Figure 3.18 that we tried to observed four hardware events i.e. L3 Instruction Cache Accesses, L1 Instruction Cache Misses, Total Cycles and L3 Total Cache Misses. On Y-axis we observe the frequency and on x-asis we observe the samples of particular events. In Figure 3.18, we observe the execution of behaviors when attacker and victim are the only loads on the system (which is the case of all the literature attacks) while running Flush+Reload attack on RSA. Figure 3.18 shows that green distribution shows the victim behavior when it is not under attack and red dstribution shows the behavior when we are under attack.

Simply by using HPCs, we were able to know the distribution of attack vs no-attack. At this point we were fully convinced to use HPCs as a major artifact for developing detection mechanism for CSCAs. Therefore, we advocate in favor of using HPCs to effectively target the threat of security specially in CSCA and CCAs. HPC determination has a niche in security evaluation and like other domains, it can be helful in detecting different CSCAs of challenging nature. Selection of HPCs as hardware events for developing accurate detecttion mechanism is discussed in detail in the next Chapter 4. In Section 4.3, we will debate about selection of approaprite HPCs related to attack behaviors with in depth experimentation to satisfy the appetite of usage of HPCs in CSCA detection. Here, it is just to showcase by experiments, that HPCs are a useful parameter to detect different sort of behaviors during an attack at run-time.

We established our concept that HPCs are useful to gain behavioral information of different processes and it can be seen in Figure 3.18 that behavior of attack and no-attack is distinguishable by simple threshold determination. If the behavior goes above a certain threshold, it is considered an attack behavior otherwise it is considered a no-attack behavior. But for a detection mechanism to be strong should also work under load conditions which is the realistic scenario of execution. The attack works under isolated conditions, but, for detection mechanism to be effective, it should perform with high detection accuracy under noisy situations too. We analyzed that hardware performance counters behave differently when noise is introduced as shown in Figure 3.19. It can be seen that attack and no-attack distribution is quite overlapping due to injecting noise which is the realistic execution scenario. Detailed experimentation on HPCs with noisy and isolated conditions with different attack scenarios is explained in Chapter 4. For understanding such behaviors, we need to develop intelligent and efficient detection mechanism which can rely on understanding mixed behaviors. 6 Payer [ Mushtaq et al. [START_REF] Mushtaq | NIGHTs-WATCH: a cache-based side-channel intrusion detector using hardware performance counters[END_REF], [START_REF] Mushtaq | Run-time Detection of Prime+ Probe Side-Channel Attack on AES Encryption Algorithm[END_REF], [START_REF] Mushtaq | Machine Learning For Security: The Case of Side-Channel Attack Detection at Run-time[END_REF], [START_REF] Mushtaq | Sherlock Holmes of Cache Side-Channel Attacks in Intel's x86 Architecture[END_REF] No No Yes

For that, we built an argument that Machine Learning can be helpful to train such mixed behaviors and provide us with good classification decisions. For that cause we see ML as a new dimension to security and we try to analyze what type of models exist in literature and what are the limitations of using ML. Details on selection of ML models into our methodology will be explained in Chapter 4 Section 4.4.

Use of ML in security

Machine Learning has been very helpful in many areas like Deep Learning [START_REF] Goodfellow | Deep learning[END_REF], Game Theory [243] and Fuzzy Logic [START_REF] Yen | Fuzzy logic: intelligence, control, and information[END_REF], [START_REF] Javaid | A deep learning approach for network intrusion detection system[END_REF]. In the recent past, it can be seen that ML is used in security domains too e.g. malware and intrusion detection: [START_REF] Javaid | A deep learning approach for network intrusion detection system[END_REF], [START_REF] Saxe | Deep neural network based malware detection using two dimensional binary program features[END_REF], [START_REF] Yuan | Droid-sec: deep learning in android malware detection[END_REF], [START_REF] Alpcan | A game theoretic approach to decision and analysis in network intrusion detection[END_REF], [START_REF] Kodialam | Detecting network intrusions via sampling: a game theoretic approach[END_REF], [START_REF] Gomez | Evolving fuzzy classifiers for intrusion detection[END_REF], [START_REF] Bridges | Fuzzy data mining and genetic algorithms applied to intrusion detection[END_REF], [START_REF] Huang | Applying FML and fuzzy ontologies to malware behavioural analysis[END_REF]. We have discussed in Chapter 2 that ML is playing vital role in detection of CSCAs [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF], [START_REF] Bazm | Cache-Based Side-Channel Attacks Detection through Intel Cache Monitoring Technology and Hardware Performance Counters[END_REF], [START_REF] Mushtaq | NIGHTs-WATCH: a cache-based side-channel intrusion detector using hardware performance counters[END_REF], [START_REF] Mushtaq | Run-time Detection of Prime+ Probe Side-Channel Attack on AES Encryption Algorithm[END_REF], [START_REF] Allaf | A Comparison Study on Flush+Reload and Prime+Probe Attacks on AES Using Machine Learning Approachess[END_REF], [START_REF] Alam | Performance Counters to Rescue: A Machine Learning based safeguard against Micro-architectural Side-Channel-Attacks[END_REF], [START_REF] Demme | On the feasibility of online malware detection with performance counters[END_REF], [START_REF] Allaf | ConfMVM: A Hardware-Assisted Model to Confine Malicious VMs[END_REF], [START_REF] Payer | HexPADS: a platform to detect "stealth" attacks[END_REF], [START_REF] Cover | Nearest neighbor pattern classification[END_REF], [START_REF] Quinlan | Induction of decision trees[END_REF], [START_REF] Lippmann | An introduction to computing with neural nets[END_REF], [START_REF] Mushtaq | Machine Learning For Security: The Case of Side-Channel Attack Detection at Run-time[END_REF]. We believe that a lot of concepts from the field of malware and intrusion detection can be borrowed to solve the problem of CSCA detection. The field of malware detection seems to have more maturity, therefore, a lot of research ideas [START_REF] Khaled | Ensemble learning for low-level hardware-supported malware detection[END_REF], [START_REF] Ozsoy | Hardware-Based Malware Detection Using Low-Level Architectural Features[END_REF], [START_REF] Patel | Analyzing hardware based malware detectors[END_REF], [START_REF] Khaled | EnsembleHMD: Accurate Hardware Malware Detectors with Specialized Ensemble Classifiers[END_REF] can be adopted for the case of CSCA and CCA detection. We observed (Chapter 2, Table 2.2) that almost 50% of the reviewed research works utilize machine learning classifiers to detect CSCAs. Most of these works use multiple machine learning models. Therefore, it would be interesting to explore the use of mutiple attacks learning techniques to combine various classifiers and observe the impact on the overall detection results. On the basis of past researches, we

Nearest Centroid Model

A parametric supervised classifier used in Machine Learning. It calculates the distance of the new input data point from the mean of the training data of each class and then assign the label to the new input data point of the class whose calculated distance was smallest.

Naive Bayes Model

Naive Bayes is a probabilistic supervised Machine Learning algorithm having a strong assumption that the features are independent of each other. It calculates the probability of an incoming data point given each class. New data point gets the label of the class whose probability is greater. In real life scenarios features are not completely independent, this can affect the performance of Naive Bayes Model.

Perceptron Model

Perceptron is like the neuron in human brain. It is a linear supervised Machine learning approach, represents the simplest neural network. It learns some weights for each feature from the training data and then predicts the class of the new incoming data point by calculating the weighted sum of these features. It works better on the linearly separable data set

Decision Tree Model

A decision tree is a tree like model of decisions and their possible consequences. It is one of the model that contains conditional control statements. Decision trees mainly help in decision analysis to carve a strategy to reach a goal. It is one of the popular machine learning algorithms.

Dummy Model

It is a naive approach which can be used for classification. It assigns the label of the most frequent class to the new input data

Neural Network Model

Neural Network is inspired by human brain Neural Networks also known as multilayer perceptron are composed of multiple perceptron hidden layers. For error reduction there is feed forward and backward propagation technique. Over-fitting problem can occur in neural networks due to the backward propagation.

Issues and Limitations of ML

ML offers many classifiers to classify the training data, but it is very important to understand the intelligence behind the ML model and perceive, if the selected model can be used for classification of particular attack or combination of attacks. Regarding using ML as a parameter for security, it is important to understand limitations of ML while using them to detect certain CSCAs & CCAs. Selection of ML model is based on a rationale of two main parameters; the model should achieve high accuracy and provide less implementation complexity which renders less performance cost. As we know CSCAs are very stealth in nature and take microseconds to execute. The detection mechanism using ML classifiers should be able to perform early stage detection (before the completion of attack) followed by mitigation mechanism to act before the attack retrieves the victim's confidential information. Under the constraints such as; real-time requirements, early-stage detection, and minimal performance overhead, the domain of CSCA and CCA detection becomes particularly challenging and interesting application domain for Machine Learning. So ML classifier should be precise in detection accuracy (provides accurate and fast decision) which incurs minimum implementation complexity of the classifier. These two parameters for selection of ML classifier are detailed below. Detection accuracy is the primary indicator for judging the effectiveness of any detection mechanism using ML. Detection accuracy shows the percentage of goodness by which the ML model has been trained and how much wisely it creates its feature vector space (classes) and finally provides us the accurate classification decision. We use percentage accuracy or other metrics like precision or F-score, to show the validity of trained machine learning models. It is important to choose the models carefuly which provide high detection accuracy to detect such stealth and high resolution attacks. If a ML model is unable to train itself well, it provides low accuracy in its decisions and ultimately provides with miss-classified decisions. To utilize ML in security, we should know the problem (attack) and we should know the characteristics and classification method of that model (how it defines its feature space and classifies the decision).

Performance Overhead

Performance overhead of ML model inside a detection mechanism becomes a particularly important design parameter in case of run-time detection. Moreover, the adaptability and scalability of mechanism also depends on its run-time performance overhead. It is important that ML model has low implementation complexibility. ML model should be chosen with great care so that it is light in implementation and easy to be embeded inside detection module. Models which explode in tree based nature, or perform a lot of forward and backward tracing, do conditional statements, take into account a lot of training data points, on one side they are very good in decision making and detection accuracy, but, on the other side they cost in terms of implementation complexity. So, there is need to select models which are balanced in terms of detection accuracy and performance overhead. Selection of ML models are also discussed in detail in the next Chapter 4.

Summary

In this chapter, we have practically demonstrated the attacks which are exploiting entire computation stack while exploiting resource sharing in Intel x86. CSCAs have targeted all the hierarchy of caches including L1, L2 and LLC. Later on, recent attacks like Spectre and Meltdown have effected the speculative execution and tried to exploit the program access in kernel space too. It is evident that all these attacks are very powerful and stealth. On the defense side, it is very hard to detect and mitigate such attacks keeping in mind their stealth nature when attack takes some microseconds to perform. The current need is to provide mechanisms which provide system wide security without changing the cache architecture which is designed for optimization and performance purposes. Later on, in this chapter, we have analyzed that use of HPCs and ML is a rather new direction in security. We advocate in favor of using HPCs and ML to detect and mitigate attacks. Their advantages and cautions to utilize them are also discussed in this chapter. We also briefly explained by experiemental results that how HPCs can be used as first building brick toward detection mechanism and why we need to use Machine Learning to better classify our complex problem of detection of CSCAs and CCAs. From here, in the next chapter, we will explain our proposed detection mechanism while using HPCs and ML. The agenda is to propose a detection tool which is able to detect a bigger class of attacks while achieving high detection accuracy, high detection speed, lower miss-classification and perforamance overhead. We also will prove the experiments on different CSCAs and CCAs in the two next coming chapters.

Publications related to this chapter

Our main contribution of this chapter, discussed in Sections 3.1.1 is given below:

Introduction

Intel's x86 architecture has been exposed to high resolution and stealthy cache-based sidechannel attacks (CSCAs) over past few years. In this chapter, we present a novel technique to detect CSCAs on Intel's x86 architecture. The chapter is divided into two main parts; the first part of chapter deals with single attack technique and its run-time detection, whereas, the second part of chapter demonstrates results on multiple attacks handled under one tool to perform fast and accurate detection of 6 major CSCAs of state-of-the-art. The proposed technique comprises of multiple machine learning models that use real-time behavioral data of concurrent processes collected through Hardware Performance Counters (HPCs). In this work, we demonstrate that machine learning models, when coupled with intelligent performance monitoring of concurrent processes at hardware-level, can be used in security for early-stage detection of high precision and stealthier CSCAs. We provide extensive experiments with 6 variants of the state-of-the-art CSCAs. We demonstrate that our proposed technique is resilient to noise generated by the system under various loads. To do so, we provide results under realistic system load conditions with an evaluation metric comprising of detection accuracy, speed, system-wide performance overhead and confusion matrix for machine learning models. In experiments, our technique achieves high detection accuracy for attacks running under different cryptosystems.

NIGHTs-WATCH: A run-time detection mechanism for single CSCA

This section presents the proposed detection mechanism for all attacks. Intrusion detection is a problem of identifying data patterns that do not confirm with the expected (normal) system behavior. Detection mechanisms therefore apply a huge amount of effort in learning the expected system behavior first. Proposed detection mechanism does this learning by profiling target cryptosystems (RSA & AES in our case and attacks which do not consider crypto systems) using carefully selected hardware events described in Section 4.3. Since detection mechanisms can only approximate the system behavior, they can be inaccurate and lead to false positives or false negatives at run-time. Moreover, they can also slowdown program execution due to detection overhead. We use all these parameters as evaluation metrics for proposed detection mechanism. We first describe our system model, followed by the detailed methodology.

System Model

We have performed our proposed detection mechanism on Linux Ubuntu 16.04.1 with kernel 4.13.0 -37 running on Intel's core i7 -4770 CPU at 3.40-GHz. We validate our detection mechanism on access driven CSCAs which are the major threats for information leakage in cache hierarchy of Intel's architecture. In our detection mechanism, threat model is same-core and cross-core SCAs. It assumed that operating system is not compromised. Information of hardware events can be retrieved by high-level software libraries/APIs such as; PerfMon, OProfile, Perf tool, Intel Vtune Analyzer and PAPI. We have used PAPI (Performance Application Programming Interface) [227] library to access HPCs on Intel Core i7 machine. Section 4.3 provides details on selection of hardware events using PAPI libraries for our selected machine learning models (described in Section 4.4).

In each case study, we evaluate the performance of ML models using performance counters under realistic system load conditions. To do so, we vary the system load from No Load (NL), Average Load (AL), to Full Load (FL) conditions by using selected SPEC benchmarks [85] that offer memory-intensive computations such as; gobmk, mcf , omnetpp, and xalancbmk, to run in the background. A NL condition involves only Victim and Attacker processes running, an AL condition involves at least two SPEC benchmarks running along with Victim & Attacker processes, and a FL condition involves at least four SPEC benchmarks running along with Victim & Attacker processes.

Methodology

An abstract representation of our proposed detection mechanism with four individual machine learning models, namely: LDA, LR, SVM and QDA, is given in Figure 5.2. We consider shared memory architecture as most of the known CSCAs target Intel's x86 based execution platforms. There are three significant steps of our detection mechanism, namely, Training of machine learning models, Run-time profiling and Classification & detection. In the following, we explain each step in detail.

Training of machine learning models

We collected training data of nearly 1-Million samples from attack & no-attack execution scenarios using variable load conditions for RSA and AES crutosystem, which helped us to train our machine learning models with this classified data. Our training data contains equal number of samples of both attack and no-attack scenarios. In our training data we feed our ML model by samples of attack and no-attack execution. To further create a realistic scenario, we classified the training data of attack and no-attack with three different load 4.2 NIGHTs-WATCH: A run-time detection mechanism for single CSCA | 91 conditions using SPEC benchmarks as explained in Section 4.2.1. Sample size of 1-Million for attack and no-attack scenarios is sufficient enough to learn the small variations in victim's behavior. We have to apply training process once so that ML models learn the behavior of attack by every possible execution scenario (realistic load conditions). Once the attack behavior is learned, it takes hardware events at run-time and detects attack on the go. For validation purposes, we applied K-fold cross validation technique [START_REF] Bishop | Pattern Recognition and Machine Learning[END_REF] for all the models on the training data to verify them before application on run-time detection. K-fold is a validation procedure in which original samples are randomly partitioned into K equal sized sub-samples (Number of K is equal to the equally divided sub-samples) where, 1 sub-sample is retained as the validation data for testing the model and remaining K -1 sub-samples are used for training.

Run-time Profiling

In the second phase, our detection mechanism collects run-time samples from the selected hardware events. Sampling granularity (collecting samples of victim's execution) has a major influence on victim execution in terms of performance because it varies the performance of victim process and its shared libraries in comparison to the normal execution. Furthermore, sampling granularity should be effective enough otherwise, it affects the detection speed and its percentage of accuracy which is an important factor for real-time detection. Our detection mechanism collects run-time samples of hardware events by offering fine-grained and coarse-grained profiling modes. We considered a fine-grained sampling after 10 encryptions and coarse-grained sampling after 50-100 encryptions of attack. In our case study, we had one encryption attack too. For one encryption attack, we did fine-grained sampling at 10 secret bits and coarse-grained sampling at 50 bits of secret key. In fact, these two modes of profiling offer a trade-off between performance and the speed of detection. For instance, in fine-grained mode, samples from hardware events are collected at a higher frequency, which subsequently leads to an early-stage detection of attacks but at an increased performance overhead because we are sampling the hardware events after a predetermined number of iterations. In coarsegrain profiling mode, the data samples are taken at a low frequency, which takes longer time in detecting attacks. In this mode, however, the performance overhead is minimal as the data samples from hardware events are collected less frequently. Our detection mechanism demonstrates successful detection in both cases, i.e., before the completion of attack.

In reality the attacker and victim are synchronised with each other or attacker is sharing the encryption library which the victim is using. We have embedded our trained machine learning models into the victim code which is performing encryption. The trained machine learning models, chosen on the basis of low implementation complexity, are a formula like representation which is embedded inside the victim code. We pre-defined the frequency at Since the scope of this work is limited to detection of access-driven CSCAs, therefore, we consider only the events that are plausibly affected by these attacks. The PAPI library offers 100+ events for Intel's Core i7 systems. In order to select the most relevant hardware events, we did experiments on a larger set of 12 most relevant events, presented in Table 4.1, in order to observe the impact of target computational loads, i.e., crypto-operations and attacks. Using these events, we collect a system-wide profile for both benign and malicious processes while running state-of-the-art CSCAs on Intel's x86 architecture. Out of these 12 events, only a subset of 4 -5 events prove to be sufficient as features for our ML models. Thus, we can discard the redundant features and save run-time overheads. We select these events based on three important factors: 1) Their relevance to attacks 2) Their potential to provide better classification 3) Selection of minimum possible counters to make detection overhead minimum. Below in this section, we elaborate which features offer what kind of information and why they are being used for a particular attack.

Selected hardware events for Flush+Reload attack on RSA

.2 shows experimental results of selected hardware events that measure Branch Miss-Predictions (BR_MSP), Total execution Cycles (TOT_CYC), L1 Instruction Cache Misses (L1-ICM), and L3 Instruction Cache Accesses (L3-ICA) for 15,000 encryptions of RSA cryptosystem. We have also experimented the tests considering L3-Total Cache Miss (L3-TCM). At a time, we tested 4 hardware events on 4 physical registers due to the reason of multiplexing and avoiding performance costs. The figure shows frequency of samples on y-axis and magnitude of measured events on x-axis. Results shown in green represent normal behavior of RSA encryptions running under No-Attack while results in red show RSA under Flush+Reload Attack. Figure 4.2 clearly shows that the magnitude of events significantly increases under attack conditions compared to normal behavior. Since Flush+Reload attack on RSA is based on Flush and Reload step of instructions in caches, that is why the magnitude of instruction cache miss largely deviates and there is clear distinction of attacking and nonattacking behavior. Thus the events are affected by attack and reveal interesting information, which could be used by the ML for run-time detection.

Selected hardware events for Flush+Reload and Flush+Flush attack on AES

The set of events that we have tested for Flush+Reload and Flush+Flush on AES includes total cache accesses and misses for all levels of caches such as: L1 data cache misses (L1-DCM), L1 instruction cache misses (L1-ICM), L3 total cache misses (L3-TCM) etc. and other pipeline events like total execution cycles (TOT_CYC). Using these events, we collect a system-wide profile for both benign and malicious processes while running state-of-the-art classification patch should be reasonable. On analyzing the short-listed machine learning models on the basis of accuracy, we find that two of those models i.e. Decision Tree and Random Forest would not be easy to implement at run-time due to their tree-based nature. We observed that, based on our experiments, the decision trees/random forest that show good accuracy for our classification problem, also have high depth and a high number of branches. Not only that it makes their embedding into cryptosystem difficult, it can also result into high performance overhead due to a high number of ifelse blocks needed to implement them. KNN also shows good classification accuracy for both attacks. However, KNN uses all training data points at run-time to infer a classification decision, which can result into high performance and storage overhead. Since better training would require more data points, KNN leads to a performance vs accuracy trade-off. Out of the remaining machine learning models, since QDA (non-linear) and LDA (linear) are based on Naive Bayes, Naive Bayes can be left out in favor of LDA and QDA. This leaves us with LDA, LR, SVM and QDA as better candidates for use in detection of CSCAs.

Experiments and Discussion

In this section, we explain that how machine learning and hardware performance counters can be useful to perform detection of stealth and high resolution attacks as mentioned in our use-cases (Chapter 3, Table 3.1). We present half key implementations of attacks as Impl1 and full key implementations as Impl2. In this section, we use the selected HPCs and selected models for the detection of one attack technique at a time. Every attack needs to be trained offline atleast once for the said vulnerability to make detection module work on that particular attack.

Case Study-I: Detecting Flush+Reload on RSA

Our first case study presents experimental results on the detection of Flush+Reload attack working under RSA cryptosystem. In this section, we present the results of our proposed detection mechanism NIGHTs-WATCH [START_REF] Mushtaq | NIGHTs-WATCH: a cache-based side-channel intrusion detector using hardware performance counters[END_REF] whic detects Flush+Reload technique running on RSA cryptosystem at an early stage of attack execution.

Detection Accuracy

Detection accuracy is one of the primary indicators for evaluating a SCA detection framework. We use percentage accuracy to show the validity of trained machine learning models as we have used the same number of no-attack and attack samples in the training and validation data (i.e. attack and no-attack samples are not biased). Results in Table 4.3 show the achieved accuracy of the selected machine learning models. All four machine learning models show very high and consistent accuracy under all load conditions. Even under FL condition, the accuracy of LDA, LR and QDA stays above 99% while SVM shows above 95% accuracy.

For LDA and LR, it goes up to 99.51%, for SVM, it goes to 98.82% and for QDA it is 99.4%. Under ML conditions, the accuracy remains consistent for LDA and LR as in NL belong to FPs, which can be considered less dangerous than FNs. In case of SVM, the behavior is different, exhibits more FN compared to FP under NL and FL conditions.

Performance Overhead

Performance degradation is another key aspect to judge the applicability of detection mechanisms in real-time systems. In Section 4.5.4.2, it has been discussed that the detection granularity defines how efficiently the detection mechanism profiles hardware events and makes detection decisions which influence the performance of victim processes. Our proposed detection mechanism incurs 1 -2% performance degradation to the victim process while run-time profiling and detection mechanism is active. These results are achieved with the highest sampling frequency of performance events. With the reduced sampling frequency, the performance overhead can be further reduced.

Case Study-II: Detecting Flush+Reload on AES

Our next case study is on the detection of Flush+Reload attack on AES cryptosystem. We extended Nights-WATCH for the detection of Flush+Reload attack [START_REF] Mushtaq | Sherlock Holmes of Cache Side-Channel Attacks in Intel's x86 Architecture[END_REF] running on a different cryptosystem such as AES and evaluated that our detection mechanism is capable to do run-time detection at an early stage.

Detection Accuracy

Table 4.4 shows the achieved accuracy of machine learning models under different system conditions for Flush+Reload attack with AES. Under NL condition all models are able to show very high accuracy (above 99%). The accuracy decreases as system load is increased. However, LR and SVM are still able to show above 96% accuracy under FL conditions. Figures 4.13 and 4.14 show the distribution of hardware performance counters used for detection under attack and no-attack cases for NL and FL conditions respectively. One interesting behavior shown in Table 4.4 is that the machine learning models show the least accuracy on Medium Load conditions rather than FL conditions.

Detection Speed

The implementation of Flush+Reload on AES by Irazoqui et al [START_REF] Irazoqui | Wait a Minute! A fast, Cross-VM Attack on AES[END_REF] that we have used in our work is very fast. The experimental results by Irazoqui et al [START_REF] Irazoqui | Wait a Minute! A fast, Cross-VM Attack on AES[END_REF] indicate that the detection would only be useful if it is done before 50 encryptions of AES. For Flush+Reload attack on AES [START_REF] Irazoqui | Wait a Minute! A fast, Cross-VM Attack on AES[END_REF], we sample performance counters after every 10 encryptions. Here, the detection speed is defined in terms of encryptions by which the attack is detected taken as a percentage

Confusion Matrix

Table 4.4 shows the distribution of inaccuracy shown by all machine learning models into false positives and false negatives while detecting Flush+Reload attack on AES. It can be observed that for almost all cases, the majority of the inaccuracies shown by all machine learning models fall into the category of false positives. A few cases where majority of miss-classifications are false negatives have very high overall accuracy and therefore would have very low number of false negatives and false positives.

Performance Overhead

The performance overhead of run-time detection for all machine learning models is shown in Table 4.4. LDA and QDA models show slightly high overhead, while the other two models exhibit a reasonable performance overhead. The primary reason for a relatively high overhead for detection of Flush+Reload attack on AES is high resolution sampling of performance counters which is necessary to detect Flush+Reload attack on AES before significant security degradation occurs (i.e. before 50 encryptions).

Case Study-III: Detecting Flush+Flush on AES

Most of the existing CSCA research works have not experimented with the attacks like Flush+Flush due to its stealth and non-detectable nature. According to [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF], it is virtually impossible to detect the thread responsible for Flush+Flush attack due to absence of any abnormality in cache misses and hits for the attacker process. However, this does not stop from detecting the presence of a Flush+Flush attack as victim process results into more cache misses and accesses because of high speed flushing from the attacker process. Flush+Flush is a high-resolution and fast attack and is considered stealthier in comparison to Flush+Reload attack as it does not make any memory accesses unlike other attacks. The identification of an attack is the primary job of any detection mechanism, so even if the attacker itself is not identified, other preventive measures can be taken to protect the entire system. We have demonstrated the results of Flush+Flush attack on two implementations; the half key retrieval (Impl1) and full key retrieval (Impl2). The next extension of our work was to extend our detection module toward stealth and non-detectable attacks of the state-of-the-art i.e. Flush+Flush. We demonstrated that our detection module works efficiently for runtime detection of both variants of Flush+Flush attack technique. The first ever detection mechanism we proposed for Flush+Flush attack is named as Sherlock Holmes of CSCAs in Intel x86 [START_REF] Mushtaq | Sherlock Holmes of Cache Side-Channel Attacks in Intel's x86 Architecture[END_REF].

Detection Accuracy

Tables 4.5 and 4.6 show the detection accuracy of all machine learning models for Flush+Flush Impl1 and Flush+Flush Impl2 of Flush+Flush attack. LDA and QDA show very high accuracy under all load conditions for detection of Flush+Flush Impl1 of Flush+Flush attack on AES. The high inaccuracy of LR and SVM models under FL conditions can be explained with the help of Figure 4.16, which shows the behavior of used hardware performance counters under attack and no-attack for FL conditions. Under NL condition, most of the features show distinguishable behavior while under attack and no-attack scenarios. However, In case of FL condition, it is evident that all the features start to overlap under attack and no-attack scenarios as shown in Figure 4.16. This behavior is in contrast to Flush+Reload attack where there were at-least a few features that showed distinguishable behavior under FL as shown in Figure 4.14. This behavior of overlapping features makes it harder for machine learning models to properly discern attack scenario from no-attack scenario. However, it is interesting to see that the LDA and QDA models are still able to show good accuracy in case of FL condition (95.20%). Similar kind of results are observed for Flush+Flush LDA shows high detection speed. Under FL condition, all the other machine learning models are showing very low detection speed (greater than 100%), to the extent that the detection will be performed after first 400 encryptions are done. Failing to detect SCAs in such cases can be avoided by using multiple machine learning models in parallel and performing an 'OR' of their individual decisions.

Confusion Matrix

Tables 4.5 and 4.6 show breakdown of miss-classifications of all machine learning models into FPs and FNs while detecting both implementations of Flush+Flush attack on AES. For first implementation (Impl1) of Flush+Flush on AES, for most of the cases the majority of mispredictions falls into FPs. A few cases (SVM and LR under NL) where majority of errors falls into false negatives category, have very high accuracy and the actual number of false negatives and positives for them is very low. Similar is the case for the second implementation (Impl2) of Flush+Flush attack on AES where most of the miss-classifications belong to FNs category.

Performance Overhead

All four machine learning models incur small profiling and detection overhead for both implementations of Flush+Flush attack as shown in Tables 4.5 and 4.6. Flush+Flush Impl1 in Table 4.5 shows maximum overhead of 1.18 in the case of LDA while, Flush+Flush Impl2 in Table 4.6 shows degradation of maximum 4.5% in case of QDA, which is still reasonable. This performance overhead can be further reduced by sampling of hardware events at a lower frequency. However, this can lead to delayed detection of the attack.

Case Study-VI: Detecting Prime+Probe on AES

This section deals with detection of two implementations of Prime+Probe attack on AES cryptosystem; half key retrieval (Impl1) and Full key retrieval (Impl2). The later extension of our work was to cover the bigger class of CSCAs which do not rely in attacker and victim sharing the same libraries. It was a rather difficult attack and we demonstrated that we are able to detect different variants of Prime+Probe attack technique efficiently [START_REF] Mushtaq | Run-time Detection of Prime+ Probe Side-Channel Attack on AES Encryption Algorithm[END_REF].

Detection Accuracy

Detection accuracy is the most important indicator to assess a CSCA detection mechanism. We use unbiased training data with equal number of attack and no-attack samples.

Detection Speed

Detection speed usually depends on the sampling resolution of detection mechanism. This resolution also impacts the performance overhead. In order to reliably estimate upper 4-bits of a secret key byte, Prime+Probe attack needs at least 4800 AES encryptions [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. Therefore, the detection of Prime+Probe would be useful only if it is achieved before completion of 4800 encryptions. Here, we define the detection speed as number of encryptions needed to detect the attack, taken as a percentage of 4800 encryptions (i.e., the upper bound). For instance, a detection speed of 2.1% would mean that detection is achieved within first 100 encryptions. Table 4.7 shows the run-time detection speed achieved by all ML models while detecting Prime+Probe Impl1. Our ML models are able to detect the attack within first 100 encryptions, which is well ahead of 4800 AES encryptions under all load conditions.

2. We demonstrate that the proposed tool is capable of detecting a large set of CSCAs with reasonably high detection accuracy, high detection speed, low performance overhead and minimal false positives and negatives. WHISPER presents experimental evaluation of at least 6 variants of the state-of-the-art CSCA implementations, i.e., Flush+Reload, Flush+Flush and Prime+Probe attacks. 3. We demonstrate that WHISPER tool is resilient to noise generated by the system under various loads. To do so, we provide results under realistic system load conditions, i.e., under No Load (NL), Average Load (AL) and Full Load (FL) conditions. These load conditions are achieved by concurrently running memory-intensive SPEC benchmarks on the system along with the cryptosystem and attacks. We demonstrate the portability of our proposed tool on existing computing platforms through these results. 4. We provide thorough discussion, supported with experimental data, about the selection of appropriate machine learning models and hardware events for run-time detection of collective CSCAs. Based on these results, the proposed tool can also be used for unknown CSCAs.

There are three potential challenges that we have addressed in designing WHISPER tool: 1) Detection tools usually approximate the overall system behavior and it can lead to greater number of false positives and false negatives at run-time, 2) Detection process can slow down the overall execution for the cryptosystem, which can lead to significant performance overhead while trying to achieve greater detection accuracy and 3) Detection speed can sometimes be very low, which leads to late detection in the sense that the attacker has already completed upto 50% of its activity, for instance, secret key retrieval. In literature, this is considered as a theoretical bound sufficient for a successful attack [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF]. We have considered all these design challenges as our evaluation metrics for the WHISPER tool.

The tool has two major components: 1) Selection of appropriate hardware events that will reveal, at run-time, an insight into the cache behavior while CSCAs take place and 2) Selection of appropriate machine learning methods that could perform binary classification of Attack vs No-Attack scenarios with high accuracy, high speed and minimum performance overhead. This section elaborates the methodology of WHISPER tool and selection criteria for these two aforementioned components. 4.23, the tool collects behavioral data of concurrent processes at run-time using HPCs similar to the NIGHTs-WATCH. These data comprise of selected hardware events, as discussed in Section 4.7 for WHISPER tool, which are fed to an Ensemble machine learning model. The Ensemble is composed of multiple machine learning models that take these data as features to perform binary classification. A majority vote is then taken on the individual decisions of selected machine learning models to decide whether the system is under attack or not.

Methodology

The methodology for WHISPER tool also consists of the same distinct phases as used in NIGHTs-WATCH, namely; 1) Run-time profiling, 2) Training of machine learning models and 3) Classification & detection, with a few exceptions mentioned in the following. The first exception is in the training phase of machine learning models. For WHISPER tool, we collected training data of nearly 1-Million samples from attack & no-attack execution scenarios using variable load conditions. However, in this case, our training data contains equal number of samples of both attack and no-attack scenarios for all use-case attacks combined, i.e., the labels with attack scenario contain a mix of all attacks. The second exception is in the classification & detection phase, in which, the trained individual classifiers in the tool utilize run-time data coming from hardware events for classification and detection purpose. On the basis of training in the second phase, every model classifies the run-time data into two categories: Attack or No-Attack. A majority vote is then taken by the Ensemble model on the individual decisions of selected machine learning models to decide whether the system is under attack or not. Thus, no individual model takes the classification decision, which helps greatly improve the detection accuracy.

Selection of HPCs for WHISPER tool

There are many hardware events that provide valuable information regarding normal vs abnormal behavior of running processes. For instance, Figure 4.24 shows some experimental results of selected hardware events that measure system-wide Branch Miss-Prediction (BR_MSP), L1-Data Cache Misses (L1-DCM), L2-Total Cache Accesses (L2-TCA) and L3-Total Cache Accesses (L3-TCM) for 100, 000 encryptions of AES cryptosystem. Figure 4.24 shows the frequency of samples on Y-axis and the magnitude of measured events on X-axis. Figure 4.24 shows that the magnitude of these events particularly varies (increases in this case) under attack situation compared to no-attack (normal) situation, indicating that the events are particulary affected during the attack. Our detailed experiments with other cache-related hardware events show that they reveal very interesting information about CSCAs.

Since we target access driven CSCAs, we consider only hardware events that are most affected by these attacks. We did experimentation on a larger set of hardware events, a part of it has been presented in Figure 4.24, and selected 12 most significant events as shown in Table 4.1. Another important challenge in using hardware events is that the underlying HPCs are limited in number and the events would require multiplexing. When multiplexed, these hardware events often lose precision. Moreover, they incur significantly large performance , the magnitude of hardware events provide clear distinction between attack vs no-attack scenarios. Since load conditions are important to emulate a more realistic run-time execution scenario, therefore, we have tested these events under Average and Full Load conditions as well. Under the load conditions, however, the events start having overlap between attack and no-attack scenarios due to increased interference with caches, which is generated by the benchmark applications running in the background. For instance, Figure 4.28 illustrates the case of Flush+Flush attack on AES under FL conditions. All hardware events, except L3_Total Cache Misses (L3_TCM), show a significant overlap that makes it difficult to distinguish the attack from no-attack scenario using mere threshold-based analysis. We observed similar effect of load conditions on hardware events for other attacks.

Experiments and Discussion

We evaluate WHISPER tool under stringent design constraints comprising of detection accuracy, detection speed, performance overhead and distribution of error. To do so, we create three experimental case studies to detect Prime+Probe, Flush+Reload and Flush+Flush attacks, respectively, on AES cryptosystem. In each case, we evaluate the performance of our tool under variable load conditions as explained earlier, whereas, all the experimental setup and system model also remain the same as explained in Section 4.2.1.

Case Study-I: Detecting Prime+Probe

Our first case study provides experimental evaluation on the detection of two implementations of Prime+Probe attack targeting AES cryptosystem.

Detection Accuracy

Detection accuracy is the primary indicator for judging the effectiveness of any detection tool. For all case studies, we use percentage accuracy, instead of other metrics like precision or F-score, to show the validity of trained machine learning models. We use unbiased samples in the training and validation data, i.e., samples for attack and non-attack cases are equal.

Tables 4.10 & 4.11 show our experimental results for individual ML models (RF, DT, SVM) and Ensemble, respectively, for two different implementations of Prime+Probe attack. These results illustrate the variation in aforementioned parameters under different load conditions. All three ML models individually provide very high and consistent detection accuracy under NL, AL and FL conditions, i.e., between 92.67-99.99% for Impl1 (Table 4.10) and between 97.73-99.99% for Impl2 (Table 4.11). Evidently, the Ensemble model used by WHISPER tool also performs very well and provides a detection accuracy ranging between 97.62-99.99% for Impl1 (Table 4.10) and 96.94-99.77% for Impl2 (Table 4.11), respectively. The results of Ensemble model are particularly interesting under AL and FL conditions where individual models might not always perform consistent. To support these results, we also provide the run-time behavior of hardware events under different load conditions. For instance, Figure 4.39 shows the behavior of hardware events for Prime+Probe attack Impl1 under FL condition and Figure 4.26 shows the same events for Prime+Probe attack Impl2 under NL condition. Figures 4.26 & 4.39 illustrate that, under Prime+Probe attack, the hardware events offer distinguishable behavior for attack and no-attack scenarios under all load conditions, which is why the detection accuracy for all ML models remains very high.

Detection Speed

Detection speed in another important criterion for the evaluation of any run-time intrusion detection tool. Detection speed is an indirect reflection of how aggressively a detection tool profiles the victim process' behavior (through hardware events in this case) and provides its decision. Detection speed also affects the resultant performance overhead of the tool as it is a trade-off between how fast an intrusion can be detected versus how much overhead detection process would cost. According to literature, Prime+Probe attack would require AES cryptosystem to perform atleast 4, 800 encryptions for Impl1 and 50, 000 encryptions for Impl2 [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF], [START_REF] Irazoqui | Wait a minute! A fast, Cross-VM attack on AES[END_REF] in order to be successful. Therefore, the percentage of encryptions being performed before WHISPER tool raises a flag, defines the detection speed with respect to attack completion. For instance, for Prime+Probe attack Impl1, if the tool raises a flag after 480 encryptions of AES are being performed then the tool is said to be capable of detecting Prime+Probe attack on AES within 10% of attack completion. Please note that the detection speed is determined in a time-independent manner. Also, theoretically, it is considered enough for an attacker to deduce 50% of the secret key, whereas, the rest of the key can be acquired using reverse engineering techniques [START_REF] Yarom | CacheBleed: A Timing Attack on OpenSSL Constant Time RSA[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF]. Therefore, it is safe to detect an attack before it could complete itself by at most 50%. For WHISPER tool, we have considered this as an upper bound on detection speed. 11, illustrate that the WHISPER tool is capable of detecting Prime+Probe attack Impl1 and Impl2 within 0.21% and 0.02% of its completion, respectively. This result implies that WHISPER tool detects within the first 10 encryptions out of 4800 and 50, 000 encryptions required by Impl1 and Impl2, respectively. This speed is achieved under variable load conditions with fine-grain sampling frequency. Fine-grain is the highest profiling granularity used in these experiments in which, the tool samples hardware events after every 10 encryptions. We have tested the tool with coarse-grain sampling granularity as well, as shown in Tables 4.12 & 4.13. A coarse-grain profiling would mean sampling of hardware events after every 100 encryptions. Tables 4.12 & 4.13 show that resulting accuracy remains almost the same or improves further in some cases, while system overhead decreases drastically compared to fine-grain sampling.

Results in Tables 4.12 & 4.13 reveal that the tool is still capable of achieving detection accuracy comparable to fine-grain detection, while the performance overhead reduces by significantly large margins. For instance, in Tables 4.11 & 4.13 with Prime+Probe attack Impl2, the performance overhead for Ensemble model reduces from 8.20% to 1.03% -that is, by a factor of roughly 8! Section 4.9.1.4 explains further the performance overhead. Similarly, the miss-classification rate for FPs and FNs also reduces due to coarse-grain detection where, in most of the cases, FNs are always zero or negligible. Section 4.9.1.3 explains further the confusion matrix. Detection speed would naturally go down by a small margin in case of coarse-grain detection as we sample hardware events only after every 100 encryptions.

Confusion Matrix

Confusion matrix provides a prognosis of results by representing the number of correct and incorrect predictions by the ML models as False Positives (FP) and False Negatives (FN). Here, the definition of FP is such that it reflects the percentage of instances when the tool incorrectly reports an attack, whereas, FN reflects the percentage of instances when the tool incorrectly reports a no-attack. Though, ideally any error in the detection is not desired, the

Case Study-II: Detecting Flush+Reload

Our second case study provides experimental evaluation on the detection of two implementations of Flush+Reload attack targeting AES cryptosystem.

Detection Accuracy

Though Flush+Reload attack is considered a high-resolution CSCA, WHISPER tool demonstrates a very high detection accuracy for this attack case study as well. Tables 4 The run-time behavior of hardware events gives more insight for these results. For instance, Figure 4.41 shows the behavior of hardware events for Flush+Reload attack Impl1 under NL condition and Figure 4.42 shows the same events for Flush+Reload attack Impl2 under FL condition. These figures illustrate that, under Flush+Reload attack, the hardware events offer distinguishable behavior for attack and no-attack scenarios.

Detection Speed

Flush+Reload attack on AES cryptosystem requires to perform 250 encryptions for Impl1 and 50, 000 encryptions for Impl2 to successfully extract the secret key. Our experimental results, shown in Tables 4.14 & 4.15, illustrate that the WHISPER tool is capable of detecting Flush+Reload attack Impl1 and Impl2 within 4.00% and 0.02% of their completion, respectively, i.e., within the first 10 encryptions out of 250 and 50, 000 required by the Flush+Reload attack Impl1 and Impl2, respectively. Similar to the first case study, this speed is achieved under variable load conditions at fine-grain detection granularity. Tables 4. [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF] & 4.17 show results for coarse-grain sampling, where the detection accuracy remains more or less the same, while detection speed reduces to 40% and 0.2% for Impl1

Case Study-III: Detecting Flush+Flush

Our third & last case study provides experimental evaluation on the detection of two implementations of Flush+Flush attack targeting AES cryptosystem.

Detection Accuracy

Compared to Prime+Probe and Flush+Reload, Flush+Flush attack is considered as stealthier, high-resolution and non-detectable CSCA [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. This is mainly due to the fact that Flush+Flush does not generate any cache accesses itself. In this case study, we demonstrate that is it not only detectable but also detectable with relatively very high detection accuracy using WHISPER tool. Tables 4 Please note that, in this case study, the use of Ensemble model instead of individual models shows clear advantage. This is due to the stealthy nature of Flush+Flush attack, which is not easily detectable by individual models under all load conditions. Thus, a major-vote helps achieve best possible accuracy. As shown in the Tables 4.18 & 4.19, individual ML models show significant variations under load conditions against Flush+Flush attack but Ensemble model performs consistent even under AL and FL conditions against Flush+Flush attack. The run-time behavior of hardware events gives more insight for these results. For instance, Figure 4.43 shows the behavior of hardware events for Flush+Flush attack Impl1 under NL condition and Figure 4.44 shows the same events for Flush+Flush attack Impl2 under FL condition. These figures illustrate that, under Flush+Flush attack, the hardware events offer much less distinguishable behavior for attack and no-attack scenarios compared to other two cases, which causes the accuracy of ML models to vary. Nevertheless, our tool demonstrates that it is capable of precisely capturing this variation and gives high detection accuracy for stealthier attacks as well.

ML Model

Loads Accuracy That is, within the first 10 -20 encryptions out of 350 -400 and 50, 000 encryptions required by Flush+Flush attack Impl1 & Impl2, respectively. Similar to the first two case studies, this speed is achieved under variable load conditions at fine-grain detection granularity. Tables 4.20 & 4.21 show results for coarse-grain sampling, where the speed reduces to 25% and 0.4% for Impl1 and Impl2, respectively, in the worst case. In terms of performance overhead, we observe similar pattern of decrease as in other case studies for both implementations. For Flush+Flush attack, the miss-classification rate is generally higher than other two attacks. This is mainly due to the stealthy nature of this particular attack, which leads the models to miss-classify more often. Section 4.9.3.3 provides more detail on this aspect. Here, we only analyze the reduction in miss-classification rate between fine-grain and coarse-grain detection scenarios that are linked with detection speed. Overall, the miss-classification rate reduces in case of coarse-grain detection. Results show that the magnitude of both FPs and FNs is reduced with coarse-grain sampling.

Confusion Matrix

For Flush+Flush attack, we have analyzed the miss-classification error rate on the same pattern as for Prime+Probe and Flush+Reload attacks. Our findings in this case, however, are different. Tables 4.18 & 4.20 show our results on the distribution of error as percentage of FPs and FNs for Flush+Flush attack Impl1 and Tables 4.19 & 4.21 show similar results for Impl2. In case of Flush+Flush Impl1, our experiments yield that individual models missclassify with a significantly high rate. For instance, SVM miss-classifies between 2.71%-1.50% as FPs and 28.14%-28.01% as FNs. The DT model miss-classifies between 0.81%-2.48% as Our experiments with three different attack categories enable us to provide an evidencebased analysis of CSCA detection. Our first lesson learned from these results is that almost all CSCAs, known or unknown, leave their footprints on the cache hierarchy, either in the form of access timing or pattern. Such a footprint can be captured by carefully profiling just the affected/victim process' behavior without having a priori knowledge of the type of attack or the timeline/order of attack taking place. We have demonstrated this by embedding our detection module inside the victim process. To this end, selection of most relevant hardware events has paramount importance as demonstrated in Section 4.7. Nevertheless, it is pertinent to mention here that the underlying hardware events can be imprecise, non-deterministic and limited in number, which can lead to an increased error rate (FPs & FNs) under smarter attacks in future. Authors in [START_REF] Das | SoK: The challenges, pitfalls, and perils of using hardware performance counters for security[END_REF] provide a detailed insight into the limitations and pitfalls of using HPCs for security.

Our second conclusion from these experiments is that simple statistical or threshold-based solutions are not sufficient to separate anomalous behavior from normal behavior, particularly in the case of side-channel attacks. The attacks can take place in any temporal order and the data being collected by the hardware events might not be easy to classify. In certain cases, even stand-alone ML models might not be sufficient to detect anomalous behavior as illustrated in our third case study with SVM model (Section 4.9.3.3). Our experiments with 12 different ML models and the use of Ensemble model provide empirical evidence to further strengthen the belief that machine learning can help in building resilient software/hardware security solutions for modern computing systems. We have demonstrated their success on Lastly, the use of multiple stringent evaluation metrics in this work reveals that there is a trade-off between performance overhead and detection speed of a run-time detection tool. In order to serve as the first line of defense against SCAs, a detection tool must be fast enough to report an attack before its completion and yet light-weight enough to continuously monitor system's behavior without significantly increasing the overhead. Our experiments show that increased detection granularity yields more reliable results in terms of speed, accuracy and miss-classification rate, resulting in increased performance overhead. With decreased granularity, performance overhead reduces significantly. Therefore, we have proposed to use WHISPER tool in two different modes, i.e., fin-grain and coarse-grain sampling modes. The tool offers this flexibility to run in any of these modes depending on the operating conditions and persisting threat levels.

Summary

This chapter argues in favor of using run-time detection as the first line of defense against cache side-channel attacks. We advocate for detection-based protection mechanisms as existing mitigation techniques against SCAs either completely remove or greatly reduce the performance benefits of resource sharing. In this chapter, we propose a machine learning based CSCA detection tool, called WHISPER, for Intel's x86 architecture. The tool comprises of multiple machine learning models, integrated in an Ensemble fashion, that use real-time behavioral data of concurrent processes running on Intel's x86 architecture. WHISPER tool is capable of detecting a large set of the state-of-the-art attacks without the need of retraining its machine learning models for each specific attack type. We provide extensive experimentation with 6 different attacks and evaluate the tool under stringent constraints, such as: detection accuracy, speed, performance overhead and distribution of error (i.e., false positives and false negatives). Our results show very high detection accuracy, i.e., > 99%, with negligible error rate. The tool is light-weight and easily embedded in the target cryptosystems for run-time detection. We provide experimental evaluation of the tool under variable load conditions to demonstrate its resilience and consistency in noisy environment.

In future, with the use of more sophisticated ML models, WHISPER tool can be scalable for detecting partially known, unknown attacks and covert channels as well. In the next chapter, we will also see an on-going work which is a proof of concept that our proposed detection mechansim also works for very strong covert channel attacks i.e. Meltdown and Spectre which are a strong representation of threat in many modern processors like Intel, AMD and ARM.

Publications related to this chapter

Our main contributions discussed in Sections 4. whereas, Meltdown exploits out-of-order execution. Speculative execution, branch prediction and out-of-order execution are computational optimizations, which are mainly developed for high performance. Spectre and Meltdown have shown that these performance optimizations can be exploited and a larger scope attack can be mounted on the systems. Both Spectre and Meltdown exploits vulnerabilities in computational part rather than storage, i.e., caches for instance. Therefore, in this thesis, we have demonstrated their run-time detection using our detection framework in order to give a proof of concept that the proposed framework is scalable to other future vulnerabilities. We demonstrate that our detection framework is capable of detecting cache-based as well as other types of side and covert channel attacks.

Spectre [START_REF] Kocher | Spectre Attacks: Exploiting Speculative Execution[END_REF] and Meltdown [START_REF] Lipp | Meltdown[END_REF] have a huge impact on most computing businesses. Some of the officially affected companies or security advisories include: RISC-V, NVIDIA, Microsoft, Amazon, Google, Android, Apple, Lenovo, IBM, Dell, HP Enterprise, HP Inc., Huawei, Synology, Cisco, F5, Mozilla, Red Hat, Debian, Ubuntu, SUSE, Fedora, Qubes, Fortinet, NetApp, LLVM, CERT, MITRE, VMWare, Citrix and Xen [260]. The exploited data can be the stored passwords in a password manager or browser, personal photos, emails, instant messages and business critical documents. Spectre and Meltdown have shown their presence on personal computers (desktops or laptops), mobile devices, cloud and proved to be an authentic and serious concern to security. Spectre and Meltdown are Covert Channel Attacks (CCAs) which use CSCAs in its second phase to retrieve execution information of victim's execution (detailed in Chapter 3). After providing our detection mechanism on CSCAs, we also extended to CCAs as proof of concept, which shows that these attacks which are a new buzz in security are also detectable by our proposed mechanism. We also demonstrate that there are some research works in state-of-the-art which detect Spectre [START_REF] Depoix | Detecting Spectre Attacks by identifying Cache Side-Channel Attacks using Machine Learning[END_REF] at its second phase where it uses CSCA technique but we are able to propose first ever early stage detection of Spectre and Meltdown using HPCs and ML.

There have been many mitigations proposed to stop Spectre and Meltdown [START_REF] Khaled | Safespec: Banishing the spectre of a meltdown with leakage-free speculation[END_REF], [START_REF] Wang | oo7: Low-overhead defense against spectre attacks via binary analysis[END_REF], [START_REF] Krüger | Vulnerability analysis and mitigation of directed timing inference based attacks on time-triggered systems[END_REF], [START_REF] Yan | Invisispec: Making speculative execution invisible in the cache hierarchy[END_REF], [START_REF] Kiriansky | DAWG: A defense against cache timing attacks in speculative execution processors[END_REF], [START_REF]Retpoline: A Branch Target Injection Mitigation[END_REF], [268], [START_REF] Oleksenko | You shall not bypass: Employing data dependencies to prevent bounds check bypass[END_REF]. But these mitigation techniques cause significant performance degradation. In the case of Spectre, it is not possible to fix this issue with a single patch, because Spectre has many variants and each variant requires a different patch related to its vulnerability [START_REF] Bright | Meltdown and Spectre: Here's what Intel, Apple, Microsoft are doing about it[END_REF]. Several software-based protection techniques have been proposed to mitigate Spectre attacks. Spectre mitigation techniques have been reported to slow down the performance by 5-12% [START_REF] Hachman | Microsoft tests show Spectre patches drag down performance on older PCs[END_REF]. In the case of Meltdown, software mitigation called 'KAISER' was proposed by Maurice et al. [START_REF] Gruss | Kaslr is dead: long live kaslr[END_REF]. It is implemented with the name of KPTI (Kernel Page Table Isolation) in Linux. KAISER has also reported to slow down the CPU performance [START_REF] Löw | Overview of Meltdown and Spectre patches and their impacts[END_REF]. Also [START_REF] Evtyushkin | Jump over ASLR: Attacking branch predictors to bypass ASLR[END_REF] performed branch predictor attack by escaping KASLR (Kernel Address Space Layout Randomization). In order to make computing devices safe from these hardware flaws, users need to deploy quick patches as soon as attacks are rolled

Introduction | 153

out. However, it is not possible for all systems to install these patches as soon as they are rolled out due to compatibility issues. Despite valiant efforts, mitigation techniques against Meltdown and Spectre attacks are not perfect. Mitigation techniques provide protection against specific variants of Spectre and Meltdown attacks. However, multiple variants of these attacks are coming each day. Also, the effectiveness of these software mitigation techniques comes for the price of performance loss. Therefore, here too, we built our argument that detection techniques can be used as a first line of defense against such attacks and system should apply performance costly mitigation only after detecting these attacks. We propose extension of our real-time detection technique for Meltdown and Spectre using hardware and software performance counters and machine learning. Our proposed detection technique can identify attacking processes with high detection accuracy and minimum system overhead under realistic system load conditions. Similar real-time detection technique has been proposed in [START_REF] Depoix | Detecting Spectre Attacks by identifying Cache Side-Channel Attacks using Machine Learning[END_REF] for the detection of Spectre attack. However, they detected Spectre attacks by identifying cache-based side-channel attacks and used only cache related hardware performance counters. Using only cache related hardware events is not reliable indicator for the Spectre attack detection because it is wide-spectrum attack which does not include only cache behavior but mainly exploits branch predictors. Therefore, we need to include hardware events related to branch prediction to make detection more effective. We present a novel detection technique for attacks which exploit hardware speculation, branch prediction, and out-of-order execution. For Spectre detection, we use hardware performance counters to monitor the caching pattern and branch prediction related events pattern for all running processes. For Meltdown detection, we use hardware performance counters to monitor caching activity for all the running processes and one software event related to page faults. We found that Meltdown attack produces significantly high number of page faults than other benign processes of same computational requirement. We use machine learning models to identify attacking processes by using data of collected performance counters. Although threshold-based methods, namely; correlation-based approach, anomaly detection, can also be used for detection, but smarter adversaries can easily bypass detection techniques that are based on thresholding methods [START_REF] Chiappetta | Real time detection of cachebased side-channel attacks using hardware performance counters[END_REF]. Followings are the main contributions of this Chapter:

1. We propose novel run-time detection techniques for Spectre and Meltdown attacks that use machine learning and hardware/software performance counters. Though detection techniques for Spectre have been reported earlier as well, this is the first-ever detection technique for Meltdown attack to the best of our knowledge. In this chapter, we demonstrate that out-of-order memory look-ups in case of Meltdown attack generate significantly high number of page faults, which can be used as a better indicator for Meltdown attack detection when coupled with cache related hardware events. 2. We demonstrate the effectiveness of our detection techniques under variable system load conditions by running SPEC benchmarks in parallel as system load. We create

Proposed Run-time Detection Mechanism | 155

decides whether the corresponding process is malicious or benign. Detection Service forwards the PIDs of malicious processes to the application which decides that what to do with these malicious processes. As described in Chapter 3, our detection mechanism for detection of CCAs also consists of three phases namely; the Training phase, Run-time profiling and Classification phase and detection phase. We provide a recall on those three steps.

Phase-I: Training of ML Models

In training phase, we train the ML models being used for detection technique of Spectre and Meltdown. We use 3 linear models i.e. LR, SVM, LDA and 1 Non-linear model based on Neural Networks i.e. CNN (Models are explained in Chapter 3 and list of models is available in Table 3.4). We profile Meltdown/Spectre and other benign processes under Attack and No-Attack scenarios and variable load conditions. We collect performance counter values at sampling rate of 100ms (at fine-granularity). We monitor suitable hardware/software counters (listed in Sections 5.3 and 5.4) for profiling, which are directly related for differentiating benign processes from Meltdown and Spectre processes, separately. We train the machine learning models with a data set of 100,000 samples. We mixed the data sample from benign and attacker processes and train ML models on these labeled data. We perform cross validation using K-fold cross validation technique.

Phase-II: Run-time Profiling

In the second phase, we monitor hardware and software events at run time. Sampling frequency is an important factor for detection technique, as it has a direct impact on performance overhead of detection. We select the sampling time period of 100-ms to incur minimum detection overhead. However, greater sampling frequency provides high detection speed, but it comes at an elevated performance overhead. We demonstrate in our results that sampling rate of 100-ms yields moderate performance results.

It is important to note that, while detecting CSCAs using NIGHTs-WATCH and WHIS-PER, the sampling rate was not time dependent. Rather, it was a function of how many bits are encrypted/decrypted before the next sample is collected from hardware events. For instance, for RSA, we used a fine-grain sampling frequency of every 10-bits being encrypted between two consecutive samples. Similarly, for AES, we used every 10-encryptions being completed between any two consecutive samples. However, Spectre and Meltdown attacks do not target specifically any crypto-operations. Rather, these attacks are used to access privileged (kernel) address space and can literally access all data in the privileged space. Therefore, the sampling frequency in this case is time dependent. We have used a sampling rate of 100-ms in our experiments to observe the selected hardware and software events.

Selected hardware events for Meltdown | 157

Spectre process. Figure 5.3 shows the branch miss-predictions generated by all processes. Spectre attack produces significantly large branch miss-predictions as compared to total number of branch instructions of Spectre attack. Also, it generates comparatively higher branch miss-predictions than other benign processes. Result of Vougioukas et al. and our experimental results shown in Figure 5.2 and Figure 5.3 prove our intuition for selection of branch related hardware events as good features for ML models. We also select hardware events related to second phase of Spectre attacks to strengthen detection technique and also to minimize False Positives (FPs) and False Negatives (FNs). In second phase, Spectre attack performs CSCA i.e. Flush+Reload, to extract confidential information from caches. As mentioned in Chapter 3, to execute Flush+Reload, attacker continuously flushes the cache lines and checks after some time if it has been accessed by victim since the last flush. By constantly performing cache flushing and reloading, attacker executes a lot of cache accesses and of which a lot will be cache misses, in a repetitive pattern. Attacker accesses the caches in a malicious way. Therefore, attacker generates a significantly higher cache miss rates while performing Flush+Reload. PAPI supports Hardware performance counters related to cache misses and cache accesses for all levels of cache. We selected L3 cache misses and cache accesses because flushing cache line from L1 cache also removes the content from all levels of cache. Figure 5.4 and Figure 5.5 show the total number of cache misses and total cache accesses generated by benign and Spectre processes. As depicted from graphs, Spectre attack produces significantly larger L3 cache misses and L3 cache accesses as compared to other benign processes. These experimental results show that cache misses and cache accesses are good indicators for detecting Spectre attack. In addition to L3 cache misses, cache accesses and branch related events, we also select total number of instructions event because it shows the workload of a specific process put on the CPU to generate related cache misses, cache accesses and branch miss predictions. Because Spectre attack consists of a shorter loop which constantly performs branch mispredictions and cache accesses. The rate of cache misses and branch mispredictions in relation to the total number of executed instructions is likely to be higher for Spectre attacks as compared to other benign processes. Figure 5.6 shows that the Spectre process puts a very small workload, in the form of total number of executed instructions, on CPU but still generates higher cache misses, cache accesses and branch miss-predictions. Relevant hardware events selected for Spectre attacks are listed in Table 5.1.

Selected hardware events for Meltdown

For Meltdown attack detection, we used both hardware and software events as features to machine learning models. We use Perf tool to monitor events related to Meltdown attack a justification to FNs, the rate of FNs is observed very low in the results and even if the detection mechanism misses to detect the attack once, still it samples the attack by fine-grain sampling and it is impossible to not detect the attack for 100ms (sampling rate of selected HPCs is 100ms). In case of FPs, the results show some overhead toward performance only, because detection service wrongly predicts a benign process as a malicious process which is not a big threat to the system. In our results, FPs and FNs are very less in number as detection accuracy of attacks is more than 99% in mostly all cases. Our detection mechanism is capable of identifying if the system is under threat at run-time by a vulnerable attack. We provide a proof of concept by detecting Spectre and Meltdown that detection can be first line of defense and later on detection mechanism can be helpful to provide mitigation on the prior knowledge of system user attack or no-attack.

Summary

This chapter presents novel run-time detection mechanism for Spectre and Meltdown attacks on Intel's x86 architecture. We perform experiments with four ML models under realistic system load conditions. These ML models use data from hardware and software performance counters to find out malicious behavior of Spectre and Meltdown attacks. This chapter presents experimental evaluation of Spectre variant 1, Spectre variant 2 and Meltdown attack under variable system load conditions, i.e. No Load, Full Load and Average Load conditions. We provide analysis of all ML models based on detection accuracy, detection overhead and detection speed. We use SPEC integer benchmark to generate data sets under variable load conditions and this generated data set is used to train and evaluate performance of ML models. Our detection technique shows high detection accuracy with minimum overhead under realistic system load conditions. Our results show a detection accuracy of 99.93%, 99.06%, and 98.03% for Spectre variant 1 attack in case of NL, AL and FL conditions, respectively, with performance overhead of < 2% at sampling rate of 100ms. In case of Spectre variant 2, our detection technique shows detection accuracy of 99.92%, 99.17%, and 98.69% for Spectre variant 2 in case of NL, AL and FL conditions, respectively, with performance overhead of < 2% at sampling rate of 100ms. For Meltdown, our detection mechanism shows better results than Spectre due to more distinctive behavior of Meltdown compared to benign processes. Meltdown detection technique shows detection accuracy of 99.95%, 99.83%, and 98.27% in case of NL, AL and FL conditions.

This chapter is a proof of concept to show that our proposed detection mechanism is adaptable and is able to cover a wide spectrum of vulnerabilties. In Chapter 4, we presented that proposed detection mechanism is able to cover a wide range of vulneraiblities that are exploited via cache behavior. We presented detailed analysis and experimental results on wide spectrum of CSCAs. Later on, in this chapter, we have presented that attacks like Spectre and Meltdown which are not only based on cache behaviors, are also detectable by our proposed mechanism. We have described that our proposed mechanism is adaptable to add different combinations of HPCs, Software counters and ML to discover larger scope of vulnerabilities which are new threat to Intel x86 architecture. To the best of our knowledge, this work is the first demonstration of a detection mechanism which detects Meltdown for the first time and also detects different variants of Spectre at both its attack phases in realistic execution scenario (not only at the stage of CSCA execution).

Publications related to this chapter

Introduction to Detection-based Mechanism

In the previous chapters, we have been explaining the inherent features that any known CSCA exploits are the cache timing and access patterns. Such attacks can be prevented at various levels such as system-level, hardware-level and application-level [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF]. At the system level, physical and logical isolation approaches exist [START_REF] Jin | A Simple Cache Partitioning Approach in a Virtualized Environment[END_REF]. At the hardware level, mitigation techniques are rather difficult due to their cost and design complexity. Hardware solutions, nevertheless, suggest having new secure caches, changes in prefetching policies and either randomization or complete removal of cache interference [START_REF] Liu | Random Fill Cache Architecture[END_REF]. Such drastic changes are difficult to adapt in commodity hardware. At the application level, the proposed countermeasures tend to target the source of information leakage and mitigate it [START_REF] Kim | STEALTHMEM: System-Level Protection Against Cache-Based Side Channel Attacks in the Cloud[END_REF]. Solutions propose to have timing obfuscation by inserting fixed or random delays, interfering the measurement of the system clock, or eliminating timing side-channel leaks using program repairs. However, in addition to being expensive, such techniques do not eliminate timing channels completely. Despite valiant efforts, mitigation techniques against SCAs are not very effective. This is mainly because mitigation techniques usually protect against any given specific vulnerability of the system and do not take a system-wide approach. Moreover, they either completely remove or greatly reduce the performance benefits of resource sharing. In addition to that, the attacks are becoming sophisticated and stealthier [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF], [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF]. Thus, they overcome statically applied mitigation techniques. Therefore, on the one hand, protection against these CSCAs needs to be applied across entire computing stack and, on the other hand, mitigation strategies must not take away the hard-earned performance benefits of computing systems.

In this chapter, we advocate for the use of need-based protection mechanisms, which are imperative to effectively mitigate CSCAs without sacrificing the benefits of resource sharing. Our arguments are in favor of enhancing the capability of Operating System (OS) by using a detection-based mitigation approach that would help the OS to apply mitigation only after successful detection of a CSCA. Thus, detection can serve as the first line of defense against such attacks. Such a solution would incur as little overhead as possible without significant performance or monetary cost. Such a solution, however, becomes very challenging in the absence of an effective detection mechanism, which needs to be highly accurate, should incur minimum system overhead at run-time, should cover a large set of attacks and should be capable of early-stage detection, i.e., before the attack completes at the very least. Rather than applying a static mitigation against CSCAs, which is active all the time and thus performance costly, a detection-based mitigation would be dynamic and it would neutralize the side-channel threat as and when it happens.

A typical OS, Linux for instance, offers user to kernel space separation. This separation prevents cross-space information sharing that is private to the OS and helps protect it from being affected by the applications in user-space that do not have appropriate access privileges. Multiple processes, victim and malicious processes alike, are hosted in the user space to run while they share the same caching hardware and OS services. Usually, the OS offers encryption as a service to any legitimate process running in the user space that potentially requires data encryption. Thus, a malicious process, just like any benign process, can request encryption and start attacking it for the extraction of secret information/key. Therefore, the Kingsguard mechanism collects execution-specific data from all the concurrent processes that are using encryption while running in the user space. It then analyses at run-time if the interference of encryption service with caches has been altered from the expected/learned behavior in order to detect malicious activity. The Kingsguard mechanism does so by using multiple machine learning models trained with the victim/encryption behavior. More specifically, following are the major contributions of this chapter.

1. This chapter proposes a novel OS-level run-time detection-based mitigation mechanism, called the Kingsguard, against CSCAs that enhances the security & privacy capabilities in general-purpose operating systems. Therefore, the novelty in this work stems from their use by the OS in providing run-time mitigation against known SCAs. 2. We demonstrate that the proposed mechanism is capable of detecting and subsequently mitigating state-of-the-art known CSCAs, such as: Prime+Probe, Flush+Reload and Flush+Flush attacks on AES and RSA cryptosystems while running under Linux. We support our claims with extensive experimental evaluations. 3. We demonstrate that the proposed mechanism is resilient to noise generated by the system under various loads. To do so, we provide results under realistic system load conditions, i.e., under No Load (NL), Average Load (AL) and Full Load (FL) conditions. These load conditions are achieved by concurrently running memory-intensive SPEC benchmarks on the system along with the encryption and attack processes. These results demonstrate the robustness & portability of our proposed mechanism. 4. In this chapter, we demonstrate the effectiveness of our proposed mitigation mechanism on Linux. However, the Kingsguard is scalable on other operating systems as well.

6.2 Background Knowledge on Linux

Security Features in Linux Distributions

Linux is one of the fastest growing operating system in multiple computing domains. For instance, if we consider the market of super computers, Linux clearly leads the market share as it is running on more than 99% of the top 500 fastest supercomputers in the world [276].

Kingsguard: Detection-based Mitigation | 173

Though Linux offers variety of distributions that are optimized for particular user base, there are mainly 2 types of distributions for desktop users: 1) general-purpose and 2) Linux distributions for security and privacy. The popular distributions for privacy and security are Qubes OS, Tails, Black Arch Linux and Kali [START_REF] Drake | Best Linux distributions for privacy and security | TechRadar[END_REF]. These distributions use sand boxing, separation of work groups, anonymous browsing and pen testing tools as their salient features. These distributions, however, are for specialized users, tricky to setup and not user friendly. General-purpose distributions such as: Linux Mint, Debian, Ubuntu, Open Suse and Manjaro [278], are the most popular Linux distributions. However, general-purpose distributions lack appropriate security features needed to deal with the threat of side-channel information leakage.

Case Studies: Selected CSCAs as a proof of concept for detectionbased mitigation

As we have explained our attack use-cases in Chapter 3, we have selected 3 different CSCA implementations as use-cases for the validation of Kingsguard tool. These attacks cover 3 main categories of CSCAs, i.e., Flush+Reload (F+R), Prime+Probe (P+P) and Flush+Flush (F+F). We have validated our results by running these use-cases on RSA & AES cryptosystems. Just to show the 3 selected implementations, Table 6.1 provides details on these use-cases along with the OpenSSL versions being used and the time to recover the key by each of these attacks on an Intel's core i7-4770 CPU machine.

Table 6.1 -Recall: List of selected CSCAs as use-cases along with their key recovery time on Intel's core i7 machine for Kingsguard.

# CSCAs

OpenSSL Version Crypto-system Key Recovery Time (µs) 1 Flush+Reload 0.9.7l RSA 150 2 Flush+Flush 0.9.7l/1.0.1f AES 33600 3 Prime+Probe 0.9.7l/1.0.1f AES 8720

Kingsguard: Detection-based Mitigation

This section provides the design details of the Kingsguard mitigation mechanism. The Kingsguard is an OS-level run-time detection-based mitigation mechanism, which is designed to detect, and subsequently mitigate, a large set of CSCAs. It enhances the capability of OS, particularly Linux general-purpose distribution, with security features against side-channel information leakage. Figure 6.2 illustrates the composition of Kingsguard mechanism with various building blocks. The Kingsguard mechanism works in two distinct stages carried out by two distinct modules: the detection module and the Mitigation module. In the first stage, it uses multiple machine learning models that take, as input features, the real-time behavioral data of concurrent processes running on Intel's x86 shared memory architecture through hardware performance counters. These data are provided to the detection module, which is embedded inside the encryption library by Kingsguard as shown in Figure 6.2. Please note that the detection module operates in User space. We have elaborated this module (NIGHTs-WATCH) and its functionality in Chapter 4 in more details. Based on these data collected through HPCs, Kingsguard detects if any malicious process is trying to manipulate the encryption process in order to extract information. If no malicious activity is reported, all processes run normally at their pre-assigned privilege levels. However, if a malicious activity is detected then the Kingsguard mechanism invokes mitigation module in the Kernel space and enters into the second phase. In this phase, through a netlink between user and kernel spaces, the process IDs (PIDs) of all processes that were using encryption library at the time of detection are provided to the mitigation module in Kernel space. Kingsguard immediately suspends any on-going encryption activity while identifying the IDs of user processes of encryption library. The mitigation module then evaluates these PIDs to separate trusted processes (usually system processes) from untrusted processes (usually user processes), if any, and initiates the procedure of removing malicious/untrusted process(es) from the system. Once all untrusted processes are removed, the mitigation module resumes the execution of all trusted processes. Figure 6.2 shows these two distinctive stages of operation as two main building blocks across user and kernel space in Linux environment.

In the following, we first elaborate the threat model with which the Kingsguard mechanism deals and then provide design details of detection and mitigation modules.

Threat Model

We assume an advantageous scenario for the attacker to demonstrate that our proposed detection-based mitigation mechanism remains effective even under weaker assumptions. Tromer et al. [START_REF] Tromer | Efficient Cache Attacks on AES, and Countermeasures[END_REF] have classified SCAs into synchronous and asynchronous attacks depending on whether or not the attacker can trigger the processing of known inputs (usually plain-or cipher-texts). Synchronous attacks, where the attacker can trigger and observe encryption, are generally easier to perform from the attacker's perspective, and thus harder to defend against, since the attack does not need to determine the start and end of each encryption. We assume as strong a position for the attacker as possible and therefore will consider the scenario of synchronous attacks where the attacker can request and observe encryption of arbitrarily chosen plain texts. Moreover, to minimize the effect of external noise for attacker, we assume that the attacker can be a co-resident on the same machine as the target encryption process. We also assume that the attacker can execute user-mode code on a processor core that is shared with the target encryption process but does not have access to the address space of 6.3 Kingsguard: Detection-based Mitigation | 175 the target process. We demonstrate that Kingsguard mechanism works for same-core attacks as well as for cross-core attacks. We assume that attacks are persistent in nature, i.e., the attacker process can repeat the same attack for a reasonably large number of times. We also assume that any legitimate benign process can be potentially an attacker, thus the OS does not have prior knowledge or any specific privilege level associated with the attacker. Lastly, we assume that our threat model comprises of multiple attacks, which can execute in any temporal order, thus the mitigation must protect the target encryption process under all possible execution scenarios. To demonstrate the proof of concept, we have considered 3 state-of-the-art CSCAs targeting 2 different cryptosystems as use-cases, i.e., Flush+Reload on RSA and Flush+Flush and Prime+Probe on AES. to achieve higher detection accuracy. Secondly, an accurate but late detection is useless for run-time detection. Theoretically, detection of an attack after 50% of its completion is considered as sufficient for a successful attack [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF]. Thus, detection speed is equally important for run-time adaptation. And thirdly, a detection mechanism must be highly accurate and should not lead to a higher number of False Positives (FPs) and False Negatives (FNs) at run-time. We considered all these aspects while designing the detection module for Kingsguard. We have extended NIGHTs-WATCH as detection module to extend it as run-time detectionbased mitigation mechanism named as Kingsguard. We have explained the methodology (profiling, training, classification), selection of hardware events, selection of ML models for the NIGHTs-WATCH in detail in Chapter 4, Section 4.2.

Run-time Mitigation Module

In this section, we present the design details of the mitigation module used in Kingsguard mechanism. As illustrated in Figure 6.2, once the trained classifiers report an attack, the mitigation module suspends encryption service and the detection module immediately starts collecting the IDs of all processes that are using encryption service at the time of detection. This information is easily extractable using Fuser utitlity in Linux shell environment that retrieves PID(s) of the processes that are concurrently interacting with any specific library or file system. In our case, we have used fuser utility to get the PIDs of all the processes interacting with encryption library. Since it is a Linux shell utility, therefore, it can not be executed directly in C code. To do so, the popen primitive is used, which provides the Linux shell environment in the C code. The popen primitive, used with fuser, returns all PIDs in the form of stream of characters that are interacting with the libcrypto.so.0.9.7. As discussed in our threat model in Section 6.3.1, Kingsguard considers synchronous attacks, in which, an attacker process triggers the encryption by using the encryption library as shown in Figure 6.3. Thus, the attacker itself is considered as a direct user of encryption service. In an asynchronous model, an attacker needs to first establish synchronization points with the victim (encryption) before initiating attack as shown in Figure 6.4. Such synchronization is non-trivial to achieve and the attacker needs to remain active for longer period of time, which can expose the attacker easily. According to the state-of-the-art, and to the best of our knowledge, no implementation of Flush+Reload, Flush+Flush, Prime+Probe or any other CSCA exists with asynchronous attacking model. Therefore, we assume that an attacker, like any legitimate benign process in the system, would access encryption library before attacking it in a synchronized fashion. We do not consider the case where an attacker process, being the parent process, spawns a child process that executes the actual attack. Linux OS provides isolation to kernel space from user space processes. Thus, in order to pass critical information, such as PIDs, we use a Netlink socket as shown in Figure 6.2. Netlink socket is a special Inter As illustrated in Figure 6.2, the mitigation module first evaluates all PIDs to separate trusted processes from untrusted ones. It does so because, in a system running with normal load under Linux, it is highly likely that the set of active processes that are concurrently using encryption library also contains some Linux's system processes, which are considered as trusted by default. Therefore, the mitigation module evaluates all PIDs to separate trusted processes from untrusted ones. Once the trusted processes are secured, the module kills all untrusted (user) processes that were accessing encryption library regardless of them being benign or attacker process. Though it might add some performance cost (as benign processes get killed), identifying individual attacker process might cost even more resources than killing all untrusted processes and resumption of encryption service. After purging the system from untrusted processes, the normal execution is resumed by the mitigation module.

Functional Description

Algorithm 2 provides pseudo-code representation of the working principle of Kingsguard mechanism. As illustrated, the detection module takes as input the sampling granularity for hardware events (SamplingGranularity), which can be either user-defined or automatically adjusted at run-time. By default, the sampling granularity is user-defined (offline) and set to fine-grain sampling. Another input is the total number of iterations for which we tested the module (MaxIterations). Number of iterations vary for each attack as discussed in Section 6.4. Lines 1 -3 show that a victim process (encryption process) is initialized, the detection module is embedded inside the encryption library for once and the hardware events are set around the victim process, considering it as the Region of Interest (ROI). For the selected number of iterations, the module activates detection after a number of encryptions equal to SamplingGranularity (lines 4 -6). Once activated, the detection module collects the data from hardware events (line 7) and feeds them as features to selected binary classifier (line 8). Based on the classification, the module generates a report on the results. Detection is then deactivated (line 9) and if the report is True then an attack is reported (lines 10). Otherwise, the victim process continues to execute uninterrupted. In case of an attack, Kingsguard immediately suspends all encryption activities in the system (line 11) and starts analyzing all processes currently using encryption library (lines 12 -14). It separates the trusted processes from untrusted ones and kills all untrusted processes (line 15) before resuming the encryption services.

Experiments and Results

Though Kingsguard mechanism is scalable on other operating systems, we demonstrate its effectiveness on Linux. The Kingsguard mechanism enhances the capability of Linux

Evaluation setup

We have performed experiments on Linux Ubuntu LTS 16.04 Kernel version: 4.10.0-28-generic running on Intel's core i7 -4770 CPU at 3.40-GHz with 64KB L1 (32KB L1-D + 32KB L1-I), 256KB L2, 8192KB L3 and 8GB system memory. We have used Performance API (PAPI) [227] library to access HPCs on Intel Core i7 machine. As use-cases, we have performed experiments with three state-of-the-art CSCAs namely: Flush+Reload on RSA cryptosystem, Flush+Flush and Prime+Probe attacks on AES cryptosystem. For RSA, the axtls Embedded 6.4 Experiments and Results | 181 SSL 2.1.4 library is used with bigint options set to square algorithm. For AES, we have used OpenSSL-0.9.7l library. As illustrated in Figure 6.2, we have used Netlink sockets for the communication between the kernel and user space in Linux. In the following, we present our experimental results using 3 case studies. Moreover, for comparative analysis, we provide results using individual ML models running separately in the detection module. One of the key features of Kingsguard mechanism is that it operates under realistic system load conditions on commodity hardware. Therefore, we emulate the load conditions by running memory-intensive SPEC benchmarks on the system as independent background load. The load conditions are defined such that a No Load (NL) condition involves only a Victim and an Attacker process running, an Average Load (AL) involves Victim, Attacker and any two SPEC benchmarks running and a Full Load (FL) condition involves Victim, Attacker and any four SPEC benchmark running in background. It is important to mention that the state-of-the-art attacks [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF], [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF], [START_REF] Yarom | Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack[END_REF], [START_REF] Aciiçmez | Yet Another MicroArchitectural Attack:: Exploiting I-Cache[END_REF] have been demonstrated as running in isolated conditions i.e., attacker and victim being the only load on the system. Therefore, assuming realistic load conditions help in validating the actual threat level these attacks pose on the one hand, while allow to assess the effectiveness of mitigation techniques on the other hand.

Overall Performance Overhead of Kingsguard

The overall performance cost of Kingsguard for performing detection and subsequent mitigation as compared to the key recovery time by potential attackers is a critical measure to evaluate the overheads. Table 6.2 illustrates the overall performance overhead incurred by Kingsguard mechanism while performing different operations both in user-and kernel-space. For a sample set of 1000 iterations under variable load conditions, we have observed that the entire operation, from detection, collection of PIDs, evaluation of PIDs, killing untrusted processes and resumption of service, takes 178µs, 199µs and 206µs on average for no load, average load and full load conditions, respectively. Compared to the time taken by the use-case attacks to recover secret key, as shown in Table 6.1, one can notice that the entire mitigation mechanism takes only a fraction of time.

For instance, under no load conditions, Flush+Reload attack on RSA crypto-systems would require at least 150µs to complete (Table 6.1), whereas the Kingsguard mechanism can detect this attack in 72µs on average for No Load conditions (Table 6.2). Once an attack is detected, the encryption is immediately halted by the OS, i.e., in the first 72µs in this case. In the next step, PIDs of all processes using encryption service are collected in the user space. This information is relayed to the kernel space for subsequent mitigation, which takes 18µs on average in this case. Thus, the overall performance overhead of running Kindgsguard, from detection to mitigation, is measured to 178µs on average. In case of Flush+Flush and Prime+Probe attacks on AES crypto-system, the detection-based mitigation overhead is Our experimental results, as illustrated in Table 6.3, show that the selected models take fractional amount of time in performing their binary classification compared to the total encryption time taken by both RSA and AES crypto-systems under various load conditions as illustrated in Table 6.4. For instance, both LR and SVM models take roughly 55µs on average to classify an attack scenario under no load condition whereas, under the same load conditions, RSA takes 7604µs while under Flush+Reload attack and AES takes 1395µs and 763µs while under Flush+Flush and Prime+Probe attacks, respectively. As the load conditions vary, there is no significant change in the measured results. In fact, the average and full load conditions only cause the crypto-systems to take longer time to completion due to Linux's fair scheduling. These results show that the time these ML models take to classify is fractional in comparison to the total encryption time taken by the crypto-systems while under different attacks. Thus, their implementations do not significantly contribute to performance overhead and help in early detection.

Simultaneous Attack Scenarios

In practice, attacks can happen in any temporal order and magnitude, i.e., they can occur sequentially as well as simultaneously or in any combination. In this work, we have also analyzed the effect of combination of multiple known CSCAs. We have performed experiments with multiple attacks running simultaneously on the same computing platform. Through these experiments, at first, we have shown that there are possible attacking scenarios in which multiple instances of the same attack or multiple unique instances of different attacks can take place simultaneously. Subsequently, we have shown that if a single attack uses multiple collaborating processes (instances of itself) to extract secret information or multiple different attacks take place simultaneously then the Kingsguard mechanism is still capable of detecting and mitigating them with considerably high accuracy. We have experimented with two combinations of simultaneously running attacks. Our first combination comprises of homogeneous attacking processes, i.e., all attacking processes are of the same type (for instance, Flush+Reload on RSA). The second combination comprises of heterogeneous attacks where we mix different attack types. Table 6.5 provides mitigation accuracy of Kingsguard for homogeneous multiple attacks happening simultaneously on the same crypto-system library. In this case, we have run 2 and 3 instances of each attack, i.e., Flush+Reload, Flush+Flush and Prime+Probe attacks. We observed that the mitigation accuracy for Kingsguard remains very high, i.e., above 99% in almost all cases with the exception of Flush+Flush attack with 3 attacking instances. In this case, the accuracy drops to 97%. The case of homogeneous multiple attacks is relatively trivial since all attacking processes behave the same and it is rather easier for the hardware events to capture the similarity in the behavior of multiple processes. Therefore, we perform further experiments with heterogeneous multiple attacks. Table 6.6 provides mitigation accuracy of Kingsguard for heterogeneous multiple attacks happening simultaneously on two different crypto-system libraries, i.e., RSA and AES. In this case, we have run a mixed number of instances by each attack in different combinations. Starting with the case of all three attacks running simultaneously, we observed that Kingsguard achieved a mitigation accuracy ranging between 97.81 -99.99%, which illustrates the fact that even if multiple attacking processes exhibit different behavior, our mitigation mechanism is capable of identifying them as threat and mitigates them efficiently. To further demonstrate this capability, we have conducted experiments with various combinations of use-case attacks as shown in Table 6. 6. In almost all cases, the mitigation accuracy remains above 90%. In only one case of four attacking instances comprising of Flush+Reload and Prime+Probe attacks, the accuracy drops as low as 82%.

Through these experiments, we analyze the combination of different known CSCAs and their influence on information leakage. As the results in Tables 6.5-6.6 show, our proposed detection-based mitigation mechanism is capable of detecting and subsequently mitigating attacks with a considerably high accuracy even if they occur in various combinations. These results demonstrate the robustness of Kingsguard mechanism. Moreover, these results illustrate that unknown/future attacks, which work on the similar working principles and exhibit similar run-time behavior, should also be detected and mitigated using Kingsguard mechanism.

Flush+Prefetch: A Noise-based Mitigation Technique

As part of my PhD studies, I have also worked partially on an obfuscation-based mitigation solution that uses calibrated noise injection to obfuscate cache timing and access pattern information for running processes. This work is mainly conducted under a collaboration between ECLab, Information Technology University (ITU), Pakistan, and Lab-STICC, UBS, France, through PHC-PERIDOT project e.health.SECURE and Eiffel Excellence program. This work is mainly done with another PhD candidate, Mr. Muhammad Asim Mukhtar from ECLab-ITU, who was with us in Lab-STICC on Eiffel Scholarship for 10 months. During that time, we worked together to build a methodology and performed some experiments for noise-based solutions. This part of the chapter discusses noise-based mitigation solution. This work is mentioned in Section 6.11 as a joint publication.

The mitigation technique we proposed is called Flush+Prefetch, which obfuscates the memory access behavior of a secure application using independent threads that randomly access the memory belonging to secure application. Unlike existing state-of-the-art countermeasures, Flush+Prefetch works with commodity hardware and it is compatible with existing performance features. This countermeasure takes benefit from two limitations of software-based cache attacks: 1) the attacks cannot identify the source that has generated a particular cache access and 2) These cannot detect multiple operations on a particular cache line. These limitations are exploited by injecting noise in cache access pattern through the use of concurrent threads that contain prefetch or clflush instructions. Doing so randomly encodes cache access pattern such that the attacker cannot extract the encryption/decryption key from cache access information. As a proof-of-concept, we have analyzed the security of RSA's implementation using Chinese Remainder Theorem (CRT) against Flush+Reload attack. The main contributions of this technique are:

• We have designed and implemented two obfuscation mechanisms called as Flush+Prefetch, integrated with application that are independent to application's execution path in order to mitigate access-driven CSCAs. Flush+Prefetch requires fewer software modification and can execute on commodity hardware without disabling hardware performance features like super-pages, data de-duplication and simultanueous multi-threading. • We have evaluated the security of these mechanisms by defending the secret key of RSA cryptosystem against a high-resolution cache side-channel attack called Flush+Reload attack. We have analyzed 10, 000 memory access traces of RSA in presence of Flush+Prefetch countermeasure to show the confidentiality of secret key. • We have evaluated the execution overhead of Flush+Prefetch countermeasure for both mechanisms and find that overhead is smaller than previous state-of-the-art single path programming based countermeasure [START_REF] Rane | Raccoon: Closing Digital Side-Channels through Obfuscated Execution[END_REF].

Flush+Prefetch -The Countermeasure

The Flush+Prefetch countermeasure takes benefit from two limitations of Flush+Reload type of attacks. The first limitation is the fact that such attacks cannot identify the source (thread) that has fetched data in cache line. This limitation can be elaborated in a situation where the attacker thread is targeting a cache line that is shared between multiple concurrent threads. The attacker, in its reload phase, cannot distinguish whether the cache accesses are being generated by the concerned thread (victim) or any other concurrent thread. Thus, cache accesses generated by unconcerned threads, i.e., other than victim, are noise from the attacker's perspective. We refer such noise as Positive noise since it has a positive effect on the execution time of victim thread due to increased cache hits.

The second limitation is the fact that such attacks cannot detect multiple operations on a particular cache line. Exploiting this limitation enables the countermeasure to hide or misrepresent the information related to the exact cache accesses of the victim thread. This limitation can be elaborated in a situation where the attacker evicts a particular cache line in its first phase (i.e., eviction) and then waits for the victim to access that cache line. During this wait phase of the attacker, if the victim or some other concurrent thread evicts the concerned cache line after being used by the victim and immediately before the reload phase of the attacker, it will result in a cache miss for the attacker, which was otherwise supposed to be a cache hit from the attacker's perspective. This increases the attacker's likelihood of missing cache accesses by victim. We refer such noise as Negative noise since it has a negative effect on the execution time of victim thread due to the possibility of increased cache miss for the victim. Eviction of the concerned cache lines by an independent concurrent thread can potentially effect the hit rate of both victim and attacker threads.

The term Noise refers to the extraneous memory operations that are introduced in the application's sequence of memory operations for obfuscating it. If the addition of noise along with the primary concern of obfuscation also improves the execution time of application, we call such noise a Positive noise. Inversely, if the addition of noise degrades the execution time of application in order to achieve obfuscation, we call such noise a Negative noise.

The Flush+Prefetch countermeasure against Flush+ Reload attack on CRT implementation of RSA cryptosystem uses both positive and negative noise and their combination to preserve confidentiality. Flush+Prefetch creates independent concurrent threads for positive and negative noise that share victim thread's address space. We have selected the way of adding noise using independent threads rather than integrating countermeasure (prefech and flush instruction) in RSA code because of performance reasons. Integration of prefetch and flush instructions in RSA will greatly degrade the performance. This is because we have to fetch all security critical instructions before use and have to add in critical path of RSA program (similarly as in single path programming). Moreover, we have to fetch those security critical instructions as well that do not require immediately to confuse the attacker. However, in our proposed countermeasure the prefetch and flush instructions are executing through independent threads generated by the RSA process and not in the critical path of RSA program. Moreover, prefetch thread without being included in the critical path of program also reduces the instruction access latency of the RSA code.

Positive Noise

The positive noise thread uses prefetch instruction to fetch an instruction in a cache line targeted by the attacker. The positive noise thread executes concurrently with other threads, therefore, different cases are possible based on instant of execution of positive noise thread relative to other threads. Figure 6.5 shows these possibilities. Case-A shows that positive noise thread has only generated the memory access during wait phase of the attacker. The attacker, in this case, cannot distinguish the source of access (positive noise or victim) and takes memory access as generated by the victim. This confusion results in loss of temporal pattern of cache accesses. Hence, the victim achieves confidentially through obscurity. Case-A is further elaborated in Figure 6.6 with real execution trace. Figure 6.6 shows the cache access pattern captured by attacker in the presence of positive noise, which is introduced in Square operations of RSA (CRT implementation). In Figure 6.6, square hits in the highlighted area are due to the prefetching of positive noise thread instead of square operations being performed by the victim thread. During reload phase of the attacker, the positive noise thread makes it difficult for the attacker thread to distinguish between actual square operations performed by the victim thread and the prefetching operations performed by the positive noise thread.

Case-B in Figure 6.5 shows that both positive noise thread and victim thread have generated the memory access during wait phase of the attacker. During reload phase, the attacker deduces correct information that victim has actually generated a memory access. In this case, positive noise thread is acting only as a prefetch for the victim thread. This particular case does not help improving confidentiality, rather the execution time of the victim thread is reduced thanks to the prefetched instructions.

Case-C in Figure 6.5 is similar to Case-B except the positive noise thread is executed after the victim thread. This situation contributes neither in achieving confidentiality nor in reducing the execution time of victim thread. Same as in Case-B, both positive noise and victim threads have accessed the memory during the wait phase of attacker. Therefore, during reload phase, the attacker deduces correct information that victim has actually generated a memory access. Also, in the wait phase, the positive noise thread is executed after the victim thread that does not help victim to prefetch data from main memory. Thus, the execution time remains the same as without positive noise thread.

Negative Noise

The negative noise thread uses cflush instruction to evict the cache lines targeted by the attacker. The negative noise thread executes concurrently with other threads similar to the positive noise thread. Therefore, different cases are possible based on instant of execution of positive noise thread relative to other threads. Figure 6.7 shows these possibilities.

Case-A in Figure 6.7 shows that, during the wait phase of attacker, the negative noise thread is executed after the victim thread. In this case, the negative noise thread evicts the shared cache line that victim thread had cached earlier and used. The attacker, in its reload phase, would still register a cache miss as it will not find information cached by the victim. Thus, the attacker deduces incorrect information about the victim's access pattern as victim has actually generated a memory access, which is evicted by the negative noise thread immediately after use. This causes the victim's access invisible to attacker.

Case-B in Figure 6.7 shows that the negative noise thread is executed before the victim's thread. This situation does not contribute in hiding victim thread's access pattern from the attacker in reload phase. The attacker, in its reload phase, would register a cache hit that is correct information about victim's access pattern. This helps the attacker to capture some of the accesses by victim as shown in highlighted area in Figure 6.8 and the negative noise will not be useful. Figure 6.8 shows negative noise being introduced in the Barrett operation of RSA.

Design Cases for CRT Implementation of RSA

The rationale for Flush+Prefetch technique is motivated from the fact that blind noise injection will not preserve confidentiality even when the relationship between key bits and access of instruction-cache lines is known. We argue that, it might seem as if injecting noise in I-cache lines that belong to Square procedure of Square & Multiply exponentiation algorithm [6] will preserve the confidentiality of private key, but it is not sufficient. To support this argument, we consider an example execution with three threads namely; an Attacker thread with Flush+Reload technique, a Victim thread containing CRT implementation of RSA, and a Positive Noise thread targeting cache lines related to Square procedure. Figure 6.6 shows the resulting pattern captured by the attacker. The attacker was able to capture the "hit length (i.e. 1024 bits). Figure 6.11b shows that multiply-activations are 505 which is equal to the number of HIGH bits in key (i.e. 505 bits). Figure 6.11c shows that barrett-activations are about 1529 which is equal to the sum of total length (i.e. 1024 bits) and the number of HIGH bits (i.e. 505 bits) in the key. Later on, we show that such relation vanishes in the presence of the positive or negative noises. Results of an attacker without noise are taken as a reference to measure how much attacker is unable to extract square, multiply and barrett activations in the presence of noise. Also Figure 6.11a shows that the attacker has captured multiple cache hits (i.e. usually 8-11) on each square-activation. This is because attacker has targeted the instruction address which is in the loop body of square procedure, decreasing the probability of missing any square-activation. The reason for multiple cache hits per square activation is that the attacker has targeted the instruction belonging to a loop of the square procedure for decreasing the probability of missing any square-activation, as discussed in the Section 6.6.2. Between two consecutive square-activations there are barrett or multiply activations, so attacker perceived as gap between two consecutive square-activations, which lets the attacker to know about the start and end of each square-activation. Additionally, this Figure 6.13a shows a gap between two consecutive square-activations because Multiply or Barrett operations activate between them. This gap helps the attacker to figure out the start and end of each square-activation. Later on, we have showed that attacker is unable to know the start and end of square-activation in the presence of noise because such gaps are filled by positive noise or increased by negative noise. In terms of cache operations, noise increases or decreases the cache hits enormously during the encryption/decryption process of RSA, which confuses the attacker. In the next Section 6.7.2, we are showing mix noise case and their efficiency over Flush+Reload.

All-Positive and Mix-Noise Cases

Based on the results obtained for noise injection in individual instructions loops, we introduce two specific design cases of Flush+Prefetch. These design cases are developed with the aim of achieving confidentiality with minimum possible performance overhead. In the following, we discuss these cases one-by-one.

Design Case-1: Concurrent Positive Noise in all Instructions (Square, Multiply, and Barrett loops)

Results in Figures 6.13a, 6.13b and 6.13c show the number of cache hits per each vulnerable procedure activation captured by the attacker respectively. This is because of the fact that, earlier, the attacker used to determine the completion of an instance activation based on inactive intervals between any two consecutive activation instances. These inactive intervals, in this case, are now filled by the positive noise. As a result, the attacker perceives a continuity of activation instance without finding any inactive interval and thus, cannot determine the completion of an activation instance. Figures 6.13a, 6.13b and 6.13c also show that now the attacker is capable of capturing the square, multiply and barrett activations only up to 19%, 14.5% and 15.8% as compared to the reference patterns. These results reveal that the attacker will capture a random number of activation instances. Moreover, these captured instances will have no correlation with actual key bits anymore.

Thanks to the positive noise, victim does not experience any performance overhead in terms of execution time as compared to performance in the presence of attacker alone. Mean execution time in this design case is 1.9 ms less than the execution time of cryptographic process in the presence of attacker alone. This results in 10.2% improvement in execution time of web server application (victim process) while under Flush+Reload attack.

Design Case-2: Concurrent Positive Noise in Square & Multiply Loops and Negative Noise in Barrett Loop

In this design case, results are obtained by injecting two types of noise, simultaneously, i.e., positive noise in Square and Multiply loops and negative noise in Barrett loop. Figure 6.16 shows the cache access pattern in this design case. These results show two effects; First effect is the elimination of inactive intervals between consecutive square and multiply-activations due to positive noise as discussed in the Design Case-1 as well. Second effect is the cache misses between consecutive barrett-activations due to negative noise injection as discussed in Case-A of Section 6.6.2.

Results in Figures 6.17a and 6.17b show number of cache hits per square and multiply activation captured by the attacker, respectively. These results are similar to the ones discussed in Figures 6.13a and 6.13b. Positive noise injection fills the inactive intervals, which leads to a cache access pattern with much less activation instances and much higher hit rates for the attacker. Figures 6.17a and 6.17b show that square and multiply activations captured Results in Figure 6.17c show the number of cache hits per barrett-activation captured by the attacker. We obtained a significant reduction in the number of captured activation activations captured by attacker, as shown in Figure 6.17c, are about 95% less as compared to the number of activations in reference pattern of Figure 6.11c.

Results in Figures 6.13a, 6.13b and 6.13c show the number of cache hits per each vulnerable procedure activation captured by the attacker respectively. These results are different from the reference activation patterns shown in Section 6.7.1 in two ways. First, there is lack of consistency in the resulting pattern as compared to reference pattern for all procedures. Second, the captured activation instances of all procedures are much less as compared to reference activation patterns.

Results in Figures 6.17a, 6.17b and 6.17c reveal that the attacker will capture an even more random number of activation instances for all instructions compared to Design Case-1. Moreover, these captured instances will have even lesser correlation with actual key bits as well. Calculated mixing of positive and negative noise enhances the confidentiality aspect of the cryptographic operations with a significant margin in this design case. Results in Figure 6.18 show the execution time distribution of Design Case-2. Mean of this distribution is 17.1 ms, which indicates 8% improvement in execution time of web server application (victim process).

Performance Comparison

To the best of our knowledge, we have found that single path programming based countermeasure [START_REF] Rane | Raccoon: Closing Digital Side-Channels through Obfuscated Execution[END_REF] outperforms as compared to previous application level countermeasures [START_REF] Brickell | Software mitigations to hedge AES against cache-based software side channel vulnerabilities. jean-pierre.seifert@intel[END_REF][START_REF] Crane | Thwarting Cache Side-Channel Attacks Through Dynamic Software Diversity[END_REF]. Therefore, we have compared the performance of Flush+Prefetch with single path programming based countermeasure. We have evaluated the performance of both Flush+Prefetch and single path programming based countermeasure on the same computing setup used for security evaluation. Additionally, libpfm-4.10.0 library is used to measure the execution time of both countermeasures.

For performance comparison, we have converted the Square-and-Multiply implementation of RSA given in web-server by axTLS [START_REF] Rich | axTLS Embedded SSL[END_REF] into the single path as shown in Algorithm [START_REF] Rane | Raccoon: Closing Digital Side-Channels through Obfuscated Execution[END_REF]. All the inputs and outputs of Algorithm [START_REF] Rane | Raccoon: Closing Digital Side-Channels through Obfuscated Execution[END_REF] are same as compared to unmodified implementation of CRT [6]. The main difference of Algorithm [START_REF] Rane | Raccoon: Closing Digital Side-Channels through Obfuscated Execution[END_REF] as compared to original Algorithm [6] is that it operates the same sequence of operations Square-Barrett-Multiply-Barrett whether the bit value of secret is LOW or HIGH. For correct operation, after executing operations, code updates the variable depending on the key value.

We have taken the measurements of 10, 000 runs of both systems. Then mean of these measurements are calculated and compared. Table 6.8 shows the execution overhead of both countermeasures. We observed that execution time of RSA modified to single path programming overhead as compared to unmodified RSA is 72%. In case of Flush+Prefetch countermeasure, execution time overhead as compared to unmodified RSA is only 10%. Flush+Prefetch outperforms 62% as compared to RSA modified to single path programming. The execution time of single path approach is significantly larger because it executes costly multiply operation in each iteration of loop regardless of the secret bit. 6.9 Discussion

Synchronization of Threads

Synchronization between threads can enhance the security. However, synchronization introduces a performance overhead. Our work has shown that synchronization between victim and noise thread is not necessary till assumption of fair scheduler remains valid. Linux OS scheduler schedules each thread fairly, which directly ensures the addition of noise. Our results are justifying that the access-trace of vulnerable cache addresses becomes unintelligible to the attacker while relying on OS scheduler and without synchronization.

Generalization of Technique

As we discussed in related work, the countermeasure that prefetches the AES tables [START_REF] Brickell | Software mitigations to hedge AES against cache-based software side channel vulnerabilities. jean-pierre.seifert@intel[END_REF] incorporated the prefetch instruction within the application's execution flow. This requires modifying application radically to introduce prefetch instruction within the application. Hence, a generalization of this countermeasure is difficult for each application. But in our countermeasure, the prefetch instruction is independent of the application execution flow. Only memory addresses targeted by the attacker are required. These addresses can be figured out by seeing assembly files. These addresses are taken as input to noise threads and launched independently.

Secret Information Leakage form Data Cache

Flush+Prefetch countermeasure can obfuscate the leakage of secret information from data cache as well. This is because Flush+Prefetch countermeasure obfuscates accesses of interested cache lines only based on memory addresses, regardless of the fact that these addresses are mapped to instruction cache or data cache. For example in case of AES, memory accesses of T-table elements, which are cached in data cache, depend on the secret key. So prefetch and flush threads are provided with memory addresses that are mapped to T-tables. This will obfuscate the cache access footprint of AES algorithm.

Leakage of secret information depends on the algorithm. For example in case of RSA, execution of square and multiply instructions depends on key bit but operates on the same data. Therefore, instruction cache access will reveal key bit and data will be accessed in both cases whether the key is HIGH or LOW, so sequence of data cache accesses does not leak secret information. In contrast to RSA, AES secret key is leaked in exactly opposite to that of RSA. In case of AES, instruction access is same and data access varies depending on the secret key. Therefore, data cache accesses is interesting for the attacker. Our countermeasure takes memory addresses irrelevant to whatever the memory contain instruction or data. To counter data leakage using proposed countermeasure, the prefetch and flush threads target the memory addresses that are mapped to security critical data (such as T-table in AES) in data cache.

Mitigating Prime+Probe Attack using Flush+Prefetch Countermeasure

Prime+Probe attack also has three phases same as Flush+Reload attack but the way of probing the cache is different (explained in Chapter 3). In our countermeasure, prefetch thread loads the cache line similarly as victim, so prefetch thread also causes eviction and results in increase in access latency measured by attacker in third phase. Moreover, flush thread in our countermeasure also causes eviction of the cache lines and results in increase in access latency measured by attacker in third phase. Access pattern obtained using Prime+Probe will include the cache line accesses generated by victim, prefetch and flush threads, hence, the access pattern is obfuscated.

Core Utilization

For instance, it looks like that proposed countermeasure will occupy additional cores and performance overhead will be large. However, today SMT feature of CPU is disabled in servers because of the collocation of multiple threads can raise cache-based side-channel attacks. Disabling SMT feature underutilized the CPU resources because of data and control dependencies between instructions in the program. Therefore, instructions of noise threads, which are independent to RSA instructions (as in our countermeasure), can be fetched in single core along with RSA instructions and results in use of underutilized resources to mitigate the cache attacks in case of SMT enabled CPU.

We have measured the instructions per cycle (IPC) of axtls application to evaluate the underutilization of CPU. CPU having the top speed of 4.0 IPC while executing the axtls application can execute on average 2.92 instructions per cycle, which means that the axtls application under utilizing CPU of about 27% (= (1 -2.92/4)). The under-utilization of CPU can be used to execute instructions for security. In our case, we have limited the utilization of CPU by noise instructions (prefetch and clflush) by up to 1 IPC, which is within the range of measured underutilization of CPU, and observes sufficient addition of noise for security as shown by the results in Figures 6.12 and 6.16.

Summary

The first half of the Chapter proposes a novel OS-level run-time detection-based mitigation mechanism, called the Kingsguard, against CSCAs that enhances the security & privacy capabilities in general-purpose operating systems. Kingsguard mechanism uses multiple machine learning models for run-time detection and relies on the profiling of concurrent processes, which are collected directly through the hardware events using HPCs in near realtime. We demonstrate that Kingsguard is capable of detecting and subsequently mitigating Prime+Probe, Flush+Reload and Flush+Flush attacks on AES and RSA cryptosystems while running under Linux general-purpose distribution. We support our claims with extensive experimental evaluation. We also demonstrate that the proposed mechanism is resilient to noise generated by the system under various loads. These variable load conditions are achieved by concurrently running memory-intensive SPEC benchmarks on the system along with the encryption and attack processes. Our results show that Kingsguard can mitigate known CSCAs with an accuracy of > 95% in most cases. To the best of our knowledge, this is the first research work that provides a run-time detection-based mitigation against CSCAs for Linux general-purpose distributions. Though we demonstrate the effectiveness of Kingsguard on Linux mainly, it is scalable to other operating systems as well. Moreover, attacks can happen in any temporal order in practice. Therefore, we have also analyzed the effect of combination of multiple known CSCAs. We have performed experiments with multiple attacks running simultaneously on the same computing platform and provided results on their mitigation. The reported mitigation accuracy of Kingsguard for simultaneously occurring homogeneous and simultaneous occurring heterogeneous attack combinations remains above 97% and 89%, respectively. The second half of the chapter proposes a novel application-level countermeasure technique, called Flush+Prefetch, against Flush+Reload category of cache-based side channel attacks. The proposed countermeasure is easily deployable and works without the requirement of specialized hardware features or any profound changes to system-level software. Flush+Prefetch technique uses intelligent noise injection to improve confidentiality of the victim process, i.e., the applied cryptosystem. The countermeasure uses independent threads that consist of pref echt and cf lush instructions to generate noise. Our experimental results show that the confidentiality of cache accesses made by RSA is preserved under Flush+Prefetch technique as the leakage of information is reduced to 22.3% only as compared to 96.7% bit recovery reported by Flush+Reload attack in a single decryption round. Results show that the leaked information is scattered and does not contain any specific pattern, i.e., either bit position or bit value, that can facilitate the establishment of secret key for RSA cryptosystem even if the attacker intends to do multiple iterations. Our results show that the performance, in terms of average execution time, is improved by 10.2% for best design case compared to the system under Flush+Reload attack.

Flush+Prefetch technique practically demonstrates that noise-based solutions are viable countermeasures and good candidates for quick-patch solution against precision attacks like Flush+Reload. The proposed countermeasure can be extended for other type of cache-based SCAs such as Prime+Probe.

Publications related to this chapter

Our main contributions discussed in Sections 6. Chapter 7

Conclusion and Future Work

This chapter concludes the thesis. The chapter summarizes, in an abstract manner, our contributions related to cache-based side-channel attacks, their detection framework and mitigation mechanism for Intel x86 architecture. Towards the end, it provides discussion on the future directions, trends and research perspectives in side-channel attack, detection and mitigation strategies.

Summary of the thesis

Attacks exploiting microarchitectural vulnerabilities such as: Prime+Probe, Flush+Reload, Flush+Flush, Spectre and Meltdown etc., are escalating the issue of security and prove to be a serious threat to contemporary processors. Modern processors contain many software and hardware performance optimization tools and techniques, such as: hierarchical and sharedmemory architectures, pipelining, out-of-order execution, speculative execution, branch prediction, data/instruction de-duplication, shared libraries, compiler optimizations, use of virtual memory and use of specialized hardware accelerators and GPUs. To date, during design phase of new architectures, performance optimization is kept as a first-class design constraint, whereas, security aspect has been neglected for far too long. Generally, hardware has been considered as an abstract layer that behaves correctly and efficiently -executing instructions and giving a logically correct output. But side-channels in the computing hardware have made it possible to leak security critical information when the software executes on underlying hardware. It opens up many questions regarding the existence of critical hardware/software vulnerabilities and their consequent impact on the security and privacy features of these architectures. Cache-based side-channels have gained importance in the recent years as they are getting sophisticated and stealthier channels of information leakage. Over the past few years, CSCAs have become demonstrably serious threat to modern processors.

While looking at the existing solutions, there have been many proposed mitigation solutions (see Chapter 2) both at hardware and software levels. Hardware-based solutions require a complete re-design of architecture, whereas, software solutions serve as quick patches to specific vulnerabilities only, such as: logical isolation, scheduling-based and obfuscation-based solutions. Thorough analysis of state-of-the-art reveals that hardware and software-based solutions only work for a specific level of cache. Moreover, they mainly target any one specific vulnerability (i.e., they mitigate against a specific attack or a leakage channel). Adding to the problem, both hardware and software solutions cause massive performance overheads and huge monetary costs in case of architecture re-design. In this thesis, we conclude that the problem with the mitigation solutions against cache-based side-channel information leakage is three-pronged: (1) mitigation solutions do not provide a system-wide approach to protect leakage across the entire computing stack, (2) mitigation solutions cause heavy performance and monetary costs due to blanket protection against SCAs. That is, without assessing if the system is under attack, mitigation solutions are applied at all times, which cause performance degradation and (3) mitigation solutions are vulnerability-specific and non-scalable. They do not protect against a large set of existing/known attacks, let alone be capable of protecting against unknown new attacks and leakage channels. This PhD thesis attempts to solve these aforementioned problems with the existing mitigation solutions at the software level. In order to retain the performance benefits while improving the security and privacy in modern computing systems, we argue in favour of a run-time detection-based protection approach to mitigate CSCAs. We argue that detectionbased protection would help applying mitigation only if the presence of an SCA is successfully assessed/detected at run-time. Such a solution would remove the restrictive model of blanket protection at all times and consequently reduce, if not completely remove, the performance degradation. Such an approach, however, has its own challenges. For instance, for detectionbased protection strategies to be effective, detection needs to be highly accurate, should incur minimum system overhead at run-time, should cover a large set of attacks and should be capable of early-stage detection, i.e., before the completion of an attack at the very least. The detection framework that we propose in this thesis is effectively evaluated using these stringent evaluation metrics.

In this thesis, at first, we propose a machine learning based CSCA detection framework for Intel's x86 architectures. The framework comprises of multiple individual machine learning models, as well as integrated in an Ensemble fashion, that use real-time behavioral data of concurrent processes running on Intel's x86 architecture. Our detection framework is capable of detecting a large set of the state-of-the-art attacks without the need of retraining its 7.1 Summary of the thesis | 207 machine learning models for each specific attack type. We provide extensive experimentation with 9 different attacks and evaluate the framework under stringent constraints, such as: detection accuracy, speed, performance overhead and distribution of error (i.e., false positives and false negatives). Our results show very high detection accuracy, i.e., > 99%, with negligible error rate. The proposed framework is light-weight and easily embedded in the target cryptosystems for run-time detection.

Using our detection framework, we have proposed an OS-level run-time detection-based mitigation mechanism in this thesis. The proposed mechanism enhances the security & privacy capabilities in general-purpose operating systems. The mechanism uses multiple machine learning models for run-time detection and relies on the profiling of concurrent processes, which are collected directly through the hardware events using HPCs in near real-time. We have demonstrated that the mechanism is capable of detecting and subsequently mitigating Prime+Probe, Flush+Reload and Flush+Flush attacks on AES and RSA cryptosystems while running under Linux general-purpose distribution. We also demonstrate that the proposed mechanism is resilient to noise generated by the system under various loads. These variable load conditions are achieved by concurrently running memory-intensive SPEC benchmarks on the system along with the encryption and attack processes. Our results show that such mitigation mechanism can mitigate known CSCAs with an accuracy of > 95% in most cases. To the best of our knowledge, this is the first research work that provides a run-time detection-based mitigation against CSCAs for Linux general-purpose distributions. Though we have demonstrated the effectiveness of detection-based mitigation on Linux mainly, it is scalable to other operating systems as well. We have also analyzed the effect of combination of multiple known CSCAs. We have performed experiments with multiple attacks running simultaneously on the same computing platform and provided results on their mitigation. The reported mitigation accuracy for simultaneously occurring homogeneous and simultaneous occurring heterogeneous attack combinations remains above 97% and 89%, respectively.

In order to validate our proposed detection and mitigation solutions, we have implemented/reproduced at least 9 different CSCAs and attacks relying on CSCAs on Intel machines (core i5, core i7) and prepared a library of attacks for the use of community at large. These attacks include: Spectre, Meltdown, Prime+Probe, Flush+Reload, Flush+Flush and their variants. Readers can access, reproduce and distribute the source code for these implementations at the Github repository at [198]. Implementation of these attacks provided a thorough experimental validation to our work. This thesis brings value-addition and novelty in many ways. Instead of conventional approaches, we have argued in favor of using a dynamic run-time detection-based mitigation approach against CSCAs at OS-level. We have supported our arguments with extensive experimental validation and results on a large set of known attacks. In this thesis, we have used hardware and software performance counters as useful instrumentation tool to predict run-time system behaviors. Hardware and software events are conventionally used for performance monitoring. We have shown that their careful selection and use at a higher abstraction layer can help protecting against CSCAs at run-time. Hardware and software events alone are not sufficient enough for detection and subsequent mitigation, such as used in the state-of-the-art previously. Therefore, in this thesis, we built an argument that machine learning techniques, when coupled with the run-time behavioral information about the system collected using these events, can be used to improve the security and privacy in modern processors. We have demonstrated that machine learning has the potential to greatly enhance the capability of systems to detect (known as well as unknown) malicious activities such as side-and covert-channel attacks. Thus, a machine learning based solution is scalable for future unknown attacks. Compared to existing state-of-the-art, we have demonstrated that our proposed detection-based mitigation mechanism is resilient to noise generated by the system under various loads, which represent realistic operating conditions.

Future Trends and Research Perspectives

The real challenge in ensuring information security and privacy today is the issue of constructing safe systems against microarchitectural attacks that exploit side-channels for information leakage. As of today, the real attack surface is unknown, both at the software level and at the hardware level. Moreover, the proposed countermeasures are rarely adopted in practice. This thesis is an attempt in this direction, however, it is not enough. The discovery of new side-channels and vulnerabilities has become a constant feature, which has opened up many new research directions. In this section, we discuss some of the future research directions, trends and challenges associated with side-channel information leakage.

Future Trends in Attacks

The biggest challenge is the consistent appearance of newer, smarter and stealthier sidechannel attacks. Extensive literature in the state-of-the-art reveals that attacks have been practically demonstrated across the entire computing stack. Similarly, cache-based attacks have targeted all levels of cache hierarchy from L1(D/I) to LLC.

One of the fundamental research challenges in the prevention of side-channel information leakage is the way conventional architectures perform computation and storage. Historically, the focus has always been on performance enhancement, which has led to a competitive market where manufacturers of these architecture do not reveal all documentation related to their products. Thus, in the absence of such documentation, the mitigation research is primarily driven based on hypotheses related to the functioning and behavior of microarchitectural components. Previous research works have shown that, at the hardware level, having the right hypotheses on these microarchitectural components is not a straightforward task, and that these hypotheses can be either insufficient, changing or simply wrong. It is an interesting fact that, until now, all known side-channels have been found manually, often by analyzing available documentation. So far, at the software level, most attacks and countermeasures have targeted cryptographic primitives. However, recent trends show that microarchitectural attacks can be used to spy on keystroke timings or to bypass system security mechanisms as well. The software attack surface is therefore expanding and more work is needed in order to establish whether a whole system is vulnerable or immune to microarchitectural attacks. Most of the recent research work related to side-channel attacks has targeted Intel x86 architecture. Another interesting dimension of the future research work can be to see the impact of these attacks on different execution platforms other than Intel x86 architecture. It will be interesting to understand if similar vulnerabilities can be exploited in other architectures or new vulnerabilities can be found, which are more or less immune to SCAs. Some interesting target architectures can be ARM TustZone, Intel SGX and AMD processors. Future attacks will be targeting computational part as well as storage part. Spectre and Meltdown are excellent examples of such attacks. Therefore, it will be interesting to analyze the vulnerabilities linked with both computation and storage, such as: branch predictions, out-of-order and speculative execution units, hardware accelerators and execution ports, cache directories, TLBs and DRAMs etc.

From the current trends and research, it is evident that new microarchitectural attacks will keep appearing in the future. One important future research direction could be to systematize the discovery of side-channels in microarchitectures that could help the community to anticipate and focus their solutions accordingly. An investigation of root causes of these side-channels in microarchitectures and the subsequent analysis of the combination of different known side-channels and their influence on information leakage could be very useful for future research in understanding microarchitectural attacks. Such an analysis would help understand if information leaked by different side-channels can add up, or if the side-channels interfere with one another. It is anticipated that future attacks would use multiple cooperative processes to create side and covert channels for information retrieval. Therefore, future research should also focus on the automated methods to assess the security of the microarchitectures. A better understanding of attack behavior would naturally lead to effective mitigation.

Future trends in detection mechanisms

We believe that a lot of concepts from the field of malware and intrusion detection can be borrowed to solve the problem of CSCA detection. The field of malware detection seems to have more maturity, therefore, a lot of research ideas can be adopted for the case of CSCA detection. To date, almost all of the proposed CSCA detection solutions work entirely in the software. Therefore, an important future direction would be to explore possibility of hardware implementation of the proposed solutions or to think of hardware solutions from scratch. These hardware solutions can accelerate the response of detection solutions in the presence of an attack. Moreover, hardware-based solutions can lead to faster mitigation solutions as well without involvement of software or OS. For instance, in case a hardware detector detects an attack, the processor pipeline can be sent a signal to stall instantaneously (without any lag due to software involvement) to make sure that no critical information is lost. Possible choices for implementation of hardware solutions include: FPGAs, separate cores or hardware accelerators.

We have observed from our study of the state-of-the-art research that the proposed techniques usually use a limited set of attacks for validation. Moreover, often the proposed machine learning classifiers used in these detection solutions are attack specific. We believe that in future the community needs to come up with more inclusive solutions and validate them on a wider variety of attacks. Similarly, the need to build detection techniques that would work for zero-day/unknown or modified attacks is evident. As argued widely in this thesis, there is a need for detection based CSCA mitigation solutions. So far, we have not seen research works that integrate the two. It is important to experiment with such ideas as their integration would expose new challenges that are not being observed as yet.

As demonstrated, machine learning has been able to help CSCA detection techniques significantly. However, as a future direction, there are other areas that can be applied to solve CSCA detection problem. These areas include Deep Learning, Game Theory and Fuzzy Logic. These areas have already been extensively applied to solve the problem of malware and intrusion detection. Almost all of the proposed CSCA detection techniques so far focus on Intel's x86 architecture. However, attacks on other architectures like ARM have also been proposed in the state-of-the-art. Since characteristics of attacks on different architectures can be different, therefore, the challenges to detect such attacks can also be different for different architectures. As a future research direction, it would be worthwhile to study detection of CSCAs on other architectures as well.

Similarly attacks on ARM TrustZone have been shown to be possible. However, a detailed study of such attacks and demonstration of their detection is still missing. In literature, we have noticed that the studied detection techniques mainly focus on detection of CSCAs that target cryptographic execution (e.g. RSA, AES, ECDSA). However, CSCAs exist on other targets as well like user and kernel space ASLR (Address Space Layout Randomization) and other environments like browsers and non-native code (e.g. javascript). In the future, researchers will have to come up with detection-based mitigation techniques for attacks against such targets as well.

Future Trends and Research Perspectives | 211

There exist research works that have proposed techniques to detect side-channel vulnerabilities using program analysis as well. Since program analysis can reveal loopholes prior to execution, combining such techniques with CSCA detection methods can help in increasing the confidence in detection as well as reduce the burden on run-time detection techniques. Moreover, compiler assistance can prove to be useful in this regard as well. Such solutions would also help to reduce performance overheads of run-time detection. It is obvious that, at the moment, there exist quite a few challenges in this field of CSCA detection techniques and there is a need to invest more resources and minds in this domain to solve these critical problems.

Another interesting research direction for the future is to look at the use of adversarial machine learning in detection and mitigation against CSCAs. Computing paradigms are shifting towards the use of machine learning models due to their ability to process exponentially increasing data more efficiently and their ability to analyse useful data before their storage. Although machine learning has proved to be very useful in Big data analytics, it has also introduced some security vulnerabilities due to the use of adversarial machine learning techniques. From an attacker's perspective, such use-cases can be taken as example to check the robustness of detection-based mitigation mechanisms that are based on machine learning. Interestingly, the traditional security measurement methods are not very useful to handle such vulnerabilities introduced by machine learning models. It will be interesting to see the impact of adversarial machine learning in the sense that whether it is able to compromise the run-time detection or not.

Future Trends in Mitigation Mechanisms

A general and somewhat obvious trend in mitigation techniques over the last decade is to prepare defences against known attacks only. However, this trend is now shifting towards more Secure-by-Design approaches in hardware as well as in software. From hardware perspective, architecture platforms such as Intel's SGX and HARP or ARM's TrustZone are some serious attempts in this direction. Recent software-based countermeasure techniques are also motivated by secure-by-design approach. For instance we proposed, operating system based countermeasure techniques that use run-time monitoring of system performance using PMUs is one such approach coming in practice. The proposed approach offered detection as well as mitigation against attacks on-the-fly, which helps reduce performance overheads. Such OS-based countermeasure techniques can help in obfuscateing the execution order of processes to prevent leakage of useful timing and access information at cache level. Some recent research work strongly argues in favor of resource isolation alone as defence against SCAs. Such countermeasures, though very effective from security perspective, are simply not viable for certain application domains, such as cloud computing, where security presents a trade-off with fundamental economic model that is based on resource sharing in this case. Existing solutions based on resource isolation propose to isolate process execution physically and temporally. Therefore, future mitigation techniques must have a holistic approach and provide solutions that are not necessarily based entirely on resource isolation. This thesis has limited its scope to the analysis, detection and mitigation of software sidechannel attacks. It is imperative, however, to acknowledge and understand the importance of microarchitectural design weaknesses, which can not be resolved by software solutions alone. In order to patch up the microarchitectural vulnerabilities, research must focus on designing new hardware architectures, both from computational and storage perspectives, in such a way that it solves the problem of security without affecting the performance benefits of already proposed hardware design. Hardware and software co-design with security being the first-class design constraint along-side performance can only solve these issues and become a long-term solution.

ments in favor of enhancing security and privacy in modern computing architectures while retaining the performance benefits. The thesis argues in favor of a need-based protection, which would allow the operating system to apply mitigation only after successful detection of CSCAs. Thus, detection can serve as a first line of defense against such attacks. However, for detection-based protection strategy to be effective, detection needs to be highly accurate, should incur minimum system overhead at run-time, should cover a large set of attacks and should be capable of early stage detection, i.e., before the attack completes. This thesis proposes a complete framework for detection-based protection. At first, the thesis presents a highly accurate, fast and lightweight detection framework to detect a large set of Cache-based SCAs at run-time under variable system load conditions. In the follow up, the thesis demonstrates the use of this detection framework through the proposition of an OS-level run-time detection-based mitigation mechanism for Linux general-purpose distribution. Though the proposed mitigation mechanism is proposed for Linux general distributions, which is widely used in commodity hardware, the solution is scalable to other operating systems. We provide extensive experiments to validate the proposed detection framework and mitigation mechanism. This thesis demonstrates that security and privacy are system-wide concerns and the mitigation solutions must take a holistic approach.

2. 5

 5 State-of-the-Art software countermeasures for different levels of Cache and threat model within Intel x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 List of Selected Cache SCAs & CCAs as Use-Cases . . . . . . . . . . . . . . . 3.2 Summary of the State-of-the-Art Cache-based Attacks . . . . . . . . . . . . . 3.3 List of Security Papers Using HPCs in SCAs . . . . . . . . . . . . . . . . . . 3.4 List of Machine Learning Models for CSCA Detection (Non-exhaustive) . . . 4.1 Selected events related to cache-based SCAs . . . . . . . . . . . . . . . . . . . 4.2 Selected events related to particular cache-based SCAs . . . . . . . . . . . . .4.3 Results using LDA, LR, SVM & QDA models for Flush+Reload attack detection with RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Results using LDA, LR, SVM & QDA models for Flush+Reload attack detection with AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Results using LDA, LR, SVM & QDA models for Flush+Flush attack (Impl1) detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Results using LDA, LR, SVM & QDA models for Flush+Flush attack (Flush+Flush Impl2) detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . List of Tables | xxi 4.7 Results using LDA, LR, SVM & QDA models for Prime+Probe (Impl1) attack detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Results using LDA, LR, SVM & QDA models for Prime+Probe (Impl2) attack detection with AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Selected events related to use-case CSCAs . . . . . . . . . . . . . . . . . . . . 4.10 Results using individual and Ensemble ML models for detection of Prime+Probe (Impl1: half-key recovery) on AES at fine-grain sampling. . . . . . . . . . . . 4.11 Results using individual and Ensemble ML models for detection of Prime+Probe (Impl2: full-key recovery) on AES at fine-grain sampling. . . . . . . . . . . . . 4.12 Results using individual and Ensemble ML models for detection of Prime+Probe (Impl1: half-key recovery) on AES at coarse-grain sampling. . . . . . . . . . . 4.13 Results using individual and Ensemble ML models for detection of Prime+Probe (Impl2: full-key recovery) on AES at coarse-grain sampling. . . . . . . . . . . 4.14 Results using individual and Ensemble ML models for detection of Flush+Reload (Impl1: half-key recovery) on AES at fine-grain sampling. . . . . . . . . . . .4.15 Results using individual and Ensemble ML models for detection of Flush+Reload (Impl2: full-key recovery) on AES at fine-grain sampling. . . . . . . . . . . . . 4.16 Results using individual and Ensemble ML models for detection of Flush+Reload (Impl1: half-key recovery) on AES at coarse-grain sampling. . . . . . . . . . . 4.19 Results using individual and Ensemble ML models for detection of Flush+Flush (Impl2: full-key recovery) on AES at fine-grain sampling. . . . . . . . . . . . . 4.17 Results using individual and Ensemble ML models for detection of Flush+Reload (Impl2: full-key recovery) on AES at coarse-grain sampling. . . . . . . . . . . 4.18 Results using individual and Ensemble ML models for detection of Flush+Flush (Impl1: half-key recovery) on AES at fine-grain sampling. . . . . . . . . . . . 4.20 Results using individual and Ensemble ML models for detection of Flush+Flush (Impl1: half-key recovery) on AES at coarse-grain sampling. . . . . . . . . . . 4.21 Results using individual and Ensemble ML models for detection of Flush+Flush (Impl2: full-key recovery) on AES at coarse-grain sampling. . . . . . . . . . . 5.1 Selected Performance counters for Spectre . . . . . . . . . . . . . . . . . . . . 5.2 Selected Performance counters for Meltdown . . . . . . . . . . . . . . . . . . . 5.4 Detection results using LDA, LR, SVM & CNN models for Spectre variant 2 xxii | List of Tables 5.5 Detection results using LDA, LR, SVM & CNN models for Meltdown . . . . 5.3 Detection results using LDA, LR, SVM & CNN models for Spectre variant 1 6.1 Recall: List of selected CSCAs as use-cases along with their key recovery time on Intel's core i7 machine for Kingsguard. . . . . . . . . . . . . . . .

Contents 1 . 1 1 1. 2 3 1. 3 4 1. 4 7 1. 5 10 1. 6

 1112334475106 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vulnerabilities in Modern Computing Systems . . . . . . . . . . . . . . . Side-channel Attacks (SCAs) . . . . . . . . . . . . . . . . . . . . . . . . . Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contributions and Organization of Manuscript . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

( a )

 a Typical organization of a set-associative cache for effective addressing.(b) Shared address space between any two processes due to shared libraries and data/instruction de-duplication.

Figure 1 . 4 -

 14 Figure 1.4 -Exploitation of cache memory organization and sharing by CSCAs in Intel's x86 architecture.

Figure 3 . 2 -

 32 Figure 3.2 -Threshold Determination for Prime+Probe Attack

Figure 3 . 6 -

 36 Figure 3.6 -Threshold Determination for Flush+Reload Attack

Figure 3 . 11 -

 311 Figure 3.11 -Threshold Determination for Flush+Flush Attack

Listing 3 . 2 -

 32 Spectre variant 1 code snippet 1 . i f ( x < a r r a y 1 _ s i z e ) 2 . y = a r r a y 2 [ a r r a y 1 [ x ] * 4 0 9 6 ] ;

Figure 4 . 9 -

 49 Figure 4.9 -Accuracy Comparison of ML Models for Flush+Reload (RSA)

Figure 4 . 10 -

 410 Figure 4.10 -Accuracy Comparison of ML Models for Flush+Flush (AES)

Figure 4 .

 4 Figure 4.23 illustrates an abstract view of the methodology used in WHISPER tool. As illustrated in Figure4.23, the tool collects behavioral data of concurrent processes at run-time using HPCs similar to the NIGHTs-WATCH. These data comprise of selected hardware events, as discussed in Section 4.7 for WHISPER tool, which are fed to an Ensemble machine learning model. The Ensemble is composed of multiple machine learning models that take

Figure 4 . 38 -Algorithm 1 : 5 if i mod SamplingGranularity == 0 then 6 Activate_Detection() 7 events ← Read_Hardware_Events() 8 votes ← ML_Classifiers(events) 9 report

 438156789 Figure 4.38 -Accuracy Comparison of ML Models for 6 Attacks

2 & 4 .6 are given below: 1 .

 241 M. Mushtaq, A. Akram, M. K. Bhatti, A. Usman, V. Lapotre, G. Gogniat., NIGHTs-WATCH: A Cache-Based Side-Channel Intrusion Detector using Hardware Performance Counters, Published at ISCA-HASP, Los Angeles, USA, 2018.

  1. B. Ahmad, M. Mushtaq, M. K. Bhatti, A. Usman., What Do We Say To Spectre & Meltdown? Not Today!, Under submission at the 25th Asia and South Pacific Design Automation Conference, ASP-DAC 2020, Jan 13-16, 2020, Beijing, China.

Figure 6 . 5 -

 65 Figure 6.5 -Timing information of Flush+Prefetch: Different cases of positive noise.

Figure 6 . 6 -

 66 Figure 6.6 -Cache access pattern: Prefetching by positive noise thread in Square & Multiply loops.

Figure 6 . 7 -

 67 Figure 6.7 -Timing information of Flush+Prefetch: Different cases of negative noise.

Figure 6 . 8 -

 68 Figure 6.8 -Cache access pattern: Eviction by negative noise thread in Barrett loop.

Figure 6 . 11 -

 611 Figure 6.11 -Activation pattern without noise, taken as a reference for confidentiality of (a) Square procedure (b) Multiply procedure (c) Barrett procedure.

Figure 6 . 12 -

 612 Figure 6.12 -Graphical representation of cache access pattern with positive noise at square, multiply and Barrett loop addresses.

Figure 6 . 13 -

 613 Figure 6.13 -Activation pattern of (a) Square procedure (b) Multiply procedure (c) Barrett procedure for Design-Case 1.

Figure 6 . 14 -

 614 Figure 6.14 -Barrett pattern in presence of negative noise.

Figure 6 . 15 -

 615 Figure 6.15 -Execution time distribution of victim's process with attacker and positive noise at square, multiply and barrett loops.

Figure 6 . 16 -

 616 Figure 6.16 -Graphical representation of cache hits and misses with positive noise at square-multiply loops and negative noise at barrett loop addresses.

Figure 6 . 17 - 199 Figure 6 . 18 -

 617199618 Figure 6.17 -Activation pattern of (a) Square procedure (b) Multiply procedure (c) Barrett procedure for Design-Case 2.

  3 & 6.5 are given below: 1. M. Mushtaq, M. M. Yousaf, M. K. Bhatti, V. Lapotre, G. Gogniat., Kingsguard: OS-level Mitigation against Cache Side-Channel Attacks using Run-time Detection, Under review at IEEE Trans. on Dependable and Secure Computing (TDSC), 2019. 2. M. A. Mukhtar, M. Mushtaq, M. K. Bhatti, V. Lapotre, G. Gogniat., Smart Flush: A Timing Countermeasure against FLUSH+RELOAD Cache-based Side-Channel Attack on RSA, Under major review at Elsevier Journal of Systems Architecture, 2019.

Contents 7 . 1 205 7. 2 Future

 712052 Summary of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trends and Research Perspectives . . . . . . . . . . . . . . . . . . 208

  1.1 Three tenets model of attack illustrated by[START_REF] Hughes | Quantitative Metrics and Risk Assessment: The Three Tenets Model of Cybersecurity[END_REF]. . . . . . . . . . . . . . . . . . 1.2 Unintended Side-Channel information leakage. . . . . . . . . . . . . . . . . . 1.3 An abstract view of shared memory at different levels of Cache hierarchy. . . 1.4 Exploitation of cache memory organization and sharing by CSCAs in Intel's x86 architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Victim's confidential information leaked by Prime+Probe Attack-Full Key retrieval of AES cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Working principal of Flush+Reload . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Threshold Determination for Flush+Reload Attack . . . . . . . . . . . . . . . 3.7 Victim's confidential information leaked by Flush+Reload Attack-Half Key retrieval of AES cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . Victim's confidential information leaked by Flush+Reload Attack-Full Key retrieval of RSA cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Working principal of Flush+Flush . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Threshold Determination for Flush+Flush Attack . . . . . . . . . . . . . . . . 3.12 Victim's confidential information leaked by Flush+Flush Attack-Half Key retrieval of AES cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13 Victim's confidential information leaked by Flush+Flush Attack-Full Key retrieval of AES cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 Working Principal of Meltdown . . . . . . . . . . . . . . . . . . . . . . . . . . List of Figures | xvii 4.27 Experimental results showing selected hardware events under no load condition for Flush+Reload attack on AES. . . . . . . . . . . . . . . . . . . . . . . . . . 4.28 Experimental results showing hardware events under Full Load conditions for Flush+Flush attack on AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.29 Experimental results showing selected hardware events under No Load conditions for 6 CSCAs on AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.30 Experimental results showing selected hardware events under Average Load conditions for 6 CSCAs on AES. . . . . . . . . . . . . . . . . . . . . . . . . . 4.31 Experimental results showing selected hardware events under Full Load conditions for 6 CSCAs on AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 ROC Curve for Ensemble model: Detecting Prime+Probe on AES under FL conditions at fine-grain detection. . . . . . . . . . . . . . . . . . . . . . . . . . 4.41 Run-time behavior of selected hardware events under NL conditions for Flush+Reload Impl1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.42 Run-time behavior of selected hardware events under FL conditions for Flush+Reload Impl2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . List of Figures | xix 6.13 Activation pattern of (a) Square procedure (b) Multiply procedure (c) Barrett procedure for Design-Case 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.14 Barrett pattern in presence of negative noise. . . . . . . . . . . . . . . . . . . 6.15 Execution time distribution of victim's process with attacker and positive noise at square, multiply and barrett loops. . . . . . . . . . . . . . . . . . . . . . . 6.16 Graphical representation of cache hits and misses with positive noise at squaremultiply loops and negative noise at barrett loop addresses. . . . . . . . . . . 6.17 Activation pattern of (a) Square procedure (b) Multiply procedure (c) Barrett procedure for Design-Case 2. . . . . . . . . . . . . . . . . . . . . . . . . . . .

	List of Figures | xv
	3.9

1.5 An abstract view of implementation of cryptosystems on underlying hardware. 2.1 Representative Cache Architecture of Intel Processors . . . . . . . . . . . . . 2.2 Principle of Time-driven Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Principle of Trace-driven Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Classification of CSCA Detection Techniques . . . . . . . . . . . . . . . . . .

3.1 Working principal of Prime+Probe . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Threshold Determination for Prime+Probe Attack . . . . . . . . . . . . . . . 3.3 Victim's confidential information leaked by Prime+Probe Attack-Half Key retrieval of AES cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 3.8 Victim's confidential information leaked by Flush+Reload Attack-Full Key retrieval of AES cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 Victim's confidential information leak by Meltdown attack. . . . . . . . . . . 3.16 Working Principal of Spectre . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.17 Victim's confidential information leaked by Spectre attack. . . . . . . . . . . 3.18 Experimental results on HPCs to showcase the real time execution behavior of 4.32 Results for data density between L1_DCM & L3_TCA under FL conditions -All attacks combined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.33 Results for data density between L1_DCM & L3_TCM under FL conditions -All attacks combined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.34 Results for data density between L1_DCM & TOT_CYC under FL conditions -All attacks combined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.35 Results for data density between L3_TCA & L3_TCM under FL conditions -All attacks combined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.36 Results on data reduction and visualization using t-SNE algorithm under NL conditions -All attacks combined. . . . . . . . . . . . . . . . . . . . . . . . . . 4.37 Results on data reduction and visualization using t-SNE algorithm under FL conditions -All attacks combined. . . . . . . . . . . . . . . . . . . . . . . . . . 4.38 Accuracy Comparison of ML Models for 6 Attacks . . . . . . . . . . . . . . . 4.39 Run-time behavior of selected hardware events under FL conditions for Prime+Probe Impl1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.43 Run-time behavior of selected hardware events under NL conditions for Flush+Flush Impl1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.18 Execution time distribution of victim's process with attacker, positive noise at square-multiply loops and negative noise at barrett loop. . . . . . . . . . . . .

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Comparative Summary of CSCA Detection Mechanisms . . . . . . . . . . . . 2.3 State-of-the-Art on hardware/software Countermeasure Techniques w.r.t. Cache Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 State-of-the-Art software countermeasures categorization . . . . . . . . . . . .

  . . . . . 6.2 Performance overhead at different stages for Kingsguard mechanism while detecting Flush+Reload attack on RSA. . . . . . . . . . . . . . . . . . . . . . 6.3 Detection time taken by different machine learning models under different load conditions for Flush+Flush atack on AES. . . . . . . . . . . . . . . . . . . . . 6.4 Encryption time taken by RSA and AES crypto-systems while under various attacks and variable load conditions. . . . . . . . . . . . . . . . . . . . . . . .

6.5 Mitigation accuracy of Kingsguard under simultaneously occurring homogeneous attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Mitigation accuracy of Kingsguard under simultaneously occurring heterogeneous attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Comparison of effect of positive and negative noises on execution time (Legends are such as +Squ: Positive noise in Square loop, +Mul: Positive noise in Multiply loop, +Bar: Positive noise in Barrett loop, -Squ: Negative noise in square loop, -Mul: Negative noise in multiply loop and -Bar: Negative noise in barrett loop). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 Execution Time Comparison with Unmodified Web Server . . . . . . . . . . . Chapter 1 Introduction This chapter provides the foundational knowledge and background motivation in order to set the context for this research work. We establish the threat model for cache-based side-channel information leakage in contemporary computing architectures and provide a non-exhaustive list of logical attacks that have targeted various cryptosystems in the recent past. Based on the presented threat model and vulnerabilities, we discuss open research problems caused by the side-channel information leakage. Towards the end, we formulate the specific research problem addressed in this thesis and summarize our contributions.

Table 2 .

 2 2 -Comparative Summary of CSCA Detection Mechanisms

	Reference	Design Cat-egory	Example Attacks	Detection Accu-racy	Detection Speed	Detection over-head	ML-Based	Attacker Identifi-cation	Use of HPCs	Impl. Level	Load/ Noise
							Yes
	Demme et al [75]	Signature-tion Based Detec-	P+P	100%	N/A	N/A	(KNN, and DT, RF	Yes	Yes	Application ware & Hard-	N/A
							ANN)
	Allaf et al [31]	Signature-Based Detec-tion	F+R & P+P	97% (F+R), 98% (P+P)	2% time to of attack complete	N/A	Yes (NN, KNN) DT,	Yes	Yes	Yes	Yes
	Allaf et al [76]	Signature-Based Detec-tion	F+R	99% (Na-tive), 96% (Cloud)	N/A	N/A	Yes (KNN)	Yes	Yes	Application	Yes
	Mathias Payer [77]	Signature-Based Detec-tion	F+R & P+P	100%	N/A	< 2%	No	Yes	Yes	Kernel	No
	Peng et al [78]	Signature-tion Based Detec-	F+R	100%	N/A	N/A	No	Yes	Yes	Application	No
	Briongos et al [79]	Signature-tion Based Detec-	F+R	>96%	N/A	N/A	No	N/A	Yes	Application	Yes

Note: N/A: Not Available/Applicable, HPC: Hardware Performace Counter, P+P: Prime+Probe, F+R: Flush+Reload, F+F: Flush+Flush, E+T: Evict+Time, VM: Virtual Machine, CVM:

Cross Virtual Machine, Impl:Implementation ML: Machine Learning. Also, note that the mentioned detection accuracy, speed and overhead are the best-case measures for each technique

	Reference	Design Cat-egory	Example Attacks	Detection Accu-racy	Detection Speed	Detection over-head	ML-Based	Attacker Identifi-cation	Use of HPCs	Impl. Level	Load/ Noise
	Raj and Dhara-nipragada [81]	Signature-Based Detec-tion	P+P, F+R	N/A	N/A	<8%	No	No	Yes	VM	No
	Chen et al [101]	Signature-Based Detec-tion	Reference Clock Attack, Appli-cation Thread Attack lation Manipu-Speed and CPU	Precision: 0.83 (Ref. Clock), lation) Manipu-Speed 0.95 (App. Thread), (CPU 0.96	N/A	<5%	No	No	No	extension [140] of LLVM	N/A
	Chouhan et al [80]	Signature-Based Detec-tion	F+R	100%	35% attack time to of execute	N/A	No	N/A	No	VM	No
	Paundu et al [104]	Signature-Based Detec-tion	P+P, F+R, F+F	0.99 (AUC)	N/A	0.7%	Yes (SVM)	Yes	Yes	VM	Yes

Note: N/A: Not Available/Applicable, HPC: Hardware Performace Counter, P+P: Prime+Probe, F+R: Flush+Reload, F+F: Flush+Flush, E+T: Evict+Time, VM: Virtual Machine, CVM:

Cross Virtual Machine, Impl:Implementation ML: Machine Learning. Also, note that the mentioned detection accuracy, speed and overhead are the best-case measures for each technique

	Reference	Design Cat-egory	Example Attacks	Detection Accu-racy	Detection Speed	Detection over-head	ML-Based	Attacker Identifi-cation	Use of HPCs	Impl. Level	Load/ Noise
	Yu et al [106]	Signature-Based Detec-tion	P+P, E+T	N/A	N/A	N/A	No	No	Yes	VM	Yes
							Yes
	Bazm et al [28]	Anomaly-tion Based Detec-	P+P	100%	N/A	2%	(Gaussian Detec-Anomaly	N/A	Yes	VM	Yes
							tion)
					within
	Briongos et al [107]	Anomaly De-tection	F+F, P+P, F+R	100%	37% of RSA of ElGamal and 50%	N/A	Yes	No	Yes	Application	Yes
					execution

Software-based Detection and Mitigation of Microarchitectural Attacks on Intel's x86 Architecture Maria Mushtaq 2019 2.3 Detection Techniques | 39 Note: N/A: Not Available/Applicable, HPC: Hardware Performace Counter, P+P: Prime+Probe, F+R:

Flush+Reload, F+F: Flush+Flush, E+T: Evict+Time, VM: Virtual Machine, CVM: Cross Virtual Machine, Impl:Implementation ML: Machine Learning. Also, note that the mentioned detection accuracy, speed and overhead are the best-case measures for each technique Reference Design Cat- egory Example Attacks

				Detection Accu-racy	Detection Speed	Detection over-head	ML-Based	Attacker Identifi-cation	Use of HPCs	Impl. Level	Load/ Noise
				0.93 for
				P+P
				(phy. &
				CVM)
	Kulah et al [108]	Anomaly-Based Detec-tion	P+P, F+R, F+F	0.99 0.97 for & F+R CVM), (phy. &	N/A	0.49-3.58%	Yes tion) (Anomaly Detec-	Yes	Yes	VM	Yes
				0.82	&
				0.96 for
				F+F (phy.
				& CVM)
	Chiappetta et al [27]	Anomaly + Signature-Based Detec-tion	F+R	F-Score: 0.93 (AES), (ECDSA) 1.0	1/5th of tion attack comple-	N/A	Yes (Anomaly Network) Neural-Detec-tion,	Yes	Yes	Application	Yes
		Anomaly +
	Zhang et al [73]	Signature-Based Detec-	P+P, F+R	100%		order of ms	< 5%	No	N/A	Yes	VM	N/A
		tion

Note: N/A: Not Available/Applicable, HPC: Hardware Performace Counter, P+P: Prime+Probe, F+R: Flush+Reload, F+F: Flush+Flush, E+T: Evict+Time, VM: Virtual Machine, CVM:

Cross Virtual Machine, Impl:Implementation ML: Machine Learning. Also, note that the mentioned detection accuracy, speed and overhead are the best-case measures for each technique

	Reference	Design Cat-egory	Example Attacks	Detection Accu-racy	Detection Speed	Detection over-head	ML-Based	Attacker Identifi-cation	Use of HPCs	Impl. Level	Load/ Noise
									Yes (RF,
		Anomaly +						SVM, Ad-
	Alam et al [74]	Signature-Based Detec-	[129], [130]	>99%		N/A	N/A	aboost, Percep-	Yes	Yes	Application	Yes
		tion							tron,
									NB)
		Signature-
	Zhang et al [131]	Based location	Co-	P+P	85%		N/A	< 4.6%	No	Yes	Yes	VM	Yes
		Detection
												commercial
												clouds
		Signature-									(Amazon
	Inci et al [47]	Based location	Co-	P+P, F+R	93% 90%	&	N/A	6.1x	No	No	No	EC2,Google Cloud en-	N/A
		Detection										gine,
												Microsoft
												Azure

Software-based Detection and Mitigation of Microarchitectural Attacks on Intel's x86 Architecture Maria Mushtaq 2019 2.3 Detection Techniques | 41

Note: N/A: Not Available/Applicable, HPC: Hardware Performace Counter, P+P: Prime+Probe, F+R: Flush+Reload, F+F: Flush+Flush, E+T: Evict+Time, VM: Virtual Machine, CVM: Cross Virtual Machine, Impl:Implementation ML: Machine Learning. Also, note that the mentioned detection accuracy, speed and overhead are the best-case measures for each technique

  Major findings from the surveyed literature related to CSCA detection mechanisms are following: • Cache Side-Channel Attack (CSCA) detection techniques are largely divided into Signature-Based and Anomaly-Based detection techniques. • Most of the CSCA detection techniques are Signature-based techniques as shown in Table 2.2. There also exist few research works that use a combination of Anomaly and Signature-based detection techniques. • As discussed in literature, more than 80% of the research works focusing on detection of cache-based side-channel attacks are performed in last 3 years indicating that the field still lacks maturity. • Almost all of the reviewed detection techniques use hardware performance counters

Table 2 .

 2 3 -State-of-the-Art on hardware/software Countermeasure Techniques w.r.t. Cache Hierarchy

	Cache Level Countermeasure	Description	Year	Type

Table 2 .

 2 4 -State-of-the-Art software countermeasures categorization

	2014, 2013,

Table 2 .

 2 5 -State-of-the-Art software countermeasures for different levels of Cache and threat model within Intel x86

	Cache Level Context Switching		hyper-	Multicore
					Threading
	L1/D-I	• Constant Time Imple-	• Cache	• Minimum Timeslice [155]
		mentation [176], [177],	Flushing [7],	(Section 2.4.3.4)
		[178], [179], [180] (Sec-	[139], [156]	• Cache Flushing [7], [139],
		tion 2.4.5)			(Section	[156] (Section 2.4.3.4)
		• Minimum	Timeslice	2.4.3.4)	• Constant	Time
		[155] (Section 2.4.3.4)	• Retired	Implementation
		• Düppel [139] (Section	Instruc-	[176],[177],[178],[179],[180]
		2.4.3.4)			tion [160]	(Section 2.4.5)
		• Server Side Defences	(Section	• Fuzzy Time [60] (Section
		[156] (Section 2.4.3.4)	2.4.3.3)	2.4.2)
		• Kernel Address Space
		Isolation [58] (Section
		2.4.4.1)
		• Migration of VMs [170]
		(Section 2.4.1.3)
	L2	• Eliminating	Fine	• Eliminating	• Minimum Time Slicing
		Grained Timers [171]	Fine	[155] (Section 2.4.3.4)
		(Section 2.4.2)			Grained	• Cache Flushing [7], [139],
		• Bystanders Workloads	Timers [171]	[156] (Section 2.4.3.4)
		[172] (Section 2.4.2)		(Section
		• Anti-correlated Noise	2.4.2)
		[161] (Section 2.4.2)		• Bystanders
		• Düppel [139] (Section	Workloads
		2.4.3.4)			[172] (Sec-
		• Retired Instruction [160]	tion 2.4.2)
		(Section 2.4.3.3)
	LLC/L3	• STEALTHMEM	[64]	• Gang	• STEALTHMEM [64] (Sec-
		(Section 2.4.1.2)		Scheduling	tion 2.4.1.2)
					[64] (Section	• Cache Flushing [139], [156]
					2.4.1.2)	(Section 2.4.3.4)
						• Cache	Coloring	[138],
						[162],[166] (Section 2.4.1.1)
						• Injecting	Noise
						[60],[171],[161],[172] (Sec-
						tion 2.4.2)
						• CacheBar [163] (Section
						2.4.1.4)
						• Quasi-Partitioning [163]
						(Section 2.4.1.4)
						• Scheduling-based Obfusca-
						tion [168] (Section 2.4.3.1)
						• Leakage Feedback [169]
						(Section 2.4.3.2)

  Our two main contributions discussed in Section 2.3 & 2.4 are given below:

	Chapter 3
	Cache-Based Side-Channel Attacks:
	Understanding and Implementations

1. M. Mushtaq, M. A. Mukhtar, V. Lapotre, M. K. Bhatti, G. Gogniat., Winter is Here! A Decade of Cache-based Side-Channel Attacks, Detection & Mitigations for RSA, Under Major Revision at Elsevier Information Systems (IS), 2019. 2. A. Akram, M. Mushtaq, M. K. Bhatti, V. Lapotre, G. Gogniat., Meet the Sherlock Holmes of Information Security: Survey of cache SCA Detection Techniques, Under Review at EURASIP Journal on Information Security (JINS), 2019. This chapter provides specific details related to different side-channel attack techniques and use-cases of the attack techniques that are implemented as part of this thesis for detection and mitigation. Compared to Chapter 2, this chapter provides in-depth discussion on specific CSCA implementations that are used for validation of our proposed detection and mitigation techniques. We also provide a discussion about how machine learning techniques and hardware performance counters can be useful for detection and subsequent mitigation of these attacks in Intel x86 architectures. Towards the end, this chapter provides discussion on the limitations, challenges and pitfalls in using machine learning and HPCs for security. Contents 3.1 Cache-based Side-Channel Attacks as Use-cases . . . . . . . . . . . . . . 57 3.2 Leakage Exploitation Techniques and Implementations . . . . . . . . . . 59 3.3 Non-exhaustive List of Attacks . . . . . . . . . . . . . . . . . . . . . . . . 72 3.4 Future trends in security: The challenges, Pitfalls and Perils . . . . . . . 75 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.6 Publications related to this chapter . . . . . . . . . . . . . . . . . . . . . 87

Table 3 .

 3 1 -List of Selected Cache SCAs & CCAs as Use-Cases

	No. Use-cases:		Cryptosystem OpenSSL	Key	Re-	Time to key
		CSCAs	&			Version	covery	Recovery
		CCAs							(µs)
	1	Flush+Reload RSA		0.9.7l	Full key	150
	2	Flush+Reload AES		0.9.7l/	Half Key	423
						1.0.1f
	3	Flush+Reload AES		0.9.7l/	Full Key	880
						1.0.1f
	4	Flush+Flush	AES		0.9.7l/	Half Key	33600
						1.0.1f
	5	Flush+Flush	AES		0.9.7l/	Full Key	883
						1.0.1f
	6	Prime+Probe	AES		0.9.7l/	Half Key	8720
						1.0.1f
	7	Prime+Probe	AES		0.9.7l/	Full Key	570
						1.0.1f
	8	Spectre Vari-	not	crypto-	Linux Ker-	Full	Mes-	50
		ant 1 & 2		specific		nel 4.13.037	sage	Ex-
							ploitation
	9	Meltdown		not	crypto-	Linux Ker-	Full	Mes-	50
				specific		nel 4.13.037	sage	Ex-
							ploitation

Software-based Detection and Mitigation of Microarchitectural Attacks on Intel's x86 Architecture Maria Mushtaq 2019 3.2 Leakage Exploitation Techniques and Implementations | 59

Table 3 .

 3 2 -Summary of the State-of-the-Art Cache-based Attacks

	Classification Leakage	Ex-	Leveraged Features	Target Level	Cryptographic	Years of Publi-
		ploitation			of Cache	Implementa-	cations
		Techniques				tion
				Inclusive Cache, Page Sharing	LLC	RSA, AES	2014, 2015, 2011
	Tr-DA			[20], [38], [56]
				Shared Libraries [164], [204],	LLC	ECDSA	2015, 2016, 2014
		F+R		[205]
				Hardware Speculation [51]	LLC	no cryptographic	2018
						implementation
				Out-of-order execution [52]	LLC	no cryptographic	2018
						implementation
				Shared Libraries [57]	LLC	DSA	2016
				Memory Mapping [56]	LLC	AES	2011
				Page De-duplication [20]	LLC	AES	2012
				Stealth Flushing, Inclusive	LLC	AES	2016
	Tr-DA	F+F		Cache [16]
				Hyper threading, Cache bank	L1-D	RSA	2017
	Tr-DA			conflicts [9]
				Symmetric Multi-threading	L1-D	RSA, AES	2010, 2006, 2005
				[14], [18], [70]
		P+P

3.4.6.5 Random Forest Model Random

  Forest is an ensemble learning method which is used for classification and regression purposes. It is mostly used for overfitting of training sets. It is suitable for various machine learning tasks. It is robust to inclusion of irrelevant features and produce inspectable models. It explodes in a form of tree and is able to grow very deep to highly irregular patterns. NN is a non-parametric statistical approach used in Pattern recognition and for supervised classification in Machine learning. KNN classifies an incoming data point by assigning it the same label as of its maximum K nearest training data points label. It can badly be affected by noise in training data as training data is used at every new prediction. This algorithm is computationally and memory intensive.

	3.4.6.6 K-Nearest Neighbors (K-NN) Model
	K-

Table 3 .

 3

	No.	Machine Learning Model	Category
	1	Linear Regression (LR)	Linear
	2	Linear Discriminant Analysis (LDA)	Linear
	3	Support Vector Machine (SVM)	Linear
	4	Quadratic Discriminant Analysis	Non-linear
		(QDA)
	5	Random Forest (RF)	Non-linear
	6	K-Nearest Neighbors (KNN)	Non-linear
	7	Nearest Centroid	Linear
	8	Naive Bayes	Linear
	9	Perceptron	Linear
	10	Decision Tree	Non-linear
	11	Dummy	Non-linear
	12	Neural Networks	Non-linear

4 -List of Machine Learning Models for CSCA Detection (Non-exhaustive)

Table 4 .

 4 1 -Selected events related to cache-based SCAs

	Scope of Event Hardware Event as Feature	Feature ID
		Data Cache Misses	L1-DCM
	L1 Caches	Instruction Cache Misses	L1-ICM
		Total Cache Misses	L1-TCM
		Instruction Cache Accesses	L2-ICA
	L2 Caches	Instruction Cache Misses Total Cache Accesses	L2-ICM L2-TCA
		Total Cache Misses	L2-TCM
		Instruction Cache Accesses	L3-ICA
	L3-Caches	Total Cache Accesses	L3-TCA
		Total Cache Misses	L3-TCM
	System-wide	Total CPU Cycles Branch Miss-Predictions	TOT_CYC BR_MSP

Table 4 .

 4 Figure 4.4 shows experimental results on selected hardware events for Flush+Flush attack on AES cryptosystem. Flush+Flush and Flush+Reload on AES use T-table entries and both attacks are based on the flushing of data from caches, therefore, it can be seen that total cycles in terms of time differentiate largely in attack and no-attack scenario. It can also be seen that these attack behaviors can be easily distinguished by the hardware event of total cache misses at L3 level. One key factor for detection attacks on AES which we noticed is data cache misses as it directly affects the data during T-table entries of AES.

		2 -Selected events related to particular cache-based SCAs
	F+R (RSA)	F+R (AES)	F+F (AES)	P+P (AES)
	L3-Total Cache	L3-Total Cache	L3-Total Cache	L3-Total Cache
	Misses		Misses	Misses	Misses
	L1-Instruction	L1-Instruction	L1-Instruction	L3-Total Cache
	Cache Misses	Cache Misses	Cache Misses	Access
	L3-Instruction	L1-Data Cache	L1-Data Cache	L1-Data Cache
	Cache Access	Misses	Misses	Misses
	Total CPU Cycles Total CPU Cycles Total CPU Cycles Total CPU Cycles
	Branch	Miss-	-	-	-
	Predictions
	CSCAs on Intel's x86 architecture.
	Figure 4.3 shows the experimental results on selected hardware events for Flush+Reload on
	AES cryptosystem. Whereas,

4.3.

3 Selected hardware events for Prime+Probe attack on AES

	LDA	LR	SVM	NearestCentr.	NaiveBayes	KNN	Dummy	Perceptron	DecisionTree	RandomForest	QDA	NeuralNet.

The 4 best suited hardware events which give precise information about execution of attacking and non-attacking behaviors for Prime+Probe attack running under AES cryptosystem are

Table 4 .

 4 4 -Results using LDA, LR, SVM & QDA models for Flush+Reload attack detection with AES

	Model Loads Accuracy (%) Speed (%) FP (%) FN (%) Overhead (%)
		N	99.8	20	0.06	0.14
	LDA	AL	93.9	20	6.1	.018	7.8
		FL	91.5	20	6.3	2.2
		NL	99.9	40	0.1	0
	LR	AL	88.4	40	11.6	0	2.7
		FL	96.8	40	3.16	0.04
		NL	99.9	20	0.1	0
	SVM	AL	88.5	20	11.5	0	3.9
		FL	96.7	20	3.25	.05
		NL	99.6	20	0.22	0.18
	QDA	AL	93.8	20	6.13	.07	8.3
		FL	91.5	20	5.9	2.6

of total 250 encryptions, which is the number of encyprtions an attacker performs to complete the attack. For example, a detection speed of 20% means that the attack was detected by the first 50 encryptions. As shown in Table

4

.4, all machine learning models except LR are able to detect attack in all cases by first 50 encryptions. In case of LR, the detection is achieved by first 100 encryptions, i.e., below 50% of 250 encryptions.

Table 4 .

 4 5 -Results using LDA, LR, SVM & QDA models for Flush+Flush attack (Impl1) detection

	Model Loads Accuracy (%) Speed (%) FP (%) FN (%) Overhead (%)
		NL	99.9	25	.075	.025
	LDA	AL	98.7	25	1.16	0.14	1.18
		FL	95.2	12.5	4.57	0.23
		NL	91.7	12.5	0	8.3
	LR	AL	83.1	25	14.3	2.7	1.10
		FL	75.9	25	24	0.1
		NL	97.4	12.5	0	2.6
	SVM	AL	70.6	12.5	27.8	1.60	0.8
		FL	63.2	12.5	36	0.8
		NL	99.9	12.5	0.09	0.01
	QDA	AL	98	12.5	1.99	.008	1.2
		FL	91.1	12.5	8.85	0.05

Table 4 . 6

 46

		NL	99.8	0.2	.042	.158
	LDA	AL	98.2	0.2	1.4	0.40	3.5
		FL	80.2	0.1	8.2	11.6
		NL	88.8	0.3	2.2	9
	LR	AL	86.8	0.4	5.9	7.3	3.4
		FL	76.5	0.8	5.9	17.6
		NL	85.2	0.1	14.2	0.6
	SVM	AL	73.3	0.1	25.4	1.3	3.7
		FL	66.7	0.8	19.6	13.7
		NL	89.7	0.2	10.1	0.2
	QDA	AL	82.1	0.2	17.1	0.80	4.5
		FL	69.1	0.8	15.1	15.8

-Results using LDA, LR, SVM & QDA models for Flush+Flush attack (Flush+Flush Impl2) detection Model Loads Accuracy (%) Speed (%) FP (%) FN (%) Overhead (%)

Table 4 .

 4 [START_REF] Zhang | Cross-VM Side Channels and Their Use to Extract Private Keys[END_REF] shows the detection accuracy of the selected ML models. The detection accuracy is very 4.5 Experiments and Discussion | 113high for all ML models (close to 100%) under all load conditions. The only exception is LDA under NL and AL, where it still shows a detection accuracy above 95%. In order to explain this high accuracy of all ML models we can have a look at Figures 4.19 and 4.20, which show the distribution of hardware events. As visible in Figure4.19, all used features show clearly distinctive behavior under NL resulting into easy classification for ML models. Under FL condition (shown in Figure4.20), the used hardware events start to overlap. However, two features (L3's total cache accesses and total cache misses) still exhibit distinctive behavior leading to good performance of ML models. Table4.8 shows the accuracy of used ML models while detecting second implementation of Prime+Probe attack on AES. Under all load conditions the ML models are able to show pretty high accuracy (above 99%).Figures 4.21 and 4.22 show the distribution of HPCs used for detection under attack and no-attack cases for NL and FL system conditions respectively. As indicated in these figures even under high load condition the distinction among the used HPCs is good enough for detection of attack.

Table 4 .

 4

	Model System	Accuracy	Speed	FP	FN	Overhead
		Condition	(%)	(%)	(%)	(%)	(%)
		NL	95.15	2.1	0	4.85
	LDA	AL	97.47	2.1	0	2.53	3.48
		FL	100	1.1	0	0
		NL	99.89	2.1	0.11	0
	LR	AL	99.97	2.1	0.03	0	3.23
		FL	99.92	2.1	0.08	0
		NL	100	2.1	0	0
	SVM	AL	100	2.1	0	0	5.08
		FL	99.99	2.1	0	0.01
		NL	100	1.1	0	0
	QDA	AL	99.99	1.1	0.01	0	1.68
		FL	99.99	2.1	0.01	0

7 -Results using LDA, LR, SVM & QDA models for Prime+Probe (Impl1) attack detection

Table 4 .

 4 9 -Selected events related to use-case CSCAs

	Attack	Hardware Event as Fea-	Feature ID
		ture
		L1-Data Cache Misses	L1-DCM
	Flush+Reload	L3-Total Cache Accesses L3-Total Cache Misses	L3-TCA L3-TCM
		Total CPU Cycles	TOT_CYC
		L1-Data Cache Misses	L1-DCM
	Flush+Flush	L3-Total Cache Misses L3-Total Cache Accesses	L3-TCM L3-TCA
		Total CPU Cycles	TOT_CYC
		L1-Data Cache Misses	L1-DCM
	Prime+Probe	L3-Total Cache Accesses L3-Total Cache Misses	L3-TCA L3-TCM
		Total CPU Cycles	TOT_CYC

overhead due to frequent sampling. Since, every attack has its own peculiar characteristics, it is critical for the detection tool to choose the most suitable minimum number of hardware events that could maximize the understanding of targeted attacks. Based on the multiple CSCA characteristics, we select hardware events mentioned in Table

4

.9 as best suited ones. Figures 4.25, 4.26 and 4.27 represent experimental results on these selected hardware events for Flush+Flush, Prime+Probe and Flush+Reload attacks, respectively, under No Load conditions. As shown in these figures, each hardware event offers distinguishable features for attack and no-attack cases. Interestingly, selection of these events is also dependent on the choice of cryptosystems. For instance, AES uses pre-computed T-table entries that are stored in data cache during encryption. Therefore, the signature of attack is more evident on data caches for AES cryptosystem. Figures 4.25

, 4.26 and 4.27 illustrate that, under No Load conditions

Table 4 .

 4 10 -Results using individual and Ensemble ML models for detection of Prime+Probe (Impl1: half-key recovery) on AES at fine-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	99.99	0.21	0.01 0.00
	SVM	AL	99.82	0.21	0.18 0.00 7.83
		FL	94.92	0.21	5.08 0.00
		NL	99.99	0.21	0.01 0.00
	DT	AL	99.76	0.21	0.24 0.00 6.59
		FL	95.00	0.21	5.00 0.00
		NL	99.99	0.21	0.01 0.00
	RF	AL	99.72	0.21	0.28 0.00 11.3
		FL	92.67	0.21	7.33 0.00
		NL	99.99	0.21	0.01 0.00
	Ensemble	AL	99.77	0.21	0.23 0.00 8.03
		FL	97.62	0.21	2.37 0.01
	Our experimental results, shown in Tables 4.10 & 4.

Table 4 .

 4 11 -Results using individual and Ensemble ML models for detection of Prime+Probe (Impl2: full-key recovery) on AES at fine-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	99.99	0.02	0.01 0.00
	SVM	AL	98.50	0.02	1.50 0.00 6.75
		FL	98.61	0.02	1.38 0.02
		NL	99.99	0.02	0.01 0.00
	DT	AL	98.53	0.02	1.47 0.00 7.45
		FL	98.54	0.02	1.46 0.00
		NL	99.99	0.02	0.01 0.00
	RF	AL	97.90	0.02	2.10 0.00 9.34
		FL	97.73	0.02	2.27 0.00
		NL	99.77	0.02	0.23 0.00
	Ensemble	AL	96.94	0.02	3.6 0.00 8.20
		FL	99.09	0.02	0.91 0.00

Table 4 .

 4 [START_REF] Daniel Genkin | RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis[END_REF] -Results using individual and Ensemble ML models for detection of Prime+Probe (Impl1: half-key recovery) on AES at coarse-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	100	2.08	0.00 0.00
	SVM	AL	97.51	2.08	2.49 0.00 0.15
		FL	98.72	2.08	1.28 0.00
		NL	99.99	2.08	0.01 0.00
	DT	AL	99.82	2.08	1.47 0.18 0.30
		FL	98.18	2.08	1.82 0.01
		NL	99.99	2.08	0.01 0.00
	RF	AL	97.20	2.08	2.80 0.00 2.99
		FL	97.70	2.08	2.30 0.00
		NL	99.99	2.08	0.01 0.00
	Ensemble	AL	97.48	2.08	2.52 0.00 0.00
		FL	97.93	2.08	2.07 0.01
							3% and 9.3% for
	Impl1 and Impl2, respectively, at fine-grain detection granularity for RF model. A coarse-
	grain sampling frequency of 100 encryptions for hardware events reduces the performance
	overhead to a maximum of 2.99% and 4.5% for Impl1 and Impl2, respectively, as shown in
	Tables 4.12 & 4.13.

overhead as fine-granularity would imply more time spent in profiling. Since WHISPER tool embeds the detection inside cryptosystem, we measure performance overhead as a percentage of slowdown experienced by the cryptosystem when detection is being enabled. Our experiments with selected ML models reveal that the performance overhead of WHISPER tool is low, specifically at coarse-grained detection. Tables 4.

10 & 4.11

show that the target cryptosystem, AES in this case, experiences a maximum slowdown of 11.

Table 4 .

 4 [START_REF] Gullasch | Cache Games -Bringing Access-Based Cache Attacks on AES to Practice[END_REF] -Results using individual and Ensemble ML models for detection of Prime+Probe (Impl2: full-key recovery) on AES at coarse-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	99.99	0.19	0.00 0.01
	SVM	AL	99.32	0.19	0.66 0.01 0.82
		FL	98.87	0.19	1.13 0.00
		NL	99.99	0.19	0.01 0.00
	DT	AL	99.71	0.19	0.29 0.00 4.5
		FL	98.19	0.19	1.81 0.00
		NL	99.99	0.19	0.01 0.00
	RF	AL	99.21	0.19	0.79 0.00 1.71
		FL	97.90	0.19	2.10 0.00
		NL	99.99	0.19	0.01 0.00
	Ensemble	AL	99.29	0.19	2.52 0.71 1.03
		FL	98.19	0.19	1.81 0.00

very high and consistent detection accuracy under NL, AL and FL conditions as well, i.e., between 97.17-100.00% for Impl1 (Table

4

.14) and between 98.52-99.99% for Impl2 (Table

4

.15). Similarly, the Ensemble model used by WHISPER tool also performs very well and provides a detection accuracy ranging between 98.92-99.99% for Impl1 (Table

4

.14) and 98.37-99.99% for Impl2 (Table

4

.15). As shown in the Tables 4.14 & 4.15, the selected ML models for the tool perform consistent even under AL and FL conditions against Flush+Reload attack.

Table 4 .

 4 14 -Results using individual and Ensemble ML models for detection of Flush+Reload (Impl1: half-key recovery) on AES at fine-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)
		NL	100	4.00	0.00 0.00
	SVM	AL	99.75	4.00	0.25 0.00 11.1
		FL	99.14	4.00	0.86 0.00
		NL	99.99	4.00	0.01 0.00
	DT	AL	99.71	4.00	0.29 0.00 10.8
		FL	99.00	4.00	1.00 0.01
		NL	99.98	4.00	0.02 0.00
	RF	AL	99.57	4.00	0.43 0.00 12.3
		FL	97.17	4.00	2.83 0.00
		NL	99.99	4.00	0.01 0.00
	Ensemble	AL	99.68	4.00	0.32 0.00 11.2
		FL	98.92	4.00	1.08 0.00
	remarkably to a maximum of 2% for both implementations of Flush+Reload attack in case
	of coarse-grain detection.

  .18 & 4.19 show our experimental results for individual ML models (RF, DT, SVM) and Ensemble, respectively, for two different implementations of Flush+Flush attack on the similar patterns as shown in other two case studies. In this case as well, all three ML models provide high and consistent detection accuracy when used as individual models under NL, AL and FL conditions. As shown, the accuracy ranges between 71.84-99.98% for Impl1 (Table4.18) and between 72.86-99.56% for Impl2 (Table4.19). The Ensemble model performs better than individual ML models in this case and provides a very good detection accuracy ranging between 94.68-99.97% for Impl1 (Table 4.18) and 94.82-97.71% for Impl2 (Table 4.19).

Table 4 .

 4 [START_REF] Ge | A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware[END_REF] -Results using individual and Ensemble ML models for detection of Flush+Reload (Impl2: full-key recovery) on AES at fine-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	99.99	0.02	0.01 0.00
	SVM	AL	99.45	0.02	0.50 0.05 9.78
		FL	95.92	0.02	0.70 3.38
		NL	99.99	0.02	0.01 0.00
	DT	AL	99.44	0.02	0.56 0.00 11.17
		FL	98.91	0.02	1.09 0.00
		NL	99.99	0.02	0.01 0.00
	RF	AL	99.05	0.02	0.95 0.00 13.25
		FL	98.52	0.02	1.47 0.01
		NL	99.99	0.02	0.01 0.00
	Ensemble	AL	98.37	0.02	0.63 0.00 8.27
		FL	98.99	0.02	1.01 0.01

Table 4 .

 4 [START_REF] Gruss | Flush+Flush: A Fast and Stealthy Cache Attack[END_REF] -Results using individual and Ensemble ML models for detection of Flush+Reload (Impl1: half-key recovery) on AES at coarse-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)
		NL	100	40	0.00 0.00
	SVM	AL	98.47	40	1.53 0.00 1.3
		FL	98.82	40	1.18 0.00
		NL	99.99	40	0.01 0.00
	DT	AL	99.86	40	0.13 0.02 2.00
		FL	98.05	40	1.77 0.18
		NL	99.99	40	0.01 0.00
	RF	AL	98.28	40	1.72 0.00 1.89
		FL	97.83	40	2.17 0.00
		NL	99.99	40	0.01 0.00
	Ensemble	AL	98.44	40	1.56 0.00 2.19
		FL	98.09	40	1.91 0.00

Table 4 .

 4

[START_REF] Zhang | Cross-Tenant Side-Channel Attacks in PaaS Clouds[END_REF]

-Results using individual and Ensemble ML models for detection of Flush+Flush (Impl2: full-key recovery) on AES at fine-grain sampling.

Table 4 .

 4 17 -Results using individual and Ensemble ML models for detection of Flush+Reload (Impl2: full-key recovery) on AES at coarse-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)
		NL	100	0.2	0.00 0.00
	SVM	AL	98.44	0.2	1.56 0.00 0.41
		FL	90.00	0.2	0.99 0.00
		NL	99.96	0.2	0.02 0.02
	DT	AL	95.83	0.2	0.36 3.81 0.1
		FL	98.30	0.2	1.70 0.00
		NL	100	0.2	0.00 0.00
	RF	AL	98.20	0.2	1.80 0.00 2.0
		FL	98.41	0.2	1.59 0.00
		NL	100	0.2	0.00 0.00
	Ensemble	AL	98.37	0.2	1.63 0.00 0.1
		FL	98.60	0.2	1.40 0.00

Table 4 .

 4 [START_REF] Dag | Cache Attacks and Countermeasures: The Case of AES[END_REF] -Results using individual and Ensemble ML models for detection of Flush+Flush (Impl1: half-key recovery) on AES at fine-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	71.84	2.50	0.01 28.14
	SVM	AL	84.52	2.50	0.13 15.35 14.5
		FL	88.44	2.50	2.71 8.85
		NL	99.98	2.50	0.01 0.01
	DT	AL	99.89	2.50	0.11 0.00 10.0
		FL	97.77	2.50	0.81 1.43
		NL	99.94	2.50	0.03 0.03
	RF	AL	99.73	2.50	0.26 0.01 12.74
		FL	94.71	2.50	1.44 3.85
		NL	99.97	2.50	0.01 0.02
	Ensemble	AL	99.80	2.50	0.17 0.03 11.17
		FL	94.68	2.50	4.36 0.96

should incur minimum system overhead at run-time, should cover a large set of attacks and should be fast enough to raise the alarm before attack completion.

Table 4 .

 4 20 -Results using individual and Ensemble ML models for detection of Flush+Flush (Impl1: half-key recovery) on AES at coarse-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)	(%)
		NL	71.99	25	0.00 28.01
	SVM	AL	93.58	25	0.94 5.49 2.74
		FL	91.43	25	1.50 7.07
		NL	99.97	25	0.02 0.00
	DT	AL	99.79	25	0.20 0.00 0.2
		FL	96.65	25	2.48 0.88
		NL	98.79	25	0.01 1.20
	RF	AL	95.37	25	1.19 3.45 1.72
		FL	96.07	25	2.88 1.05
		NL	98.79	25	0.01 1.20
	Ensemble	AL	95.54	25	1.01 3.45 0.26
		FL	96.18	25	2.48 1.34

known CSCAs. With the use of more sophisticated ML models, WHISPER tool is scalable for unknown attacks as well.

Table 4 .

 4 21 -Results using individual and Ensemble ML models for detection of Flush+Flush (Impl2: full-key recovery) on AES at coarse-grain sampling.

	ML	Loads Accuracy	Speed	FP	FN	Overhead
	Model		(%)	(%)	(%)	(%)
		NL	74.07	0.4	0.00 25.93
	SVM	AL	90.68	0.2	2.19 7.12 4.13
		FL	83.14	0.4	4.87 12
		NL	88.01	0.2	0.02 11.97
	DT	AL	93.73	0.2	0.28 5.99 2.9
		FL	90.31	0.2	1.80 7.89
		NL	87.32	0.4	0.03 12.65
	RF	AL	92.71	0.2	2.48 4.81 5.46
		FL	92.64	0.4	2.78 4.58
		NL	87.28	0.4	0.03 12.69
	Ensemble	AL	92.58	0.2	2.22 5.20 2.52
		FL	91.72	0.4	2.47 5.81

Table 5 .

 5 3 -Detection results using LDA, LR, SVM & CNN models for Spectre variant 1

	Model Loads	Accuracy	Speed	FP	FN	Overhead
			(%)	(ms)	(%)	(%)	(%)
		NL	99.93	100	0.07	0
	LDA	AL	99.06	100	0.57	0.37	1.6
		FL	98.03	100	1.18	0.79
		NL	99.97	100	0.03	0
	LR	AL	98.40	100	1.27	0.33	1.6
		FL	97.36	100	1.98	0.66
		NL	99.25	100	0.69	0.06
	SVM	AL	97.29	100	2.02	0.69	1.6
		FL	95.87	100	2.87	1.26
		NL	99.80	100	0.17	0.03
	CNN	AL	99.13	100	0.57	0.29	1.6
		FL	97.43	100	1.56	1.01

Algorithm 2 :

 2 Pseudocode representation of the working principle of Kingsguard Mitigation Mechanism.

		Input: SamplingGranularity, MaxIterations
		Initialization:
		events← ∅, report← False, Victim ← NIL
		Victim← Get_Encryption_Lib()
	1 Set_of_Active_Processes ← Get_PIDs(Victim)
	2 Embed_Detection(Victim)
	3 Set_Hardware_Events(Victim)
	4 for i ← 1 to MaxIterations 1 do
	5	if i mod SamplingGranularity == 0 then
	6	Activate_Detection()
	7	events ← Read_Hardware_Events()
	8	report ← ML_Classifiers(events)
	9	Sleep_Detection()
	10	if report == True then
		/* Attack is detected	*/
		/* Activate Mitigation	*/
	11	Suspend(Encryption)
	12	Analyze_PIDs(Set_of_Active_Processes)
	13	Untrusted_Processes ← Get_Untrusted_PIDs(Victim)
	14	Trusted_Processes ← Get_Trusted_PIDs(Victim)
	15	Kill(Untrusted_Processes)
	16	Resume_Encryption(Trusted_Processes)
		/* Turnoff Mitigation	*/
	17	return 1
	18	end
	19	end
	20 end
		/* No attack detected !	*/
	21 return 0
	general-purpose distributions by adding security features against side-channel information
	leakage.

Table 6 .

 6 2 -Performance overhead at different stages for Kingsguard mechanism while detecting Flush+Reload attack on RSA.

	Load	Detection	PID Collec-	Mitigation	Total Over-
	Type	(µs)	tion (µs)	(µs)	head (µs)
		Min: 64	Min: 68	Min: 5	Min: 137
	No Load	Avg: 72	Avg: 88	Avg: 18	Avg: 178
		Max: 121	Max: 119	Max: 54	Max: 294
		Min: 69	Min: 85	Min: 5	Min: 159
	Av. Load	Avg: 103	Avg: 75	Avg: 21	Avg: 199
		Max: 172	Max: 79	Max: 58	Max: 309
		Min: 70	Min: 99	Min: 6	Min: 173
	Full Load	Avg: 138	Avg: 44	Avg: 25	Avg: 206
		Max: 208	Max: 79	Max: 108	Max: 395
	relatively much less compared to the attack completion time as illustrated in Tables 6.1 and
	6.2.

Table 6 .

 6 4 -Encryption time taken by RSA and AES crypto-systems while under various attacks and variable load conditions.

	Load Condition RSA under	AES under	AES under
		F+R Attack	F+F Attack	P+P Attack
		(µs)	(µs)	(µs)
		Min: 7264	Min: 209	Min: 728
	No Load	Avg: 7604	Avg: 1395	Avg: 763
		Max: 26391	Max: 1680	Max: 924
		Min: 7328	Min: 210	Min: 744
	Average Load	Avg: 9982	Avg: 1477	Avg: 792
		Max: 22600	Max: 2004	Max: 1012
		Min: 7578	Min: 210	Min: 779
	Full Load	Avg: 15284	Avg: 2899	Avg: 839
		Max: 28283	Max: 3121	Max: 1061

Table 6 .

 6 5 -Mitigation accuracy of Kingsguard under simultaneously occurring homogeneous attacks

	Type of Attacks No. of Attacking Processes Mitigation Accuracy (%)
	Flush+Reload	2 3	99.58 -99.75 99.66 -99.73
	Flush+Flush	2 3	99.03-99.95 97.17-99.95
	Prime+Probe	2 3	99.95-99.99 99.90-99.97

Table 6 .

 6 6 -Mitigation accuracy of Kingsguard under simultaneously occurring heterogeneous attacks

	No.	of	Type of At-	Combination	Mitigation
	Attacking	tacks	of Attacking	Accuracy [Min-
	Processes		Processes	Max(%)]
			Flush+Reload,	1 F+F & 1 P+P	97.81-99.99
			Flush+Flush,	& 1 F+R
			Prime+Probe
			Flush+Reload,	1 F+R & 1 P+P 99.72-99.8
			Prime+Probe
			Flush+Reload,
			Prime+Probe

Table 6 .

 6 7 -Comparison of effect of positive and negative noises on execution time (Legends are such as +Squ: Positive noise in Square loop, +Mul: Positive noise in Multiply loop, +Bar: Positive noise in Barrett loop, -Squ: Negative noise in square loop, -Mul: Negative noise in multiply loop and -Bar: Negative noise in barrett loop).

	Mean (ms) Deviation

Table 6 .

 6 8 -Execution Time Comparison with Unmodified Web Server

		Execution Time Overhead
		Versus Unmodified Web
		Server
	Single path programming	×1.72
	Flush+Prefetch	×1.10

Software-based Detection and Mitigation of Microarchitectural Attacks on Intel's x86 Architecture Maria Mushtaq 2019

Table 6.3 -Detection time taken by different machine learning models under different load conditions for Flush+Flush atack on AES.

F+R &

P+P 91.3-99.99 Flush+Reload, Prime+Probe 2 F+R & 1 P+P 93.21-99.99 Flush+Reload, Prime+Probe 2 F+R & 2 P+P 82.07-99.9 Flush+Reload, Flush+Flush 1 F+R & 1 F+F 90.54-99.58 Flush+Reload, Flush+Flush 1 F+R & 2 F+F 92.86-99.32 Flush+Reload, Flush+Flush 2 F+R & 1 F+F 89.15 -99.66 Flush+Reload, Flush+Flush 2 F+R & 2 F+F 92.23 -99.86 Flush+Flush, Prime+Probe 1 F+F & 1 P+P 98.13-99.99 Flush+Flush, Prime+Probe 1 F+F & 2 P+P 99.87-99.99 Flush+Flush, Prime+Probe 2 F+F & 1 P+P 99.41 -99.99 Flush+Flush, Prime+Probe 2 F+F & 2 P+P 99.95 -99.99 Software-based Detection and Mitigation of Microarchitectural Attacks on Intel's x86 Architecture Maria Mushtaq 2019

List of Algorithms

Detection of Cache-Based Side-Channel Attacks

This chapter presents in detail our proposed run-time detection mechanism for access-driven CSCAs on Intel's x86 architecture. In this chapter, we demonstrate that our proposed detection mechanism is capable of detecting a large set of CSCAs with considerably high accuracy at run-time. We provide methodology and experimental set up for our proposed detection mechanism. We debate, with experimental results, that the proposed mechanism is capable of early-stage detection of CSCAs under variable system load conditions on an Intel x86 architecture.

Chapter 5

Detection of Covert-Channel Attacks

This chapter presents detection of Covert Channel Attacks (CCAs). Recently, the Spectre and Meltdown processor vulnerability revelations have shocked the world. Both these vulnerabilities exploit CCAs. The vulnerabilities affect almost every processor, across virtually every operating system and architecture. Spectre and Meltdown, both targeting the computational part, have completely exposed the vulnerabilities in modern processors. Meltdown specifically affects Intel microprocessors stretching back to 1995. The longevity of this issue means most of the world's Intel processors are at risk. Spectre has a similar global effect. The Spectre vulnerability affects microprocessors from Intel, as well as other major designers including AMD and ARM. In this chapter, we demonstrate successful detection of both Spectre and Meltdown using our proposed detection framework. We validate our results with experimental evaluation and present results.

Introduction

The Spectre and Meltdown attacks have rendered most of the world's computing vulnerable. Both the vulnerabilities affect almost every processor, across virtually every operating system and architecture. Spectre exploits speculative execution and affects branch prediction mainly, Although tools like PAPI and Perfmon allow to do even fine-grained sampling, but we have selected 100-ms to make sure that the system does not incur heavy performance overheads due to excessive sampling. The sampling frequency is adjustable.

Phase-III: Classification & Detection.

In this phase, we pass the data collected in last phase to trained ML models in real time. Based on this data, trained ML models classify processes either as benign or malicious. We provide details of detection accuracy, FPs and FNs (miss-classification rate) for each ML model in Section 5.5.

System Model

We demonstrate the effectiveness of proposed detection mechanism on Intel's core i3 -2120 CPU running on Linux Ubuntu 16.04.1 with kernel 4.13.0-37 at 3.30-GHz. Our threat model consists of detecting attacks which exploits hardware speculation, branch predictors, out-oforder execution and cache-based side-channel attacks in Intel x86 architecture. We use PAPI and Perf to monitor performance events on intel's core i3 machine. We use PAPI to extract events related to Spectre attacks and Perf to extract events related to Meltdown attack. These performance counters are used to train machine learning models. To train machine learning models, we produced data set from various benign processes and Meltdown/Spectre processes using these hardware and software performance counters. We monitored performance counters of each process and labelled them as benign or malicious. Detail on principle of Spectre and Meltdown, Selection of ML models and selection of HPCs, is described in Chapters 3 and 4. We will list the HPCs used for detection in coming Sections 5.3 and 5.4.

Selected hardware events for Spectre

The vulnerability being exploited by all variants of Spectre attack is the miss-training of branch predictor unit. Spectre variant 1 exploits Branch-direction predictor and Spectre variant 2 use Branch-target buffer. Although both variants of Spectre miss-train different branch predictor units, but both variants perform carefully crafted branch miss-predictions after every training phase. Therefore, we select two hardware events related to the first phase of Spectre attacks such as total branch instructions and total branch miss-predictions. Also, in [START_REF] Vougioukas | BRB: mitigating branch predictor side-channels[END_REF] Vougioukas et al. showed that branch predictors increase their miss-prediction rate by as much as 90% on average when used by the attacks which exploit branch prediction like Spectre attacks. Figure 5.2 shows magnitude of total branch instructions for three benign processes and one Chapter 6

Mitigation techniques for CSCAs

This chapter is mainly divided into two parts. In the first part, we propose a novel OS-level run-time detection-based mitigation mechanism, called the Kingsguard, against CSCAs in general-purpose operating systems, particularly Linux. We argue that, in order to retain performance benefits of computing architectures, a need-based protection should be applied, which allows operating system to apply mitigation only after successful detection of any threat, such as CSCAs and CCAs. Thus detection serves as a first line of defense and mitigation is followed by successful detection. In the second part, we present an obfuscation based mitigation solution that uses calibrated noise injection in the system. We proposed a technique named Flush+Prefetch, which works on the obfuscation of memory access behavior of a secure application.

Publications and Presentations

International Conferences