Better Practices for the Connected Car Era

Figure 1: Modern car interface

Infotainment systems aren't the only ones that can be affected by attacks. AI and autonomous driving systems make decisions based on data collected in real time, and those decisions can affect critical systems and cause significant harm to vehicles and road users. In addition to vehicles with self-driving systems, many important systems such as brake pedals and steering wheels are now electronically controlled.

Auto companies are aware of the risks, but how can cybersecurity, risk assessment and analysis be properly implemented? If a vulnerability is discovered, how can the damage be minimized?

Vulnerability (probably) exists in your software

The total code size of the software installed in the car is getting bigger and bigger. For example, the code size for a car is about 10 times larger than the software for an airplane. Figure 2 shows the size of the software (number of lines) in various applications.

One reason for this bloat is the increasing demand for new technologies in automotive software.

Initially, we adopted infotainment systems with attractive graphics and operating systems for smartphones such as Android and Linux to speed up the development cycle and reuse existing libraries. Unfortunately, these operating systems were fundamentally not designed to meet the demands of automotive security and safety. Vulnerabilities in these general-purpose operating systems are frequently discovered, some of which can cause serious problems.

Software complexity also brings other problems. Since the total code size is too large, maintenance of each component requires individual expertise. Therefore, OEMs and Tier 1 companies must rely on third-party companies to develop each module. What if a vulnerability is discovered? In many cases, it is necessary to track software written by multiple companies to identify the cause. Developers must establish a way to track the provenance and change history of source code that consists of multiple modules.

Most cars have multiple network interfaces for connecting other devices, such as LTE, Wi-Fi, and Bluetooth. In the future, more network interfaces will be added, such as vehicle-to-vehicle connections and connections with traffic lights.

None of the network layers defined by IEEE and others are simple, and most protocols are complex, making it difficult and impractical to build a software stack from scratch. Automakers must use third-party libraries for protocol stacks such as Ethernet and TCP/IP to reduce development time. If the library contains open source material, it may be the work of thousands of people. THE CODE OF SUCH OPEN SOURCE SOFTWARE IS PROVIDED "AS-IS". And don't forget the basics. That is, it was not designed for safety-critical applications such as automotive. Companies should assess the risks of their software libraries and plan and implement ways to mitigate them.

To solve such obscure software glitches and add new features, OTA (Over the air) updates are supported or will be supported by many models. OTA brings many benefits to vehicles, but it also carries the risk of reprogramming, so the design and update process must be done carefully.

Can we forestall all possible vulnerabilities in the vast amount of software code bloated for these reasons? "It would be very difficult."

Hacking Techniques

Over the past decade, a number of serious vulnerabilities have been reported with significant security implications. Penetrating systems through the most vulnerable areas is a common way to finally get to the point of entry into critical systems.

Modern in-vehicle networks have many interfaces, such as Bluetooth, Wi-Fi, and LTE, that connect to in-vehicle systems.

Usually, if the infotainment system is running a general-purpose OS such as Linux or Android, the attacker will use one of the exploits within the information hub, represented by things like buffer overruns.

After first gaining access to the system, they attempt to access the CAN bus or similar bus protocols such as Flexray or LIN by running and launching some malicious software. The CAN bus is a common protocol used in automobiles and the connected devices are safety-critical such as engine sensors, brakes and transmissions. The CAN bus was specified before the security of in-vehicle systems became an issue. Signals on the CAN bus can be sniffed, so if you have even one car for testing, the protocol can be analyzed separately.

As shown in Figure 3, a typical attack can be divided into two stages. The first stage is an attack on the infotainment system and the second stage is an attack on the vehicle bus processor.

Auto manufacturers can install several firewalls to prevent it and isolate between systems to prevent intrusion into the entire system and increase system security, but the risk is should be properly evaluated.

The Need for ISO/SAE 21434

Most vulnerabilities can be prevented through good software and workflow design. How can we minimize critical system failures?

In the past, there were no standards for automotive cybersecurity. It combines a lot of software, some from third parties and others from open source like Linux and Android. Developers should, as already mentioned, list all the pieces, track the code, and evaluate each module. However, this was done at the discretion of each manufacturer, and there was no standard explaining how to do it.

There was also no standard way for companies to respond when vulnerabilities were exposed. Exposed vulnerabilities often require some kind of action by the company. When vulnerabilities are exposed, companies must communicate and communicate with their customers, fix the issues, and deploy their fixes. More importantly, you need to proactively check for possible vulnerability scenarios and protect your most important and critical modules from those issues.

What is the best way to achieve that goal?

As you know, ISO 26262 is an established standard for functional safety. This standard requires software to be evaluated very carefully. However, the lifecycle of the software itself, such as OTA updates, is not considered. ISO26262 is very important as a safety standard, but it is not a security standard.

ISO 21434 is a framework for automotive cybersecurity and is one of the security standards supported by Green Hills Software's INTEGRITY real-time operating system (RTOS). Its importance continues to grow as various governments around the world legislate UNECE WP.29 (UNECE World Forum for Harmonization of Vehicle Regulations) requirements for automotive cybersecurity management systems (CSMS). ISO 21434 is the relevant standard for implementing the requirements of UNECE WP.29 CSMS.

This framework covers cybersecurity management from concept to production and defines a common language for cybersecurity. The standard helps companies understand what can go wrong in developing a car, how to organize a cybersecurity department, what to check and how to deal with problems. increase. Also, in order to communicate without confusion between organizations and companies, it is important to use the same terminology, so we have also defined terms used for cybersecurity risks. For example, an asset is defined as one of the characteristics of cybersecurity that can be targeted for damage.

ISO 21434 can also help organize your cybersecurity department. Cybersecurity requires policies that cover all aspects of operations and vulnerability disclosure. The policy also defines what the cybersecurity department's responsibilities are.

ISO 21434 deliberately avoids mentioning specific techniques, specific methods or systems. On the other hand, it covers more about lifecycle management.

Products have a life cycle that includes development, testing, mass production, and operation. Conventional software safety management has not been considered much after mass production. This is because once the development is finished and certified, the code is frozen. Lifecycle management, on the other hand, covers a broader scope, including post-production. Specifically, the standard refers to the V-Model, which describes how developers apply cybersecurity assessments during the development cycle. Operation and maintenance are also considered part of the life cycle. A risk assessment must be performed at each life cycle.

Risk assessment is important in promoting cyber security. ISO 21434 provides guidance for asset identification, threat scenarios, and risk assessment. As I said earlier, an asset is something that should be protected from threats. For example, users' personal information, braking systems, electric mirrors, and safety-critical functions such as cameras can be said to be assets. Each asset has some threat scenario that can result in damage.

As an example of risk assessment, what are some methods of breaking into vehicle systems? "Is it possible to perform the method remotely, or does the attacker need to be very close to the vehicle, or do they need to physically touch the vehicle?" "The risk will change depending on the difficulty level."

Some assets are directly related to safety, others are not. Let's say an attacker stole a user's personal information from an infotainment system. Although this is a big problem, it is not a safety issue in motoring. What if the electric mirror stops working? "The operation of the vehicle will be affected, but it may not be a serious failure that will lead to an immediate accident." What if the braking system fails? "This is a serious malfunction and may cause serious injury to the driver or others." In this way, ISO21434 organizes risk assessment and provides tools such as impact assessment.

Best Products Come from Best Practices

Having the right tools is key to making managing your product lifecycle easier. Green Hills Software has supported ISO/SAE 21434 and UNECE WP.29 as an INTEGRITY RTOS. Trusted by OEMs and their Tier 1 suppliers, the INTEGRITY RTOS is built with a robust partitioning architecture to help embedded developers meet their security, safety, reliability and performance demands.

INTEGRITY can also use hardware memory protection features to isolate and protect embedded applications. A secure partition ensures that the OS and user tasks are protected. Compared to a general-purpose OS like Linux, the separation is clearer, and resources that are normally centrally managed by the kernel are also separated. For example, the heap is isolated so a memory leak in one application won't affect other address spaces. With minimal interference between applications, risk assessment is easier and you have more options for mitigating and prioritizing risks.

Development tools are an important factor in building a safe and secure system for cyber security, not just for the OS.

ISO 21434 mentions several coding guidelines, such as MISRA's (Motor Industry Software Reliability Association) C language to help reduce risk. MISRA is designed to identify aspects of the C language that should be avoided because they are susceptible to ambiguity and common language mistakes. For example, let's look at the following code:

if (flag && (total=num++)

The original intent of the code was "total == num++", not "total = num++" The programmer forgot to put one "=" character. As a result, the code does not run as the programmer intended. The programmer realizes the mistake and replaces "=" with "= =", will "num" increase?　If the flag is false, "num" will not increase, so the answer is "Sometimes it increases, sometimes it doesn't." MISRA Guide helps reduce such mistakes.

MISRA C is a guideline for software developers, not a compiler specification. So if the developer has to do the inspection themselves, it will be costly. Therefore, some steps need to be automated and performed consistently.

In the INTEGRITY series, INTEGRITY-178 has obtained EAL 6+ High Robustness. Common Criteria EAL stands for Evaluation Assurance Level and is accredited by the National Information Assurance Partnership (NIAP). Other operating systems, such as Windows and Linux, are certified EAL 4+, which means "negligent or casual attempts to compromise system security." EAL 6+ is described as "a highly robust system that provides protection from sophisticated and well-funded attackers."

Even if the OS is secure, automakers use third-party and open-source libraries that often run on guest operating systems such as Linux, Android, and Windows to minimize costs. is needed. To mitigate this risk, INTEGRITY isolates code that runs natively, INTEGRITY Multivisor provides a safe virtual environment when a guest OS is required, and security breaches to the guest OS run within the system. I try not to affect other software.

Consider the common methods of intrusion into the critical systems we talked about earlier. Hackers take advantage of one of the exploits found in major operating systems. Breaking into a hub system like Android will end up trying to get to the safety-relevant components via the CAN bus. Alternatively, they try to steal sensitive information such as passwords and keys.

INTEGRITY allows you to provide a virtual device driver that monitors/filters all data between physical signals and the device driver. This allows you to prevent the worst without isolating your hardware if your guest OS is compromised.

As shown in Figure 4, the INTEGRITY RTOS trusted real-time and isolated partition architecture allows multiple arbitrary guest operating systems to run alongside mission-critical real-time software functions.

Applications and guest operating systems should be efficiently scheduled across one or more cores, communicate efficiently with each other, and share system peripherals such as GPUs and Ethernet, following a strict access control model. I can.

By using a decoupled architecture, INTEGRITY is able to provide clean isolation between partitions. If only a limited number of modules are connected with the vehicle bus interface, system separation and high security are achieved despite being in one piece of hardware.

Summary

The growing number of external digital interfaces and the variety of software applications and operating systems in modern automobiles presents a large attack surface for hackers. Even if vulnerabilities are identified and remedied, it is very difficult to update systems and install patches safely at scale.

The ISO/SAE 21434 standard, scheduled for publication in 2021, will provide a framework dedicated to automotive cybersecurity. ISO 21434 is key to implementing the UNECE WP.29 CSMS requirements (which are now being adopted worldwide). Therefore, when developing embedded systems used in automotive applications, it will be essential to ensure security using RTOS-compatible development tool suites that support ISO 21434.

Author Profile