1 / 37

Scalable Security: A Practical Approach for Bounding Cyber Security in Autonomous Vehicles

Explore a framework for securing Connected and Autonomous Vehicles (CAVs) through secure OTA updates and onboard breach mitigation. Discuss the motivation, related work, future implications, and proposed research questions. Discover strategies like self-verification of OTA updates, runtime models for adaptive systems, and best practices for software dependability in CAVs.

clair
Download Presentation

Scalable Security: A Practical Approach for Bounding Cyber Security in Autonomous Vehicles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Scalable Security: A Practical Approach for Bounding Cyber Security in Autonomous Vehicles By: Jesse Hoskins

  2. Overview • Introduction • Motivation • Related Work • Framework • Example Usage • Pros and Cons • Future Work

  3. Introduction

  4. Introduction – Research Questions • How will Connected and Autonomous Vehicles (CAVs) mitigate an onboard cyber security breach? • How will CAVs implement secure over-the-air (OTA) updates and mitigate the remaining risk associated with a breach?

  5. Research Proposal Overview • Adapt and extend run-time safety assurance (RTSA) for unmanned aircraft systems (UAS) as a run-time security framework for CAVs addressing both OTA and onboard security breach mitigation

  6. What is RTSA?

  7. Why RTSA? • Method to safely bound complex system behavior • Artificial Intelligence/Machine Learning • Adaptive software • Non-deterministic intelligent algorithms • Software rate of change increasing, rendering traditional certification methods astronomically costly • Enables automated UAS operations in the aviation industry* *This is an industry best practice currently as the regulations governing highly automated UAS operations develop

  8. Motivation • CAV software rate of change and complexity is increasing: how to verify security cost effectively?

  9. Related Work

  10. Secure OTA Updates • Secure Firmware Updates over the Air in Intelligent Vehicles • Lightweight protocol providing data integrity, authentication, confidentiality, and freshness • Protocol Steps • Divide firmware binary into fragments • Using random nounce, create hash chain of fragments in reverse order • Concatenate first and second hash • Encrypt each hash (using Cipher-block chaining) • Add header and transmit • Reverse procedure on vehicle side

  11. Self Verification of OTA Updates • A Framework for Self-Verification of Firmware Updates over the Air in Vehicle ECUs Figure 1: Framework for self-verification of firmware updates over the air in vehicle ECUs Figure 2: Protocol for self-verification of ECU firmware update

  12. Runtime Models for Assurance of Self Adaptive Systems • Using Models at Runtime to Address Assurance for Self-Adaptive Systems • Apply models at runtime for assurance of both functional and non-functional requirements Figure 3: The three levels of M@RT for the assurance of SASs

  13. UAS Software Dependability – Best Practices • Standard Practice for Ensuring Dependability of Software Used in Unmanned Aircraft Systems • Focus on: • Organizational controls • Use of software in system • Metrics and design analysis • Code review tools and techniques • Quality assurance • Testing Figure 4: Typical Small Unmanned Aircraft System

  14. CAV Electronic & Electronic Architecture • Understanding Vehicle E/E Architecture Topologies for Automated Driving: System Partitioning and Tradeoff Parameters Figure 5: Typical Vehicle E/E Topology

  15. Considerations – UAS vs CAV

  16. Considerations – Safety vs Security • Assurance covers both safety and security • Security • Focuses on protecting system from external actors • Threats are generally intentional and malicious in nature • Safety • Focuses on protecting system from factors that cause harm (both internal and external) • Threats are generally unintentional

  17. Framework

  18. Component Breakdown • ECU – Electronic Control Unit • DC – Domain Controller • PDC – Pedigreed Domain Controller • V2V – Vehicle to Vehicle • V2I – Vehicle to Infrastructure • V2X – Vehicle to Everything • OTA – Over the Air

  19. UAS RTA Mapping to PDC Note that the “Complex Function” exists in the PDC’s domain and externally (incoming from the Central Gateway)

  20. RTA for CAVs via PDC

  21. Input Manager • Check for corrupt data/invalid messages • Separate instances for incoming data from central vehicle network and from PDC’s domain

  22. Security Monitor • Monitors incoming vehicle commands and general network traffic • Commands RTA Switch which RCF to use or to passthrough inputs • Contains: • Blacklisted functionality/behavior • Intrusion Detection System • Runtime model of outgoing domain expected behavior • Runtime model of expected incoming behavior

  23. RTA Switch • Based on inputs from the Security Monitor, either invoke Recovery Control Function, Self Verification System, or passthrough inputs

  24. Recovery Control Functions • Responsible for mitigation of detected anomalous behavior • Example RCF Functions • Reset specific ECU • Notify driver of potential cyber breach • Safely stop the vehicle • Disable remote connectivity • Quarantine an ECU or subsystem • Advanced intrusion detection

  25. Self Verification Control System • Invoked by the RTA Switch, acts as “Control System” • Flashes new firmware on ECU • Reads memory back • Calculate response based on memory and challenge • Verify response and verification code match • Confirm update via OTA ECU Figure 2: Protocol for self-verification of ECU firmware update

  26. Why PDCs? • Functionality is decentralized (multiple PDCs performing pedigreed security functionality) • Harder for attacker to eliminate pedigreed security monitoring • Allow for pedigreed models to be less complex/specific to each domain • More efficient then implementing pedigreed functionality per ECU • DCs will change slower than individual ECUs • Less power consumption then per ECU

  27. Assumptions • Secure Firmware Over The Air (SFOTA) mechanism employed • PDCs can be implemented as depicted without drastically increased time/computing resource/power consumption

  28. Example Usage – Malicious Firmware Update

  29. Example Usage – Malicious Firmware Update RTA Switch activates the Self Verification Control System Attacker modifies firmware stored in RAM, undetected Security Monitor validates request to update firmware and commands RTA Switch to activate Self Verification Control System Control System feedback detects malicious modification, Security Monitor alerts RTA Switch, and RCF 1 (ECU Quarantine) is initiated Control System stores firmware update in RAM on target ECU, waiting for vehicle to not be in use Input Manager validates Firmware update is allowed from Connectivity PDC Firmware Update for Air Conditioning Quarantine

  30. Example Usage – Infotainment Breach Attacker breaches Infotainment system and tries to send commands to the accelerator and steering wheel

  31. Example Usage – Infotainment Breach Security Monitor will detect that Infotainment system should not be broadcasting this command and command the RTA Switch to initiate RCFs Input Manager will pass valid messages through to Security Monitor

  32. Utility of Approach • Robust security monitoring provides both mitigations of onboard attack and SFOTA • Allows for software updates of complex functionality without rigorous security certification • Provides relatively cost effective method of securing CAVs in dynamic environment • Utilizes existing CAV system architecture and hardware

  33. Limitations of Approach • Cost and time required to certify a domain controller as pedigreed could be substantial depending on the domain (ADAS more complex than Body Electronics) • Potentially computing resource and memory intensive, depending on implementation • Does not prevent eavesdropping attacks • Only as sophisticated as the implemented security monitor

  34. Future Work • Further analysis on practicality of implementation of a PDC for each domain • Memory/processing constraints • Cost • Timing when RTA functions are triggered • Power consumption • Develop specific requirements for inputs to security monitor for each domain • Prototyping of PDC

  35. Conclusions • RTSA for UAS can be adapted and extended to effectively provide a framework for bounding cyber security in CAVs • RTSA for CAVs can be used to cost effectively address OTA and cyber attack mitigation despite the high rate of change of CAVs and extreme complexity • More research is needed, specifically defining the requirements for a PDC in an initial prototype

  36. Questions?

  37. References [1] - Parkinson, S., Ward, P., Wilson, K., & Miller, J. (2017). Cyber Threats Facing Autonomous and Connected Vehicles: Future Challenges. IEEE Transactions on Intelligent Transportation Systems,18(11), 2898-2915. doi:10.1109/tits.2017.2665968 [2] - ASTM International. (2017). Standard Practice for Methods to Safely Bound Flight Behavior of Unmanned Aircraft Systems Containing Complex Functions. F3269 − 17. [3] - Nilsson, D. K., & Larson, U. E. (2008). Secure Firmware Updates over the Air in Intelligent Vehicles. ICC Workshops - 2008 IEEE International Conference on Communications Workshops. doi:10.1109/iccw.2008.78 [4] - Nilsson, D. K., Sun, L., & Nakajima, T. (2008). A Framework for Self-Verification of Firmware Updates over the Air in Vehicle ECUs. 2008 IEEE Globecom Workshops. doi:10.1109/glocomw.2008.ecp.56 [5] - B. Cheng, K. Eder, M. Gogolla, L. Grunske, M. Litoiu, H. Müller, P. Pelliccione, A. Perini, N. Qureshi, B. Rumpe, D. Schneider, F. Trollmann, N. Villegas: Using Models at Runtime to Address Assurance for Self-Adaptive Systems. Models@run.time, LNCS 8378, pp. 101-136, Springer Publisher, 2014. [6] - Mody, Mihir, et al. “Understanding Vehicle E/E Architecture Topologies for Automated Driving: System Partitioning and Tradeoff Parameters.” Electronic Imaging, vol. 2018, no. 17, 2018, doi:10.2352/issn.2470-1173.2018.17.avm-358. [7] - ASTM International. (2016). Standard Practice For Ensuring Dependability of Software Used in Unmanned Aircraft Systems (UAS). F3201 − 16.

More Related