better tables and add begining of l3 test case

BPV/qrs/main.typ

@@ -1,4 +1,5 @@
 #import "utils.typ": *
+#import "tablex.typ": tablex, hlinex, vlinex, colspanx, rowspanx
 
 #import "template.typ": *
 #show: ieee.with(
@@ -43,7 +44,8 @@
   "SCA": "Side-Channel Analysis",
   "ROM": "Read Only Memory",
   "AIM": "Anomaly-Infused Model",
-  "RFC": "Random Forest Classifier"
+  "RFC": "Random Forest Classifier",
+  "BIOS": "Basic Input/Output System"
 )
 
 #show ref: r =>{// Overload the reference definition
@@ -109,7 +111,7 @@ Our solution addresses this trade-off by leveraging side-channel information.
 == 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.
+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.
 A distance-based outlier detector that uses power traces of a nominal boot-up sequence can learn the expected pattern and detect any variation in a new boot-up sequence.
 This novel solution can detect various attacks centred around manipulating firmware.
 In addition to its versatility of detection, it is also easily retrofittable to almost any embedded system with @DC input and a consistent boot sequence.
@@ -123,8 +125,6 @@ Finally, the paper finishes with @discussion that provides more insight on speci
 
 
 = Related Work
-
-// All devices uses firmware and firmwares ar at risk of attacks
 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.
@@ -175,7 +175,6 @@ However, the current work is designed for defense and aims at obfuscating the pa
 Thus, power consumption remains a trustworthy source of information as a different set of instructions necessarily generates a different power consumption.
 
 = Threat Model<threat>
-
 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.
@@ -225,7 +224,6 @@ The number of training time series $N$ is considered small relative to the usual
 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>
-
 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$.
 If this distance is greater than the pre-computed threshold, then the @BPV classifies the new trace as anomalous.
@@ -260,7 +258,6 @@ The distance threshold takes the value $1.5 * "IQR"$. For the detection, the dis
 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 bootup sequences that are considered normal.
 There can exist various reasons for such behaviour.
 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.
@@ -275,8 +272,40 @@ If the new trace does not match any model, then it does not follow any of the no
   caption: [BPV model trained with two modes.]
 )<fig-modes>
 
-= Test Case 1: Network Devices<exp-network>
+= Test Case 0: Aggregated Power Measurements
+This test case illustrate the first application of the @BPV and follows a slightly different setup and assumptions.
+First, the power consumption measurement does not only contain the consumption of the machine to protect.
+In some cases, capturing only the power consumption of the machine to protect is impossible.
+For example, if the power connections follow proprietary designs, or if the machine to protect is innaccessible (for practical or security reasons).
+In this case, the data available is an aggregate of the machine to protect and a second machine.
+The second machine does not perform any task and its contribution to the aggregated power consumption is constant.
+Second, anomalous examples of bootup sequences are available.
+This test case was designed with an industry partner for the detection of two specific attack: bootup on an extrnal USB drive and access to the machine's @BIOS.
+Because hte machine and the expected attacks are known in advance, it is possible to tailor the @BPV's parameters for maximizing the performances at detecting the attacks.
+Because of these two specificities, this test case should be regarded as a first iteration to demonstrate the potential of the @BPV in a more restrictive environment.
+The following test cases in @exp-network and @exp-drone present other applications in more challenging environments.
 
+== Experimental Setup
+This test case was conducted on a micro-pc running Windows 10.
+The available power consumption was an aggregate of two micro-pc, one being the machine to protect.
+The second machine remained idle for the duration of the experiment.
+@l3-setup illustrate the setup for the data capture.
+
+#figure(
+  image("images/l3-setup.svg", width:100%),
+  caption: [Overview of the setup for the test case.]
+)<l3-setup>
+
+#figure(
+  image("images/l3-training.svg", width:100%),
+  caption: [Multi-Modal BPV model after training.]
+)<l3-training>
+
+
+== Results
+
+
+= Test Case 1: Network Devices<exp-network>
 To verify the performance of the proposed detector, we design an experiment that aims at detecting firmware modifications on different devices.
 Networking devices are a vital component of any organization, from individual houses to complete data centers @downtime.
 A network failure can result in significant downtime that is extremely expensive for data centers.
@@ -300,19 +329,23 @@ This @PDU's output can be controlled by sending instructions on a telnet interfa
 Each machine will undergo a firmware change or version change to represent a firmware attack.
 The changes are listed in @tab-machines.
 
+#v(10pt)
 #figure(
-  table(
+  tablex(
-    columns: (auto,auto,auto,auto),
+    columns: (25%,25%,25%,25%),
     align: horizon,
-    [*Equipment*], [*Original \ Firmware*], [*Modification 1*], [*Modification 2*],
+    auto-vlines: false,
+    repeat-header: false,
+    [*Device*], [*Original*], [*Change 1*], [*Change 2*],
     [TP-Link\ Switch], [20200805], [20200109], align(center, [X]),
     [HP Procurve\ Switch], [H.10.119], [H.10.117], align(center, [X]),
     [Asus Router], [Latest EOM], [OpenWrt\ v21.02.2], [OpenWrt\ v21.02.0],
-    [Linksys\ Router], [Latest EOM], [OpenWrt\ v21.02.2], [OpenWrt\ v21.02.0]
+    [Linksys\ Router], [Latest EOM], [OpenWrt\ v21.02.2], [OpenWrt\ v21.02.0],
   ),
-  caption: [Machines used for the experiments and their modifications.],
+  caption: [Machines used for the experiments and the changes applied.],
 )<tab-machines>
 
+
 This experiment aims at simulating an attack situation by performing firmware modifications on the target devices and recording the boot-up power trace data for each version.
 For the switches, we flash different firmware versions provided by the \gle{oem}.
 For wireless routers, their firmware is changed from the @OEM to different versions of #link("https://openwrt.org/")[OpenWrt].
@@ -344,13 +377,14 @@ The final score is the average of these $F_1$ scores.
 The results are presented in @tab-results.
 
 #figure(
-  table(
+  tablex(
     columns: 2,
+    auto-vlines: false,
     [*Machine*], [*BPV*],
-    [TP-Link switch], [0.866],
+    [TP-Link switch], [0.87],
-    [HP switch], [0.983],
+    [HP switch], [0.98],
-    [Asus router], [1],
+    [Asus router], [1.00],
-    [Linksys router], [0.921]
+    [Linksys router], [0.92]
   ),
   caption: [Results of detection.]
 )<tab-results>
@@ -369,7 +403,6 @@ A machine boot-up in two seconds will require a higher sampling rate than a mach
 All these parameters are machine-specific and need manual tuning before deployment of the side-channel @IDS.
 
 = 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 significantly in recent years @droneincrease.
 The core component of consumer-available drones is usually a microcontroller, also called a flight controller.
@@ -380,7 +413,6 @@ Moreover, flight controllers as specialized devices that usually do not support
 With drone usage soaring and the lack of security solutions, the problem of verifying their firmware against anomalies becomes important.
 
 == Experimental Setup
-
 The experimental setup for this case study is similar to the one presented in @exp-network.
 The experiment focuses on the Spiri Mu drone #footnote[#link("https://spirirobotics.com/products/spiri-mu/")] flashed with the PX4 Drone Autopilot firmware #footnote[#link("https://px4.io/")].
 The firmware for the flight controller consists of a microprocessor-specific bootloader, a second-stage bootloader common to all supported flight controllers.
@@ -408,7 +440,8 @@ The experiment procedure automatically captures boot-up traces for better reprod
 Both Original and Compiled represent nominal firmware versions.
 
 #figure(
-  table(
+  tablex(
+    auto-vlines: false,
     columns: (40%,20%,40%),
     [*Scenario*],[*Accuracy*], [*Nbr. of Samples*],
     [Original],[1],[98],
@@ -431,20 +464,6 @@ It is interesting to notice that the differences in power consumption patterns a
 This suggests that future work could achieve an even lower time-to-decision, likely as low as 200ms depending on the anomaly.
 
  
-// = Test Case 3: Aggregated Power Measurements
-// In some cases, capturing only the power consumption of the machine to protect is impossible.
-// For example, if the power connections follow proprietary designs, or if the machine to protect is innaccessible (for practical or security reasons).
-// In this case, the data available may be an aggregate of the consumption of multiple machines or components.
-// This power global power consumption measurement is still suitable for boot process verification.
-
-// This test case was conducted with an industry partner to protect a micro-pc running Windows 10.
-// The available power consumption was an aggregate of two micro-pc, one being the machine to protect.
-// The second machine remained idle for the duration of the experiment.
-// @l3-setup illustrate the setup for the data capture.
-
-// Although this setup can seem simplistic or ideal, it is a first approache to evaluating the applicability of @BPV in a more complexe environement.
-// The data presented in this test case come from a real installation, not from a controlled laboratory environment.
- 
 // #figure(
 //   image("images/l3-setup.svg", width: 100%),
 //   caption: [Setup for BPV with an aggregated power measurement.]
@@ -548,7 +567,6 @@ The results are presented in @tab-aim
 )<tab-aim>
 
 == Conclusion on the @AIM Model<aim-conclusion>
-
 The @AIM model produces mixed results.
 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.