add section in discussion, factorize capture process

BPV/qrs/bibli.bib

@@ -484,3 +484,124 @@ pages={938-946},
 doi={10.1109/TVT.2018.2884767}
 }
 
+
+@inproceedings{clark_current_2013,
+	address = {Berlin, Heidelberg},
+	series = {Lecture {Notes} in {Computer} {Science}},
+	title = {Current {Events}: {Identifying} {Webpages} by {Tapping} the {Electrical} {Outlet}},
+	isbn = {978-3-642-40203-6},
+	shorttitle = {Current {Events}},
+	doi = {10.1007/978-3-642-40203-6_39},
+	abstract = {Computers plugged into power outlets leak identifiable information by drawing variable amounts of power when performing different tasks. This work examines the extent to which this side channel leaks private information about web browsing to an observer taking measurements at the power outlet. Using direct measurements of AC power consumption with an instrumented outlet, we construct a classifier that correctly identifies unlabeled power traces of webpage activity from a set of 51 candidates with 99\% precision and 99\% recall. The classifier rejects samples of 441 pages outside the corpus with a false-positive rate of less than 2\%. It is also robust to a number of variations in webpage loading conditions, including encryption. When trained on power traces from two computers loading the same webpage, the classifier correctly labels further traces of that webpage from either computer. We identify several reasons for this consistently recognizable power consumption, including system calls, and propose countermeasures to limit the leakage of private information. Characterizing the AC power side channel may help lead to practical countermeasures that protect user privacy from an untrustworthy power infrastructure.},
+	language = {en},
+	booktitle = {Computer {Security} – {ESORICS} 2013},
+	publisher = {Springer},
+	author = {Clark, Shane S. and Mustafa, Hossen and Ransford, Benjamin and Sorber, Jacob and Fu, Kevin and Xu, Wenyuan},
+	editor = {Crampton, Jason and Jajodia, Sushil and Mayes, Keith},
+	year = {2013},
+	keywords = {Background Process, Parasitic Modulation, Power Consumption, Side Channel, Threat Model},
+	pages = {700--717},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/YCPP3Y6C/Clark et al. - 2013 - Current Events Identifying Webpages by Tapping th.pdf:application/pdf},
+}
+
+@inproceedings{10.1145-2899007.2899009,
+author = {Conti, Mauro and Nati, Michele and Rotundo, Enrico and Spolaor, Riccardo},
+title = {Mind The Plug! Laptop-User Recognition Through Power Consumption},
+year = {2016},
+isbn = {9781450342834},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/2899007.2899009},
+doi = {10.1145/2899007.2899009},
+abstract = {The Internet of Things (IoT) paradigm, in conjunction with the one of smart cities, is pursuing toward the concept of smart buildings, i.e., ``intelligent'' buildings able to receive data from a network of sensors and thus to adapt the environment. IoT sensors can monitor a wide range of environmental features such as the energy consumption inside a building at fine-grained level (e.g., for a specific wall-socket). Some smart buildings already deploy energy monitoring in order to optimize the energy use for good purposes (e.g., to save money, to reduce pollution). Unfortunately, such measurements raise a significant amount of privacy concerns.In this paper, we investigate the feasibility of recognizing the pair laptop-user (i.e., a user using her own laptop) from the energy traces produced by her laptop. We design MTPlug, a framework that achieves this goal relying on supervised machine learning techniques as pattern recognition in multivariate time series. We present a comprehensive implementation of this system and run a thorough set of experiments. In particular, we collected data by monitoring the energy consumption of two groups of laptop users, some office employees and some intruders, for a total of 27 people. We show that our system is able to build an energy profile for a laptop user with accuracy above 80%, in less than 3.5 hours of laptop usage. To the best of our knowledge, this is the first research that assesses the feasibility of laptop users profiling relying uniquely on fine-grained energy traces collected using wall-socket smart meters.},
+booktitle = {Proceedings of the 2nd ACM International Workshop on IoT Privacy, Trust, and Security},
+pages = {37–44},
+numpages = {8},
+keywords = {internet of things, energy consumption., smart meter, user identification, smart building, machine learning, intrusion detection},
+location = {Xi'an, China},
+series = {IoTPTS '16}
+}
+
+@inproceedings{michalevsky2015powerspy,
+  title={Powerspy: Location tracking using mobile device power analysis},
+  author={Michalevsky, Yan and Schulman, Aaron and Veerapandian, Gunaa Arumugam and Boneh, Dan and Nakibly, Gabi},
+  booktitle={24th $\{$USENIX$\}$ Security Symposium ($\{$USENIX$\}$ Security 15)},
+  pages={785--800},
+  year={2015}
+}
+
+  
+
+
+
+@INPROCEEDINGS{4531926,
+
+  author={Nilsson, D. K. and Larson, U. E.},
+
+  booktitle={ICC Workshops - 2008 IEEE International Conference on Communications Workshops}, 
+
+  title={Secure Firmware Updates over the Air in Intelligent Vehicles}, 
+
+  year={2008},
+
+  volume={},
+
+  number={},
+
+  pages={380-384},
+
+  doi={10.1109/ICCW.2008.78}}
+
+@INPROCEEDINGS{8726545,
+
+  author={Kolehmainen, Antti},
+
+  booktitle={2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData)}, 
+
+  title={Secure Firmware Updates for IoT: A Survey}, 
+
+  year={2018},
+
+  volume={},
+
+  number={},
+
+  pages={112-117},
+
+  doi={10.1109/Cybermatics_2018.2018.00051}}
+
+@INPROCEEDINGS{8855288,
+
+  author={Hernandez Jimenez, Jarilyn and Goseva-Popstojanova, Katerina},
+
+  booktitle={2019 2nd International Conference on Data Intelligence and Security (ICDIS)}, 
+
+  title={Malware Detection Using Power Consumption and Network Traffic Data}, 
+
+  year={2019},
+
+  volume={},
+
+  number={},
+
+  pages={53-59},
+
+  doi={10.1109/ICDIS.2019.00016}}
+
+  @inproceedings{pothukuchi2021maya,
+  title={Maya: Using formal control to obfuscate power side channels},
+  author={Pothukuchi, Raghavendra Pradyumna and Pothukuchi, Sweta Yamini and Voulgaris, Petros G and Schwing, Alexander and Torrellas, Josep},
+  booktitle={2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA)},
+  pages={888--901},
+  year={2021},
+  organization={IEEE}
+}
+
+@misc{sun2017revisiting,
+      title={Revisiting Unreasonable Effectiveness of Data in Deep Learning Era}, 
+      author={Chen Sun and Abhinav Shrivastava and Saurabh Singh and Abhinav Gupta},
+      year={2017},
+      eprint={1707.02968},
+      archivePrefix={arXiv},
+      primaryClass={cs.CV}
+}

BPV/qrs/main.typ

@@ -73,20 +73,21 @@
 }
 
 // add spaces around lists and tables
-#show enum: l =>{v(10pt)
+#show enum: l =>{v(5pt)
   l
-  v(5pt)}
+  //v(5pt)
+}
 
-#show list: l =>{v(10pt)
+#show list: l =>{v(5pt)
   l
-  v(5pt)}
+  //v(5pt)
+}
 
 #show table: t=>{v(10pt)
   t
   v(5pt)}
 
 
-#agd[Change title]
 = Introduction
 The firmware of any embedded system is susceptible to attacks. Since firmware provides many security features, it is always of major interest to attackers.
 Every year, a steady number of new vulnerabilities are discovered. Any device that requires firmware, such as computers @185175, @PLC @BASNIGHT201376, or IoT devices @rieck2016attacks, is vulnerable to these attacks.
@@ -100,9 +101,13 @@ The first and most common countermeasure is verifying the integrity of the firmw
 The methods to verify a firmware typically include but are not limited to cryptography @firmware_crypto, blockchain technology @firmware_blockchain @firmware_blockchain_2 or direct data comparison @firmware_data. Depending on the complexity, the manufacturer can provide a tag @firmware_sign of the firmware or encrypt it to provide trust that it is genuine.
 The integrity verification can also be performed at run-time as part of the firmware itself or with dedicated hardware @trustanchor.
 
-The above solutions to firmware attacks share the common flaw of being applied to the same machine they are installed on. This allows an attacker to bypass these countermeasures after infecting the machine. An attacker that could avoid triggering a verification, tamper with the verification mechanism, feed forged data to the verification mechanism, or falsify the verification report could render any defense useless. @IDS are subjected to a trade-off between having access to relevant and meaningful information and keeping the detection mechanism separated from the target machine. Our solution addresses this trade-off by leveraging side-channel information.
+The above solutions to firmware attacks share the common flaw of being applied to the same machine they are installed on.
+This allows an attacker to bypass these countermeasures after infecting the machine.
+An attacker that could avoid triggering a verification, tamper with the verification mechanism, feed forged data to the verification mechanism, or falsify the verification report could render any defense useless.
+@IDS are subjected to a trade-off between having access to relevant and meaningful information and keeping the detection mechanism separated from the target machine.
+Our solution addresses this trade-off by leveraging side-channel information.
 
-= Contributions
+== Contributions
 This paper presents a novel solution for firmware verification using side-channel analysis.
 Building on the assumption that every security mechanism operating on a host is vulnerable to being bypassed, we propose using the device's power consumption signature during the firmware execution to assess its integrity.
 Because of the intrinsic properties of side-channel information, the integrity evaluation is based on does not involve any communication with the host and is based on data difficult to forge.
@@ -112,71 +117,121 @@ In addition to its versatility of detection, it is also easily retrofittable to
 It requires minimal training examples and minor hardware modification in most cases, especially for @DC powered devices.
 
 == Paper Organization
-We elaborate on the type of attacks that our method aims to mitigate in the threat model section @threat and the technology we leverage to capture relevant information in Section @SCA.
+We elaborate on the type of attacks that our method aims to mitigate in the threat model @threat and the technology we leverage to capture relevant information in Section @SCA.
 Secion~@bpv describe the proposed solution.
 Sections~@exp-network,~@exp-drone and~@aim present test cases that illustrates applications and variations of the @BPV.
 Finally, the paper finishes with Section @discussion that provides more insight on specific aspects of the proposed solution and Section~@conclusion for the conclusion.
 
 
-= Overview
+= Related Work
-There are plenty of attack points on an ordinary machine.
-Depending on the machine's vulnerability and the attacker's skill, variable intrusion levels are possible.
-A successful firmware attack can remain undetected by common @IDS as the attacker can deceive detection methods at multiple levels.
-Moreover, firmware tampering is not necessarily a complex operation.
-#agd[this section is weird]
 
-== Threat Model<threat>
+// All devices uses firmware and firmwares ar at risk of attacks
-The range of attacks that can be performed by tampering with the boot process is extensive. Because the firmware is responsible for the initialization of the components, the low-level communications, and some in-depth security features, executing adversary code in place of the expected firmware is a powerful capability @mitre @capec. If given enough time, information or access, an attacker could take complete control of the machine and pave the way to future @APT.
+Historically, the firmware was written on a @ROM, and it was impossible to change.
+With the growing complexity of embedded systems, manufacturers developed procedures to allow remote firmware upgrades.
+Firmware upgrades can address performances or security flaws or, less frequently, add features.
+Unfortunately, attackers can leverage these firmware upgrade mechanisms to implement unauthorized or malicious pieces of software in the machine.
+Almost all embedded systems are vulnerable to firmware attacks.
+In industrial applications, studies proposed firmware attacks on control systems such as power systems field devices @power-devices, @PLC @plc_firmware, or any other industrial embedded system @santamarta2012here.
+Safety-critical environments are also prime targets, including medical devices @health_review @pacemaker @medical_case_study, railway systems @railway or automotive systems @cars.
 
-A firmware modification is defined as implementing any change in the firmware code. Modifications include implementing custom functions, removing security features, or changing the firmware for a different version (downgrade or upgrade). As long as the firmware is different from the one expected by the system administrator, we consider that it has been modified. 
+// Manufacturers try to protect firmware updates with cryptography but each solution interract with the host and cannot be trusted.
+Manufacturers have implemented different security mechanisms to prevent firmware attacks.
+The most common protection is code signing @8726545 @4531926.
+The firmware code is cryptographically signed, or a checksum is computed.
+This method suffers many possible bypasses.
+First, the firmware can be modified at the manufacturer level @BASNIGHT201376, generating a trusted signature of the modified firmware.
+Second, the verification can be bypassed @9065145.
+Finally, the result of the test can be forged to report valid firmware, even with dedicated hardware @thrangrycats.
+Blockchain technology is also considered for guaranteeing firmware integrity @blockchain1.
+Blockchain is a cryptographic chain of trust where each link is integrated into the next to guarantee that the information in the chain has not been modified.
+This technology could provide software integrity verification at each point where a supply chain attack is possible.
+However, the blockchain still needs to be verified at some point, and this verification can still be bypassed or forged.
+Overall, no security mechanism that requires interacting with the host machine can guarantee firmware integrity as the host machine can already be compromised and thus produce forged results.
 
-Downgrading the firmware to an older version is an efficient way to render a machine vulnerable to attacks. Opposite to writing custom firmware, it requires little information about the machine. All the documentation and resources are easily accessible online from the manufacturer. Even the reopened exploits are likely to be documented as they are the reason for the firmware upgrade. An attacker would only need to wait for vulnerabilities to be discovered and then revert the firmware to an older version. These properties make the firmware downgrade a powerful first step to performing future attacks. Custom firmware could need to be written for more subtle or advanced attacks. This requires more work and information as firmware codes are not open source and are challenging to reverse engineer. Moreover, the firmware is tailored for a specific machine, and it can be difficult for an attacker to test a custom firmware attack. Although, if a custom firmware can be successfully implemented, almost any attack can be performed. Finally, a firmware upgrade could also be used to open a newly discovered vulnerability.
+// SCA provides a way to verify the integrity without interacting with the host.
+Historically, attackers leveraged @SCA in general and power analysis in particular @sca_attack.
+Power consumption generally leaks execution information about the software activity that enables attacks.
+Clark et al. proposed a method to identify web page visits from @AC power @clark_current_2013.
+Conti et al. developed a method for identifying laptop-user pairs from power consumption @10.1145-2899007.2899009.
+Seemingly harmless power consumption data from a mobile phone can even leak position data @michalevsky2015powerspy.
+All these methods illustrate the potential of power side channels for attacks, but a well-intention program could also leverage them for defense purposes.
+After all, the lack of interaction required with the machine benefits the defense mechanism by increasing bypasses difficulty.
+Following this idea, Clark et al. @wud proposed in 2013 a power consumption-based malware detector for medical devices.
+Hernandez et al. included power consumption with network data for malware detection @8855288.
+Electrical power consumption is especially appropriate for infering the machine activity for different reasons.
+First, it is easy to measure in a reproducible manner.
+Then, it can be easy to get access to relevant power cables with little tampering from the machine when the power conversion from @AC to @DC power is performed outside the machine.
+It is also a common side channel to all embedded systems as they all consume electricity.
+Second, it is hard to fake from the developer's point of view. Because of the multiple abstraction layers between the code of a program and its implementation at the hardware level, changes in the code will result in a different power consumption pattern.
+This is especially true when considering firmware or machines with low computation capabilities or highly specialized devices that have deterministic and stable execution patterns at boot-up.
 
-A complete firmware change is another form of firmware manipulation. The manufacturer's firmware is replaced by another available firmware that supports the same machine. Such alternatives can be found for computers @coreboot, routers @owrt @ddwrt @freshtomato, but also video game consoles or various embedded machines.
+However, to the best of our knowledge, no work leveraged the same data or method for firmware integrity verification.
-These alternative firmware are often open-source and provide more features, capabilities and performances as they are often updated and optimized by their community. Implementing alternative firmware on a machine could allow an attacker to gain control of it without necessarily alerting the end user.
+Bootups are a natural target for defensive purposes are they are notoriously hard to protect, and host-based @IDS are not yet active in defending the machine.
+Moreover, bootup produces significantly more consistent power consumption than normal operation on general-purpose machines as it follows a pre-defined process.
 
-The last firmware manipulation is to write custom firmware for a specific machine. This is generally very hard to perform as the firmware is particular to the machine it is applied on. Writing custom firmware allows for unlimited access to the machine at the cost of a more complex attack.
+In light of the potential of side-channel attacks, some work proposed manipulating power consumption patterns.
+Defense mechanism like Maya @pothukuchi2021maya proposes to obfuscate specific activity pattern by applying a control method to target a pre-defined mask.
+If changing the power consumption pattern of software to impersonate another is possible, that could decrease the potential of side-channel-based @IDS.
+However, the current work is designed for defense and aims at obfuscating the patterns by applying masks with the goal of making all power signatures similar, not impersonating a specific one.
+Thus, power consumption remains a trustworthy source of information as a different set of instructions necessarily generates a different power consumption.
 
-== Side Channel Analysis<sca>
+= Threat Model<threat>
-@SCA leverages the emissions of a system to gain information about its operations. Side channels are defined as any involuntary emission from a system. Historically, the main side channels are sound, power consumption or electromagnetic. The common use of side-channel is in the context of attacks. The machine state is leveraged to extract critical information, allowing powerful and difficult-to-mitigate attacks. @SCA attacks are commonly applied to cryptography @cryptoreview @curveattack, keyboard typing @keyboard, printers @printer and many more. Side-channel attacks can be easy to implement depending on the chosen channel. Power consumption is a reliable source of information but requires physical access to the machine. Sound and electromagnetic fields can be measured for a distance but are also typically more susceptible to measurement location @iot_anoamly_sca.
 
-Electrical power consumption is especially appropriate for side-channel analysis for many reasons. First, it is easy to measure in a reproducible manner. Then, it can be easy to get access to relevant power cables with little tampering from the machine when the power conversion from @AC to @DC power is performed outside the machine. It is also a common side channel to all embedded systems as they all consume electricity. Finally, it is hard to fake from the developer's point of view. Because of the multiple abstraction layers between the code of a program and its implementation at the hardware level, any change in the code will likely result in a different power consumption pattern (see \ref{fig-boot-up}). This is especially true when considering firmware or machines with low computation capabilities or highly specialized devices that have deterministic and stable execution patterns at boot-up.
+Many attacks are enabled by tampering with the firmware.
+Because the firmware is responsible for the initialization of the components, the low-level communications, and some security features, executing adversary code in place of the expected firmware is a powerful capability @mitre @capec.
+If given enough time, information or access, an attacker could take complete control of the machine and pave the way to future @APT.
 
-== Related Work
+A firmware modification is defined as implementing any change in the firmware code.
-Historically, the firmware was written on a @ROM, and it was impossible to change. With the growing complexity of embedded systems, manufacturers developed procedures to allow remote firmware upgrades. Firmware upgrades can address performances or security flaws or, less frequently, add features. Unfortunately, these firmware upgrade mechanisms can also be leveraged by an attacker to implement unauthorized or malicious pieces of software in the machine. Almost all embedded systems are vulnerable to firmware attacks. In industrial applications, control systems such as power systems field devices @power-devices, @PLC @plc_firmware, or any other industrial embedded system @santamarta2012here. Safety-critical environments are also prime targets, including medical devices @health_review @pacemaker @medical_case_study, railway systems @railway or automotive systems @cars.
+Modifications include implementing custom functions, removing security features, or changing the firmware for a different version (downgrade or upgrade).
+As long as the firmware is different from the one expected by the system administrator, we consider that it has been modified.
+Downgrading the firmware to an older version is an efficient way to render a machine vulnerable to attacks.
+Opposite to writing custom firmware, it requires little information about the machine.
+All the documentation and resources are easily accessible online from the manufacturer.
+Even the exploits are likely to be documented as they are the reason for the firmware upgrade.
+An attacker would only need to wait for vulnerabilities to be discovered and then revert the firmware to an older version.
+These properties make the firmware downgrade a powerful first step to performing more elaborate attacks.
+Custom firmware may be required for more subtle or advanced attacks.
+This requires more work and information as firmware codes are usually not open source and are challenging to reverse engineer.
+Moreover, the firmware is tailored for a specific machine, and it can be difficult for an attacker to perform a custom firmware attack.
+Although, if a custom firmware can be successfully implemented, almost any attack can be performed.
+Finally, a firmware upgrade could also be used to open a newly discovered vulnerability.
 
-Different security mechanisms have been implemented by manufacturers to guarantee the integrity of the firmware. The first and most common protection is code signing. The firmware code is cryptographically signed, or a checksum is computed. This software signature is provided by the manufacturer and is checked against the signature of the installed firmware. This method suffers many possible bypasses. First, the firmware can be modified at the manufacturer level @BASNIGHT201376, generating a trusted signature of the modified firmware. Second, the verification can be bypassed @9065145. Finally, the result of the test can be forged to report a valid firmware, even with dedicated hardware @thrangrycats. Blockchain technology is also considered for guaranteeing firmware integrity @blockchain1. Blockchain is a cryptographic chain of trust where each link is integrated in the next to guarantee that the information in the chain has not been modified. This technology could provide software integrity verification at each point where a supply chain attack is possible. However, the blockchain still needs to be verified at some point, and this verification can still be bypassed or forged. A complementary approach to software verification is to leverage side-channel information produced by the machine at runtime.
+A complete firmware change is another form of firmware manipulation.
-
+The manufacturer's firmware is replaced by another available firmware that supports the same machine.
-Historically, @SCA in general and power analysis is mainly used by attackers @sca_attack. Power consumption generally leaks execution information about the running software that can be leveraged to perform various attacks. However, defense is also a promising application for this technology with runtime anomaly detection @timing or specific attack detection @DTU. Notably, Clark et al. @wud proposed in 2013 a power consumption-based malware detector for medical devices. These defense mechanisms are powerful at enabling the protection of systems that cannot host defense software. Unfortunately, common methods usually rely on a lot of training data and neural network algorithms to perform detection. These models can yield excellent performances for classifications at the cost of expensive data collection and anomalous trace examples.
+Such alternatives can be found for computers @coreboot, routers @owrt @ddwrt @freshtomato, but also video game consoles or various embedded machines.
-
+These alternative firmware are often open-source and provide more features, capabilities and performances as they are updated and optimized by their community.
-#agd[add a paragraph about forging consumption (Maya obfuscation) and data augmentation]
+Implementing alternative firmware on a machine could allow an attacker to gain control of it without necessarily alerting the end user.
 
+#agd[add a section about the capture process. Either here or in the discussion and reference it.]
+// = Side Channel Analysis<sca>
+// @SCA leverages the emissions of a system to gain information about its operations.
+// Side channels are defined as any involuntary emission from a system.
+// Historically, the main side channels are sound, power consumption or electromagnetic.
+// The common use of side-channel is in the context of attacks.
+// The machine state is leveraged to extract critical information, allowing powerful and difficult-to-mitigate attacks.
+// @SCA attacks are commonly applied to cryptography @cryptoreview @curveattack, keyboard typing @keyboard, printers @printer and many more.
+// Side-channel attacks can be easy to implement depending on the chosen channel.
+// Power consumption is a reliable source of information but requires physical access to the machine.
+// Sound and electromagnetic fields can be measured for a distance but are also typically more susceptible to measurement location @iot_anoamly_sca.
 
 = Boot Process Verification<bpv>
 Verifying the firmware of the machine using its power consumption represents a time series classification problem described in the problem statement:
 
 #ps(title: "Boot Process Verification")[
-Given a set of N time series $T=(t_1,...,t_N)$ corresponding to the power consumption of known-good bootup sequence and a new unlabeled time series $u$, predict whether $u$ was generated by a nominal boot sequence. 
+Given a set of N time series $T=(t_1,...,t_N)$ corresponding to the power consumption during nominal boot sequences and a new unlabeled time series $u$, predict whether $u$ was generated by a nominal boot sequence. 
 ]
 
 The training time series in $T$ are discretized, mono-variate, real-valued time series of length $L$.
 The length of the captured time series is a parameter of the detector, tuned for each machine.
-The number of training time series $N$ is considered small relative to the usual size of training datasets in time series classification problems #cn.
+The number of training time series $N$ is considered small relative to the usual size of training datasets in time series classification problems @sun2017revisiting.
-All time series considered in this problem ($T union u$) are all of length $L$ and synchronized at capture time; see section @sds for more details about the synchronization process.
+All time series considered in this problem ($T union u$) are all of the same length and synchronized at capture time; see Section~@sds for more details about the synchronization process.
 
 == Detection Models<detector>
 
-#figure(
-  image("images/schematic.svg", width: 90%),
-  caption: [Overview of the @BPV model training and evaluation.],  
-)<fig-overview>
-#agd["Update figure to remove anomaly generation"]
-
 The @BPV performs classification of the boot traces using a distance-based detector and a threshold.
-The core of the detection is the computation of the distance between the new trace $u$ and the training traces $T$.
+The core of the detection is the computation of the distance between the new trace $u$, and the training traces $T$.
 If this distance is greater than the pre-computed threshold, then the @BPV classifies the new trace as anomalous.
 Otherwise, the new trace is nominal.
-@fig-overview presents an overview of the model's data flow.
 
 The training phase consists in computing the threshold based on the known good training traces.
 Two main specificities of this problem make the computation of the threshold difficult.
@@ -186,15 +241,15 @@ The @BPV aims at fingerprinting the nominal sequence, not recognizing the possib
 Thus, the model can only describe the nominal traces statistically, based on the available examples, and assume that outliers to this statistical model correspond to abnormal boot sequences.
 
 Second, the number of training samples is small.
-In this case, small is relative to the usual number of training samples leveraged for time series classification #cn.
+In this case, small is relative to the usual number of training samples leveraged for time series classification (see @discussion for more details).
 We assume that the training dataset contains between ten and 100 samples.
 This assumption is important for realism.
-To keep the detector non-disruptive, the nominal boot sequences are captured during normal operation of the device.
+To keep the detector non-disruptive, the nominal boot sequences are captured during the normal operation of the device.
-However, the boot of a machine is a rare event and thus the training dataset must remain small.
+However, the bootup of a machine is a rare event, and thus the training dataset must remain small.
 
-The training sequence of the @BPV computes the distance threshold based on a statistical description of the distribution of distance between each pair of normal traces.
+The training sequence of the @BPV computes the distance threshold based on a statistical description of the distribution of the distance between each pair of normal traces.
-The training sequence folows two steps.
+The training sequence follows two steps.
-+ The sequence compute the distance between all pairs of training traces $D = {d(t_i,t_j) forall i,j in [1,...,N]^2; i eq.not j }$.
++ The sequence computes the distance between all pairs of training traces $D = {d(t_i,t_j) forall i,j in [1,...,N]^2; i eq.not j }$.
 + The sequence computes the threshold as $"thresh" = 1.5 dot "IQR"(D)$ with IQR the Inter-Quartile Range of the distances set $D$.
 
 The @IQR is a measure of the dispersion of samples.
@@ -202,24 +257,24 @@ It is based on the first and third quartiles and defined as $ "IQR" = Q_3 - Q_1$
 This value is commonly used @han2011data to detect outliers as a similar but more robust alternative to the $3"sigma"$ interval of a Gaussian distribution.
 To apply the @IQR to the times series, we compute first compute the average of the NORMAL traces.
 This average serves as a reference for computing the distance of each trace.
-The Euclidean distance is computed between each trace and the reference, and the @IQR of these distances are computed.
+The Euclidean distance is computed between each trace and the reference, and the @IQR of these distances is computed.
 The distance threshold takes the value $1.5 * "IQR"$. For the detection, the distance of each new trace to the reference is computed and compared to the threshold.
 If the distance is above the threshold, the new trace is considered anomalous.
 
 === Support For Multi-modal Boot-up Sequences
 
-Some machines can boot following multiple different boot-up sequence that are considered normal.
+Some machines can boot following multiple different bootup sequences that are considered normal.
-There can exists various reason for such behavior.
+There can exist various reasons for such behaviour.
-For example, a machine can perform recovery operations if the power can interupted while the machine was off, or perform heath check on component that may pass or fail and trigger deeper inspections procedure.
+For example, a machine can perform recovery operations if the power is interrupted while the machine is off or perform health checks on components that may pass or fail and trigger deeper inspections procedure.
-Because the machines are trated as black boxes, it is important for the @BPV to deal with these multiple modes during training.
+Because the machines are treated as black boxes, it is important for the @BPV to deal with these multiple modes during training.
-Our approach is to developp one model per mode following the same procedure as for a single mode, presented in section @detector.
+Our approach is to develop one model per mode following the same procedure as for a single mode, presented in Section~@detector.
-Then, the detection logic evolves to consider the new trace nominal if it mached any of the models.
+Then, the detection logic evolves to consider the new trace nominal if it matches any of the models.
-If the new trace does not match any model, then it does not follow any of the nominal modes and is considered anbormal.
+If the new trace does not match any model, then it does not follow any of the nominal modes and is considered abnormal.
 @fig-modes illustrate the trained @BPV models when two modes are present in the bootup sequence.
 
 #figure(
   image("images/training.svg", width:100%),
-  caption: ["BPV model trained with two modes."]
+  caption: [BPV model trained with two modes.]
 )<fig-modes>
 
 = Test Case 1: Network Devices<exp-network>
@@ -241,14 +296,8 @@ The firmware is verified only during updates with a proprietary mechanism.
 This experiment illustrates the firmware verification capability of a side-channel @IDS for these machines where common @IDS may not be applicable.
 
 == Experimental Setup<setup>
-Although this experiment is conducted in a controlled environment, the setup is representative of an real deployment.
+Although this experiment is conducted in a controlled environment, the setup to a real deployment (see @capture for more details).
-We use a hardware device referred to as the capture box @hidden placed in series with the primary power cable of the target device.
+We gather data from the four networking equipment which are connected to a managed @PDU (see @capture for more details).
-The capture box's shunt resistor generates a voltage drop representative of the global power consumption of the machine.
-This voltage drop value is recorded at a sampling rate of 10 KSPS.
-These samples are packaged in small fixed-size chunks and sent to a data aggregation server on a private @VLAN.
-The data aggregation server is responsible for gathering data from all of our capture boxes and sending it via a @VPN tunnel to a storage server as 10s time series files.
-
-We gather data from the four networking equipment which are connected to a managed @PDU.
 This @PDU's output can be controlled by sending instructions on a telnet interface and enables turning each machine on or off automatically.
 Each machine will undergo firmware change or version change to represent a firmware attack.
 The changes are listed in @tab-machines.
@@ -324,7 +373,7 @@ All these parameters are machine-specific and need manual tuning before deployme
 = Test Case 2: Drone<exp-drone>
 
 In this case study, we demonstrate the potential of physics-based @IDS for drones.
-Drones are not new but their usage both in the consumer and professional sectors increased in recent years @droneincrease.
+Drones are not new, but their usage both in the consumer and professional sectors increased significantly in recent years @droneincrease.
 The core component of consumer-available drones is usually a microcontroller, also called a flight controller.
 As with any other microcontrollers, the flight controller of a drone and its main program (we call the main program firmware in this paper) are subject to updates and attacks @8326960 @8433205.
 Some of these attacks leverage firmware manipulations @8556480.
@@ -339,13 +388,13 @@ The experiment focuses on the Spiri Mu drone #footnote[#link("https://spirirobot
 The firmware for the flight controller consists of a microprocessor-specific bootloader, a second-stage bootloader common to all supported flight controllers.
 
 The battery of the drone is disconnected to ensure reproducible results and replaced with a laboratory power supply.
-The power consumption measurement device is attached in series with the main power cable that provides an 11V @DC current to the drone.
+The power consumption measurement device (see @capture for more details) is attached in series with the main power cable that provides an 11V @DC current to the drone.
 A controllable relay is placed in series with the main cable to enable scripted bootup and shutdown scenarios.
 The experiment scenarios are:
 
-- *Nominal*: The first two versions consisted of unmodified firmware provided by the PX4 project, the first one was a pre-compiled version, and the second one was locally compiled. Although both version should be identical, some differences appeared in their consumption pattern and required the training of a dual-mode model.
+- *Nominal*: The first two versions consisted of unmodified firmware provided by the PX4 project, the first one was a pre-compiled version, and the second one was locally compiled. Although both versions should be identical, some differences appeared in their consumption pattern and required the training of a dual-mode model.
 - *Low Battery*: When the drone starts with a low battery level, its behaviour changes to signal the user of the issue. Any battery level below 11V is considered low. In this scenario, a nominal firmware is loaded, and the drone starts with 10V, triggering the low battery behaviour.
-- *Malfunctioning Firmware*: Two malfunctioning firmware versions were compiled. The first introduces a _division-by-zero_ bug in the second stage bootloader. The second introduces the same bug but in the battery management module (in the OS part of the firmware). The second scenario should not introduce measurable anomalous patterns in the boot-up sequence as it only affects the OS stage. #agd[Explain that we add this scenario for sanity check].
+- *Malfunctioning Firmware*: Two malfunctioning firmware versions were compiled. The first introduces a _division-by-zero_ bug in the second stage bootloader. The second introduces the same bug but in the battery management module (in the OS part of the firmware). The second scenario should not introduce measurable anomalous patterns in the boot-up sequence as it only affects the OS stage.
 
 #figure(
   image("images/drone-overlaps.svg", width: 100%),
@@ -355,7 +404,7 @@ The experiment scenarios are:
 == Results
 The experiment procedure consists in starting the drone flight controller multiple times while capturing the power consumption.
 The experiment consists in repeating each scenario between 40 and 100 times.
-The experiment procedure automatically captures boot-up traces for better reproductibility (see @sds for more details).
+The experiment procedure automatically captures boot-up traces for better reproducibility (see @sds for more details).
 
 @drone-results presents the results of the detection.
 Both Original and Compiled represent nominal firmware versions.
@@ -413,7 +462,7 @@ In the context of this study, it would be impractical to measure power consumpti
 Such data collection would require modifying firmware parameters, suspending equipment usage, or infecting production machines with malicious firmware.
 These modifications are impossible for production equipment and would still lead to an incomplete training dataset.
 To circumvent this limitation, we propose a variation of the training process called @AIM.
-@AIM leverages the specificity of the distance-based detectors.
+@AIM leverages the specificity of distance-based detectors.
 Distance-based detectors produce results based solely on the distance between two traces and a learned threshold.
 The threshold is chosen to separate normal and anomalous traces as well as possible.
 The actual pattern of the traces is not important for this type of detector as only the aggregated distance of each sample matters.
@@ -437,22 +486,31 @@ The goal is not the reproduce exact anomalous traces but to generate a wide vari
   ],
 )<fig-boot-up_traces_TPLINK>
 
-As illustrated in @fig-boot-up_traces_TPLINK, the domain knowledge extracted from the study of anomalous traces is of two type:
+@fig-boot-up_traces_TPLINK illustrate the domain knowledge extracted from this machine.
+The anomalies that the power trace exibit are a combination of types of transformations.
 
 - The trace is shifted along the $y$ axis. In this case, the anomalous firmware consumes significantly more or less power than the normal one. This shift can affect the whole trace or only a part of it. This can be the result of different usage of the machine's components or a significant change in the firmware instructions.
 - The trace is delayed or in advance along the $x$ axis. The anomalous trace presents the same patterns and amplitude as the normal trace but at different points in time. This shift can occur when parts of the firmware are added or removed by updates.
 
-The anomaly generation function combines the domain knowledge observations and applies anomalies to generate examples of anomalous traces from normal traces.
+The anomaly generation function combines the domain knowledge observations and applies transformations to generate examples of anomalous traces from normal traces.
-The transformations include:
+The possible transformations are:
 
-- Shifting the time domain. The direction of the shift can be forward (introducing a delay) or backward (removing a delay). The parameters of the shift are the amplitude and the start time. Both parameters are randomly selected for each new trace. The boundaries of these values do not include very large shifts as these would not contribute to the threshold placement for the models selected. The missing parts of the trace after shifting are recreated based on the average and standard deviation value of the previous 0.5s assuming a Gaussian noise.
+- Shifting the time domain. The direction of the shift can be forward (introducing a delay) or backward (removing a delay). The parameters of the shift are the amplitude and the start time. Both parameters are randomly selected for each new trace. The boundaries of these values do not include very large shifts as these would not contribute to the threshold placement for the models selected. The missing parts of the trace after shifting are recreated based on the average and standard deviation value of the previous 0.5s, assuming a Gaussian noise.
     
 - Shifting the $y$ axis. The direction of the shift can be upward (more energy consumed) or downward (less energy consumed). The amplitude is chosen between $4$ and $5$ times the standard deviation for each sample. These values ensure not creating an anomalous trace that conflicts with the normal traces and removing any shift too large that would not contribute to the threshold placement. The start time is chosen randomly in the trace.
     
 - Shifting both the $x$ and $y$ axis. Anomalous traces always presents a combination of $x$ shift, $y$ shift, or both.
 
+@fig-overview presents an overview of the model's data flow.
+
+#figure(
+  image("images/schematic.svg", width: 100%),
+  caption: [Overview of the @BPV model training and evaluation.],  
+)<fig-overview>
+
 The resulting dataset does not exactly resemble the anomalous traces that are collected but presents traces with the same range of distance to normal traces (see  @fig-Synthetic_vs_Normal_TPLINK).
-To avoid introducing traning biases, the dataset is balanced by generating new normal traces using the average and standard deviation if required.
+To avoid introducing training biases, the dataset is balanced by generating new normal traces using the average and standard deviation if required.
+
 
 #figure(
   image("images/Synthetic_vs_Normal_TPLINK.svg", width: 100%),
@@ -460,20 +518,20 @@ To avoid introducing traning biases, the dataset is balanced by generating new n
 )<fig-Synthetic_vs_Normal_TPLINK>
 
 == Results
-A benchmarking algorithm evaluate the performances of @AIM against the performances of the original @BPV trained with only normal traces.
+A benchmarking algorithm evaluates the performances of @AIM against the performances of the original @BPV trained with only normal traces.
-@AIM places the threshold to maximize the margins to the closest normal distance and abnormal distance, in the same way a 1D-@SVM would.
+@AIM places the threshold to maximize the margins to the closest normal distance and abnormal distance in the same way a 1D-@SVM would.
 This is a natural extension of the @BPV when abnormal samples are available.
 
 Two main parameters are important to tune for the @AIM.
-First, the range for the lenght of the x shift, and especially its lower bound, has an important influence on the generated anomalies.
+First, the range for the length of the x shift, and especially its lower bound, has an important influence on the generated anomalies.
-A small lower bound allow for the generation of anomalous traces that closely resemble the nominal traces, that can result in a sub-optimal threshold placement.
+A small lower bound allows for the generation of anomalous traces that closely resemble the nominal traces, which can result in a sub-optimal threshold placement.
-Second, the range parameter for the y-shift affect the results in the same way.
+Second, the range parameter for the y-shift affects the results in the same way.
-The values for these parameters are chosen as part of the domain knowledge extraction and they affect the transferability of the model (see @aim-conclusion).
+The values for these parameters are chosen as part of the domain knowledge extraction, and they affect the transferability of the model (see @aim-conclusion).
 
 The performances are evaluated on the same dataset as for the initial @BPV evaluation (see~@exp-network).
 The performance metric is the F1 score.
-The final performance measure is the average F1 score (and its standard deviation) over 30 independent run. 
+The final performance measure is the average F1 score (and its standard deviation) over 30 independent runs. 
-Each run select five random normal traces as seed for the dataset generation.
+Each run selects five random normal traces as seed for the dataset generation.
 The training dataset is composed of 100 training traces and 100 evaluation races.
 
 
@@ -494,26 +552,28 @@ The results are presented in @tab-aim
 == Conclusion on the @AIM Model<aim-conclusion>
 
 The @AIM model produces mixed results.
-The model was tuned for the the TPLINK-SWITCH machine and produces significantly better results for this machine.
+The model was tuned for the TPLINK-SWITCH machine and produced significantly better results for this machine.
 However, the results did not transfer well to the other machines.
-Experiments reveal that the values of parameters that produces the best results can differ significantly from one machine to the other, even for the same type of machines.
+Experiments reveal that the values of parameters that produce the best results can differ significantly from one machine to the other, even for the same type of machine.
 The idea of introducing artificial anomalous examples in the training dataset is valid and can indeed enable the creation of a better model.
 This artificial augmentation of the training set is especially interesting in the context of rare events where creating an extensive dataset is expensive.
-However, the lack of transferability of the proposed methods indicate that further work is required to evolve @AIM into an undeniably better solution compared to @BPV. 
+However, the lack of transferability of the proposed methods indicates that further work is required to evolve @AIM into an undeniably better solution compared to @BPV.
+
 
 = Discussion<discussion>
-#agd["Add subsection"]
+This section elaborate on some important aspects of this study.
-This study only evaluates the performance of this method on a mix of consumer and enterprise networking devices.
-The results give us great confidence that a side-channel @IDS can be deployed to other types of equipment.
-This technology is, in theory, applicable to any embedded system. Depending on the type of machine, taping the power consumption or identifying a reliable boot-up sequence can be difficult.
-Further studies will aim at illustrating the potential of side-channel firmware verification on a wider range of machines.
-There are studies to be conducted on the detection decision from the model's output in order to provide a more reliable and generic detection model by leveraging the output of multiple models focused on specific time-series features.
 
-== Hyper Parameters
+== Capture Process<capture>
-#agd[already discussed in the first experiment, watch out for double infos]
+We use a hardware device referred to as the capture box @hidden placed in series with the primary power cable of the target device.
+The technology for measuring the current differ depending on the capture box's version.
+For test case 1 and 3, the box's shunt resistor generates a voltage drop representative of the global power consumption of the machine.
+For test case 2, a Hall effect sensor return a voltage proportional to the current.
+For both versions, the voltage value is sampled at 10 KSPS.
+These samples are packaged in small fixed-size chunks and sent to a data aggregation server on a private @VLAN.
+The data aggregation server is responsible for gathering data from all of our capture boxes and sending it via a @VPN tunnel to a storage server.
+Each file on the server contains 10s of power consumption data.
 
 == Extraction of Synchronized Bootup Traces<sds>
-
 A threshold-based algorithm extracts the boot-up sequences from the complete trace.
 The extraction is not performed manually because of the large number of samples and to ensure a consistent detection of the boot-up pattern and a precise alignment of the different sequences extracted.
 Because the boot-up sequence usually begins with a sharp increase in power consumption from the device, the algorithm leverages this rising edge to detect the start time accurately.
@@ -521,7 +581,7 @@ Two parameters control the extraction.
 $T$ is the consumption threshold, and $L$ is the length of the boot-up sequence.
 To extract all the boot-up sequences in a power trace, the algorithm evaluates consecutive samples against $T$.
 If sample $s_{i-1}<T$ and $s_i>T$, then $s_i$ is the first sample of a boot-up sequence, and the next $L$ samples are extracted.
-The power trace is resampled at $50"ms"$ using a median aggregating function to avoid any incorrect detections.
+The power trace is resampled at 50ms using a median aggregating function to avoid any incorrect detections.
 This pre-processing removes most of the impulse noise that could falsely trigger the detection method.
 The final step of the detection is to store all the boot sequences under the same label for evaluation.
 The complete dataset corresponding to this experiment is available online @dataset.
@@ -533,8 +593,8 @@ Each bootup event is extracted and added to a dataset of bootup traces.
 Once the dataset reaches the expected number of samples, the @BPV computes the threshold and is ready for validation of the next bootup.
 The complete training and validation procedures require no human interractions.
 
-In the case of a multi-modal model, the training procedure require one human interraction.
+In the case of a multi-modal models, the training procedure require one human interraction.
-Presented with the bootup samples, an operator can define transform the model into a multi-modal model by separating the training samples into multiple modes.
+Presented with the bootup samples, an operator can transform the model into a multi-modal model by separating the training samples into multiple modes.
 Once the separation is performed, the training procedure resumes without interraction and the next bootup samples are assigned to the closest mode.
 
 Thanks to its low-complexity and support for multi-modes, the @BPV can adapt during training to changes in the training data and supports switching between single and multi-modes.

BPV/qrs/template.typ

@@ -163,4 +163,3 @@
     bibliography(bibliography-file, title: text(10pt)[References], style: "ieee")
   }
 }
-