grizzly/deneir
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update proposal

Browse source
This commit is contained in:
Arthur Grisel-Davy 2023-06-13 21:50:12 -04:00
parent f20570f5d0
commit 737c930a15
13 changed files with 751 additions and 228 deletions
Download patch file Download diff file Expand all files Collapse all files

98
PhD/research_proposal/bibliography.bib
View file

@ -1976,3 +1976,101 @@ keywords = {activity recognition, activity sensing, energy monitoring, infrastru
location = {Copenhagen, Denmark},
series = {UbiComp '10}
}
@misc{hdd_malware,
title = {Indestructible malware by Equation cyberspies is out there – but don’t panic (yet)},
howpublished = {\url{https://www.kaspersky.com/blog/equation-hdd-malware/7623/}},
note = {Accessed: 2023-03-15}
}
@INPROCEEDINGS{8057232,
author={Chen, Yimin and Jin, Xiaocong and Sun, Jingchao and Zhang, Rui and Zhang, Yanchao},
booktitle={IEEE INFOCOM 2017 - IEEE Conference on Computer Communications},
title={POWERFUL: Mobile app fingerprinting via power analysis},
year={2017},
volume={},
number={},
pages={1-9},
doi={10.1109/INFOCOM.2017.8057232}
}
@article{sayakkara2019survey,
title={A survey of electromagnetic side-channel attacks and discussion on their case-progressing potential for digital forensics},
author={Sayakkara, Asanka and Le-Khac, Nhien-An and Scanlon, Mark},
journal={Digital Investigation},
volume={29},
pages={43--54},
year={2019},
publisher={Elsevier}
}
@ARTICLE{9727162,
author={Kim, Taehun and Shin, Youngjoo},
journal={IEEE Access},
title={ThermalBleed: A Practical Thermal Side-Channel Attack},
year={2022},
volume={10},
number={},
pages={25718-25731},
doi={10.1109/ACCESS.2022.3156596}}
@article{page2003defending,
title={Defending against cache-based side-channel attacks},
author={Page, Daniel},
journal={Information Security Technical Report},
volume={8},
number={1},
pages={30--44},
year={2003},
publisher={Elsevier}
}
@article{halevi2015keyboard,
title={Keyboard acoustic side channel attacks: exploring realistic and security-sensitive scenarios},
author={Halevi, Tzipora and Saxena, Nitesh},
journal={International Journal of Information Security},
volume={14},
pages={443--456},
year={2015},
publisher={Springer}
}
@inproceedings{van2018side,
title={Side-channel based intrusion detection for industrial control systems},
author={Van Aubel, Pol and Papagiannopoulos, Kostas and Chmielewski, {\L}ukasz and Doerr, Christian},
booktitle={Critical Information Infrastructures Security: 12th International Conference, CRITIS 2017, Lucca, Italy, October 8-13, 2017, Revised Selected Papers 12},
pages={207--224},
year={2018},
organization={Springer}
}
@ARTICLE{10016748,
author={Xun, Yijie and Deng, Zhouyan and Liu, Jiajia and Zhao, Yilin},
journal={IEEE Transactions on Vehicular Technology},
title={Side Channel Analysis: A Novel Intrusion Detection System Based on Vehicle Voltage Signals},
year={2023},
volume={},
number={},
pages={1-10},
doi={10.1109/TVT.2023.3236820}}

45
PhD/research_proposal/futurwork.tex
View file

@ -1,37 +1,45 @@
\chapter{Planned Work}\label{chap:futurwork}
All the work achieved in the preliminary work serves as the foundation for the planned work.
The thesis will focus on the state detection problem.
Detecting the state of a system is a stepping stone in the construction of specialized tools.
The thesis will focus on the state detection problem under various input data and detection requirements.
Detecting the state of a system constitute a stepping stone in the construction of specialized tools for physics-based security.
As illustrated by the \gls{sds} and \gls{bpv}, the detection of specific attacks often relies on the ability to pre-process the time series to find sections of interest.
In this sense, solving the state detection problem enables a deeper investigation of power consumption by making the data actionable.
The different machines and data measurement design lead to different problems to solve and different detection capabilities.
This chapter described the planned research topics with their problem statement and a description of the motivation and expected results.
The different machines and data measurement designs lead to different problems to solve and different detection capabilities.
This chapter described the problems to study with their problem statement as well as the motivations and expected results.
The problems are discretized based on the input data and measured machines that constitute the power trace.
A single sensor only measure the power flowing through one cable.
It is possible to combine sensores to measure multiple related consumptions --- for example, the consumptions of different components in the same machine.
In this case, the problem is called \textit{multi-measure} and the resulting input data is multivariate trace.
It is also possible to place the sensor on a power cable that provide power to multiple machines.
In this case, the problem is called \textit{multi-sources} and the resulting input data is an aggregate of multiple traces.
The difference between machines and components is a fine and blury line as the description of a machine often fits individual components.
In this thesis, a component is a system that expects instructions from a central unit while a machine run its own software.
For example, at a macroscopic scale, a graphics card does not take the initiative on its own to run any software and expect instructions from the rest of the \gls{pc}.
\section{Single-Source, Single-Measure}
The \gls{dsd} shows promising results in an experimental setup.
The \gls{dsd} --- example of a Single-Source Single-Measure problem --- shows promising results in an experimental setup.
To this date, the experiments have focused on the detection of simple global states.
The global state are usualy \textit{OFF}, \textit{ON}, \textit{BOOT}, \textit{HIGH LOAD}.
Depending on the machine, other states like \textit{FIRMWARE FLASH}, \textit{SLEEP} or a specific activity mode can also be detected.
The experiments focus on the deployment of general-purpose computers, network switches, and \gls{wap}/routers.
In the next months, the goal for the \gls{dsd} is to evaluate the performances of the runtime state detection.
The current accuracy and edit distance performances (see Figure \ref{fig:dsd_acc}) show promissing results for the detection of well defined states (i.e. states associated with a striking variation of average power consumption).
However, in order for the \gls{dsd} to provide useful and reliable runtime labeling of the a machine's activity, a more diverse selection of states must be evaluated for typical machines like general purpose computers.
These results will be compiled for the publication of an article.
The work on \gls{dsd} is the base for the planned development of more specific applications of the same principle of physics-based monitoring.
The experiments focus on the deployment to general-purpose computers, network switches, and \gls{wap}/routers.
In the next months, the goal for the \gls{dsd} is to evaluate the performances of the runtime state detection in broaders and more exhaustives conexts.
The current accuracy and edit distance performances (see Figure \ref{fig:dsd_acc}) illustrate the capabilities of the \gls{dsd} for the detection of well defined states --- i.e. states associated with a striking variation of average power consumption.
However, in order to provide a useful and reliable runtime labeling of the a machine's activity, the \gls{dsd} must achieve similar results with a more diverse selection of states.
The work on \gls{dsd} is the fundation for the planned development of more specific applications of the same principle of physics-based monitoring.
\begin{figure}
\centering
\includegraphics[width=\textwidth]{images/dsd_acc}
\caption{Current results of the DSD algorithm on several datasets..}
\caption{Current results of the DSD algorithm on several datasets.}
\label{fig:dsd_acc}
\end{figure}
\section{Single-Source, Multi-Measure}
The global power consumption of a machine does not necessarily tell the full story about its activity.
In an embedded system, the power consumption can be assigned to different components, each with its specific activity.
For the simplest systems performing one specific task \agd{give examples}, the activity of each component is often consistently correlated/agd{weird sentence}.
The global power consumption of a machine does not always tell the full story about its activity.
In an embedded system, the power consumption can be attributed to different components, each with its specific activity.
For the simplest systems performing one specific task --- such as \gls{rtu} ---, the activity of each component is often correlated.
If the system is in a mode \textit{A} then each component is in mode \textit{A}, and the global power consumption will display the \textit{mode A} pattern.
For more complex systems, different components can be in different modes to accommodate the multi-tasking nature of the global activity.
In this case, if the first component is in mode \textit{A} but the second is in mode \textit{B}, this indicates a different global activity than if both are in the same mode.
@ -43,7 +51,7 @@ However, the new nature of the captured data requires an evolution of the techni
Differentiating between the different components to better understand the activity of a machine is a valuable capability associated with a new problem.
\begin{problem-statement}[Single-Source Multi-Measure]
Given a discretized time series $t$ and a set of $n$ components for each of $m$ patterns $P=\{\{\chi\},\{P_{11},\dots, P_{1n}\},\dots, \{P_{m1},\dots, P_{mn}\}\}$, identify an injective mapping $m_{SSMM}:\mathbb{N}\longrightarrow P$ such that every sample $t[i]$
Given a discretized time series $t$ and a set of $n$ components for each of $m$ patterns $P=\{\{\chi\},\{P_{11},\dots, P_{1n}\},\dots, \{P_{m1},\dots, P_{mn}\}\}$, identify an injective mapping $m_{SSMM}:\mathbb{N}\longrightarrow P$ such that every sample $t[i]$\agd{fix equation overflow}
maps to exactly one set of pattern components in $P$ with the condition that the sample matches an occurrence of the set of patterns in $t$.
\end{problem-statement}
@ -99,3 +107,6 @@ For example, an assembly line can leverage hundreds of conveyor belt drivers, ro
Each type of system is simple in its design and task.
However, adding a designated power monitoring measurement device to each individual system is costly, maintenance-heavy, and it multiplies the potential points of failure.
Capturing the power consumption of these machines at a single point is an efficient way to minimize the implementation footprint while maintaining a reliable physics-based monitoring solution.
\section{Conclusion}
\agd{to be filled}

5
PhD/research_proposal/glossaries.tex
View file

@ -28,5 +28,6 @@
\newacronym{iqr}{IQR}{Inter-Quartile Range}
\newacronym{scs}{SCS}{Safety-Critical Systems}
\newacronym{mcm}{MCM}{Machine Condition Monitoring}
\newacronym{cnn}{CNN}{Concolutional Neural Network}
\newacronym{mac}{MAC}{Media Access Control}
\newacronym{cnn}{CNN}{Convolutional Neural Network}
\newacronym{dpa}{DPA}{Differential Power Analysis}
\newacronym{ics}{ICS}{Industrial Control System}

BIN
PhD/research_proposal/images/dsd_illustration.pdf
View file

Binary file not shown.

183
PhD/research_proposal/images/dsd_illustration.svg
View file

@ -2,9 +2,9 @@
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
width="255.77675mm"
height="138.88191mm"
viewBox="0 0 255.77675 138.88192"
width="348.89758mm"
height="201.39735mm"
viewBox="0 0 348.89758 201.39736"
version="1.1"
id="svg5"
inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
@ -27,13 +27,13 @@
inkscape:deskcolor="#b5b5b5"
inkscape:document-units="mm"
showgrid="false"
inkscape:zoom="0.84096521"
inkscape:cx="416.783"
inkscape:cy="248.52396"
inkscape:zoom="0.70076027"
inkscape:cx="684.25683"
inkscape:cy="463.782"
inkscape:window-width="1920"
inkscape:window-height="1056"
inkscape:window-x="1920"
inkscape:window-y="0"
inkscape:window-height="1030"
inkscape:window-x="0"
inkscape:window-y="26"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<defs
@ -62,10 +62,10 @@
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(0,31.938722)">
transform="translate(89.3618,39.907382)">
<g
id="g1435"
transform="translate(24.074656)">
transform="translate(0,1.1174492)">
<path
style="fill:none;stroke:#000000;stroke-width:0.548541;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#TriangleStart)"
d="M 18.926336,101.3713 V 44.044769"
@ -77,7 +77,7 @@
</g>
<path
style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 44.735398,91.85577 2.420268,-0.346743 0.44444,1.210574 4.041633,-0.350173 1.883993,-0.893371 1.539284,1.252182 4.141983,-1.676255 2.420758,1.158469 3.989974,0.226561 3.559469,-30.679349 1.616024,12.123183 2.085569,-3.396141 2.5674,4.779515 1.884949,-2.71725 2.474739,1.672681 1.698466,-1.257393 0.05431,-5.346572 3.635873,-0.198027 0.56631,7.431518 3.759341,0.108748 0.567472,-2.029135 h 0.914193 c 0.002,0.01923 2.17064,1.00157 2.128171,1.063689 l 1.149033,-1.269908 2.199441,-15.607188 2.546217,0.107613 2.339242,0.918922 1.05372,1.13 1.7124,-1.304751 1.78304,2.37449 2.28202,10.558795 3.07671,-1.180266 c 0,0 1.9114,1.477473 2.3757,1.276174 0.46431,-0.2013 1.65159,-0.749754 1.65159,-0.749754 l 1.25162,6.288967 5.40989,-0.934294 c 0,0 0.63,1.969189 1.27411,1.518873 0.6441,-0.450317 3.01302,-1.820259 3.01302,-1.820259 l 3.62767,1.176137 3.34912,-1.760613 c 0,0 1.36351,2.213865 1.82426,2.213865 0.46075,0 4.65779,0.05006 5.1396,-0.107523 0.4818,-0.157582 2.37325,-1.642789 2.69541,-0.930101 0.32215,0.712687 2.58716,1.167526 2.58716,1.167526 l 1.22916,-32.49056 c 0,0 2.22926,-0.372824 2.65993,-0.214518 0.43066,0.158306 -0.20656,1.311303 1.39645,0.795573 1.60302,-0.51573 4.37802,-1.867639 4.37802,-1.867639 0,0 2.45422,1.714906 3.0556,1.714906 0.60137,0 4.18876,-0.980768 4.18876,-0.980768 l 1.17865,1.646353 0.70055,31.201908 4.01144,-1.435239 0.88831,1.377104 c 0,0 2.97435,-0.155344 3.67755,-0.155344 0.7032,0 2.28686,-1.770033 3.12316,-1.207522 0.83628,0.562511 2.40354,1.22732 2.40354,1.22732 l 4.15437,-0.366868 1.88897,-0.729687 6.63412,0.417695 2.30629,0.799181 4.24187,-0.522135 1.4025,16.762194 4.60926,-1.156199 1.53871,0.736685 c 0,0 2.32593,0.656752 3.21675,0.492254 0.89082,-0.164497 2.10681,-0.518044 2.10681,-0.518044 l 2.8663,0.946674"
d="m 24.27273,92.239135 2.420268,-0.346743 0.44444,1.210574 4.041633,-0.350173 1.883993,-0.893371 1.539284,1.252182 4.141983,-1.676255 2.420758,1.158469 3.989974,0.226561 3.559469,-30.679349 1.616024,12.123183 2.085569,-3.396141 2.5674,4.779515 1.884949,-2.71725 2.474739,1.672681 1.698466,-1.257393 0.05431,-5.346572 3.635873,-0.198027 0.56631,7.431518 3.759341,0.108748 0.567472,-2.029135 h 0.914193 c 0.002,0.01923 2.17064,1.00157 2.128171,1.063689 l 1.149033,-1.269908 2.199441,-15.607188 2.546217,0.107613 2.339242,0.918922 1.05372,1.13 1.7124,-1.304751 1.78304,2.37449 2.28202,10.558795 3.07671,-1.180266 c 0,0 1.9114,1.477473 2.3757,1.276174 0.46431,-0.2013 1.65159,-0.749754 1.65159,-0.749754 l 1.25162,6.288967 5.409888,-0.934294 c 0,0 0.63,1.969189 1.27411,1.518873 0.6441,-0.450317 3.01302,-1.820259 3.01302,-1.820259 l 3.62767,1.176137 3.34912,-1.760613 c 0,0 1.36351,2.213865 1.82426,2.213865 0.46075,0 4.65779,0.05006 5.1396,-0.107523 0.4818,-0.157582 2.37325,-1.642789 2.69541,-0.930101 0.32215,0.712687 2.58716,1.167526 2.58716,1.167526 l 1.22916,-32.49056 c 0,0 2.22926,-0.372824 2.65993,-0.214518 0.43066,0.158306 -0.20656,1.311303 1.39645,0.795573 1.60302,-0.51573 4.37802,-1.867639 4.37802,-1.867639 0,0 2.45422,1.714906 3.0556,1.714906 0.60137,0 4.18876,-0.980768 4.18876,-0.980768 l 1.17865,1.646353 0.70055,31.201908 4.01144,-1.435239 0.88831,1.377104 c 0,0 2.97435,-0.155344 3.67755,-0.155344 0.7032,0 2.28686,-1.770033 3.12316,-1.207522 0.83628,0.562511 2.40354,1.22732 2.40354,1.22732 l 4.15437,-0.366868 1.88897,-0.729687 6.63412,0.417695 2.30629,0.799181 4.24187,-0.522135 1.4025,16.762194 4.60926,-1.156199 1.53871,0.736685 c 0,0 2.32593,0.656752 3.21675,0.492254 0.89082,-0.164497 2.10681,-0.518044 2.10681,-0.518044 l 2.8663,0.946674"
id="path1374"
sodipodi:nodetypes="ccccccccccccccccccccccccccccccccscccscccsssccsscscccccsscccccccccscc" />
<path
@ -138,27 +138,174 @@
sodipodi:nodetypes="csscscc" />
<path
style="fill:none;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 44.689231,101.1869 H 65.643133"
d="M 24.757957,132.56399 H 45.711859"
id="path1527" />
<path
style="fill:none;stroke:#ff2ad4;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 66.323448,101.12668 H 115.47357"
d="M 46.392174,132.50377 H 95.542296"
id="path1529" />
<path
style="fill:none;stroke:#44aa00;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 116.25015,101.07184 h 29.24129"
d="M 96.318876,132.44893 H 125.56017"
id="path1531" />
<path
style="fill:none;stroke:#2c5aa0;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 146.03357,101.08536 h 16.62719"
d="m 126.1023,132.46245 h 16.62719"
id="path1533" />
<path
style="fill:none;stroke:#44aa00;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 163.34513,101.00343 h 34.28191"
d="m 143.41386,132.38052 h 34.28191"
id="path1535" />
<path
style="fill:none;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 198.28097,101.09516 h 15.19636"
d="m 178.3497,132.47225 h 15.19636"
id="path1537" />
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="-23.96072"
y="0.93749487"
id="text530"><tspan
sodipodi:role="line"
style="stroke-width:0.264583"
x="-23.96072"
y="0.93749487"
id="tspan1013">Example </tspan><tspan
sodipodi:role="line"
style="stroke-width:0.264583"
x="-23.96072"
y="9.6874952"
id="tspan1017">patterns</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="-29.022732"
y="76.591011"
id="text668"><tspan
sodipodi:role="line"
id="tspan666"
style="stroke-width:0.264583"
x="-29.022732"
y="76.591011">Raw trace</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="-24.962185"
y="136.94144"
id="text672"><tspan
sodipodi:role="line"
id="tspan670"
style="stroke-width:0.264583"
x="-24.962185"
y="136.94144">Detected </tspan><tspan
sodipodi:role="line"
style="stroke-width:0.264583"
x="-24.962185"
y="145.69144"
id="tspan1019">states</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="27.100143"
y="143.79657"
id="text877"><tspan
sodipodi:role="line"
id="tspan875"
style="stroke-width:0.264583"
x="27.100143"
y="143.79657">OFF</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="62.495796"
y="143.77777"
id="text881"><tspan
sodipodi:role="line"
id="tspan879"
style="stroke-width:0.264583"
x="62.495796"
y="143.77777">Boot</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="104.2215"
y="143.80511"
id="text885"><tspan
sodipodi:role="line"
id="tspan883"
style="stroke-width:0.264583"
x="104.2215"
y="143.80511">Idle</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="127.18002"
y="143.12494"
id="text889"><tspan
sodipodi:role="line"
id="tspan887"
style="stroke-width:0.264583"
x="127.18002"
y="143.12494">High</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="153.83679"
y="143.80511"
id="text893"><tspan
sodipodi:role="line"
id="tspan891"
style="stroke-width:0.264583"
x="153.83679"
y="143.80511">Idle</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="177.72427"
y="143.79657"
id="text897"><tspan
sodipodi:role="line"
id="tspan895"
style="stroke-width:0.264583"
x="177.72427"
y="143.79657">OFF</tspan></text>
<rect
style="fill:none;stroke:#000000;stroke-width:0.499999;stroke-linecap:square;stop-color:#000000"
id="rect1021"
width="292.04227"
height="149.50206"
x="-38.046333"
y="-33.365623"
ry="7.3405862" />
<rect
style="fill:none;stroke:#000000;stroke-width:0.499999;stroke-linecap:square;stop-color:#000000"
id="rect1075"
width="292.54224"
height="30.847338"
x="-38.296333"
y="123.71193"
ry="7.3405862" />
<text
xml:space="preserve"
style="font-weight:bold;font-size:11.5366px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.436054"
x="-83.383705"
y="-20.938604"
id="text1085"><tspan
sodipodi:role="line"
id="tspan1083"
style="stroke-width:0.436054"
x="-83.383705"
y="-20.938604">Inputs</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:11.5366px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.436054"
x="-87.929619"
y="136.2628"
id="text1093"><tspan
sodipodi:role="line"
id="tspan1091"
style="stroke-width:0.436054"
x="-87.929619"
y="136.2628">Output</tspan></text>
</g>
</svg>

Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 16 KiB

Before After
Before After

BIN
PhD/research_proposal/images/windows_dsd.pdf Normal file
View file

Binary file not shown.

214
PhD/research_proposal/images/windows_dsd.svg Normal file
View file

@ -0,0 +1,214 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
width="215.19312mm"
height="38.285248mm"
viewBox="0 0 215.19311 38.285248"
version="1.1"
id="svg5"
inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
sodipodi:docname="windows_dsd.svg"
inkscape:export-filename="windows_dsd.pdf"
inkscape:export-xdpi="175.618"
inkscape:export-ydpi="175.618"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
xmlns:svg="http://www.w3.org/2000/svg">
<sodipodi:namedview
id="namedview7"
pagecolor="#ffffff"
bordercolor="#000000"
borderopacity="1"
inkscape:showpageshadow="0"
inkscape:pageopacity="0"
inkscape:pagecheckerboard="0"
inkscape:deskcolor="#b5b5b5"
inkscape:document-units="mm"
showgrid="false"
inkscape:zoom="1.1893044"
inkscape:cx="295.55091"
inkscape:cy="256.45243"
inkscape:window-width="1920"
inkscape:window-height="1030"
inkscape:window-x="0"
inkscape:window-y="26"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<defs
id="defs2">
<marker
style="overflow:visible"
id="TriangleStart"
refX="0"
refY="0"
orient="auto-start-reverse"
inkscape:stockid="TriangleStart"
markerWidth="5.3244081"
markerHeight="6.155385"
viewBox="0 0 5.3244081 6.1553851"
inkscape:isstock="true"
inkscape:collect="always"
preserveAspectRatio="xMidYMid">
<path
transform="scale(0.5)"
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
d="M 5.77,0 -2.88,5 V -5 Z"
id="path135" />
</marker>
<inkscape:path-effect
effect="tiling"
id="path-effect539"
is_visible="true"
lpeversion="1"
unit="px"
seed="1;1"
lpesatellites=""
num_rows="1"
num_cols="22"
gapx="0"
gapy="0"
offset="0"
offset_type="false"
scale="0"
rotate="0"
mirrorrowsx="false"
mirrorrowsy="false"
mirrorcolsx="false"
mirrorcolsy="false"
mirrortrans="false"
shrink_interp="false"
split_items="false"
link_styles="false"
interpolate_scalex="false"
interpolate_scaley="true"
interpolate_rotatex="false"
interpolate_rotatey="true"
random_scale="false"
random_rotate="false"
random_gap_y="false"
random_gap_x="false"
transformorigin="" />
</defs>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-3.064665,2.7586116)">
<path
id="rect426"
style="fill:none;stroke:#000000;stroke-width:0.499999;stroke-linecap:square;stop-color:#000000"
d="m 10.257475,20.096319 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002726 v 9.002726 h -9.002726 z m 9.002726,0 h 9.002721 v 9.002726 h -9.002721 z m 9.002721,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00272 v 9.002726 h -9.00272 z m 9.00272,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00272 v 9.002726 h -9.00272 z m 9.00272,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00272 v 9.002726 h -9.00272 z m 9.00272,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00272 v 9.002726 h -9.00272 z m 9.00272,0 h 9.00273 v 9.002726 h -9.00273 z m 9.00273,0 h 9.00273 v 9.002726 h -9.00273 z"
inkscape:path-effect="#path-effect539"
inkscape:original-d="m 10.257475,20.096319 h 9.002726 v 9.002726 h -9.002726 z"
class="UnoptimicedTransforms" />
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="112.68334"
y="27.179548"
id="text648"><tspan
sodipodi:role="line"
id="tspan646"
style="stroke-width:0.264583"
x="112.68334"
y="27.179548">i</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 118.29019,17.534911 V 15.626173 H 55.271103 l 0.0255,1.908738"
id="path704" />
<path
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 172.17319,6.9715718 v -1.908738 h -63.01908 l 0.0255,1.908738"
id="path1260" />
<path
style="fill:none;stroke:#b3b3b3;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 127.08229,13.531878 H 64.063204"
id="path1262"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#b3b3b3;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 135.89274,12.376853 H 72.873656"
id="path1311"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#b3b3b3;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 144.93398,11.221828 H 81.914894"
id="path1313"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#b3b3b3;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 154.4267,10.066803 H 91.407614"
id="path1315"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#b3b3b3;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 163.24998,8.9117778 H 100.2309"
id="path1317"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
style="font-weight:bold;font-size:5.20864px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.196874"
x="8.0884438"
y="10.178811"
id="text1321"><tspan
sodipodi:role="line"
id="tspan1319"
style="stroke-width:0.196874"
x="8.0884438"
y="10.178811">First window</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:5.20864px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.196874"
x="184.29355"
y="13.176313"
id="text1375"><tspan
sodipodi:role="line"
id="tspan1373"
style="stroke-width:0.196874"
x="184.29355"
y="13.176313">Last window</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:2.96852px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.112203"
x="56.490971"
y="25.744217"
id="text1379"><tspan
sodipodi:role="line"
id="tspan1377"
style="stroke-width:0.112203"
x="56.490971"
y="25.744217">i-k-1</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:2.96723px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.112154"
x="163.72339"
y="25.594648"
id="text1387"><tspan
sodipodi:role="line"
id="tspan1385"
style="stroke-width:0.112154"
x="163.72339"
y="25.594648">i+k-1</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:4.91642px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.185828"
x="139.78477"
y="3.9748731"
id="text1391"><tspan
sodipodi:role="line"
id="tspan1389"
style="stroke-width:0.185828"
x="139.78477"
y="3.9748731">k</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:0.396875;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#TriangleStart)"
d="m 43.162167,11.472851 10.041802,3.951984"
id="path1393" />
<path
style="fill:none;stroke:#000000;stroke-width:0.396875;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#TriangleStart)"
d="M 184.12888,11.058192 174.08708,7.1062091"
id="path1616" />
</g>
</svg>
Side by side

After

Width:  |  Height:  |  Size: 9.1 KiB

BIN
PhD/research_proposal/images/xpsu_illustration.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 68 KiB

100
PhD/research_proposal/images/xpsu_illustration.svg
View file

@ -2,14 +2,14 @@
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
width="196.01933mm"
height="109.79893mm"
viewBox="0 0 196.01933 109.79894"
width="198.46512mm"
height="120.55564mm"
viewBox="0 0 198.46512 120.55566"
version="1.1"
id="svg5"
inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
sodipodi:docname="xpsu_illustration.svg"
inkscape:export-filename="xpsu_illustration.pdf"
inkscape:export-filename="xpsu_illustration.png"
inkscape:export-xdpi="175.618"
inkscape:export-ydpi="175.618"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
@ -27,13 +27,13 @@
inkscape:deskcolor="#b5b5b5"
inkscape:document-units="mm"
showgrid="false"
inkscape:zoom="1.1893044"
inkscape:cx="427.56085"
inkscape:cy="306.90208"
inkscape:zoom="1.4806582"
inkscape:cx="356.93584"
inkscape:cy="237.05673"
inkscape:window-width="1920"
inkscape:window-height="1056"
inkscape:window-x="1920"
inkscape:window-y="0"
inkscape:window-height="1030"
inkscape:window-x="0"
inkscape:window-y="26"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<defs
@ -79,7 +79,8 @@
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
id="layer1"
transform="translate(0,10.756712)">
<rect
style="fill:#ffffff;stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="rect426"
@ -88,7 +89,7 @@
x="67.731293"
y="7.1779485" />
<path
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 90.658141,66.810425 V 77.217293"
id="path1312"
sodipodi:nodetypes="cc" />
@ -98,7 +99,7 @@
id="path1250"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="m 133.90748,67.060425 9.07953,7.737368"
id="path1314"
sodipodi:nodetypes="cc" />
@ -108,7 +109,8 @@
width="61.330917"
height="46.977749"
x="76.837845"
y="19.832676" />
y="19.832676"
ry="0" />
<rect
style="fill:#ffffff;stroke:#000000;stroke-width:0.499999;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="rect1308"
@ -126,14 +128,14 @@
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="99.148849"
y="27.159023"
x="97.365608"
y="17.503132"
id="text1372"><tspan
sodipodi:role="line"
id="tspan1370"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';stroke-width:0.264583"
x="99.148849"
y="27.159023">PSU</tspan></text>
x="97.365608"
y="17.503132">xPSU</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
@ -168,7 +170,7 @@
x="123.69964"
y="87.053398">Motherboard</tspan></text>
<path
style="fill:none;stroke:#1a1a1a;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
style="fill:none;stroke:#1a1a1a;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 154.60019,33.653064 H 138.16876"
id="path1316"
sodipodi:nodetypes="cc" />
@ -191,46 +193,35 @@
x="151.65038"
y="36.052479">CPU</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 90.658139,66.810425 76.837845,33.653064"
id="path1536"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 133.90748,67.060424 76.837845,33.653064"
id="path1538"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
style="fill:none;stroke:#000000;stroke-width:0.529167;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
d="M 138.16876,33.653064 H 76.837843"
id="path1540" />
<circle
style="fill:none;stroke:#999999;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="path1594"
cx="116.29061"
cy="33.653065"
r="4.3233824" />
<circle
style="fill:none;stroke:#999999;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="circle1596"
cx="109.1107"
cy="52.296837"
r="4.3233824" />
<circle
style="fill:none;stroke:#999999;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
style="fill:none;stroke:#999999;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="circle1598"
cx="86.850281"
cy="58.098007"
r="4.3233824" />
cx="86.321114"
cy="56.510506"
r="2.5294065" />
<path
style="fill:none;stroke:#808080;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleStart)"
d="m 10.854704,48.268965 h 65.983139 l 7.248412,6.504619"
style="fill:none;stroke:#808080;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#TriangleStart);stroke-dasharray:none"
d="m 10.854704,48.268965 h 65.983139 l 7.606721,6.734459"
id="path1600"
sodipodi:nodetypes="ccc" />
<path
style="fill:none;stroke:#808080;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 104.78732,52.296836 76.837843,48.268965 112.47605,35.687951"
id="path1602" />
style="fill:none;stroke:#808080;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-dasharray:none"
d="M 104.82831,51.218834 76.837843,48.268965 112.17474,34.485281"
id="path1602"
sodipodi:nodetypes="ccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;fill:#808080;stroke:none;stroke-width:0.264583"
@ -242,5 +233,28 @@
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';fill:#808080;stroke:none;stroke-width:0.264583"
x="15.589134"
y="44.870735">Measurments</tspan></text>
<text
xml:space="preserve"
style="font-weight:bold;font-size:7px;line-height:1.25;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Bold';letter-spacing:0px;word-spacing:0px;stroke-width:0.264583"
x="117.55229"
y="2.8555455"
id="text1139"><tspan
sodipodi:role="line"
id="tspan1137"
style="stroke-width:0.264583"
x="117.55229"
y="2.8555455">PC</tspan></text>
<circle
style="fill:none;stroke:#999999;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="circle1348"
cx="114.30235"
cy="33.37188"
r="2.5294065" />
<circle
style="fill:none;stroke:#999999;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stop-color:#000000"
id="circle1350"
cx="107.35772"
cy="51.218834"
r="2.5294065" />
</g>
</svg>

Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

Before After
Before After

91
PhD/research_proposal/introduction.tex
View file

@ -6,70 +6,75 @@ These systems are present in many aspects of our daily life from transportation
\gls{scs} are now more and more computer-based to enable features such as remote control or lower cost maintenance.
These systems are also increasingly connected to the internet to allow for offsite monitoring or data collection.
This digitalization of \gls{scs} also brings the undesirable aspects of connected computers.
The more connection and interraction types are available to a computer system, the greater is the risk of an attack using one of these connection to be discovered.
This sum of potential attack points, called attack surface, should typically be as reduced as possible, especially for \gls{scs} that require high reliability and availability.
The more connection and interraction types are available to a computer system, the greater is the risk of an attacker using one of these connection.
This sum of potential attack points, called attack surface, should typically be as small as possible, especially for \gls{scs} that require high reliability and availability.
Increasing the capabilities and connectivity of \gls{scs} enable large scale attacks that would be infeasible before.
For example, if all the water treatment plants in Canada are equipped with a data collection mechanisme exposed to the internet for centralized analysis, then an atacker could leverage this mechanism to take over all these system and put the whole country at risk.
A wide variety range of solutions are available to protect computer systems in general.
Among them, \gls{ids} aim at detecting security policies violations or suspicious activities from or among computers.
This detection is often enabled by the collection and analysis of data related to the machine's activity.
If the ressources considered are local to the machine (e.g. CPU load, RAM data, disks read/write speed), then the detection system is called \gls{hids}.
Collection and analysis of data related to the machines activity often enable the detection.
If the \gls{ids} only consideres local ressources (e.g. CPU load, RAM data, disks read/write speed), then it is called \gls{hids}.
\gls{hids} have access to relevant local data\cn but they require to install a software on the machine (either for collection only or for local analysis).
This represent a potential flaw as the host machine may not be trusted and can be compromised, allowing the attacker to deploy stealth attacks \cite{10.1145/586110.586145}.
Moreover, an \gls{hids} can lack the broader vision required to detect intrusions distributed over a network of machines\cn.
This represent a potential flaw for multiple reasons.
First, the host machine may not be trusted and can be compromised, allowing the attacker to deploy stealth attacks \cite{10.1145/586110.586145}.
Second, an \gls{hids} can lack the broader vision required to detect intrusions distributed over a network of machines\cn.
Finally, the operation of the \gls{hids} may interfer with the critical operation of the system (for example if the \gls{hids} missbehave and block other operations).
For these reasons, \gls{hids} may be difficult to implement on a wide range of embedded systems.
The other main class of \gls{ids} aims at solving these issues.
\gls{nids} \cite{vigna1999netstat, bivens2002network} consider the communication between machines in a network to detect intrusions.
This solution does not require installing individual software on each machines and can detect network-level intrusions \cn.
However, \gls{nids} present their own concerns.
First, machine-specific attacks can remain undetected as only network information are accessible.
Then, they require the installation of dedicated equipment to collect network traffic.
Finally, modern traffic encryption practices will limit the \gls{nids} the sender-receiver pattern analysis unless traffic flows unencrypted, which can raises privacy issues.
Finally, modern traffic encryption practices will limit the \gls{nids} to sender-receiver pattern analysis unless traffic flows unencrypted, which can raises privacy issues.
It appears that the current \gls{ids} scene present a tradeoff between granularity of detection and isolation from the protected machine.
What about the case of protecting a machine against a local intrusion without the possibility to install additional software?
This use case can seem a niche one but it is a reality for many purpose-built embedded systems with minimal \gls{os}.
Systems like network switchs, \gls{rtu}, \gls{wap} rarely allow the installation of any software and yet are of critical importance.
This use case can seem niche but it represent a reality for many purpose-built embedded systems with minimal \gls{os}.
Systems like network switchs, \gls{rtu}, \gls{wap} rarely allow the installation of any software and yet perform critical tasks.
In these cases, neither local ressources usage or network information can be leveraged for local attacks detection.
Moreover, any industry that rely on \gls{scs} have strict regulations (e.g. DO-178C for aerospace systems in Canada, ISO 26262 for automotive system, ISO 16142 for medical devices) that guarantee the safety of every equipment.
In this context, modifying an existing system to add intrusion detection capabilities is expensive as it requires the re-validation of the whole system.
An external solution relying on side-channel anaylysis is easier to get certified as it does not directly interact with the \gls{scs}
Modifying an existing system to add intrusion detection capabilities is expensive as it requires the re-validation of the whole system.
%An external solution relying on side-channel anaylysis is easier to get certified as it does not directly interact with the \gls{scs}
Another under-exploited source of information for embedded systems activity are the side-channels.
A third, under-exploited, source of information for embedded systems activity are the side-channels.
The side-channels are all the physical emissions that a machine involuntarely generates.
For example, the sound of a fan, the temperature of a CPU, or the power consumption of a \gls{psu} are all common side-channels \cn.
For example, the sound of a fan, the temperature of a CPU, or the power consumption of a \gls{psu} are common side-channels \cn.
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{images/side_channel}
\caption{Main side channels from a typical embedded systems.}
\caption{Main side-channels from a typical embedded systems.}
\label{fig:side_channel}
\end{figure}
Historically, side channels have been leveraged for attacks.\agd{rewrite this to not spoil the related work section but still present the context}
Eventhough the main use of side-channel analysis is to attack a system, the core idea is to retrieve information correlated with the system's activity.
With enougth knowledge of the normal behavior of a machine, an algorithm should be able to use the side-channel signature of a machine to assess its correct behavior.
Eventhough the historical usecase of side-channel analysis is to attack a system, the core idea is to retrieve information correlated with the system's activity.
With enougth knowledge of the normal behavior of a machine, an algorithm should be able to assess its correct behavior from only side-channel information.
This idea is called physics-based security and is the core principle of this research work.
\section{Proposal Organization}
This proposal is organized as follow: Section \ref{sec:related-work} presents an overview of the related work, Chapter \ref{chap:pastwork} presents the preliminary work conducted until now, Chapter \ref{chap:futurwork} presents the main problems I want to address during my research, and finally Chapter \ref{chap:timetable} draws a proposed timeline for the completion of the planned work.
This proposal is organized as follow: Section~\ref{sec:related-work} presents an overview of the related work, Chapter~\ref{chap:pastwork} presents the preliminary work conducted until now, Chapter~\ref{chap:futurwork} presents the main problems I want to address during my research, and finally Chapter~\ref{chap:timetable} draws a proposed timeline for the completion of the planned work.
\section{Related Work}\label{sec:related-work}
The idea of side-channel based IDS traces back to the seminal work in side-channel analysis by Paul C. Kocher.
He introduced Differential Power Analysis to find secret keys used by cryptographic protocols in tamper resistant devices~\cite{kocher1999differential}.
This led to a field of research focussing on side-channel analysis that has been ever growing. Power analysis is the most common and widely studied side-channel analysis technique~\cite{brier2004correlation,mangard2008power}. %new citations%
Cagalj et al.~\cite{vcagalj2014timing} show a successful passive side-channel timing attack on U.S. patent Mod 10 method and Hopper-Blum (HB) protocol.
Quisquater et al.~\cite{quisquater2002automatic} present an approach to identify executed instructions with the use of self-organizing maps, power analysis and analysis of electromagnetic traces. %new citations%
Zhai et al.~\cite{zhai2015method} propose a self-organizing maps approach that uses features extracted from an embedded processor to detect abnormal behavior in embedded devices.
Eisenbarth et al.~\cite{eisenbarth2010building} propose a methodology for recovering the instruction flow of microcontrollers using its power consumption.
Goldack et al.~\cite{goldack2008side} propose a solution to identify individual instructions on a PIC microcontroller through mapping each instruction type to a power consumption template.
Side-channel signatures can provide information about the integrity of a system.
The idea of side-channel based analysis traces back to the seminal work by Paul C. Kocher.
He introduced \gls{dpa} to find secret keys used by cryptographic protocols in tamper resistant devices~\cite{kocher1999differential}.
This led to a field of research focussing on side-channel analysis that grew ever since.
A wide variety of side-channels have since been leveraged to recover information from a system such as power consumption \cite{brier2004correlation,mangard2008power}, electromagnetic fields~\cite{sayakkara2019survey}, acoustic emanations~\cite{7479068, alevi2015keyboard}, thermal dissipations~\cite{9727162} or, on the non-physical side, cache~\cite{page2003defending}.
Among them, power consumption is the most common and widely studied side-channel because of its numerous advantages.
Power consumption leaks information about the activity of an embedded system with a low inertia --- i.e., it can transmit high frequency information contrary to thermal ---, is easy to measure with low-cost equipment at specific points in a machine --- contrary to electromagnetic fields or sound --- and is guaranteed to be present in any system.
This combination of properties allow for a granular detection of a system activity, even at the instruction level.
Quisquater et al.~\cite{quisquater2002automatic} present an approach to identify instructions with the use of self-organizing maps, power analysis and analysis of electromagnetic traces.\agd{this citation comes out of nowhere}
Eisenbarth et al.~\cite{eisenbarth2010building} propose a methodology for recovering the instruction flow of microcontrollers using its power consumption.\agd{this citation comes out of nowhere}
Eventhough the information portential of side-channel analysis enable powerfull attacks, it also enables defensive capabilities.
Zhai et al.~\cite{zhai2015method} propose a self-organizing maps approach that uses features extracted from an embedded processor to detect abnormal behavior in embedded devices.
Different teams at Georgia Tech University leveraged power and electromagnetic backscattering \cite{8701559, jorgensen2022efficient} to detect hardware trojans and counterfeit integrated circuit.
Due to its non-intrusive and architectur-agnostic nature, power fingerprinting has a wide range of applications from energy production systems \cite{6378346}, Software Defined Radio compliance assesments \cite{5379826}.
However, the attack focussed side-channel analysis can offer non-intrusive run-time monitoring, as well. \\
\indent
Due to its non-intrusive and architectur-agnostic nature, power fingerprinting has a wide range of applications from energy production systems \cite{6378346}, Software Defined Radio compliance assesments \cite{5379826}, or applications activity on mobile devices \ref{8057232}.
Literature shows promising work in assessing integrity through cache monitoring~\cite{7163050} and power monitoring~\cite{10.1145/2976749.2978299}.
Works by Moreno et al. offer two building blocks for this work.
In~\cite{moreno2013non}, the team proposes a solution for non-intrusive debugging and program tracing using side-channel analysis.
@ -77,13 +82,19 @@ In this work, they use the power consumption of a given embedded system to ident
The team builds on their previous technique and presents a new one~\cite{Moreno2018} using the power consumption of embedded systems for non-intrusive online run-time monitoring through anomaly detection.
They use a signals and systems analysis approach to identify anomalies using the power consumption of a system and show case this by identifying buffer overflow attacks on their system.
Msgna et al.~\cite{msgna2014verifying} propose a technique for using the instruction-level power consumption of a system to verify the integrity of the software components of a system with no prior knowledge of the software code.
In~\cite{kur2009improving}, Kur et al. perform power analysis of smart cards based on the JavaCard platform helps identify vulnerable operations, obtain bytecode instruction information, and also proposes a framework to replace vulnerable operations with safe alternatives.\\
\indent
In~\cite{kur2009improving}, Kur et al. perform power analysis of smart cards based on the JavaCard platform helps identify vulnerable operations, obtain bytecode instruction information, and also proposes a framework to replace vulnerable operations with safe alternatives.\\
The non-intrusiveness and difficult-to-forge nature of side-channel information makes it ideal input for developing \gls{ids} systems.
Van Aubel et al.~\cite{van2018side} proposed using electromagnetic information to protect \gls{ics} by detecting changes in software flow.
Xun et al.~\cite{10016748} uses voltage signal of a vehicule CAN bus to detect anomalies without extensive documentation from the manufacturer.
On a different kind of embedded systems, Liang et al. propose a framework to leverage side-channel information in additive manufacturing where tradictional \gls{ids} would fail.
In more recent literature, there is a trend towards the use of \gls{ml} for side-channel analysis to enhance the security of systems.
Michele Giovanni Calvi~\cite{calvi2019runtime} offers a solution for run time monitoring of an entire cyberphysical system treated as a black box.
They collect data from a self-driving car during operations such as steering and acceleration.
Using this data, they train an Long Short Term Memory~\cite{hochreiter1997long} deep learning model and use it to verify the safety of the vehicle. %new citations%
Zhengbing et al. \cite{4488501} suggest the use of forensic techniques for profiling user behaviour to detect intrusions and propose an intelligent lightweight \gls{ids}. Hanilçi et al.~\cite{hanilci2011recognition} use recorded speech from a cell phone to ascertain the cell phone brand and model through using vector quantization and \gls{svm} models on the \gls{mfcc} of the audio.
Using this data, they train an Long Short Term Memory~\cite{hochreiter1997long} deep learning model and use it to verify the safety of the vehicle.
Zhengbing et al.~\cite{4488501} suggest the use of forensic techniques for profiling user behaviour to detect intrusions and propose an intelligent lightweight \gls{ids}.
Hanilçi et al.~\cite{hanilci2011recognition} use recorded speech from a cell phone to ascertain the cell phone brand and model through using vector quantization and \gls{svm} models on the \gls{mfcc} of the audio.
In~\cite{khan2019malware} Khan et al. propose a technique to identify malware in critical embedded and cyberphysical systems using \gls{em} side channel signals.
Their technique uses deep learning on EM emanation to model the behavior of an uncompromised system.
The system flags an activity as anomalous when the emanations differ from the normal ones used to train the neural network.
@ -95,13 +106,11 @@ Using the ML methods, they can determine the state of cellphone cameras.
A mechanical equivalent of physics-based security is \gls{mcm} that aims at monitoring the evolution of key parameters of a machine for health assessment.
This topic is not restricted to ditecting attackers activity and can inform about the health of the machine over timeto enable timely maintenance.
Different technics are deployed based on the machine type and the specific metrics of interest.
Machining equipment is often monitored with side-channel measurment such as vibration \cite{PENG2004199,4084702,HOU2021107451} sound \cite{sound_mcm}, temperature \cite{22438} or chemical analysis \cite{tavner1987condition}.
Machining equipment is often monitored with side-channel measurment such as vibration~\cite{PENG2004199,4084702,HOU2021107451} sound~\cite{sound_mcm}, temperature~\cite{22438} or chemical analysis~\cite{tavner1987condition}.
These technics focuses on mechanical machines with high reliability requirements and leverage side-channel information to reduce intrusivity.
On a larger scale, power consumption information for a whole house -- or even a whole building -- provides information about the activity of each appliance.
Monitoring, or prediction applications can leverage this information without the need for a measurment system on each endpoint.
This idea of non-intrusive load monitoring was first proposed by Hart in 1992 \cite{hart1992nonintrusive}.
The interests and challenges posed by the problem yielded different proposed solutions such as \gls{cnn} \cite{moradzadeh2021practical}, soft computing \cite{puente2020non}, or guassian models fitting on electromagnetic signatures \cite{10.1145/1864349.1864375}.
The concepts of signal disambiguation and individual consumption retrieval are transposable from a house omposed of appliances to an embedded system composed of devices.
This idea of non-intrusive load monitoring was first proposed by Hart in 1992~\cite{hart1992nonintrusive}.
The interests and challenges posed by the problem yielded different proposed solutions such as \gls{cnn}~\cite{moradzadeh2021practical}, soft computing~\cite{puente2020non}, or guassian models fitting on electromagnetic signatures~\cite{10.1145/1864349.1864375}.
The concepts of signal disambiguation and individual consumption retrieval are transposable from a house composed of appliances to an embedded system composed of devices.

233
PhD/research_proposal/pastwork.tex
View file

@ -1,80 +1,86 @@
\chapter{Exploratory Work on Physics-Based Security}\label{chap:pastwork}
The \gls{esg} has a history of power side-channel analysis.
In 2017, the \gls{eet} project started with the aim to explore the intrusion detection capabilities of side-channel analysis.
A series of exploratory work on the topic of physics-based defense followed, each ilustrating a different capability
In 2017, the \gls{eet} project started with the aim to explore the intrusion detection capabilities of side-channel analysis on a wide range of embedded systems.
A series of exploratory work on the topic of physics-based defense followed, each ilustrating a different capability.
\section{Electromechanical Emission Tripwire}
The \gls{eet} project marked the start of the physics-based security at the ESG lab.
The project aims to evaluate the capabilities of physics-based security and provide a proof-of-concept.
The project aims at evaluating the capabilities of physics-based security and provide a proof-of-concept.
The initial target was a network switch.
Network switches are a core component of any data center.
As powerful as computers can be, if they are not inter-connected, their computing power remains useless.
Communication becomes as essential as individual computing capabilities in a data center with hundreds of machines.
The failure of a network switch can have devastating consequences for data center operations.
In a data center with hundreds of machines, communication is as essential as computing power.
The failure of a network switch can have devastating consequences for the data center operations.
Every minute of downtime costs the data center and its clients a fortune and must be prevented.
\gls{hids} are often not a perfect solution for network switches.
Their \gls{os} dont support additional software installation and may not propose built-it \gls{ids} capabilities.
Their \gls{os} typically dont support additional software installation and may not propose built-in \gls{ids} capabilities.
When they do, the security solutions may be weak or rapidly out of date and fail to protect against attacks such as firmware modification~\cite{cisco_trust,thomson_2019} and bypassing secure boot-up~\cite{Cui2013WhenFM, hau_2015}.
They also fail to offer effective run-time monitoring through auditing and verifying log entries~\cite{koch2010security}.
For these reasons, network switches are prime candidates for side-channel security.
The installation of a side-channel monitoring system is often minimally invasive and can even be performed without downtime if the machine supports redundant power supplies.
The aim of the project was to leverage side-channel analysis to detect anomalous activities that can be related to attacks on a network switch.
The goal is not to create a complete \gls{ids} suite from physics-based security but to offer a complementary detection mechanism for the cases where traditional \gls{ids} are failing.
\agd{ask sebastian about examples of traditional H|N-IDS}
\subsection{Attack Scenario}
The attack surface on a network switch is large.
Network switches have large the attack surface.
Every manageable switch has a management system that enable changing the parameters of the machine.
This management is typically accessible remotly via \gls{ssh}, telnet, HTTP or locally with a serial connection.
At least one of these interface shoud be available and they are typically protected with a username/password pair -- although certificate or key authentication may be available for modern interfaces like \gls{ssh}.
On top of these intended interface, a network switch is also at risk of attacks from the connected clients.
A malicious client connected to the switch can run \gls{MAC} flooding attack or VLAN hopping attack.
A malicious client connected to the switch can run \gls{mac} flooding attack or VLAN hopping attack.
An attacker that gets physical access to the machine can also tamper with the firmware (upgrading/downgrading the firmware, uploading malicious firmware) or the hardware configuration of the machine.
We considered the following intrusions: a remote connection via \gls{ssh}, a firmware change, and a hardware change.
The remote connection via \gls{ssh} can be legitimate and does not always implies an intrusion.
The remote connection via \gls{ssh} does not always implies an intrusion.
However, this operation can be the first step of a more complex attack.
The network switch logs the connections for later forensics, but there is no mechanism to act on a remote connection on the default \gls{os}.
The network switch logs the connections for later forensics, but the \gls{os} does not typically offer mechanism to trigger actions for a remote connection.
The capability of detecting a remote connection independently of the \gls{os} is valuable in a security pipeline.
Moreover, an attacker that gains access to the machine could wipe logs to cover their tracks.
With the detection mechanism isolated from the target machine, the attacker cannot bypass the detection.
With the detection mechanism isolated from the target machine, the attacker cannot bypass the detection nor erase their tracks.
A firmware change can also be a legitimate operation.
Updating the firmware is now a common capability on many embedded systems.
However, if the firmware change was not allowed by the system administrator, then it represents a threat.
Downgrading the firmware can re-open older security flaws that have since been documented.
Upgrading the firmware without approval can cause disruptions in the machine's operation.
Loading a modified version of the firmware can also enable an attacker to forge the firmware version and remain undetected from remote security or monitoring solutions.
Finally, a hardware change is also a security threat.
The machine that we considered for the experiment \agd{cite machine model} allows for the installation of additional port modules.
The machine that we considered for the experiment --- HP Procurve Network Switch 5406zl --- allows for the installation of additional port modules.
Each module expands the port capacity of the machine.
Modules can be \textit{hot-plugged} and will apply the default configuration of the machine.
Installing a new blade on a machine with a poor default configuration allows an attacker to set up various attacks.
For example, if the default configuration does not limit the number of \gls{mac} addresses, an \gls{mac} flooding attack can be performed to access restricted traffic.
For example, if the default configuration does not limit the number of \gls{mac} addresses, a attacker can perform a \gls{mac} flooding attack to access restricted traffic.
This last scenario requires physical access to the machine.
\subsection{Host Independence}
One important aspect of the \gls{eet} technology is the independence between the host and the detection machine.
In a similar way to a \gls{nids}, the detection system is remote.
An attacker with access to the host does not have access to the detection system, which is important for the reliability of the results.
One important aspect of the \gls{eet} technology reside in the independence between the host and the detection machine.
In a similar way to a \gls{nids}, the detection system is remote and never require cooperation from the host to collect data.
This independence provide compeling features in both directions.
First, an attacker with access to the host does not have access to the detection system, which is important for the reliability of the results.
In the case of a \gls{hids}, the data are collected by a software on the host.
Whether these data are analyzed locally of sent to a remote machine makes no difference, as a compromised machine cannot be trusted to send genuine measurements.
An attacker with access to the machine can tamper with the measurement process to report nominal values and stay under the radar.
This problem is addressed by the \gls{eet} system as the power consumption of a software running on a machine cannot be faked and is difficult to hide.
Second, a failure of the detection system does not induce any perturbation of the host --- as long as the measurement system can safely fail into a passive component ---, which is crutial for critical systems.
The \gls{eet} system attempts to close the gap between host-\gls{ids} independence and access to relevant information about the machine's activities.
\subsection{Side-Channels}
Two side-channel were initially considered: electrical power consumption and ultrasound emissions.
The ultrasound emissions were quickly discarded.
Two side-channel were initially considered: power consumption and ultrasound emissions.
The ultrasound emissions were quickly discarded for multiple reasons.
When working with sound, the placement of the microphone is important and should be consistent.
This is a problem for the deployment of this technology to a variety of machines, as finding the best position of the microphone is complicated.
Moreover, the ultrasound measurements did not show the same level of detail as the power consumption.
Power consumption is a popular side-channel for many reasons:
This is a problem for the deployment of this technology to a variety of machines, as finding the best position of the microphone is difficult.
Moreover, the ultrasound measurements did not show the same level of details as the power consumption.
Power consumption is a popular side-channel for many reasons:
it is easy to capture reliably with low-cost equipment,
the placement of the capture device has little impact on the results,
adding a capture device is often easy as it can be plugged in series with the main power cable of the machine,
it provides a good level of detail about the machine's activity.
adding a capture device is often as easy as plugging it in series with the main power cable of the machine,
and provides a good level of detail about the activity.
We measured the power consumption in the form of power traces (time series of power measurements).
The capture device was a shunt resistor placed in series with the main power cable that generated a voltage drop proportional to the current (see figure \ref{fig:overview-eet1}).
We measured this voltage drop at a high frequency from 10-kilo samples per second (10KSPS) to one million samples per second (1MSPS).
@ -82,15 +88,15 @@ We measured this voltage drop at a high frequency from 10-kilo samples per secon
\begin{figure}
\centering
\includegraphics[width=0.9\textwidth]{images/overview_eet1.pdf}
\caption{Overview of the EET setup}
\caption{Overview of the EET setup.}
\label{fig:overview-eet1}
\end{figure}
\subsection{Results}
The detection of remote connection, firmware changes, and hardware changes were all successful.
The proposed method successfully detected remote connections, firmware changes, and hardware changes.
More specifically, firmware change detection showed the most promising results.
The power consumption during the boot process is more stable and less noisy than during runtime.
Thanks to this consistency, changes between two firmware versions (see Figure \ref{fig:eet1_firmware}) are easy to detect with simple methods like \gls{knn}, \gls{svm} and \gls{rfc}.
Thanks to this consistency, changes between two firmware versions (see Figure \ref{fig:eet1_firmware}) are easy to detect with simple distance-based methods like \gls{knn}, \gls{svm} and \gls{rfc}.
All these methods yield good results for the detection of abnormal firmware.
\begin{figure}
@ -102,57 +108,60 @@ All these methods yield good results for the detection of abnormal firmware.
\newpage
\section{xPSU}\label{sec:xpsu}
The xPSU project continues the exploratory work started with the \gls{eet} project.
The xPSU project continued the exploratory work started with the \gls{eet} project.
One important observation of the \gls{eet} project was that the global power consumption could be too noisy to extract all the relevant information is some cases.
One solution to this issue is to measure the power consumption at a lower level on specific components of interest.
One solution to this issue is to measure the power consumption at a lower level on specific components of interest (see Figure~\ref{fig:xpsu}).
The xPSU project aims at placing a power consumption probe and pre-processing system inside a regular \gls{pc}'s \gls{psu}.
The \gls{psu} is a prime location for monitoring power as it is responsible for generating the different power sources for the components of the \gls{pc}.
The \gls{psu} is a prime location for monitoring power as it generates the different power sources for the components of the \gls{pc}.
Integrating the measurement device in a \gls{psu} enables a \textit{drop-in} installation of the monitoring system in most \gls{pc}.
The capture mechanism consisted of a shunt resistor for generating the voltage drop, an \gls{adc} for measuring the value, and an \gls{sbc} for compiling and processing or sending the measurements.
The measurement and analysis did not require any communication with the host device to ensure independence.
The capture mechanism consisted of a shunt resistor for generating the voltage drop, an \gls{adc} for measuring the value, and an \gls{sbc} for processing the measurements.
The xPSU system measure and analyse the power consumption without any communication with the host device to ensure independence.
The xPSU was an early proof of concept, and all the components could not fit in the \gls{psu}.
The fan of the \gls{psu} was moved outside of the enclosure, and the form factor of the \gls{psu} was modified.
As a result, the xPSU was not a perfect \textit{drop-in} replacement of a regular power supply, but the final form factor was encouraging.
With a better design of the capture system and a more appropriate choice of components (the raspberry pi is too large and powerful for the task), a more compact form factor could be achieved.
The fan of the \gls{psu} was moved outside of the enclosure, modifying the form factor of the \gls{psu}.
For this reason, the xPSU was not a perfect \textit{drop-in} replacement of a regular power supply, but the final form factor was encouraging.
A more compact form factor is possible with a better design of the capture system and a more appropriate choice of components.
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/xpsu_illustration}
\caption{The xPSU focuses on a more granular measure of each components.}
\caption{The xPSU focuses on a granular measure of each components.}
\label{fig:xpsu}
\end{figure}
\subsection{Results}
We evaluated the performances of the xPSU on the task of detecting changes in hard drive firmware.
We placed the shunt resistor on the 5V cable of the Molex connector.
Although it is not an ordinary operation, it is possible to update the firmware of a hard drive.
Updates enable attackers to modify the firmware in the same way presented in the \gls{eet} project previously.
We selected drives with a pending firmware update for the experiment and measured their boot power trace before and after an update.
We also measured the trace of multiple drives of the same model and capacity to evaluate the detection of a drive replacement.
Updates enable attackers to modify the firmware an potentially implent malwares that are impossible to detect or remove without changing the drive \cite{hdd_malware}.
We selected drives with a pending firmware update for the experiment and measured their boot power trace before and after the update.
We also measured the trace of multiple drives of the same model and storage capacity to evaluate the detection of a drive replacement.
The results were satisfactory and illustrated the possibility of detecting a firmware change or a drive replacement from the boot power consumption of the drive captured from within the \gls{psu}.
The standard Molex cable supplying power the a SATA hard drive is composed of 3 voltage levels: 3V, 5V and 12V.
After some tests, it appears that the 5V cables --- grouped on the same shunt resistor --- carried the most information about the drive activity.
The shunt resistor generated the voltage drop on the 5V cables of the hard drive.
\agd{find back results and add them here}
\newpage
\section{Boot Process Verifier}\label{sec:bpv}
The good results of the \gls{eet} and xPSU projects paved the way for the development of a robust and versatile solution for verifying the boot process of a machine.
From the \gls{eet} project, we learned that modelling the expected trace (based on a number of known good boot traces) enabled the detection of anomalous firmware.
From the xPSU project, we learned that most embedded systems requiring a firmware would exhibit a firmware signature in the power consumption.
The base idea of the \gls{bpv} is to leverage a small number of known good firmware traces to build a model of normal boot power consumption.
With the model, a threshold is automatically computed to describe the acceptable range within which a new boot trace should fall to be considered normal.
If a new boot trace falls outside of the range, then it is abnormal, and an alert is raised.
The \gls{bpv} is not a tool for finding the root cause of an anomaly.
A root cause analysis can be applied later, but the \gls{bpv} is only responsible for detecting an anomaly.
From the \gls{eet} project, we learned that modelling the expected trace --- based on a number of known good traces --- enabled the detection of anomalous firmware.
From the xPSU project, we learned that most embedded systems requiring a firmware would exhibit a firmware signature in the power consumption during boot up.
The core idea of the \gls{bpv} is to leverage a small number of known good firmware traces to build a model of normal boot power consumption.
The model automatically computes a threshold to describe the acceptable range within which a new boot trace should fall to qualify as normal.
If a new boot trace falls outside of the range, the system labels it abnormal, and an alert is raised.
The \gls{bpv} is not a tool for finding the root cause of an anomaly, but only for detecting an anomaly.
The anomaly can result from malicious firmware, firmware upgrade/downgrade, or a change in firmware settings.
The \gls{eet} project also illustrated the potential of the simpler distance-based models.
A distance-based model was adopted for the \gls{bpv} to keep the maximum explainability of the model decision.
The \gls{eet} project also illustrated the potential of simple distance-based models.
A distance-based model was prefered for the \gls{bpv} to maintain the explainability of the model decision.
The \gls{bpv} is an approach to the following problem statement.
\begin{problem-statement}[Boot Process Verification]
Given a set of known-valid time series sample $S=\{s_1,\dots, s_n\}$ and a new unlabeled time series $t$, assign to $t$ the label \textit{valid} or \textit{anomalous} with the condition that the \textit{valid} label should only be assigned to new traces originating from the same distribution as the training samples from $S$.
Given a set of known-valid time series samples $S=\{s_1,\dots, s_n\}$ and a new unlabeled time series $t$, assign to $t$ the label \textit{valid} or \textit{anomalous} with the condition that the \textit{valid} label should only be assigned to new traces originating from the same distribution as the training samples from $S$.
\end{problem-statement}
The sample in $S$ and the unlabeled input $t$ are all discretized, real-valued time series of the same length.
The training samples $S$ all belong to the \textit{valid} class.
No example of the \textit{anomalous} class is accessible to the algorithm.
No example of the \textit{anomalous} class is accessible to the algorithm for building the model or choosing the threshold.
All samples in $S$ originate from the same distribution as they are different occurrences of boot sequences from the same machine with the same firmware and configuration.
The proposed solution was a distance-based detector with a threshold based on the \gls{iqr}.
@ -179,27 +188,29 @@ However, the \gls{bpv} could still detect intrusions in the computer from the gl
For example, a user modifying some settings through the \gls{bios} or booting into a different \gls{os} was detected.
This case study revealed that some systems could have multiple valid modes of the boot sequence.
This discovery enabled us to rethink the model of the \gls{bpv} to allow such variations.
The final evaluation was performed on a drone.
We performed the final evaluation on a drone.
A drone is a prime machine for the \gls{bpv} as its low complexity allows for consistent boot traces.
We successfully detected different firmware versions by leveraging the information from the two previous experiments.
Along the evaluations, the \gls{bpv} capabilities have been modified to adapt to specific cases and enable anomalous training samples, multi-model evaluations, and autonomous learning.
\agd{add results}
\newpage
\section{State Detection and Segmentation}
In Section~\ref{sec:bpv} we mentioned the use of distance metrics on boot power traces to evaluate their validity.
However, we never mentioned how these traces were detected, extracted, and synchronised.
This problem of pattern detection in a time series is more complexe than it seems and the boot sequence may not be known in advance, can take multiple form, and must still be detected if an anomalous boot radically changes the pattern.
The \gls{sds} algorithm was a first attempt at detected and extracting boot sequences for the \gls{bpv} to analyse.
The algorithm leverages two feature common to all (cold) boot sequences which are a sharp spike of power consumption and an average increase in the power consumption.
Section~\ref{sec:bpv} mentioned the use of distance models on boot power traces to evaluate their validity.
However, we never mentioned how these traces were detected, extracted, and synchronized.
This problem of pattern detection in a time series is complexe as the boot sequence may not be known in advance, can take multiple form, and the solution must detect an anomalous boot that radically changes the pattern.
The \gls{sds} algorithm was a first attempt at detecting and extracting boot sequences for the \gls{bpv} to analyse.
The algorithm leverages two feature common to all boot sequences: a sharp spike of power consumption, and an average increase in the power consumption.
Two thresholds are manually set for the detection.
The first is the \textit{off\_threshold} that is the power consumption under which the machine is considered off.
The second is the \textit{boot\_time} which represent the time span of the boot procedure.
Each sample is considered and a set of rule is applied to decide on its state among \textit{OFF}, \textit{BOOT} and \textit{ON}.
First, the \textit{off\_threshold} which is the power consumption under which the machine is considered off.
Second, the \textit{boot\_time} which represent the time span of the boot procedure.
The algorithm considers each sample iteratively to decide on the state among \textit{OFF}, \textit{BOOT} and \textit{ON}.
\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{images/sds_illustration}
\caption{SDS detection mechanism using the y offset (\textit{off\_threshold}) and the x offset (\textit{bios\_time})}
\caption{SDS detection mechanism using the $y$-offset (\textit{off\_threshold}) and the $x$-offset (\textit{bios\_time})}
\label{fig:sds_illustration}
\end{figure}
@ -243,32 +254,31 @@ Each sample is considered and a set of rule is applied to decide on its state am
\end{algorithm}
This simple algorithm makes the \gls{sds} robust and reliable but also limited.
The \gls{sds} is an appropriate solution for states that exhibit a change in average consumption and with pre-defined duration.
The detection of consistent and synchronized bootup sequences fits perfectly in this use case.
This consistency and synchrony of the instances are essential for distance-based detectors which compare these instances.
This simple algorithm makes the \gls{sds} robust and reliable, but also limited.
The \gls{sds} is an appropriate solution for detecting states that exhibit a change in average consumption and with stable pre-defined duration.
The detection of consistent and synchronized boot-up sequences fits perfectly in this use case.
This consistency and synchrony of the instances are essential for distance-based detectors that compare these instances.
However, for the states that cannot be described by a change in average consumption and duration, the \gls{sds} is incompetent.
For example, if a machine can perform two runtime operations that generate the same consumption pattern but with different frequencies, then the \gls{sds} cannot distinguish these two states reliably.
These limitations make the \gls{sds} a preliminary work, not a final solution.
It outlines that state detection is a complex problem and that the properties of the output need to be taken into account during the design.
If the desired output is only the information of the state occurrence, then the perfect consistency and synchronization of the extract are not required.
If the output is expected to be processed by a follow-up algorithm, and especially if it is distance-based, then the output needs to be much more consistent and synchronized.
If the desired output is only an information of the state occurrence, then the perfect consistency and synchronization of the detected segments are superfluous.
If a follow-up algorithm processes the output --- and especially if it is distance-based --- then the output needs to be consistent and synchronized.
These considerations reveal a tradeoff between training data and capabilities.
The \gls{sds} required no training data except for the two threshold values.
This is interesting from a deployment perspective, where machine data can be scarce.
It also impacts the detection capability as the \gls{sds} does not look for actual patterns but for single values.
This is interesting from a deployment perspective, where labeled data can be scarce.
However, it also impacts the detection capability as the \gls{sds} does not look for actual patterns but for independent thresholds crossings.
\newpage
\section{Device State Detector}
The \gls{dsd} is the continuation of the \gls{sds}.
The algorithm's goal remains the same; detect the machine's state.
However, the detection process and the outputs are fundamentally different.
The \gls{sds} was built with robustness, ease of training and consistency.
The keywords for the \gls{dsd} would be versatility and range of application.
You may already guess \agd{familiar?} that the synchronization and consistency of the output will not be the main focus of the \gls{dsd}, and they will be replaced by a greater versatility of the state detection at the cost of more training data.
The \gls{dsd} fits in a family of problems that are similar but differ by the natur of the data leveraged.
Until now, we only took into accound the case of the power consumption of a single machine (or single source) captured at a single point (single measure).
Other variation of the same problem (multi sources, multi measures, ...) will studies in the next chapter.
The \gls{sds} was built with robustness, ease of training and consistency in mind.
The synchronization and consistency of the output will not be the main focus of the \gls{dsd}, and they will be replaced by a greater versatility of the state detection at the cost of more training data.
The \gls{dsd} is an approach to a family of problems that are similar to \gls{sds}, but differ by the nature of the leverage data.
Until now, we only took into accound the case of the power consumption of a single machine --- or single source --- captured at a single point --- single measure.
Other variations of the same problem --- combinations of single/multi and single/multi measures --- will follow in the next chapter.
The \gls{dsd} algorithm is an approach to the following problem statement.
\begin{problem-statement}[Single-Source Single-Measure]
@ -288,65 +298,82 @@ The pattern $\chi$ is the unknown pattern assigned to the samples in $t$ that do
\label{fig:dsd_illustration}
\end{figure}
The core of the algorithm is the \gls{knn} classification.
This algorithm is a proven and robust way of labelling new samples based on their relative similarity to the training samples.
Although this is a good algorithm for various problems, its application to time series for pattern matching is not obvious.
For the rest of the explanation of the \gls{dsd} we will suppose that the training data consists of one time series per state.
The core of the algorithm is a \gls{knn} classification.
This algorithm is a proven and robust way of labelling new samples based on their relative similarity to the training samples (\cn ?).
Although this is a good algorithm for many classification problems, its application to time series for state detection is not trivial for multiple reasons.
First, a single time serie can contain multiple different states, making it a multi-label classification problem.
Second, extracting windows to perform classification introduces parameters --- window size, window placement around sample to classify, number of sample to classify per window, stride --- potentially difficult to tune or justify.
Finally, there is no single commonly accepted distance metric between time series of different lengths.
The \gls{dsd} addresses these design choices to perform state detection with minimal training data.
For the rest of the explanation of the \gls{dsd}, we will suppose that the training data consists of one time series per state.
These time series represent one occurrence of a state to detect.
One important detail is that each training sample can have a different length as the states are likely not all of the same duration.
The default way of applying a \gls{knn} classifier for detecting patterns in a long time series would be to iteratively consider slices of the trace corresponding to each length of the training sample.
Then the classifier would evaluate the distance of the slices to the training sample and normalize this distance by the length to generate comparable values.
The state of the closest training sample is assigned to each sample of the slice, and the next slice is considered without overlap.
The results for this method are sub-optimal.
The stride between each window is too large, and crucial patterns can be overlooked in the trace.
Moreover, the whole window will be assigned one label, which causes the edges of the states to be inaccurate.
The common way of applying a \gls{knn} classifier for detecting multiple patterns in a time series is to iteratively consider windows of the trace corresponding to each length of the training sample.
Then the classifier would evaluate the distance of each slices to the corresponding training sample and normalize this distance by the length to generate comparable values.
The state of the closest training sample is assigned to every sample of the slice, and the next slice is taken without overlap.
The results for this method are sub-optimal for two reasons.
First, if the stride between each window is too large, crucial patterns can be overlooked in the trace.
If it is too small, the detection accuracy can suffer as the state of each sample is evaluated multiple time --- due to windows overlap.
Second, the whole window will be assigned one label, which causes the edges of the states to be inaccurate --- especially when states patterns share similarities.
\agd{find a theoretical setup where the middle-sample knn is worse than dsd. Consider cases of a bootup with a description that include some OFF portion.}
The \gls{dsd} uses a better metric for evaluating the distance between a sample and each state.
For each sample and for each state, every window of the length of the state containing the sample is considered.
The first window contains the sample at the last position, and the last window contains the sample at the first position.\agd{add figure to explain that}
The first window contains the sample at the last position, and the last window contains the sample at the first position (see Figure~\ref{windows_dsd}).
\begin{figure}
\centering
\includegraphics[width=0.9\textwidth]{images/windows_dsd.pdf}
\caption{Windows considered around the sample $i$ for comparison with the pattern of size $k$.}
\label{fig:windows_dsd}
\end{figure}
The algorithm computes the distance between each window and the state and normalizes it by the length of the state.
After all the distances are computed, we can assign to the sample the state that is the closest.
This method naturally segments the state space into areas where the borders represent a mid-point between two states.\agd{figure}
This method naturally segments the state space into areas where the borders represent a mid-point between two states.
We refined the method by introducing a coefficient to shrink the capture areas of each state.
The emerging area corresponding to no state allows for the detection of unseen states.
The emerging empty area corresponding to no state allows for the detection of unseen states.
This method retains the low complexity of a distance-based \gls{knn} algorithm while yielding better accuracy, especially around state transitions.
The \gls{dsd} was designed for one-shot classification, but the multi-shot version is naturally accessible by adding more training examples and going from a 1-NN to a K-NN.
Two metrics represent the performance of the \gls{dsd} and any other algorithm for the same problem.
First, the accuracy is computed as the number of correct labels over the total number of labels to predict.
The accuracy is computed as the number of correct labels over the total number of labels to predict.
This metric is common and gives an overview of the performances comparable with a random baseline.
However, the knowledge of the specific applications that the \gls{dsd} is designed for allow for the definition of a complementary metric.
The label of each sample makes the time series actionable.
Other algorithms down the processing pipeline can evaluate the sequence of states detected for a machine in order to decide on the integrity of the machine.
The reason for labeling of each sample is to makes the time series actionable.
Other algorithms --- further down in the processing pipeline --- can evaluate the sequence of states detected for a machine in order to decide on the integrity of the machine.
In this regard, a labeling error can have different impact depending on the location.
More specifically, a single error at the transition between two states would result in a slight timing error for the state transition detection.
A single error at the transition between two states would result in a slight timing error for the state transition detection.
However, a single error in the middle of a series of identical labels would result in the detection of a new incorrect state, potentially triggering actions down the line.
These two errors have the same impact on the accuracy.
These two errors have the same impact on the accuracy but a radically different impact on .
This illustrates that the accuracy is not the complete picture.
To evaluate the state detection at a higher level, the levenshtein distance of the reduced labels is defined.
The reduced labels is the vector of labels with every sequence of identical labels represented as only one symbole.
The normalized state edit distance is defined as
\begin{equation}
nsed(truth,preds) = \dfrac{1}{max(reduced(truth),reduced(preds)}*Lev(reduced(truth),reduced(preds))
nsed(truth,preds) = \dfrac{Lev(reduced(truth),reduced(preds))}{max(reduced(truth),reduced(preds)}
\end{equation}
with $Lev$ the Levenshtein distance.
This metric is complementary to the accuracy and will be computed for every evaluation of the the state detection algorithms.
\newpage
\section{Conclusion on Past Work}
The project of physics-based security at a global level is not trivial.
The main hurdle is the extraction of information with a dual constraint of only collecting unlabeled and partial information (the power consumption) and not having any control over the machine's activity (host independance).
The project of physics-based security at a global level with complete independence from the protected machine is not trivial.
The main hurdle is the collection of information with a dual constraint.
First, the collected data is always unlabeled and often partial --- i.e.s may not contain all possible activities.
Second, the independence from the machine implies not having any control over the machine's activity to collect specific data.
However, these constraints are also the strengths of this approach.
The power consumption is a limited but reliable source of information as it is very difficult to forge.
It is up to the algorithm to extract as much information from it.
The power consumption is a limited but reliable source of information which is difficult to forge.
The challenge is for the solution to extract as much information from it.
The independence is also important as it guarantees that an attacker cannot bypass the detection mechanism.
With these constraints in mind, the current results illustrate\agd{change word} a great potential.
The \gls{bpv} and \gls{dsd} algorithm tackle the problems of boot process integrity and runtime activity monitoring.
With these constraints in mind, the results of the preliminary works are encouraging.
The \gls{bpv} and \gls{dsd} algorithm propose approaches to the problems of boot process integrity and runtime activity monitoring.
These two complementary aspects represent a large area of the attack surface of a typical embedded system.
The unique properties of host independence and unforgeability of the input data make the physics-based \gls{ids} a promising complement for any security suite.
More work is obviously required.
The main study\agd{change word} currently is to evaluate the performance of the \gls{dsd} to make it as versatile and reliable as possible.
The main point of interest is to evaluate the performance of the \gls{dsd} to make it as versatile and reliable as possible.
From the xPSU project, we understood that a more granular measurement of the power consumption could be beneficial in detecting specific attacks and enabling root cause analysis instead of basic anomaly detection.
The continuation of the research work will focus on runtime monitoring and investigate the data measurement scales and their respective benefits for a better security solution \agd{change solution, marketing term}.
The continuation of the research work will focus on runtime monitoring and investigate diferent data measurement scales and their respective benefits.

2
PhD/research_proposal/proposal.tex
View file

@ -85,6 +85,8 @@
\usepackage{algorithm}
\usepackage{algpseudocode}
\usepackage{setspace}
\doublespacing
%\usepackage{algorithmic}
% Hyperlinks make it very easy to navigate an electronic document.

8
PhD/research_proposal/timetable.tex
View file

@ -2,13 +2,13 @@
The planned work is segmented into three main parts: finishing the \gls{dsd}, building the data acquisition system and building to algorithm for the single-source multi-measure system, and setting up an experiment for the multi-source single-measure system.
Each of these three parts has its own specificities and challenges that call for careful planning.
\section{Winter 2023}
\section{Spring 2023}
The main focus for this term is the writing of the \gls{dsd} paper.
The algorithm has now reached a satisfactory state with a good range of detection and useful precision.
However, more experiments are required to evaluate the robustness and capabilities of the detector in a wider variety of situations.
The goal for this paper is the submission to a major conference in the next term.
\section{Spring 2023}
\section{Fall 2023}
This term will have a dual goal.
On one hand, finishing the \gls{dsd} paper and submitting it to a conference.
On the other, start working on the single-source multi-measure capture system.
@ -18,14 +18,14 @@ The single-source multi-measure system aims for integration in the machine with
The goal could be a computer's \gls{psu} or an external box with multiple measurement systems.
In any case, the design and prototyping of this new measurement system is an important part of the single-source multi-measure system.
\section{Fall 2023}
\section{Winter 2024}
Fall 2023 will be dedicated to designing and evaluating the single-source multi-measure system.
The challenge of this work is to enable the processing of multi-variate time series to yield better results.
The system's performances will be put in perspective with the capabilities of the DSD (single-source single-measure).
A series of experiments will also provide a complementary evaluation of the performances of these new techniques.
The experiments will be collected in a paper with a publication aimed at the next term.
\section{Winter 2024}
\section{Spring 2024}
After evaluating the single-source multi-measure system, a paper will summarize the findings and present the solution.
This term will also be dedicated to beginning the design of the multi-source single-measure system.
For this third system, the capture system is already available.