AUTOSAR Safety and Security
02-11-2023
news_15


OVERVIEW OF AUTOSAR SAFETY AND SECURITY

Connectivity and collaboration with various external sources are crucial for future automotive applications. This involves communicating with sensors and applications within the vehicle, as well as external sources such as mobile devices, roadside infrastructure, and cloud computing systems provided by backend IT systems.

AUTOSAR paves the way to a standardized set of safety and security means to support developers in achieving the Automotive Safety Integrity Level (ASIL) according to ISO DIS 26262.


AUTOSAR Safety Standard and Concepts

Ø  Safety Standard

Before mentioning AUTOSAR Safety Concepts, we will go through the introductory requirements of ISO 26262 for functional safety of vehicles on the road.

• ISO 26262 provides an automotive safety lifecycle (management, development, production, operation, service, and decommissioning) and supports tailoring the necessary activities during these lifecycle phases.

• ISO 26262 provides an automotive specific risk-based approach for determining Automotive Safety Integrity Levels (ASILs).

• ISO 26262 uses ASILs for specifying the item’s necessary safety requirements for achieving an acceptable residual risk.

• ISO 26262 provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved.

• ISO 26262 provides requirements for the relation with suppliers.


Ø  AUTOSAR Safety Concepts

・ Concept 1: Fault Detection, Isolation, and Recovery (FDIR)

Fault Detection, Isolation, and Recovery (FDIR) concept is a primary safety concept provided by AUTOSAR, which helps detect, isolate, and recover from faults to ensure the safety and dependability of the system.

There are many definitions of FDIR mechanism to be found in the literature. The following tasks are typical part of a FDIR System:

–       Fault detection is the identification of faults in a system and of their occurrence times.

–       Fault isolation to determine the type and position of faults.

–       Fault identification refers to determining the size and fault behaviors and estimating the damage level and its possible impact on the system.

–       System reconfiguration compensates for the identified faults, for example by switching to redundant systems.

Figure 1: Definition of Fault Dectection & Isolation (FDI), Fault Detection & Diagnosis (FDD), Fault Detection, Isolation & Recovery (FDIR)

 

・ Concept 2: Safety Element out of Context (SEooC)


Figure 2: SEooC development process

 

This concept refers to the process of verifying the safety of a component or system in isolation, without considering its interaction with other components or systems in the vehicle, which helps to ensure that the component or system is safe and reliable, even when it is integrated into a larger system.

 By way of illustration, the operating system is responsible for ensuring safety by providing guaranteed scheduling of safety-related tasks and protecting higher ASIL processes from lower ASIL or QM processes in terms of memory, hardware, and resources. This responsibility remains the same regardless of the ECU in which it is used or the specific safety goals of the system.

 

・       Concept 3: Freedom From Interference (FFI)

 The concept of Freedom From Interference (FFI) pertains to the absence of failure propagation from a lower ASIL level element to a higher one. This implies communication or dependency between two elements of different ASIL levels should not have any impact on their respective safety requirements.

 The effects that can prevent FFI include timing or execution failures, such as deadlocks, execution blocking, and lack of phase synchronization between software elements, as well as memory failures and information exchange issues.

 There are various mechanisms that can be used together to achieve FFI and prevent the above failure propagation as follows:

ー Barriers are hardware-based (external watchdogs and MPU) to prevent interference between elements.

ー Defenses are programming techniques that disable interruptions during critical sessions, pointer checking mechanisms, etc. They are effective against memory corruption, but not dynamic calling failures.

ー Qualifiers are documents with evidence that show an element has its own mechanisms to guarantee FFI.

ー Well-trusted elements are also used to ensure no ASIL level corruption occurs.


AUTOSAR SAFETY MECHANISM FEATURES

・        Memory Partitioning

It separates software applications from each other to avoid any data corruption, which allows safety and non-safety applications to be implemented on the same ECU.

 Memory partitioning is a protection mechanism that restricts access to memory and memory-mapped hardware. It also prevents code running in one partition from modifying memory of another partition.

 Figure 3 displays a partitioning example that is utilized as the fault containment regions. If an error is found in a specific partition, that partition can be terminated or restarted while the system is running. Electronic Control Unit (ECU) configuration files are used to configure these partitions. If a violation or error occurs in Partition 1 as illustrated in Figure 1, the OS services terminate Partition 1 and stop any possible communication, then the partition is restarted.


Figure 3: Example of Partitioning

・       Defensive Behavior

The defensive behavior of basic software modules in microcontrollers, which do not have hardware support for memory partitioning, prevents data corruption and incorrect service calls. This cost-efficient approach is suitable for applications with low to medium levels of integrity to prevent the propagation of faults.

 

・       End-to-End (E2E) Communication Protection

In AUTOSAR 4.0, the End-to-End (E2E) communication protection features are included as a standard library offering protection mechanisms. These mechanisms enable the sender to protect the data, and the receiver(s) to identify and handle errors in the communication link during runtime. This library offers E2E protection mechanisms suitable for safety-critical communication with requirements up to ASIL D.


Figure 4: Example of faults detected by E2E protection

 

・Program flow monitoring

The program flow monitoring is a mechanism used to ensure the accurate execution of software. Its main purpose is to detect program flow errors, which happen when the program sequence deviates from the correct path. This can occur if program instructions are processed out of sequence, or not executed on time, or not processed at all. Such errors can result in data inconsistencies, data corruption or software failures.

 

・Time determinism and timing constraint modeling:

The purpose of this mechanism is to create a consistent and predictable timing behavior. This is achieved through several methods, including the use of synchronized time bases, ensuring synchronized execution and deterministic timing of software components, and controlling timing behavior and detecting timing violations at runtime. The mechanism also includes setting timing constraints such as end-to-end delays, minimum and maximum execution times of runnable entities, and trigger rate constraints for events.

 

AUTOSAR SECURITY CONCEPTS

Ø  Security Concepts:

・       Security and Cryptograph Architecture

Different security applications require different cryptographic services, and the Crypto Service Manager (CSM) enables various applications to utilize the same service with different cryptographic primitives and routines.

The crypto module is responsible for managing requests for cryptographic services made by applications and dispatching them to a pool of basic cryptographic routines. To facilitate this, the crypto module provides a standardized interface for security applications to access cryptographic routines and another interface for cryptographic routines to be integrated into the module and used by security applications. 


Figure 5: Cryptographic Architecture

 

・       DCM Manages Security Access Level Handling

The Diagnostic Communication Manager (DCM) is a basic software module offering a common API for diagnostic services. It is utilized by diagnostic tools from external sources during the development, manufacturing, and service phases. The primary purpose of this module is to guarantee diagnostic data transmission and to manage diagnostic states, such as diagnostic sessions and security states.

 

・        Memory Read Access

The Operating System (OS) can provide memory protection for OS-Application against read access by other OS-Applications. When a task can read any memory, it can operate on incorrect data, leading to failures during runtime. By preventing read access, such faults can be detected immediately. Additionally, memory protection can also address security concerns, though there are typically no security implications between OS-Applications on the same processor.

 

AUTOSAR CYBERSECURITY AND THREAT ANALYSIS

Cybersecurity is a broad field about securing any digital information against cyberattacks. One way to ensure cybersecurity solutions is to use threat modeling techniques, such as STRIDE method which stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. An alternative approach is to identify the core assets of a specific domain and collect threats targeting these assets, and this approach will be discussed in more detail as follows.

 

・       Asset 1: ARA_ The Runtime Environment between user applications and the lower layer functional cluster may have the following attacks and attack steps.

A 1.1. Access

A 1.2. Compromise

A 1.3. Information leak

A 1.4. Message injection

A 1.5. Denial of service

The access attack step (A 1.1) is used by the upper layer user application to gain access to at least one interface of the lower layer platform-level applications. Attackers who have access to any functional cluster interface in the ARA can use it to deny service (A 1.5) that the interface provides. Attackers can also compromise (A 1.2) the runtime environment itself, which can lead to information leakage (A 1.3), and messages injections (A 1.4) during communication. As a result, attackers can read information by leaking information (A 1.3), write data by injecting messages (A 1.4), and deny services provided by the platform applications and user applications by making a denial-of-service attack (A 1.5) on the public interfaces in the ARA.

 

・       Asset 2) Operating System (OS) may have the following attacks and attack steps.

A 2.1. Access

A 2.2. Malware

A 2.3. Denial of service

A 2.4. Data injection

A 2.5. Information leak

A 2.6. Memory corruption

If attackers gain access (A 2.1) to the OS, they can launch denial of service (A 2.3) attacks, inject data (A 2.4) into running processes, and cause memory corruption (A 2.6) in running programs. They can also install malware (A 2.2) programs that can compromise accounts, read and write data, bypass access control, and cause denial of services (A 2.3) in the OS. Malware can be protected by antimalware programs, but attackers can still perform denial of service (A 2.3) attacks by flooding services or exhausting resources. Such attacks prevent legitimate processes from running, causing denial of services in the platform and user application.

Additionally, attackers can inject (A 2.4) processed data of one process into another process's data or from one thread to another in the same process, resulting in information leaks (A 2.5). Finally, unhandled codes can cause memory corruption (A 2.6), leading to information leaks (A 2.5), denial of services (A 2.3), data injection (A 2.4), and account compromises. Protected runtime environments can safeguard against memory corruption.

 

・       Asset 3) Bus Network

It is important to note the potential attacks and attack steps that can occur on the bus network

A 3.1. Traffic injection

 A 3.2. Wakeup message injection

 A 3.3. Impersonation

 A 3.4. Man-in-the-middle

An attacker could inject wakeup messages (A 3.2) or exceed the maximum transmit error counter threshold to initiate a bus-off attack on connected ECUs. Wakeup message injection on networked ECUs can lead to battery drain attacks. Since the bus network allows everyone to send traffic without verification, an impersonation attack (A 3.3) can occur easily, enabling adversaries in the middle (A 3.4). The impersonation threat can be prevented with a message authentication mechanism.

 

※Reference Links:

https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_EXP_SecurityOverview.pdf

https://www.autosar.org/fileadmin/standards/R20-11/FO/AUTOSAR_RS_Safety.pdf

https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSAR_RS_CommunicationManagement.pdf

https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSAR_SWS_Cryptography.pdf

https://fscdn.rohm.com/en/products/databook/white_paper/iso26262_wp-e.pdf

You may like also

News
Introducing MaaZ-Lite: The lightweight AUTOSAR Solution
News
Discover MaaZ Lite: The future-ready AUTOSAR solution
News
FPT Signs MoU with Subaru, Driving Innovation in Automotive Manufacturing Sector
Get started on your effortless
SDV journey!
Contact Us
AUTOSAR
MaaZ
Contact Us
FPT Automotive
Headquarter:
Suite 108, 2770 Main Street, Frisco, Texas 75033
Tel: +1 947 339 0024
Copyright 2024 © FPT Automotive.
Products
Services
Resources
Company