

\subsection{Microarchitectural Side-channel Attack}
\begin{comment}
A side-channel analysis recovers sensitive information from an application's execution by analyzing the indirect effects of that execution.
Side-channel analysis has been successfully applied on measurements of structures like caches~\cite{cacheTut,cacheside}, branch predictors~\cite{branchAttack}, and interconnects~\cite{lordofthering}, as well as on a computer's physical signals like power~\cite{Kocher2011} and electromagnetic (EM) emanations~\cite{genkinEm}.

Recently, attackers have begun using ML classifiers for signal analysis, 
leveraging ML's strength in pattern recognition~\cite{dlsca,mlsurvey,hospodar2011machine,perin2018lowering,kp2020comprehensive}. These classifiers, particularly Deep Neural
Networks (DNNs), can automatically identify information-carrying patterns, overcoming simple defenses like noise addition or signal misalignment~\cite{cnnjitter,perin2018lowering}.

ML-based side-channel analyses have recovered sensitive data from encryption modules~\cite{mlsurvey}, caches~\cite{mlcaches}, power measurements~\cite{powerml,kubota2020deep,hospodar2011machine,scaul,maghrebi2016breaking}, EM emissions~\cite{ascad} and on-chip interconnects~\cite{lordofthering}. It has also been demonstrated that ML-based attacks are able to identify encryption keys with higher accuracy and fewer measurements than conventional methods~\cite{kubota2020deep,lerman2015template}. Indeed, ML classifiers are gaining prominence among attackers for side-channel analysis~\cite{kp2020comprehensive}, and there is an urgent need for  hardware designers to develop countermeasures against this new class of attacks.
\end{comment}

\begin{figure}[ht]
\centering
\includegraphics[width=\linewidth]{Figures/fig_scamodel.pdf}
\caption{A typical model of architectural side-channel attacks.}
\label{fig:sidechannel}
\end{figure}

A typical architectural side-channel attack with ML is illustrated at Figure~\ref{fig:sidechannel}.
First, a secret information can be leaked if the victim application's activity depends on the information.
Next, an attacker can indirectly observe such activity via shared resources like caches~\cite{cacheTut}, branch predictor~\cite{branchAttack}, PCI express~\cite{tan2021invisible}, and on-chip interconnects~\cite{lordofthering}.
Finally, the attacker can decode the observed activity patterns to infer the secret information like cryptographic keys~\cite{emAttack} and accessed websites~\cite{websiteAttackModel}.

Recently, attackers have begun using ML for side-channel analysis~\cite{batteryAttack, lordofthering}.
ML attacks not only amplify leakage from unprotected channels~\cite{crossDL, maghrebi2016breaking, lerman2015template}, but also circumvent defenses like noise addition, masking, and shuffling~\cite{perin2018lowering, cnnjitter}.



\subsection{Adversarial Attacks}
\label{aml}

Recent studies have found that ML models are vulnerable to attacks.
It is possible to generate \textit{adversarial examples}~\cite{adversarialexample} against 
an ML classifier which,
with very small perturbations to the inputs (even imperceptible to humans), drastically change the classification outcomes.

Sometimes, an adversarial attacker may target a black-box classifier whose parameters are not known at the time of the attack.
Fortunately, adversarial examples are often transferable~\cite{transferability} in that an attack targeting one classifier can be effective at another classifier.
One possible way to automatically generate such adversarial perturbations is training an ML generator that generates the adversarial examples.
Adversarial GAN (AdvGAN)~\cite{advgan} is an example of this method to train the generator.
AdvGAN adversarially trains the generator using the generative adversarial network (GAN)~\cite{gan} structure, amplifying its efficacy for black-box attacks.

\begin{comment}
Defending the side-channel attack can be performed in any point of this model.
Firstly, the programmer can modify the victim application in that its observable states are independent to the secret information.
However, it requires a huge programming effort and significant performance loss to guarantee safety of the application.
Second, the HW architect can \emph{partition} the hardware resource so that the activity is not observable from outside.
This method also requires software support to utilize the secure partition, and some HW resources like power and memory are very hard to separate.
The most straightforward defense is \emph{obfuscation} by adding noise to the side-channel using a noise generator.
The biggest benefit of obfuscation is that there is zero need for software modification.
Meanwhile, an effective noise generator may require high noise level which incurs high overhead.
In this work, we leverage adversarial machine learning to minimize both information leakage and noise level.


\subsection{Compressing a Deep Learning Model}

A DNN model can require huge computing resources in its original form~\cite{cnnperf}.
Hence, it is often
necessary to compress it into a smaller form before deploying it for inference. There are 
several popular compression techniques. They include network pruning~\cite{deepcompression}, where some low-weight
edges are removed, and knowledge distillation~\cite{distillation}, where a smaller-sized network is trained to imitate the original one. These techniques
reduce  
the amount of computation and memory requirements. Another technique is quantization~\cite{deepcompression} to lower-precision numbers,
as DNNs are often insensitive to precision loss.
Using lower precision numbers  
can substantially reduce power and area cost. 
Fixed-point 8-bit integers (INT8) are often used to represent quantized values.
\end{comment}

\subsection{Adversarial Attack for Side-channel Defense}

There are two prior works that use adversarial attacks
as a countermeasure against side-channel attacks.
However, they cannot be considered as complete practical solutions due to their limitations.
Picek et al.~\cite{advattackposter} considered the power signals 
created by various plaintexts and analyzed them with  
ML attackers. Then, they showed that, with small, adversarial modifications to the trace, they can 
mislead the attackers. However, they only use classifiers trained with unprotected signals, which is
unrealistic as attackers can always train classifiers with the presence of the protection.

Rahman et  al.~\cite{mockingbird} showed the use of AML method against website fingerprinting 
attacks through traffic measurement.
Their defense is not very effective, in that  attackers can still achieve 38--42\% accuracy,
while a perfect defense of website fingerprinting with 95 classes 
 allows attackers to reach only 1.05\% accuracy.

Most of all, these systems require the full trace of a signal to produce the perturbations for the signal. As a result, they are post-processing solutions, not implementable to defend systems in the real world; they are proofs of concept.
A practical solution must be a dynamic defense, which produces the perturbations on the fly.


\subsection{Designing the Defender Network}
\label{sec:defender}

A defender is an ML model that determines the current noise to add given the measurements of previous signals.
The implementation method of the defender depends on the timing and frequency requirements of the target side-channel.
For example, it is possible to implement the defender by software if the side-channel operates at resolution of milliseconds.
On the other hand, some architectural side-channels can run at much faster rate, even once in a few nanoseconds.
In those cases, it is necessary to integrate the defender to the hardware design to meet the timing requirements.

The hardware installation cost is the main factor that determines the allowable size of the neural network.
Contemporary neural network accelerator designs can achieve up to 10 TOPS/W~\cite{reuther2019survey} so that one can estimate the maximum amount of computation per inference given the power budget and timing requirements.
For instance, assume that the power budget is 1W and the defender needs to run at 500MHz.
Then, the computation per defender inference must not exceed 20k operations = $(10 TOPS/W) \times (1W) / (0.5GHz)$.

Most side-channel signals are sequences so that it is desirable to use an ML model that catches sequential dependencies.
Recurrent neural networks (RNN) are good candidates because they can handle sequential dependencies with memory states and tend to have low inference cost.
Transformers and convolution neural networks can also manage sequential patterns but they are not suitable for most cases due to their high computational costs.


\begin{comment}
As indicated above, a relatively inexpensive structure to use as a defender is a 
3-layer DNN  with a GRU~\cite{gru} layer in the middle.
The recurrent hidden state of the GRU feeds back as input to the next time step.
This design enables the model to process the sequential patterns from signals of any length.
The network uses randomization techniques (i.e., dropout~\cite{dropout} and noise injection~\cite{gannoise}) 
to stabilize its training and add randomness after deployment.

After some empirical testing, we choose an input history vector of 32 elements. We believe that this number of
past samples provides a good window of observation at reasonable cost. In terms of outputs,
the defender for the memory side channel needs to generate a small positive number of cycles to add to the latency
of a memory access. Hence, its output is rounded up to positive values using the ReLU activation function
and quantized to an 8-bit integer. The defender for the power side channel can generate positive or negative
outputs to increase or decrease the current power consumption, respectively. Moreover, the output is a continuous value and,
therefore, we use a 32-bit floating point (FP) number. 

The two designs have very different timing requirements. The defender for the memory side channel needs to
process loads at the rate that they are being satisfied by main memory. Since such loads may come from
different cores, our defender design is pipelined to take in a new access every memory controller
cycle. However, we allow the defender to 
 take  about 10 cycles to fully process an access. For these reasons,
 the defender needs to be implemented in hardware and
compressed aggressively. 
The parameters are quantized to 8-bit integer numbers to further reduce the hardware cost.
However, the recurrent hidden state of the GRU layer should maintain a higher precision because the loss can accumulate through the recurrent feedback.
Therefore, we quantize
the hidden activations to FP16. Also, we use dropout~\cite{dropout} per hidden layer because it is a cheaper 
randomization than Gaussian noise. 

In the end, the defender only needs
16 hidden neurons. The defender cost is equivalent to less than 1\% of the multicore power and area.
The implementation is given in Section~\ref{sub_impl_mem}.

The defender for the power side channel measures and actuates on power every 20 ms. Consequently, its response
time is not very critical. Hence, we 
implement it in software and deploy it without compression nor quantization. We use 32-bit FP numbers and
choose 64 hidden neurons to keep the inference latency within 1ms.
The defender leverages the standard Gaussian noise injection~\cite{gannoise}, whose amplitudes are
configurable parameters.

Figure~\ref{fig_generator} shows the resulting defenders. It can be shown that the defenders for the memory and power 
side channels need about 2K and 26K parameters, respectively.
\end{comment}





\subsection{Training the Defender in \modelname{}}
\label{sec:defendergan}



Once we have designed the defender and collected labeled signals from the side channel,
we train the defender using proposed \modelname{} network.
Figure~\ref{fig_architecture} shows how we train the networks in the \modelname{}.
It follows the design principles of AdvGAN, but designed to solve the side-channel defense problem, instead of adversarial attack.

The first difference is that the defender must generate the noise on-the-fly so that it can only leverage previous history of the signal when determining the current noise level.
Specifically, at step $t$, it is fed the most
recent 32 samples \{$x_t$, $x_{t-1}$..\} and produces the perturbation $p_t$.
The resulting noisy trace $x+p$ is passed to the classifier and discriminator as an attacker can collect the signal and decode it offline.

Second, the defender's objective is to fully randomize the classifier's predictions, not confusing it to a specific target.
Therefore, when training the defender, the classification target of the classifier is the uniform probability distribution instead of a single fake label.
In binary classification, we use the flipped target $(0\rightarrow 1, 1\rightarrow 0)$ instead, because we empirically find that the flipped target is better against binary classifiers.
The defender is evaluated by how close the predictions are to the random guesses.

Next, unlike in an AdvGAN, the classifier is also adversarially trained against the defender using perturbed signals generated by it.
The reason is that the defender must resist adaptive attacks that are trained in presence of the noisy signals.
Also, this adversarial training with the dynamically adapting classifier helps the defender being transferable to other adaptive attackers.

Finally, the discriminator does not distinguish real and fake signals as there is no such distinction after deploying the defender.
Instead, the discriminator acts like another classifier which gives a different type of adversarial pressure to the defender.
While the classifier minimizes the cross entropy between its predictions and the true labels, the discriminator tries to maximize Wasserstein distance~\cite{wgan} between label distributions.

The defender $g$ generates the perturbation $p=g(x)$, and  the classifier and the discriminator are trained with the perturbed signal $x+p$.
The classifier $f$ is trained with the cross-entropy loss $L_C(y,f(x+p))$ between its prediction and the true label $y$.
The discriminator $d$ is optimized to minimize our \emph{one-to-all} Wasserstein loss $L_D(y,d(x+p))$.
While the original Wasserstein loss can only handle binary cases (real or fake), the one-to-all can manage multi-label cases.
With the discriminator outputs $d(x+p) = \{d^{(1)}(x+p), \dots d^{(n)}(x+p)\}$, the one-to-all loss $L_D$ is defined as below.
$$L_D(y,d(x+p)) = \mathbb{E}_{i\neq y}(d^{(i)}(x+p)) - d^{(y)}(x+p)$$
Minimizing $L_D$ should maximize the one-to-all distances between label distributions.
Like in Wasserstein GAN, we apply weight clipping to the parameters with the threshold of $+-0.01$.
The defender's loss $L_G$ has three components: (1) the Kullback-Leibler divergence $kl(\cdot,\cdot)$ between the classifier output probabilities $f(x+p)$ and the uniform probability $u$ (inverted probability in binary case), (2) the negated discriminator loss $L_D$ to minimize the distances, and (3) the hinged L1-norm of the perturbation output.
$$ L_G = kl(f(x+p),u) - \lambda_d L_D + \lambda_h max(0, ||p|| - P)$$
By adjusting the value of $P$, we can control the perturbation level of the defender.
The detailed implementation and hypereparameters ($\lambda_d, \lambda_h$) are available at the source code in the supplementary materials.

\begin{comment}
The three networks are adversarially trained simultaneously, with different loss 
functions.
This adversarial training emulates the adaptive attack to
help the defender to achieve better transferability to other classifiers.
The classifier is trained by the cross-entropy loss between its prediction 
probabilities and the true label.
The discriminator is optimized by Wasserstein loss~\cite{wgan}, which tries to maximize the Wasserstein distances between distributions.
In cases of more than two labels, we optimize the discriminator for \textit{one-to-all} Wasserstein loss.
This means that, given (i) the true label $y$ of the signal $x$ and, (ii) for the perturbed signal $x+p$, the discriminator output $d(x+p) = \{d^{(1)}(x+p), \dots d^{(n)}(x+p)\}$ (which is the set of distances from $x+p$ to the distributions of the $n$ labels), then the one-to-all Wasserstein loss is defined as $Loss_W(y,d(x+p)) = d^{(y)}(x+p) - \mathbb{E}_{i\neq y}(d^{(i)}(x+p))$. 
Also, we perform weight clipping~\cite{wgan} to the discriminator with the threshold of 0.01.

The defender is trained with three losses: (1) the Kullback-Leibler divergence between the classifier output probabilities and the uniform probability, (2) the negated Wasserstein loss of the discriminator, and (3) the L2-norm of the perturbation output.
The first loss optimizes the defender to confuse the classifier, while the second loss optimizes it for 
perturbed outputs that are indistinguishable to the discriminator.
Finally, the  L2-norm loss minimizes the perturbation level to lower the overhead caused by 
the defender's perturbations.
The loss can be hinged by a constant to adjust the allowed perturbation level.
The detailed implementation is
available at the source code in the supplementary materials.

While \modelname{}'s structure is similar to that of AdvGAN~\cite{advgan}, it has a few design differences to match the side-channel defense problem.
First, the defender can only leverage previous history of the signals for each noise level decision because the defender must generate the noise on-the-fly.
Second, the classification target of the defender is the uniform probability distribution instead of the single fake label.
This is because the defender's objective is fully randomizing the classifier's inference result rather than faking the specific targets.
Finally, the discriminator does not discriminate real and fake signals as all perturbed signals become real once the defender goes active.
Instead, the discriminator acts like another classifier which gives different type of adversarial pressure to the defender.
While the discriminator is not a necessity, it helps the defender achieve better transferability.
\end{comment}

\begin{comment}
The defender for the power side-channel is trained with a 64-neuron GRU (Figure~\ref{fig_generator}) and deployed without compression.
The memory side-channel defender is trickier because it is hard to train such a small DNN directly.
Consequently, we train a bigger defender with a 160-neuron GRU first.
Then, we leverage GAN compression techniques~\cite{gancompression} to compress the GRU layer to
16 neurons, as shown in Figure~\ref{fig_generator} (left).
The detailed setup and hyperparameters used to  apply  GAN compression to the defender 
are described in~\cite{anonymous}.
\end{comment}

\subsection{Assessing Defender Transferability}
\label{sec:adaptive}
\begin{figure}[ht]
\centering
\includegraphics[width=0.85\linewidth]{Figures/fig_traintest.pdf}
\caption{Training and deploying a defender.}
\label{fig_traintest}
\vskip -0.1in
\end{figure}

Figure~\ref{fig_traintest} illustrates the procedure of testing the transferability of the defender against adaptive attacks.
The defender can only be adversarially trained with a certain classifier (Classifier 1) on a certain training data (Train 1).
Then, we emulate the adaptive attack using a new classifier (Classifier 2) and a new training data (Train 2).
Here, Classifier 2 is trained with the presence of the defender's noise and the defender's parameters are frozen as we cannot update the defender after deployment.
Finally, we test the efficacy of Classifier 2 at a new environment (Test).

We select various types of ML classifiers for Classifier 2 and, for each of them, perform the steps shown in Figures~\ref{fig_traintest}b and c.
The best performing classifier's test accuracy is reported, which is the worst case for the defender.
This determines the expected channel capacity of the defended side-channel.

\begin{comment}
The defender trained with a certain classifier must be transferable to
other classifiers. Consequently, after we train a defender, we select various types of ML classifiers
for the classifier and, for each of them, perform the steps shown in Figures~\ref{fig_traintest}b and c.


As described above, the  defender is trained using a certain classifier and input data set. The
operation is shown in Figure~\ref{fig_traintest}a, where  classifier and data set are called 
{\em Classifier 1} and
{\em Train 1}, respectively.
However, the defender must also be effective against a variety of other classifiers that
the attacker may use in deployments. 
Specifically, 
the attacker may use a {\em deployed} defender
to train a potentially stronger classifier ({\em Classifier 2}) with a new input data set ({\em Train 2})
(Figure~\ref{fig_traintest}b). The goal is to become more effective against the defender. 
Then, the attacker will use  the trained {\em Classifier 2} to attack deployment runs with real (i.e., {\em Test})
input data sets and perform accurate predictions of the secret data (Figure~\ref{fig_traintest}c).
Then, we report the highest classification accuracy attained by any classifier.
This determines the expected channel capacity of the defended side-channel.
\end{comment}
\subsection{Deploying the Defender}
\label{sec:deploy}

After training and evaluating the defender, the defender with the best transferability is chosen and deployed for the side-channel obfuscation.
As discussed above, the defender may be deployed via software or hardware depending on the characteristics of the side-channels.
The defender may additionally have to be compressed for a hardware deployment.
This compression can be performed using the GAN compression technique~\cite{gancompression}.
Given the bigger \emph{teacher} model, the compressed \emph{student} can be trained using both the knowledge distillation loss~\cite{distillation} and \modelname{}'s loss functions simultaneously.
We can quantize the compressed model using smaller precision numbers to further reduce the hardware cost.

\begin{comment}
The two cases require very different implementations.

\subsubsection{Defender for the Memory Contention Side Channel}
\label{sub_impl_mem}

We implement the defender in hardware in the memory controller (MC). As shown in
Figure~\ref{fig_defense}, every load request arriving at the MC is
intercepted, and its address and current time ($t_{in}$) are stored in a Latency Buffer (LAB) for 
the requesting core.
When the memory releases the reply message at $t_{out}$, the 
LAB for the core is searched. On finding the matching entry, the hardware completes
the entry by saving $t_{out} - t_{in}$.
When the LAB for a core has as many completed entries as the length $N$ of the
History Vector, $N$ entries are
passed to the defender, which computes the stall time ($t_s$) to add to the youngest of the
$N$ reply messages. Then,
this reply
message is stalled for $t_s$ at the Delay Buffer, and the LAB is shifted one
position. 

\begin{figure}[ht]
\centering
\includegraphics[width=\linewidth]{Figures/fig_defender_mc.pdf}
\caption{Defender for the memory contention side channel.}
\label{fig_defense}
\end{figure}

There is a LAB for each core in the machine, since any core could run the attacker
process. In the worst case, the defender may need to process one History Vector 
every MC cycle. Consequently, we pipeline the defender so that it can take one 
History Vector every MC cycle. Since the defender is shared by all the cores, and
the GRU layer contains state specific to a
core (i.e., 16 FP16 numbers forming the GRU hidden state), the hardware saves and restores these per-core 
numbers every time the defender is used by a load from a different core.

Most of the hardware implementation cost of the defender originates from matrix multiplications.
They require hardware for 1552 INT8-FP16 MACs and 512 INT8-INT8 MACs.
We estimate their cost based on Johnson's analysis~\cite{rethinkingfloat} for TSMC 28nm, scaled down~\cite{processscaling} to 7nm.
Assuming a single MC with dual-channel DDR4-3200 memory, we conservatively estimate that
our added hardware  
consumes 
a maximum power of 0.65W and uses an area of 0.69$mm^2$.
These are less than 1\% of the TDP (105W) and die size (161.4$mm^2$) of the target 16-core multicore.

We estimate that the critical path of the defender shown in Figure~\ref{fig_generator} (left) can be 
pipelined in about 10 pipeline stages. In each stage, many operations are performed in
parallel. Approximately, the stages are: two stages for each of the two  feed-forward layers  (one for a MAC operation
and one for a bias addition) and six stages for the GRU layer (MAC, sigmoid function,
two element-wise multiplications,
bias addition, and tanh function).
Given an MC frequency of 1.6GHz, the defender operation takes less than 7ns. 
Some of this time can be hidden by routing and flow-control operations.
Since the defender can process a request at every MC cycle, it doesn't affect the main memory throughput.



\subsubsection{Defender for the Application Power Side Channel}

We implement the defender in software as a priviledged process running on one of the 
cores. We build on the framework of Maya~\cite{maya}, a mechanism used to obfuscate power signals.

Figure~\ref{fig_maya}a shows the Maya 
framework.
Maya consists of two parts. The mask generator creates 
sinusoidal- and gaussian-based power curves; the robust controller 
uses control theory techniques to control the system inputs (e.g., processor
frequency) to enforce the power  curves in the target computer. 

\begin{figure}[ht]
\centering
\includegraphics[width=\linewidth]{Figures/fig_maya.pdf}
\caption{Maya~\cite{maya} framework (a) and defender plugged into the same framework (b).}
\label{fig_maya}
\end{figure}

Figure~\ref{fig_maya}b shows 
how our defender is plugged into the Maya framework.   
It replaces the mask generator, directly providing the perturbation values to the controller.
Our uncompressed defender architecture is lightweight enough to operate in software.
The average inference latency of our C++ implementation is $\approx$1ms, which is negligible compared to the 20ms power sampling period.

\subsection{Application to Other Victim Applications}
\label{sec:victimchange}

A  defender is specific to the victim applications that it is trained for.
Sometimes, a defender may also be effective for other types of victim applications. 
However, in general, to defend other types of victim applications requires 
the system designer to collect data for the new   applications, train a
defender using the data, and deploy the new defender. Note that 
the defender design itself is typically not specific to the victim application.
Therefore, as we change the victim applications,
we can typically re-use the defender design and replace only its internal weight parameters.

We can support this form of reconfigurability by placing the defender parameters
in registers or memories, and provide a way for the software to update them across
victim applications.
For the application power side-channel defender, we can easily update the parameters since we deploy it via software.
On the other hand, we need an software-hardware interface to re-program the parameters of the memory side-channel defender.

This interface to reconfigure the parameters of the memory side-channel defender can be
model-specific registers (MSR),  microcode, or firmware. For example, if 
an MSR interface is used, the software can write to an MSR the ID of the parameter it wants to 
change and its new value. 
For our defender, one MSR register is sufficient 
to perform a full reconfiguration. This is because the defender has 2K parameters
(weights and biases) as shown in Figure~\ref{fig_generator} (left), and each of them is 
an INT8 value. Consequently, we write to the MSR 12 bits to specify the parameter ID and
8 bits to specify the new value. Since one MSR write takes about 1$\mu$s, reprogramming all
the parameters of the defender takes about 2ms.

With this support, one can disable the defender by 
writing zeros to all parameters.
Further, a victim application can be protected by applying a binary patch that: (i) writes the application-specific defender parameters at the beginning and (ii) disables the defender at  program exit.
\end{comment}
\subsection{Defending Memory Contention Side Channel}

\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{Figures/fig_defender_mc.pdf}
\caption{Defender for the memory contention side channel.}
\label{fig_defense}
\end{figure}

The memory contention side-channel can leak information of a victim application through memory latency patterns.
We consider a chip multiprocessor where the victim application runs on one core and the attacker on another.
The victim's execution path depends on a secret bit; the attacker repeatedly accesses the main
memory and measures the latencies.
From the pattern of access latencies, an attacker can deduce the secret bit.
This attack is is based on the work of Paccagnella et al.~\cite{lordofthering}.


In this attack, we run iterative functions from two crypto applications: the RSA~\cite{rsa} and the
EDDSA~\cite{eddsa} decryption algorithms.
The victim applications run in loops, where each iteration processes one bit.
The samples of memory access latencies during an iteration form an input signal; the 
corresponding secret bit of the iteration  is the target label.

The envisioned defender is in a hardware unit in the memory controller (MC) that records the time
when a load arrives at the MC and the time when the main memory produces the requested data. To obfuscate the
latency of the load access, the defender stalls the returning data for a certain time period.
The defender cannot know which memory transaction is issued by the attacker so that it needs to process every load arriving to the MC.
In modern dual-channel DRAM (DDR4-3200), the fastest rate of memory transactions is once in every 1.25 nanoseconds.
Such a fast hardware module needs to consume reasonable power and area.
We believe that 1\% of a contemporary CPU's power and area are justifiable to invest for a side-channel defense, which are 1W and 1mm$^2$, respectively.

\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{Figures/fig_generator.pdf}
\caption{Architectures of the defenders for the memory (left) and power (right) side channels.}
\label{fig_generator}
\end{figure}

The left side of Figure~\ref{fig_generator} shows the defender architecture to match that cost.
We choose a structure of 3-layer DNN  with a GRU~\cite{gru} layer in the middle.
While we only process the history of 32 samples at each time step, the memory of GRU enables handling longer sequential patterns.
As we can only add latencies to obfuscate the side-channel, ReLU is applied to the final output of the defender model.
While most of the activations and weights can be quantized to INT8, the memory cell of the GRU layer is quantized to FP16 to prevent accumulate precision loss through the feedback loop.
For a noise injection~\cite{gannoise} method, we choose Dropout~\cite{dropout} to further reduce the cost.
Using the existing estimation results~\cite{rethinkingfloat} scaled down~\cite{processscaling} to TSMC 7nm, the estimated power and area are 0.74W at maximum and 0.69mm$^2$.
The power consumption is proportional to the main memory utilization so that the average power should be far less than the estimated maximum.
Since direct training of a tiny DNN is hard, we train a bigger model with 160 hidden neurons with \modelname{} and compress it to the target architecture. 







\subsection{Defending Application Power Side Channel}

\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{Figures/fig_maya.pdf}
\caption{Maya~\cite{maya} framework (a) and an ML defender plugged into the same framework (b).}
\label{fig_maya}
\end{figure}

The second case considers a chip multiprocessor running one of several victim applications.
The attacker periodically measures  the chip power consumption using the Intel RAPL interface~\cite{intelRapl}.
Based on the measurements over time, the attacker tries to deduce which application is running. 
We run PARSEC~\cite{parsec} applications so that the attack becomes a multi-label classification problem.

The side-channel operates at a slower speed because the fastest rate of RAPL measurements is once in a millisecond.
Hence, the envisioned defender is a software program.
The process measures the power consumed using RAPL, and spawns compute-intensive threads,
adds idle time, and changes the frequency
to distort the power consumed. The setup is based on the one described in Maya~\cite{maya}. 
Maya uses a randomized mask generator to distort the power trace; in this paper, we replace it with an ML defender, as shown in Figure~\ref{fig_maya}.

The defender's ML structure is illustrated at the right side of Figure~\ref{fig_generator}.
We can use a bigger DNN model with FP32 precision because we have $\approx 10^6 \times$ more time to process one inference compared to the memory side-channel defender.
The inference computation takes less than 1ms, which is negligible compared to Maya's 20ms sampling period.
An important difference in this deployment is that the defender must determine the noise for the \textit{next} time step, because it makes a decision only after measuring the current power.
\subsection{Data Collection}

\paragraph{Memory contention side-channel}
We base our attack code on the ring side-channel code of Paccagnella et al.~\cite{lordofthering}. We collect signal traces by running
two victim  crypto applications on a desktop with an Intel i5-9400 processor. 
One is the RSA decryption algorithm in \textit{libgcrypt}~\cite{libgcrypt} 1.5.2.
The other application is the EDDSA algorithm in the \textit{libgcrypt} 1.6.3.
The measurements are segmented into signals, each of which corresponds to a loop iteration of the target function. Each signal contains 42 and 105 samples for RSA and EDDSA, respectively.
To estimate the performance impact of our defender, we use the SST simulator~\cite{sst} modeling the desktop that generated the traces.
We run several memory-bound SPEC 2017 applications from~\cite{disintegratedcontrol}, to see the performance impact of higher memory latency.

\paragraph{Application power side-channel}
For this attack, we use the codebase of Maya~\cite{maya}.
We collect power traces on a desktop with an Intel Xeon W-2245 processor using RAPL~\cite{intelRapl}.
As victim applications, we use 10 PARSEC 3.0 \cite{parsec} applicatons (blackscholes,
bodytrack, canneal, freqmine, vips, streamcluster, splash2x.radiosity, splash2x.volrend, splash2x.water\_nsquared, and splash2x.water\_spatial) with simlarge inputs.
Each PARSEC signal is 500-samples long
to record the longest workloads (10 seconds).
The AML defender is trained using PyTorch and deployed to a real system using the Maya codebase and
the LibTorch API.

\subsection{Machine Learning Models}
\label{types_classifiers}

For the classifier in the \modelname{}, we use 1-D CNNs, which typically show the best attack accuracies.
For the  discriminator, we use an MLP, producing one 
real number for binary discrimination and $N$ numbers for $N$-class discrimination.
See Section~\ref{sec:sidechannel} for defender designs.

To perform our transferability analysis, we consider 7   ML classifiers.
Five of them are DNNs implemented using PyTorch:
a default 16-layer CNN  (CNN), a 25-layer CNN (CNN-Deep), a 16-layer CNN with double hidden neurons (CNN-Wide), a GRU-based
one (RNN), and an MLP (MLP).
The other 2 are non-DNNs implemented with the scikit-learn library: an SVM and a
K-Nearest Neighbor (KNN).

Additional implementation details (data collection, environmental setup, and evaluation methods) are available at the appendix and the source code in supplementary materials.

\subsection{Security Provided}

\begin{table*}[t]
\caption{Attacker accuracy of seven classifiers as they attack three variations of our ML defender that were trained with 
the CNN classifier. No Discriminator is an uncompressed model trained without the discriminator in \modelname{}.}
    \label{table_transfer}
    \vskip 0.1in
\centering
\setlength{\tabcolsep}{8pt}
\renewcommand{\arraystretch}{1.1}
\begin{tabular}{|r|c|c|c|c|c|c|c|}
\hline
\multirow{2}{*}{Defender} & \multicolumn{7}{c|}{Classifier Accuracy}                      \\ \cline{2-8}
                           & MLP   & RNN   & CNN    & CNN-Deep & CNN-Wide & SVM   & KNN                             \\ \hline
Uncompressed                   & 0.513 & 0.507 & 0.507  & 0.506    & 0.507    & \textbf{0.524} & 0.513                    \\ \hline
No Discriminator           & 0.507 & 0.503 & 0.516  & 0.513    & 0.511    & \textbf{0.537}      & 0.528                                \\ \hline
Compressed                 & 0.526 & 0.520 & \textbf{0.532} & 0.528    & 0.528    & 0.531 & 0.511                    \\ \hline

\end{tabular}
\vskip -0.1in
\end{table*}

We evaluate how efficiently our ML defender secures the memory contention side-channel in terms of the security over noise level.
Here, the noise level is counted by the average extra delay in CPU cycles.
We consider three different obfuscation methods as baselines.
Gaussian and Gaussian Sinusoid are noise generator methods from Maya~\cite{maya} that generate random signal targets.
Since we cannot apply negative noise to the channel, the noise is applied only when the target is higher than the measured latency.
Another baseline is Padding to Constant which sets a minimum constant latency and delays all transactions to take at least that latency.
We adjust the average noise level by modifying their hyperparameters such as noise average and constant value.
The defender's noise level can also be adjusted by changing the L1 hinge value while training it.

Figure~\ref{fig_curve} shows the accuracy of the attack for each defender and level of noise---showing only the data
for the highest accuracy of the 7 classifiers. 
Note that the accuracy of 0.5 is the target for a perfect defense because the crypto key attack is a binary classification problem.
Padding to Constant is the only design that can achieve perfect defense---but only if we allow a large perturbation level of 88 average cycles or more.
The randomized generators (Gaussian and Gaussian Sinusoid) are not effective, especially at low average latencies.
Finally, our ML defender is the most secure for medium to low average latencies.
For the best defender (i.e., 43 average cycle latency), it can be shown that the randomized generators leak 12 times more bits 
per measurement, with the proportionally lower time to reconstruct the secret. 
This defender is used for further evaluations.



\begin{comment}

To visually understand how our AML defender deceives the classifiers, 
Figure~\ref{fig_perturb} shows the latency of the different samples in two signals. The leftmost one corresponds to 
the secret bit equal to 1, while the rightmost one to the bit equal to 0. For each signal, we show the original 
curve in blue and the perturbed one in orange. We see that
the resulting perturbed signals are very similar to each other regardless of their original secret bits.

\begin{figure}[ht]
\centering
\includegraphics[width=\linewidth]{Figures/fig_perturb_2x1.pdf}
\caption{Examples of original signals (in blue) and after they are
perturbed  by the AML defender (in orange). The plots are labeled
with the bit they carry.
}
\label{fig_perturb}
\end{figure}
\end{comment}

\begin{table*}[ht]
\caption{IPCs of applications with defensive ML or padding to constant defense  normalized to
the IPCs without defenses.}
\label{table_perf}
\vskip 0.1in
\renewcommand{\arraystretch}{1.1}
\centering
\begin{tabular}{|r|c|c|c|c|c|c|c|c|c|}
\hline
                   & GCC   & Bwaves & MCF   & cactuBSSN & LBM   & Leela & Fotonik3D & XZ    & Geomean \\ \hline
ML Defender & 0.986 & 0.869  & 0.906 & 0.969     & 0.875 & 0.912 & 0.994     & 0.853 & \textbf{0.919}   \\ \hline
Padding to Constant    & 0.913 & 0.759  & 0.812 & 0.878     & 0.768 & 0.817 & 0.982     & 0.737 & \textbf{0.829}   \\ \hline
\end{tabular}
\end{table*}

\subsection{Transferability to Other Classifiers}
\label{sec:memory_transferability}

Our ML defender is trained with a CNN classifier and a discriminator. We now assess its transferability to 7 classifiers as shown in Table~\ref{table_transfer}.  
We consider three variations of our defender: the uncompressed design (160 hidden neurons),
the uncompressed design trained without a discriminator (No Discriminator), and the compressed and quantized design.
 
The range of accuracy numbers in the table is 0.51-0.54. This means that the generated perturbations 
are transferable to various types of attackers. We also see that 
CNNs with more layers (CNN-Deep) or hidden neurons (CNN-Wide) do not show better accuracy compared to the original CNN.
This observation suggests that using reasonably bigger DNN is unlikely to break the defense.
In addition, the existence of the discriminator during training typically helps the defender achieve better transferability, especially to non-DNN classifiers (SVM and KNN). This is despite the fact that, with discriminator, the average 
perturbation of the defender is smaller (43 versus 51 cycles).
Finally, compressing and quantizing the model exposes slightly more leakage, but the model is still transferable to a variety of classifier types.
Overall, these results suggest that our defender is likely to be transferable to other types of classifiers.

\subsection{Different Victim Application}

We now generate the defender for the EDDSA application as described in Section~\ref{amldefense}.
Hereby we maintain the same defender architecture and only the parameters of the defender are different.
Specifically, Table~\ref{table_victimchange} shows the 
attacker accuracies of the best classifiers against generators trained on one victim application
({\em Training}) but used to defend  another victim ({\em Target}).
This shows that we can reuse the same defender hardware for different victim applications by only re-configuring the parameters.

\begin{table}[ht]
\caption{Attacker accuracies against generators trained on one victim ({\em Training}) 
but used to defend  another victim ({\em Target}), along with their average added cycles.}\label{table_victimchange}
\vskip 0.1in
\renewcommand{\arraystretch}{1.1}
\centering
\begin{tabular}{|r|c|c|c|}
\hline
\multirow{2}{*}{Training Victim} & \multicolumn{2}{c|}{Target Victim} & \multirow{2}{*}{Avg. Cycles} \\ \cline{2-3}
                                 & RSA              & EDDSA           &                                                                       \\ \hline
RSA                              & 0.532            & 0.566           & 43                                                                    \\ \hline
EDDSA                            & 0.661            & 0.543          & 38                                                                    \\ \hline
\end{tabular}
\vskip -0.1in
\end{table}

If we train for RSA and defend EDDSA, we attain some level of protection. 
This means that our AML defender is at least partially transferable to other victim applications.
However, if we train for EDDSA and defend RSA, the attacker accuracy is high (0.661).
This data suggests that the perturbation patterns for short signals (e.g., RSA with 42 samples) may be applicable 
to longer signals (e.g., EDDSA with 105 samples), but not the other way.

\subsection{Performance Overhead}


We compare the performance overhead of activating our ML defender to that of applying the
Padding to Constant defense with an average number of cycles of 88---i.e., the cycles for which it
attains perfect protection. We run the memory-intensive SPEC applications with these defenses
and measure the average Instructions Per Cycle (IPC). Table~\ref{table_perf} shows the resulting
IPCs normalized to the IPCs without defenses. 
From the table, we see that the ML defender and 
Padding to Constant attain 8\% and 17\% relative slowdown, respectively, than with no defense.
This overhead is largely proportional to the average latency added per access (43 and 88,
respectively). Overall, Defensive ML limits the performance overhead of securing the side-channel.


\section{Related Work}
\label{relatedwork}

There are two prior works that use adversarial ML attacks
as a countermeasure against ML analysis of  signals~\cite{advattackposter,mockingbird}.
These systems require the full trace of a signal to produce the perturbations for the signal. As a result, they are
post-processing solutions, not implementable to defend systems in the real world; they are
proofs of concept. Our technique is a dynamic defense, 
which produces the perturbations on the fly. It is an architectural
solution suitable for deployment in real systems to protect them.

In addition, these prior works have  limitations that our technique solves.
Specifically, Picek et al.~\cite{advattackposter} considered the power signals 
created by various plaintexts and successfully analyzed them with  
ML attackers. Then, they showed that, with small, adversarial modifications to the trace, they can 
mislead the attackers. However, they only use classifiers trained with unprotected signals, which is
unrealistic. Our methodology uses strong attackers that are trained with signals {\em already perturbed} by the defensive AML.
The second work by Rahman et  al.~\cite{mockingbird} showed the use of AML against website fingerprinting 
attacks through traffic measurement.
Their defense is not very effective, in that  attackers can still achieve 38--42\% accuracy,
while a perfect defense of website fingerprinting with 95 classes 
 allows attackers to reach only 1.05\% accuracy. We use strong defenders trained adversarily with an
advanced \modelname{} methodology, attaining effective defense.



There are some related works that discuss using ML  for countermeasures against ML-based side-channel attacks.
However, they either are unable to  show  AML effectiveness and generality, 
or use ML techniques only to help other defenses.
In the first class, we have Picek et al.'s work~\cite{advattackposter}. In a poster, they outline
gradient-based adversarial techniques~\cite{adversarialexample} to counter ML-based side-channel analysis.
However \josep{Raghav augment}, they only use classifiers trained with unprotected signals, providing no evidence  that the method works for  attackers that are trained with perturbed signals.


Overall, our defensive AML proposal, 
through strong ML methodology and the ability to operate dynamically, is an effective generic technique 
that can be broadly used by computer architects. We propose a workflow to design, train, evaluate, and
deploy defenders for different architectural environments.

There are two  works where ML is used not to obfuscate a signal, but  
to help other   techniques to do so.
Gu et al.~\cite{advcounter} designed a countermeasure against a power side-channel attack by combining the one-pixel attack~\cite{onepixel} with the insertion of noise instructions by the compiler.  
The one-pixel attack uses ML to choose  the point in the code where the noise instructions should be inserted;
the compiler then inserts the noise instructions.
 Rijsdijk et al.~\cite{rlcountermeasure} applied reinforcement learning (RL) to help counter ML-based 

 attacks.
The countermeasure consists of standard methods (i.e., jitter, desynchronization, or
noise insertion); the RL model's role is to choose the optimal 
combination of these methods in a given context.

Bertrand et  al.~\cite{howtofool} showed that non-ML label cheating can fool ML attackers.
However, they concluded that one can design informed attackers that
can easily circumvent them. 

There are multiple non-ML techniques to obfuscate information in particular side channels. Three of the most
relevant are Maya~\cite{maya}, Camouflage~\cite{camouflage}, and DAGGuise~\cite{dagguise}.
Maya~\cite{maya} re-shapes power signals into gaussian sinusoid signals with the help of control theory;
our approach can improve Maya by replacing the signal generator. 
Camouflage~\cite{camouflage} and DAGGuise~\cite{dagguise} re-shape memory traffic, even using fake requests to meet the desired target shapes. While Camouflage re-shapes the \textit{distribution} of inter-arrival times, DAGGuise reshapes the inter-arrival times for \textit{all} requests/responses. Both techniques determine the target inter-arrival times offline with profiling. Our work differs 
in several ways. First, we dynamically determine the target shape instead of  statically. 
Second, while the techniques can, in theory, re-shape memory traffic in any form, they restrict themselves to only a few shapes due to the large profiling overheads---e.g., DAGGuise considers a target shape that has the same latency between all requests~\cite{dagguise}. Our defender picks any shape.
Third, our defense does not create fake requests which consume memory bandwidth.
Fourth, defensive AML can be applied to other types of signals like power, while these two techniques are limited to timing side-channels.
\end{comment}
\section{Conclusion}
\label{conc_sec}

This paper showed that {\em Defensive} ML is a practical, general, 
and effective architectural technique
to  obfuscate signals from  
architectural side channels.
Our approach is based on strong ML methodology
and the ability to operate dynamically. 
We proposed a multi-network structure called \modelname{} to train  defenders adversarially.
We showed a workflow to design, implement, 
train, and deploy  transferable  defenders for different environments. We successfully applied
defensive ML to thwart two very different side-channel attacks: one
based on memory contention  and the other on application power. 
Future work will involve applying defensive ML to more environments.
\section{Introduction}
\label{intro}
\input{1_intro}

\section{Background}
\label{back}
\input{2_background}


\section{Side-channel Defense Problem}
\label{lands}
\input{3_mldefense}

\section{Defensive ML}
\label{amldefense}
\input{4_defensiveaml}

\section{Applying Defensive ML to Side-channels}
\label{sec:sidechannel}
\input{5_sidechannel}



\section{Experimental Methodology}
\label{setup}
\input{6_setup}

\section{Memory Side-channel Defense Evaluation}
\label{memoryeval}
\input{7_memoryeval}

\section{Power Side-channel Defense Evaluation}
\label{powereval}
\input{8_powereval}


\input{9_conclusion}



