Security OTA upgrading system and method for automobile domain centralized E / E architecture

Abstract

The invention relates to a safe OTA upgrading system and method for an automobile domain centralized E / E framework. The system framework is composed of a cloud end and an automobile end. An automobile domain centralized E / E framework is adopted, the framework takes a time-sensitive network as a backbone network, five sub-domains are connected with a central gateway, and the five sub-domains are respectively a power assembly domain, a chassis domain, an advanced driving assistance system domain, an automobile body domain and an infotainment domain; each sub-domain takes a domain controller as a center and is connected with a plurality of ECUs (electronic control units) in the domain through a controller local area network, a flexible data rate CAN (controller area network) or a media-oriented system transmission network and the like, and the automobile domain centralized E / E architecture realizes unified and centralized management of a software platform by integrating a plurality of function-related ECUs into a unified DCU (data control unit). The upgrading method comprises the steps of identity authentication, upgrading control and safe upgrading. The limitation of traditional independent ECU upgrading is broken through, a global upgrading strategy is designed based on the domain centralized E / E architecture, and the current automobile E / E architecture is adapted through a unified certificate system and communication protocol management.

Description

Technical Field

[0001] The present invention relates to the field of automotive OTA upgrades, and in particular to a secure OTA upgrade system and method for an automotive-domain centralized E / E architecture. Background Art

[0002] To meet the high-bandwidth and low-latency communication requirements of smart cars, a domain-centralized electrical and electronic architecture has become the preferred architecture for mass-produced smart cars by various automakers. With the increasing deployment of application systems in smart cars, automotive software architectures are shifting toward a service-oriented architecture (SOA), leading to increasingly frequent software updates. However, software upgrades solely through dealerships or recalls to the original manufacturer fail to provide an optimal user experience and increase after-sales costs, leading to the emergence of over-the-air (OTA) software updates. However, OTA updates require the vehicle to open an interface for communication with the cloud, making the update package vulnerable to cyberattacks during the update process, threatening system security. For example, in September 2016, Tencent's Keen Security Lab exploited a vulnerability to remotely access Tesla's electrical network without physical contact, prompting Tesla to implement a "code signing" mechanism to enforce integrity verification for firmware upgrades. In 2017, Tencent's Keen Lab again discovered multiple high-severity security vulnerabilities in Tesla and achieved a contactless remote attack, enabling arbitrary remote control of the vehicle in both parking and driving modes. Such incidents have prompted the refinement of relevant policies. For example, China's Ministry of Industry and Information Technology (MIIT) issued the "Guidelines for the Management and Technology of Product Access, Recalls, and Online Software Upgrades for Intelligent Connected Vehicles." These guidelines explicitly require that OTA upgrades be fully tested and verified, clearly inform users of risks, ensure data security, and prohibit the mixing of assisted and autonomous driving functions. Furthermore, industry alliance documents, such as the "Current Status and Recommendations for the Development of Remote Upgrades (OTA) for Intelligent Connected Vehicles," emphasize the establishment of a technical standards system to promote "cloud-pipeline-end" collaboration and ensure safe and controllable upgrades. As the fundamental supporting platform for realizing automotive system functions, the automotive E / E architecture undertakes core functions such as the topology design and communication protocol management of the entire vehicle's electronic system. Therefore, vehicle-level scenario integration is a key challenge for automotive OTA upgrades. Existing automotive OTA upgrade solutions primarily focus on node-level updates of individual electronic control units (ECUs) and lack system-level consideration of the entire vehicle's electrical / electronic (E / E) architecture.

[0003] At the security level, existing solutions often only partially address the CIA (Confidentiality, Integrity, and Availability) triad, and a comprehensive protection system that simultaneously addresses all three has yet to be established. This is particularly true in vehicle cyber-physical systems (CPS) scenarios, where preventing upgrade package leaks, ensuring data integrity, and maintaining functional continuity of critical systems during upgrades are essential. Together, these three elements form the security cornerstone of automotive OTA upgrades.

[0004] To improve the security of automotive OTA software updates, current solutions include those based on blockchain and HSM technologies. Blockchain-based OTA software updates can quickly verify the authenticity and integrity of update packages, but their high computational and storage requirements limit their practical application. HSM-based solutions provide high security and trustworthiness through specially designed hardware, but this inevitably increases system cost and complexity. Due to their low cost, low complexity, and high flexibility, secure OTA update solutions based on cryptographic algorithms are widely adopted. However, these cryptographic-based OTA update solutions only consider a few nodes in the automotive network and do not take into account the E / E architecture of the automotive system. Furthermore, these OTA update solutions fail to simultaneously provide the CIA triples, identity authentication, and the comprehensive information security of the update package for automotive OTA updates. Summary of the Invention

[0005] Based on this, in order to solve the above problems, the present invention proposes a secure OTA upgrade method for centralized E / E architecture in the automotive domain. This solution adapts to the development of modern automotive E / E architecture, while also ensuring the security properties of the CIA triplet as well as security properties such as package freshness and node identity authentication. The present invention is based on cryptographic algorithms, provides identity authentication for each participant in the OTA upgrade through digital certificates, ensures the availability and legitimacy of communications through access control based on symmetric encryption algorithms, and ensures the confidentiality and integrity of upgrade packages based on symmetric encryption and HASH algorithms; at the same time, a timestamp is added to each message to ensure the freshness of the message and upgrade package.

[0006] A secure OTA upgrade method for a centralized E / E architecture in an automotive domain, including an automotive OTA upgrade system architecture;

[0007] The system architecture consists of two components: the cloud and the vehicle. The cloud refers to the OTA cloud server, which is responsible for the management, storage, and distribution of software upgrade packages (provided by the OEM) and communicates with the vehicle through the Telematics Control Unit (TCU). The TCU, also part of the vehicle, facilitates data transmission between the vehicle and the cloud server via cellular networks (such as 4G / 5G), Wi-Fi, Ethernet, and other communication methods. It is a key node for downloading update packages during the OTA upgrade process. The vehicle refers to the OTA software upgrade target and adopts a centralized automotive E / E architecture. This architecture uses Time-Sensitive Networking (TSN) as its backbone network, connecting five subdomains to a central gateway: the powertrain domain, the chassis domain, the Advanced Driver Assistance Systems (ADAS) domain, the body domain, and the infotainment domain. Each subdomain is centered around a Domain Control Unit (DCU), connecting multiple ECUs within the domain via networks such as the Controller Area Network (CAN), CAN with Flexible Data-Rate (CAN-DF), and Media Oriented Systems Transport (MOST). This invention adopts a centralized automotive domain E / E architecture as the automotive system architecture because it offers significant advantages over traditional distributed E / E architectures. First, by integrating multiple functionally related ECUs into a unified DCU, the domain-centralized E / E architecture unifies and centrally manages the software platform, simplifying the OTA upgrade process and effectively avoiding the version control confusion and upgrade coordination difficulties associated with the diverse ECU types and heterogeneous platforms in distributed architectures. Second, the DCU boasts stronger computing and storage capabilities, supporting differential upgrades and modular deployment strategies, effectively reducing the amount of data transmission and network resource consumption required for upgrades. In addition, centralized software management also facilitates the implementation of mechanisms such as partition protection, image verification, and failure rollback, thereby significantly improving the reliability and fault tolerance of the OTA process and reducing system risks caused by upgrade failures.

[0008] A secure OTA upgrade method for a centralized E / E architecture in the automotive domain. The secure OTA software upgrade solution proposed in the present invention uses the central gateway in the centralized E / E architecture in the automotive domain as the master node and the DCU, TCU, ECU and OTA cloud server as slave nodes to complete the three steps of secure OTA upgrade: step 1 identity authentication; step 2 upgrade control; step 3 secure upgrade.

[0009] Step 1: Identity Authentication. In a centralized automotive E / E architecture, an end-to-end identity authentication process is required to ensure the legitimacy of each node before establishing communication and executing OTA software updates. The authentication mechanism proposed in this paper covers bidirectional authentication between the central gateway and all slave nodes (including DCUs, ECUs, TCUs, and OTA cloud servers). The overall process is divided into four key steps: Step 1.1 OTA cloud server notification; Step 1.2 Central gateway broadcast; Step 1.3 Slave node registration; and Step 1.4 Central gateway response.

[0010] Step 1.1: OTA cloud server notification.

[0011] When a new software version becomes available, the OTA cloud server sends an update notification to the vehicle owner via the TCU. The TCU then prompts the owner to confirm the update through the human-machine interface. Once the owner agrees, the OTA cloud server officially initiates the upgrade process and sends its digital certificate to the central gateway for identity verification. This digital certificate is issued by a reputable third-party Certificate Authority (CA) using the standard X.509 format. The certificate includes the node's public key, public key algorithm identifier, certificate serial number, validity period, issuer information, and the node's unique identifier. It also carries the CA's digital signature, ensuring the certificate's technical and legal credibility.

[0012] Step 1.2: Central gateway broadcasts.

[0013] After receiving the digital certificate from the OTA cloud server, the central gateway verifies its digital signature using its built-in CA root certificate to ensure the certificate has not been forged or tampered with. Once verified, the central gateway extracts the OTA cloud server's public key for subsequent encrypted communication and key negotiation. The central gateway then broadcasts its digital certificate to all slave nodes (DCU, ECU, TCU, and OTA cloud server). Certificate broadcasting is a key step in establishing a system trust chain. Upon receiving the central gateway's certificate, each slave node verifies its signature to confirm its legitimacy, laying the foundation for trust in subsequent authentication interactions.

[0014] Step 1.3: Register from the node.

[0015] After completing the legitimacy verification of the central gateway's digital certificate, each slave node needs to register its own identity with the central gateway to complete the establishment of mutual trust. The content of the registration message varies slightly depending on the node type. Since the OTA cloud server has submitted its digital certificate in the notification stage, it only needs to send information such as the symmetric key and timestamp during the registration stage. These sensitive data are encrypted with the central gateway's public key and digitally signed to ensure the confidentiality, integrity and non-repudiation of the message. The registration messages of DCU, ECU and TCU include their digital certificates, symmetric keys and timestamps. Among them, the digital certificate is used by the central gateway to verify the legitimacy of its identity, while key fields such as the symmetric key and timestamp are encrypted with the central gateway's public key and digitally signed at the same time to prevent data leakage and tampering.

[0016] Step 1.4: The central gateway responds.

[0017] The central gateway receives registration information from slave nodes. For DCUs, ECUs, and TCUs, it first verifies the digital certificate signatures to confirm the validity of the certificates and obtains the node's public key. The central gateway then uses its private key to decrypt sensitive data (such as the symmetric key and timestamp) encrypted with the public key in the registration message and verifies the digital signature to ensure the message's authenticity, integrity, and non-repudiation. Furthermore, the central gateway generates a current timestamp and compares it with the timestamp in the registration message to verify the timeliness and freshness of the message to prevent replay attacks. After completing all verifications, the central gateway sends a response message to the corresponding slave node (DCU, ECU, TCU, and OTA cloud server). This response message contains information such as the timestamp generated by the central gateway and is encrypted using the symmetric key provided by the slave node, ensuring that the message can only be decrypted and read by authorized nodes. Upon receiving the response message, the slave node decrypts the content using its own symmetric key and verifies the timeliness and authenticity of the response by comparing information such as the timestamp, thus completing the closed-loop authentication process.

[0018] Step 2: Upgrade Control

[0019] Upgrade control refers to the centralized management and security control of the entire OTA upgrade process by the central gateway, acting as the master node, after completing identity authentication between the master and slave nodes, ensuring the legitimacy, controllability, and security of the upgrade process. This phase consists of two key steps: Step 2.1, OTA cloud server upgrade request, and Step 2.2, central gateway authorization of the upgrade.

[0020] Step 2.1: OTA cloud server upgrade request.

[0021] The OTA cloud server initiates an upgrade request to the central gateway. The request message includes the upgrade target (e.g., multiple ECUs, DCUs, etc.), upgrade package configuration information (e.g., target version number, product type, upgrade module type), and a timestamp generated by the OTA cloud server. To ensure communication confidentiality, the request message is encrypted using the symmetric key agreed upon between the OTA cloud server and the central gateway.

[0022] Step 2.2: Central Gateway Authorization Upgrade.

[0023] After receiving the upgrade request from the OTA cloud server, the central gateway performs consistency verification and policy review to determine whether the upgrade package configuration, upgrade node permissions, and the current vehicle status allow the upgrade operation (for example, whether the vehicle is stationary, safe, and controllable). Once verification is successful, the central gateway generates a unique upgrade key for this upgrade. This key is used for encrypted transmission of the subsequent upgrade package and HMAC calculation. The central gateway then encrypts the upgrade key and sends it to each upgrade node (including multiple ECUs, DCUs, etc.) and the OTA cloud server using the respective symmetric keys established during the authentication phase. It is important to emphasize that within an OTA task, all upgrade nodes use the same upgrade key to ensure data consistency and synchronization. Each authorized upgrade message also includes the central gateway's current timestamp to ensure message freshness. After decryption, the receiving node must compare this timestamp with its own timestamp to prevent replay attacks.

[0024] Step 3: Security Upgrade

[0025] A secure upgrade primarily involves the OTA cloud server securely sending the upgrade package to each target, ensuring its confidentiality and integrity. The OTA cloud server uses the upgrade key to encrypt the package to be upgraded and the OTA cloud server's timestamp. It also calculates an HMAC value between the package and the timestamp for subsequent integrity verification. The OTA cloud server then sends the encrypted package along with the corresponding HMAC value to each target node. Upon receiving the message, the upgrade node first decrypts the package using the upgrade key and recalculates its local HMAC value (denoted as HMAC*) based on the same upgrade key. This value is then compared with the HMAC value sent by the OTA cloud server. If the two match, the upgrade package is confirmed to have not been tampered with during transmission. The upgrade node then generates a timestamp and compares it with the received timestamp to ensure message freshness. The upgrade node then enters the software writing and functional verification process, completing the upgrade. After the upgrade is complete, each node reports the upgrade status (success, failure, or exception) to the central gateway and the OTA cloud server for system status archiving and subsequent maintenance. This mechanism effectively prevents the risk of upgrade package leakage and tampering through the dual means of encrypted transmission and integrity verification, ensuring the security and reliability of vehicle function updates.

[0026] This invention utilizes multiple cryptographic algorithms to provide five key security attributes for automotive OTA upgrades: authentication, confidentiality, integrity, availability, and freshness. This is achieved through three phases: authentication, upgrade control, and secure upgrade. Specifically, digital certificates are used to ensure the identity of the OTA upgrade node; symmetric encryption and timestamps are used to ensure availability, confidentiality, and freshness for upgrade control; and symmetric encryption, HMAC, and timestamps are used to provide confidentiality, integrity, and freshness for secure upgrades.

[0027] Compared with the prior art, the present invention has the following beneficial effects:

[0028] 1. Achieve secure upgrades for the automotive domain-centralized E / E architecture. Break through the limitations of traditional independent ECU upgrades, design a global upgrade strategy based on the domain-centralized E / E architecture, and adapt to the current automotive E / E architecture through a unified certificate system and communication protocol management. The domain-centralized E / E architecture integrates multiple function-related ECUs into a unified DCU, achieving unified and centralized management of the software platform. This can simplify the OTA upgrade process and effectively avoid the version control confusion and upgrade coordination difficulties caused by the wide variety of ECUs and heterogeneous platforms in the distributed architecture. Secondly, the DCU has stronger computing and storage capabilities, can support differential upgrades and modular deployment strategies, and effectively reduce the amount of data transmission and network resource consumption required for upgrades. In addition, centralized software management also facilitates the implementation of mechanisms such as partition protection, image verification, and failure rollback, thereby significantly improving the reliability and fault tolerance of the OTA process and reducing system risks caused by upgrade failures.

[0029] 2. Build a multi-dimensional integrated security protection system. Through the three-stage progressive protection of "authentication-control-upgrade", multiple cryptographic combinations such as digital certificates + symmetric encryption + HMAC + timestamp are adopted to achieve five core security attributes simultaneously in OTA scenarios. Identity authentication: Digital certificates based on the PKI system ensure two-way trusted authentication of cloud, central gateway, TCU, DCU and other nodes to prevent spoofing attacks; confidentiality: Symmetric encryption algorithms ensure the security of upgrade package transmission and storage to prevent sensitive data leakage; integrity: HMAC algorithm generates message verification codes to detect upgrade package tampering in real time; availability: dynamic key negotiation mechanism combined with lightweight protocol design to avoid communication congestion caused by encryption load; anti-replay: dual verification mechanism of timestamp and non-repetitive serial number to effectively resist replay attacks.

[0030] 3. Focusing on the centralized architecture characteristics of intelligent connected vehicle domains, research a secure OTA upgrade framework that complies with UNECE R156 and ISO 24089 standards, covering cloud-vehicle collaborative authentication, encrypted communication, firmware signature verification, and anti-replay attack mechanisms. Design an end-to-end upgrade process threat model and protection strategy, and establish a security testing and verification system to ensure that the entire upgrade chain meets the dual goals of functional safety and information security. Provide the industry with standardized implementation paths and compliance management recommendations. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a schematic diagram of the automotive OTA upgrade architecture for the centralized E / E architecture in the automotive domain of the present invention;

[0032] Figure 2 This is the basic flow chart of the secure OTA upgrade for the centralized E / E architecture in the automotive domain of the present invention;

[0033] Figure 3This is a schematic diagram of the automotive OTA software upgrade framework for the centralized E / E architecture in the automotive domain of the present invention;

[0034] Figure 4 This is a schematic diagram of the secure OTA upgrade topology platform for the centralized E / E architecture in the automotive domain of the present invention;

[0035] Figure 5 This is a schematic diagram of the automotive OTA upgrade hardware platform for the centralized E / E architecture in the automotive domain according to the present invention. DETAILED DESCRIPTION

[0036] To facilitate understanding of the present invention, the present invention will be described more fully below with reference to the accompanying drawings. The accompanying drawings illustrate preferred embodiments of the present invention. However, the present invention may be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the present disclosure.

[0037] Based on the STRIDE threat model, this paper analyzes the standard automotive OTA process and designs a secure OTA upgrade solution centered on authentication and authorization, based on international standards for in-vehicle software updates, such as UNECE R156 and ISO 24089. This solution aims to ensure the authenticity, confidentiality, integrity, availability, and freshness of the entire upgrade process.

[0038] To effectively demonstrate the security properties of the security protocol, the present invention uses the ProVerif tool to formally verify the security protocol. ProVerif logically infers the protocol's reachability and correspondence assertions under the Dolev–Yao model. The verification results demonstrate that the secure OTA upgrade framework meets identity authentication, confidentiality, integrity, availability, and message freshness requirements.

[0039] A prototype system for secure OTA upgrades was built using the automotive-grade SJA1105Q-EVB (TSN switch) and LS1028A (ECU) chips. By simulating actual upgrade scenarios, functional verification and comprehensive evaluation of performance and resource overhead were carried out.

[0040] A secure OTA upgrade system for a centralized E / E architecture in an automotive domain, including an automotive OTA upgrade system architecture;

[0041] like Figure 1As shown in the figure, the system architecture consists of two components: the cloud and the vehicle. The cloud refers to the OTA cloud server, responsible for the management, storage, and distribution of software upgrade packages (provided by the OEM). It communicates with the vehicle through the Telematics Control Unit (TCU). The TCU, also part of the vehicle, facilitates data transmission between the vehicle and the cloud server via cellular networks (such as 4G / 5G), Wi-Fi, Ethernet, and other communication methods. It is a key node for downloading update packages during the OTA upgrade process. The vehicle, the target of OTA software upgrades, adopts a centralized automotive E / E architecture. This architecture uses Time-Sensitive Networking (TSN) as its backbone, connecting five subdomains to a central gateway: the powertrain domain, the chassis domain, the Advanced Driver Assistance Systems (ADAS) domain, the body domain, and the infotainment domain. Each subdomain is centered around a Domain Control Unit (DCU), connecting multiple ECUs within the domain via networks such as the Controller Area Network (CAN), CAN with Flexible Data-Rate (CAN-DF), and Media Oriented Systems Transport (MOST). This invention adopts a centralized automotive domain E / E architecture as its automotive system architecture because it offers significant advantages over traditional distributed E / E architectures. First, by integrating multiple functionally related ECUs into a unified DCU, the domain-centralized E / E architecture unifies and centrally manages the software platform, simplifying the OTA upgrade process and effectively avoiding the version control confusion and upgrade coordination difficulties associated with the diverse ECU types and heterogeneous platforms in distributed architectures. Second, the DCU boasts stronger computing and storage capabilities, supporting differential upgrades and modular deployment strategies, effectively reducing the amount of data transmission and network resource consumption required for upgrades. In addition, centralized software management also facilitates the implementation of mechanisms such as partition protection, image verification, and failure rollback, thereby significantly improving the reliability and fault tolerance of the OTA process and reducing system risks caused by upgrade failures.

[0042] A secure OTA upgrade method for a centralized E / E architecture in the automotive domain, which also includes an automotive secure OTA software upgrade framework, uses the central gateway in the centralized E / E architecture in the automotive domain as the master node and the DCU, TCU, ECU, and OTA cloud server as slave nodes to complete the three steps of secure OTA upgrade: Step 1: identity authentication; Step 2: upgrade control; Step 3: secure upgrade. Figure 2 The figure shows the basic process of secure OTA upgrade of the present invention, taking the ECU upgrade process in the infotainment domain as an example.

[0043] Step 1: Identity authentication. In the centralized E / E architecture of the automotive domain, in order to ensure the legitimacy of the identity of each node before establishing communication and executing OTA software upgrades, an end-to-end identity authentication process must be completed first. The identity authentication mechanism proposed in this invention covers two-way identity authentication between the central gateway and all slave nodes (including DCU, ECU, TCU and OTA cloud server). The overall process is divided into four key steps: Step 1.1 OTA cloud server notification; Step 1.2 Central gateway broadcast; Step 1.3 Slave node registration; Step 1.4 Central gateway response. Figure 3 As shown in part (1).

[0044] Step 1.1: OTA cloud server notification.

[0045] When a new software version becomes available, the OTA cloud server sends an update notification to the vehicle owner via the TCU. The TCU then prompts the owner to confirm the update through the human-machine interface. Once the owner agrees, the OTA cloud server officially initiates the upgrade process and sends its digital certificate to the central gateway for identity verification. This digital certificate is issued by a reputable third-party Certificate Authority (CA) using the standard X.509 format. The certificate includes the node's public key, public key algorithm identifier, certificate serial number, validity period, issuer information, and the node's unique identifier. It also carries the CA's digital signature, ensuring the certificate's technical and legal credibility.

[0046] Step 1.2: Central gateway broadcasts.

[0047] After receiving the digital certificate from the OTA cloud server, the central gateway verifies its digital signature using its built-in CA root certificate to ensure the certificate has not been forged or tampered with. Once verified, the central gateway extracts the OTA cloud server's public key for subsequent encrypted communication and key negotiation. The central gateway then broadcasts its digital certificate to all slave nodes (DCU, ECU, TCU, and OTA cloud server). Certificate broadcasting is a key step in establishing a system trust chain. Upon receiving the central gateway's certificate, each slave node verifies its signature to confirm its legitimacy, laying the foundation for trust in subsequent authentication interactions.

[0048] Step 1.3: Register from the node.

[0049] After completing the legitimacy verification of the central gateway's digital certificate, each slave node needs to register its own identity with the central gateway to complete the establishment of mutual trust. The content of the registration message varies slightly depending on the node type. Since the OTA cloud server has submitted its digital certificate in the notification stage, it only needs to send information such as the symmetric key and timestamp during the registration stage. These sensitive data are encrypted with the central gateway's public key and digitally signed to ensure the confidentiality, integrity and non-repudiation of the message. The registration messages of DCU, ECU and TCU include their digital certificates, symmetric keys and timestamps. Among them, the digital certificate is used by the central gateway to verify the legitimacy of its identity, while key fields such as the symmetric key and timestamp are encrypted with the central gateway's public key and digitally signed at the same time to prevent data leakage and tampering.

[0050] Step 1.4: The central gateway responds.

[0051] The central gateway receives registration information from slave nodes. For DCUs, ECUs, and TCUs, it first verifies the digital certificate signatures to confirm the validity of the certificates and obtains the node's public key. The central gateway then uses its private key to decrypt sensitive data (such as the symmetric key and timestamp) encrypted with the public key in the registration message and verifies the digital signature to ensure the message's authenticity, integrity, and non-repudiation. Furthermore, the central gateway generates a current timestamp and compares it with the timestamp in the registration message to verify the timeliness and freshness of the message to prevent replay attacks. After completing all verifications, the central gateway sends a response message to the corresponding slave node (DCU, ECU, TCU, and OTA cloud server). This response message contains information such as the timestamp generated by the central gateway and is encrypted using the symmetric key provided by the slave node, ensuring that the message can only be decrypted and read by authorized nodes. Upon receiving the response message, the slave node decrypts the content using its own symmetric key and verifies the timeliness and authenticity of the response by comparing information such as the timestamp, thus completing the closed-loop authentication process.

[0052] Step 2: Upgrade Control

[0053] Upgrade control means that after completing the identity authentication of the master and slave nodes, the central gateway acts as the master node to uniformly manage and securely control the entire OTA upgrade process to ensure the legitimacy, controllability and security of the upgrade process. This stage mainly includes two key steps: step 2.1, OTA cloud server upgrade request, step 2.2, central gateway authorization upgrade, such as Figure 3 As shown in part (2).

[0054] Step 2.1: OTA cloud server upgrade request.

[0055] The OTA cloud server initiates an upgrade request to the central gateway. The request message includes the upgrade target (e.g., multiple ECUs, DCUs, etc.), upgrade package configuration information (e.g., target version number, product type, upgrade module type), and a timestamp generated by the OTA cloud server. To ensure communication confidentiality, the request message is encrypted using the symmetric key agreed upon between the OTA cloud server and the central gateway.

[0056] Step 2.2: Central Gateway Authorization Upgrade.

[0057] After receiving the upgrade request from the OTA cloud server, the central gateway performs consistency verification and policy review to determine whether the upgrade package configuration, upgrade node permissions, and the current vehicle status allow the upgrade operation (for example, whether the vehicle is stationary, safe, and controllable). Once verification is successful, the central gateway generates a unique upgrade key for this upgrade. This key is used for encrypted transmission of the subsequent upgrade package and HMAC calculation. The central gateway then encrypts the upgrade key and sends it to each upgrade node (including multiple ECUs, DCUs, etc.) and the OTA cloud server using the respective symmetric keys established during the authentication phase. It is important to emphasize that within an OTA task, all upgrade nodes use the same upgrade key to ensure data consistency and synchronization. Each authorized upgrade message also includes the central gateway's current timestamp to ensure message freshness. After decryption, the receiving node must compare this timestamp with its own timestamp to prevent replay attacks.

[0058] Step 3: Security Upgrade

[0059] Secure upgrade mainly refers to the OTA cloud server sending the upgrade package to each upgrade target securely to ensure the confidentiality and integrity of the upgrade package. The specific process is as follows Figure 3As shown in part (3), the OTA cloud server uses the upgrade key to encrypt the software package to be upgraded and the timestamp of the OTA cloud server, and calculates the HMAC value of the upgrade package and the timestamp for subsequent integrity verification. Subsequently, the OTA cloud server sends the encrypted software package and the corresponding HMAC value to each target node. After receiving the message, the upgrade node first uses the upgrade key to decrypt the software package, and recalculates the local HMAC value (denoted as HMAC*) based on the same upgrade key, and compares it with the HMAC sent by the OTA cloud server. If the two are consistent, it is confirmed that the upgrade package has not been tampered with during the transmission process. Then, the upgrade node generates the timestamp at this time and compares it with the received timestamp to ensure the freshness of the message. The upgrade node enters the software writing and function verification process to complete the upgrade process. After the upgrade is completed, each node will feedback the upgrade status (success, failure or abnormal information) to the central gateway and OTA cloud server for system status archiving and subsequent maintenance. This mechanism effectively prevents the risk of upgrade package leakage and tampering through the dual means of encrypted transmission and integrity verification, ensuring the security and reliability of vehicle function updates.

[0060] Furthermore, the present invention uses the ProVerif tool to verify the security properties of the invented automotive OTA software upgrade framework, including identity authentication, confidentiality, integrity, access control and data freshness.

[0061] ProVerif is a formal tool for automatically verifying the security of cryptographic algorithms. Developed by Bruno Blanchet in 2002, it is widely used to verify the security properties of various real-world network protocols. ProVerif uses the Dolev-Yao model as its attack model, which assumes that cryptographic algorithms are perfect and allows attackers to conduct malicious attacks (such as eavesdropping, tampering, injection, and man-in-the-middle attacks) on public communication channels. ProVerif supports the verification of various network security properties, such as confidentiality, authentication, and communication security.

[0062] ProVerif's operational process consists of three steps: 1) ProVerif input, 2) core processing, and 3) ProVerif output. 1) ProVerif input: Consists of security protocols and security properties. Security protocols are described using the applied pi-calculus, while security properties are described through a combination of events and queries. 2) Core processing: After receiving input, ProVerif first automatically converts the security protocol into a Horn terminology set and converts the security properties into derived queries against these Horn terms. ProVerif then automatically detects whether an attacker can violate the asserted security properties through logical deduction. 3) ProVerif output: If the security protocol satisfies the security properties through logical deduction, ProVerif displays a "true" result; otherwise, it displays a "false" result. For security properties that are not met, ProVerif also attempts to reconstruct the attack and provides feasible attack paths to enable researchers to improve the security protocol design.

[0063] The following are the specific verification contents:

[0064] (1) Identity authentication and verification: Before the OTA upgrade package is distributed and upgraded, the central gateway must perform mutual identity authentication with the OTA cloud server and each node in the vehicle (TCU, DCU, ECU, etc.). In order to evaluate the identity authentication properties of the secure OTA upgrade framework of the present invention, ProVerif captures two consistency assertions: query (1) and query (2), where eventBeginServer() indicates that the OTA cloud server initiates an authentication request to the gateway; eventBeginGateway() indicates that the gateway initiates an authentication request to the OTA cloud server; eventEndServer() indicates that the OTA cloud server successfully verifies the legitimate identity of the gateway; eventEndGateway() indicates that the gateway successfully verifies the legitimate identity of the OTA cloud server. Query (1) verifies that whenever eventEndGateway() occurs, eventBeginServer() must have occurred. Similarly, query (2) ensures that whenever eventEndServer() occurs, eventBeginGateway() must have also been executed. Successful verification of these queries indicates that the secure OTA upgrade framework of the present invention can provide authentication; otherwise, it means that authentication failed.

[0065] query (1): inj−event (EndGateway( )) ==> inj−event (BeginServer( ))

[0066] query (2): inj−event (EndServer( )) ==> inj−event (BeginGateway( ))

[0067] (2) Confidentiality Verification: The confidentiality of the secure OTA upgrade framework of the present invention involves three objects: node symmetric key, upgrade key and upgrade package. The confidentiality of the node symmetric key ensures the secure execution of the authorization process, while the confidentiality of the upgrade key and upgrade package ensures the secure distribution of the upgrade package. The secure OTA upgrade framework of the present invention verifies confidentiality by querying whether the attacker can access these three objects. These queries are listed in query (3), (4) and (5), where AuthorizationKEY, DistributionKEY and UpdatePKG represent the node symmetric key, upgrade key and upgrade package respectively. If the attacker can access these objects, it means that the confidentiality of the secure OTA upgrade framework of the present invention has been destroyed. On the contrary, if the attacker cannot access these objects, it means that the confidentiality of LigSecOTA is effectively protected.

[0068] query (3): attacker (AuthorizationKEY).

[0069] query (4): attacker (DistributionKEY).

[0070] query (5): attacker (UpdatePKG).

[0071] (3) Integrity Verification: The integrity of the secure OTA upgrade framework of the present invention ensures that the upgrade package remains unchanged during the distribution process from the OTA cloud server to the designated upgrade node. The secure OTA upgrade framework of the present invention uses the HMAC function to ensure the integrity of the upgrade package. ProVerif cannot directly verify the integrity, but ensuring the confidentiality of the symmetric key (i.e., the upgrade key) can ensure the accurate execution of the HMAC function. Therefore, ProVerif can verify the integrity by verifying the confidentiality of the upgrade key, using query (4) as described.

[0072] (4) Availability Verification: The upgrade control mechanism in the secure OTA upgrade framework of the present invention ensures that the central gateway shares the upgrade key with the OTA cloud server and the target upgrade object under a legitimate upgrade request, thereby achieving secure distribution of the upgrade package. Similar to integrity, ProVerif cannot directly verify access control. However, the secure execution of upgrade control depends on the confidentiality of the node symmetric key, because the sharing process of the upgrade key depends on the secure execution of upgrade control. Therefore, ProVerif indirectly verifies the upgrade control attribute by confirming the confidentiality of the node stack key and the upgrade key, which corresponds to queries (4) and (5).

[0073] (5) Data freshness verification: The freshness of the upgrade package in the secure OTA upgrade framework of the present invention can be ensured by comparing timestamps. Similar to the integrity and upgrade control attributes, ProVerif cannot directly verify the data freshness attribute. The secure transmission of timestamps relies on the confidentiality of the node symmetric key and the upgrade key. Therefore, ProVerif can indirectly verify data freshness by confirming the confidentiality of these keys. That is, ProVerif can use query (4) and query (5) to verify data freshness.

[0074] The secure OTA upgrade framework of the present invention is input into ProVerif for analysis. After automatic processing by ProVerif, the verification results of query (1) and query (2) are both true, which proves that the secure OTA upgrade framework of the present invention can provide authentication between the central gateway and the OTA cloud server, and between the central gateway and each node in the vehicle. Similarly, the verification results of query (3), query (4), and query (5) are also true, which shows that the secure OTA upgrade framework of the present invention can provide confidentiality for the node symmetric key, upgrade key, and upgrade package, respectively. Similarly, the secure OTA upgrade framework of the present invention can also ensure integrity and upgrade control.

[0075] The present invention also includes a hardware platform construction for a secure OTA upgrade method for a centralized E / E architecture in the automotive domain. The present invention constructs a hardware prototype platform for a centralized E / E architecture in the automotive domain for secure OTA software upgrades. The topology of the platform is as follows: Figure 4As shown, the system includes a central gateway, three DCUs, a TCU, and an OTA cloud server. The central gateway communicates with the DCUs and TCUs using Transit Network (TSN), while the DCUs and their internal ECUs exchange data based on the CAN-FD protocol. Because the central gateway must not only support the concurrent transmission of multiple communication flows but also process the relevant data, it consists of a TSN switch and a processor that supports both TSN and CAN-FD. The following describes the equipment elements required to implement a centralized automotive E / E architecture.

[0076] 1. TSN switch: This is represented by the SJA1105Q-EVB, used to implement TSN networking. The SJA1105Q-EVB is a mainstream automotive-grade TSN switch developed by NXP Semiconductors. It is a five-port switch chip development board specifically designed to support high-performance in-vehicle AVB / TSN networks. The SJA1105Q includes configurable TSN features (such as the Credit-Based Shaper (CBS) defined in 802.1Qav and the Time Awareness Shaper (TAS) defined in IEEE 802.1Qbv), and can be configured to deliver 100Mbps or 1Gbps data rates as needed.

[0077] 2. Central Gateway and TCU / ECU / DCU: This is represented by the LS1028A development board, a processor developed by NXP Semiconductors. It integrates a dual-core ARM Cortex-A72 with packet processing and high-speed peripherals. It runs at up to 1.5 GHz and includes 2 GB of DDR4 RAM and 8 GB of ROM. The processor is equipped with six Gbit Ethernet interfaces and supports TSN-capable Ethernet switches and controllers.

[0078] 3. TSNPHY: Two TSN PHYs are used according to the development board. 1) The TSNPHY equipped in the TSN switch is the TJA1102

[161] , a high-performance, dual-port automotive Ethernet PHY developed by NXP Semiconductors. It complies with the IEEE 100BAES-T1 specification and has a transmission speed of up to 100 Mbps. 2) The TSNPHY equipped in the LS1028A is the YT8614H, produced by Yutai Microelectronics, a domestically produced, low-power, four-port 10 / 100 / 100 Mbps Ethernet PHY that supports synchronous Ethernet clock output.

[0079] 4. OTA cloud server: A cloud server is used for simulation. The cloud server runs Ubuntu 22.04 64-bit, is equipped with 2 core vCPUs and 2GB of memory, and has a network bandwidth of 1Mbps.

[0080] (2) Hardware platform

[0081] OTA hardware based on domain-centralized E / E architecture Figure 5 As shown, the system includes a central gateway (TSN switch represented by the SJA1105Q and gateway processor represented by the LS1028A development board), a TCU (represented by the LS1028A development board), and a DCU / ECU (represented by the LS1028A development board). Because the LS1028A development board uses an RJ45 Ethernet interface, while the SJA1105Q development board uses a twisted pair Ethernet interface, this hardware architecture uses an automotive Ethernet media converter (an automotive Ethernet to standard Ethernet transparent transmission module) to connect the two. This converter supports 100BASE-T1 and 100BASE-TX interfaces, enabling bidirectional conversion between standard RJ45 Ethernet and twisted pair automotive Ethernet. It is compatible with devices from NXP, TI, Broadcom, Marvell, and Realtek.

[0082] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0083] The above-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the patent for this invention shall be determined by the appended claims.

Claims

1. A secure OTA upgrade system for a centralized E / E architecture in the automotive domain, characterized by: include: Automobile OTA upgrade system architecture; The system architecture consists of two parts: the cloud and the vehicle side; the cloud side refers to the OTA cloud server, which communicates with the vehicle side through the telematics control unit; the vehicle side refers to the OTA software upgrade object, which adopts the automotive domain centralized E / E architecture; the vehicle side also includes the TCU, which realizes data transmission between the vehicle and the cloud server and is the key node for downloading update packages during the OTA upgrade process; the system architecture uses TSN as the backbone network to connect five subdomains to the central gateway. The five subdomains are powertrain domain, chassis domain, body domain, infotainment domain, and advanced driver assistance system domain; each subdomain uses DCU as the core computing unit, integrating multiple function-related ECUs, while retaining a small number of ECUs connected to the DCU through traditional networks, and the traditional networks include one or more of CAN, CAN-FD, LIN, and MOST.

2. The system upgrade method according to claim 1, characterized in that: The following steps are involved: Step 1: Identity authentication; Step 2: Upgrade control; Step 3: Security upgrade.

3. The upgrade method according to claim 2, characterized in that: In step 1, to ensure the legitimacy of the identity of each node before establishing communication and performing OTA software upgrades, the mutual identity authentication process between the nodes is first completed, which is implemented using a digital identity certificate mechanism, covering two-way authentication between the master node and all slave nodes. The master node refers to the central gateway, the slave nodes include DCU, ECU, TCU and OTA cloud server, and the nodes include master nodes and slave nodes; The specific steps include: Step 1.1: OTA cloud server notification; Step 1.2: Central gateway broadcast; Step 1.3: Slave node registration; Step 1.4: Central gateway response.

4. The upgrade method according to claim 3, characterized in that: In step 1.1, When a new software version is available, the OTA cloud server will send an update notification to the car owner through the TCU. The TCU prompts the car owner to confirm through the human-computer interaction interface. After the car owner agrees, the OTA cloud server officially starts the upgrade process and sends its own digital certificate to the central gateway for identity verification. The digital certificate is issued by a third-party certificate authority and uses the standard X.509 format. The certificate content includes the node's public key, public key algorithm identifier, certificate serial number, validity period, issuer information, and the node's unique identifier, and is accompanied by the CA's digital signature to ensure the certificate's technical and legal credibility.

5. The upgrade method according to claim 3, characterized in that: In step 1.2, after receiving the digital certificate of the OTA cloud server, the central gateway verifies its digital signature using the built-in CA root certificate to ensure that the certificate has not been forged or tampered with. After the verification is successful, the central gateway extracts the public key of the OTA cloud server for subsequent encrypted communication and key negotiation. The central gateway will then broadcast its own digital certificate to all slave nodes; After receiving the certificate from the central gateway, each slave node will verify its signature to confirm its legal identity.

6. The upgrade method according to claim 3, characterized in that: In step 1.3, After completing the legitimacy verification of the central gateway's digital certificate, each slave node needs to register its identity with the central gateway to establish mutual trust. Since the OTA cloud server has already submitted its digital certificate during the notification phase, it only needs to send the symmetric key and timestamp during the registration phase. These sensitive data are encrypted using the central gateway's public key and digitally signed to ensure the confidentiality, integrity, and non-repudiation of the messages. The registration messages of DCU, ECU, and TCU include their digital certificates, symmetric keys, and timestamps. The digital certificates are used by the central gateway to verify the legitimacy of their identities, while the symmetric keys and timestamps are encrypted using the central gateway's public key and digitally signed to prevent data leakage and tampering.

7. The upgrade method according to claim 3, characterized in that: In step 1.4, When the central gateway receives the registration information from the slave node, it first verifies the digital certificate signature to confirm the legitimacy of the certificate and obtains the node's public key. Then, the central gateway uses its own private key to decrypt the sensitive data encrypted with the public key in the registration message and verifies its digital signature to ensure the message's source is credible, the content is complete, and it is non-repudiable. The central gateway will generate a current timestamp and compare it with the timestamp in the registration message to confirm the timeliness and freshness of the message to prevent replay attacks; after completing all verifications, the central gateway will send a response message to the corresponding slave node; the response message contains the timestamp generated by the central gateway and is encrypted using the symmetric key provided by the slave node to ensure that the message can only be decrypted and read by legitimate nodes; after receiving the response message, the slave node uses its own symmetric key to decrypt the content, and by comparing information such as the timestamp, it verifies the timeliness and authenticity of the response, and finally completes the closed-loop process of identity authentication.

8. The system upgrade method according to claim 2, characterized in that: The upgrade control in step 2 means that after completing the identity authentication of the master and slave nodes, the central gateway acts as the master node to uniformly manage and securely control the entire OTA upgrade process to ensure the legality, controllability and security of the upgrade process; step 2 includes two key steps, step 2.1, OTA cloud server upgrade request, and step 2.2, central gateway authorization upgrade.

9. The upgrading method according to claim 8, characterized in that: In step 2.1, the OTA cloud server initiates an upgrade request to the central gateway; the request message includes the upgrade object, upgrade package configuration information, and a timestamp generated by the OTA cloud server; to ensure the confidentiality of the communication, the request message is encrypted using the symmetric key agreed upon between the OTA cloud server and the central gateway; In step 2.2, after receiving the upgrade request from the OTA cloud server, the central gateway will perform consistency verification and policy review on the request content to determine whether the upgrade package configuration, upgrade node permissions, and current vehicle status allow the upgrade operation to be performed; After verification, the central gateway will generate a unique upgrade key for this upgrade, which will be used for the encrypted transmission and HMAC calculation of subsequent upgrade packages; the central gateway will then encrypt the upgrade key separately and send it to each upgrade node and OTA cloud server. The encryption key used is the respective symmetric key established in the previous identity authentication stage.

10. The upgrade method according to claim 2, characterized in that: The secure upgrade in step 3 means that the OTA cloud server securely sends the upgrade package to each upgrade target to ensure the confidentiality and integrity of the upgrade package; the OTA cloud server uses the upgrade key to encrypt the software package to be upgraded and the timestamp of the OTA cloud server, and calculates the HMAC value of the upgrade package and the timestamp for subsequent integrity verification; then, the OTA cloud server sends the encrypted software package together with the corresponding HMAC value to each target node; after receiving the message, the upgrade node first uses the upgrade key to decrypt the software package, and recalculates the local HMAC value based on the same upgrade key, recorded as HMAC*, and compares it with the HMAC sent by the OTA cloud server; if the two are consistent, it is confirmed that the upgrade package has not been tampered with during transmission; then, the upgrade node generates a timestamp at this time and compares it with the received timestamp to ensure the freshness of the message; the upgrade node enters the software writing and function verification process to complete the upgrade process; After the upgrade is completed, each node will feedback the upgrade status to the central gateway and OTA cloud server to facilitate system status archiving and subsequent maintenance.

Images