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

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.