Wanted: Protection From Intrusive Hacks for Connected Vehicles

An organization that has been instrumental in establishing best practices for security in cloud computing has issued a list of its recommendations for connected-vehicle security.

The Cloud Security Alliance yesterday published a 35-page report that describes the complex ecosystem required to support a connected vehicle -- which sometimes is a driverless vehicle -- and how to secure it against possible vectors of attack. The report was written by the alliance's Internet of Things Working Group and identifies 20 different potential attack vectors.

The need for a review of connected-vehicle security is obvious. On July 21, 2015, Wired ran the story, Hackers Remotely Kill A Jeep on the Highway – With Me In It.

Then on Sept. 20, 2016, CNBC reported another incident, Chinese Company Hacks Tesla Car Remotely.

Earlier that year, the National Highway Traffic and Safety Administration, the FBI and the Department of Transportation issued a joint statement saying some threats had already been addressed but it was important to remain on guard for future and unanticipated vulnerabilities. It was headlined, Motor Vehicles Increasingly Vulnerable to Remote Exploits.

Want to learn more about connected vehicle security? See Cybersecurity Center of New Bipartisan Bill.

So what exactly would the Cloud Security Alliance have auto manufacturers and consumers do to contain the hacker threat? Among other things, the alliance wants consumers and manufacturers to be aware that the OBD-II connector, also known as the on-board diagnostic port, through which authorized maintenance technicians access a vehicle's sensors is one pathway to a vehicle's sensitive information. So is a USB port built into the dash. Other avenues include the WiFi, Bluetooth, or cellular communication connections, and infotainment devices.

In addition, consumers are using their onboard communication systems to connect to the Internet for services on the Web and soon, to such things as traffic management services that will become available through smart cities and other agencies.

As vehicles have gained more electronics, they've also become more dependent on the CAN bus, or the message bus that allows the devices to communicate with each other. This bus was designed as a closed network, which means it doesn't have security features. "An unauthorized party that gains access to the bus can block legitimate messages and transmit illegitimate ones," the authors warned.

Less threatening but still a potential access avenue is Amazon's Echo device with its Alexa voice-activated application. Alexa can tie into a vehicle to query it about the last trip the vehicle took, track its current location, and start the vehicle remotely.

One other thing: The widespread use of remote keyless entry means there's a possibility of an intruder planting a device near a vehicle to intercept the door opening code for later use when the owner is away. It's not clear whether this technique has been used but questions have been raised on why it couldn't be.

"The community must take a fresh look at the larger picture," said Brian Russell, chairman of the alliance's IoT Working Group and one of the authors, in the announcement of the report. The driving public must develop the designs and operations that "incorporate security throughout the development," he said. In addition to Russell, the report was authored by working group members Aaron Guzman, Paul Lanois and Drew Van Duren.

Here are some of the specific recommendations of the group:

The Department of Transportation has issued the Connected Vehicle Reference Implementation Architecture. It contains four views of the vehicle connection process – enterprise, functional, physical and communications -- and applies security to each. Start with this reference, the CSA authors urged. Under it, when one vehicle communicates with another or with a nearby cell tower or with other communications infrastructure in its proximity, it does so through a wireless protocol, Dedicated Short Range Communication. DSRC requires that each message be given a digital certificate as a guarantee against undetected tampering.

Manufacturers need to understand the risks and avoid compromise of the means of access they provide. Has each manufacturer "accounted for the ramifications of inserting a third party device into the OBD-II port…" Could a compromised third party device result in spoofed vehicle-to-vehicle messages being transmitted, the authors asked. The manufacturers need to take appropriate steps to prevent such a possibility.

Likewise, the makers of smart phone apps for connected vehicles need to vouch for the secure operations of their applications. The writers of Web-based applications or smart city applications will likewise have to insure they have composed secure software. Cloud-based applications will need to use secure APIs.

Encryption will frequently be a feature of communications and applications for connected vehicles, and therefore, correct cryptographic key controls must be followed.

Safety critical features such as braking or lane detection systems should be maintained on CAN buses that are separate from non-critical systems, such as automated door opening.

Updates for the software used by the electronic components in cars should be updated with a minimum of inconvenience to the consumer. At the same time, those updates will need to occur within a protection update lifecycle to avoid tampering.

Non-critical features of the connected vehicle, such as keyless entry, may have unprotected interfaces and these interfaces must be given filters to detect messages that differ from those acceptable to the function of the interface.

When a third party device is accessing the vehicle's Bluetooth system, it should be using the mutual authentication available through Bluetooth Low Energy that allow mutual recognition without allowing in intruders.