Published on 05/14/2017 | Strategy
Why to take a value-chain approach to connected car security
A gulf exists within the connected car value chain when it comes to connected car security, as revealed by automaker responses to recent high-profile connected vehicle hacks. Consider the opposite responses taken by Tesla and Chrysler Fiat when their vehicles were hacked. Tesla mitigated the hack by promptly pushing an over-the-air (OTA) update—done.
Chrysler’s solution requires physical software updates to 1.4 million vehicles—either at a dealership or via the owner downloading software to a USB drive and then installing it in the car. This process leaves Chrysler struggling with the cost, long timelines and non-compliance issues related to its recall.
Figure 1: Car Update Portal
Automakers Band Together for Car Security
These responses bring the difference between “traditional automotive” and “Silicon Valley” approaches to securing the connected car into sharp relief. Both companies faced the same problem —hacked—but only one completely solved it. Security solutions that bridge these two realms and bring them into alignment are clearly needed.
This is the goal of a new organization announced in August 2015 by the Alliance of Automobile Manufacturers (AAM). AAM is setting up an “Information Sharing and Analysis Center” (ISAC) which “will serve as a central hub for intelligence and analysis, providing timely sharing of cyber threat information and potential vulnerabilities in motor vehicle electronics or associated in–vehicle networks,” per AAM vice president for vehicle safety Rob Strassburger.
ISAC will serve as a clearinghouse and brain trust for securing the connected car and mitigating malware and other security threats. The AAM ISAC should be up and running before the end of 2015.
Connected Car Threats Arise Across the Value Chain
While ISAC’s membership will initially be limited to auto manufacturers, AAM intends to expand the organization to include component suppliers, telecommunications providers and technology companies. This type of comprehensive approach to vehicle security is clearly needed, as security threats can arise at any step along the value chain—and it can be difficult to pin down who’s “responsible” for vehicle intrusions. In the case of the Jeep hack, Harmon is being sued over purported security defects in its infotainment head unit, while Fiat Chrysler pointed the finger at Sprint with assertions that the company’s cellular network is insecure.
Security threats can also be introduced through any physical connection, including the OBD-II port, USB ports and the EV charging port. Even aftermarket accessories can introduce security threats: Progressive Insurance’s “Snapshot” OBD-II driver monitoring device was recently hacked, allowing intruders access to a car’s drivetrain and brakes.
Layers of Connected Car Security
As the ISAC begins its work, participants will need to consider multiple layers of connected car security. These include:
In-Vehicle Proactive vs. Reactive Security Modes
Inside the vehicle, electronic control units (ECUs) must be secured using both proactive and reactive security measures. Proactive security monitors a vehicle’s CAN bus for unauthorized messages, such as reprogramming instructions sent to an ECU from a compromised/hacked ECU from which malicious code is trying to spread.
Cloud-based solutions that provide proactive vehicle security have started coming to market, in order effectively secure connected vehicles and enhance vehicle safety. One such platform is Movimento OTA, an over-the air programming and security platform for connected vehicles introduced last June at TU-Automotive Detroit.
Movimento’s connected car client sits within the car on one of the ECUs and monitors all of the messages passing though the CAN bus. When it sees an ECU reprogramming messages that did not originate from within the platform, the Movimento client stops them in transit and reports back to the Cloud which car and ECU were attacked—and by what.
Reactive security allows car owners and mechanics to change whatever software-controlled variables they want, within reason. Hobbyists trying to get that last ounce of performance can have at it —though certain changes that would cause the vehicle to malfunction may be blocked. Owner changes and preferences are logged under a reactive security scheme, so they can be rolled back in case of problems, and for diagnostic use when an owner brings a “tweaked” car in for service.
Data Security
In addition to securing data within a vehicle, data traveling to and from a vehicle must also be secured. This is one of many security defects found in the Progressive Snapshot: the device did not encrypt sensitive information about vehicle location and driver behavior before transmitting it over a cellular network—potentially leaving it vulnerable to being seen or stolen while in transit.
Data coming into the vehicle must be encrypted to prevent it from being tampered with during transmission. This data must also be validated as coming from a trusted source, and that trusted source also must be tightly secured. A quick way to infect millions of vehicles would be to invade the platform that updates the vehicles’ software and firmware.
Threats from Aftermarket Accessories
Security threats arising from Progressive’s Snapshot go beyond “in the clear” storage and transmission of sensitive driver data. Oddly, even though Snapshot is a purpose-built connected vehicle device, the Digital Bond Institute (DBI) found last June that Snapshot “was designed with no security features.” Per Dale Peterson, DBI Founder and CEO, “[Snapshot] wasn’t even based on basic security coding practices. It’s a house that has no doors, no windows and no fences, with valuables inside.”
The hackers who recently disabled the brakes of a Corvette by sending malicious code to its Snapshot did not discover and exploit a weakness in Snapshot’s security architecture. There was no security architecture to breach. Hopefully, the work that ISAC takes up will include security standards for aftermarket devices such as the Snapshot—or any other device that connects to a vehicle’s OBD-II port.
OTA vs. Plug-In OBD-II Software Updates
Lastly, how software updates are applied to connected cars presents another security risk: OTA updates (Figure 1) also completely eliminate the opportunity for malware to enter the vehicle through a physical connection. Physical connections create a channel for malware to enter any computer, including a connected car.
As long ago as May 2013 , it’s been public knowledge that cars can be hacked through an EV charging station—the last place an owner would expect a malware threat to arise. Malware can also be introduced to a vehicle through the USB and OBD-II ports.
ISAC should focus on the basics
Movimento applauds the AAM’s efforts to bring collaboration and transparency to securing the connected car, and looks forward to joining the ISAC as soon as membership opens to automotive technology providers. In the meantime, ISAC will be well-advised to focus on the basics: maintaining proactive and reactive security measures within a connected vehicle, securing data in the vehicle and in transit, developing security standards for all connected vehicle components including aftermarket accessories that have access to the CAN bus, and limiting the paths malicious code may take to enter a vehicle by requiring over-the-air software updates.
The original article is available here.
