Download as PDF, PPTX
Uploaded byAlexios Lekidis
Wfcs2019
This document discusses model-based simulation and threat analysis of in-vehicle networks. It outlines the evolution of connected cars and the associated security risks. It then introduces the CARSEC environment for simulating in-vehicle networks and assessing risks. A case study applies CARSEC to evaluate security on a Toyota Prius architecture. Attacks are simulated and their impacts analyzed. The document concludes that CARSEC allows early detection of errors and threats to help enhance vehicle security. Future work includes automating the data collection process and directly using OBD-II port access.
Wfcs2019
- 1. Model-based simulation and threatanalysis of in-vehicle networks Alexios Lekidis, Ion Barosan WFCS 2019 Sundsvall, 28/05/2019
- 2. Outline • Connected carsevolution • Security risks and challenges • CARSEC: In-vehicle network simulation and risk assessment environment • Case-study: Evaluation on a Toyota Prius architecture • Conclusions and perspectives
- 3. Car historical evolution 18862000 2020 R&D area: 1966-1995 Embedded area: 1995- 2002 Infotainment area: 2007- 2012
- 4. 1886 2005 2020 Embedded area:1995- 2002 V2X area: 2012- ongoing Infotainment area: 2007- 2012 Car historical evolution
- 5. 1886 2005 2020 Embedded area:1995- 2002 V2X area: 2012- ongoing Infotainment area: 2007- 2012 New mobility area: 2020- onwards Car historical evolution
- 6. In-vehicle software complexity Complexityand V2X connectivity increase threat/hazard surface
- 7. Tackling complexity throughdata visibility • OBD-II added for troubleshooting and diagnostics (i.e. observing vehicle characteristics as engine, temperature) • OBD-II standard mandatory for all vehicles - 01 0C - 7E8 04 41 0C 10 C5 - 7EA 04 41 0C 10 80 RPM value length Request RPM OBD-II
- 8. In-vehicle network architecture:V2X area central gateway Instrument cluster Climate control Door locking Head Unit Audio Video Navigation Telephone Steering control Air Bag control Breaking system Engine control Transmission control Power train sensors MOST protocolCAN LINCAN/FlexRay OBUTCUHead Unit OBD-II • Head Unit: Vehicle entertainment system • On-board Unit (OBU): Enabling V2X communication • Telematics Control Unit (TCU): Vehicle tracking • Gateway: Central vehicle data access • On Board Diagnostics (OBD): Status diagnostics
- 9. In-vehicle network architecture:V2X area central gateway Instrument cluster Climate control Door locking Head Unit Audio Video Navigation Telephone Steering control Air Bag control Breaking system Engine control Transmission control Power train sensors MOST protocolCAN LINCAN/FlexRay OBUTCUHead Unit OBD-II Critical systems • Head Unit: Vehicle entertainment system • On-board Unit (OBU): Enabling V2X communication • Telematics Control Unit (TCU): Vehicle tracking • Gateway: Central vehicle data access • On Board Diagnostics (OBD): Status diagnostics
- 10. Outline • Connected carsevolution • Security risks and challenges • CARSEC: In-vehicle network simulation and risk assessment environment • Case-study: Evaluation on a Toyota Prius architecture • Conclusions and perspectives
- 11. Connected car securityrisks • Vital risks to vehicle passengers • Various incidents over the last years Crysler’s Jeep Cherokee CIA’s Vault 7 Bosch Drivelog dongle
- 12. Vehicle attack surfaces OBDII Telematics Control Unit Central Gateway Keyless entry Tire Pressure Monitoring Sensor Head UnitDirect access Long-range access Short-range access
- 13. Attack scenario OBDII Central Gateway Head Unit Brake Control Unit Telematics Control Unit •Sniff the telematics system IP address • Random generator of Bluetooth PIN / WiFi WPA password
- 14. Central Gateway Brake Control Unit Head Unit Telematics Control Unit • Move tosafety Bus from telematics system Attack scenario OBDII
- 15. OBDII Central Gateway Brake Control Unit Head Unit Telematics Control Unit • Disengage brakes orkill engine Attack scenario Challenges: • Accessing the attack impact • Detecting the anomaly in the embedded system
- 16. Outline • Connected carsevolution • Security risks and challenges • CARSEC: In-vehicle network simulation and risk assessment environment • Case-study: Evaluation on a Toyota Prius architecture • Conclusions and perspectives
- 17.
- 18. Behavior learning • Networkfingerprinting – Network communication baseline for driving or parking mode – Captures cyclic messages between ECUs periodic • Manual scenario execution – Captures asynchronous actions inside the vehicle (e.g. driver switching on/off the engine) – Extends the communication baseline with dynamic messages Outcome: 1) Data flow patterns 2) Correlation between certain messages
- 19.
- 20. Data model (inDBC) Data model filling
- 21. OMNET++ simulation environment •Open-source discrete event simulation framework • Progressive system construction from component-based modules • Network Editor (NED): Module editing • Initial configuration file (INI): Network data exchange definitions • In-vehicle protocol simulation through FiCo4OMNeT library – CAN, FlexRay support
- 22. OMNET++: CAN node(NED) • Data transmitter (sourceApp): CAN frame transmission • Output buffer (bufferOut): Temporal frame storage and scheduling for Bus transmission Input buffer (bufferIn): Temporal frame storage and forwarding to the data receiver • Data receiver (sinkApp): CAN frame reception and physical vehicle actions • Hardware clock (canClock): Node clock for frame scheduling • Data logger (pcapRecorder): Traffic logging
- 23. OMNET++: CAN node(INI) • idDataFrames: Message identifiers of the node • periodicityDataFrames: Message periodicity • dataLengthDataFrames: Data length • payloadDataFrames: Message payload • initialDataFrameOffset: CAN message scheduling offset Challenges: 1) Configuration changes require manual simulation restart 2) User actions cannot be modeled (e.g. driving mode)
- 24. Dynamic vehicle behavior •Added functionality: – Dynamic changes in the model’s INI configuration while the simulation is active – Dynamic calculation of bit-stuffing based on the exchanged data • Technique: Distribution fitting on the data logged while driving • Outcome: Payload values chosen based on the probability law of the fitted distribution
- 25. Model validation • Toolfor automatic validation of the simulation accuracy against the real vehicle behavior – Different operation modes (i.e. parking or driving) • Relying on network traffic (i.e. pcap, log files) • Comparison on: 1) Packet level 2) Communication flow OMNET++ simulated traffic OBDII vehicle traffic CANvalidator Verdict OK NOK
- 26. Outline • Connected carsand their underlying security risks • Challenges in in-vehicle network simulation • CARSEC: In-vehicle network simulation and risk assessment environment • Case-study: Evaluation on a Toyota Prius architecture • Conclusions and perspectives
- 27. Data logging fromthe Toyota Prius • Vehicle available within TU/e premises from A-Team • CANtact to OBD-II due to buffer overflow in ELM327
- 28. Network and threatanalysis on a Toyota Prius Goal: Real-time analysis of operational errors or security aspects Outcome: In-vehicle impact analysis and feedback for enhancements
- 29. Simulated attacks Attack classDescription Denial Of Service Network flooding with certain frame ID Frame injection Inserting known/unknown frame ID Diagnostic messages Extract diagnostic info from ECUs allowing to reprogram them Masquerade / impersonation attack ECU spoofing or frame replay Fuzzing Iterative transmission of random or partially random packets Suspension Prevent frame transmission from a specific ECU Source: Common threats based on in-vehicle security state-of-the-art Purpose: Use simulation to avoid non recoverable errors from attacks on the in- vehicle architecture
- 30. Simulated attacks Attack classDescription Denial Of Service Network flooding with certain frame ID Frame injection Inserting known/unknown frame ID Diagnostic messages Extract diagnostic info from ECUs allowing to reprogram them Masquerade / impersonation attack ECU spoofing or frame replay Fuzzing Iterative transmission of random or partially random packets Suspension Prevent frame transmission from a specific ECU Three categories of attacks: 1) Not feasible 2) Feasible but no impact on vehicle functionality 3) Feasible with impact on vehicle functionality, but requiring adequate in-vehicle network knowledge
- 31. Attack impact onvehicle functionality Attack start • Impact: Confusing indicator in the dashboard • Generating error frames on the Bus • Errors lead to error active/passive mode
- 32. Attack impact onthe in-vehicle network - Initial increase in the amount of messages - Frequency-based detection for identifying the anomaly - For persistent attacks the Bus gradually balances the message load - Attack detection becomes very difficult
- 33. Conclusion • Early-stage detectionof operational errors and security threats in the in-vehicle architecture • Impact and risk assessment for the addition of new features • Applied to a Toyota Prius vehicle within TU/e premises – State-of-the-art attacks to examine alternations of the vehicle behavior Future work • Automate the preliminary in-vehicle learning/data filling step • Use of OBD-II: 1) allows to learn only CAN and LIN network data 2) limits the network data if manufacturer firewall is used
- 34. Thank you foryour attention Further info: a.lekidis@tue.nl, i.barosan@tue.nl