RASCv2: Enabling Remote Access to Side-Channels for Mission Critical and IoT Systems

The Internet of Things (IoT) has revolutionized the way we interact with technology at home and work. The IoT corresponds to the interconnection of uniquely identifiable sensors, actuators, and embedded computing devices within the existing Internet infrastructure, which enhances computing power and analytic capabilities of individual objects by linking them to additional resources and increasing the interaction between objects and their environments [48]. For example, governments and companies around the world have aggregated temperature readings or symptom data from IoT devices or smartphones to track a disease outbreak [8] or to fully automate patient-care workflow during the COVID-19 pandemic. The impact of COVID-19 is accelerating the adoption of the IoT in the healthcare sector and wearable devices [45].

However, IoT devices also face various malware attacks, including ransomware, which has been on the rise during the pandemic. Ransomware [49], a type of malware that threatens a victim’s data or blocks access, initially reported in 1989, infected 20,000 disk drives of the participants of the World Health Organization’s AIDS conference [32]. It can be categorized into three basic types: crypto ransomware, locker ransomware, and hybrid ransomware [49]. A crypto ransomware cracks or implements a public-private key by penetrating botnets into IoT devices. In 2008, GPCode.AK [2] was unleashed and began spreading from PC to PC, locking or encrypting the victim’s files and demanding money, unless victims could crack a 1024-bit RSA key in 72 hours. Locker ransomware alters the functionalities of IoT devices and restricts user access to devices. One noteworthy example of locker ransomware was the Koler [3] ransom attack in 2014. Koler uses social engineering to trick its victims into installing the app by offering enticing adult-themed apps or fake app updates. More importantly, uninstalling Koler can be challenging because it obtains admin rights during installation. Similar to Koler ransomware, lockerpin [5] ransomware is also implemented on the smartphone. However, lockerpin ransomware directly locks a victim’s system and extorts the victim for payment in virtual currency. Hybrid ransomware attacks that enable encryption and locking mechanisms are more dangerous because the device data and functionality could be compromised. In 2014, CTB-Locker [4] ransomware was discovered. It could install itself on its victims’ computers and claim money when it finished encrypting victims’ files.

Malware can infect a system through buffer overflow attacks, return-oriented program (ROP) attacks, and code injection attacks, which hijack the control flow of computing devices. A buffer overflow [15] occurs when a program copies a value to the buffer array that is shorter than the incoming data, overwriting the adjacent memory locations. Sometimes, buffer overflows occur when unsafe copy functions (e.g., strcpy in the C programming language) are used in a program. These functions can copy oversized data to the target memory without a bound check. The target memory cannot hold the entirety of the oversized data; thus, part of the data overflows and alters the adjacent memory values. An example of a buffer overflow is presented in Figure 1(a). First, the oversized data “0x44556541235654654” is copied into the target memory address. Then, part of the data is copied into the target memory and the value in the adjacent memory also gets updated.

Typically, buffer overflows occur unintentionally from uninformed programming choices. However, the buffer overflow can also be utilized by attackers. If attackers could gain access to the original code, they could substitute a state function with malicious functionality, overwriting some important values such as private keys in the RSA or AES encryption modules. The successful replacement of a secret key can cause serious security problems. One example is demonstrated in [46] in which the Code Red worm exploited a buffer overflow in Microsoft’s Internet Information Services (IIS) and infected over 350,000 hosts.

The buffer overflow attack can easily be prevented by performing a bound check every time a copy occurs. On the other hand, the ROP attack does not need to rely on unsafe functions. ROP attacks utilize the existing gadgets, which end with a return instruction and are stored in the library. These gadgets perform well-defined operations, such as a load, and an xor, or a jump. Each gadget specifies certain values to be placed on the stack that make use of one or more sequences of instructions from libc. The attacker [36] connects useful gadgets to achieve desired operations that did not exist in the library (e.g., copying data into a secret address or printing out private keys). Figure 1(b) presents one example of the ROP attack. In Figure 1(b), the attacker aims to modify the secret value stored in the address “0x605” in the x86 system, and there is no direct command in the library to achieve this goal. Thus, the attacker exploits three separate gadgets in the addresses 0x21f, 0x25f, and 0x28f. The first and second gadgets pop value 8 and value 0x605 into the address eax and ebx (the pointer starts at value 8). The third gadget in the 0x28f copies data from value in the address eax to address ebx. With these three gadgets, the attacker could move data 8 into address 0x605.

The ROP attack assumes that the attacker could call gadgets in the library. However, in many cases, the attacker could access the original code and insert malicious code pieces directly. In many real working scenarios, such as autonomous driving and face recognition, any slight modifications to mechanical parameters could cause serious problems. For example, a car crash could quickly happen if the attacker makes changes to the threshold breaking distance in the autonomous car’s code. The code injection attack also happens in cloud services. For example, in [18], hackers from APT group Team GhostShell targeted 53 universities using SQL injection, stealing and publishing 36,000 personal records belonging to students, faculty, and staff.

In addition to such malware attacks, some modifications to the hardware—such as hardware Trojans—can also cause threats to IoT devices. A hardware Trojan [42] is an intentional modification to the target circuit—such as ASICs, microprocessors, and microcontrollers—before or during fabrication. A hardware Trojan can later be activated when the target circuit meets some predefined conditions. For example, the hardware Trojan can be activated to leak a secret key from an encryption module.

To mitigate these threats, different defense mechanisms have been proposed. In general, they can be divided into software-based and hardware-based methods. The software-based methods, such as StackGuard [15] and program shepherding [26], perform control-flow integrity (CFI) checks on indirect branches. They can be added as a part of a compiler optimization step, static binary rewriting, or through dynamic library translation. StackGuard [15] is a compiler extension that enhances the executable code produced by the compiler so that it can detect and thwart buffer-overflow attacks against the stack. Program shepherding [26] prevents the execution of malicious code by monitoring all control transfers to ensure that each satisfies a given security policy. However, based on [16], the software-based CFI architectures are sometimes writable, and the runtime data structure can be modified to bypass the defend mechanism [16].

Compared with software-based methods, the hardware-based methods use monitoring circuits on the target device. There are two kinds: internal and external. The internal hardware-based method adds a monitoring circuit into the target device for detecting abnormal behaviors, such as the CFI-based monitor [13], the debug interface monitor [6], and the memory access monitor [50]. However, monitoring circuits need to modify the original circuit; therefore, they increase the overhead. Moreover, sometimes it is unrealistic and costly to adjust the original design. In contrast to the internal-based methods, the external hardware-based methods are based on the principle side-channel analysis system. They analyze the side-channel leakage, such as EM and power traces of the target device, to identify the abnormal behavior with the oscilloscope and the EM probe. For processing these side-channel traces, different algorithms are developed [30], which can be divided into the fine-grained method [19, 28, 31, 39, 40] and the coarse-grained method [14, 20, 51]. The coarse-grained methods can be applied for malware detection with repetitive features [29, 30]. Some coarse-grained method monitors [20, 51] measure the loop time of the target device. Examples include WattsupDoc [14] and EDDIE [29]. The fine-grained method is based on instruction-level granularity [30]. In [19, 28, 31, 39], the power traces are analyzed to disassemble instruction flow of the target device. In [31], Park et al. propose a disassembler based on the power-based side-channel to analyze the real-time operation of embedded systems by utilizing machine learning algorithms, Kullback-Leibler (KL) divergence, and principal component analysis (PCA). PCA is generally used for unsupervised dimensionality reduction [24]. It projects each data point onto only the first few principal components, which keeps the data variance as close as possible to the original. Experimental results demonstrate that the trained disassembler can recognize test instructions, including register names, with a high success rate with various machine learning methods: quadratic discriminant analysis (QDA) [27], linear discriminant analysis (LDA) [27], support vector machines (SVMs) [12], and neural network (NNs) [17]. The fitcdiscr function in the MATLAB statistical toolbox is used to construct LDA and QDA classifiers and the train function in the MATLAB deep learning toolbox is used to train a neural network classifier. LIBSVM [12] is used for the SVM classifier with RBF kernel. Among these four classifiers, QDA and the SVM classifier achieve a higher successful recognition rate (>99%) than the rest.

Even though the existing external hardware-based monitors have advantages in keeping the original design of the target device unchanged, they are based on the traditional side-channel analysis systems, which need expensive equipment such as oscilloscopes and EM probes. In addition, the conventional side-channel system is too large to be used to continuously monitor an IoT device for malware outside of the laboratory setting.

In summary, the limitations of the existing methods are apparent. Software-based methods can be bypassed, especially in hardware. Internal hardware monitoring needs to modify the original design and cannot be used in legacy devices. The existing external monitors are costly, infeasible for in-field use, and power hungry. To resolve the latter in particular, we propose RASC (short for remote access to a side-channel platform). RASC is an external monitor that miniaturizes the traditional side-channel system into two tiny PCB boards and provides remote communication either to perform analysis (e.g., disassembly) off-board or to communicate alerts of anomalous behavior occurring on the device being monitored. When working in ideal conditions (Figure 2), RASC could be arranged above the target device and connect to the power pin of the target circuit for the power supply. RASC gathers power traces from the power pin and EM traces with an internal near-field antenna. RASC also possesses two analog-to-digital converters (ADCs) so that power and EM traces can be collected at the same time. A Bluetooth module on RASC can perform wireless communication to base stations. While Bluetooth itself cannot communicate over large distances, its signal can be collected by a nearby wireless link to do so. This allows each RASC device to be cheap and consume less energy while such a wireless link can collect and transmit the signals from multiple RASC devices.

In this article, the following are our main contributions.

The rest of the article is organized as follows. Section 2 discusses related work, including the first version of RASC and other hardware monitoring systems. Section 3 provides discussion of RASCv2’s hardware, comparison between RASCv2 and other side-channel monitoring systems, and security characteristic of RASCv2. Section 4 introduces two algorithms adopted in the AES-128 subkey extraction and malware detection experiments. We also explain the experimental setup in Section 4. Section 5 demonstrates the attack capability of RASCv2 against the AES-128 module implemented on an FPGA and an Arduino UNO. Section 6 presents high successful detection rates toward different attack scenarios (buffer overflow attack, code injection attack, and ROP attack) in 10 different benchmarks using trained SVM classifiers with power traces collected by RASCv2. Section 7 presents our conclusions and discusses future directions for RASC.

Many side-channel external monitoring methods have been proposed for detecting malware. One efficient way for detecting malware is to validate the control flow integrity [30] of the target device. As introduced before, these CFI techniques could be classified into coarse-grained CFI methods and fine-grained methods based on the granularity of monitored activities. Some related works in the malware detection area are introduced here.

WattsUpDoc. Clark et al. [14] proposed WattsUpDoc for detecting malware attacks on an embedded medical device. WattsUpDoc [14] collects power traces at runtime and uses supervised machine learning (ML) to identify abnormal activities of the medical device. The output of the supervised ML algorithm is a functional state such as idle, booting, and shutdown of the medical device. The algorithms could achieve 94% detection rate toward known attacks and at least 85% accuracy for unknown attacks. Compared with WattsUpDoc, this article (RASC) not only focuses on the power channel but also focuses on the EM channel. Further, WattsUpDoc is applied at the outlet rather than near the target device.

EDDIE [29]. Nazari et al. proposed EDDIE to detect abnormal behaviors caused by code injection attacks in program execution with EM traces. EDDIE relies on spikes in the EM spectrum due to the periodic activity in the monitored execution. This involves two phases: the training phase, followed by the monitoring phase. In the training phase, EDDIE is trained under the normal execution behavior in terms of peaks in the EM spectrum. In the monitoring phase, EDDIE identifies peaks in the observed EM spectrum and compares these peaks to those learned during training. EDDIE achieves at least 92% accuracy against code injection attacks. Compared with RASC, EDDIE relies on a commercial antenna, uses an oscilloscope, and does not perform wireless communication, making it more expensive and difficult to perform remotely.

Syndrome. Syndrome uses spectral profiling [35] to analyze program execution using spectral “spikes” produced by periodic program activity with EM traces. The EM traces are transformed into the time and frequency domain using the short-time Fourier transform, and the frequency and per-iteration execution time of the loop are analyzed. Figure 3 presents the spectrogram of the benchmark “Basicmath” from Mibench [21]. In benchmark Basicmath, four loops are included, all of which can be clearly visualized in the spectrogram. The spectrogram also brings more details about frequency and the time period of the internal loop in Basicmath. The frequency and per-iteration execution time matches the core frequency of the processor and the number of loops. Any code injections to the main program can be detected by comparing differences between malware spectrograms and the malware-free spectrogram. For developing malware attacks, Sehatbakhsh et al. propose Syndrome [33] to detect abnormal activities on medical IoT devices based on [35]. Sehatbakhsh et al. trained all of the important spikes in the spectrum, which includes features corresponding to the internal loop. In the monitoring phase, the K-S test is adopted to compare the spectrum of the gathered testing EM trace and the trained spectrum in the training phase. Abnormal behavior is decided by the deviation between the testing spectrum and the trained spectrum. Syndrome achieves a 100% true-positive detection rate against control flow attacks on different devices, including Arduino, Nios-II, TS, and Olimex. Like Syndrome, RASC also employs spectral profiling for malware detection.

NIPAD. Xiao et al. propose NIPAD [25] to detect abnormal activities in a programmable logic controller (PLC). Unlike EDDIE [29] and Syndrome [33], NIPAD [25] collects power traces and extracts a discriminative feature set. Later, the features of normal samples are trained based on a long short-term memory (LSTM) neural network. Abnormal behavior could be identified by comparing the predicted sample and the actual sample. The experiment results show a high successful detection rate of LSTM networks (90.33%) even if only one line of the original program is modified. In addition, NIPAD [25] compares three different methods that could be used for malware detection: a one-class SVM classifier, LSTM network, and correlation-based algorithm. LSTM achieves a higher successful recognition rate against modification and lower equal error rate than the other two methods. In this article, we use power and EM, spectral profiling, and a one-class SVM for malware detection.

Bridges et al. [11] present an experimental design and algorithm for power-based malware detection on general-purpose computers. For detecting abnormal activities, different features of the power trace are calculated and trained into a classifier for identifying malware attacks. Bridges et al. [11] also compare different kinds of features, including mean, variance, skewness, and so forth. The authors found that the proposed one-class method outperforms supervised learning with kernel SVMs.

In summary, these works are all solutions for side-channel external monitoring. Some [29, 33, 35] target EM traces and others [11, 14, 25] analyze power traces. The most significant differences between these and our proposed work are related to the improved methods to collect EM/power traces by RASC. These methods need some traditional side-channel analysis system, such as the oscilloscope and the EM probe, to collect power/EM traces. The large size and high cost limit the range of usage. However, the tiny body and cheap cost of RASC allow us to fit it into some narrow place. In addition, RASC supports remote communication so that we could fabricate large quantities of RASC, place them in different places, and monitor distributed IoTs remotely. The articles discussed here target only one channel: EM or power. However, RASC can combine EM and power traces to improve the result.

RASCv1 [38]. The original RASC builds on the principle of side-channel analysis. Side-channel analysis gathers unintentional leakages from an electronic system and processes these leakages for reverse-engineering instructions, analyzing control flow of the target device, and so forth. A predefined condition of side-channel analysis is that the device under test could be accessed physically. However, in most IoT and cyberphysical system scenarios, this condition cannot be satisfied. Hence, a remote access embedded system, termed RASC, was initially designed by Stern et al. to achieve side-channel utilization in physically inaccessible devices. As shown Figure 2(a), RASCv1 consists of two 15 \(\times\) 15 mm PCB boards (denoted PCB1 and PCB2). PCB1 houses the main microcontroller, power side-channel measurement circuitry, and power regulators. PCB2 contains an internal near-field magnetic probe, an amplifier, and an ADC circuit. During in-field use, the two PCBs can stack on top of each other to perform both EM and power analysis. In [38], RASCv1 could visually identify code injection attacks. In Figure 4, power traces collected by RASCv1 show differences between original code and the code that is injected. The experiment results of RASCv1 demonstrate its potential applications, including monitoring of cyberphysical systems, real-time CPS monitoring, and secure firmware upgrading. However, the RASCv1 had shortcomings in its design. First, the response of the EM probe in RASCv1 was too low, which decreased the signal-to-noise ratio (SNR) so that RASCv1 could not meet the basic demands of EM analysis. Second, the sampling speed of the two ADCs on the RASCv1 was less than 10 MS/s, which is slower than the main clock of most target devices. For example, high-speed microprocessors such as the x86 processor are faster than 1 GHz. Even low-speed microcontroller units (MCUs) such as Arduino UNO have 16-MHz clock frequency. Thus, RASCv1 could not sample even one point for each instruction. Hence, RASCv1 could not perform key extraction or support more advanced/automated malware detection methods such as spectral profiling [35]. Third, the Bluetooth module of RASCv1 could not transmit large amounts of data due to the insufficient memory inside the Bluetooth module, thereby limiting its remote communication. In RASCv2, hardware upgrades have been made to solve these three problems; thus, RASCv2 has improved significantly compared with RASCv1.

In this experiment, two different target boards are used for performing SCA attacks to extract an AES-128 secret key. The first is the Arduino UNO based on an AVR 8-bit microcontroller (ATMega 328P), and the second is the SAKURA-G FPGA board [1].

In order to demonstrate the defense capabilities of RASC, we performed a set of malware detection experiments for 10 different benchmarks. For every benchmark, there are four different scenarios: (1) original (i.e., malware-free), (2) buffer overflow, (3) code injection, and (4) ROP attack. The target board in this experiment is Arduino UNO. In this section, we include the description of each benchmark, the payload of the three different kinds of malware attacks, how to trigger three different kinds of malware-infected codes, and the overall results. To analyze the results, we examine two benchmarks more closely: one in which RASC obtains a high detection rate in all four scenarios and one example that RASC had trouble with.

In this paper, we demonstrated the attack and defense capability of RASCv2 with AES key extraction and malware detection experiments, respectively. Besides, RASCv2 shows its ability to transmit data remotely. All the experiments show the potential ability of RASC to perform remote side-channel monitoring. In future work, we plan to perform additional experiments and also improve RASC’s design in the third version based on what we’ve learned from v2. First, we plan to combine EM and power traces together. In RASCv2, two ADCs could run at the same time, which means it can gather EM and power traces simultaneously. We assume this characteristic could decrease the time to crack subkey since two different channels are used. Here should be noted the combination of two different channels is not a conclusion of this paper but an assumption that needs us to design experiments to verify it in the future. However, as experiment results show, the power traces break subkeys with fewer traces than EM traces. This caused us issues when we tried to combine EM and power traces together in v2. In this case, the new version of the EM antenna will be designed to balance the ability of cracking subkeys between EM and power channel. Second, we hope to move most of the processing used for malware detection from the PC/admin to RASC. For example, an internal FFT core will be implemented inside the RASC. RASC could do the data streaming and FFT to the power/EM traces at the same time. Moreover, algorithms will be inserted into RASC to increase the SNR of the EM and power signals. Third, we will also make updates to RASC’s performance to handle instruction disassembly. In RASCv2, the low sampling speed limits the choice of the method used in the malware detection experiment. Moreover, the disassembly experiment has a higher requirement of the sampling speed since most of the methods adopted are fine-grained methods. In addition, the sensitivity decides the accuracy of the traces. This is an essential parameter for better malware detection results and the disassembly experiment in the next step. Finally, the wrong detection range of the EM ADC caused RASC to miss half of the range of the trace. An improved circuit will be implemented for RASC to measure negative voltages.