Securing Your Largest USB-Connected Device: Your Car
Securing Your Largest USB-Connected Device: Your Car
BY Shomit Ghose, General Partner, ONSET Ventures
The biggest battle unfolding in the automobile industry is no longer between GM and Toyota, but between these auto industry behemoths of the past and the would-be auto industry behemoths of the future: Google, Apple, and a myriad of data-driven software start-ups. Just as your cell phone is no longer about the physical device itself but about the applications and data flowing through it, your automobile is about to undergo the same transition. This marks a major opportunity for software technologists and start-up investors alike.
The connected car market is forecast to be over $40 billion in size within the next two years. But whether it’s a connected car, a self-driving car, a Zipcar or an Uber, there’s a fundamental shift occurring in the auto industry, and it’s 100% toward software technology and the use of (really) Big Data.
The transition from car-as-your-largest-mechanical-device to car-as-your-largest-computing-device is already well underway and opens an entire new universe of opportunity for the software industry. But given that automobiles are firmly embedded in the physical world alongside us – where they are capable of doing us both virtual harm and physical harm – the issues of information security, privacy and reliability are paramount.
Automobiles present a worst-case scenario in the number of attack surfaces they bring, with:
- Up to 100 million lines of source code in a typical luxury sedan;
- 50-70 electronic control units (ECUs), each acting as an independent, network-connected computer;
- ECU interconnection via multiple, shared, publish/subscribe-based Controller Area Network (CAN) buses;
- Multiple points of ingress into the CAN bus via Bluetooth, WiFi, cellular and satellite navigation networks;
- Electronic access via the On-Board Diagnostics (OBD) II port that is physically accessible to anyone in temporary custody of your car.
While the attack surface is large, it promises to get ever larger as an increasing number of wireless interfaces for vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I, V2X), and vehicle-to-Internet-of-Things (V2IoT) communications are brought online. As well, both auto manufacturers and software companies continue to provide interfaces – aka. threat vectors – into automobiles, and ultimately into the ECUs on the CAN bus: Apple’s Car Play, Android Auto, GM’s OnStar, Ford’s Sync, Chrysler’s UConnect, Lexus’ Enform, BMW’s Connected Drive all serve as examples.
Automobile manufacturing is a distributed process, with many suppliers contributing components to the fully-integrated whole. But while an open architecture may be desirable for the mechanical integration of a car, it opens Pandora’s Box for a vehicle’s software integration. Data and software provide the underpinning of much of a car’s functionality, and these functions – automatic parallel parking, roll stability control, anti-lock braking, the infotainment system, the instrument panel cluster – require the integration and cooperation of multiple ECUs. But infiltration of any single ECU can afford access to other ECUs, thereby compromising the safety of the vehicle, its occupants, and their data. In short, an automobile is a fully-networked, 3,500-pound, application software platform on wheels, but without commensurate information security measures.
The connected car will be the next great platform for data-driven applications, supplanting the smart phone, and giving rise to many new business models. For example, in a world where Google or Ford knows exactly how and when you drive your car, why buy insurance from a traditional auto insurance company who can only guess at your risk, versus buying it in real-time from Google or Ford directly?
Enabling these new business models requires resolving a whole host of technical and policy issues: While the NHTSA may certify the mechanical worthiness of a manufactured automobile, will they do so too for the constantly evolving and updating (“driver update” redefined!) software in your car? Is your local mechanic qualified to keep your car’s software up-to-date and bug-free? Want to cheat on your emissions test?? There’s an app for that!
The volume of potential security events for the connected car far exceeds the volume for “traditional” fraud events in the financial sector. Hackers would be capable of shutting off a car’s lights and brakes while driving at night, displaying incorrect speedometer readings, locking or unlocking the doors, or stopping the engine entirely. As well, hackers could exfiltrate private data from a connected car: location, in-vehicle conversations, addresses from the navigation system, vehicle maintenance logs, and financial information used to pay tolls or purchase entertainment content.
Needless to say, these risks, particularly those related to physical safety, present an unprecedented financial liability to auto manufacturers and software vendors alike, with no previous analogue in the world of traditional computing. As a consequence, the connected car industry’s most critical need lies in the area of security, and it is this area that presents the broadest and most compelling commercial opportunities.
For software entrepreneurs, or for start-up investors like me, two technology areas may hold the most promise for helping to secure the connected car:
- Continuous authentication;
- Overlay networks.
With a connected car, a constant connection to the Internet backbone is never a given. There can be no reliance on security patches or virus definition updates delivered wirelessly. Nor will it be practical to clog wireless networks with constant, two-way traffic between tens of millions of connected cars and the Cloud; ideally, security events must be resolved autonomously at the network’s edge.
With these constraints in mind, connected car security might best be powered by next-generation unsupervised machine learning techniques to provide “continuous authentication”. Specifically, the detection and isolation of anomalous network behavior in real-time on the vehicle itself. Of course, compounding the technical challenge (think Time Sensitive Networking as applied to control systems) any on-board security measures employed must not introduce latency that delays application of your connected car’s brakes!
The other area of promise is in overlay networks to provide software-defined perimeters (SDPs) on and around the dozens of ECUs that currently govern every aspect of a car’s operation. Heretofore, communication between ECUs on the CAN bus has not been well regulated, leading to much-publicized hacks that have compromised vehicle security. SDP overlay networks can functionally partition ECUs so that units can only send/receive commands from “approved” peers. These overlay networks can be applied to existing topologies, and can minimize damage by quarantining threats that have succeeded in gaining a foothold in a connected car’s internal network.
The connected car will revolutionize automobile usage, and this revolution will be driven entirely by data and software. Promising automobile-focused efforts such as OVERSEE, EVITA and PRESERVE have already begun to address the challenges and opportunities presented by this huge market. Solving the security problem for the connected car will by extension also serve to solve the companion problems for the connected home, wearables and “nearables”, autonomous drones, and IoT-based industrial infrastructure. The connected car turns out to be the key technology linchpin, and the solutions it defines will help fuel the everything-is-connected business models of the future.