By Melissa Walsh

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”:

1. 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.
2. 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.)
3. 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.
4. 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.
5. 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.

In summary, securing the CAN against cyberattack requires strategic planning and structured documentation for supporting it. This should not be an after-thought; nor should documentation be developed in the 11th hour, such as immediately before an audit. The complexity of design ought to drive complexity of structure of supporting documentation, because as the computer takes more command of the helm, we drivers become more vulnerable to hacking.

​“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

By Melissa Walsh
​​
Developers and their OEM sugar daddies are rearing nascent autonomous vehicle technology as a prodigy in car culture. It is maturing and here to stay.

All of the players except Google X -- or the manufacturers who have been in the car-making business long before cruise-control was introduced -- have plotted autonomous vehicle rollout on an ADAS (Advanced Driver Assist Systems) continuum. OEM projections for roll-out of autonomous-driving vehicles are less of planning for a coming out ball and more of releasing autonomous driving snapshots from infancy through adolescence. When the driverless car will emerge as a fully autonomous, independent adult remains to be seen, but most OEMs are projecting their darling’s coming of age for the mid-2020s. In fact, Uber projects releasing a fleet of autonomous vehicles by 2030.

Anecdotally my perception is that consumer demand for driverless cars is tenuous, but I’m a middle-aged Gen-Xer who longs for the return of the carburetor in the NASCAR stockcar. And growing up watching the Jetsons, I thought there’d be stronger demand for flying cars. I'm certain though that the OEMs have market research data supporting their autonomous-driving business case.

OEMs claim that the demand for autonomous vehicles is largely based on statistics on the high rate of driver error leading to accidents; their business case therefore is rooted in safety. And with that, the shift in liability moves from driver to manufacturer. So what about the ROI? Functional Safety (FS) features and the reliability estimation and required system checks and redundancies that go with FS significantly impact program budgets.

Anyone close to the design and development of automotive powertrain systems should understand well how FS engineers and assessors have become critical partners in the automotive product lifecycle. As driver-controlled passive powertrain systems have evolved into driver-assisted active powertrain systems, so has design for safety moved from passive to active.

With projections for mature, fully autonomous vehicles on the roads, assistive driver (drive-by-wire) driving is on track to evolving into driverless (drive-by-machine) driving. Today’s automotive technology is firmly in the “driver assistive” phase, which includes active technologies of advanced driver assist systems (ADAS), such as adaptive cruise control, anti-lock braking, active stability control, driver drowsiness detection, and parking assistance, in addition to legacy passive safety features, such as airbags, seatbelts, and human factures-driven structural design. 

Yet our imaginations skirt off onto rabbit trails with the what-ifs. What if an autonomous vehicle can’t perceive the ambulance about to race through the red light? What if the “cloud” the vehicle depends on malfunctions and sensor inputs on traffic and road conditions are erroneous. How will an autonomous vehicle react to a deer running out into the road? After all, we consumers are already annoyed by our vehicle’s warning beeps when we back out of our unplowed, snowy driveway. The vehicle senses obstacle; we know that it’s merely a minor accumulation of light snowflakes that our AWD vehicle will have no problem driving over. We know that we are smarter than the vehicle we drive. Still, cars are becoming smarter.

The ISO 26262 Functional Safety standard was established in the context of hazard analysis and controllability for driver assistance active safety technologies and is relevant for autonomous braking, acceleration, and turning. But what about the addition of autonomously backing out of a parking spot, starting from a green light, pulling into a car wash, or dropping the kids off at school?

Functional Safety checks and redundancies are established in a Safety Case to ensure that operation is a correct response to input. Inputs from the human operator and inputs from the vehicle’s powertrain control bus E/E hardware components and software algorithms. What additional checks and redundancies are required once the human operator inputs are removed?

Likely, the brilliant folks in the automotive industry are mapping out resolutions to these concerns in a strategy that includes additional programmable logic controllers, ASICs, microprocessors, transmitters, actuators, and more intelligent sensors. Therefore, suppliers responding to RFQs to provide these components must be highly proficient in what the ISO 26262 standard and an OEM’s Safety Case prescribes.
​
It remains to be seen what consumers will pay not to drive their car and how profitable autonomous vehicles will be for OEMs given the heavy projections for cost in reliability analysis, functional safety development and certification, and liability the machine may incur if it is as prone to error leading accident as the human.
​
© 2016, Powerplay Communications