For automakers, addressing cyber-security vulnerabilities in autonomous cars is Job 1.
Major auto manufacturers, high-tech companies, and startups whose names we’re not familiar with all are putting in overtime trying to solve an unprecedented problem accompany in development of the self-driving car: cyber-security holes that could lead to potentially fatal safety issues.
To borrow a slogan used in 1982 by the Ford Motor Company, at the time discussing build quality: For the self-driving car, maintaining the security and integrity of on-board systems is “Job 1.”
The potential danger was demonstrated in 2015 when, as part of a research initiative, two hackers remotely took control of a Jeep Cherokee. Afterward Chrysler issued a formal recall of 1.4 million vehicles that may have been affected by the hackable software vulnerability.
One of the central challenges in vehicle cyber-security is that the various electronic control units (ECUs—cars today have dozens of them) are connected by means of an internal network. So if hackers manage to gain access to a vulnerable ECU (say, the infotainment system), there is concern they may be able to take control of ECUs managing the engine or brakes.
There are 15 main hackable points in the next-generation car.
Earlier this week, the French company Vedecom Tech—a commercial subsidiary of Vedecom Public Foundation, whose members include Renault, Peugeot, and Valeo—said the completely autonomous, self-driving vehicles (SAE Level 5) it plans to launch for commercial use in 2017 and 2018 in municipalities in France, Germany, Italy, Portugal and the Netherlands would represent the first cyberattack-secured, commercially-available automobiles.
Vedecom will be using Israeli startup Karamba Security’s Carwall software to protect the cars’ ECUs against hacking. Karamba said its security tool is OS- and hardware-agnostic and can run on every ECU, without requiring any changes or upgrades to the ECU’s software or hardware. The company further noted that it operates reliably on the ECU without interfering with any of its other functions.
Software from Karamba Security hardens the ECUs of this autonomous car.
Carwall’s patent-pending software is embedded during the ECU’s software build process. It automatically learns the factory settings, which are the legitimate programs, scripts, and function-calling sequences car manufacturers and tier-one system providers intend to run in the car.
Carwall then creates a control flow graph of all acceptable function call paths showing the calling relationship within a computer program. It then forms a security policy that detects and prevents any deviation from those settings. All detection and prevention decisions are made locally.
When a function call is made, Carwall checks it, in runtime, against the function call map it created during the build process. If the function call hasn’t followed a legitimate path, Carwall will not let it execute, since a hacker may have infiltrated a process in the ECU’s memory.
Because Carwall seals the ECU’s software, security bugs contained in that code are also hardened, so they can’t be exploited to infiltrate the car’s safety systems. No malware updates are required, and the ECU is said to be fully capable of protecting itself against potential hacks at all times without any required external connectivity. Karamba Security further claimed there should be no false positives that mistakenly block legitimate vehicle commands.
In the background of cybersecurity issues is the question of what role (if any) government should play in regulating self-driving cars. Most companies, like people, don’t like it when government decides to micromanage things. Nevertheless, the regulations game appears to be heating up.
Last week the U.S. Senate Commerce, Science, and Transportation Committee released bipartisan principals for self-driving vehicle legislation. Authored by U.S. Senators John Thune (R-S.D.), Gary Peters (D-Mich.), and Bill Nelson (D-Fla) these principles state that any proposed legislation must:
- Consider both the near-term and long-term regulatory oversight of these vehicles, recognizing that new safety standards governing self-driving vehicles should eventually be set.
- Allow the life-saving safety benefits of self-driving vehicle technology to move forward as new standards development is underway.
- Find ways to preserve and improve safety while addressing incompatibility with old rules that were not written with self-driving vehicles in mind.
- Be technology neutral and avoid favoring the business models of some developers of self-driving vehicles over others.
- Clarify the responsibilities of federal and state regulators to protect the public and prevent conflicting laws and rules from stifling this new technology.
- Address the connectivity of self-driving vehicles and potential cybersecurity vulnerabilities before they compromise safety.
- Review consumer education models for self-driving vehicles and address how companies can inform the public on what self-driving vehicles can and cannot do based on their level of automation and their individual capabilities.
Eighteen states and Washington D.C. have passed legislation related to autonomous vehicles. The legislation ranges from creating a committee to study self-driving cars (Alabama) to letting fully autonomous vehicles on the road without a driver (Florida).
Given that self-driving cars collect large amounts of data, there’s also government anxiety about privacy and how the data will be stored and used. But the main point of concern remains: Unless self-driving vehicles are proven to be highly secure against cyberattacks, many other states will attempt to regulate their development.
Uncle Sam will, too. (content credit to Murray Slovick, June, 29, 2017, electronicdesign.com )