Presentation on theme: "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 computers?"— Presentation transcript:
What is…? What is a car? Why are there computers in cars? Why can something other than a car access these computers?
Not an Outline ● Internal Structure o ECUs o Controller Area Networks o Seed to Key Algorithms o 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 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 Vulnerabilities: ● All nodes see all traffic ● All nodes communicate all other nodes ● DoS-able ● No identifiers ● Firmware updates ● Weak access controls that aren’t used CAN Security
● 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 ECU ● Algorithms used to compute them are not stored in ECUs for “security” ● Return of challenge not always used Seed to Key Algorithms
● 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 DeviceControl
● 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 Attack Vectors
● 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-Moving Car Testing
● I.E. Moving ● Tested on ECUs that don’t affect the safety of the car or driver ● 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 Non-Stationary Car Testing
● 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 Issues
Future (to the paper) work Comprehensive Experimental Analyses of Automotive Attack Surfaces http://www.autosec.org/pubs/cars-usenixsec2011.pdf
[In] Conclusion Cars are insecure. You’re all engineers, fix it.