Lightweight Hardware-Based Cache Side-Channel Attack Detection for Edge Devices (Edge-CaSCADe)

One of the most significant concerns in the field of Computer Security is the protection from Cache Side-Channel Attacks (CSCAs). By carefully observing the cache behavior, an attacker can deduce valuable insights into the execution of cryptographic algorithms or private keys or even extract sensitive data from other processes running on the same hardware. Cache timing-based side-channel attacks are a class of CSCAs that leverage the timing behavior of cache memory to extract sensitive information from a target system. These attacks take advantage of the variations in access times to cache memory based on whether the data is already present in the cache or needs to be fetched from the main memory. By carefully measuring the time taken to access specific cache lines, an attacker can infer patterns and deduce information about the data being accessed, such as encryption keys or passwords. Our focus in this article is on the detection of such timing-based CSCAs.

The cache memory structure of most processors is such that one level in the hierarchy (the last level in multi-level cache) is shared between multiple cores or between user threads in a single-core setting. In such a case, if the attacker and victim processes reside on the different cores sharing this cache space, the attacker is able to trace the pattern of victim process execution and correspondingly retrieve secret information of the victim by monitoring the victim cache activity. The presence or absence of information in the cache is tracked by the attacker using timing analysis based on cache hits and misses, thereby understanding the execution pattern of the victim and correspondingly retrieving its secret information.

In this article, we propose a fine-grained monitoring approach, which monitors processor events at the level of instructions, functions, and so forth, as opposed to the current approaches, which monitor events at the system or application level.

Modern processor systems have Hardware Performance Counters (HPCs) that track the counts of various microarchitectural events during the program execution. Detection of attacks by analyzing the monitored counts for suspicious events is an important research area. However, the research works done in the past, such as [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13], involve the use of HPCs that count the events generated at a coarse granularity such as at the level of the entire system, application, or process with the help of software tools. The detection of attacks is critical to the application of mitigation techniques and hence should be highly accurate and precise with minimal performance overhead. Usage of microarchitectural event data at a coarse granularity has chances of raising false alarms. Previous works [2, 3, 4, 5, 7, 11, 12, 14] have reported false alarms at rates of 47%, 5%, 4%, 0.77% to 1.15%, 1%, 5%, 1%, and 4%, respectively.

False alarms lead to erroneous attack detection and then mitigation is unnecessarily applied. This causes unnecessary performance overload of increased (compared to baseline) execution time of an application though it is not under any attack. Our proposed fine-grained detection technique overcomes these limitations by focusing only on the event counts of the sensitive part of the code in victim applications.

Direct management of HPCs is not possible from user-level accesses to a processor. Privileged access is needed. However, operating system (OS) system configurations or usage of software tools allows the filtering and management of the HPCs [15]. Tools like LIKWID [16], Intel Vtune Profiler [17], PAPI [18], PerfMon [19], OProfile [20], and Perf[21] provide data about microarchitectural event counts. They also have the option to filter the counts generated by the HPCs based on some criteria to take a fine-grained view instead of a system-level (application, process) view. However, such tools have certain limitations. They either work as profilers used after execution and hence do not work in real time or have high-performance overhead due to the system calls made by them to fetch the hardware event counts. These tools themselves can have significant code sizes and hence require their own installation and configuration. This approach is unsuitable for real-time detection where periodic sampling of the code section is involved, which we aim at through our proposed lightweight approach.

In this article, we discuss the design and implementation of a cache timing attack detection framework, Edge-CaSCADe, that includes a hardware-based attack detection module, associated software-based identification, and marking of the sensitive code. Custom hardware performance counters, part of the attack detection block, count the cache misses of only the sensitive sections of victim code. Since the processor events corresponding to only the sensitive sections of victim code are considered, we think of this as a fine-grained and lightweight approach. To our knowledge, there does not exist prior work that monitors the microarchitectural events in a fine-grained manner for attack detection, though coarse-grained approaches exist, as discussed in the related work.

The following are the major contributions of this article:

The rest of the article is structured as follows. In Section 2, we discuss the related work in the area of detection of CSCAs, mainly the ones using hardware performance counters. In Section 3, we talk about the attack types we have targeted in our detection approach. In Section 4, we discuss all the steps in our proposed Edge-CaSCADe framework. In Section 5, we mention the details of our experimental setup and show the results from our experiments on the Comet RISC-V simulator. We also discuss the hardware implementation and related overhead. In Section 6, we discuss how our methodology addresses the issues and challenges of existing HPC-based detection approaches. Lastly, we conclude in Section 7 by shedding some light on the future scope of this research.

Detection of CSCAs has been a key area of research, especially in Intel and ARM processor architectures. However, recently, this domain has been gaining pace in the RISC-V community as well, as they are prone to timing-based cache attacks too. Hardware, software, and hybrid approaches have been adopted by the researchers comparing the pros and cons of the methodology used. For example, software approaches provide better results on existing architectures but have performance overhead. On the other hand, hardware approaches prove to have minimal performance overheads but need architectural modifications, proving them unuseful for existing devices.

In [24], the authors tried to bypass the cache access from the Last Level Cache for the instructions that are flushed by the CLFLUSH instruction. However, this technique does not defend against other attacks that evict the secret information from the cache using other methods like Evict+Probe, Prime+Probe, and Prime+Abort attacks. In [25], a reconfigurable hardware module is used that checks for underlying suspicious events to detect attacks by comparing it with a timer or flush instruction as they are the ones used by the attacker to perform the attack. However, this may not work when the attacker tries some other instructions or uses these instructions in a different order compared to the one mentioned in their detection algorithm prototypes. Hence, the authors claim to be able to detect only two types of attacks.

In [26], the effectiveness of Flush+Reload attack is seen to be reduced by 30% to 50% by using a compressed cache design. However, this design does not completely mitigate the attack and also impacts the cache performance by a factor of 2.9. In [27], a hardware detection module is implemented that checks the micro-instructions under execution and compares them against a set of suspicious instruction snippets to detect attacks. However, there is a memory requirement to store these snippets for comparison, which would increase with the number of attacks to be detected, leading to area and power overheads. In [28], a reconfigurable framework is developed to monitor internal signal events and detect suspicious activities. However, this work monitors the events at the system level and not at the fine-grained level, which may cause false alarms. Also, there is no mention of multiple attacks being detected simultaneously.

Table 1 summarizes the above-mentioned work.

Another category of interesting research work relies on attack detection techniques using HPCs. HPCs are used not only to detect CSCAs but also for exploit detection [29, 30, 31, 32], malware detection [33, 34, 35, 36, 37, 38], firmware verification [39, 40], integrity checking [41, 42], and vulnerability analysis [43]. Our work, however, only overlaps with the focus on the detection of CSCAs. Table 2 shows a list of works based on coarse-grained HPCs for the detection of CSCAs. In [1], three different machine learning techniques are adopted on counts by HPCs to detect the attacks. The counts are fetched using the Linux Perf tools and cause an overhead of 2.3%. In [2], the authors use the Intel Cache Monitoring Technology (ICMT) counters to detect cross-vm cache attacks by applying the Gaussian anomaly approach. In [3], again ICMT is used to fetch hardware counter values to detect cache attacks. In [4], a machine learning approach is used on counters of the Intel Performance Counter Monitor (PCM) to detect the attacks in real time. In [5], unsupervised deep learning is performed on the Intel PCM to predict microarchitectural attack risks. In [6], the non-cache-related event counts from HPCs are extracted in real time, which are then fed to machine learning techniques to detect attacks. Similarly, in [7], detection of transient execution-based attacks is achieved using machine learning techniques on HPCs of an out-of-order RISC-V processor. A similar approach is adopted in [8], where the edge classifier prototype is implemented on ARM and x86-based SoCs. In [9], a fully supported Perf engine is used to detect spectre attacks with more than 90 \(\%\) accuracy.

In [10], the authors have fine-grained the counts, improving the system-level count approach. However, the drawback is that it does not work in real time, nor is the detection in hardware. In [11] also, the authors have claimed that by only using existing HPCs that give counts at the entire system level, the accuracy as well as false alarm rate in attack detection is hampered. Hence, they have used the locality of the Control Flow Graph (CFG) along with HPC data in the detection approach to map HPCs with the attack-sensitive locations in the target program CFGs. However, their method uses tools like Angr [44], Intel Processor Trace [45], and Perf [46] to fetch HPC counts and CFG mapping, which leads to a high performance overhead of about 12 \(\%\) . In [12], the authors use the PAPI tool to extract HPC values and then find the best fit features to detect the attack based on anomalies. In [13], machine learning classifiers are trained with the system-wide HPC counts to detect suspicious programs or attacks. While our primary focus remains on eviction-based CSCAs, it is pertinent to note the existence of fault attacks and fault detection schemes within cryptographic contexts. [47, 48] and [49] focus on detection of such fault attacks in RSA- and ECC-based algorithms. However this study does not overlap with our target attacks and is out scope. In Table 2, we have listed the main works that deal with the detection of CSCAs using coarse-grained HPCs and the tools used to fetch the counter data.

The work in [50] also mentions the advantage of using tailor-made HPCs over the existing HPCs for the purpose of attack detection. The custom counters mentioned in their work are a combination of multiple events in an order being treated as a single event, which increases the chances of accurate attack detection due to more accurate patterns being monitored. However, in this work too, the counts are still being taken at coarse granularity and fetched using system calls, which involve events generated by all the processes under execution and cause performance overhead. Also, in [51], the Intel Precise Event-based sampling approach is also said to show lags and shadowing, causing errors in event capturing.

In [52, 53], and [54] the authors have summarized the drawbacks and pitfalls of using HPCs with software tools for attack detection. First, the tools used to fetch the HPC counts make system calls each time to fetch the counts and then analyze them by feeding them to the classifiers. These system calls cause high performance overhead. Also, the training samples and the testing environment of the machine learning classifiers used differ when the HPC values are obtained in a virtualized and bare-metal environment. This impacts the overall accuracy of classification. They also point out that the division of data for offline training and testing sets can lead to errors in real-life testing. While mentioning the experimental drawbacks, they also state that no sufficient cross-validation for the machine learning classifiers is performed. Inconsistencies during context switching also are highlighted. Our proposed method addresses most of these drawbacks, as discussed in Section 6.

To summarize, our proposed method detects the timing-based CSCAs where the attacker evicts the key-sensitive section of the code from the cache memory periodically to understand the victim activity for that section, correspondingly revealing the key. The order in which the instructions are executed does not matter in this case, as periodic eviction will be done by the attacker to reveal each key bit, causing a high number of cache misses experienced by the victim. Hence, our technique is applicable to in-order as well as out-of-order processors, prone to timing-based CSCAs. We focus on monitoring only the secret sections of the victim, giving it a fine-grained approach to reduce false alarms. We have also improvised the counting method to only count events that could be suspicious, further reducing false alarms. Also, our detection module is performed as an addition to the hardware, leading to minimal performance overhead. Our work also overcomes the other above-listed drawbacks that include real-time monitoring and concurrent multiple attack detection.

Our proposed framework, Edge-CaSCADe, targets attacks that evict secret data from the cache memory repeatedly to understand the activity of the victim. This methodology is adopted in attacks like Flush+Reload, Flush+Flush, Prime+Probe, Prime+Abort, or Evict+Probe. To understand the working of such attacks, the most prominent Flush+Reload (F+R) attack is discussed in this section.

Public-key cryptographic algorithms, e.g., RSA, AES, DSA, Diffie Hellman key exchange, and ECC-based algorithms used for encryption of plain text data to cipher text involve some computation on the secret keys. They either use modular exponentiation or elliptical curve scalar addition on the key bits or perform a series of data access manipulations. The applied modification depends on the value of the key currently being processed. The reverse mapping of the key bit extraction can be done if the attacker is given access to the trace of the computation done. Consider the Encrypt function of the Square and Multiply algorithm, adopted by RSA encryption, as shown in Algorithm 1 [55]. Here b is the base message and e is the encryption key. Each bit value of e will determine the computation to be applied to encrypt the message. We can see that steps 6 and 7 are executed only when the value of e is 1.

In the Flush+Reload attack, the attacker flushes these instructions 6 and 7 from the cache memory initially and then waits for a period of time (until the victim executes these instructions again). The attacker then again tries to access these instructions and monitors the time needed to fetch them. If the access is fast, it denotes a cache hit. This shows that the victim had accessed these instructions and hence led to its presence in cache memory, revealing the key value to be 1. However, if the attacker experiences slow access, it denotes a cache miss, eventually revealing the key value to be 0. In Flush+Reload and Flush+Flush attacks, the attacker makes use of the architecture-specific Flush instruction to flush the secret-dependent instructions from cache. However, for other attack types, the attacker makes use of other instructions that would in turn evict the required sensitive victim instruction from the cache memory.

For these attacks to be successful and reveal 100% key bits, the attacker has to flush the secret data from the cache periodically to get fresh information of a hit or miss, for every key bit. This increases the number of cache misses experienced by the victim only for this particular set of instructions. In our work, we are monitoring cache misses for only such sets of instructions to get a fine-grained detection of the attack.

We propose a fine-grained hardware-based attack detection block that counts cache misses of only secret sections of the victim applications. Existing processor HPCs perform the event counting of the overall system. Our proposed detection module includes counters that count cache misses of only mapped secret addresses, making it a fine-grained monitoring approach. Figure 1 shows the system-level cache miss counts while running applications from the MiBench benchmark suit [22] and our test cases (details in Table 4). These counts were fetched on Intel x86 processor architecture using the Intel Vtune profiler tool [17]. The true negatives are the non-attack cases, where the HPC counts are shown to be low and hence there is no attack detection. True positives are the attack cases where the HPC counts are high, leading to attack detection accurately. However, false positives are the non-attack cases, whose HPC counts turn out to be high, due to the in-built execution pattern of the programs. Hence, these cases are wrongly classified as attack cases.

Finally, Figure 1 shows that when the counts are at the system level, some applications may mimic attack-like behavior in the microarchitecture, causing false alarms.

This motivates us to focus on fine-grained monitoring that only focuses on event counts of target sections in code, instead of counts at the system level.

Existing works use processor HPCs that count different types of microarchitectural events. By using performance monitoring tools like Intel VTune Profiler, these counts can be filtered to the finest granularity, i.e., at the level of a process or a section of the code. On the other hand, we propose fine-grained counters that target only the sensitive secret section of the given code/process. It needs no further process monitoring software and completely does the fine-grained counting in hardware, helping with accurate attack detection in case of anomalies detected in the targeted section of the code. This section discusses the details of the proposed framework in detail.

Figure 2 presents the overall framework of our Edge-CaSCADe system. A minimum of three components are involved at the software level. The victim code is the one that carries sensitive information and needs protection from attack. The victim will have to do some updates on his or her code before launching it in the multi-user environment, as discussed in Section 4.1.1.

Attack code is the code that launches CSCAs on the victim to retrieve the secrets. Calibration code is used to derive certain parameters from the victim code in order to run the detection process and is further discussed in Section 4.1.2. At the hardware level, we have implemented our detection module to perform the monitoring and detection task, using counters. In other words, our proposed detection methodology involves certain software-level activities and certain hardware-level phases, as discussed in the following sections.

We demonstrate Edge-CaSCaDE on the Comet RISC-V processor simulator. Comet is an open-source 32-bit five-stage pipeline processor written in C++ for High-Level Synthesis (HLS) that can operate at a frequency of 700 MHz when synthesized [57]. The simulator is fast, cycle-accurate, and bit-accurate, as it mirrors the hardware microarchitecture of the processor. Comet is an in-order processor. It has a four-way associative cache that uses the Least Frequently Used replacement policy. In our experiments, the system-level counts are found by the in-built performance counters (HPCs) of the Comet processor, whereas the fine-grained secret section counts are found by the proposed detection module. The OS that we use for the experiments is ZephyrOS [58]. It is an open-source OS dedicated to embedded systems. C++ language is used to describe the architecture of our proposed cache monitor block, which is further transformed into the Register-Transfer Level (RTL) description using the Catapult HLS Toolchain. This RTL description is further fed to the Synopsys Design Compiler to transform it into a Gate-Level Netlist. We have generated area, power, and timing overhead reports from this implementation using a 28 nm FDSOI technology.

We consider RSA, AES, and ECIES encryptions to demonstrate our framework. The maximum key size in RSA, AES, and ECIES is 2,048, 256, and 256, respectively [59, 60]. As per research in [61], recovering cryptographic keys from partial information needs at least 25 \(\%\) of keys known at a stretch. Hence, in our experiments, we have kept the counter refresh rate of 10 \(\%\) of the victim encryption code execution time, which covers this possibility. For a key size of 2,048 bits, 10 \(\%\) execution would at the most complete processing of 204 bits. Further, the threshold value \(50\%\) , when reached, detects the attack, thus stopping the counter. Hence, synthesis of an 8-bit counter would suffice in this case. As presented in Table 4, we have constructed various test cases to scrutinize the behavior of the detection module on multithreaded programs in different scenarios. We mention the name of the test case scenario along with the number and type of threads involved. The details of each thread are mentioned in Table 5. When several options are reported for a thread, they are randomly selected among the number of experiments.

The attack is launched on the RSA following the methodology described in [62], on the AES following the technique mentioned in [63] and [64], and on the ECC-based cryptographic algorithm ECIES using [65].

We have broadly divided the use case scenarios into three categories, namely:

The single victim scenarios include only the victim code without the MiBench benchmark application, with only one secret-dependent encryption section to be monitored. The complex victim scenarios include benchmark and complex user applications along with the victim encryption applications. We have performed these complex victim test experiments in single as well as multiple victim cases. In the single complex victim case, there is one secret section to be monitored, whereas the multiple complex victim case has multiple victim secret sections to be monitored.

Tables 4 and 5 provide more details on the various test cases. The codes for test cases used can be found at https://github.com/Pavitra07/Use-Cases.

Since our detection technique works completely in hardware and is not based on machine learning, most of the issues faced by current HPC-based detection methods, as mentioned in [52, 53] and [54], are addressed as follows:

We have presented a methodology to detect timing-based CSCAs in a fine-grained approach. We have created a detection module that interacts with the processor core to monitor cache miss counts for secret sections of the victim, and have also derived a technique to distinguish the suspicious cache misses from the genuine ones, in order to increment the counter. Our techniques have proven to be highly accurate and show negligible false alarms in our test cases. Using this methodology, we are also able to detect multiple attacks on multiple victims happening concurrently. The attacks that can be detected by our method follow the technique of flushing the sensitive section of the victim from the cache to perform timing analysis based on CSCAs. Our results show more than 98% detection accuracy and negligible false alarms with a detection speed of 2% from the start of attacker execution. The area overhead and power overhead after logic synthesis of the detection module is only \(0.9\%\) to \(2\%\) and \(1\%\) to \(2.1\%\) , for one to five counters, respectively.

There is no clock cycle overhead, as the detection computations are not in the processor critical path, resulting in no impact on its operating frequency. Our proposed calibration and detection algorithms are processor generic. Though we have demonstrated our method on a specific RISC-V processor core, our method is applicable to other processor architectures with inclusive and shared caches.

Our experiments are conducted on an in-order processor core; however, our approach would show similar outcomes on out-of-order processor architectures for the detection of the same targeted attack types.

Currently, marking of the secret sensitive sections in the code is the responsibility of the user. However, as part of future work, automation through statistical program analysis offers a promising avenue for improvement. As demonstrated in [67], techniques such as control flow extraction, taint analysis, and address analysis can be leveraged to automatically identify and mark these sections, streamlining the process and enhancing overall efficiency. We also look forward to extending such a fine-grained detection technique to detect attacks that exploit other vulnerabilities, like speculative execution and out-of-order execution.