Car Hacking

Car Hacking
Patrick, James, Penny
What is…?
What is a car?
Why are there computers
in cars?
Why can something other
than a car access these
Not an Outline
● Internal Structure
Controller Area Networks
Seed to Key Algorithms
Device Control
● Exploits
o Testing Methodology
o Attack Strategies
o Attack Results
Why is car hacking bad?
Control car components remotely
Physical implications
Privacy concerns
You won’t know about it afterwards
Controller Area Network
● CAN: Controller Area Network
● ECU: Electronic Control Unit
o Car computers in general
● Comprised of 2 buses
o High speed bus: safety critical, more trusted
o Low speed bus: non-critical, convenience modules
● Required in all cars sold in US since 2008
CAN Security
CAN packets: header that says where the packet goes
● No addresses used
● All packets broadcast physically and logically to all nodes
● Each node decides if it should process the packet
All nodes see all traffic
All nodes communicate all other nodes
No identifiers
Firmware updates
Weak access controls that aren’t used
Seed to Key Algorithms
● Authentication method for sensitive operations
o One ECU sends the seed (the challenge)
o The other replies with the key
● Each ECU has its own seed and key
● Keys and seeds are fixed and stored in the memory of each
● Algorithms used to compute them are not stored in ECUs for
● Return of challenge not always used
● Essentially debuggers for cars
o Assists in diagnosis of a car’s components
o Examines state
o Manipulates state
● In operating systems debuggers are limited by access-control
● CANs do not have access-control
Testing Methodology
● Bench
o Testing individual ECUs
● Stationary Car
o Car on jacks
● Car in motion
o Professional driver, closed course.
o Do not attempt.
● CarShark
Attack Vectors
● Packet Sniffing and Target Probing
o Analyze packets with CarShark
o Only sees normal operations
● Fuzzing
o Send random or partially random packets
o Useful for system disruption
o Exploit the DeviceControl service
● Reverse-Engineering
o Dump assembly code & analyze
o Adding new functionality
Non-Moving Car Testing
● I.E. Stationary
● Tested on all ECUs in the car
● Radio
o First ECU tested, easiest to exploit
o Disable user control
o Display arbitrary messages and play arbitrary sounds
● Brakes
o Fuzzing showed how to lock individual brakes as well as sets
o DeviceControl Key not needed
Non-Stationary Car Testing
● I.E. Moving
● Tested on ECUs that don’t affect the safety of the car or
● Exploits were transmitted from a chase car
● Cancellation packet sent after exploit is verified
● Laptop pulled from port if anything goes wrong
o Car functions return to normal shortly after laptop is removed
● Only difference was EBCM
● Required (almost) physical access to car via
o OBD-II port
o Bluetooth
o Wireless Tire Pressure Sensors
● Given physical access an attacker could
o Cut breaks
o Set fire to car
o Place bomb in car
Future (to the paper) work
Comprehensive Experimental Analyses of Automotive Attack
[In] Conclusion
Cars are insecure.
You’re all engineers, fix it.
Too bad.
● Prevent reflashing
● Signed firmware updates
● Disallow 3rd party components

similar documents