DeepAuditor: Distributed Online Intrusion Detection System for IoT devices via Power Side-channel Auditing

Abstract: As the number of IoT devices has increased rapidly, IoT botnets have exploited the vulnerabilities of IoT devices. However, it is still challenging to detect the initial intrusion on IoT devices prior to massive attacks. Recent studies have utilized power side-channel information to identify this intrusion behavior on IoT devices but still lack accurate models in real-time for ubiquitous botnet detection.We proposed the first online intrusion detection system called DeepAuditor for IoT devices via power auditing. To develop the real-time system, we proposed a lightweight power auditing device called Power Auditor. We also designed a distributed CNN classifier for online inference in a laboratory setting. In order to protect data leakage and reduce networking redundancy, we then proposed a privacy-preserved inference protocol via Packed Homomorphic Encryption and a sliding window protocol in our system. The classification accuracy and processing time were measured, and the proposed classifier outperformed a baseline classifier, especially against unseen patterns. We also demonstrated that the distributed CNN design is secure against any distributed components. Overall, the measurements were shown to the feasibility of our real-time distributed system for intrusion detection on IoT devices.

\section{Introduction}\label{section:1}
Internet of Things (IoT) devices have become the new cybercrime intermediaries to process cyber attacks and deploy malicious content. In October 2016, a massive distributed denial-of-service (DDoS) attack turned down a Domain Name System provider Dyn, which made several Internet platforms and services, such as Amazon, Netflix, PayPal, Twitter, temporarily unreachable to numerous users in Europe and North America. This IoT botnet attack is called Mirai and exceeded 600 Gbps in volume. Remarkably, the overwhelming traffic was sourced from 65,000 injected IoT devices, including routers, web cameras, and digital video recorders \cite{Anonymous:dcm0bUHc}. In fact, these IoT devices were known for their weak security protection. As reported by Symantec \cite{web:symantec}, thousands of routers running outdated firmware were targeted by the worms exploiting an old vulnerability. Since then, many variants have emerged to target the innocence of IoT devices. Besides the intermediaries of DDoS attacks, IoT devices were also found to serve as attack proxies for multiple cybercrimes, such as clickjacking and spearphishing \cite{iot:phishing}\cite{Panwar:2019uo}.

Mirai and its variants exploited the Brute-force attack \cite{brute} when first intruding IoT devices, and cybercriminals' preferred option is still the Brute-force attack from the Mirai botnet \cite{survvv}. Despite the clear intrusion procedures of botnet attacks on IoT devices, it is not easy to characterize whether the threatening intrusion occurred. The main concern is that the network traffic generated on endpoint devices is not significant as malicious behavior at the initial stages. One approach to tackle this issue involves the use of power side-channel information. Some pioneering works utilized power side-channel data to detect malign behavior on mobile devices in the early 2010s \cite{Kim:2008cl}\cite{Yang2017OnIB}. Using a power side-channel is durable since power traces are hard to be compromised and can capture accumulated tasks on devices. However, these studies are out-of-date and need to be validated in IoT environments.

Several studies explored IoT security utilizing power auditing \cite{Myridakis:2021tg}\cite{Li:ej}. However, the purpose of the proposed systems mainly focused on detecting massive DDoS attacks on IoT devices. Hence, it is still challenging to distinguish the subtle initial stages of botnet intrusion. Jung et al. \cite{Jung-01} introduced an IoT botnet detection via power modeling. In this research, the authors designed a Convolutional Neural Network (CNN) model that takes into account one-dimensional power side-channel data to classify malicious intrusion. While the CNN classifier showed promise in detecting subtle differences in power traces, the fundamental problem with this study is that they conducted an offline study with a bulky and expensive power monitor. Thus, it is not practical for ubiquitous botnet detection on IoT devices. To tackle these challenges, we designed a distributed online classification system for resource-constrained IoT devices . Our proposed solution \textit{DeepAuditor} is developed in a distributed setting and can simultaneously detect the initial botnet intrusion on multiple IoT devices via power auditing.

With this aim, our research questions in this paper are as follows:
\begin{itemize}
\item How can we audit power side-channel information of IoT devices in real-time for ubiquitous botnet detection?
\item How can we conduct online inference for multiple IoT devices in a distributed setting?
\item How can the distributed classifier prevent data leakage and networking redundancy?
\end{itemize}

To answer the first question, we designed a small form-factor device called Power Auditor that audits power traces of a connected IoT device for behavior classification. Unlike off-the-shelf power monitors, our Power Auditor is inexpensive and portable and therefore easily cooperates with IoT devices for ubiquitous botnet detection. It is also as accurate as a third-party power monitor.

To answer the following questions, we developed distributed CNN classifier components:\textit{ Power Auditor} and \textit{Data Inferencer} in user site and \textit{Computing Cloud} in cloud site. We then designed distributed protocols between our CNN components: a privacy-preserved CNN protocol and a sliding window protocol. Note that side-channel information can also reveal users' private data to the cloud site \cite{Maiti:2019vc}. Moreover, attackers can extract classifier model parameters from distributed environments \cite{Zhang} \cite{Shokri}. To remedy this concern, we designed a privacy-preserved CNN protocol in our distributed system. Next, a sliding window protocol was developed to reduce networking redundancy.

Furthermore, we demonstrated the performance of the distrusted system in our laboratory settings. Our distributed classifier detects malicious behavior in real-time with an accuracy of up to 98.9\%. Then, we theoretically analyzed the data protection of the privacy-preserved inference protocol. We also measured the scalability of our online system.

In summary, our contributions in this study are threefold.
\begin{itemize}
\item We designed a dedicated small form-factor device called Power Auditor to realize online botnet detection. Our Power Auditor is cheaper and more portable than off-the-shelf power monitors and as accurate as the existing power monitors.

\item We are the first to realize a distributed online intrusion detection system for IoT devices via power auditing. We designed distributed CNN components and proposed distributed protocols between user and cloud sites in order to conduct real-time inference without data leakage.

\item
We also demonstrated the performance of our deployed classification system in laboratory settings: 1) The CNN classifier detects malicious behavior with an accuracy of up to 98.9\%, 2) we theoretically analyzed the data protection of the privacy-preserved protocol, and 3) the distributed system supports about 90 IoT devices simultaneously by using our laboratory server.
\end{itemize}

The rest of the paper is organized as follows: Section \ref{section:2} provides background and a threat model for our study. In Section \ref{section:3}, we introduce our botnet detection system DeepAuditor. In Section \ref{section:4}, we present the Power Auditor design of our system. Section \ref{section:5} introduces the distributed online CNN model for botnet detection. Section \ref{section:7} demonstrates performance evaluation of our online system. In Section \ref{section:8}, we share our thoughts regarding limitation and future work. Section \ref{section:9} summarizes related work. Finally, we conclude this paper in Section \ref{section:10}.

\section{Background and Threat Model} \label{section:2}
This section provides background knowledge and introduces a threat model.

\begin{figure}[t]
    \centering
      \subfloat[Device Rebooting ]{%
        \includegraphics[width=0.24\textwidth]{figures/reboot.png}
        \label{fig:1a}}
      \subfloat[Botnet Intrusion]{%
        \includegraphics[width=0.24\textwidth]{figures/bot.png}
        \label{fig:1b}}

    \caption{Power Traces collected by our Power Auditor \textemdash\enspace DeepAuditor aims to detect botnet intrusion events.} \label{fig:1}
\end{figure}

\subsection{Intrusion Detection via Power Modeling} \label{section:2.1}
Power traces capture accumulated tasks so that a classifier can utilize the side-channel information to distinguish abnormal behavior. Accordingly, several studies demonstrated that subtle activities on smartphones can be inferred from power consumption data \cite{Yang2017OnIB, qi:2018tn, Kim:2008cl}. Likewise, other studies on IoT security \cite{Jung-01}\cite{Li:ej} explored how IoT devices' behavior generates different patterns of power consumption data. Figure \ref{fig:1} illustrates two examples of different activities collected by our Power Auditor. As shown in Figure \ref{fig:1a}, rebooting IoT devices generates certain power traces, whereas Figure \ref{fig:1b} displays power patterns occurred by Mirai botnet intrusion. Since the Mirai botnet family has exploited the brute force attack \cite{BF}, the power traces generated by the intrusion look almost the same between instances in our dataset. For example, in Figure \ref{fig:1b}, attackers try to sneak into the device via using different username/password combinations, which is possible because many IoT devices retain default account settings, and conduct post-processing. Overall, the intrusion generates two power trace parts: the brute-force attack and post-processing. Thus, it is feasible to utilize power traces in order to distinguish malign behavior from normal operations on IoT devices.

For IoT botnet detection, it is crucial to detect this intrusion behavior at the early stages. Accordingly, we aim to classify whether the real-time power traces suggest malicious or benign behavior. The state-of-the-art researches \cite{Jung-01}\cite{Li:ej} take power data into a one-dimensional CNN classifier. Their offline study demonstrated the effectiveness of the CNN approach. Note that RNN could also help streaming data, but it is popular in natural language applications. Instead, CNN is widely used in sensor streaming applications. Moreover, taking the power traces as input is like time-series sensing data. Therefore, we adopted the one-dimensional CNN design \cite{Jung-01} and modified this model into our distributed setting to realize an online botnet intrusion detection system. More detailed design factors will be discussed in the following sections.

\begin{figure*}[t]
	\centering
    \includegraphics[width=1.02\textwidth]{figures/deepauditor.png}

	\caption{\textit{DeepAuditor} System Overview \textemdash\enspace The system consists of three subsystems (Power Auditor, Data Inferencer, and Computing Cloud) with two distributed protocols.}
	\label{fig:2}
\end{figure*}

\subsection{Threat Model} \label{section:2.2}
In DeepAuditor, we train power traces generated by well-known IoT botnets. However, our system is designed to detect a diverse set of botnets beyond those that are well-known. We assume that an adversary is capable of conducting various patterns of botnet attacks. Thus, we consider two possible avenues that the adversary can use to attack our client-side. 1) Exploit vulnerabilities of the Power Auditor device that measures power consumption. 2) Generate complicated post-processing jobs. Adversaries could perform complicated or different jobs that generate unseen power patterns. For example, downloading different files, connecting to multiple servers, or rebooting the infected device can create more complicated data patterns.

In our study, our proposed power auditing device only monitors the power consumption of the connected IoT device within a local network; thus, the Power Auditor does not allow any inbound traffic from remote sources. Meanwhile, we directly connect our Power Auditor to an IoT device. To address the post-processing job side, segmented data from different patterns were trained as botnet instances in our deep learning model. Thus, as long as power side-channel information is noticeable enough to label, our CNN model is able to learn and distinguish those new patterns.

Furthermore, adversaries could also target our cloud servers. Consider that we implemented our classification model into two cloud-based edges. We assume any user-hold application and model-hold server in our system can become a semi-honest adversary. This means that they may try to learn additional information from their received messages. For example, server may try to learn IoT device behavior based on the power trace input, and user tries to infer the server's model parameter based on the server output. We consider all parties non-colluding for their input data and output data. It is essential for our system to avoid user's privacy data disclosure that leads to poor credibility.

The emerging attacks presented in \cite{Zhang, Shokri} are also threats that we need to consider in our model. User-side can launch the model extraction attack \cite{Zhang} to extract the convolution layer and fully connected parameters based on the server received message. Server can process membership inferences attack \cite{Shokri} to compare the user input with the server's pre-trained dataset.
In this research, our privacy-preserving mechanism masks the intermediate/final output for both user and server. However, the user still can learn the correct predicted result. Simultaneously, our privacy-preserving mechanism protects the server holds model parameters from the user, and user input is oblivious for server.
We applied a flexible method to protect the output correctness and prove our system security by using a real-ideal paradigm \cite{Goldreich}, as introduced in detail in Section \ref{section:6.3}.

\section{\textit{Deep Auditor} System Overview} \label{section:3}

In this section, we introduce our distributed IoT botnet detection system DeepAuditor. Figure \ref{fig:2} illustrates an overview of the system; DeepAuditor consists of three subsystems: Power Auditor, Data Inferencer, and Computer Cloud. Power Auditors are used to securing power traces of IoT devices in real-time. Data Inferencer and Computing Cloud are proposed for an online classifier. Altogether, the proposed distributed components satisfy the online intrusion detection via power side-channel auditing.

In user site, Power Auditor is connected to each IoT device to collect power consumption trace; there can be multiple Power Auditors for the corresponding IoT devices. First, Power Auditor is capable of auditing power consumption footprint by Power Data Processing module. During the online phase, Networking module transmits the collected data to Data Inferencer for online inference. Power Controlling module transforms AC power to DC in order to supply power to the connected IoT device. Section \ref{section:4} introduces the universal design of the Power Auditor in detail.

In our system, we adopted an 8-layer CNN classifier \cite{Jung-01} for botnet intrusion detection, as illustrated in Section \ref{section:5.1}. This classifier showed promise in detecting subtle differences in power traces but was not validated in an online system. Thus, Section \ref{section:5.3} described our modifications and evaluation results with our dataset. Based on the modified one-dimensional CNN model, we implemented and deployed the pre-trained CNN classifier into Data Inferencer and Computing Cloud.

Section \ref{section:ppip} introduces the Privacy-preserved CNN inference protocol, which enables the CNN communications between user and cloud sites without leaking data. Data Inferencer runs in user site, receives power traces from Power Auditors, and sends encrypted data to Computing Cloud to offload computation resources. In cloud site, Computing Cloud is in charge of CNN inference computations, i.e., nonlinear activation computations in the CNN. Then, Computing Cloud sends the encrypted computation results to Data Inferencer for online inference. Finally, Data Inferencer classifies the final prediction of whether the given input power trace is benign or malicious.

Lastly, we developed a sliding window protocol between Power Auditor and Data inferencer in user site. Data Inferencer requires overlapping input windows for real-time inference. An overlapping window is needed for better accuracy to detect truncated power traces. If Power Auditor sends those overlapping windows to Data Inferencer, this will lead to networking redundancy. For example, in our system, if Power Auditor sends 1.5s of data every 0.5 seconds, this will bring 67\% networking redundancy. Instead, Power Auditor sends segmented data to Data inferencer, and Data Inferencer concatenates the segmented packets for overlapping input windows. More details will be described in Section \ref{section:5.2}.

\section{Power Auditor Design} \label{section:4}

\begin{figure}[t]
	\centering
    \includegraphics[width=0.38\textwidth]{figures/testbed.png}
	\caption{Power Auditor Prototype}
	\label{fig:auditor}
\end{figure}

In this section, we introduce the three software components of the Power Auditor: Power Data Processing, Networking, and Power Controlling modules. In our Power Monitor, the Power Controlling module supplies power to a connected IoT device. Next, the Power Data Processing module reads the power consumption trace of the attached IoT device. The Networking module communicates with the server-side to convey the sensing data for online classification. Figure \ref{fig:auditor} shows our prototype of a Power Auditor and a connected IoT device. All the source codes for Power Auditors will be available for download.

Power Auditor supplies a fixed voltage to the IoT device. Many IoT devices require DC power, which can be converted from AC power by an adapter. Likewise, we use an AC adapter to output 5V to our Power Auditor. Then, the Power Auditor bypasses power to the connected IoT device. Figure \ref{fig:data} shows our proposed Power Control circuit. We built a FET-based switch to turn on the connected IoT device via GPIO pin from the Power Auditor device, as shown in Figure \ref{fig:power_circuit}. Figure \ref{fig:power_logic} illustrates the schematic of the circuit. When the GPIO pin (SIG\_IN) is 0V, it turns off the Q2 transistor. The collector of Q2 is, therefore, 5V, which turns on the Q1 transistor resulting in $V_{gs} = -5V$. It eventually turns on the PMOSFET (M1), so the input voltage bypasses the circuit. Overall, the current draw of this module is only 20mA when the 5v output is being provided. Since a Power Auditor supplies power to the connected IoT device, IoT devices do not need any modifications in our system.

\begin{figure}[t]
	\centering
	  \subfloat[Hardware Design]{%
		\includegraphics[width=0.38\textwidth]{figures/power_circuit.png}
		\label{fig:power_circuit}}

	 \subfloat[Schematic of the Power Control Circuit]{%
		\includegraphics[width=0.42\textwidth]{figures/power_circuit2.png}
		\label{fig:power_logic}}
	\caption{Power Control Circuit}
	\label{fig:data}
\end{figure}

\begin{figure}[t]
	\centering
	  \subfloat[INA219 Sensor]{%
		\includegraphics[width=0.13\textwidth]{figures/ina219.png}
		\label{fig:sensor}}

	 \subfloat[Logical Circuit of Power Measurement]{%
		\includegraphics[width=0.4\textwidth]{figures/current.png}
		\label{fig:current}}
	\caption{Power Measurement Design}
	\label{fig:sensingmodule}
\end{figure}

Next, we designed a current circuit for power measurement. To get the current and voltage reading on the connected IoT device, we utilize the current sensor INA219 \cite{ina219}, as displayed in Figure \ref{fig:sensor}. This sensor includes a shunt resistor and provides ADC conversion to a Power Auditor. Figure \ref{fig:current} illustrates how the current sensor provides power consumption data on the IoT device. In this circuit, Power Auditor measures the voltage drop around the shunt resistor at a high frequency. Based on this data, we calculate the current values going through the entire circuit. By doing so, we can measure the power consumption of the connected IoT device since the voltage input is also fixed. According to the specification of the sensor used, the maximum error rate is approximately 0.5\%, which is considered negligible.

 After measuring power data, the Power Data Processing module pushes each power reading instance into a local queue. Then, the Networking module fetches the queued data periodically and assembles the collected data to a TCP packet for data transmission to the online classifier. As the sampling rate of the current sensor is 1.7kHz, the Power Auditor collects 1,700 data points of power reading per second. More importantly, the Networking module implements the interface between our Power Auditor and Data Inferencer. The networking protocol and message format are illustrated in Section 5.4.

\section{Distributed Online CNN Classifier Design} \label{section:5}

In Section \ref{section:5.1}, we applied the one-dimensional CNN architecture presented in \cite{Jung-01} to our distributed network while modifying several hyper-parameters. In Section \ref{section:5.3}, we evaluated the modified CNN classifier design with our dataset. Sections \ref{section:ppip} and \ref{section:5.2} propose distributed protocols between the DeepAuditor components to protect data leakage and reduce networking redundancy.

\begin{figure}[b]
	\centering
	\includegraphics[width=0.5\textwidth]{figures/cnn.png}
	\caption{7-Layer CNN Model (Note. This model was modified from "IoT Botnet Detection via Power Consumption Modeling," by Jung et al. \cite{Jung-01})}
	\label{fig:cnn}
\end{figure}

\subsection{Source CNN Classifier and Modifications} \label{section:5.1}
As illustrated in Figure \ref{fig:cnn}, we applied the state-of-the-art CNN architecture in power-based botnet detection to our distributed networks while modifying several hyper-parameters.

First, we adjusted Input layer parameters. The input layer prepares one-dimensional input before the convolution layer. Since DeepAuditor takes power consumption data, every single input instance consists of one-dimensional power trace data points, as presented in Figure \ref{fig:1}. In our system, the sampling rate of the power sensing module is 1.7kHz, and the length of a single window is 1.5 seconds (See Section \ref{section:5.2}). Thus, the input instance size for our CNN model is (1 x 2550). We also use ten one-dimensional (1 x 128) kernels, and the stride size is 32. In our application, it is unnecessary to have small-size kernels since the sampling rate is pretty high. Accordingly, we chose a kernel size of 128, which represents a 75 milliseconds power trace under the sampling rate 1.7kHz. The stride size makes a kernel move one-quarter of each instance. Consequently, the convolution layer computes a dot product between the power consumption data of 75 milliseconds and the kernels.

Next, we got rid of the batch normalization from the previous model. Instead, Data Inferencer normalizes input data prior to the CNN model for both offline training and online inference. Other layers such as ReLU or Softmax are the same as in \cite{Jung-01}. Thus, the classification layer has four classes, which are \textit{Idle, IoT service, Reboot}, and \textit{Botnet} classes, to represent the behavior of an IoT device. In other words, our system can classify input power instances whether they belong to benign or malign behavior. As a result, our modified design is a one-dimensional 7-layer CNN architecture.

\begin{table}[t]
\centering
	\caption{The Collected Dataset of Power Traces }
	\resizebox{0.48\textwidth}{!}{%
\begin{tabular}{cc|c|c|c}
\hline
\multicolumn{2}{c|}{\textbf{Class}} & \textbf{Description} & \textbf{\begin{tabular}[c]{@{}c@{}}Number of\\ Instances\end{tabular}} & \textbf{\begin{tabular}[c]{@{}c@{}}Total number\\ of Instances\end{tabular}} \\ \hline\hline
\multicolumn{2}{c|}{Idle} & \begin{tabular}[c]{@{}c@{}}When IoT Service\\ is not running\end{tabular} & 4693 & 4693 \\ \hline
 \multicolumn{2}{c|}{  \begin{tabular}[c]{@{}c@{}}IoT Service\\ (Security Camera)\end{tabular} } & Streaming Service & 4523 & \multirow{2}{*}{5976} \\ \cline{3-4}
 &  & Motion Detection & 1453 &  \\ \hline
\multicolumn{2}{c|}{Reboot} & \begin{tabular}[c]{@{}c@{}}When system\\ is rebooting\end{tabular} & 2200 & 2200 \\ \hline
 \multicolumn{2}{c|}{  \begin{tabular}[c]{@{}c@{}}Botnet\\ (Mirai) \cite{etc:mirai}\end{tabular} }& \begin{tabular}[c]{@{}c@{}}Malicious behavior\\ while system is Idle\end{tabular} & 2000 & \multirow{2}{*}{3000} \\ \cline{3-4}
\multicolumn{2}{c|}{} & \begin{tabular}[c]{@{}c@{}}Malicious behavior\\ while system is running\\ IoT service\end{tabular} & 1000 &  \\ \hline
\end{tabular}
}
\label{tab:dataset}
\end{table}

\begin{table}[b]
\caption{Confusion Matrix of Offline Classification}
\centering
\label{tab:cmoff}
\resizebox{0.42\textwidth}{!}{%
\begin{tabular}{c|c|c|c|c|c|c}
\hline
 & \multicolumn{4}{c|}{\textbf{Inference}} & \multicolumn{2}{c}{} \\ \cline{2-5}
\multirow{-2}{*}{\textbf{\begin{tabular}[c]{@{}c@{}}Ground\\ Truth\end{tabular}}} & Class 1 & Class 2 & Class 3 & Class 4 & \multicolumn{2}{c}{\multirow{-2}{*}{}} \\ \hline
Idle & 4672 & 21 & 0 & 0 & 99.55\% &  \\ \cline{1-6}
IoT Service & 15 & 5900 & 0 & 61 & 98.73\% &  \\ \cline{1-6}
Reboot & 0 & 23 & 2177 & 0 & 98.95\% &  \\ \cline{1-6}
Mirai Botnet & 2 & 5 & 0 & 2992 & 99.76\% & \multirow{-4}{*}{\textbf{Recall}} \\ \hline
 & 99.64\% & 99.18\% & 100\% & 98.00\% & \multicolumn{2}{c}{} \\ \cline{2-5}
\multirow{-2}{*}{} & \multicolumn{4}{c|}{\textbf{Precision}} & \multicolumn{2}{c}{\multirow{-2}{*}{\textbf{\begin{tabular}[c]{@{}c@{}}Accuracy :\\ 99.19\%\end{tabular}}}} \\ \hline
\end{tabular}
}
\end{table}

\subsection{Offline Evaluation} \label{section:5.3}
In this subsection, we verify the modified 7-layer CNN classifier modeling with our new dataset.

\subsubsection{Data Collection} \label{section:5.3.1}
As discussed earlier, our classifier aims to predict a given power instance whether it is one of the four classes. Thus, we collected power traces and created a new dataset collected by our Power Auditor device. Then, we manually labeled the collected instances to train the weights and biases of our online CNN model. Detailed testbed environments will be described in Section \ref{section:7.1}, whereas we present the data here first.

Table \ref{tab:dataset} illustrates the summary of the collected dataset. In our environment, we generated a specific scenario and collected over 2,000 power instances for each class. For example, we collected 4693 instances of 1.5 second-power traces when the IoT service is not running for the Idle class. We also collected power traces when the IoT service is running or the IoT device is rebooting. For the Botnet class, we downloaded an open-source of Mirai from Github \cite{etc:mirai} and built them on an IoT bot testbed. To generate Mirai instances in our local network, we modified the source code to attack only our IoT devices. Then, we collected 3,000 instances of malicious attacks when the IoT service is running or the system is Idle. This new dataset will also be available for download.

\subsubsection{Evaluation Results} \label{section:5.3.2}

Before building an online system, we first conducted an offline test to validate our CNN inference model. Accordingly, we ran a 5-fold cross-validation test; we divided the collected dataset into five subsets. Then, we trained four subsets and tested on the remaining subset. We repeated this procedure to calculate the total accuracy. With this newly collected dataset, the overall accuracy of the classification is about 99.19\%. We also calculated Recall, Precision, and F1-Score, and the values are 99.70\%, 99.20\%, and 99.45\%, respectively, which suggests low probabilities of false alarm and miss rate. Table \ref{tab:cmoff} shows the confusion matrix of the offline classification. Each class shows a good classification accuracy with low false-positive rates. Figure \ref{fig:off_result} also demonstrates that the training and testing results are not overfitting. Overall, this offline result of our classifier is slightly better than the state-of-art offline research \cite{Jung-01} with a larger dataset collected by our Power Auditor. Hence, these results demonstrate the credibility of our power auditing device as well as the modified CNN design.

\begin{figure}[t]
\vspace{-5mm}
	\centering
	  \subfloat[Classification Accuracy]{%
		\includegraphics[width=0.45\textwidth]{figures/off_accr.png}
		\label{fig:off_accr}}

	 \subfloat[Loss ]{%
		\includegraphics[width=0.45\textwidth]{figures/off_loss.png}
		\label{fig:off_loss}}
	\caption{Offline Training and Testing Results}
	\label{fig:off_result}
\vspace{-5mm}
\end{figure}

\subsection{Privacy-preserved Inference Protocol}\label{section:ppip}

In Section \ref{section:2.2}, we discussed the possible threat of distributed CNN design. In this subsection, we design a privacy-preserved inference protocol between Data Inferencer and Computing Cloud to avoid data leakage. Then, we will theoretically validate the data protection of the privacy-preserved protocol in Section \ref{section:6.3}.

\subsubsection{Motivation and Design}
We assume that Data Inferencer is a user-running application designed for Computing Cloud, as discussed in Section \ref{section:3}. Data Inferencer holds the Power Auditor's raw data, and Computing Cloud holds the CNN model. We utilized Packed Homomorphic Encryption (PHE) to allow Data Inferencer to encrypt the power trace data before uploading it to Computing Cloud, and enable the latter to run the CNN model on the ciphertext. It encodes multiple plaintext data elements into one ciphertext, and high-efficiently carries out element-wise homomorphic computation in a Single Instruction Multiple Data (SIMD) manner \cite{pack}. This tool is particularly useful for our system as each input includes thousands of sampling data due to the high sampling rate. Our design uses the CKKS-based PHE that works on element-wise float point data addition and multiplication in ciphertext \cite{ckks, seal}.

\begin{protocol}{Privacy-preserving CNN Inference}
\textit{Inputs:} Received power trace $\mathbf{X}$
\label{design protocol}
\\
\textit{Outputs:} Prediction Status $l$ on the given trace $\mathbf{X}$
\sbline
\textit{The Protocol:}
\begin{enumerate} [label=\arabic*.]
\item
Data Inferencer receives raw data {X} from Power Auditor and encrypts it as $[{X}']_{C}$. Then, it sends $[{X}']_{C}$ to Computing Cloud.
\item
Computing Cloud computes $[U]_{C} = K_{1}W_{1}'[X']_{C} + K_1 B_{1}' + N_{1}$ where $K_{1}$ is a non-zero positive random number, $W_{1}'$ is a kernel, $B_{1}'$ is the encoded bias, $N_{1}$ is a pseudo-random zero-sum vector. Finally, Computing Cloud sends $[U]_{C}$ to Data Inferencer.
\item
Data Inferencer decrypts $[U]_{C}$ and computes $Z_j=\sum_{i=0}^3 U_{i+j}$, where $j$ is the convolution block index. Then, it feeds the result to the ReLU activation function and mean pooling layer. Finally, it gets the result ${Y}$.
\item
Data Inferencer encodes and encrypts ${Y}$ as $[{Y'}]_{C}$ and sends it to Computing Cloud.
\item
Computing Cloud removes the random number $K_1$ and computes the $[V']_{C} = K_{2}W_{2}'[Y']_{C} + K_2 B_{2}' + N_{2}$, where the $k_2$ is a non-zero positive random number, $N_2$ is a pseudo-random zero-sum vector, and the subscript 2 of $w$ indicates the corresponding variables at the fully connected layer in our CNN model. Then, Computing Cloud sends $[V']_{C}$ to Data Inferencer.
\item
Data Inferencer decrypts $[V']_{C}$ and performs the summation similarly to Step 3 on each hidden unit block. Finally, it feeds the fully connected layer output into the softmax layer to get the final prediction status $l$ for a given power trace. Depending upon the policy, Data Inferencer takes further actions if $l$ represents a malicious intrusion.
\end{enumerate}
\end{protocol}

To make the linear part layer evaluate efficiently in this network, we separate multiplication and summation in the convolution and fully connected layers. The objective is to avoid the time-consuming permutation operation \cite{GAZELLE} and addition offline secret sharing strategies like other works \cite{MiniONN, qiao, delphi} for both of the convolution and fully connected layers. Our proposed protocol enables that the Data Inferencer can only compute cheap plaintext operations and Computing Cloud computes expensive ciphertext operations. Specifically, for the linear part like convolution layer, our privacy-preserved strategy is to make Computing Cloud carry out the multiplication operation in the ciphertext, while Data Inferencer conducts the summation operation to complete the convolution layer computing. After that, we directly feed the output into the next layer.

\subsubsection{Detailed Procedures}
The detailed privacy-preserved inference protocol for our CNN model is described in Protocol 1 and Figure \ref{fig:ckks}. In order to explain the main idea of our protocol, we take an identical CNN model with a smaller size input instead of the original input size. Recall that the input size of our CNN model is (1 x 2550), and the kernel size is (1 x 128) with a stride size 32 (See Section \ref{section:5.1}). Instead, we use a CNN model as an example whose kernel size is (1 x 4) with a stride size 2.

Let $X$ denote the received raw data by Data Inferencer from Power Auditor. The Data Inferencer first utilizes a PHE package that uses one packed vector to store multiple encrypted plaintext data. In Step 1, to implement the convolution function over the ciphertext, Data Inferencer encodes the data $X$ to $X'$, as illustrated in Figure \ref{fig:ckks}. Correspondingly, Computing Cloud encodes the weight $W_{1}$ and bias $B_{1}$ into packed vectors $W'$ and $B'$ in Step 2. With such encoding, the convolution between $X$ and $W$ can be implemented as the element-wise multiplication between $X'$ and $W'$, plus $B'$.

Steps 2 and 3 show how we securely implement the convolution layer among ciphertext. After Computing Cloud receives the ciphertext $[X']_{C}$ from Data Inferencer, Computing Cloud uses Eq. (\ref{eq:compute_z}) to compute the homomorphic multiplication result.

\begin{equation}
\label{eq:compute_z}
    [U]_C = K_1 \times W'_1 \times [X']_{C} + K_1 \times B'_1 + N_1,
\end{equation}

\begin{figure}[t!]
\centering
\resizebox{0.49\textwidth}{!}{%
\centerline{\includegraphics[width=0.5\textwidth]{figures/Data_Encode_cropped.png}}
}
\caption{Data operations on Data Inferencer and Computing Cloud in Steps 2 and 3}
\label{fig:ckks}
\vspace{-5mm}
\end{figure}

The purpose of using random numbers $N_1$ and $K_1$ in Eq. (\ref{eq:compute_z}) is to prevent Data Inferencer from inferring the model parameter $W'_1$ from its received message $[U]_C$. Computing Cloud first generates a zero-sum vector $N_{1} \in \mathbb Z$, which is a vector of pseudo-random numbers such that $N_{1} = \sum_{j=0}^3 n_{i, j}=0$ $(0 \leq j \leq 3)$, to mask each multiplication result, as illustrated in Fig. \ref{fig:ckks}. Then, Computing Cloud multiplies a non-zero positive random number $K_{1}$ to mask all multiplication results. With both masks $N_{1}$ and $K_{1}$, Data Inferencer is unable to learn the parameter $W_{1}'$ and $B_{1}'$ based on $[U]_C$ and $X'$. Note that $N_{1}$ and $K_{1}$ are different across different kernels in convolution. Finally, Computing Cloud sends the multiplication result $[U]_C$ to Data Inferencer.

Steps 5 and 6 are similar to Steps 2 and 3 but implement the fully connected layer. However, Computing Cloud only requires to choose a non-zero positive random number $K_{2}$ in Step 5 to mask the ciphertext multiplication result. At the end of Step 6, Data Inferencer directly feeds the weighted sum result of the fully connected layer (See Figure \ref{fig:cnn}) into the softmax layer to infer the Power Auditor status $l$. If the $l$ value represents a malicious intrusion on the IoT Device, Data Inferencer can take further actions, such as sending a notification to the administrator.

\subsection{Sliding Window Protocol} \label{section:5.2}

We introduce the interface design between Power Auditor and Data Inferencer for online inference. First, we determined a window size of 1.5 seconds for botnet intrusion input. The authors in \cite{Jung-01} revealed that Mirai and its variants have similar time distributions for the initial intrusion during the propagation period, which is less than 1.5 seconds. It should be noted that this invasion time may vary depending on systems or botnets. However, as long as it is noticeable to label, a window size would not be a critical issue.

\begin{figure}[t]
	\centering
	  \subfloat[Client-side Implementation]{%
		\includegraphics[width=0.24\textwidth]{figures/net1.png}
		\label{fig:net1}}
	 \subfloat[Server-side Implementation]{%
		\includegraphics[width=0.24\textwidth]{figures/net2.png}
		\label{fig:net2}}
	\caption{Sliding Window Protocol \textemdash\enspace We adopted Server-side scheme to reduce networking redundancy}
	\label{fig:net}
\end{figure}
\begin{table}[b]
	\caption{TCP Packet Interface Format between Power Auditor and Data Inferencer}
	\resizebox{0.46\textwidth}{!}{%
\begin{tabular}{l|l|l|l}
\hline
\textbf{Header} & \textbf{Type} & \textbf{Description} & \textbf{Example} \\ \hline\hline
\textbf{Hostname} & String & Hostname of Power Auditor & smpg1 \\ \hline
\textbf{Message ID} & String & Unique ID for each message & 4da77a50-aeaf-11 \\ \hline
\textbf{Sampling Rate} & Integer & Sampling Rate of Current Sensor (Hz) & 1700 (Hz) \\ \hline
\textbf{Window Size} & Integer & Length of a single window (ms) & 1500 (ms) \\ \hline
\textbf{\begin{tabular}[c]{@{}l@{}}Sliding Window\\ Ratio\end{tabular}} & Integer & Ratio of Overlapping Data & \begin{tabular}[c]{@{}l@{}}1: No Overlapping\\ 2 : 1/2 Overlapping\\ 3 : 1/3 Overlapping\end{tabular} \\ \hline
\textbf{\begin{tabular}[c]{@{}l@{}}Number of\\ Data Points\end{tabular}} & Integer & \begin{tabular}[c]{@{}l@{}}The number of data points \\ in a single TCP packet\end{tabular} & \begin{tabular}[c]{@{}l@{}}850 (Sampling Rate *\\ Window Size / 1000 /\\ Sliding Window Ratio)\end{tabular} \\ \hline
\textbf{Data Points} & Float & List of Power consumption data (mW) & 1854.878, ... (mW) \\ \hline
\end{tabular}}
\label{tab:format}
\end{table}

Next, we applied a sliding window with one-third overlapping for better classification accuracy. Our reasoning is that malicious instances could be truncated within a single window. With the overlapping sliding windows, our classifier can learn various patterns, including the truncated cases. Figure \ref{fig:net} illustrates the overlapping sliding window scheme in our DeepAuditor system. As shown in Figure \ref{fig:net1}, if a Power Auditor transmits a data packet of 1.5 seconds every 0.5 seconds, this will create redundant packets. Instead, a Power Auditor reads 0.5 seconds of data and sends it out once collected, as illustrated in Figure \ref{fig:net2}. Data Inferencer then receives the packet every 0.5 seconds. After receiving three consecutive packets, Data Inferencer assembles the last three packets and feeds them into the pre-trained CNN classifier for online inference. By doing so, we implemented the sliding window scheme between Power Auditor and Data Inferencer, avoiding unnecessary network redundancy in a distributed setting.

Accordingly, we implemented the interface format between our Power Auditor and Data Inferencer to deliver the collected power instances. Table \ref{tab:format} illustrates the packet header format. The number of data points is determined based on the following values. For example, our sampling rate is 1700, and the window size is 1.5 seconds. Consequently, the number of data points in a single-instance for classification is $1700 \times 1.5 = 2550$. Since we adopted the server-side sliding window scheme, Power Auditor also set the Sliding Window Ratio header to 3. Finally, the number of data points in a single TCP packet will be $2550 \div 3 = 850$ in our system. The message body contains a list of power-sensing data. Figure \ref{fig:example} describes an example of the raw TCP packet data.

\begin{figure}[t]
    \centering
      \includegraphics[width=0.5\textwidth]{figures/raw.png}
      \caption{TCP Packet Example in Sliding Window Scheme}
    \label{fig:example}
\end{figure}

\section{Online System Performance Evaluation} \label{section:7}

\begin{table}[b]
\caption{Online System Testbed}
\resizebox{0.49\textwidth}{!}{%
\begin{tabular}{c|c|c|c|c|c}
\hline
 & \textbf{Power Auditor} & \textbf{IoT Device} & \textbf{Mirai Bot} & \textbf{\begin{tabular}[c]{@{}c@{}}Data\\Inferencer\end{tabular}} & \textbf{\begin{tabular}[c]{@{}c@{}}Computing\\Cloud\end{tabular}} \\ \hline\hline
\textbf{\begin{tabular}[c]{@{}c@{}}Network\\ Deployment\end{tabular}} &  \multicolumn{4}{c|}{\begin{tabular}[c]{@{}c@{}}Local Network\end{tabular}} &  Cloud\\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Hardware\\ Platform\end{tabular}} & Raspberry Pi 3 & Raspberry Pi 3 & Raspberry Pi 3 & \begin{tabular}[c]{@{}c@{}}Apple Mac\\ Mini Server\end{tabular} &  Linux Server\\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}CPU\\ \end{tabular}} & \begin{tabular}[c]{@{}c@{}}1.4GHz,\\ Quad-core\end{tabular}& \begin{tabular}[c]{@{}c@{}}1.4GHz,\\ Quad-core\end{tabular}& \begin{tabular}[c]{@{}c@{}}1.4GHz,\\ Quad-core\end{tabular}& \begin{tabular}[c]{@{}c@{}}2.5GHz,\\ Dual-core\end{tabular}& \begin{tabular}[c]{@{}c@{}}2.6GHz,\\ 2*16 cores\end{tabular} \\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Memory\\ \end{tabular}} & 1GB&1GB&1GB& 8GB& 250GB \\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Sensor\\ used\end{tabular}} & \begin{tabular}[c]{@{}c@{}}Current Sensor\\ (INA219A)\end{tabular} & \begin{tabular}[c]{@{}c@{}}Camera Sensor\\ (Module v2)\end{tabular} & N/A & N/A & N/A \\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Operating\\ System\end{tabular}} & Raspbian 9 & Raspbian 10 & Raspbian 9 &
\begin{tabular}[c]{@{}c@{}}macOS 10.15\end{tabular}
 &
\begin{tabular}[c]{@{}c@{}}Ubuntu 18.04\end{tabular}
 \\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Software\\ Module\end{tabular}} & \multicolumn{1}{l|}{\begin{tabular}[c]{@{}l@{}}- Power Monitoring\\ - Networking\\ - Power Controlling\end{tabular}} & \begin{tabular}[c]{@{}c@{}}- Video Streaming\\ - Motion Detection\end{tabular} & \begin{tabular}[c]{@{}c@{}}Mirai \\ (Scanner/Loader)\end{tabular} & \begin{tabular}[c]{@{}c@{}} Privacy-preserved \\ Online Classifier \end{tabular} & \begin{tabular}[c]{@{}c@{}} Privacy-preserved \\ Online Classifier \end{tabular} \\ \hline
\end{tabular}}
\label{tab:testbed}
\end{table}

To evaluate the DeepAuditor system performance, we have implemented a prototype system in Python in our distributed environment. Section \ref{section:7.1} illustrates the prototype implementation. In Section \ref{section:7.2}, we validated the performance of the Power Auditor device. Section \ref{section:7.3} then demonstrates the system-level online classification performance. In Section \ref{section:6.3}, we theoretically analyze the data protection of the privacy-preserved CNN inference protocol. Finally, Section \ref{section:7.5} illustrates the scalability evaluation of the system.

\subsection{DeepAuditor Implementation} \label{section:7.1}
We have built a prototype DeepAuditor for proof of concept. Table \ref{tab:testbed} describes our testbed environments. We utilized Raspberry Pi 3 devices for Power Auditors and IoT devices since it is widely used for IoT device prototyping purposes. We also used a desktop for Data Inferencer in the same local network. Computing Cloud is located in a department cloud server outside the local network.

In Power Auditors, we have implemented the proposed modules, including the sliding window protocol, for real-time data collection in Python. Thus, Power Auditors can collect real-time power traces continuously, as presented in Figure \ref{fig:1}. For IoT device prototyping, we deployed an open-source camera software called MotionEye \cite{etc:motion} on the connected IoT device. This software includes motion detection as well as video streaming; thus, we consider the Raspberry Pi 3 running MotionEye as an IoT device. Overall, the Power Auditor is connected to an AC adapter, and the IoT device is provided power through the Power Auditor, as shown in Figure \ref{fig:auditor}.

As mentioned in Section \ref{section:ppip}, our privacy-preserved protocol utilized CKKS-based PHE \cite{ckks}, which involves three parameters \footnotemark: 1) polynomial modulus degree $N$, 2) ciphertext scale $s$, and 3) coefficient modulus. In our protocol, we set up the CKKS-related encryption parameters as follows: 1) Parameters for PHE scheme are selected for a 128-bit security level, 2) the selection of polynomial modulus degree $N$ is a smaller degree that allows to encode $N/2$ elements into one ciphertext. In our case, we selected $N = 32768$ for the convolution layer and $N = 4096$ for the fully connected layer, 3) a ciphertext scale $s=2^{40}$ is enough to store all the intermediate results in the convolution layer, and a ciphertext scale $s=2^{20}$ is enough to store all the intermediate results in the fully connected layer, and 4) In seal \cite{seal}, the modulus switching chain is set up as coefficient modulus for ciphertext against exponential noise growth during ciphertext operation. In our case, we selected the coefficient modulus $(60, 40, 40, 60)$ for the convolution layer and $(30, 20, 20, 30)$ for the fully connected layer.

\footnotetext{The reader is referred to \cite{ckks, seal} for more detail.}

We have also implemented our online CNN classifier architecture in Python in our distributed environment. Between the Data Inferencer and the Computing Cloud, we deployed the privacy-preserved inference protocol presented in Protocol 1. According to the protocol, the classification procedures comprise six steps; steps 2 and 5 are implemented in the Computing cloud, whereas steps 1, 3, 4, and 6 are implemented in the Data Inferencer. The final step makes a final decision for behavior classification prediction.

Moreover, we adopted pipeline processing \cite{pipeline} in those six inference steps; each step is being executed in parallel in Data Inferencer and Computing Cloud. Thus, Data Inferencer and Computing Cloud do not have to wait until all the steps are done. Having said that, a single CPU processor can handle arrived messages without knowing previous data. This pipelining increases the throughput of the instructions, which eventually leads to real-time inference for multiple IoT devices simultaneously. We will discuss the performance in Section \ref{section:7.5}.

Lastly, we have implemented the sliding window scheme between the Power Auditor and the Data Inferencer. Accordingly, the Power Auditor sends power traces every 0.5 seconds, and the Data Inferencer predicts a power trace of the 1.5 seconds data every 0.5 seconds. As a matter of course, Figure \ref{fig:net} itself validates the efficiency of the server-side sliding window implementation.

\begin{table}[t]
\caption{Power Auditing Devices Comparison}
\resizebox{0.3\textwidth}{!}{%
\begin{tabular}{c|c|c}
\hline
 &
  \textbf{\begin{tabular}[c]{@{}c@{}}Our\\ Power Auditor\end{tabular}} &
  \textbf{\begin{tabular}[c]{@{}c@{}}Monsoon\\ Power Monitor \cite{msoon}\end{tabular}} \\ \hline\hline
\textbf{\begin{tabular}[c]{@{}c@{}}Sampling\\ Rate\end{tabular}} &
  Up to 1.7kHz &
  Up to 5kHz \\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Measurement\\ Range\end{tabular}} &
  \begin{tabular}[c]{@{}c@{}}Up to 5.5V\\ Up to 2.3A\end{tabular} &
  \begin{tabular}[c]{@{}c@{}}Up to 13.5V\\ Up to 6A\end{tabular} \\ \hline
\textbf{Dimension} &
  3" x 2" x 1" &
  8" x 6" x 3" \\ \hline
\textbf{Weight} &
  0.3lb &
  4lb \\ \hline
\textbf{Software} &
  \begin{tabular}[c]{@{}c@{}}Text-based\\ Python Software\end{tabular} &
  \begin{tabular}[c]{@{}c@{}}Window GUI\\ Software\end{tabular} \\ \hline
\textbf{\begin{tabular}[c]{@{}c@{}}Online\\ Measurement\end{tabular}} &
  Available &
  Not Applicable \\ \hline
\textbf{Price} &
  \$25 &
  \$929 \\ \hline
\end{tabular}
}
\vspace{-5mm}
\label{tab:device}
\end{table}

\subsection{Power Auditor Performance} \label{section:7.2}

In Table \ref{tab:device}, we compare our power auditing device with the off-the-shelf power monitor Monsoon Power Monitor \cite{msoon} that was used in the offline study \cite{Jung-01}. Our Power Auditor supports a sampling rate of up to 1.7kHz and a voltage of up to 5.5V. Although these ranges are less than the Monsoon power monitor, it is enough for our system to classify IoT devices' behavior. On the contrary, the Power Auditor is much smaller and lighter than the Monsoon device, which makes our device convenient for ubiquitous power measurement. More importantly, our proposed device is able to measure power traces in real-time for online inference. The Power Auditor supplies 5V power to connected devices while measuring power consumption. In addition, since we wrote the Power Auditor software in Python, it can be incorporated with other prototype devices.

Table \ref{tab:metrics} describes the performance metrics for a single Power Auditor working with the servers. In short, the resource of Raspberry Pi 3 is superabundant to realize our Power Auditor device.
For example, the maximum CPU load in the Power Auditor is up to 76\%, which used roughly 20\% of the quad-core computing power. Memory (RAM) usage on online data collection is only 10MBytes out of 1GB (1\%). Based on the proposed sliding window design, the required network bandwidth between Power Auditor and Data Inferencer is only 120Kbps. This bandwidth can be covered by Bluetooth or even the Zigbee protocol. In addition, the power consumption of the Power Auditor is approximately 4\si{\watt} (800\si{\mA}) during the real-time inference, whereas it consumes 2\si{\watt} (400\si{\mA}) in Idle. Thus, the Power Auditor consumes about 400\si{\mA} in addition to the Idle status. Overall, our data confirm that the Power Auditor design is lightweight enough for an online auditing device.

Accordingly, we plan to re-design the Power Auditor prototype for future work based on the above requirements. Although the current prototype is still much cheaper than the Monsoon power monitor, it may be costly in large-scale deployment in view of the fact that the DeepAuditor system requires one Power Auditor for each IoT device. Thus, we will build a lightweight device upon real-world demonstration. Then, the prototype cost will even decrease on mass production of Power Auditor.

\subsection{Online CNN Classifier Performance} \label{section:7.3}

Based on the pre-trained CNN classifier, we measured online classification results in the same environment with a single Power Auditor. In this test, we provide the classification accuracy and other metrics to validate the classifier performance. Similar to the offline test in Section \ref{section:5.3}, we generated power instances of each class in real-time and conducted online inference to measure the metrics. For example, the IoT device was in Idle status for the Idle class, while the IoT device streamed video for the IoT service class. For the Mirai intrusion class, a bot device sneaked into the IoT device, and we measured the inference results on the intrusion events.

Table \ref{tab:cmon} shows our online classification results for each class. The result is almost the same as the offline classification result in Table \ref{tab:cmoff}. For example, an accuracy in the offline test is 99.19\%, and the online test has a 98.95\% accuracy. Overall, the results validate that our distributed classifier is able to distinguish different patterns of device behavior in real-time, including malicious intrusion as trained. Moreover, Table \ref{tab:metrics} also shows the performance of each distributed component in that the classifier is deployed in separate servers. The total inference time per power instance is about 520 milliseconds: 160ms in Data Inferencer and 360ms in Computing Cloud. The network rate between Data Inferencer and Computing Cloud is 11.375Kbps after encryption, and the memory usage per a single IoT device is 50MBytes in Data Inferencer and 30MBytes in Computing Cloud. Overall, these metrics are not overwhelming for online inference since we utilize cloud resources.

\begin{table}[t]
\centering
\caption{Online System Performance per IoT Device}
\resizebox{0.48\textwidth}{!}{%
\begin{threeparttable}

\begin{tabular}{c|c|c|c|c|c}
\hline
&\textbf{\begin{tabular}[c]{@{}c@{}}CPU Load\\ (Max\tnote{1}\enspace)\end{tabular}} & \textbf{\begin{tabular}[c]{@{}c@{}}Memory\\ Usage\end{tabular}} & \textbf{\begin{tabular}[c]{@{}c@{}}Network\\ Bandwidth\end{tabular}} & \textbf{\begin{tabular}[c]{@{}c@{}}Processing\\ Delay\end{tabular}} &
\textbf{\begin{tabular}[c]{@{}c@{}}Power\\Consumption\end{tabular}} \\ \hline\hline
\textbf{Power Auditor} & 76\% (400\%) & 10MB & 120Kbps & 25ms & 4\si{\watt} (800\si{\mA}) \\ \hline
\textbf{Data Inferencer} & 40\% (200\%) & 50MB & 11.375Kbps & 160ms & \textemdash \\ \hline
\textbf{Computing Cloud} & 35\% (3200\%) & 30MB & \textemdash & 360ms &\textemdash \\ \hline
\end{tabular}
  \begin{tablenotes}
    \item[1] Maximum CPU Load depends on the number of CPU cores, i.e., Dual-core CPU has a maximum 200\% CPU load.
  \end{tablenotes}
\end{threeparttable}
}
\label{tab:metrics}
\vspace{-5mm}
\end{table}

\begin{table}[b]
\caption{Confusion Matrix of Online Classification}
\centering
\label{tab:cmon}
\resizebox{0.42\textwidth}{!}{%
\begin{tabular}{c|c|c|c|c|c|c}
\hline
 & \multicolumn{4}{c|}{\textbf{Inference}} & \multicolumn{2}{c}{} \\ \cline{2-5}
\multirow{-2}{*}{\textbf{\begin{tabular}[c]{@{}c@{}}Ground\\ Truth\end{tabular}}} & Class 1 & Class 2 & Class 3 & Class 4 & \multicolumn{2}{c}{\multirow{-2}{*}{}} \\ \hline
Idle & 1832 & 0 & 0 & 0 & 100\% &  \\ \cline{1-6}
IoT Service & 2 & 1708 & 19 & 25 & 97.38\% &  \\ \cline{1-6}
Reboot & 1 & 0 & 1834 & 0 & 99.95\% &  \\ \cline{1-6}
Mirai Botnet & 2 & 21 & 5 & 1710 & 98.34\% & \multirow{-4}{*}{\textbf{Recall}} \\ \hline
 & 99.73\% & 98.79\% & 98.71\% & 98.56\% & \multicolumn{2}{c}{} \\ \cline{2-5}
\multirow{-2}{*}{} & \multicolumn{4}{c|}{\textbf{Precision}} & \multicolumn{2}{c}{\multirow{-2}{*}{\textbf{\begin{tabular}[c]{@{}c@{}}Accuracy :\\ 98.95\%\end{tabular}}}} \\ \hline
\end{tabular}
}
\end{table}

\begin{figure}[t!]
	\centering
	  \subfloat[Processing Delay per Step in Protocol 1]{%
		\includegraphics[width=0.44\textwidth]{figures/dist.png}
		\label{fig:dist}}

	 \subfloat[CDF of Response Time per Instance]{%
		\includegraphics[width=0.44\textwidth]{figures/cdf.png}
		\label{fig:cdf}}
	\caption{Online Classifier Processing Time}
	\label{fig:oc}
\end{figure}

Furthermore, Figure \ref{fig:dist} illustrates the processing delay of each step in the privacy-preserved inference protocol. For instance, it takes about $350ms$ for the Convolution procedure (Step 2) at Computing Cloud, which is the majority of the entire online classification. Other steps relatively consume less computing resources. In addition, Figure \ref{fig:cdf} demonstrates an empirical CDF function of the online classification response time. We observe that over 90\% of the inferences were done in $580ms$. Note that our system is designed to classify real-time instances per Power Auditor every 0.5 seconds. Thus, the DeepAuditor system needs to process two instances per second for each Power Auditor. Since we have implemented the pipeline processing in the inference protocol, the entire performance mainly relies on step 2, which is the most time-consuming job in our classifier. Even though most of the instances are predicted about 580 milliseconds later after the Data Inferencer receives the power instance, a Computing Cloud is able to classify two instances per second securely because step 2 takes at most 400 milliseconds, as presented in Figure \ref{fig:dist}. Therefore, as an entire system, the DeepAuditor is reliable for real-time inference for multiple IoT devices.

\subsection{Theoretical Analysis of the Privacy-preserved Inference Protocol} \label{section:6.3}
In this subsection, we demonstrate that our distributed classifier design is secure in that 1) Computing Cloud cannot obtain the client's power trace data, and 2) Data Inferencer cannot obtain the model parameters $W$ and $B$ of the CNN model in Computing Cloud. Hence, there is no information leakage between Computing Cloud and Data Inferencer.

We used a security analysis method in \cite{Goldreich} for the security analysis. We assume Adversary A can compromise either Computing Cloud or Data Inferencer. For example, Adversary A forwards the encoded input $\Bar{X}$ to our system. Simultaneously, for the ideal interaction, Adversary A forwards $\Bar{X}$ to a trusted functionality machine \textit{f} with the same model structure and parameters. \textit{f} is non-colluding with Adversary A. We want to show that the real output is computationally indistinguishable from the ideal output. We describe our analysis in detail as follows:

\subsubsection{\textit{Data Security against Compromised Data Inferencer}}
We assume that Data Inferencer is compromised by Adversary A. We use the simulator \textit{sim} to behave as Adversary A. The \textit{sim}, \textit{f} and Computing Cloud conduct the following steps: 1) \textit{sim} encodes the input data into a packed plaintext $\Bar{X}'$ based on the convolution block. Then, \textit{sim} encrypts it as $[\Bar{X}']_{sim}$. Finally, it forwards $[\Bar{X}']_{sim}$ to Computing Cloud and \textit{f}. 2) Computing Cloud and \textit{f} compute the ciphertext multiplication result $U = K_{s}W'[\Bar{X}']_{sim} + K_s B + N_{s}$ and $V = K_{f}W'[\Bar{X}']_{sim} + K_f B + N_{f}$ by Eq. (\ref{eq:compute_z}). $K_{s}$ and $K_{f}$ are random numbers selected by Computing Cloud and \textit{f}, respectively. Similarly, $N_{s}$ and $N_{f}$ are the pseudo-random zero-sum vectors selected by Computing Cloud and \textit{f}, respectively. After that, Computing Cloud and \textit{f} send $[U]_{sim}$ and $[V]_{sim}$ to \textit{sim}. 3) \textit{sim} decrypts $[U]_{sim}$ and $[V]_{sim}$ and computes the summation result $\bar{Z}$ and $Z$.

Next, our privacy-preserved protocol is secure against the semi-honest Data Inferencer. Adversary A first analyzes the intermediate results $U$ and $V$. Computing Cloud's output $U$ is computationally indistinguishable from \textit{f}'s output $V$ because the random numbers $K_{s}$ and $K_{f}$ are uniformly distributed in $\mathbb Z_{> 0}$, and $N_{s}$ and $N_{f}$ are also uniformly distributed in $\mathbb Z$. It is hard for Adversary A to learn random numbers $K_{s}$ and $N_{s}$ based on $U$ and $V$. Next, Adversary A can analyze the final convolution result $\Bar{Z}$ and $Z$. Let $*$ represent the convolution function. Adversary A can only view the convolution result $\Bar{Z} = [K_sW*X+K_sB)]$ from Computing Cloud and $Z = [K_fW*X+K_fB)]$ from \textit{f}. Computing Cloud's output $\Bar{Z}$ are also computationally indistinguishable from \textit{f}'s output $Z$ because the random number $K_s$ and $K_f$ are uniformly distributed in $\mathbb Z_{> 0}$. It is hard for Adversary A to reveal the model parameters $W$ and $B$ based on $\Bar{Z}$ and $Z$. In summary, the proposed classifier is secure in the convolution layer computation. Likewise, it is similar to prove that the classifier is also secure on the fully connected layer computation. As a result, our system is secure against the semi-honest Data Inferencer. At the same time, based on convolution result, $\Bar{Z}$ is computationally indistinguishable from $Z$.

\subsubsection{\textit{Data Security against Compromised Computing Cloud}}

Similarly, we assume that Computing Cloud is compromised by Adversary A.
However, our system is secure against Computing Cloud because Adversary A cannot reveal Data Inferencer's input data $X$ from $[X']_{C}$ based on the fact that the PHE algorithm is semantically secure \cite{pack}.

\begin{table}[t]
\centering
\caption{Comparison of Computation Complexity}
\label{complexity:computiaon}
\resizebox{0.48\textwidth}{!}{%
\begin{tabular}{c|c|c|c}
\hline
\textbf{Methodology} & \textbf{Permutation} & \textbf{Multiplication} & \textbf{Addition} \\ \hline\hline
\textbf{Gazelle-Convolution} & $\mathcal{O}(r)$ & $\mathcal{O}(rC)$ & $\mathcal{O}(rC)$ \\ \hline
\textbf{DeepAuditor-Convolution} & $0$ & $\mathcal{O}(C)$ & $\mathcal{O}(C)$ \\ \hline
\textbf{Gazelle-FC} & $\mathcal{O}(k)$ & $\mathcal{O}(k\frac{Cn_in_o}{n})$ & $\mathcal{O}(k\frac{Cn_in_o}{n})$ \\ \hline
\textbf{DeepAuditor-FC} & $0$ & $\mathcal{O}(\frac{Cn_in_o}{n})$ & $\mathcal{O}(\frac{Cn_in_o}{n})$ \\ \hline
\end{tabular}}
\label{tab:result}
\vspace{-5mm}
\end{table}

\subsubsection{Computation Complexity Analysis} \label{section:7.3.3}

We analyzed the overall computation complexity for the convolution layer and fully connected (FC) layer of DeepAuditor in Table \ref{complexity:computiaon}. Let denote that $r$ is kernel size for the convolution layer and $C$ is the number of output channels for the convolution layer. We compared our work with a naive method of Gazelle \cite{GAZELLE}, which is a more state-of-the-art protocol with speed-up than some classic privacy-preserving inference protocol like \cite{cryptonets}. Based on our benchmark on Protocol 1, Computing Cloud needs $C$ times ciphertext multiplication and addition to compute the intermediate result $[U]_C$. Meanwhile, Data Inferencer only conducts a cheap plaintext summation $[U]_C$ to complete the convolution output $Z_j$. The total computation cost for our protocol design is much less than the Gazelle, which requires $r$ times ciphertext permutation, $rC$ times ciphertext multiplication, and $rC$ times ciphertext addition.

To improve the computation efficiency in the FC layer. We extended our data encode operation presented in Figure \ref{fig:ckks}, which enables all mean-pooling outputs to be packed into one ciphertext. Let $n_i$ denote the number of data in each output channel of mean-pooling, $n_o$ denote the output data for the FC layer, $n$ denote the number of slots for one ciphertext, and $k$ denote the kernel size for the FC layer. Each ciphertext can hold $\frac{Cn_in_o}{n}$ data. Compared with Gazelle's input packing method \cite{GAZELLE}, the Computing Cloud in our protocol needs less than $k$ time ciphertext multiplication and addition. The FC layer of our protocol also does not require ciphertext permutation, while Gazelle still requires $k$ times ciphertext permutation.

\subsection{Scalability Evaluation} \label{section:7.5}

We deployed our online CNN classifier in a distributed environment to offload computation resources. Thus, the cloud servers can handle multiple IoT devices simultaneously. We then evaluated how many IoT devices the cloud servers can support for intrusion detection.

\begin{figure}[b!]
	\centering
	\vspace{-6mm}
	  \subfloat[CPU Utilization]{%
		\includegraphics[width=0.38\textwidth]{figures/cpu.png}
		\label{fig:cpu}}

	 \subfloat[Processing Time in Step 2 ]{%
		\includegraphics[width=0.38\textwidth]{figures/scale.png}
		\label{fig:scale}}
	\caption{Scalability Performance Evaluation}
	\label{fig:scalability}
	\vspace{-6mm}
\end{figure}

According to Figure \ref{fig:2}, a single Computing Cloud supports multiple Data Inferencers and Power Auditors. To test the scalability of our system, we set up a distributed environment with eight Power Auditors, two Data Inferencers, and one Computing Cloud. Thus, each Data Inferencer is connected to four Power Auditors, and the Data Inferencers are connected to the same Computing Cloud. The eight Power Auditors collect power traces of the respective IoT devices for online inference. Figure \ref{fig:scalability} shows the performance results as the number of Power Auditors increases. In Figure \ref{fig:cpu}, as the number of Power Auditors increases, the CPU utilization of the Computing Cloud increases linearly. The Computing Cloud's CPU utilization per Power Auditor is approximately 35\%, which is consistent with the result in Table \ref{tab:metrics}. Moreover, when we tested with eight Power Auditors, the total CPU utilization is still less than 300\% out of 3,200\% (32 Cores).

Furthermore, Figure \ref{fig:scale} validates that the DeepAuditor classifies multiple IoT devices' data in real-time. As demonstrated in Section \ref{section:7.3}, the inference time mostly relies on the processing time in step 2 of our protocol, which is the convolution layer. As long as the processing time in step 2 is less than 0.5 seconds, which is our input data period, our DeepAuditor system can guarantee real-time inference for online detection. In Figure \ref{fig:scale}, although we only tested eight Power Auditors for proof of concept, the processing time does not change much as the number of Power Auditors increases.

Overall, these results demonstrate that Computing Cloud supports inference computations for multiple IoT devices as much as CPU cores are available. For example, step 2 takes approximately $350ms$ on average, and the CPU utilization of Computing Cloud is about 35\% for handling a single Power Auditor. Based on the pipelining processing, a single core of Computing Cloud can handle up to three Power Auditors per second. Since the Computing Cloud server in our environment has 32 CPU cores, this server technically supports about 90 Power Auditors on online CNN inference. Note that the current evaluation is bounded by the processing time in step 2. Thus, we also plan to enhance the processing time in the future.

\section{Discussion} \label{section:8}

In this section, we present our thoughts with regard to limitations and future work.

\textbf{Power Auditor Prototype}
Since we utilized a Raspberry Pi device for prototyping the Power Auditor, our current version is still bulky and costly for ubiquitous power measurement. Thus, we plan to make Power Auditor a thumb-drive type device that can be attached to off-the-shelf IoT devices. This job will require PCB board manufacturing. If so, the Power Auditor will even be smaller and cheaper than the current prototype. Still, the software modules are going to be the core parts.
In addition, it should be noted that Power Auditor is only accessible within a local network although it looks like another IoT device that supports the Internet connection. Consequently, users only need to set up the Power Auditor when they first place the DeepAuditor system.

\textbf{Learning Architectures }
Due to the streaming nature of the input data, a recurrent neural network (RNN) would have been another option in our system. However, it is popular in natural language applications, while CNN is more widely used in power-auditing applications \cite{Li:ej, Jung-01}. Thus, we adopted and modified the state-of-the-art CNN architecture into our system. Instead, we designed the Power Auditor device and realized the distributed system for online inference. Our offline and online evaluation results demonstrate the effectiveness of our system design.

\textbf{Comparison with Gazelle Protocol} In our evaluation, we did not compare our protocol design with diagonal and hybrid methods in Gazelle. Instead, we compared our protocol with a native method in Gazelle. Our reasoning is that the input data of DeepAuditor is a one-dimensional power trace matrix. Thus, it is not applicable to compare Gazelle's advanced methods with our protocol.

\textbf{Comparison with other techniques}
DeepAuditor is the first online realization to look into the power consumption of IoT botnet intrusion after IoT botnets emerged. Fundamentally, we monitor the power consumption of the connected IoT devices in real-time for intrusion detection, which has not been addressed before. Therefore, we focused on demonstrating the validity of our system design since other approaches may not be directly comparable with the DeepAuditor. Meanwhile, we compared the online classification result with the offline research \cite{Jung-01} and analyzed our privacy-preserved protocol with the state-of-the-art protocol Gazelle \cite{GAZELLE}.

\textbf{Measurement for Future Botnets}
Unexpected power trace events could impact our model. However, since the distributed classifier has more than one million parameters for modeling, it can bear various power profiles. Our solution is more like an anomaly-based solution. Based on trained data, our design can also tell strange traffic as anomaly behavior. The higher accuracy is, the better classifier against new patterns is. Thus, the high classification results demonstrate the potential of our design.

\textbf{Malign Behavior besides Botnet Attacks}
Information Stealer attacks are conventional in web and mobile computing environments \cite{infostealer}. On that account, attackers can also withdraw sensitive data from IoT devices, such as stored images. Specifically, the authors in \cite{Maiti:2019vc} exploited infrared bulbs to access users’ private data. This is a new type of attack on IoT devices that exploits side-channel information (Infrared transmission). However, no system to date has defended IoT devices against the possible exfiltration attack of users' private data. Accordingly, we plan to characterize the malicious behavior from this specific attack using our system.

\section{Related Work}\label{section:9}
In Section \ref{section:9.1}, we first summarize the related work with regard to IoT security and detection methods. Then, Section \ref{section:9.2} introduces the existing work concerning about preservation of data privacy.

\subsection{IoT Security via Power Auditing} \label{section:9.1}

The literature has scrutinized IoT security against botnets for decades \cite{Aversano:9999bh, Anonymous:2021gb}, which include power auditing-based detection methods as well as network-based solutions. While network-based solutions have struggled to address the endpoint security on resource-constrained IoT devices, power side-channel information has been utilized to infer malicious behavior on end devices.

\begin{table}[b]
	\caption{Comparison of IoT Security via Power Auditing}
	\resizebox{0.49\textwidth}{!}{%
\begin{tabular}{c||c|c|c|c|c|c}
\hline
\textbf{} &
\textbf{\begin{tabular}[c]{@{}c@{}}Target\\Attacks\end{tabular}} &
\textbf{\begin{tabular}[c]{@{}c@{}}Testbed\\Environment\end{tabular}} &
\textbf{\begin{tabular}[c]{@{}c@{}}Learning\\Method\end{tabular}} &
\textbf{\begin{tabular}[c]{@{}c@{}}Concurrent\\Capacity\end{tabular}} &
\textbf{\begin{tabular}[c]{@{}c@{}}Auditing\\Device\end{tabular}} &
\textbf{\begin{tabular}[c]{@{}c@{}}Classification\\Accuracy\end{tabular}} \\ \hline\hline
\textbf{Jung \cite{Jung-01}} &\begin{tabular}[c]{@{}c@{}}Botnet\\Detection\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Offline\\Modeling\end{tabular}
&\begin{tabular}[c]{@{}c@{}}1-D\\CNN\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Single\\Device\end{tabular}
& Monsoon \cite{msoon}
& 96.5\%
\\ \hline
\textbf{Li \cite{Li:ej}}
&\begin{tabular}[c]{@{}c@{}}DoS\\Attacks\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Online\\Classification\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Dual\\1-D CNNs\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Single\\Device\end{tabular}
&\begin{tabular}[c]{@{}c@{}}IoT\\Hardware\end{tabular} \cite{Hindle:ug}
& MSE 0.032 \\ \hline
\textbf{Myridakis \cite{Myridakis:2021tg}}
&\begin{tabular}[c]{@{}c@{}}DoS\\Attacks\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Online\\Classification\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Spike\\Detection\end{tabular}
&\begin{tabular}[c]{@{}c@{}}Single\\Device\end{tabular}
&\begin{tabular}[c]{@{}c@{}}IoT\\Hardware\end{tabular}
& 100\%
\\ \hline
\textbf{DeepAuditor}
&\begin{tabular}[c]{@{}c@{}}\textbf{Botnet}\\Detection\end{tabular}
&\begin{tabular}[c]{@{}c@{}}\textbf{Online}\\Classification\end{tabular}
&\begin{tabular}[c]{@{}c@{}}\textbf{Distributed}\\1-D CNN\end{tabular}
&\begin{tabular}[c]{@{}c@{}}\textbf{90+}\\Devices\end{tabular}
&\begin{tabular}[c]{@{}c@{}}\textbf{IoT}\\Hardware\end{tabular}
&98.9\%\\ \hline
\end{tabular}}
\label{tab:related}
\end{table}

Especially for resource-constrained devices such as IoT devices, using side-channel information is efficient in that they usually do not require many resources. For example, some pioneering works used power side-channel data to detect malign behavior on mobile devices in the early 2010s \cite{Kim:2008cl}\cite{Yang2017OnIB}. Recently, several researchers \cite{Li:ej, Myridakis:2021tg, Jung-01} have worked on IoT devices to characterize malicious behavior via power side-channel information as IoT botnets have been popular. Myridakis et al. \cite{Myridakis:2021tg} implemented a power monitoring circuit for botnet prevention for IoT devices. However, their system mainly focused on detecting massive DoS attacks on IoT devices instead of intrusion detection with a spike detection method. Li et al. \cite{Li:ej} addressed energy auditing for physical and cyber attacks. For cyber attacks, it utilized dual-CNNs to infer massive DoS attacks such as network flood using energy meters \cite{Hindle:ug}. Jung et al. \cite{Jung-01} pioneered IoT botnet intrusion detection via power modeling. While their CNN classifier showed promise in detecting subtle differences in power traces, they conducted an offline study with a bulky and expensive power monitor. Thus, it is not practical for ubiquitous botnet detection on IoT devices. In summary, Table \ref{tab:related} summarizes the related works on IoT botnet detection methods for endpoint security via power auditing. Overall, we are the first to realize a distributed online classification system for botnet intrusion detection via ubiquitous power auditing.

\subsection{Preservation of Data Privacy} \label{section:9.2}

Preservation of data privacy has been widely studied in the literature. There are three major approaches. The first approach is differential privacy \cite{dp}, which injects noise into query results, such as perturbating stochastic gradient descent (SGD) \cite{Abadi2016ccs}. However, the additive noise may degrade model accuracy.
The second approach designs privacy-preserved protocols based on secure multi-party computations. They usually distribute secrets among a group of parties to achieve security computations at the expense of high computational overhead and strong security assumptions \cite{secret1}\cite{secret2}\cite{secret3}. Thus, they are rarely adopted in general scenarios.

A new solution for privacy preservation was introduced using the fully homomorphic encryption \cite{gentry2009}. It allows users to encrypt data and offload the computation to a cloud. The cloud computes encrypted data and sends back encrypted results \cite{cryptonets}\cite{onn}\cite{juvekar18gazelle}. However, the nonlinear activation computation cannot be supported by the homomorphic encryption, and the approximation often has to be used. Compared with existing work, our solution is novel in that our proposed scheme capitalizes on the proposed CNN model structure to adopt a smart design to address this problem.

\section{Conclusion } \label{section:10}
In this paper, we proposed a distributed online intrusion detection system for IoT devices via power auditing. We first developed a portable power-auditing device to measure power side-channel information of IoT devices in real-time. In our system, we then designed partitioned servers for online intrusion detection. We adopted and modified a one-dimensional CNN classifier into non-colluding servers in our distributed setting. Between the system components, we also proposed distributed protocols to avoid data leakage and reduce networking redundancy. Altogether, the DeepAuditor system is the first online intrusion detection system that classifies multiple IoT devices’ behavior via power traces.

The evaluation results demonstrated that our online system performs well in laboratory settings. The CNN classifier predicted IoT devices’ behavior from power instances with up to 98.9\% accuracy, which outperforms the state-of-the-art offline experiments. Moreover, we theoretically validated the data protection of the privacy-preserved protocol; our inference protocol is secure against anyone of the non-colluding servers. Finally, we evaluated the scalability of our system; in our distributed setting, the DeepAuditor is able to support about 90 IoT devices simultaneously for botnet intrusion detection. We further plan to validate our system across different types of IoT devices and enhance the processing performance in real-world settings.

Cryptography and Security (cs.CR); Machine Learning (cs.LG)