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.

1. Model-based simulation
and threat analysis of
in-vehicle networks
Alexios Lekidis, Ion Barosan
WFCS 2019
Sundsvall, 28/05/2019

2. Outline
• Connected cars evolution
• 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
1886 2000 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
Complexity and V2X connectivity increase threat/hazard surface

7. Tackling complexity through data 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 cars evolution
• 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 security risks
• 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
Unit Direct 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 to safety Bus
from telematics system
Attack scenario
OBDII

15. OBDII
Central
Gateway
Brake
Control
Unit
Head
Unit
Telematics
Control
Unit
• Disengage
brakes or kill
engine
Attack scenario
Challenges:
• Accessing the attack impact
• Detecting the anomaly in the
embedded system

16. Outline
• Connected cars evolution
• 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. Proposed method

18. Behavior learning
• Network fingerprinting
– 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. Data model

20. Data model (in DBC)
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
• Tool for 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 cars and 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 from the Toyota Prius
• Vehicle available
within TU/e premises
from A-Team
• CANtact to OBD-II due
to buffer overflow in
ELM327

28. Network and threat analysis 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 class Description
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 class Description
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 on vehicle 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 on the 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 detection of 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 for your attention
Further info: a.lekidis@tue.nl, i.barosan@tue.nl