Definition
Soft·ware de·fined ve·hi·cle | ˈsɒfˌtwer dəˈfaɪnd ˈviːhɪkl̩ | – noun: Cars whose features and functions are primarily enabled through software. The emergence of SW defined vehicles is the result of the ongoing transformation of the automobile from a hardware-based product to a software-centric electronic device on wheels.
How is the SDV different than previous car generations and how does it influence cybersecurity? Why is it good for the industry?
The SDV is a disruptive technology changing the current market paradigms and customer mindset. Here are some examples:
- SDV is an evolution built on top of a mechanical car with electronic and computerized control systems. The secret for its success is its capability for continuous improvements, with a growing offer of new features, options and convenient over-the-air (OTA) updates. Overall, both car manufacturers (OEMs) and vehicle owners benefit from much more flexibility. The main drivers originate from the new trend of CASE (Connectivity, Automation, Sharing and Electrification).
- To have reached the goal of an SDV, one major pillar is the vehicle physical abstraction. This is like the computing practice of HAL (Hardware Abstraction Layer). The automotive equivalence is call VHAL (Vehicle Hardware Abstraction Layer) where the vehicle functionality is described in a formal fashion. It is achieved by a set of generic APIs (Application Programming Interfaces) separating the actual physical implementation in the vehicle. See for example the COVESA (Connected Vehicle Systems Alliance) project VSS (Vehicle Signal Specification) and initiatives such as Android™ Automotive Vehicle Interface (Vehicle HAL). This enables the development of software that performs advanced functionality not directly related to a physical vehicle. This software can run on various vehicle platforms providing the functionality regardless of the actual physical implementation of the vehicle.
- Another enabling factor is the industry trend of OEMs to develop their own vehicle operating system such as Volkswagen’s VW.OS (Volkswagen Operating System) and Mercedes-Benz MB.OS. The OEM that develops the OS can also share it with other OEMs in the industry. This OS is the enabling factor that serves as the basis, abstraction and orchestration platform for the new services installed in the vehicle.
- OEMs gain the capability to offer new services, change the vehicle configuration, and generate new income streams that were previously impossible.
- It enables the vehicle owner to add and change the vehicle functionality according to the changing needs, such as buying battery extended range for one week due to an expected long journey.
- Third party companies can provide their solutions to numerous vehicle owners from different OEMs. For example, if a company develops a ADAS (Advanced Driver-Assistance System) it can be fitted on various platforms by this opening the market to competition and creating new commercial opportunities. This can enable the user to select the preferred ADAS that best meets its needs and install it on its vehicle.
- This is one central system with several interconnected subsystems. It is not an orchestrated set of independent or communicating modules. It has a central HPC (High Performance Computer), most likely running Linux, that interacts with all the components and controls the vehicle. The previous physical isolation and network segregation is replaced by hypervisors and virtual devices. It is still to be seen if this security method is at least equal to the legacy ones. This is the platform on top of which OEM and third-party services can be accommodated.
- Old legacy architecture included over one hundred of ECUs (Electronic Control Units) with software running over 150 million lines of code, coexisting, and communicating over an in-vehicle network. Add to this the growing array of sensors and actuators such as cameras, LIDAR (Light detection and ranging), sonar, etc. the SDV is much more than a smart phone on wheels. It is a datacenter on wheels. To support all those current and future goodies, the computing power needs to be oversized for current needs but increased in a sane economical fashion. This undertaking is quite challenging today since it needs to support future protection against unknown cyber risks.
- Vehicle development changes from a legacy waterfall model to an agile process. This is similar to software industry practices such as CI/CD (Continuous Integration/ Continuous Delivery). It looks more like the software updates on your mobile phone and user selected applications download. This method enables frequent updates adding capabilities to the existing software running in the vehicle. CI/CD have its virtues, such as addressing vulnerabilities quickly, but given frequent software updates and multiple versions there are constant cyber risks.
- Resources are shared between the various consumers in the vehicle facilitating flexibility and scalability. If a high priority task requires resources at one point, other less important tasks such as playing music, can be pushed back for a while until the higher priority task is completed and then the resources are restored to the less urgent tasks. Previously, with dedicated ECUs the IVI (In-Vehicle Infotainment) resources could not be allocated to the BCM (Body Control Unit). Now those resources can be balanced and shared among applications in a dynamic fashion considering the installed/active application and their needs for resources. An attacker with access to the IVI might use this sharing of resources to access many areas and components in the vehicle when launching an attack.
- Connectivity to the cloud is a major pillar in this architecture enabling cloud applications to interact with the vehicle for feature enablement and configuration changes. Some of these changes require payment for example to the OEM. Enabling technologies which support the increase in high volume, low latency mobile communication including cellular 5G, upcoming 6G and future generation to come. Together with the intensive connectivity comes an extended attack surface that can be used by hackers.
- OEMs realized that if they wish to hope to have future income, they cannot rely on selling a physical vehicle. Instead, they must focus on selling services and optional features. This is reflected in the industry by observing many OEMs taking ownership and developing their own operating system, software, and applications. New software developed in new organization emerge with bugs and vulnerabilities by nature of the software industry.
- Easier to perform preventive maintenance, vehicle monitoring, reporting of reckless driving, perform OTA (Over the Air) updates and improve driver wellbeing with relevant information. This is lots of data that a hacker would be happy to possess.
- The customer can buy new features on permanent or conditional basis long after the vehicle was acquired. For example, one can permanently increase the engine performance or temporarily add ADAS (Advanced Drive Assistance System) and AD (Autonomous Driving) for the duration of a long boring drive. Even one-time pay-per-use fast charge can be acquired. From the hacker perspective, this is not only another potential way to access the vehicle and personal data, but also an option for financial fraud.
- Even the used cars market is affected. One does not need to look for the exact used car wanted but for one close enough. It can be changed and upgraded after it is acquired.
Cybersecurity for SDV?
- The industry should adopt the posture of “assume harm”. Trust no one. Check and doublecheck everything. Go by the theory: “Only the Paranoid Survive”!
- Major threats:
- OTA updates – adds the widest attack surface so plan for the highest risk. Consider the attack scenario of exploiting a vulnerability in the update process and eventually takes control over the whole vehicle. It should be noted that that OTA is also used for dispatching security updates so it should be regarded as a security critical functionality as well.
- Compromising mobile applications – the mobile phone can turn into your vehicle into a remote control. This can become a dangerous path, like an attacker taking over the mobile phone to access the vehicle and personal data.
- Malware – hackers can access unsecured Wi-Fi or Bluetooth devices and use them to inject malware into the vehicle such as Hell2Cap vulnerability discovered by Cymotive Technologies https://www.cymotive.com/wp-content/uploads/2019/03/Hell2CAP-0day.pdf.
Once injected, the malware can be used to hijack a vehicle. - Vulnerable servers – once successfully penetrating a server, a hacker could access all connected mobile apps, sales data, and controls. With this access, it is now possible to manipulate secondary vehicles connected to the server, access a car’s on-board diagnostic, and use it to access its management system.
- Fleet attack – once an attack method is developed, it can be applied not only to the individual vehicle but also to the whole fleet making this a much more dangerous scenario.
- Service attack – since the same service application can run on different platforms from several OEMs, a compromised application can be exploited over a wide range of vehicles makes and models.
- HPC and large ECUs – having a centralized and complex computing component with lots of hardware, virtualization, software and interfaces in the vehicle exponentially increase the associated cybersecurity risks.
- The multi-layer, defense-in-depth approach with a secure by design methodology should be the basis of any new development. In general, the SDV requires a deeper, more meticulous implementation of existing methodologies with the proper adaptation to it cybersecurity requirements.
- Change to a proactive approach. Legacy systems would use a reactive policy with many beneficial uses. For example, if the IDS (Intrusion Detection System) detected an infected component, it would shut it down. Reactive systems would rely on cryptographic means to authenticate message origin, ensure its integrity and freshness to confirm its processing. Such an approach would enable a compromised component to transmit malware over the secured communication channels to its victim. This would not be sufficient, and a proactive approach would perform things like deep content inspection to verifying the message format validity and plausibility of information contained in it. This can be achieved by sensor fusion to detect misbehavior of V2X (Vehicle to Everything) messages for example. The HPC with its powerful and flexible processing capabilities is an enabler to this approach previously not feasible with the numerous limited power ECUs architecture.
- The concept with this growing ecosystem implies that the software originates from multiple sources, not all controlled by the OEM. Something that resembles the aftermarket situation but at a much larger and deeper scale. This is not a controlled supply chain of Tier 1/2/3s with the appropriate security means and controls set in place. It is more like an application store running on top of the vehicle operating system like on a smart phone. In terms of running software, separation, segregation, containers, and hypervisors should be used to prevent one piece of software from accessing and infecting another one. Using SOA (Service Oriented Architecture) implies borrowing the security and testing methodologies from IT (Information Technologies) and applying them to the automotive community with the proper adaptations. This can clearly be seen in the networking move from CANbus to Automotive Ethernet including layered protocols such as SOME/IP (Scalable service-oriented middleware over IP). The same concept should be applied to the software part and its security.
- An IDPS (Intrusion Detection and Prevention System) should be independent. Currently, common implementation of the IDPS is in the CGW (Connected Gateway). This in an overlay functionality on an existing device that has weak processing power and not designed for this kind of task. The IDPS should monitor the network traffic and have reporting agents in the various components but should reside in a separate and autonomous environment. While security means are included in all the vehicle components, the IDPS is the only dedicated, devoted, independent, and objective tool that protects the vehicle. As such, it should be implemented in a sperate protected location that cannot be affected by the compromise of other components. Currently, the IDPS is not awarded its deserved respect as centerplate in the industry.
- All software should be subject to threat analysis and vulnerabilities management for detection of CVEs (Common Vulnerabilities and Exposures). This is done by software composition analysis i.e., extraction of the SBOM (Software Bill of Materials) out of the image and performing risk reduction by mitigating the detected threats. Since much of software is open source (which is regarded as more secure than proprietary closed source) applying such tools is highly effective and efficient.
- Security testing and penetration testing should be performed even in the pre-hardware phase to reduce the development costs and improve security. This can be done on simulators and emulators platform running a digital twin that enable this kind of activity.
- Hardware should be not overlooked, and the same concepts of vulnerabilities management and penetration testing should be equally applied to hardware as it is applied to software. The chips can potently include COTS (Commercial Off the Shelf) ones. They should include secure hardware capabilities such as HSM (Hardware Security Module), secure boot, secure firmware updates, secure key updates, secure storage, antitampering, etc.
Conclusion
SDV is the next thing in the automotive industry. For it to be a success, customers need to both trust it and see the benefits.
Regarding the benefits, which for sure is more important to the OEMs and consumers, one can assume this will eventually workout (although, it’s not clear how much in the favor of the OEMs and how much in the favor of the large internet players such as Google).
Regarding the trust, this means the car needs to be safe and secure, but customers are not willing to pay one dime for either one since it is expected to be an inherent part of the vehicle. However, at the brand level, a vehicle which is perceived as safer and more secured will gain additional market value and customers would take this virtue in consideration when weighting their preferences towards a new vehicle they plan to acquire.
For functional safety, OEMs need to implement the current methods to the new vehicle.
For security, as discussed above, major changes, updates and improvement need to be performed to ensure the security of the vehicle. In the industry, we see several approaches by OEMs.
- At one extreme there are those that invest the bear minimum to pass regulation for plausible deniability in case of a cyber event with damages.
- Others take a more moderate approach hoping their cars would not be the first ones to be attacked in a catastrophic way and improve security along the way only if and only when the need arises.
- The other extreme includes those OEMs (not too many for them unfortunately for now) that aggressively invest into security even at the expense of offering fewer features in the car.
In sum, although securing the SDV is vastly different than anything we have seen before, it is definitely achievable.
