Q&A with Dan Klinedinst
FASTR recently released its “Automotive Industry Guidelines for Secure Over-the-Air Updates.” They describe the threat models, recommend cryptographic algorithms and detail a step-by-step checklist for evaluating software over-the-air (SOTA) update systems. “These guidelines will serve as a comprehensive, objective resource to help OEMs (original equipment manufacturers) analyze SOTA systems and make wise design choices,” Craig Hurst, FASTR executive director, said in the press release announcing their availability.
We spoke with Dan Klinedinst, vulnerability researcher with the Carnegie Mellon University CERT Coordination Center and a member of the FASTR Technical Steering Committee, to learn more about how the new SOTA guidelines are representative of FASTR’s work to drive systematic coordination of cybersecurity across the entire supply chain and ensure trust in the connected and autonomous vehicle of the future.
What is SOTA?
SOTA stands for “secure, over-the-air” updates. In general, a product’s security is enhanced by the ability to update its software if a security vulnerability is discovered. This is most efficiently achieved by over-the-air updates—that is, the ability to update via the cellular (or in some cases, satellite) network, rather than connecting vehicles or other mobile devices to a computer. However, these OTA updates also open a new attack vector to be manipulated. So it’s imperative that the OTA mechanisms themselves are securely designed and implemented, or they increase risk rather than mitigate against it. SOTA is, therefore, an OTA implementation that is itself secure.
How pervasive is SOTA in the auto industry today?
Most production cars today at least have a cellular modem and are capable of doing OTA updates. Whether that capability has been implemented, and to what degree, probably varies widely. It is likely that many secondary systems, such as in-vehicle infotainment systems (IVIs) and telecommunications units (TCUs) have an OTA capability. The electronic control units (ECUs) that control driving and safety functions are less likely to, as there are concerns around both safety and usability (drivers would not appreciate having to wait for updates to be installed before they drove to work, for example). Even in systems that have OTA capabilities, history tells us that at least some of them will have security vulnerabilities.
Why was this considered to be a high-priority area for FASTR to focus on now?
Customers will increasingly demand OTA capabilities for their cars, even if it’s just to add new features (maps, apps, etc.) We also believe the ability to remotely apply security fixes enhances security overall. However, an “always-on” internet connection is a source of potential vulnerabilities, especially if it is intended to download and install new software, firmware or data. Therefore, an OTA function is both high risk and high reward with regard to a vehicle’s security posture.
Who will find useful the guidelines you are publishing?
The FASTR guidelines are intended to be sufficiently detailed that engineers and product managers can assess third-party SOTA solutions or assess their own proprietary SOTA solutions. However, they are also useful to OEMs, Tier 1-n manufacturers, system integrators and others who need to acquire and implement software-centric components.
What will it help them do better than they can do today, and how?
The guidelines can be used as a reference when designing a SOTA solution, but they can also be used to assess software-centric systems that companies are acquiring to integrate into vehicles or connectivity solutions. Acquisition experts can ask their suppliers questions based on the FASTR guidelines, in order to judge how much thought has gone into the security of their OTA solutions and their security posture in general.