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

remove notes

Browse source
This commit is contained in:
Arthur Grisel-Davy 2023-08-01 21:24:49 -04:00
parent 63ecc43799
commit 8039145a14
1 changed files with 1 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

4
BPV/qrs/main.typ
View file

@ -317,7 +317,6 @@ The abnormal boot sequences are composed of sequences where an operator went int
== Results
The models are manually tuned to obtain 100% accuracy in the classification of nominal and abnormal boot sequences.
Obtaining 100% accuracy illustrates that there is a clear separation between nominal and abnormal boot sequences for this type of attack.
//#agd[could not redo the results as teh data for bios boot are missing]
Although this test case represents an unrealistic situation (mainly because the anomalous samples are accessible during training), it is still a valuable first evaluation of the #acr("BPV").
This test case serves as a proof-of-concept and indicates that there is a potential for the detection of firmware-level attacks with power consumption.
@ -481,7 +480,7 @@ The experiment procedure automatically captures boot-up traces for better reprod
caption: [Results of the intrusion detection on the drone.]
)<drone-results>
]
#agd[Remove results of battery module bug, they are confusing]
@drone-results presents the results of the detection.
Both Original and Compiled represent nominal firmware versions.
@ -490,7 +489,6 @@ The model correctly identifies the anomalous firmware.
One interesting scenario is the Battery Module Bug that is mostly detected as nominal.
This result is expected as the bug affects the operations of the firmware after the boot-up sequence.
Hence, the power consumption in the first second of activity remains nominal.
//#agd[Should the result of the battery module bug remain, or is it confusing to present scenarios where the BPV expectedly fails?]
It is interesting to notice that the differences in power consumption patterns among the different firmware are visible immediately after the initial power spike.
This suggests that future work could achieve an even lower time-to-decision, likely as low as 200ms depending on the anomaly.