[FOTA] Module of ECUs' FOTA unit design
最后更新于
最后更新于
The X-Shield System (XSS) is a GUI feature set used to support AUTOX’s production-secure features and provide auxiliary functions that contain embedded board initialization requirements, OBD diagnosis and analysis, certificate configuration, also include firmware sideloading.
The requirement for a solid and secure firmware update mechanism for ECU devices has been raised in the IoT vehicle industry in order to fix the vulnerabilities of IoT devices as well as implement new features and functionalities or update customized configurations and settings.
Because a FOTA solution needs to cover a wide variety of ECU devices, especially the ones with constrained resources, the AUTOX FOTA solution is built on a light-weight control protocol - MQTT, with KPI to provide a trustworthy channel, and protocol-leveled data transmission scalability leveraging the (USDI). AUTOX FOTA solution is a full-featured firmware update solution for ECU devices, which covers firmware image packaging, control message publishing/subscribing, and metadata campaigning.
AUTOX FOTA solution aligns with the security framework. Uptane was developed in response to the clear need for a comprehensive security model for automotive updates and is the first security system that provides serious compromise resilience in .
FOTA System components include:
Repositories
FOTA Manager (On the primary ECU)
FOTA Download Manager
FOTA Update Manager
FOTA Update Agent (On the secondary ECU)
The most important concept in Uptane is that there are two sets of metadata, from separate sources, that must agree with each other and have valid cryptographic signatures.
Image Repository, the image repository contains metadata for update packages that are valid install targets, and its metadata is signed by a chain of trust.
Director Repository, which controls what updates (selected from the valid install targets) should actually be installed on devices.
The Uptane specification defines several different types of metadata, but the two main files that you need to manage are as follows:
In the Uptane framework, an ECU is categorized as either a Primary or a Secondary ECU. In most cases, a vehicle has one Primary ECU and several Secondary ECUs. The Primary ECU is responsible for downloading and distributing software to the Secondary ECUs. In the AUTOX FOTA solution, the Telematics Control Unit (TCU) serves the role of Primary ECU. A Primary ECU also verifies and distributes the Uptane-compliant metadata associated with each piece of software. Secondary ECUs, such as the Transmission or Body control modules, receive the software and should also perform some form of metadata verification.
The FOTA control message publishing/subscribing should base on the X.509 PKI authentication. And the FOTA message should transform via the TLS using the MSG x.509 certificate[3].
The FOTA package should be signed by Target Key[1], which supports RSA up to 2048-bit keys with RSA PKCS#1 v1.5 signature with hashing mode. The signature hash scheme supports the SHA-256[2]. The FOTA manager should verify the signature of the FOTA package after it is downloaded and before being parsed into firmware components.
The FOTA solution should set up trusted communication between the FOTA Update Manager and the FOTA Update Agent based on the UDS-29 service[4] using the x.509 certificate. Moreover, the FOTA solution should set up secure access based on the UDS-27 service with the FOTA Update Agent.
For anti-rollback, FOTA Current Version is stored in RPMB and updated after each firmware update is successfully done by the FOTA update agent.
The following table summarizes the credentials needed for the FOTA solution:
Credentials
Description
x.509 certificate
For TLS, MQTT Broker with The FOTA download manager.
For the Download Server with the FOTA download manager.
For UDS-29, FOTA download manager with the FOTA update agent.
trust chain
CA cert.
Sign server public key (.pem) (Uptane Targes Key)
For verifying the targets meta data that is signed by the Signing Server.
The FOTA solution overall security arch is shown in the following figure:
Note, the red blocks shall not be included in the FOTA solution on the device side. The green blocks are the FOTA solution’s components
The below steps demonstrate a typical FOTA scenario:
A. Device acquires Model ID and Device ID, and other relevant eFUSE via The Provisioning Tool. B. FOTA admin downloads the corresponding FOTA image’s signer public key and inputs the key to The Provisioning Tool. C. FOTA admin builds new images with the FOTA signer public keys. Target metadata is zipped and uploaded to the image repository. D. The director repository invokes the FOTAGENtool in the image repository to generate a signed new target metadata. E. The target information is stored in the director repository. F. The Director repository publishes a new FOTAREQ message which includes the download URL, version filters, and other parameters to the MQTT broker. G. Device FOTA Download Manager publishes a FOTREG message as registration to the director repository as the device boots. H. Device FOTA Download Manager subscribes to FOTAREQ message and verifies the message using TLS. I. Device FOTA Download Manager interprets the FOTAREQ message and determines whether to download the new FOTA metadata by checking Current Version, version filters, and other parameters. J. Device FOTA Download Manager setups an HTTPS connection with the image repository. (Initial connection triggers provisioning and stores the device root credentials and relevant business root CA) K. Device FOTA Download Manager downloads FOTA metadata from the specific URL to the FOTA cache. L. Device FOTA Download Manager downloads proceeds a sanity-check[5] on the downloaded FOTA package and parses each firmware metadata from it. M. Each firmware in the FOTA cache is loaded by the FOTA update manager. T. The Device FOTA Update Agent will call U-APIs to load the firmware and to update. N. The Device FOTA Update Agent writes the current version and results to the RPMB and the FOTA cache. S. The Device Manager updates ECUs based on the UDS protocol.
The TCU should typically be configured as the primary ECU. The perspective with TCU as the primary ECU is shown in the following figure:
This perspective has limitations in that the TCU cannot access the XCU and CDC using the CANFD protocol. From this point of view, the Ethernet protocol serves solely as a means for transmitting OTA packages.
In the XERO project, the VDU offers more extensive transmission mediums options compared to the TCU's perspective as the primary ECU, such as the CANFD, ETH1000, and ETH100.
When considering transmission mediums, it is more suitable to set the primary ECU to VDU.
A typical ECUs layer is shown in the following figure:
In the FOTA solution, we defined four levels (Level 0 - Level 3) to cover the entire ECUS according to the vehicle structure.
Defined as Level 0: The FOTA manager and FOTA agent are running on the TCU. The FOTA agent is used to update TCU itself.
Defined as Level 1: The FOTA agent is running on this level. The FOTA agent provides some API services such as receiving the FOTA packages, reporting upgrade results, and gathering the version number, etc.
Defined as Level 2: This is NOT in the FOTA scope, the ECU team themselves shall cover the firmware updating. The FOTA agent provides some API services such as receiving the FOTA packages, reporting upgrade results, and gathering the version number, etc.
Defined as Level 3: This is NOT in the FOTA scope, the ECU team themselves shall cover the firmware updating.
1. The FOTA manager (running on the TCU or VDU) downloads the metadata package from the repository and verifies the metadata package using the RSA public key. Then, the FOTA manager parses the metadata into the metadata images for ECUs of level-1.
2. After the FOTA agent (running on ECUs of level-1) receives its metadata image from the FOTA manager, the FOTA agent verifies the metadata image using the RSA public key. If the metadata image belongs to its own, the ECU of level-1 shall execute the Local-OTA process. However, the metadata images are for level-2, the ECU of level-1 shall refresh the corresponding firmware by the UDS (The UDS Security service 0x29 shall be used). (Note, It is NOT in the FOTA scope)
3 & 4. Similarly, the behavior of the ECU in level-3 and level-4 shall align with level-2 and level-3. (It is also NOT in the FOTA scope)
For the flow of the Image and the Director, please refer to the link .
root.json: This file contains information about all the roles that can sign software metadata. To see an example of this metadata, open the root.json file from the TUF (The Update Framework) website.
targets.json: The instance of targets.json in your image repository contains information about all the valid software files. To see an example of this metadata, open the targets.json file from the TUF (The Update Framework) website.
The FOTA metadata downloading is via TLS, and the FOTA business secrets such as RSA keypair and X.509 certificate are managed by the crypto hardware engine. The FOTA download manager is responsible to establish and maintain the TLS connection via the library using the x.509 certificate[3].
All of the credentials (certs, public keys, etc, shall be injected by the trusted X-Shield Provisioning Tool). For the provisioning tool, please refer to the link: [5]. Moreover, The provisioning tool helps the FOTA solution to set up the trust chain (CA cert).
The [1] defined in . The key is used to sign the "targets" metadata file for software updates. This file contains information about all the valid software files in your software repository.
The [2] defined in . The public key cryptographic algorithm used by the key (such as RSA or ECDSA). The particular scheme used to verify the signature (such as rsassa-pss-sha256 or ecdsa-sha2-nistp256)
The [3] defined in s. The Director repository could utilize other mechanisms to uniquely identify a vehicle (e.g., 2-way TLS with unique client certificates)
The [4] defined in , Problems associated with OBD or UDS programming of ECUs, such as authentication of communications between ECUs is outside the scope of the Uptane.
The [5] defined in .
The Provisioning Suite in
The [5] defined in An in-vehicle client on a Primary ECU is capable of verifying the signatures on all update metadata and downloading updates on behalf of its associated Secondary ECUs. The Primary ECU can be the same ECU that communicates with the server.
