Connected cars and automotive software: At the intersection of safe and secure
2015 in the auto industry will be remembered as a year of significant achievements for early; one that saw major tech companies jockey for position within infot ; and advances in , for better or worse.
However, 2015 will also go down with a level of infamy, as white hat hackers demonstrated security vulnerabilities associated with our increasingly connected cars. The Jeep hack popularized by an article in WIRED Magazine prompted Chrysler to recall 1.4 million vehicles earlier this year, each of which came with a price tag of around $100, according to Egil Juliussen, PhD, Senior Director and Analyst for Automotive Technology at research firm IHS. That $140 million “really puts a stake in the ground of how much it costs,” Juliussen says, and with the number of cars connected via some combination of smartphone integration and embedded telematics growing from 13.8 million units sold in 2013 to a projected 82.6 million in 2022, the stakes are getting higher.
A brief history of in-vehicle networks
The primary area of concern today for automotive security is the ability to access in-vehicle networks that are often based on buses such as CAN, LIN, and FlexRay. Historically these buses have been protected by means of isolation, with the primary mode of entry being the ODB-II port designed as a plug-in for environmental testing scan tools. As a result, these wired networks were primarily susceptible only to wired hacks.
But the growing importance of software and advent of the Internet of Things (IoT) now offer what Andrew Girson, CEO of the wireless interfaces that permit access to the networks of modern vehicles that represent “things” on the IoT, but while the “Internet provides a standard for communications,” Randy Field, Director of Consulting and Chief IoT Architect at says it is “inadequate for some automotive software” in subsystems such as infotainment, powertrain, chassis/comfort, and active and passive safety systems.calls “a uniquely-zero-weight way for carmakers to add new features to vehicles, including improvements relating to accident reduction and better fuel economy.” This has prompted the introduction of
“Prior to introducing OTA or wireless communications, security concerns were limited to scan tools that access the OBD-II port,” Field says. ”OEMs encrypt codes for safety systems making it difficult for third parties to develop aftermarket products and services. Authorized dealers are provided with encryption software to read fault codes for repair.
“Today, wireless communication allows access to encrypted codes by wireless scanners,” Field continues. “Since wireless communications operate over standard networks like CDMA, 4G-LTE, and GSM, the IT community and carriers must work together to develop best practices. It is too large of a task for each automotive OEM to develop their own. The National Highway Transportation Safety Administration (NTHSA) report number DOT HS 812 075 titled “A Summary of Cybersecurity Best Practices” created an infographic for recommended cybersecurity best practices.
The full report can be downloaded from.
At the intersection of safe and secure
But placing the onus of secure communications on large tech companies with knowledge of the major systems involved in end-to-end connected vehicle architectures still leaves automotive engineers tasked with developing systems that are both safe and secure in no man’s land. As in-vehicle networks become increasingly critical for automaker roadmaps, “designers of in-vehicle networks should be ever vigilant against the threat of denial-of-service, packet replay, and/or man-in-the-middle attacks via an insecure network access point,” Girson says, using “software reliability best practices [that] improve both safety and security.” While he cautions “computer systems that are safe may not be secure and vice versa,” Girson suggests that “it’s useful to consider that any undesirable behavior that an attacker’s malicious code could cause could also occur via software malfunction.” He therefore prescribes three system-level approaches for improving safety and security:
- All software must be presumed to fail occasionally, and the surrounding electro-mechanical components thus designed to detect, contain, and recover such faults. For example, engine control software should not generally hold the throttle open wide when the brake is pressed. Such a misbehavior is easily detected and contained via an electro-mechanical throttle versus a brake sanity check.
- It is valuable for both safety and security to be able to somehow authenticate commands from the driver. That is, if the instruction to resume an earlier cruise control is simply a network packet, how can recipient nodes be sure it was the driver who requested this? With respect to cruise control switch design this is, in theory a solved problem involving button press de-bouncing and redundant circuitry.
- Drivers should be provided mechanisms to quickly resolve undesired vehicle behaviors. One simple suggestion is that activating the emergency brake provides an electrical signal that the whole network continuously listens for and responds to by making the system safer.
This final point is especially crucial in the move towards self-driving cars, Girson adds.
Risk assessment meets automotive innovation
The progression from isolated automobiles to interconnected systems comprised of vehicles and supporting infrastructure will require the participation from every sector of the technology industry as attack vectors rise. Collaboration has begun through forums such as theas value propositions are defined and risks assessed in an automotive environment ripe for innovation.
“has developed truck caravan technology that can save hundreds of millions of dollars in fuel cost by creating a virtual train,” Field says. “Hacking into this system while 10 tractor-trailers are traveling down the highway in close proximity and traffic at 70 mph would be similar to launching 10 missiles.
“Much like Target’s hack through a vendor’s portal, the proliferation of IoT devices by small companies creates new risks,” Field continues. “From inception, it took 20 years for the OBD-II standard to become mandatory. Innovation is advancing at an unprecedented pace creating new areas prone to cybersecurity attacks. The latest risk is from unregulated IoT edge devices.”