The functionalities of modern vehicles are highly dependent on software. For example, if we examine a vehicle’s brake system, we will find complex software managing features such as anti-lock braking, brake-by-wire, emergency braking, and parking brakes. To enhance the performance of these systems or address detected weaknesses or vulnerabilities, OEMs and suppliers often need to update the software periodically. ISO 24089 provides a comprehensive guideline for software update engineering in road vehicles to support this process. In this article, we will explore an overview of the software update process, including a summary of ISO 24089, cybersecurity challenges during updates, and the security objectives of software update packages with automotive use cases.

Organizations Involved

To facilitate software update activities, a supplier, OEM, or an authorized third party may be involved. These updates can occur either in a workshop using wired methods (e.g., via flash USB) or remotely using over-the-air (OTA) wireless protocols, such as cellular or Wi-Fi. The roles and responsibilities of each entity involved in automotive software update activities are outlined as follows.

Supplier.

Typically, a Tier 1 supplier is responsible for building vehicle systems or subsystems, either by developing in-house software for their ECUs or outsourcing ECUs from another supplier (e.g., Tier n). If the ECU software requires an update, the original party that created the software remains responsible for developing the software update package. Suppliers (from Tier 1 to Tier n) often include this process in their Cybersecurity Interface Agreement (CIA) to prevent potential conflicts. Once the software update package is ready, the supplier initiates the software update campaign, seeking authorization from the OEM or the vehicle user for the distribution of the new software. After authorization, the supplier can distribute the software update either through their own infrastructure or by delivering it to the OEM for distribution. The roles and responsibilities for this distribution should also be outlined in the CIA between the OEM and the supplier. In addition to the OEM and the supplier, an authorized third party may distribute the software update package. To support the supplier in creating the new version of the software, the OEM or authorized entity provides vehicle configuration information, rather than allowing suppliers to collect it directly from the vehicle.

Note: You might have encountered two new terms: software update package and software update campaign. Here is the definition of these terms:

Software update package: Set of software and associated metadata that is intended to be deployed to one or more vehicles, vehicle systems, or ECUs.
Software update campaign: Sequence of identifying the target and resolving recipient, distributing software update package, and monitoring & documenting software update operation results.

OEM.

While suppliers are primarily responsible for ECUs, OEMs can take responsibility for updating the software of the vehicle, vehicle systems, or ECUs. OEMs may have their own in-house software teams tasked with developing and updating software when necessary. The general rule is that whoever creates the software (e.g., OEM or supplier) is responsible for producing updates to ensure there are no safety or security risks. OEMs assess the potential safety impacts of a software update package and determine whether a skilled technician is needed for the update operation based on that assessment. For OEMs, the software and its associated metadata may apply to the entire vehicle, multiple vehicle systems, or specific ECUs.

Other Authorized Entity.

Sometimes, the supplier and the OEM create a new version of the software for a third-party organization to distribute it to the vehicle(s). This type of organization must have skilled personnel to ensure the software update is performed correctly and securely.

Summary of ISO 24089 – Software Update Engineering Process For Road Vehicles

The diagram below shows the overview of the ISO 24089 standard.

Clause 4: Organizational Processes.

This clause outlines the organizational processes for software update engineering, which encompass governance, continuous improvement, information sharing, and auditing.

Governance: This aspect oversees the management rules and processes related to software update activities. It includes areas such as quality management, requirements management, configuration management, change management, and document management. Any tools employed for these management processes also fall under governance.
Continuous improvement: The processes for continuous improvement involve evaluating, applying, and communicating lessons learned from various sources, such as training or previous projects. This also includes analyzing feedback from prior software update projects, field monitoring, and observations to enhance future updates.
Information sharing: This component establishes the organization’s policy for sharing information both internally and externally concerning software update activities. The policy details what information is shared, with whom it is shared, when it is shared, and the procedures for permitting information sharing.
Auditing: Conducting an audit is essential to determine whether the software update engineering activities align with the objectives of the ISO 24089 standard. This audit may be integrated with or conducted alongside an audit according to a quality management system standard. Audits can be performed by either internal teams or external organizations to ensure compliance and effectiveness.

Clause 5: Software Update Project Processes (Project Level).

This clause primarily addresses software update project management, tailoring software update activities, ensuring interoperability between vehicles and infrastructure, and maintaining the integrity of software update packages and metadata. The remaining clauses in the ISO 24089 document expand on project-level considerations, focusing on vehicle and vehicle system integration, infrastructure, software update packages, and software update campaign levels.

Project management: Project management encompasses the planning of all software update engineering activities, the assignment of roles and responsibilities for each task, and the maintenance of comprehensive documentation for overall project oversight. Examples of software update activities include the development and adaptation of vehicle or infrastructure functions, as well as executing software update campaigns.
Tailoring and Rationale: A software update project can be customized to address specific functionalities of vehicles, vehicle systems, or ECUs. A rationale must be provided to explain how the tailored project meets the requirements outlined in the ISO 24089 document.
Interoperability: It is essential to implement processes that maintain interoperability between infrastructure and vehicle systems. This aspect focuses on the relationship between infrastructure and vehicle systems, ensuring they work together effectively to facilitate successful software update projects.
Integrity: The organization shall establish, implement, and maintain processes to preserve the integrity of software, and either metadata or software update packages, or both, during distribution in the context of interoperability: within the infrastructure of organizations, between the organization of the supply chain, from organization to vehicle, within the vehicle and between vehicle systems.

Clause 6: Infrastructure Functions/Level.

Infrastructure for software update engineering is defined as the processes or systems that manage the software update operation, software update campaign, documentation, and vehicle configuration information including digital and manual activities. Overall, an infrastructure should have the following functionalities:

Risk Management: It is very crucial to manage the risk of the infrastructure by the organization. Compromise of cybersecurity in any form of the infrastructure can affect the software update project severely making the vehicle vulnerable at the end.
Managing vehicle configuration information: The infrastructure shall have a process to collect, analyze, and distribute vehicle configuration data to the responsible parties. It is important to maintain the integrity of the configuration data when it is at rest or in transit.
Communicating software update campaign: The infrastructure shall have a process to communicate to the vehicle user about the new version of the software update package.
Processing software update packages: The infrastructure shall have a process to collect the software update package from another organization in the supply chain, resolve the target into the recipient, and maintain the integrity of the software update package. Infrastructure also needs to determine if the in-vehicle resources are sufficient to implement the software update packages to the recipients.

Clause 7: Vehicle and Vehicle Systems Function/Level.

The objective of this clause is to manage risks at the vehicle level, manage vehicle configuration information, communicate with vehicle users about software update campaigns, process software update packages received from the infrastructure, and manage failure during software update campaigns. Each of these functionalities are summarized below:

Managing risks: Upon receiving the software package from the infrastructure, a process shall be defined inside the recipient to analyze, detect, and prevent any potential safety or security risks. ISO 26262-3 and ISO 21434 can be used as a reference for exploring risk management activities for software update engineering.
Managing vehicle configuration information: Like the infrastructure, the vehicle shall have a process to collect vehicle configuration data and maintain its integrity.
Communicating software update campaign: This includes communicating with the vehicle user and obtaining the confirmation for a software update operation. Methods to obtain vehicle user confirmation: in-vehicle display, mobile application, website, contractual agreement.
Processing software update packages: This includes one or more functions which support software update distribution methods (e.g, wireless/wired), arbitrate access requests, handle interruption in communication, verify the integrity and authenticity of the received package.

Clause 8: Software Update Package Assembly.

The objectives of this clause are to identify the target(s) and contents of the software update package, assembling the package with software and related metadata, verification and validation of the software update package, and finally approving the software update package for release. Each of these objectives are summarized below:

Identification of targets and the contents for the software update package: In this stage, the target(s) for a software update package shall be determined. The software and associated metadata released for the identified target(s) shall be selected for the software update package in this phase as well. Examples of metadata include: safe vehicle state, condition, compatibility information, either version information or release information, necessary in-vehicle resources, etc.
Assembly of the software update package: A software update package shall be created. Only the selected software and associated metadata shall be included in the created software update package. An organization should include a unique identifier for each of the software update packages.
Verification and validation of the software update package: During verification and validation the following things need to be checked: compatibility with the existing software and hardware of the target, dependencies for the software update package, necessary in-vehicle resources etc.
Approval for release of the software update package: Upon successful verification and validation, the software update package shall be approved for release.

Clause 9: Software Update Campaign.

The objectives of this clause are to prepare, execute, and complete software update campaigns.

Software update campaign preparation: During the preparation phase, for each software update campaign, the organization shall determine the purpose(s), assign roles & responsibilities, define distribution method(s), obtain permission from the user, and so on.
Software update campaign execution: The execution phase includes obtaining vehicle configuration information to resolve the target into recipient, distribute the software update package to the recipient, verification of the software update package compatibility at least before the activation, error handling and so on.
Software update campaign completion: The end of the software update campaign should be communicated to the vehicle user and related parties.

Cybersecurity Challenges During Software Update Campaigns

Side Channel Attack.

During software update campaigns, cybersecurity challenges arise from side-channel and fault injection attacks, such as glitch attacks. These attacks manipulate the hardware state, causing the software control flow to bypass crucial code segments. This can lead to the CPU skipping certain instructions, compromising the integrity of the update process. For instance, attackers could bypass boot authentication checks, allowing non-genuine or malicious software to be executed on critical components like the Electronic Control Unit (ECU). Such vulnerabilities expose software update mechanisms to significant risks, emphasizing the need for robust protection strategies during campaign execution.

Privilege Distribution.

One effective way to mitigate such attacks is by distributing privileges. Instead of having a single backend server manage the entire OTA process, the responsibilities are split across different roles. For example, OTA functions can be divided into a signing server, time server, and deployment server, so that an attacker would need to compromise multiple systems to deploy malicious software updates. Another example is using multiple signing authorities for software images, which are verified during secure boot. An ECU supplier may sign the software with their own key, even if the OEM also signs it with theirs. This ensures that the OEM cannot alter software the supplier wants to keep unchanged.

Security Objectives of the Software Update Operation

The following security objectives must be achieved during the over-the-air (OTA) or flash programming sessions for a software update operation.

Integrity.

Protecting the integrity of the software binaries, including any associated metadata, is essential because a corrupted software execution environment in the ECU or an altered update package could lead to catastrophic consequences for road safety. This can be achieved using both symmetric and asymmetric cryptography for example: HMAC (Hash-based Message Authentication Code) and digital signatures.

Authenticity.

The authenticity of a software update package can be validated using digital signatures to confirm its origin, ensuring that it comes from a trusted source. This is applicable across multiple levels, including the infrastructure, vehicle systems, and individual ECUs.

Confidentiality.

Software updates for modern vehicles often contain sensitive intellectual property, such as machine learning algorithms, proprietary software, or even user data. Protecting the confidentiality of this information during the update process, and even after the software has been installed, is essential to prevent unauthorized access. Cryptographic measures must be applied to safeguard these assets, with particular attention to protecting encryption keys to avoid potential data breaches.

Accountability.

Accountability is essential to ensure that any party responsible for the creation, distribution, or execution of a defective or malicious software update can be identified and held liable. This prevents the possibility of repudiation, where the origin of the update package could be denied. Cryptographic methods, such as digital signatures, can be used to ensure non-repudiation, ensuring that the supplier or OEM is accountable for the update.

Availability.

The availability of the newly updated software must be maintained, even under potential cyberattacks. If the update process or the software itself becomes unavailable during an attack, it could compromise the safety and functionality of the vehicle. Ensuring the continuous availability of software, possibly through redundancy or failover mechanisms, is crucial to keep vehicle systems operational at all times.

Reference

ISO 24089 – Road Vehicles – Software Update Engineering – https://www.iso.org/standard/77796.html
Automotive Cybersecurity Engineering Handbook by Dr. Ahmad MK Nasser – https://www.amazon.com/Automotive-Cybersecurity-Engineering-Handbook-cyber-resilient/dp/1801076537

Cybersecurity in Automotive Software Update Engineering