diff --git a/BPV/qrs/bibli.bib b/BPV/qrs/bibli.bib new file mode 100644 index 0000000..5c81f11 --- /dev/null +++ b/BPV/qrs/bibli.bib @@ -0,0 +1,488 @@ +@online{cve-firmware, + author = {mitre.org}, + title = {cve.mitre.org}, + year = 2021, + url = {https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Firmware}, + urldate = {2021-12-7} +} + +@article{BASNIGHT201376, +title = {Firmware modification attacks on programmable logic controllers}, +journal = {International Journal of Critical Infrastructure Protection}, +volume = {6}, +number = {2}, +pages = {76-84}, +year = {2013}, +issn = {1874-5482}, +doi = {https://doi.org/10.1016/j.ijcip.2013.04.004}, +url = {https://www.sciencedirect.com/science/article/pii/S1874548213000231}, +author = {Zachry Basnight and Jonathan Butts and Juan Lopez and Thomas Dube}, +} + +@misc{rieck2016attacks, + title={Attacks on Fitness Trackers Revisited: A Case-Study of Unfit Firmware Security}, + author={Jakob Rieck}, + year={2016}, + eprint={1604.03313}, + archivePrefix={arXiv}, + primaryClass={cs.CR} +} + +@inproceedings {185175, +author = {Jacob Maskiewicz and Benjamin Ellis and James Mouradian and Hovav Shacham}, +title = {Mouse Trap: Exploiting Firmware Updates in {USB} Peripherals}, +booktitle = {8th {USENIX} Workshop on Offensive Technologies ({WOOT} 14)}, +year = {2014}, +address = {San Diego, CA}, +url = {https://www.usenix.org/conference/woot14/workshop-program/presentation/maskiewicz}, +publisher = {{USENIX} Association}, +month = aug, +} + +@online{usb_killer, + author = {Dark Purple }, + title = {USB Killer}, + year = 2021, + url = {https://kukuruku.co/post/usb-killer/}, + urldate = {2021-12-18} +} + +@online{lan_turtle, + author = {Hack5}, + title = {LAN Turtle}, + year = 2021, + url = {https://hak5.org/collections/sale/products/lan-turtle}, + urldate = {2021-12-18} +} + +@online{rubber_ducky, + author = {Hack5}, + title = {Rubber Ducky}, + year = 2021, + url = {https://hak5.org/collections/sale/products/usb-rubber-ducky-deluxe}, + urldate = {2021-12-18} +} + +@online{key_croc, + author = {Hack5}, + title = {Key Coc}, + year = 2021, + url = {https://hak5.org/collections/sale/products/key-croc}, + urldate = {2021-12-18} +} + +@online{minio, + author = {MinIO}, + title = {MinIO}, + year = 2021, + url = {https://min.io/}, + urldate = {2021-12-18} +} + +@INPROCEEDINGS{firmware_blockchain, + author={Lim, Jea-Min and Kim, Youngpil and Yoo, Chuck}, + 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={Chain Veri: Blockchain-Based Firmware Verification System for IoT Environment}, + year={2018}, + volume={}, + number={}, + pages={1050-1056}, + doi={10.1109/Cybermatics_2018.2018.00194}} + + @InProceedings{firmware_blockchain_2, +author="Lee, Boohyung +and Malik, Sehrish +and Wi, Sarang +and Lee, Jong-Hyouk", +editor="Lee, Jong-Hyouk +and Pack, Sangheon", +title="Firmware Verification of Embedded Devices Based on a Blockchain", +booktitle="Quality, Reliability, Security and Robustness in Heterogeneous Networks", +year="2017", +publisher="Springer International Publishing", +address="Cham", +pages="52--61", +isbn="978-3-319-60717-7" +} + +@InProceedings{firmware_data, +author="McMinn, Lucille +and Butts, Jonathan", +editor="Butts, Jonathan +and Shenoi, Sujeet", +title="A Firmware Verification Tool for Programmable Logic Controllers", +booktitle="Critical Infrastructure Protection VI", +year="2012", +publisher="Springer Berlin Heidelberg", +address="Berlin, Heidelberg", +pages="59--69", +isbn="978-3-642-35764-0" +} + +@INPROCEEDINGS{firmware_crypto, + author={Nilsson, Dennis K. and Sun, Lei and Nakajima, Tatsuo}, + booktitle={2008 IEEE Globecom Workshops}, + title={A Framework for Self-Verification of Firmware Updates over the Air in Vehicle ECUs}, + year={2008}, + volume={}, + number={}, + pages={1-5}, + doi={10.1109/GLOCOMW.2008.ECP.56}} + +@InProceedings{firmware_sign, +author="Jeong, Eunseon +and Park, Junyoung +and Son, Byeonggeun +and Kim, Myoungsu +and Yim, Kangbin", +editor="Barolli, Leonard +and Xhafa, Fatos +and Javaid, Nadeem +and Enokido, Tomoya", +title="Study on Signature Verification Process for the Firmware of an Android Platform", +booktitle="Innovative Mobile and Internet Services in Ubiquitous Computing", +year="2019", +publisher="Springer International Publishing", +address="Cham", +pages="540--545", +isbn="978-3-319-93554-6" +} + +@misc{mitre, + title = {MITRE ATT&CK® T1542.001 Pre-OS Boot: System Firmware}, + howpublished = {\url{https://attack.mitre.org/versions/v10/techniques/T1542/001/}}, + note = {Accessed: 2022-03-31} +} + +@misc{capec, + title = {CAPEC-532: Altered Installed BIOS}, + howpublished = {\url{https://capec.mitre.org/data/definitions/532.html}}, + note = {Accessed: 2022-03-31} +} + +@misc{coreboot, + title = {Coreboot. Fast, secure and flexible OpenSource firmware}, + howpublished = {\url{https://www.coreboot.org/}}, + note = {Accessed: 2022-03-31} +} + +@misc{owrt, + title = {OpenWrt}, + howpublished = {\url{https://openwrt.org/}}, + note = {Accessed: 2022-03-31} +} + +@misc{ddwrt, + title = {DD-WRT}, + howpublished = {\url{https://dd-wrt.com/}}, + note = {Accessed: 2022-03-31} +} + +@misc{freshtomato, + title = {FreshTomato}, + howpublished = {\url{https://www.freshtomato.org/}}, + note = {Accessed: 2022-03-31} +} + +@misc{trustanchor, + title = {Cisco's Trustworthy Technology Datasheet}, + howpublished = {\url{https://www.cisco.com/c/dam/en_us/about/doing_business/trust-center/docs/trustworthy-technologies-datasheet.pdf}}, + note = {Accessed: 2022-04-06} +} + +@misc{downtime, + title = {How to Calculate Data Center Downtime}, + howpublished = {\url{https://datacenterfrontier.com/how-calculate-data-center-downtime/}}, + note = {Accessed: 2022-04-06} +} + + +@misc{cryptoreview, + author = {YongBin Zhou and + DengGuo Feng}, + title = {Side-Channel Attacks: Ten Years After Its Publication and the Impacts on Cryptographic Module Security Testing}, + howpublished = {Cryptology ePrint Archive, Report 2005/388}, + year = {2005}, + note = {\url{https://ia.cr/2005/388}}, +} + +@misc{curveattack, + author = {Roberto M. Avanzi}, + title = {Side Channel Attacks on Implementations of Curve-Based Cryptographic Primitives}, + howpublished = {Cryptology ePrint Archive, Report 2005/017}, + year = {2005}, + note = {\url{https://ia.cr/2005/017}}, +} + +@InProceedings{keyboard, +author="Anand, S. Abhishek +and Saxena, Nitesh", +editor="Grossklags, Jens +and Preneel, Bart", +title="A Sound for a Sound: Mitigating Acoustic Side Channel Attacks on Password Keystrokes with Active Sounds", +booktitle="Financial Cryptography and Data Security", +year="2017", +publisher="Springer Berlin Heidelberg", +address="Berlin, Heidelberg", +pages="346--364", +} + +@INPROCEEDINGS{printer, + + author={Al Faruque, Mohammad Abdullah and Chhetri, Sujit Rokka and Canedo, Arquimedes and Wan, Jiang}, + + booktitle={2016 ACM/IEEE 7th International Conference on Cyber-Physical Systems (ICCPS)}, + + title={Acoustic Side-Channel Attacks on Additive Manufacturing Systems}, + + year={2016}, + + volume={}, + + number={}, + + pages={1-10}, + + doi={10.1109/ICCPS.2016.7479068}} + +@inproceedings{iot_anoamly_sca, +author = {Devin Spatz and Devin Smarra and Igor Ternovskiy}, +title = {{A review of anomaly detection techniques leveraging side-channel emissions}}, +volume = {11011}, +booktitle = {Cyber Sensing 2019}, +editor = {Igor V. Ternovskiy and Peter Chin}, +organization = {International Society for Optics and Photonics}, +publisher = {SPIE}, +pages = {48 -- 55}, +keywords = {Rf emission, loT, Cyber security}, +year = {2019}, +doi = {10.1117/12.2521450}, +URL = {https://doi.org/10.1117/12.2521450} +} + +@INPROCEEDINGS{power-devices, + + author={Konstantinou, Charalambos and Maniatakos, Michail}, + + booktitle={2015 IEEE International Conference on Smart Grid Communications (SmartGridComm)}, + + title={Impact of firmware modification attacks on power systems field devices}, + + year={2015}, + + volume={}, + + number={}, + + pages={283-288}, + + doi={10.1109/SmartGridComm.2015.7436314}} + +@article{plc_firmware, +title = {Firmware modification attacks on programmable logic controllers}, +journal = {International Journal of Critical Infrastructure Protection}, +volume = {6}, +number = {2}, +pages = {76-84}, +year = {2013}, +issn = {1874-5482}, +doi = {https://doi.org/10.1016/j.ijcip.2013.04.004}, +url = {https://www.sciencedirect.com/science/article/pii/S1874548213000231}, +author = {Zachry Basnight and Jonathan Butts and Juan Lopez and Thomas Dube}, +keywords = {Industrial control systems, Programmable logic controllers, Firmware, Modification attacks, Reverse engineering}, +} + +@article{santamarta2012here, + title={Here be backdoors: A journey into the secrets of industrial firmware}, + author={Santamarta, Ruben}, + journal={Black Hat USA}, + year={2012} +} + +@ARTICLE{health_review, author={Yaqoob, Tahreem and Abbas, Haider and Atiquzzaman, Mohammed}, journal={IEEE Communications Surveys Tutorials}, title={Security Vulnerabilities, Attacks, Countermeasures, and Regulations of Networked Medical Devices—A Review}, year={2019}, volume={21}, number={4}, pages={3723-3768}, doi={10.1109/COMST.2019.2914094}} + + + + + + +@article{pacemaker, +author = {Adrian Baranchuk and Bryce Alexander and Debra Campbell and Sohaib Haseeb and Damian Redfearn and Chris Simpson and Ben Glover }, +title = {Pacemaker Cybersecurity}, +journal = {Circulation}, +volume = {138}, +number = {12}, +pages = {1272-1273}, +year = {2018}, +doi = {10.1161/CIRCULATIONAHA.118.035261}, +URL = {https://www.ahajournals.org/doi/abs/10.1161/CIRCULATIONAHA.118.035261}, +eprint = {https://www.ahajournals.org/doi/pdf/10.1161/CIRCULATIONAHA.118.035261} +} + +@article{medical_case_study, +author = {Ang Cui, Michael Costello and Salvatore J. Stolfo}, +title = {When Firmware Modifications Attack: A Case Study of Embedded Exploitation}, +journal = {20th Annual Network & Distributed System Security Symposium 2013}, +year = {2013}, +} + +@InProceedings{railway, +author="B{\"a}ckman, Ronny +and Oliver, Ian +and Limonta, Gabriela", +editor="Casimiro, Ant{\'o}nio +and Ortmeier, Frank +and Schoitsch, Erwin +and Bitsch, Friedemann +and Ferreira, Pedro", +title="Integrity Checking of Railway Interlocking Firmware", +booktitle="Computer Safety, Reliability, and Security. SAFECOMP 2020 Workshops",year="2020", +publisher="Springer International Publishing", +address="Cham", +pages="161--175",} + + +@INPROCEEDINGS{cars, author={Nilsson, Dennis K. and Phung, Phu H. and Larson, Ulf E.}, booktitle={IET Road Transport Information and Control - RTIC 2008 and ITS United Kingdom Members' Conference}, title={Vehicle ECU classification based on safety-security characteristics}, year={2008}, volume={}, number={}, pages={1-7}, doi={10.1049/ic.2008.0810}} + + +@article{BASNIGHT201377, +title = {Firmware modification attacks on programmable logic controllers}, +journal = {International Journal of Critical Infrastructure Protection}, +volume = {6}, +number = {2}, +pages = {76-84}, +year = {2013}, +issn = {1874-5482}, +doi = {https://doi.org/10.1016/j.ijcip.2013.04.004}, +url = {https://www.sciencedirect.com/science/article/pii/S1874548213000231}, +author = {Zachry Basnight and Jonathan Butts and Juan Lopez and Thomas Dube}, +keywords = {Industrial control systems, Programmable logic controllers, Firmware, Modification attacks, Reverse engineering} +} + +@INPROCEEDINGS{9065145, author={Gao, Chao and Luo, Lan and Zhang, Yue and Pearson, Bryan and Fu, Xinwen}, booktitle={2019 IEEE International Conference on Industrial Internet (ICII)}, title={Microcontroller Based IoT System Firmware Security: Case Studies}, year={2019}, volume={}, number={}, pages={200-209}, doi={10.1109/ICII.2019.00045}} + +@article{thrangrycats, + title={Thrangrycat flaw lets attackers plant persistent backdoors on Cisco gear}, + author={Cimpanu, C}, + journal={Accessed: Sep}, + volume={15}, + pages={2019}, + year={2019} +} + +@article{hidden, + title={Source Hidden for Double Blind Review}, + author={Jhon Doe}, + journal = {Journal}, + year = {2022}, +} + +@INPROCEEDINGS{blockchain1, + + author={Dhakal, Samip and Jaafar, Fehmi and Zavarsky, Pavol}, + + booktitle={2019 IEEE 19th International Symposium on High Assurance Systems Engineering (HASE)}, + + title={Private Blockchain Network for IoT Device Firmware Integrity Verification and Update}, + + year={2019}, + + volume={}, + + number={}, + + pages={164-170}, + + doi={10.1109/HASE.2019.00033}} + +@inproceedings{sca_attack, +author = {Liu, Yannan and Wei, Lingxiao and Zhou, Zhe and Zhang, Kehuan and Xu, Wenyuan and Xu, Qiang}, +title = {On Code Execution Tracking via Power Side-Channel}, +year = {2016}, +isbn = {9781450341394}, +publisher = {Association for Computing Machinery}, +address = {New York, NY, USA}, +url = {https://doi.org/10.1145/2976749.2978299}, +doi = {10.1145/2976749.2978299}, +booktitle = {Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security}, +pages = {1019–1031}, +numpages = {13}, +keywords = {code execution tracking, power side-channel, embedded system, hardware security}, +location = {Vienna, Austria}, +series = {CCS '16} +} + +@INPROCEEDINGS{7928948, author={Krishnankutty, Deepak and Robucci, Ryan and Banerjee, Nilanjan and Patel, Chintan}, booktitle={2017 IEEE 35th VLSI Test Symposium (VTS)}, title={Fiscal: Firmware identification using side-channel power analysis}, year={2017}, volume={}, number={}, pages={1-6}, doi={10.1109/VTS.2017.7928948}} + +@inproceedings{ssd_firmware, +author = {Brown, Dane and Walker, Owens and Rakvic, Ryan and Ives, Robert W. and Ngo, Hau and Shey, James and Blanco, Justin}, +title = {Towards Detection of Modified Firmware on Solid State Drives via Side Channel Analysis}, +year = {2018}, +isbn = {9781450364751}, +publisher = {Association for Computing Machinery}, +address = {New York, NY, USA}, +url = {https://doi.org/10.1145/3240302.3285860}, +doi = {10.1145/3240302.3285860}, +booktitle = {Proceedings of the International Symposium on Memory Systems}, +pages = {315–320}, +numpages = {6}, +keywords = {firmware, security, classification, embedded systems}, +location = {Alexandria, Virginia, USA}, +series = {MEMSYS '18} +} + +@article{timing, +title = {Using timing-based side channels for anomaly detection in industrial control systems}, +journal = {International Journal of Critical Infrastructure Protection}, +volume = {15}, +pages = {12-26}, +year = {2016}, +issn = {1874-5482}, +doi = {https://doi.org/10.1016/j.ijcip.2016.07.003}, +url = {https://www.sciencedirect.com/science/article/pii/S1874548216301111}, +author = {Stephen Dunlap and Jonathan Butts and Juan Lopez and Mason Rice and Barry Mullins}, +} + +@INPROCEEDINGS{DTU, author={Xu, Aidong and Jiang, Yixin and Cao, Yang and Zhang, Guoming and Ji, Xiaoyu and Xu, Wenyuan}, booktitle={2019 IEEE 3rd Conference on Energy Internet and Energy System Integration (EI2)}, title={ADDP: Anomaly Detection for DTU Based on Power Consumption Side-Channel}, year={2019}, volume={}, number={}, pages={2659-2663}, doi={10.1109/EI247390.2019.9062014}} + +@inproceedings {wud, +author = {Shane S. Clark and Benjamin Ransford and Amir Rahmati and Shane Guineau and Jacob Sorber and Wenyuan Xu and Kevin Fu}, +title = {{WattsUpDoc}: Power Side Channels to Nonintrusively Discover Untargeted Malware on Embedded Medical Devices}, +booktitle = {2013 USENIX Workshop on Health Information Technologies (HealthTech 13)}, +year = {2013}, +address = {Washington, D.C.}, +url = {https://www.usenix.org/conference/healthtech13/workshop-program/presentation/clark}, +publisher = {USENIX Association}, +month = aug, +} + +@dataset{dataset, + author = {Anonymous}, + title = {{Dataset of bootup power consumption traces for + four networking equipments.}}, + month = apr, + year = 2022, + publisher = {Zenodo}, + doi = {10.5281/zenodo.6419214}, + url = {https://doi.org/10.5281/zenodo.6419214} +} + +@book{han2011data, + title={Data mining: concepts and techniques}, + author={Han, Jiawei and Pei, Jian and Kamber, Micheline}, + year={2011}, + publisher={Elsevier} +} + +@article{zimmering2021generating, + title={Generating Artificial Sensor Data for the Comparison of Unsupervised Machine Learning Methods}, + author={Zimmering, Bernd and Niggemann, Oliver and Hasterok, Constanze and Pfannstiel, Erik and Ramming, Dario and Pfrommer, Julius}, + journal={Sensors}, + volume={21}, + number={7}, + pages={2397}, + year={2021}, + publisher={Multidisciplinary Digital Publishing Institute} +} + + diff --git a/BPV/qrs/glossary.typ b/BPV/qrs/glossary.typ new file mode 100644 index 0000000..a42fe92 --- /dev/null +++ b/BPV/qrs/glossary.typ @@ -0,0 +1,123 @@ +// Glossary code by Hugo Cartigny (BlueskyFR) 🍉 + +#let glossary(indent-defs: false, doc) = { + // ✨ The glossary displays its items using level 99 headings + let glossary = state("wow", (:)) + + // Hide the numbering for level 99 titles + show heading.where(level: 99): it => text(weight: "regular", it.body) + + let page-refs-color = rgb("#7630EA") + + show terms: list => { + let terms-grid = () + // Add terms to glossary + for item in list.children { + glossary.update(v => { + v.insert( + item.term.text, + ( + // Holds the list of the locations referencing the term + ref-locs: (), + // The actual term definition + def: item.description, + ) + ) + + // Return the new state with the added entry + v + }) + + if indent-defs { + // Term + terms-grid.push([ + #heading(level: 99, numbering: "1")[*#item.term*] + #label(item.term.text) + ]) + + // Definition + terms-grid.push([ + #item.description + // Pages where the term is referenced + #show: text.with(page-refs-color) + #locate(loc => { + glossary.final(loc).at(item.term.text).ref-locs + .map(l => link(l, str(l.page))) + .join(", ") + }) + ]) + + } else [ + // Display items directly one by one since + // we don't need to build a grid + + // Use a level 99 title so it doesn't conflict with regular ones + // and it can be refered to by @citations + #heading(level: 99, numbering: "1")[ + *#item.term*:~~#item.description + // Pages where the term is referenced + #show: text.with(page-refs-color) + #locate(loc => { + glossary.final(loc).at(item.term.text).ref-locs + .map(l => link(l, str(l.page))) + .join(", ") + }) + ] + #label(item.term.text) \ + ] + } + + if indent-defs { + grid( + columns: (1fr, 4fr), + column-gutter: 2mm, + row-gutter: 8mm, + ..terms-grid + ) + } + + // 🐛 Debug + //glossary.display() + } + + show ref: r => { + locate(loc => { + // Search for the source of the ref + let term = str(r.target) + let res = query(r.target, loc) + + // If the source exists and is the glossary (heading level 99) + if res.len() > 0 and res.first().level == 99 { + let entry = glossary.at(loc).at(term) + + // Replace term by the user-specified supplement if not none + let custom-term = { + if r.citation.supplement != none { r.citation.supplement } + else { term } + } + + // If it is the first reference to the term, display its definition too + link(res.first().location(), { + if entry.ref-locs.len() == 0 [*#entry.def* (#custom-term)] + else [#custom-term] + }) + + // Add location to the term's ref list if the current page + // is not already listed + glossary.update(v => { + // If this page is not in, push the loc in! + if v.at(term).ref-locs.all(l => l.page != loc.page()) { + v.at(term).ref-locs.push( + // Current page loc + loc.position() + ) + } + v + }) + } + else { r } // Otherwise just return the ref as it is + }) + } + + doc +} \ No newline at end of file diff --git a/BPV/qrs/images/Bootup_traces_TPLINK.svg b/BPV/qrs/images/Bootup_traces_TPLINK.svg new file mode 100644 index 0000000..813ed5a --- /dev/null +++ b/BPV/qrs/images/Bootup_traces_TPLINK.svg @@ -0,0 +1,243 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/BPV/qrs/images/Synthetic_vs_Normal_TPLINK.svg b/BPV/qrs/images/Synthetic_vs_Normal_TPLINK.svg new file mode 100644 index 0000000..b23336d --- /dev/null +++ b/BPV/qrs/images/Synthetic_vs_Normal_TPLINK.svg @@ -0,0 +1,285 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/BPV/qrs/images/bootup.svg b/BPV/qrs/images/bootup.svg new file mode 100644 index 0000000..7a77550 --- /dev/null +++ b/BPV/qrs/images/bootup.svg @@ -0,0 +1,220 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/BPV/qrs/images/schematic.svg b/BPV/qrs/images/schematic.svg new file mode 100644 index 0000000..349e386 --- /dev/null +++ b/BPV/qrs/images/schematic.svg @@ -0,0 +1,620 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/BPV/qrs/images/training.svg b/BPV/qrs/images/training.svg new file mode 100644 index 0000000..4b6233c --- /dev/null +++ b/BPV/qrs/images/training.svg @@ -0,0 +1,2176 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 0 + + + + 200 + + + + 400 + + + + 600 + + + + 800 + + + + 1000 + + + + 250 + + + + + + + + + + + 0 + + + + 250 + + + + 500 + + + + 750 + + + + 1000 + + + + 1250 + + + + 1500 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 12.5 + + + + 15.0 + + + + 17.5 + + + + 20.0 + + + + 22.5 + + + + 25.0 + + + + 27.5 + + + + 30.0 + + + + 32.5 + + + + + + + + + + + + + + + + + BPV Models + Distance from each trace to average and Threshold + Amplitude + + + + + Model 1 Average trace + Model 2 Average trace + + Time (ms) + + + + + Model 1 Threshold + Model 2 Threshold + + Distance to Average + + diff --git a/BPV/qrs/main.typ b/BPV/qrs/main.typ new file mode 100644 index 0000000..44a6f9f --- /dev/null +++ b/BPV/qrs/main.typ @@ -0,0 +1,377 @@ +#import "utils.typ": * + +#import "template.typ": * +#show: ieee.with( + title: "Firmware Integrity Verification with Side-Channel Power Consumption Analysis", + abstract: [ + + ], + authors: ( + ( + name: "Arthur Grisel-Davy", + department: "Electrical and Computer Engineering", + organization: "University of Waterloo", + location: [Waterloo, Canada], + email: "agriseld@uwaterloo.ca" + ), + ( + name: "Sebastian Fischmeister", + department: "Electrical and Computer Engineering", + organization: "University of Waterloo", + location: [Waterloo, Canada], + email: "sfischme@uwaterloo.ca" + ), + ), + index-terms: (), + bibliography-file: "bibli.bib", +) + +// #let agd(content) = { +// text(blue, size:15pt)[#sym.star.filled] +// [#footnote[agd: #content]] +// } + +// #let cn = text(purple,size:15pt)[ #super[citation needed]] + +// #let ps_counter = counter("ps_counter") +// #let ps(title: none, content: none) = block[ +// #ps_counter.step() +// *Problem Statement #ps_counter.display() (#title)*: +// #content +// ] + +// // Define acronyms +// #let acronyms=( +// "IDS": "Intrusion Detection System", +// "SVM": "Support Vector Machine", +// ) +// // use heading 99 to display acronyms +// #show heading.where(level: 99): it => text(weight: "regular", it.body) +// #let refs=state("plop",acronyms) + +// // Initialize the expansion list to keep track of the expansions +// // #let exp = ("dummy": 0) +// // #for key in acronyms.keys(){ +// // exp.insert(key,0) +// // } + +// // function to call an acronym. Expands it on first encounter. +// #let acr(a: none) = { +// // if exp.at(a) == 0{ +// let long = acronyms.at(a) +// heading(level: 99)[#long (#a)] +// // exp.insert(a,1) +// //} +// } + +#let acronyms = ( + "IDS": "Intrusion Detection System", + "SVM": "Support Vector Machine", + "PLC": "Programable Logic Controlers", + "DC": "Direct Current", + "AC": "Alternating Current", + "APT": "Advanced Persistent Threats", +) + +#show ref: r =>{ + if str(r.target) in acronyms{ + locate(loc =>{ + let term = str(r.target) + let res = query(ref.where(target: r.target).before(loc),loc) + if res.len() == 1{ + [#acronyms.at(term) (#term)] + }else{ + term + } + }) + }else{ + r + } +} + += 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. There are multiple ways to leverage a firmware attack. Reverting firmware to an older version allows an attacker to reopen discovered and documented flaws. Cancelling an update can ensure that previously deployed attacks remain available. Finally, implementing custom firmware enables full access to the machine. + +The issue of malicious firmware is not recent. The oldest firmware vulnerability recorded on #link("cve.mitre.org") related to firmware dates back to 1999. Over the years, many solutions have been proposed to mitigate this issue. The first and most common countermeasure is verifying the integrity of the firmware before applying an update. 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. + += 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 unforgeable data and does not involve any communication with the host. A distance-based outlier detector that uses power traces of an unaltered boot-up sequence can learn the expected pattern and detect any variation in a new boot-up sequence. This novel solution could 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. It requires minimal training examples and minor hardware modification in most cases, especially for @DC powered devices. + +//% What we propose in this context: detecting firmware manipulations with power consumption +== Paper Organization +We elaborate on the type of attacks that our method aims to mitigate in the threat model section \ref{threat} and the technology we leverage to capture relevant information in section \ref{sca}. The models developed for this study are detailed in section \ref{feature_eng}. Finally, we present the experiment designed to illustrate the performance of our novel detector in section \ref{experiment}. +// % Reminder of how the paper is organized + += Overview +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 \glspl{ids} as the attacker can deceive detection methods at multiple levels. Moreover, firmware tampering is not necessarily a complex operation. + +== Threat Model +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. + +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. + +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. + +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. 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 an alternative firmware on a machine could allow an attacker to gain control of it without necessarily alerting the end-user. + +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. + +== Side Channel Analysis +\gls{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. \gls{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 \gls{ac} to \gls{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. + +$ a + b = gamma $ + +== Related Work +Historically, the firmware was written on a \gls{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, \glspl{plc} @plc_firmware, or any other industrial embedded system @santamarta2012here. Safety-critical environment are also prime targets including medical devices @health_review @pacemaker @medical_case_study, railway systems @railway or automotive systems @cars. + +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 simply 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 have 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. + +Historically, \gls{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. + + += Boot Process Verification +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. +] + +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. +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. + +== Detection Models +// The \gls{bpv} is responsible for detecting anomalies in a boot sequence power trace. The training phase is based on a few normal traces that are leveraged to train two types of distance-based detectors. After training, any new boot-up trace can be evaluated to verify the integrity of the firmware. An overview of the \gls{bpv} is presented in @fig-overview #footnote[The source code for the BPV is made available upon request]. + +// #figure( +// image("images/schematic.svg", width: 90%), +// caption: [Overview of the \gls{bpv} model training and evaluation.], +// ) +// #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$. +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. + +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. +First, the training dataset only contains nominal traces. +This assumption is important as there are a near inifinite ways how a boot sequence can be altered to create a malicious or malfunctining device. +The BPV aims at fingerprinting the nominal sequence, not recognizing the possible abnormal sequences. +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 sample is small. +In this case, small is relative to the usual number of training samples leveraged for time series classification #cn. +We assume that the training dataset contains between ten and 100 samples. +This assumption is important for realisme. +To keep the detector non-disruptive, the nominal boot sequences are captured during normal operation of the device. +However, the boot 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 folows 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 threshold as $"thresh" = 1.5 dot "IQR"(D)$ with IQR the Inter-Quartile Range of the distances set $D$. + +The \gls{iqr} is a measure of the dispersion of samples. +It is based on the first and third quartiles and defined as $ "IQR" = Q_3 - Q_1$ with $Q_3$ the third quartile and $Q_1$ the first quartile. +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 \gls{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 \gls{iqr} of these distances are 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 + +#agd[Add image from drone with multiple modes] +Some machines can boot following multiple different boot-up sequence that are considered normal. +There can exists various reason for such behavior. +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. +Because the machines are trated 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. +Then, the detection logic evolves to consider the new trace nominal if it mached 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. +@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."] +) + += Test Case 1: Network Devices + +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 IT organization, from individual houses to complete data centers @downtime. +A network failure can result in significant downtime that is extremely expensive to data centers. +Compromised network devices can also result in data breaches. +These devices are generally highly specialized in processing and transmitting information as fast as possible. +We consider four machines that represent consumer-available products for different prices and performance range. + +- Asus Router RT-N12 D1. This router is a low-end product that provides switch, router and wireless access point capabilities for home usage. +- Linksys Router MR8300 v1.1. This router is a mid-range product that offers the same capabilities as the Asus router with better performance at a higher price. +- TP-Link Switch T1500G-10PS. This 8-port switch offers some security features for low-load usage. +- HP Switch Procurve 2650 J4899B. This product is enterprise-oriented and provides more performance than the TP-Link switch. This is the only product of the selection that required hardware modification, as the power supply is internal to the machine. The modification consists in cutting the 5V cables to implement the capture system. + +None of the selected devices supports the installation of host-based @IDS or firmware integrity verification. Firmware is verified only during updates with a non-public mechanism. This experiment is designed to illustrate the firmware verification capability of a side-channel @IDS for these machines where common @IDS may not be applicable. + +//% \spabs{The text above connects with the listing of devices, but the text below is not connected and was written to be at the start and refers to the experiment we must have explained above as "this study"} +//% \spabs{Suggested to just continue the previous text and explain that we are trying to perform an experiment that can do that (firmware verif) for the mentioned hardware that lacks it, and for that bla bla... we use a capture box.......} + +== Experimental Setup +Although this experiment is conducted in a controlled environment, the setup is representative of an actual deployment. 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 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 \numprint[KSPS]{10}. These samples are packaged in small fixed-size chunks and sent to a data aggregation server on a private \gls{vlan}. The data aggregation server is responsible for gathering data from all of our capture boxes and sending it via a \gls{vpn} tunnel to a storage server as \numprint[s]{10} time series files. + +We gather data from the four networking equipment which are connected to a managed \gls{pdu}. This \gls{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. + +#figure( + table( + columns: (auto,auto,auto,auto), + align: horizon, + [*Equipment*], [*Original \ Firmware*], [*Modification 1*], [*Modification 2*], + [TP-Link\ Switch], [20200805], [20200109], [], + [HP Procurve\ Switch], [H.10.119], [H.10.117], [], + [Asus 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.], +) + +This experiment aims to simulate 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 \gls{oem} to different versions of OpenWrt. In this study, we consider the latest \gls{oem} firmware version to be the \textit{NORMAL} version, expected to be installed on the machine by default. Any other version or firmware is considered anomalous and represents an attack. + +== Experiment procedure +To account for randomness and gather representative boot-up sequences of the device, we performed \numprint{500} boot iterations for each machine. This cannot reasonably be performed manually with consistency. Therefore, an automation script controls the \gls{pdu} with precise timings to perform the boots without human intervention. + +The exact experimental procedure followed for each target has minor variations depending on the target's boot-up requirements. Overall, they all follow the same template with different timings. +- Step 1: Turn ON the power to the machine. +- Step 2: Wait for a predetermined period (depending on the specific target) for the target to boot up completely. +- Step 3: Turn OFF the power to the machine and wait for a few seconds to ensure proper shutdown of the machine. + +== Boot-up Sequence Extraction +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. 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$ 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. This pre-processing removes most of the \textit{salt-and-pepper} 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 the experiments presented in this paper can be found online @dataset}. + +== Results +We obtain the result per machine and per model. The training dataset is generated by injecting artificial anomalies, but the evaluation is performed on actual anomalous traces collected in a controlled environment. For each evaluation, a random set of $10$ consecutive traces is selected from the \textit{NORMAL} label to serve as the seed for the anomaly generation. The anomaly generator returns a training dataset composed of normal traces on one side and anomalous artificial traces on the other. The models train using this dataset and are evaluated against a balanced dataset combining $M\in[20,50]$ consecutive anomalous traces selected at random across all non \textit{NON-NORMAL} classes and as many \textit{NORMAL} traces. The testing set is balanced between \textit{NORMAL} and \textit{NON-NORMAL} traces. The training requires only a few \textit{NORMAL} traces. This evaluation is repeated $50$ times, and the $F_1$ score is computed for each iteration. The final score is the average of these $F_1$ scores. The results are presented in @tab:results. + +// \begin{table}[h] +// \centering +// %\begin{tabular}{|p{0.32\linewidth} |p{0.32\linewidth}| p{0.32\linewidth}|} +// \begin{tabularx}{\linewidth}{|X|X|X|} +// \hline +// \textbf{Machine} & \textbf{AIM Model} & \textbf{IQR Model}\\ +// \hline +// \hline +// TP-Link switch & 0.993 & 0.866\\ +// \hline +// HP switch & 0.73 & 0.983\\ +// \hline +// Asus router & 0.995 & 1\\ +// \hline +// Linksys router & 0.899 & 0.921\\ +// \hline +// \end{tabularx} +// \caption{Results of detection.} +// \label{tab:results} +// \end{table} + +#figure( + table( + columns: 3, + [*Machine*], [*AIM Model*], [*IQR Model*], + [TP-Link switch], [0.993], [0.866], + [HP switch], [0.73], [0.983], + [Asus router], [0.995], [1], + [Linksys router], [0.899], [0.921] + ), + caption: [Results of detection.] +) + +There are two hyper-parameters to tune to obtain the best performances. First, the length of the trace considered is essential. The trace needs to cover the whole boot-up sequence to be sure to detect any possible change. It is better to avoid extending the trace too much after the firmware sequence is done, as the typical operation of the machine can produce noisy power consumption that interferes with the optimal placement of the threshold. Secondly, the number of training traces can be optimized. A minimum of four traces is required for the \gls{iqr} method based on quartiles. A minimum of two traces are necessary for the \gls{svm} Threshold method as anomalous traces need to be generated based on the average and standard deviation of the normal dataset. Collecting additional traces after these lower boundaries offers marginal performance improvements as the number of traces has little impact on the threshold placement of both models. Moreover, collecting many boot-up sequences can be difficult to achieve in practice. Finally, tuning the sampling rate is important to ensure the best performances. A machine boot-up in two seconds will require a higher sampling rate than a machine booting in thirty seconds. All these parameters are machine-specific and need to be manually tuned before deployment of the side-channel \gls{ids}. + += Test Case 2: Drone + +== Experimental Setup + +== Experiment Procedure + +== Results + += Test Case 3: Aggregated Power Measurements +Results from L3 experiment. Present following the same model as for the previous ones. + += Specific Case Study: Anomaly Infused Model +When training a model to detect outliers, it is often expected to have examples of possible anomalies. In some cases, gathering anomalies can be difficult, costly, or impossible. In the context of this study, it would be impractical to measure power consumption patterns for a wide range of firmware anomalies. Such data collection would require modifying firmware parameters, suspending equipment usage, or infecting 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 leveraged the specificity of the 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. This implies that a distance-based detector that relies on a distance threshold can be trained the same way with either actual anomalous traces or with artificial traces that present the same distance to the reference. The idea behind an \gls{aim} is to leverage this property and generate artificial anomalous traces to form the training set. This training is generated from only normal traces, which circumvents the need for extensive data collection. + +The generation of anomalies from normal traces is based on the modification of the global pattern. Data augmentation can leverage different time series modification methods to help a model generalize. The kind of modification applied to a trace is highly dependent on the application and the model @zimmering2021generating and requires domain knowledge about the system. In this case, we want to generate adversarial traces with patterns similar to actual anomalous traces from a machine. The first step of this process is to extract domain knowledge from all the traces collected. The type of modification an anomalous trace present compared to a normal trace help us design anomaly generation functions that apply the same type of transformation to normal traces with varying parameters. The goal is not the reproduce exact anomalous traces but to generate a wide variety of possible anomalous traces given a small set of normal traces. The domain knowledge extracted from the study of anomalous traces is of two kinds: + +- 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 a 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 present 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. + +An example of anomalous trace can be found in @fig:boot-up_traces_TPLINK. + +#figure( + image("images/Bootup_traces_TPLINK.svg", width: 80%), + caption: [ + Example of TP-Link switch boot-up traces for different firmware versions. The anomalous firmware (FIRMWARE V2) present both a $y$ and $x$ shift. + ], +) + + + +The anomaly generation function combines the domain knowledge observations and applies anomalies to generate examples of anomalous traces from normal traces. The transformations include: + +- 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 \numprint[s]{0.5} 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 always presents a combination of $x$ shift, $y$ shift, or both. + +The algorithm for the anomaly generation function is presented in Algorithm \ref{algo}. + +// \begin{algorithm}[h] +// \caption{Anomaly Generation Procedure}\label{algo} +// \begin{algorithmic}[1] +// \State $x_{amp} \gets \text{random float} \in[-4,-2]\cup[4,2]$ +// \State $y_{amp} \gets \text{random float} \in[-5,-4]\cup[4,5]$ +// \State Generate a new trace using the data augmenter. +// \State Select the direction of the shift: $x$,$y$ or both. +// \If{$y$ shift selected} +// \State Add standard deviation multiplied with $y_{amp}$ to the new trace. +// \EndIf +// \If{$x$ shift selected} +// \State Select start time of shift. +// \State Shift new trace by $x_{amp}$ seconds. +// \State Recreate missing part based on previous $0.5$ seconds. +// \EndIf + +// \Return new anomalous trace +// \end{algorithmic} +// \end{algorithm} + +// #figure(caption: [Anomaly Generation Procedure], +// ``` + +// ``` +// ) + +The resulting dataset does not precisely resemble the anomalous traces that are collected but presents traces with the same range of distance as normal traces (see @fig:Synthetic_vs_Normal_TPLINK). +The dataset is balanced to avoid training bias by including new normal traces that are generated using the average and standard deviation of the available normal traces. + + +#figure( + image("images/Synthetic_vs_Normal_TPLINK.svg"), + caption: [Example of generated synthetic anomalous traces vs normal traces for TP-Link switch.], +) + += Discussion +#agd["Add subsection"] +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 \gls{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. + +== Limitations of Anomaly Generation + += Conclusion +This study illustrates the applicability of side-channel analysis to detect firmware attacks. The proposed side-channel-based \gls{ids} can reliably detect firmware tampering from the power consumption trace. Moreover, distance-based models leveraged in this study allow minimal training data and training time requirements. Anomaly generation is leveraged to enhance the training set without additional anomalous data capture. Finally, deploying this technology to production networking equipment requires minimal downtime and hardware intrusion, and it is applicable to clientless equipment. diff --git a/BPV/qrs/template.typ b/BPV/qrs/template.typ new file mode 100644 index 0000000..14a3582 --- /dev/null +++ b/BPV/qrs/template.typ @@ -0,0 +1,165 @@ +// This function gets your whole document as its `body` and formats +// it as an article in the style of the IEEE. +#let ieee( + // The paper's title. + title: "Paper Title", + + // An array of authors. For each author you can specify a name, + // department, organization, location, and email. Everything but + // but the name is optional. + authors: (), + + // The paper's abstract. Can be omitted if you don't have one. + abstract: none, + + // A list of index terms to display after the abstract. + index-terms: (), + + // The article's paper size. Also affects the margins. + paper-size: "us-letter", + + // The path to a bibliography file if you want to cite some external + // works. + bibliography-file: none, + + // The paper's content. + body +) = { + // Set document metdata. + set document(title: title, author: authors.map(author => author.name)) + + // Set the body font. + set text(font: "STIX Two Text", size: 10pt) + + // Configure the page. + set page( + paper: paper-size, + numbering: "1", + // The margins depend on the paper size. + margin: if paper-size == "a4" { + (x: 41.5pt, top: 80.51pt, bottom: 89.51pt) + } else { + ( + x: (50pt / 216mm) * 100%, + top: (55pt / 279mm) * 100%, + bottom: (64pt / 279mm) * 100%, + ) + } + ) + + // Configure equation numbering and spacing. + set math.equation(numbering: "(1)") + show math.equation: set block(spacing: 0.65em) + + // Configure lists. + set enum(indent: 10pt, body-indent: 9pt) + set list(indent: 10pt, body-indent: 9pt) + + // Configure headings. + set heading(numbering: "I.A.1.") + show heading: it => locate(loc => { + // Find out the final number of the heading counter. + let levels = counter(heading).at(loc) + let deepest = if levels != () { + levels.last() + } else { + 1 + } + + set text(10pt, weight: 400) + if it.level == 1 [ + // First-level headings are centered smallcaps. + // We don't want to number of the acknowledgment section. + #let is-ack = it.body in ([Acknowledgment], [Acknowledgement]) + #set align(center) + #set text(if is-ack { 10pt } else { 12pt }) + #show: smallcaps + #v(20pt, weak: true) + #if it.numbering != none and not is-ack { + numbering("I.", deepest) + h(7pt, weak: true) + } + #it.body + #v(13.75pt, weak: true) + ] else if it.level == 2 [ + // Second-level headings are run-ins. + #set par(first-line-indent: 0pt) + #set text(style: "italic") + #v(10pt, weak: true) + #if it.numbering != none { + numbering("A.", deepest) + h(7pt, weak: true) + } + #it.body + #v(10pt, weak: true) + ] else [ + // Third level headings are run-ins too, but different. + #if it.level == 3 { + numbering("1)", deepest) + [ ] + } + _#(it.body):_ + ] + }) + + // Display the paper's title. + v(3pt, weak: true) + align(center, text(18pt, title)) + v(8.35mm, weak: true) + + // Display the authors list. + for i in range(calc.ceil(authors.len() / 3)) { + let end = calc.min((i + 1) * 3, authors.len()) + let is-last = authors.len() == end + let slice = authors.slice(i * 3, end) + grid( + columns: slice.len() * (1fr,), + gutter: 12pt, + ..slice.map(author => align(center, { + text(12pt, author.name) + if "department" in author [ + \ #emph(author.department) + ] + if "organization" in author [ + \ #emph(author.organization) + ] + if "location" in author [ + \ #author.location + ] + if "email" in author [ + \ #link("mailto:" + author.email) + ] + })) + ) + + if not is-last { + v(16pt, weak: true) + } + } + v(40pt, weak: true) + + // Start two column mode and configure paragraph properties. + show: columns.with(2, gutter: 12pt) + set par(justify: true, first-line-indent: 1em) + show par: set block(spacing: 0.65em) + + // Display abstract and index terms. + if abstract != none [ + #set text(weight: 700) + #h(1em) _Abstract_---#abstract + + #if index-terms != () [ + #h(1em)_Index terms_---#index-terms.join(", ") + ] + #v(2pt) + ] + + // Display the paper's contents. + body + + // Display bibliography. + if bibliography-file != none { + show bibliography: set text(8pt) + bibliography(bibliography-file, title: text(10pt)[References], style: "ieee") + } +} diff --git a/BPV/qrs/utils.typ b/BPV/qrs/utils.typ new file mode 100644 index 0000000..92170c9 --- /dev/null +++ b/BPV/qrs/utils.typ @@ -0,0 +1,22 @@ +// Comment macros +#let agd(content) = { + text(blue, size:15pt)[#sym.star.filled] + [#footnote[agd: #content]] +} + +#let cn = text(purple,size:15pt)[ #super[citation needed]] + +// problem statement environment +// Usage: +// #ps(title: "Boot Process Verification", +// content: "Given a set of time series..." +// ) +#let ps_counter = counter("ps_counter") +#let ps(content, title: none) = [ + #ps_counter.step() + #pad(y: 10pt,[ + *Problem Statement #ps_counter.display() (#title)*: + #content + ]) +] +