As the car becomes more connected, it faces security vulnerabilities, and although recognizing them is a start, the industry must be working on preventative solutions that can evolve with increasing challenges, according to Dr. Tao Zhang, Chief Scientist for Cisco Connected, at Cisco Systems.
Even at this early stage for the connected car, it is vulnerable to malware from public clouds, automakers, and other private clouds, such as businesses with which the motorist may be dealing. This may be less of an issue with simple browsing, as for weather reports. However, the OBD II connector under the dashboard is presently one of the input devices providing the greatest risk, Zhang said. At one time it was strictly a hard-wired connection from a scan tool, but today it accepts WiFi signals for convenience features as door-unlock plus remote diagnostics by car makers or even some aftermarket service information providers. Because OBD gets deep into all functional systems, the car is exposed.
The CAN bus has just basic integrity checking, no real security, Zhang said, because the messages are short and making them longer would slow down the network. The “rolling codes” to protect door-lock systems may seem secure, but they are not nearly as random as people think and can be penetrated, he added.
A related issue is the move to remotely reprogram computers, for if the car makers can do it, so could hackers, and their changes would not be good for the car or the driver.
What has held back the car makers—the need to maintain battery voltage for the length of an extensive reflash, would not bother a hacker looking to inject malware, Zhang observed. The ease of access for a hacker has been known for years, as aftermarket companies long have sold reflashing software to improve vehicle performance. The best known of the companies have been careful, writing their software to work outside the range of EPA regulations for emissions control tests.
With public signals, such as for “smart” traffic lights that communicate with cars, on the horizon, the public cloud will be a major source of vulnerabilities, Zhang told an audience at an SAE Congress technical session titled "Connected Car and Cyber Security." The move to V2V (vehicle to vehicle) communications opens up an obviously even more at-risk area, as malware may attack through all communications channels, he added.
Malware in a personal computer is an inconvenience if the files are backed up. Just take it in to a specialist and have it removed, or at worst redo the hard drive. With a car, the motorist suddenly encountering even something as simple as a radio blasting at full volume and an inability to turn it down or off can render the vehicle undrivable, said Zhang.
Long life for vehicle modules necessary
The electronics in cars pose a longevity problem, Zhang said. They have limited internal resources and must last a long time. Although people change personal computers every few years for faster, more capable processors, vehicle electronic control units usually are expected to last the life of the car.
At present, even with a data bus, individual modules need to be protected, and cars have dozens of them. Theoretically, a gateway to evaluate new software could be used, and although a change of one such “master” module as an upgrade might be possible, that would be the limit. And even if urgent, it might be difficult to even find owners to notify of the change, particularly if a car had been resold. Just as a limited number of recalls on other than brand-new vehicles are serviced by the dealers, Zhang noted.
Replacement parts pose a related problem. There might have to be configuration keys that would allow parts to interact with the rest of the system, and the parts would have to be programmed to the same level of security, a how-to-do question for aftermarket manufacturers. At present, many parts are programmed to match the performance of the OE part it is replacing, but equivalent security for aftermarket parts would be a new addition.
It might seem that encrypting of messages would provide secure connections, but all that does is handle the issue of confidentiality. “If malware has gotten in, you might just be encrypting it,” Zhang said, as he reviewed the limitations of present security systems that might be used.
Possible security approaches
If fixed designs are built in, they may require heavy onboard processing, require too large a database, raise trustworthiness issues if downloaded from the cloud, and create a need to determine what’s relevant to the car. And, of course, there is a cost to keep them up to date.
With a heuristic protection approach, there is even heavier processing needed, the programming itself is complex to implement and update over the life of the car.
Even a cloud-based system raises issues. There could easily be a communications overload imposed on the in-car hardware, with long delays for file execution. A continuous connection from the car to the cloud might be needed but would be impractical. The software still would have to determine the trustworthiness of threat messages and decide which malware it sees is relevant to the car.
Virtual private networks (VPNs) provide good security, but with millions of cars that might want to use them, Zhang said, they would be far too costly “unless we were smart about them.” The idea would be to incorporate ways to reduce the need for the VPN, turning it on only on an as-needed basis.
An onboard system with a major assist from a cloud-based “back end” is the likely near-future approach to connected-vehicle security, Zhang said. The car would have its onboard networks that would allow outside communication only through an onboard security gateway. That allows direct communication via local wireless, such as Bluetooth, and physical connections to the vehicle electronics, such as the OBD II connector. Other data transfer would go into a cloud-based security “back end,” which would provide the separation for connection to public, car maker, and other private clouds, including shopping sites.