Posted by Robert Vamosi on June 19, 2017
Adding communications to cars and the transportation infrastructure provides cool new services (e.g., safe driving, faster transit times, etc.). From a security perspective, it also widens the threat landscape. Potentially, a bad actor sitting along the roadside with wireless access might be able to mess with the internal workings of your car or the traffic lights ahead.
Automakers today are designing cars that will become available to consumers five to ten years from now. These cars must communicate with other vehicles (i.e., vehicle-to-vehicle or V2V communication). They must also communicate with certain infrastructures such as traffic lights and speed-reduced construction zones (i.e., vehicle to infrastructure or V2I communication). This challenges an industry that is new to software to find and adopt technologies that will be not only safe but secure.
We’re already witnessing a rush toward the future. In 2015, researcher Cesar Cerrudo demonstrated at DEF CON 22 that thousands of wireless traffic sensors in the ground (in hundreds of cities around the world) have significant vulnerabilities. The sensors use a 802.15.4 system-on-chip 2.4-GHz transceiver alone with dedicated access points and receivers on nearby utility poles. The problems that Cerrudo identifies in his presentation involve the ZigBee protocol, specifically lack of encryption and authentication. These devices are only available for updating by digging the sensors out of the asphalt.
Access to a few traffic sensors might not seem bad on its own. What if an attacker changes a few traffic lights to red, stopping traffic in all directions. This happened in Los Angeles in 2009. Using different technology and by targeting just a few intersections, two city traffic engineers, citing a labor dispute, shut down four strategic intersections for several hours. This created a state of gridlock lasting several days. Imagine a more coordinated attack and the consequences of that.
Not all early traffic automation efforts are flawed. In May 2017, the state of Nevada announced a program with the Nevada Center for Advanced Mobility (Nevada CAM) and Nexar to implement V2V throughout the state. They cited the need for greater vehicular and pedestrian safety as well as the desire to accelerate the future of connected cars. This also acts as a way to test how connected infrastructures might work in the future.
Using mobile apps, smartphone dash cams, and cellular technology, the Nevada system is designed to reduce CO2 emissions and fuel waste by rerouting traffic whenever possible. It also alerts drivers to hazardous conditions beyond the line of sight, reducing collisions. This effort uses existing mobile technology as a short-term fix. What happens when cars come equipped with embedded V2V systems?
Just as individual parts of the car are made by a physical supply chain of Tier One and Tier Two manufacturers, the software in a car is an assemblage of components. This cyber supply chain comes together from a variety of sources, including free and open source software. “The problem is when people buy a car, they think ‘Oh, I’m buying a Toyota,’ but what they’re really buying is parts from 100 different suppliers all cobbled together,” Nidhi Kalra, a Senior Information Scientist at the RAND Corporation, told the New York Times. “Cybersecurity cannot be applied on top of everything else. It needs to be based in the design of the vehicle and embedded throughout the entire supply chain.”
Automakers starting today to design the cars of tomorrow should use architecture design and threat modeling to map out their future use of software. These processes identify known risks and help software engineers navigate these during development. The various third-party software packages they are using, for example, should always be tested with software composition analysis tools to make sure they are using the latest and most secure version. A recent report from Synopsys shows that up to 50% of the software components in use in applications are outdated, subject to known vulnerabilities, and can be updated to newer, patched versions.
As mentioned, apart from the software within the car, there are concerns around the quality and the security of the communications between cars and with the roadways themselves. Because the vehicles are moving, sometimes in opposite directions, there is no time for the traditional wireless authentication and association handshake.
A new IEEE 802 protocol, 802.11p, dispenses with that. It provides immediate communication as soon as the vehicle comes within range. It passes temporary tokens to access points to provide smooth and relatively anonymous transitions. 802.11p is designed for dedicated short-range communications (DSRC). Testing by the National Highway Traffic Safety Administration (NHTSA) for DSRC systems began in the summer of 2015. When approved, protocols such as 802.11p will be used for toll collection, safety services, as well as communications between cars.
The immaturity of this protocol and others, however, creates the potential for implementation errors. Here, fuzz testing becomes important. Fuzz testing creates malformed input to identify conditions under which the application can fail and therefore allow bad actors the opportunity for remote code execution.
Cities themselves need software quality and security as well. Imagine an emergency vehicle automatically commanding connected cars to pull to the side and allow access in rush hour traffic. Or, a city bus interacting with traffic lights to give it priority through intersections, saving time and fuel. Now imagine a bad actor introducing grid lock with unauthenticated fake information.
In 2007, researchers at CanSecWest demonstrated how roadside hackers could compromise an in-vehicle GPS system using a ten-year-old protocol. Here, the RDS-TMC signal was intended for GPS traffic updates, but it was not secured with authentication. The researchers had their fun by injecting messages claiming false road closures, even a fake terrorist attack. Similar exploits will be possible as smart city infrastructures roll out, especially those built on older, less secure protocols.
Fortunately, there are initiatives within the auto industry (among others, SAE is leading this) and within city governments (such as the 2015 Obama administration “Smart Cities” Initiative) to not only roll out more transportation connectivity, but to do so responsibility and securely.
Of course, there will be hiccups. There will also be a desire—usually for cost reasons—to rely upon older, existing technologies often not intended for their new purposes. Hopefully the disclosures of responsible research can identify these early. The idea is that by introducing security early into the connectivity discussions, the potential security nightmares will be largely avoided.