Connected cars are moving past commonplace and becoming standard. According to data from Statista, by 2020 connected cars will account for 98% of the global car market, with 100% market saturation by 2025. That’s just six years from now. The implications for connectivity at this scale are immense, especially on the security infrastructure side.
Within the connected transportation ecosystem, the actual vehicles are the most visible part. But behind the scenes, the most important part of such an environment is the underlying electronic standards that make it possible. With any distributed and connected system you have to get everyone working on the same page. Connected cars are no exception; the engineers, auto manufacturers, maintenance personnel and regulators need to all be on the same technical page so they can work together seamlessly.
Making standards standard
There’s a precedent for useful and connective standards in the automotive industry. For example, there’s the on-board diagnostics II (OBD-II) standard, which became mandatory for all cars made or sold in the United States since 1996. This standard specifies the diagnostic connector (typically located near the driver’s left knee), its pinout, signaling protocols available and the messaging format. Vehicle parameters and guidance on encoding the data are also included.
The results of the OBD-II standard were and remain profound. Drivers were no longer tied to the dealer for repairs; they now had the flexibility to take their car to any experienced mechanic, at any repair shop, to have their car serviced and maintained using OBD-II standard diagnostic tools. Within IT there are analogous standards. For example, the standardization of the Transport Layer Security (TLS) protocol enables users of any browser — Chrome, Firefox, Safari, Edge, etc. — to reasonably expect that they can securely navigate to any webpage hosted by any webserver — Apache, NGINX, Tomcat, IIS, LiteSpeed, etc. — without worrying about compatibility.
Open standards are necessary for connected cars to provide enhanced safety and better use of data. Manufacturers, regulators and service providers need such standards to build vehicles independently yet still create interoperable products. The vehicles need to seamlessly and securely communicate with not only with each other, but with other elements in a smart city, regulatory agencies and other outside services.
How do we get these standards? It doesn’t require a lightbulb moment of discovery, but instead diligent and patient work. Teams of people will need to collaborate together in a similar fashion to the Internet Engineering Task Force (IETF), whose members generously donate large amounts of their time developing the standards that make the internet work.
Current vulnerabilities and potential safeguards
While there are stories of engineers hacking connected cars, it’s important to remember these attacks in non-lab conditions are statistically insignificant. There’s no epidemic of breaches, as we’re at the very nascent stages of the smart car era. This means the industry still has time to step back and assess. It’s during this period that the industry must get things right. This means working with the government and organizations such as the IETF and the Society of Automotive Engineers (SAE — whose J1939 standards collection defines the CAN bus). Academia needs to jump deeper into automotive IoT to help create meaningful and verifiable standards for connected vehicles. The connectivity, security, maintainability and reliability of the vehicles all warrant protection through smart design and universal standards. Without such agreement from manufacturers, subcontractors, OEM vendors and regulatory organizations, the connected car promise is no longer practical and certainly not economical for those involved.
There’s a convergence of operational technology (OT) and IT within the industry. We have OT-related technology such as the CAN bus, a standard allowing manufacturers to build vehicle control systems that enable microcontrollers and devices to communicate without a host computer. Cars are essentially moving industrial control systems, and the requirements for these types of systems are reliability and safety. Contrast that with IT, such as that found in mobile phones. Manufacturers can accept them to work flawlessly 96% of the time in exchange for occasional restarts and better graphics. Automakers can’t take that remaining 4% risk of brake or transmission failure.
Problems arise with current automotive manufacturing when they take shortcuts. For example, they might converge IT and OT onto a “super-bus” single network. IT must be open to communicate with the outside world. Consumers want apps such as Pandora or Waze within their cars. The problem is the open interface making the apps possible opens the system to bad actors. When IT and OT systems are converged, then the avenue of attack goes beyond audio controls and navigation into steering, braking or engine control.
Securing device-to-device communications and interoperability presents multiple challenges in the IoT environment. Without a prevailing standard for automotive security, many industry and technology experts struggle to navigate a variety of protocols, processes and compatibility issues. The auto industry outpaces many others in the IoT space with a comparatively high number of in-automobile devices (all requiring security technologies) that are now being connected. In cases where traditional encryption methods simply don’t fit well, such as public/private key certificate management between small components, a reliable lightweight commercial encryption mechanism is needed.
A non-PKI framework for exchanging strong symmetric encryption keys between devices (within the car), while also capable of scaling to cloud and global services levels, would be a real game-changing and disruptive technology that meets critical security needs head-on. Integrating scalable security systems in the automotive and telematics spaces is still a loosely defined practice, ready for a next-generation solution.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.