1. Experimental Security Analysis of a Modern Automobile
Presented by
Gaurav Mastakar

2. Authors
Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, and Tadayoshi Kohno
Department of Computer Science and Engineering
University of Washington
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and Stefan Savage
Department of Computer Science and Engineering
University of California San Diego

3. Abstract Automobiles are monitored and controlled
Introduction of new potential risks
Demonstration of fragility of system structure
Electronic Control Unit (ECU)
Range of experiments performed
Possible to bypass network security
Composite attacks

4. Introduction Automobiles contains myriad of computers
Luxury sedan contains 100 MB binary code spread across computers
Safety the main concern
Onboard Diagnostics port
User-upgradable subsystems

5. Introduction (contn’d)
Telematics system by GM’s OnStar features
Integration of internal automotive subsystems with a remote command center via a wide- area cellular connection
Hughes Telematics App Store
Ford’s Sync Telematics system

6. Introduction (contn’d)
Experiments on two passenger cars
Test cars components to assess resilience
Demonstrate ability to control components
Combining these mount attacks
Evaluation of security properties of each component and analyze network substrate

7. Background 250 million automobiles in US
Automotive Embedded Systems: Self contained embedded systems called ECUs in 1970s
Integrated into cars functioning and diagnostics

8. Background (contn’d) ECU Coupling: complex interactions across ECUs
Electronic Stability Control (ESC): monitors wheel speed, steering angle, throttle position and accelerometers; modulates engine torque and wheel speed to increase traction
Antilock Breaking System (ABS)
Roll Stability Control (RSC): apply breaks, reduce throttle, modulate steering angle
Activity Cruise Control (ACC): scan road ahead and increase decrease throttle. Eg: Audi Q7
Also provide pre-crash features

9. Background (contn’d)
Luxury sedans even offer automated parallel parking features. eg: Lexus LS460
Electric driven vehicles require precise software control over power management and regenerative braking to achieve high efficiency, by a slew of emerging safety features
Eg: GM’s OnStar will offer integration with Twitter

10. Background (contn’d)
Car contains multiple buses (high-speed and low speed)
Buses are bridged to provide subtle interaction requirements
Eg: Central Locking System (CLS) controls power door locking mechanism
CLS must also be connected to safety critical systems

11. Background (contn’d) Telematics: automation in automobiles
GM’s OnStar: analyze OBD detect vehicle problems
ECUs monitor crash sensors; OnStar personnel to perform functions; to do so bridge all important buses, connect to Internet via Verizon’s digital cellular service

12. Related Work Framing the vehicle security and privacy problem space
Security problems of vehicle-to-vehicle systems
Tuner subculture

13. Threat Model What an attacker could do?
How an attacker could gain access?
1. Physical access: insert malicious component into cars internal network via OBD-II port
2. Via wireless interfaces: five kinds of digital radio interfaces accepting outside input; remotely compromise key ECUs in our car via externally-facing vulnerabilities, amplify the impact using the results in this paper, and ultimately monitor and control our car remotely over the Internet.

14. Experimental Environment
Two 2009 automobiles with electronically controlled components and telematics system
Two vehicles to allow differential testing and to validate the results were not tied to one car
Also purchased individual replacement ECUs via third-party dealers to allow additional testing.

16. Experimental Environment (contn’d)
Experiments with these cars—and their internal components—in three principal settings:
Bench
Stationary car
On the road

17. Experimental Environment (contn’d)
Bench
Extract hardware
Variant of CAN
protocol

18. Experimental Environment (contn’d)
Stationary car:
Used CAN-to-USB
interface
Atmel AT90CAN128
development board
with custom firmware

19. Experimental Environment (contn’d)

20. Experimental Environment (contn’d)
On the road:

22. Intra-Vehicle Network Security
Assess the security properties of CAN bus
A. CAN Bus: link layer data protocol used for diagnostics used by BMW, Ford, GM, Honda

23. Intra-Vehicle Network Security (contn’d)
CAN variant includes
Slight extensions to framing
Two separate physical layers
Gateway bridge is used to route data
Protocol standards define a range of services to be implemented by ECUs

24. Intra-Vehicle Network Security (contn’d)
B. CAN Security Challenges:
Broadcast Nature: Malicious component can snoop packets
Fragility to DoS: CAN has priority based arbitration scheme with states dominant or recessive
No Authenticator Fields: Any component can send CAN packet to any other component

25. Intra-Vehicle Network Security (contn’d)
Weak Access Control: Protocol standards specify a challenge response sequence to protect ECUs
Reflashing and memory protection:
Tester Capabilities: restricts access to DeviceControl services
Fixed challenge-response pairs are 16 bits
ECUs allow response attempt every 10 sec
Multiple ECUs can be cracked in parallel
Physically removing the component

26. Intra-Vehicle Network Security (contn’d)
ECU Firmware Updates and Open Diagnostic Control:
Software only upgrades to ECUs
As DeviceControl Service used in diagnosis of cars components, many attacks can be built on it

27. Intra-Vehicle Network Security (contn’d)
Deviation from Standards
Not all components follow standards
Disabling Communications: ECUs should reject “disable CAN communications”
Reflashing ECUs while driving: “The engine control module should reject a request to initiate a programming event if the engine were running.”
Could place ECM and TCM into reflashing mode

28. Intra-Vehicle Network Security (contn’d)
Noncompliant Access Control: Firmware and Updates: ECUs must be protected by challenge-response protocol
Telematics Unit connected to cars CAN buses use hardcoded challenge and response common to all units
can reflash the unit and can load our own code into telematics unit
Should deny rights to read sensitive memory areas

29. Intra-Vehicle Network Security (contn’d)
Standard states defining memory addresses that will not allow tester to read under any circumstances
But could read reflashing keys out of BCM
DeviceControl keys for ECM and TCM
Extract telematics units entire memory

30. Intra-Vehicle Network Security (contn’d)
Noncompliant Access Control: Device overrides:
DeviceControl service override state of components
ECUs should reject unsafe DeviceControl override requests
Certain requests succeeded without authenticating

31. Intra-Vehicle Network Security (contn’d)
Imperfect Network Segregation: standard states that gateways between the two networks must only be re-programmable from the high-speed network
2 ECUs on both buses and can bridge signals: BCM and Telematics unit which is not a gateway
Verified that we could bridge these networks by uploading code into telematics unit

32. Component Security A. Attack Methodology
1. Packet Sniffing and Targeted Probing:
Used CARSHARK to observe traffic on CAN buses
Combination of replay and informed probing

33. Component Security (contn’d)
2. Fuzzing:
Damage can be done by fuzzing of packets
DeviceControl allows testing devices to override normal output functionality of ECU
DeviceControl takes an argument called CPID
Eg. BCM
3. Reverse Engineering:
Dumped code via CAN ReadMemory service and used third party debugger (IDA pro)
Essential for attacks that require new functionality to be added

34. Component Security
B. Stationary Testing:

35. Component Security

36. Component Security

37. Component Security
1. Radio: completely control, disable user control and display arbitrary messages 2. Instrument Panel Cluster (IPC):

38. Component Security
3. Body Controller: control is split across low- speed and high-speed buses 4. Engine: attacks were found by fuzzing DeviceControl requests to the ECM Attack like disturb engine timing by resetting the learned crankshaft angle sensor error 5. Brakes: how to lock brakes without needing to unblock EBCM with its DeviceControl key 6. HVAC: control the cabin environment

39. Component Security
7. Generic DoS: disable communication of individual components on CAN bus C. Road Testing: car was controlled via a laptop running CARSHARK and connected to the CAN bus via the OBD-II port. Laptop controlled via wireless link to another laptop in chase car

40. Component Security
EBCM needed to be unblocked to issue DeviceControl packets
Able to release brakes and prevent from breaking
Able to continuously lock brakes unevenly
Road testing helped to completely characterize the brake behavior

41. Multi-Component Interactions
A. Composite Attacks:
1. Speedometer: display an arbitrary speed or an arbitrary offset of the current speed
intercepting speed update packets
implemented as a CARSHARK module and as custom firmware for the AVR-CAN board
tested by comparing displayed speed with actual speed

42. Multi-Component Interactions (contn’d)
2. Lights Out: disable interior and exterior lights
requires the lighting control system to be in the “automatic” setting
3. Self-Destruct: demo in which a 60-second count-down is displayed on the Driver
Information Center
Kills the engine and activates the door lock relay

43. Multi-Component Interactions (contn’d)
B. Bridging Internal CAN Networks
BCM regulates access between two buses
Telematics unit connected to both buses can be reprogrammed from device connected to low speed bus; acts as a bridge
any device attached to low speed bus can bypass BCM gateway

44. Multi-Component Interactions (contn’d)
C. Hosting Code; Wiping Code:
Implant malicious code within telematics unit
Complicating detection and forensic evaluations
Perform action and erase evidence
if attack code installed as per above method simply reboot

45. Discussion and Conclusions
1. Extent of damage: Didn’t anticipate that we would be able to directly manipulate safety critical ECUs or create unsafe conditions 2. Ease of attack: Automotive systems are fragile, simple fuzzing infrastructure 3. Unenforced Access Controls: could load firmware onto ECUs like Telematics unit and RCDLR without authentication; Critical ECUs respond to DeviceControl packets

46. Discussion and Conclusions (contn’d)
4. Attack Amplification:
Maliciously bridging high-speed and low- speed networks
Design code to erase evidence
Components designed to tolerate failures but tolerating attacks not part of design

47. Discussion and Conclusions (contn’d)
Future Work:
1. Diagnostic and Reflashing Services:
Lock-down capabilities
How could mechanics service and replace components
Reflashing commands should only be issued with validation
Physical access to car required before issuing dangerous commands

48. Discussion and Conclusions (contn’d)
2. Aftermarket Components:
Allow owners to connect external filtering device between untrusted component and vehicle bus
3. Detection versus Prevention:
if prevention is expensive, quick reversal is sufficient for certain class of vulnerabilities
4. Toward Security:
See what is feasible practically and compatible with interests of a broader set of stakeholders

49. Questions ?

50. THANK YOU !!