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

1 INTRODUCTION

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.

Fig. 1.

View Figure

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.

Fig. 2.

View Figure

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.

2 RELATED WORK

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.

Fig. 3.

View Figure

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.

Fig. 4.

View Figure

3 OVERVIEW OF RASCV2

3.1 Structure of RASCv2

Figure 2(b) presents the structure of RASCv2. The schematic is presented in Figure 5. Similar to RASCv1, RASCv2 consists of two boards but with a larger size. The first board (PCB1) contains two ADCs for digitalizing EM and power traces, a Bluetooth module for remote communication, and a Xilinx Spartan-3E (XC3S500E) [47] FPGA for data processing. The ADC on the PCB1 is TI ADC08200 [44]. Its maximum sampling speed could be 220 MS/s. SESUB-PAN 14580 [47] is selected as the Bluetooth module since it has a tiny body (8 \( \times \)8mm) and a long range of communication (>20 m). The key reason for choosing Spartan-3E is its tiny body and large number of I/O ports. The second board (PCB2) has an internal 4-loop magnetic probe. The method connecting two boards is similar to RASCv1 in Figure 2, that is, the two boards could be stacked on top of and attached to each other. In the working scenario, RASCv1 and RASCv2 could be arranged on the top of the target chip. EM traces could be gathered by the magnetic probe and the power of the RASCv2 could be supplied by the device under test (DUT).

Fig. 5.

View Figure

Compared with RASCv1, RASCv2 upgrades its functionality by selecting different components so that it can handle more complicated experiments and practical applications. More details are provided here.

(1)	ADC. The sampling speed of ADC in RASCv2 is much faster than before. The maximum sampling speed could reach 220 MS/s. However, in RASCv1, the ADC is an internal module inside the MCU, which is slower than 10 MS/s. A target device in this article and [38] is Arduino UNO; its core frequency is 16 MHz. Clearly, a faster sampling speed of the ADC could support a more accurate analysis method.
(2)	FPGA. Unlike choosing an MCU in the first version, a Spartan-3E is adopted for controlling more components and providing sufficient I/O ports on the board for connecting to possible external modules such as a universal asynchronous receiver/transmitter (UART) module for test and debugging.
(3)	Amplifier and EM antenna. In the first version, the low SNR of the EM probe limited its functionality to gather pure EM traces. Thus, in this version, we design more loops of antenna and choose better LNA components to receive correct EM signals. The correctness of the EM traces have been verified in the AES-128 key extraction experiments.
(4)	Size and Sample Holder. In Figure 6, the size of RASCv2 is small and close to a US quarter. However, the size is still 20% larger compared with the first version. Moreover, we also design a special sample holder (shown on the right of Figure 6) for containing PCB2, which allows us to carefully and reliably position it on top of the target board. View Figure

3.2 Functionality of the Second Version of RASC

In the functional diagram (Figure 7), RASCv2 connects to the power pin of the target device for power supply and gathers power traces at the same time. The magnetic probe collects EM traces and the EM traces are sent to PCB1. When power and EM traces are received in PCB1, two ADCs digitalize the signals and the FPGA can store them in its memory. After processing data inside the FPGA, RASC can send information to security administrators for remote analysis as needed.

Fig. 7.

View Figure

Compared with RASCv1, RASCv2 upgrades its functionality in terms of faster sampling speed, better EM signal, and better Bluetooth communication.

(1)	Sampling speed. The low sampling speed of the first version limits its ability to detect minor differences caused by malware attacks. The first version can detect only huge differences happening in the target device, such as the updates of the system. In this version, the collected power traces could find differences in some parameters in the main program. This has been verified in the experiments section.
(2)	EM signal. The response of the first-version EM probe is overwhelmed by white noise. Thus, there is no EM experiments included in the first RASC paper [38]. In this article, this problem is improved, and the EM trace can be used for extracting AES-128 subkeys.
(3)	Bluetooth communication. The choice of the Bluetooth module in this article is SESUB-PAN-DA14580 from Dialog Semiconductor (TDK). Compared with the first version, the new Bluetooth module has advantages in detection range and a larger memory. Here, we design a simple experiment of transmitting collected power traces to show the Bluetooth module’s abilities.

Figure 8 is the screenshot of hex data received by our smartphone and the comparison between power traces stored in RASCv2 and received power traces. Figure 8(a) shows the screenshot of the DSP app from TDK company. Every two digits are hex values of its corresponding point in the power trace. For example, the first data value is 34, and the hex data 34 stands for 52 in the decimal system. Thus, the voltage value of the first point should be \( \tfrac{52}{256}\times 3.3V=0.6703V \). Figure 8(b) is the power trace received by the smartphone and Figure 8(c) is the power trace stored in RASC. The high similarity between the two power traces shows that the correct communication could be built between RASCv2 and security administrators. In this edition, we use RASC to transmit signals to a PC for off-board analysis. In the next version, we want RASC to perform processing internally and transmit cracked keys, disassembled instructions, and/or resulting alerts to remote computers instead.

Fig. 8.

View Figure

4 EXPERIMENTAL SETUP AND ALGORITHMS

4.1 Setup

The experimental setup for collecting power traces using RASC and an oscilloscope is shown in Figure 9. For collecting power traces using RASC, PCB1 is directly connected to pin 8 of the ATmega 328P chip. For the EM traces using RASC, PCB2 is arranged on top of the ATmega 328P chip using the sample holder. For comparison, the channel 1 of the oscilloscope MDO3102 [43] is used for collecting power traces and the channel 2 is used for collecting EM traces with a commercial EM probe. Details are found in the square insets of Figure 9.

Fig. 9.

View Figure

4.2 Algorithms

There are two different experiments included in this article. The first experiment is an illustration of RASC’s offensive capabilities in which it is used to extract AES-128 subkeys by correlation power analysis (CPA) of traces. The second experiment involves malware detection, in which we train a spectral profiling-based SVM classifier. The algorithms used are described next for replication by other research groups.

4.2.1 AES-128 CPA Attack Algorithms.

The details of the CPA attack are explained in Algorithm 1. First, power traces (T) and associated plaintext (P) are collected by RASC and used to calculate the hypothesis data (\( h \)) for different key indexes. The index (\( i \)) here means the position of the subkey in the whole key. The 128-bit key can be divided into 16 subkeys and each subkey has 8 bits. Therefore, each subkey has 256 possible values. Thus, the hypothesis should be calculated 256 times, that is, once for each possibility. The hypothesis model that we use for the Arduino UNO is the Hamming weight (HW) model (line 4). The guessing value (\( j \)) of the subkey needs to be XORed with its corresponding 8 digits in the plaintext (\( p(k,i) \)). The result is sent to its related SBox. The HW model is based on how many bits with value of ‘1’ exist in the result. The hypothesis model for the FPGA is the Hamming distance (HD) model (line 6). Here, we calculate the HD between ciphertexts and the intermediate result before the last round of encryption based on 256 guess values. After getting the hypothesis value, the correlation coefficient can be worked out between the sampling trace points (\( \mathbf {t_k} \)) and the hypothesis value (\( \mathbf {h_j} \)) for every possibility (line 12). After finishing the calculation, the index value of the largest peak in the correlation coefficient is chosen as the guessed subkey (line 15).

4.2.2 Malware Detection Algorithms.

The algorithm used for malware detection is shown in Algorithm 2. It consists of two phases: training and testing.

(1)

Training phase. First, RASC collects \( N_t \) traces (T) from the target device, which runs malware-free code. Then, each collected power trace is transformed into the time-frequency domain by short-time Fourier transform (STFT) (line 2) and a complex matrix (\( \mathbf {Spec} \)) correlated with time and frequency is obtained. Mrow (line 3) is the max row number of the matrix (\( \mathbf {Spec} \)), and Mcolumn (line 4) is the max column number. Next, each complex value (Spec(r,c)) in a column of the matrix is transformed into its magnitude value, squared, and added to generate a value, named Vspec1 (line 10). The \( Mrow\times Mcolumn \) matrix (Spec) is then transformed into a temporary vector of size \( Mrow \) (Vspec1); this vector is stored in \( \mathbf {Vspec} \) (line 12). We next randomly choose two vectors in \( \mathbf {Vspec} \) (line 15 and 16), calculate the distance between these two vectors (line 17), and repeat it \( N_l \) times. The \( N_l \) distances (D) between these vectors are trained to generate a one-class SVM classifier (S) in line 19; 5% of the observations are outliers. The purpose of the trained SVM classifier is to compare the distance within malware-free traces and the distance between malware-free traces and malware traces. Obviously, the former distance is shorter than the latter distance. Therefore, the latter one will be detected as an anomaly by the trained one-class SVM classifier.

(2)

Testing phase. In the testing phase, a testing trace (T’) is collected from the target device running malware-free code or malware-inserted code. The testing trace is transformed into the testing vector just like the training phase (lines 2–line 12). We calculate the distance between this testing vector (Dtest) and average them (A) in line 33. The one-class SVM classifier (S) gives a score (Score) to these vectors (line 34). If the score is larger than 0, it means that it is within the separating hyperplane of the classifier; thus, the testing trace is classified as a malware-free trace (line 36). If the score is less than 0, the testing trace is considered a malware-infected trace (line 38).

5 AES-128 KEY EXTRACTION EXPERIMENTAL RESULTS AND DISCUSSION

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].

5.1 Attack on Arduino UNO

The flow of this experiment is close to the description in the functional diagram. The plaintext is sent to the Arduino UNO and RASC starts to collect the power/EM traces when the Arduino UNO is encrypting the data using AES. The power/EM trace has 7,000 points; these traces can be sent to the laptop through UART. After collecting plaintext, ciphertext, and the corresponding power/EM traces, the extraction process using MATLAB occurs as described in Algorithm 1. Figure 10 presents the comparison between collected EM and power traces by RASCv2. Some points are missing in the EM trace due to the insufficient voltage detection range of the EM ADC. The voltage-detecting range of the EM ADC is from 0 V to 3.3 V. However, some parts of the EM signal are below 0; sthus, these portions of traces are missing (see Figure 10(b)).

Fig. 10.

View Figure

Before cracking subkeys, the \( t \)-test result for RASC and oscilloscope is performed to verify that the power trace from the Arduino could be attacked. For the \( t \)-test experiment, we perform a random-versus-fixed test vector leakage assessment (TVLA) test [9]. For the random dataset, the first plaintext is 0xAAAAAAAAAAAAAAAA. Then, the ciphertext is used as the next plaintext. For the fixed dataset, the fixed plaintext is fixed to 0xAAAAAAAAAAAAAAAA. After gathering all of the traces, we use the formula described in [9] to calculate the \( t \)-test result. Note that the oscilloscope and the RASC share the same trigger signal to keep with their start time. The comparison is presented in Figure 11. Both oscilloscope and RASC \( t \)-test results are beyond the threshold (< –4.5 and > 4.5), which means that the power traces of the Arduino are breakable. More importantly, the similarity between two graphs shows correctness of the collected power traces from RASC. In Figure 11(a), the \( t \)-test value becomes larger after 2,000 sampling points. The time period after 2,000 sampling points is more easily attacked compared with the period before 2,000 sampling points. Similarly, the same situation happens for RASCv2 after 2,550 sampling points in Figure 11(b). The different start times of the crack time periods in Figures 11(a) and 11(b) are caused by different sampling speeds of the RASC (128 MS/s) and the oscilloscope (100 MS/s). Since the start time is the same, the start time point of the crack time period in the oscilloscope experiment is \( 2,\!000 \times \tfrac{1}{100M}=2 \mu s \). For RASC, the start time point of the cracking time period is \( 2,\!550 \times \tfrac{1}{128M}=1.992 \mu s \), which is close to the result from the oscilloscope.

Fig. 11.

View Figure

After this verification, the power traces and EM traces from RASC and the oscilloscope were used to extract AES subkeys. For analyzing the successful detection rate, we collect plaintexts and associated power traces randomly from the dataset and repeat the key extraction 50 times. In Figure 12(a), we compare the successful extracting rate of subkey #6 between power traces collected by RASC versus oscilloscope as the number of traces increases. This figure also includes a comparison of the success rate between power traces collected by RASC from three different Arduino UNOs. The success rate of RASC is very close to the oscilloscope in the power channel. It proves the correctness of the power traces from RASC. Moreover, the stability of RASC collecting power traces is proved since the successful cracking rate of power traces from different Arduino UNOs are close to each other.

Fig. 12.

View Figure

In Figure 13, the comparison of cracking subkey #6 using EM traces collected from RASC and from the commercial EM probe and oscilloscope are presented. The success rate of the oscilloscope + probe is much better than the result from the RASC. The first reason is the difference between the internal antenna inside RASC PCB2 and the commercial EM probe. The second reason is insufficient detecting range of EM ADC so that RASC misses some pieces of data (shown previously in Figure 10(b)). However, the result still demonstrates that RASCv2 can crack subkeys even if it misses almost half of the data. If the EM detection range of RASC improves in its next version, we expect success rates comparable to the oscilloscope.

Fig. 13.

View Figure

6 MALWARE DETECTION RESULTS AND DISCUSSION

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.

6.5 High Success Rate Example (“Gausseidel”) and Discussion

The code of Gausseidel is presented in Figure 14(a). For the malware-free code, Gausseidel includes two periodic loops. The first loop runs 500 times for calculating the result of the first Gausseidel function with 500 loops. The second loop runs another 500 times for calculating the result of the second Gausseidel function with 500 loops. The two Gausseidel functions have different loop times. The first Gausseidel function costs four clock cycles and the second Gausseidel function costs three clock cycles. For the buffer overflow attack, if we give the variable Struct1.beginningWord an oversized string, the value of the Struct1.start will be modified to a large number, which causes the wrong calculation of the benchmark. The code injection attack directly changes the value, and the result of the spectrogram is very close to the buffer overflow attack result. The ROP attack calls the preloaded asm code “Routine” and the whole program will run the malicious code only, never returning to the good code.

Fig. 14.

View Figure

RASCv2 achieves a high successful recognition rate for malware-free code, buffer overflow attacks, ROPs, and code injection scenarios for Gausseidel. Malware-free code contains two different functions; thus, we should see two different loops with different frequencies. In Figure 15(a), two different frequency loops can be clearly seen in the spectrogram. However, the code injection attack and the buffer overflow attack increase the loop time of the first function. In this case, RASC detects only one loop. There are huge differences resulting from the ROP attack since the whole program is hijacked and the Arduino runs completely different codes.

Fig. 15.

View Figure

6.6 Low Success Rate Example (“Multiply”) and Discussion

Unlike Gausseidel, the benchmark Multiply has a very low detection rate on buffer overflow attacks and code injection attacks. A part of the code is presented in Figure 14(b). The programs multiply1 and multiply2 are two internal loops in the benchmark “Multiply.” Each runs 300 times for a one-time run. The spectrograms for Multiply are shown in Figure 16. The reason why the classifier fails is because the frequency of the functions multiply1 and multiply2 are close to each other. The former function runs at 300 kHz and the latter function runs at 250 kHz. In the spectrogram of malware-free code, the first loop and the second loop are almost the same due to close frequency. The buffer overflow and malware attack in this benchmark modify the loop time of only two internal loops; thus, we can see only one loop in the spectrogram of malware code. The spectrogram of malware-free code and malware code are almost the same since the frequency of the two loops are nearly the same. In this case, the classifier cannot detect the buffer overflow attack and the code injection attack. For the ROP attack, however, the classifier can detect it because the ROP attack runs an entirely different program.

Fig. 16.

View Figure

7 CONCLUSION AND FUTURE WORK

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.