Clocking CAN Attacks:

1. Clocking CAN Attacks: Analysis of the Clock-based IDS (CIDS) proposed in “Fingerprinting electronic control units for vehicle intrusion detection.” by Kyong-Tak Cho and Kang G. Shin Daniel Kent College of Engineering Michigan State University 2018 Feb 26

2. Review: Vehicle Attack Surfaces[2] • Low-Level Sensor Spoofing/Jamming • Global Navigation Satellite Systems (GNSS) • Active Sensors (lidar, radar) • Passive Sensors (camera) • Connected Vehicle Technology • Cellular Uplink • V2V/V2X (Cellular or DSRC) • Tire Pressure Monitoring System (TPMS) • Vehicle Bus • Compromise existing ECUs • Inject data via OBD-II, infotainment, or direct tap [2] S. Parkinson, P. Ward, K. Wilson, and J. Miller, “Cyber threats facing autonomous and connected vehicles: future challenges,” IEEE Transactions on Intelligent Transportation Systems, vol. 18, no. 11, pp. 2898– 2915, 2017.

3. Review: CAN Vulnerabilities • CAN is designed as an open bus that allows any connected computer to read and/or write any message ID • Open-bus design results in five classes of CAN vulnerabilities[3, pg, 3]: • Data Integrity • Authentication • Confidentiality • Non-repudiation • Availability • Some techniques available can mitigate some of these vulnerabilities • Wang et al.: Message Authentication Codes (1, 2, 4) [4] • Cho and Shin: Clock-based Message Fingerprinting (2, 4) [1] [3] O. Avatefipour and H. Malik, “State-of-the-art survey on in-vehicle network communication can-bus security and vulnerabilities,” 2017. [4] Q. Wang and S. Sawhney, "VeCure: A practical security framework to protect the CAN bus of vehicles,"2014 International Conference on the Internet of Things (IOT), Cambridge, MA, 2014, pp.13-18.doi: 10.1109/IOT.2014.7030108

4. Message Source: CAN vs. Ethernet • CAN by design does not have a sender/receiver component for each message. • Ethernet: MAC source/destination[5]. Higher-level protocols (TCP/UDP) also contain additional routing information. Not immune to spoofing, but can be detected/mitigated[6]. Format of a CAN data frame [1, pg. 912] Format of an Ethernet data frame [5] [5] “802.3-2015 – IEEE Standard for Ethernet.” IEEE Std. 802.3. 2015. [6] “Reverse Path Filtering.” Linux Advanced Routing and Traffice Control HOWTO. Accessed 3 February 2018. https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

5. Message Source on CAN: Takeaways • CAN bus message spec does not include message routing information, and limited bytes per message makes it cumbersome to add origin information to existing bus • Adding source and/or authentication would reduce capacity of CAN, already limited to ~1 Mbps under best-case scenario • Inclusion of message origin could help determine whether messages are genuine, based on existing technology targeted at Ethernet-based networks Is there some other way to get message source information on CAN?

6. Message Timing on CAN • CAN is designed as a bus for real-time systems, so periodic message timings are generally consistent to some degree • Computer clocks tend to drift slightly over time in a roughly linear fashion (expected value of non-linear components are assumed to be 0) • ECUs do not typically have their clocks synchronized as many Internet-connected systems do (NTP / PTP) • CAN protocol has a message arbitration phase (message ID block), allowing for message transmission synchronization without directly synchronized clocks • After arbitration phase, only one ECU should be transmitting at any given time Depiction of Clock Skew [1, pg. 916]

7. ECU Clock State as a Side-Channel • Message bit rising/falling edges after the message arbitration phase leak information about the clock for the ECU sending the message. • Cho and Shin proposed a method to use bid edge timings to differentiate between different ECUs on the system, and discover if the source ECU for a given message has changed[1].

8. A Brief Foray into Estimation Theory • Recovering information from a signal corrupted by noise and/or transformed using a function can seem daunting • Probabilistic frameworks for both estimating parameters, as well as evaluating both the quality of the estimate as well as the theoretical effectiveness of these estimators exist • ECE 864: Detection and Estimation Theory goes into more detail on these methods and their derivations

9. Types of Estimators Different types of estimators exist: • Maximum Likelihood (MLE) and Maximum a posteriori (MAP) Estimators • Best Linear Unbiased Estimator (BLUE) • Wiener filters (static parameters) • Kalman filters (changing parameters) • Extended/Unscented variants • Particle filters (sample-based) • Linear/Quadratic Regression • Recursive Least Squares (RLS)

10. Implementation of RLS as a Clock Skew Estimator • RLS estimator will come up with a series of coefficients that estimate the ECU’s clock skew based on measurements of • A “forgetting factor” (λ) causes RLS to weigh older samples exponentially less • Cumulative Sum (CUSUM) of the skew for a given message is tracked, allowing for detection of sudden changes, which can indicate that the transmitter has changed or has been silenced [1, pg. 918]. Cumulative Clock Skew [1, pg. 920]

11. Proposal: Clock-based IDS (CIDS) Based on the information provided by the clock skew estimator, Cho and Shin proposed an intrusion-detection system that uses the cumulative clock skew to detect if/when a periodic CAN message’s transmitting ECU changes.

12. Specific Types of CAN Attacks • Cho and Shin describe three specific types of CAN attacks that their clock-based IDS can detect: • Fabrication: Send a message ID that another ECU normally sends (requires “strong” attacker) • Suspension: Prevent an ECU that is supposed to periodically send a message ID from sending said message (requires “weak” attacker) • Masquerade: Use suspension to prevent transmission of a message ID, then use fabrication to send false messages with the message ID from another ECU (requires 1 “strong” and 1 “weak” attacker) • Masquerade attack was used in the Miller et al. Jeep proof-of-concept attack, as direct braking manipulation wasn’t available. Identified Attack Types [1, pg. 914]

13. Detecting Attacks with CIDS • When an attacker begins to transmit a periodic message at the wrong frequency, the clock skew CUSUM will jump abruptly for the affected message(s) • When the attack ceases, the clock skew CUSUM will once again change abruptly

14. Examples of Detected Attacks using Clock-Based IDS CIDS detecting fabrication and suspension attacks in a 2013 Honda Accord [1, Pg. 921]

15. Corner Case: Near-Equivalent Clock Skews • While the main body of the paper assumes that ECUs will have measurably different clock skews, the researchers involved discovered that two ECUs can experience nearly identical clock skew. • An extension to CIDS was added that checks the pairwise correlation between messages sent by the same ECU • A change in transmission source of a message will cause the clock skew correlation between it and other messages that were previously sent by the same ECU to drop

16. Examples of Detected Attacks using Clock-Based IDS CIDS detecting masquerade attacks in worst-case (equivalent clock skew) case [1, Pg. 923]

17. CIDS Performance Metrics • Receiver operating characteristics (ROC) curves show very low false positive rates for per-message detection, and even better rates when adding message pairwise detection ROC curves for per-message (top) and per-message plus pairwise detection (bottom) [1, pg. 924]

18. Defeating CIDS • Cho and Shin discussed several ways that attackers aware of CIDS could avoid detection: • Disable the CIDS installed in an ECU • Mitigated if all ECUs contain a CIDS and can cross-validate • Attempt to match clock skew of target ECU via similar clock-estimation techniques • Can still be detected with message pairwise detection

19. Limitations ofCIDS • CIDS doesn’t work on aperiodic messages • If a compromised ECU sends falsified messages aperiodicallyfor an otherwise periodic message, the source ECU likely can’t be determined by CIDS • CIDS can still detect that the message was falsified.

20. Applicability Beyond CAN • CAN-FD: • Higher bandwidth CAN variant with flexible data rate • Still based on existing CAN protocol; CIDS could work • TTCAN/FlexRay: • Node are periodically synchronized • Synchronization frequency is manufacturer-specified • Synchronization reduces clock skews across system • CIDS may not be feasible if synchronization is too frequent • Applicability to Ethernet was not addressed • Irrelevant given higher payload of Ethernet frames?

21. Discussion Questions • Are there other opportunities for automotive cybersecurity enhancements that make use of parameter estimation or other probability-based methods? • How can suspension attacks be dangerous, even though the attacker is “weak”? • Are there other data sources on vehicles (current and future) that could leak internal state information, like how CAN messages leak data about ECU clocks? Can these sources be advantageous/detrimental to security and/or privacy?