Cloud native EDA tools & pre-optimized hardware platforms
This article was originally published on WardsAuto.
We’ve heard the saying that modern cars are like computers on wheels. Well, vehicles are also like smartphones on wheels. Familiar and favorite apps from your phone are now available natively inside your ride. You can listen to streaming music, play a movie, map a route to the nearest ATM, and soon even order dinner or your favorite beverage on the way home or to work.
We’re in the age of software-defined vehicles, where automotive functions and features are driven more by software than by mechanical components. Over-the-air (OTA) updates allow carmakers to correct software bugs, deliver new capabilities (including apps!), and assess the vehicle’s operation. This way of constantly modifying the vehicle also presents opportunities for collaboration with third parties for new offerings—and new revenue streams.
However, as with any electronic system, vehicles can be ripe for cyberattack if not properly protected. OTA updates, especially when they involve third parties, represent a potential area of vulnerability. In this article, I’ll highlight key security considerations of OTA updates and in-vehicle apps and the measures that should be taken to keep cars safe and secure.
OTA updates are delivered over a cellular network, Wi-Fi, or other radio frequency- (RF-) based methods that provide software updates. This grouping of technologies offers a fast and convenient way for vehicle manufacturers to resolve issues and future-proof their cars, all without requiring car owners to visit the dealer. There isn’t currently a standardized way in the automotive industry to verify software updates. As such, it’s possible for an OEM to have multiple ways to confirm software updates for some of its components or to rely on a complex supply chain for the delivery of these updates. But this should change as the software-driven features become further ingrained in the industry.
In the U.S., the National Highway Traffic Safety Administration (NHTSA) offers security guidance through its Cybersecurity Best Practices for the Safety of Modern Vehicles report. The report outlines steps for vehicle manufacturers to take to mitigate the risk of cyberattacks. NHTSA isn’t alone in this endeavor. The EU has issued UN Regulation No. 155, which has clear requirements that require OTA capabilities to update vehicles in order to sell in that market.
Efforts generally begin with a risk assessment, outlining components in a vehicle that any application would interact with. But then, there are a lot of questions about risk and responsibilities. As an example, let’s consider a self-parking application that’s activated by a smartphone. The vehicle in question already has autonomous driving capabilities. However, to enable self-parking, the driver needs to install an app that is tied to a parking garage company and must be allowed to communicate with the vehicle. For this application to work, the carmaker needs to provide location and other vehicular data to the app so that the car can navigate safely through the garage to an available parking spot once prompted by the driver. Is the OEM responsible for monitoring and managing the app’s security and capability, or is it the supplier's responsibility to ensure that the app contains nothing malicious or compromised? Many of these questions will be resolved by legal departments, but proper cybersecurity hygiene is the primary focus for minimizing these types of events.
In-vehicle apps such as the self-parking example represent a new revenue stream, and the opportunities are wide open for a host of new and exciting capabilities. Imagine having a car that knows your favorite morning coffee order—once you step inside for your commute, the car has already placed the order, handled the payment, and is navigating the fastest route to the café for order pickup. Or, what if different in-vehicle apps could interact with one another? Your car senses—thanks to an app plus a tracking tag on the bag—that you have clothes in the trunk for the dry cleaner. The dry-cleaning app communicates with the café app, directing the car on the most efficient route to drop off the dry cleaning and pick up your coffee.
The apps themselves must have built-in protections against malicious attacks. When they’re ready to be updated, the OTA updates must flow securely from server to vehicle, with little risk that the data will be intercepted and compromised.
These days, carmakers and app developers are collaborating closely, though a primary focus is getting new capabilities to market. At the consumer level, it may be several years before we start seeing these example scenarios come to fruition. Enterprise-level innovations may come sooner. Pizza Hut, for example, is exploring a driverless concept vehicle equipped with a pizza oven, a move that could transform how food is ordered, prepared, and delivered.
Regardless of when these new offerings are available, the time is ripe to start addressing the security considerations.
The risk assessment is a solid starting point that requires the right people for the task. Also important is assigning areas of responsibility, as well as accounting for the steps and actions needed to mitigate security risks. Carmakers would be wise not to rely on third-party app developers to understand the security requirements of their vehicles. These requirements will vary widely across vehicle types and manufacturers. A secure set of application programming interfaces (APIs) for the app developers is a good safeguard and opens an opportunity to monitor and limit access. This way, if anything inappropriate happens with the app, the vehicle would know how to react and potentially protect itself. Another important element is establishing a protective layer for the vehicle subsystems, enabling a safe, secure way for third parties to interact with the vehicle to deliver value-added services.
Key elements of an effective OTA software update security program include having a robust public key infrastructure (PKI), well-defined software verification and validation practices, and effective vehicle software deployment, storage, and activation. The automotive industry can also take some lessons from the mobile device industry – smartphone makers, for example, must apply robust security measures to ensure that their devices, the apps installed on them, and the data accessible by these apps remain safe and secure. Carmakers must do the same across all their product lines.
A variety of security and monitoring technologies is available to support carmakers. For the vehicles themselves, automotive engineers can employ electronic digital twin solutions, which provide virtual environments to test silicon solutions before they are deployed. As we see more consolidation of in-vehicle compute platforms, traditional methods to test silicon for security become impractical given all the touch points in these complex environments. Electronic digital twins provide an answer. Silicon lifecycle management (SLM) sensors and monitors can track electronic component behavior over time, from in-design stages to the field. With SLM, automotive engineers have a way to evaluate how devices are performing under their workloads over the long lifespan of vehicles.
On the software side, static application security testing, fuzz testing to uncover security weaknesses, and application vulnerability correlation to diagnose and manage software risk are among the solutions available to safeguard in-vehicle apps and OTA updates.
OTA updates are an efficient and cost-effective way for carmakers to future-proof vehicles, provide updates, or keep cars out of the dealerships for recall fixes. As with any electronic component or software solution, these updates as well as the in-vehicle apps that enrich the driver experience can all be vulnerable to cyberattacks. Conducting a thorough risk assessment, assigning areas of security responsibility, and deploying both hardware and software security solutions can help keep vehicles safe and sound for the long haul.