How the Secure Over-The-Air (SOTA) tool ensures cyber secure vehicle software updates

What does a secure Over-The-Air software update tool do?

Imagine we have the following situation: the ego vehicle is driving on the road, the monitoring system on the vehicle in front has detected suspicious behaviour of its own and reported to the Roadside Unit (RSU). The RSU identified this abnormality as a vulnerability/bug for the software system, and it has been learnt that it is caused by a compromised or outdated software version. The remediation action of a software update is requested, and the surrounding vehicles, including the ego vehicle, have been informed.

This use case illustrates the need for vulnerability detection and providing software updates and security bugfixes via a secure update mechanism.

In this use case the software update is executed using the SOTA tool in the SELFY project. The primary aim of this tool is to provide secure and efficient delivery of software updates to the vehicle’s Electronic Control Units (ECUs) remotely.

This capability is crucial for maintaining or upgrading vehicle functionalities without the inconvenience of physical dealership visits. It ensures that the latest cybersecurity measures are implemented swiftly, addressing vulnerabilities, and enhancing the vehicle’s safety features. For the connected and automated vehicles, the OTA software update process will be highly significant in upcoming years and accelerate the upgrade of the vehicle software system, as in the mobile world.

Since the OTA update requires the access to the in-vehicle communication system and enables additional attack surfaces remotely to all the ECUs which have the OTA capability, the security of the update process itself is significantly critical. Due to its importance, the United Nations Economic Commission for Europe (UNECE) published in 2021 the regulation R156, requiring the vehicle type approval on the cybersecurity of the software update and the software update management system. In the SELFY project, the security of the OTA software update process is the focus.

The SELFY SOTA tool

The SELFY SOTA tool consists of its core part and integrated tools for facilitating a secure software update process.

Based on the Uptane framework, the core of the SOTA tool includes the following components:

• Uptane Server: This server-side component is responsible for preparing secure software updates, signing them cryptographically, and distributing them to related vehicles. It is the starting point for the secure update lifecycle.
• Primary Client: Embedded within the vehicle, the primary client acts as the intermediate ECU, receiving updates from the server. It verifies the updates’ signatures and integrity before disseminating them to the secondary clients.
• Secondary Clients: These are in-vehicle components, such as ECUs, that receive updates from the primary client. Each of the various secondary clients is responsible for performing independent verification of updates that install in its own, managing its respective vehicle function.

The SOTA tool works together with integrated tools for a secure update preparation and monitoring the secure process. These are:

• Remote Attestation Services (RAS): The RAS ensures the trustworthiness of the vehicle’s ECUs before and after updates are applied, verifying that the system has not been compromised.
• Vehicle Security Operations Center (VSOC): The VSOC monitors the entire update process, alongside the vehicle’s overall security posture, ready to respond to any detected threats or anomalies. Therefore, it provides the Application Programming Interface (API) to connect with the necessary SELFY tools.
• Binary Scanning Tool: This tool leverages machine learning to analyse software update packages, solving the Binary Function Identification Task. It can re-identify known vulnerable functions stored in a database, making it a valuable tool for routine checks in software warehouses or last-minute deployment assessments. This ensures that no known vulnerabilities (e.g., 1-day or n-day vulnerabilities) persist in the binary.

How the secure update process works?

The SOTA tool has the following main sequence of operations:

1. Continuous Monitoring: Throughout this process, the VSOC provides real-time surveillance to oversee the update’s deployment and the vehicle’s cybersecurity status.
2. AI Analysis: The SOTA server proves the release of a new software update package and triggers the completion of the analysis process of the binary scanning tool, which ensures that the update binary does not contain vulnerabilities.
3. Distribution to Primary client: The update package is securely transmitted to the primary client within the vehicle through.
4. Update Verification and Installation: The primary client verifies the update and then distributes it to the secondary clients for installation.

Implementation and demonstration

The SOTA server is implemented based on Uptane standard. Uptane is an open-source framework that ensures the security of software updates for vehicles. Uptane utilizes multiple servers, known as repositories, to provide security through the validation of images before downloading. The server-side implementation contains the following components:

• Image Repository: The image repository can be thought of as an unchanging source of information about images. It is the keeper of every image currently deployed by the OEM, along with the metadata files that prove their authenticity.
• Director Repository: The director repository knows what software should be distributed to each ECU, given the current state of the repository.
• Device Registry: It manages the status and configuration information of devices.
• Console Interface: Command line tools to manage a remote SOTA repository. CURL is used as command line tool for communicating with the SOTA server.

In the vehicle side, there is a primary client, which relates to several secondary clients. In the first step of the update process, the primary client sends its vehicle version manifest to the Director repository. The manifest contains information about existing images.

Using this input, the Director chooses which images should be installed next. The images are then moved to the primary client, which will run a verification process. ECUs are generally classified in terms of access to storage space, memory, a power supply, and a direct internet connection. The form of verification that will be run –Full or Partial– is also based on the resources of the ECUs, as well as how security critical it may be. If the verification indicates no issues, the images can be downloaded to the secondary clients, and finally the software will be updated.

Authors: FEV.io GmbH