Key security practices for the SDV

The Software-Defined Vehicle (SDV) is about to hit the road, and it will deliver ever more sophisticated experiences for users, and challenges for automotive OEMs and Tier 1s, who are developing more advanced and complex software systems. Features include multiple communication interfaces with the occupants, the OEM and the traffic infrastructure – all of these modes could present the risk of a cyberattack, potentially affecting the complete vehicle fleet.

Specifically ADAS/AD (Advanced Driver Assistance Systems / Autonomous Driving) require decisions to be made in real-time, based on sensor information or on data delivered via V2X communication. Automotive OEMs are aware of the exposure risk, and vulnerabilities do exist. However, how can they execute the proper procedure for cybersecurity, risk assessment and analysis? What should they do when someone finds a vulnerability? How can they minimize the impact on customer safety and brand reputation?

General-purpose means generally insecure

There have been many serious vulnerabilities demonstrated over the last decade that have had safety-critical consequences. Attacking the system through vulnerable communications interfaces like Bluetooth, Wi-Fi and 4G/5G is the standard approach to gain access to the internally interconnected critical systems. Typically attackers use one of the exploits in the information hub, knowing the infotainment system frequently runs a general-purpose operating system, such as Linux or Android.

Having gained access to the system, malicious software is run in an attempt to access the CAN bus or similar bus protocols such as FlexRay or LIN. CAN was defined with reliability in mind, long before the car’s cybersecurity was a concern. CAN has worked well for reliably connecting safety-critical modules, such as engine control, brake, and transmission ECUs. However, with access to a vehicle, the CAN bus can be sniffed, the protocol can be analyzed and eventually a fake message can be introduced.

As figure 1 shows, a typical attack is conducted in two parts. The first step is to attack the infotainment system, and the second is to attack the vehicle bus.

Typical process for hacking a car. First, get access to the infotainment system, head unit or central ECU. Secondly, continue attack over the vehicle bus.

ISO 21434 to the rescue

How can developers minimize critical system failures with the wide range of complex software modules in a vehicle, developed in-house or by third parties, sometimes using open source software such as Linux/Android? Correct software design and development process can prevent vulnerabilities and developers must assess each component and track the code and interactions with other components.

Historically companies developed their own processes for addressing cybersecurity. When a vulnerability is exposed, customers and other affected parties need to be informed and a patch created and deployed. Related possible vulnerability scenarios need to be addressed to protect the most important and critical modules from further exposure.

For functional safety, ISO 26262 is an established standard, which enforces the assessment of software components. However, it does not consider software lifecycle, such as the OTA (over-the-air) update.

In contrast, ISO 21434 is a framework that pertains directly to automotive cybersecurity. It is one of the security standards supported by the Green Hills Software. ISO 21434 is of increasing importance as various governments worldwide adopt the UNECE WP.29 (UNECE World Forum for Harmonization of Vehicle Regulations) automotive cybersecurity management system (CSMS) requirements into law, as it is a relevant standard for putting UNECE WP.29 CSMS requirements into practice.

The framework covers cybersecurity management from concept, production and operation, and defines a common language for cybersecurity. It defines terms used in cybersecurity risk, which is important as using the same terminology is essential to communicate between organizations and companies without confusion.

ISO 21434 covers lifecycle management rather than a specific technology, method, or system, i.e. unlike traditional safety management, it also includes operation and maintenance, and describes how cybersecurity risk assessments can be applied in each part of the lifecycle. The standard provides the guidance to identify assets to be protected, threat scenarios and evaluate the risk.

Secure separation for controlled interaction of applications

Using the right tools and the right processes makes managing the product lifecycle easier. A safety- and security-certified real-time operating system is essential to build modules in the car that are impenetrable to attack. Such an RTOS, or separation kernel, uses hardware memory protection to isolate and protect drivers, third party software, communications, embedded applications and even host one or more instances of guest operating systems. Secure partitions guarantee separation of user tasks and are more robust than typically found within general-purpose operating systems. For example, the heap is separated, so a memory leak in one application will not affect other address spaces. The minimized interference between applications makes the risk assessment more manageable and provides more options to mitigate and prioritize the risk.

As figure 2 illustrates, the trusted real-time separation partition architecture executes multiple arbitrary guest operating systems alongside mission-critical real-time software functions. Applications and guest operating systems are efficiently scheduled across one or multiple cores and can communicate efficiently with each other and share system peripherals, such as GPU or Ethernet, according to a strict access control model.

Example of a safety- & security-certified RTOS, showcasing the separation between various address spaces, critical software functions and guest operating systems.

By using the separation architecture, the RTOS can provide clear isolation between partitions. If only limited modules can talk to the vehicle bus interface, it will increase system separation and security.

In addition to the operating system, ISO 26262 certified development tools are key components for building a safe and secure system for cybersecurity. ISO 21434 mentions some coding guidelines such as MISRA (Motor Industry Software Reliability Association) C, which helps to reduce risk. MISRA C is a set of guidelines for software developers, identifying aspects of the C language that should be avoided due to their ambiguity and susceptibility to common language mistakes; it is not a specification for a compiler. Inspecting the code manually would be a painful process so it is better to automate some of these steps to ensure consistent enforcement. Consequently, selecting a C compiler that supports MISRA C 1998, MISRA C:2004 and MISRA C:2012 for the most common automotive system processors, is very important.

Summary

The growing number of ECUs, external communications interfaces, and a variety of software applications and operating systems being used in the SDV, present a large attack surface to hackers. Identifying vulnerabilities, developing countermeasures, updating systems and securely installing fixes is extremely costly and challenging.

The ISO/SAE 21434 standard, provides a framework specifically designed to address automotive cybersecurity. In addition to applying this standard, it is essential to use safety- and security-certified tools and building blocks, like the Green Hills INTEGRITY RTOS, to ensure security when developing embedded systems for use in automotive applications.

For further information, please contact:

Green Hills Software Ltd
Tel: +44 (0)1844 267950
Email: info-uk@ghs.com
https://ghs.com/automotive