Active regulations are written broadly to safeguard personal and proprietary data from intrusion. The details and documentation are left to self-regulation, requiring private enterprise investment in developing and executing a compliance plan – an honor system to reduce risk of liability. This requires tedious analysis and planning, in addition to imagining possible scenarios resulting from data conflicts and failures and cyber attack. This runs counter to the automotive business model of cost-savings until field issues and public awareness of vulnerabilities force increased investment. Therefore, security experts have taken on the mission of conducting their own security audits by hacking into cars and documenting the vulnerabilities with proposed resolution.
In this automotive age of drive-by-wire systems, we drive around in powerful computers that are our cars. These computers apply modules that rely on an aging communications protocol called the Controller Area Network (CAN). So in light of today’s vision among automakers for design products with autonomous driving capabilities, assuming the computers are smarter than us drivers, is yesterday’s archaic CAN protocol vulnerable for cyber-attack? Will hackers prove to be smarter than the computers driving the cars?
Yes, and yes.
So then as technology and technical compliance grow increasingly complex, how will CAN protocol keep pace in safeguarding vehicle network functions from being compromised? Over the past several years, so called "white hat" hackers have presented the vulnerabilities to automakers, hoping that their findings will; 1- influence automotive software-engineering development and Electronic/Electrical physical-layer design; and 2- spur follow-on legislation and regulation to enforce the mitigation of these vulnerabilities by the automakers and the organizations that prescribe automotive standards.
CAN
The automotive industry adopted and required CAN protocol before service professionals began relying on wireless networking protocol for vehicle diagnostics and service/repair and long before consumers embraced options for on-board wi-fi-based infotainment and utility bells and whistles. In 1983, Robert Bosch introduced the CAN vehicle bus protocol for multiplex communication between physical layer modules. When the protocol was officially accepted as an industry standard at Detroit’s 1986 Society of Automotive Engineers (SAE) Conference, CAN became one of the accepted protocols used for On-board Diagnostics (OBD). In 1996, industry regulators prescribed the CAN-based, OBD-II standard (J-1962 diagnostics interface) as required for all gasoline engine applications for cars and trucks in the United States; and in 2004, the standard (J-1979 diagnostics interface) became mandatory for all diesel cars and trucks.
Because it is low-cost, lightweight, and extensible for interoperability, the 30-plus-year old CAN is here to stay; therefore, any security resolution to prevent cyberattack must assume CAN as the on-board communication platform. Though CAN was developed long before the emergence of the Web and wireless networking protocols, automotive system designers continue to rely on the CAN platform as integrated with on-board Wi-Fi, cellular connectivity, Bluetooth pairing, and, alas, intrusive, or “smart” autonomous driving facility. So if computers are driving the car, how can system designers protect the CAN from cyberattack? Or does the “security by obscurity” argument hold water when it comes to nefarious players hacking into a vehicle communications network to, let's say, throw a driver’s car into Limp mode ... or disable the ABS?
Legislation
The Digital Millennium Copyright Act (DMCA), signed by President Clinton in 1998, legally prohibited car hacking. Intended to protect proprietary rights of software publishers from reverse-engineering, the DMCA also prohibited hacking for academic research. In 2015, the U.S. Copyright Office backed legislation that allowed DMCA “good faith” exemptions for research and for promoting the public good, which took effect in October 2016.
The bipartisan SPY Act was drafted during the Obama administration and introduced in the House January 25, 2017 (sponsored by Rep. Ted Lieu - D-CA and Rep. Joe Wilson - R-SC) as a push on the National Highway Traffic Safety Administration (NHTSA) to protect drivers against vehicle cyberattacks and as an authority directing federal studies to discern the proper defenses in vehicle systems against hackers. The Act remains pending during this Trump administration. While making abstract statements about making the nation safe, Trump also presents a perhaps conflicting objective to reduce regulation in commercial industry. (Track the bill’s progress here: https://www.govtrack.us/congress/bills/115/s680.)
Active regulations are written broadly to safeguard personal and proprietary data from intrusion. The details and documentation are left to self-regulation, requiring private enterprise investment in developing and executing a compliance plan – an honor system to reduce risk of liability. This requires tedious analysis and planning, in addition to imagining possible scenarios resulting from data conflicts and failures and cyberattack. This runs counter to the automotive business model of cost-savings until field issues and public awareness of vulnerabilities force increased investment. Therefore, security experts have taken on the mission of conducting their own security audits by hacking into cars and documenting the vulnerabilities with proposed resolution.
‘White Hat’ Hacking
In 2011, researchers from the University of Washington and University of California-San Diego hacked into a vehicle CAN via several vectors, including the technician wireless/wired scantools, a vehicle communication interface (VCI) (or “pass-through” device), CD player, Bluetooth pairing, and cellular radio. In 2015, researchers Charlie Miller and Chris Valasek hacked into an unaltered 2014 Jeep Cherokee via Sprint cellular interface with the onboard Uconnect infotainment system, allowing them to control the vehicle’s steering, transmission, and brakes. In 2016, Keen Security Lab researchers hacked a Tesla Model S wirelessly via a “malicious Wi-Fi hotspot,” controlling the vehicle’s integrated Web browser.
In 2012, academic researchers in England and the Netherlands exposed a flaw in engine immobilizer systems of vehicles from different manufacturers and expressed intent to publicly disclose the discovery so that manufacturers will eliminate the vulnerability. Among the manufacturers was Volkswagen, which filed a lawsuit to keep the issue undisclosed. After years of litigation and a ruling in favor of the manufacturer, Volkswagen, in 2015, allowed the publication of a redacted version of the findings.
Critical Security Controls
Assuming that CAN is indeed here to stay, developers would conclude that the surest way to protect drivers from cyberattack would be to properly authenticate device access into the CAN bus, i.e. message encryption to prevent intruders from modifying or reverse-engineering CAN messages.
According to Roderick H. Currie in his whitepaper “Hacking the CAN Bus: Basic Manipulation of a Modern Automobile Through CAN Bus Reverse Engineering,” CAN bus vulnerabilities are numerous. I understood the whitepaper as Currie shooting a flare, warning that zooming into a vision for fully autonomous driving could be putting the shiny new wagon ahead of the old gray mare of a horse that is CAN.
Currie warns, “What is particularly alarming about this research is that the same network bus that was exploited to manipulate the gauge cluster also hosts communications for the engine, transmission, brakes, and steering. On a newer, more connected vehicle with a greater amount of computerization, the same techniques … could be used to take full control of the vehicle and create a dangerous, potentially deadly situation.”
According to Currie, there are at least 20 Critical Security Controls (CSCs) to apply; in another whitepaper, he stresses the following as the “top five”:
- Document all authorized and unauthorized devices. To prohibit certain devices, it must be clear what devices are allowed to begin defining a baseline security-control strategy. This is a reference for software developers for configuring CAN physical-layer modules (with unique identifiers) to accept a limited inventory of controllers. Further, CAN identification should require encryption in transit.
- Develop secure configurations for hardware and software. This implies configuring a central control unit to manage CAN configuration according to a robust change-control process, thereby making CAN architecture less open and more secure. (This is similar to the role of the Automotive Service Bus for seeing all controllers at once for troubleshooting a system and servicing a particular controller.)
- Limit and control network ports, protocols, and services. This is ensuring that ports are not left open or services running, thereby exposing the system to intrusion.
- Defend the network boundary. While a decade ago, the only external network interface was the OBD-II port, today’s vehicles have a diverse attack surface of external interfaces, including Wi-Fi, Bluetooth, GPS, and cellular connections. Therefore, these multiple interfaces require multiple layers of boundary defense – firewalls that are hardware- and software-based.
- Control Access on a Need-to-Know Basis. Identify security- and safety-critical assets, classify them for sensitivity, and secure the controllers accordingly. This will remove the scenario of the hacker only requiring remote access to any point in the vehicle network to manipulate critical functions.
“Ironically, it is the newer and more ‘advanced’ cars that offer the most hacking potential," says Currie, "as they have greater interconnectivity between the various Electronic Control Units (ECUs) and a wider overall attack surface.”
References
“Adventures in Automotive Networks and Control Units” by Charlie Miller and Chris Valasek, 2014 - http://illmatics.com/car_hacking.pdf
“The Automotive Top 5: Applying the Critical Controls to the Modern Automobile” by Roderick Curie, February 2016 - https://www.sans.org/reading-room/whitepapers/critical/automotive-top-5-applying-critical-controls-modern-automobile-36862
“Complying with Data Protection Law in a Changing World” by Benjamin Wright, June 2017: - http://www.sans.org/reading-room/whitepapers/analyst/complying-data-protection-law-changing-world-378
“Comprehensive Experimental Analyses of Automotive Attack Surfaces,” by Stephen Checkoway, Damon McCoy, et al., August 2011 - http://www.autosec.org/pubs/cars-usenixsec2011.pdf
“Developments in Car Hacking” by Roderick Currie, December 2015 - https://www.sans.org/reading-room/whitepapers/ICS/developments-car-hacking-36607
“Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobilizer” by Roel Verdult, Flavio D. Garcia, and Baris Ege, 2015 -- https://www.usenix.org/conference/usenixsecurity13/dismantling-megamos-crypto-wirelessly-lockpicking-vehicle-immobilizer
"Hackers were able to remotely control a moving Tesla Model S" by Andrew Dalton in Engadget, September 20, 2016 - https://www.engadget.com/2016/09/20/tesla-model-s-remote-hack-keen-security/
“Hacking the CAN Bus: Basic Manipulation of a Modern Automobile Through CAN Bus Reverse Engineering” by Roderick Currie, May 2017 -- http://www.sans.org/reading-room/whitepapers/awareness/hacking-bus-basic-manipulation-modern-automobile-through-bus-reverse-engineering-37825
“The Jeep Hackers Are Back to Prove Car Hacking Can Get Much Worse” by Andy Greenberg in Wired, August 2016 - https://www.wired.com/2016/08/jeephackersreturnhighspeedsteeringaccelerationhacks/
“New Bipartisan SPY Act Pushes NHTSA on Automotive Cyberthreats” by Pete Bigelow in Car and Driver, January 27, 2017 - http://blog.caranddriver.com/new-bipartisan-spy-act-pushes-nhtsa-on-automotive-cyberthreats/
"A New Wireless Hack Can Unlock 100 Million Volkswagens" by Andy Greenberg in Wired, August 10, 2016 - https://www.wired.com/2016/08/oh-good-new-hack-can-unlock-100-million-volkswagens/
© 2017, Powerplay Communications