Vehicle software flashing method, oem server and vehicle high-level controller

Abstract

This invention provides a method for flashing vehicle software, an OEM server, and a vehicle advanced controller, belonging to the field of automotive software technology. The method includes: obtaining a software container sent by an ECU supplier; the software container is obtained by the ECU supplier through AES ciphertext and a software hash value, packaged together based on plaintext software encryption; after verifying the normal function of the software container, encrypting the software container to obtain an encrypted software container; transmitting the encrypted software container to the vehicle advanced controller via a host computer or an in-vehicle TBOX; the vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller, after confirming the legitimate source of the encrypted software container, sends the encrypted software container to a target controller for decryption and signature verification. This invention can solve the technical problem that existing in-vehicle network security architectures cannot meet the requirements of functional complexity at a lower cost.

Description

Technical Field

[0001] This invention relates to the field of vehicle software technology, specifically to a method for flashing vehicle software, an OEM server, and a vehicle advanced controller. Background Technology

[0002] Cybersecurity is a relatively new topic in the automotive field, and there are currently two main solutions: First, for vehicle ECUs (electronic control units) with HSM (Hardware Security Module) and AUTOSAR (Automotive Open System Architecture), all network security-related designs such as AES / HMAC / ECDSA algorithms are usually performed locally on the ECU. These ECUs are usually directly connected to the communication bus, can directly participate in the vehicle network communication, and have a high ability to resist network security risks.

[0003] Second, for low-critical or low-cost vehicle ECUs, the ECUs typically do not have HSM modules or AUTOSAR. In network security architecture design, these components are usually designed as slaves to the upper-level ECU (such as ZCU / VCU), and are not directly connected to the communication bus, thus avoiding network security risks.

[0004] The two current mainstream designs are mainly for highly complex automotive ECUs or for simple ECUs, with little "middle ground." For automotive ECUs in the so-called "middle ground," there is a requirement for both functional complexity and relatively low cost. If the first solution is adopted directly, it will inevitably lead to increased costs, while if the second solution is adopted directly, it will inevitably lead to functional deficiencies. Therefore, a cybersecurity architecture design adapted to this type of ECU is needed.

[0005] In summary, existing in-vehicle network security architectures cannot meet the requirements of functional complexity at a low cost. Summary of the Invention

[0006] In view of this, it is necessary to provide a whole vehicle software flashing method, an OEM server, and a whole vehicle advanced controller to solve the technical problem that the existing in-vehicle network security architecture cannot meet the requirements of functional complexity at a low cost.

[0007] To address the aforementioned problems, in a first aspect, the present invention provides a method for flashing vehicle software, the method being applied to an OEM server, the method comprising: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container. The encrypted software container is transmitted to the vehicle's advanced controller via a host computer or an in-vehicle TBOX. The vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller is used to send the encrypted software container to the target controller for decryption and signature verification after verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is normal.

[0008] In one possible implementation, the vehicle-mounted TBOX is connected to the OEM server via OEM cloud communication.

[0009] In one possible implementation, the software container is obtained by the ECU supplier based on the following steps: The plaintext software is encrypted using the AES key and initial value provided by the OEM server to generate AES ciphertext. The software hash value is calculated based on the HMAC key corresponding to the encryption. The AES ciphertext and the software hash value are packaged together to obtain a software container.

[0010] In one possible implementation, the software container is encrypted to obtain an encrypted software container, including: The software container is encrypted using the ECDSA encryption algorithm to obtain an encrypted software container.

[0011] In one possible implementation, the vehicle advanced controller is used to perform signature verification on the encrypted software container based on the ECDSA encryption algorithm.

[0012] Secondly, the present invention also provides a method for flashing vehicle software, the method being applied to a vehicle advanced controller, the vehicle advanced controller including a domain controller or a vehicle VCU controller; the method includes: Obtain the encrypted software container sent by the OEM server via a host computer or in-vehicle TBOX; After verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is legitimate, the encrypted software container is sent to the target controller for decryption and signature verification. The encrypted software container is obtained from the OEM server through the following steps: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container.

[0013] In one possible implementation, signature verification of the encrypted software container includes: The signature based on the ECDSA encryption algorithm is used to verify the signature of the encrypted software container.

[0014] Thirdly, the present invention also provides an OEM server, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps of the vehicle software flashing method as described in any of the above.

[0015] Fourthly, the present invention also provides an advanced vehicle controller, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps of the vehicle software flashing method as described in any of the above.

[0016] Fifthly, the present invention also provides a vehicle software flashing system, comprising: the aforementioned OEM server and the aforementioned vehicle advanced controller; the vehicle advanced controller is communicatively connected to the target controller via a CAN bus, and is communicatively connected to the OEM server via a host computer or an in-vehicle TBOX; the in-vehicle TBOX is communicatively connected to the OEM server via the OEM cloud.

[0017] The beneficial effects of the above implementation method are as follows: The vehicle software flashing method, OEM server, and vehicle advanced controller provided by the present invention are applied to the OEM server. The method includes: obtaining a software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext and software hash value based on software plaintext encryption; after verifying that the software container functions normally, encrypting the software container to obtain an encrypted software container; transmitting the encrypted software container to the vehicle advanced controller through a host computer or vehicle TBOX; wherein, the vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller is used to send the encrypted software container to the target controller for decryption and signature verification after verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is normal.

[0018] The method provided by this invention involves the decryption and signature verification of software container data by the target controller, which can be a local ECU. The data acceptance of the software container can be performed by the OEM server and the vehicle advanced controller. For example, the OEM server verifies that the software container data is functionally normal, the vehicle advanced controller verifies that the source of the software container data is normal, and finally the local target controller performs decryption and signature verification to ensure the integrity of the software code. This approach conforms to the design of a high-level network security architecture (CAL2 and above) and consumes less local ECU resources.

[0019] Therefore, using the method provided by this invention, only decryption and signature verification are required for the local controller ECU, without adding any additional functions and thus no additional cost. For complex functions, such as the verification of software container data, these can be performed by the OEM server and the vehicle's advanced controller, thereby solving the technical problem that existing in-vehicle network security architectures cannot meet the requirements of functional complexity at a lower cost. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart of an embodiment of the vehicle software flashing method provided by the present invention; Figure 2 A flowchart illustrating another embodiment of the vehicle software flashing method provided by the present invention; Figure 3 A schematic diagram illustrating the design architecture of the vehicle software flashing method provided by this invention; Figure 4 A schematic diagram of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0023] In the description of the embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0024] In this embodiment of the invention, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, apparatus, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to such process, method, product or device.

[0025] The naming or numbering of steps in the embodiments of the present invention does not mean that the steps in the method flow must be executed in the time / logical order indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effect can be achieved.

[0026] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0027] This invention provides a method for flashing vehicle software, an OEM server, and a vehicle advanced controller, which will be described below.

[0028] This invention provides a method for flashing software on a complete vehicle. This method is applied to OEM servers. OEM (Original Equipment Manufacturer) is commonly known as "contract manufacturing." In the server field, an OEM server refers to a manufacturer (such as Jinpin Company) that produces and assembles server hardware entirely according to the design drawings, bill of materials (BOM), and other requirements provided by the brand customer. Figure 1 As shown, the method includes: S101. Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext and software hash value obtained by encrypting software plaintext.

[0029] Understandably, the software code is generated at the ECU supplier and compiled into a binary file containing plaintext software. This plaintext software is then further encrypted to obtain AES ciphertext, and its hash value is calculated.

[0030] A container is a structured solution for encapsulating and managing internal components. In the computer field, containers isolate resources such as processes and networks through the Linux kernel's namespaces and utilize cgroups to implement resource limiting, forming a lightweight virtualization environment.

[0031] S102. After verifying that the software container functions normally, the software container is encrypted to obtain an encrypted software container.

[0032] Understandably, after receiving the software container, the OEM server performs secondary encryption to further ensure the security of the software container. The encryption method here can be symmetric encryption or other software encryption methods.

[0033] S103. Transmit the encrypted software container to the vehicle's advanced controller via a host computer or an onboard TBOX (telematics processor); The vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller is used to send the encrypted software container to the target controller for decryption and signature verification after verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is normal.

[0034] Understandably, if a cloud-based OTA solution is used, the software container is transmitted to the vehicle's advanced controller, such as a domain controller or the vehicle's VCU controller, via the in-vehicle TBOX; if a host computer solution is used, the software container is directly sent to the vehicle's advanced controller via the host computer and the bus.

[0035] In some embodiments, the vehicle-mounted TBOX and the OEM server are connected via OEM cloud communication.

[0036] Understandably, the OEM cloud includes DKS, TSP, and PKI. The DKS platform is a key management platform that manages keys, such as key deletion, authorization, and security components. If password verification is required, a PKI will be applied for. PKI is a cryptographic device, a platform for storing passwords, primarily the root key; the password is readable but not writable. The OEM factory mainly pre-fabricates keys and certificates, binds the chip to the assembled vehicle, and collects corresponding information.

[0037] In some embodiments, the software container is obtained by the ECU supplier based on the following steps: The plaintext software is encrypted using the AES key and initial value provided by the OEM server to generate AES ciphertext. The software hash value is calculated based on the HMAC key corresponding to the encryption. The AES ciphertext and the software hash value are packaged together to obtain a software container.

[0038] It's understandable that AES keys and HMAC keys are used in cryptography for encryption and message authentication, respectively. While their functions differ, they can be used together to ensure data confidentiality and integrity. AES key: used for symmetric encryption / decryption, ensuring data confidentiality. HMAC key: used for message authentication code generation, ensuring data integrity and authenticity.

[0039] In some embodiments, encrypting the software container to obtain an encrypted software container includes: The software container is encrypted using the ECDSA encryption algorithm to obtain an encrypted software container.

[0040] As is understandable, ECDSA (Elliptic Curve Digital Signature Algorithm) is a digital signature technology based on elliptic curve cryptography, used to verify data integrity, authenticate identity, and prevent tampering.

[0041] ECDSA utilizes the discrete logarithm problem on elliptic curves (ECDLP) as its security foundation, featuring short keys, high security, and excellent computational efficiency.

[0042] The core processes of ECDSA include: Key generation: Select an elliptic curve and a base point G, randomly generate a private key d, and calculate the public key Q = d × G.

[0043] Signature generation: Hash the message and generate a signature value (r, s) using the private key and a random number k.

[0044] Signature verification: The recipient uses the public key, message hash, and signature (r, s) to verify whether the signature was generated by the corresponding private key.

[0045] It should be noted that ECDSA only provides digital signature functionality and does not support data encryption. It is usually used in conjunction with symmetric encryption or public-key encryption algorithms to achieve a complete security solution.

[0046] In some embodiments, the vehicle advanced controller is used to perform signature verification on the encrypted software container based on the ECDSA encryption algorithm.

[0047] It is understood that in the above embodiments, the software container is encrypted based on the ECDSA encryption algorithm to obtain the encrypted software container. Correspondingly, the vehicle advanced controller performs signature verification on the encrypted software container based on the signature of the ECDSA encryption algorithm.

[0048] The present invention also provides an OEM server, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps of the vehicle software flashing method as described in any of the above.

[0049] This invention also provides a method for flashing vehicle software, the method being applied to a vehicle advanced controller, the vehicle advanced controller including a domain controller or a vehicle VCU controller; such as Figure 2 As shown, the method includes: Obtain the encrypted software container sent by the OEM server via a host computer or in-vehicle TBOX; After verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is legitimate, the encrypted software container is sent to the target controller for decryption and signature verification. The encrypted software container is obtained from the OEM server through the following steps: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container.

[0050] In some embodiments, signature verification of the encrypted software container includes: The signature based on the ECDSA encryption algorithm is used to verify the signature of the encrypted software container.

[0051] The information security design provided by this invention mainly includes three core functions: data encryption / decryption, data integrity verification, and data source verification. In the existing first solution, all three core functions are executed locally on the ECU. In the existing second solution, these three core functions are executed by the host ECU. However, for some important but low-cost ECUs (hereinafter, we will take the low-voltage battery BMS (i.e., battery management system) as an example), they cannot function entirely as slave controllers because they need to participate in vehicle information interaction. However, due to cost requirements, they cannot fully execute complete network security functions in terms of chip load and chip computing power.

[0052] Therefore, the functions need to be broken down. Taking AES128, SHA256, and ECDSA as examples, these three algorithms correspond to the three core functions of data encryption / decryption, data integrity verification, and data source verification, respectively. Typically, AES (symmetric encryption algorithm) and SHA256 (256-bit cryptographic hash algorithm) occupy relatively little memory (15KB and 5KB respectively), while ECDSA (elliptic curve digital signature algorithm) occupies more space (50KB). ECDSA's main function is simply data source verification, which is what network security calls "signature," so it is usually only used in OTA (Over-the-Air) and software downloads.

[0053] Based on the above basic information, the design architecture provided by this invention is as follows: Figure 3 As shown: Data encryption / decryption and data integrity verification are performed locally by the ECU, while data source confirmation is handled by the host ECU and an external server. This conforms to a high-level network security architecture design (CAL2 and above) and consumes relatively few local ECU resources. If ECDSA is to be implemented locally, it requires more than 100KB of storage space because the software is usually divided into APP (application) and boot modes, and this asymmetric encryption also places high demands on the chip's computing power.

[0054] Furthermore, this working mode, when combined with KMS (Key Management System) to update keys periodically, provides a higher level of resistance to network attacks, i.e., a higher level of network security.

[0055] Vehicle network security architecture design: For the ECU local, all encryption and decryption are completed by AES128, and all signatures are completed by HMAC (including key frame message communication); the part that needs to verify the source of data is completed by external ECDSA.

[0056] In some embodiments, the specific process steps of the method provided by the present invention are as follows: 1. The software code is generated at the ECU supplier and compiled to obtain the plaintext binary file.

[0057] 2. Use the AES key and initial value provided by the OEM at the ECU supplier to encrypt the plaintext software, generate AES ciphertext, and calculate the hash value of the software based on the HMAC key.

[0058] 3. Package the hash value and the software ciphertext into a software container for the supplier to release, and upload the software container to the OEM server.

[0059] 4. The OEM first conducts software acceptance testing to ensure that the OEM server software functions normally and has not been tampered with by network attacks.

[0060] 5. The OEM uses the ECDSA asymmetric encryption algorithm to perform signature calculation on the software container, and then uploads it to the OEM cloud or sends it to the host computer on the production line for writing.

[0061] 6. If a cloud-based OTA solution is used, the software container is transmitted to the vehicle's advanced controller, such as a domain controller or the vehicle's VCU controller, via the in-vehicle TBOX; if a host computer solution is used, the software container is sent directly to the vehicle's advanced controller via the host computer and bus.

[0062] 7. Perform ECDSA signature verification on the domain controller or vehicle controller to ensure the source is legitimate.

[0063] 8. Send the software ciphertext and hash value as a new software container to the target controller via the CAN bus.

[0064] 9. The target controller uses the same AES key and HMAC key for software decryption and signature verification to ensure the integrity of the software code.

[0065] 10. If an HMAC or AES key needs to be updated, treat the key as software and repeat the above process. (Use the old key as the encryption and decryption tool). This allows for daily or monthly key changes, depending on the OEM's requirements.

[0066] The present invention also provides an advanced vehicle controller, which includes a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps of the vehicle software flashing method as described in any of the above.

[0067] The present invention also provides a vehicle software flashing system, comprising: the aforementioned OEM server and the aforementioned vehicle advanced controller; the vehicle advanced controller is communicatively connected to the target controller via a CAN bus, and is communicatively connected to the OEM server via a host computer or an in-vehicle TBOX; the in-vehicle TBOX is communicatively connected to the OEM server via the OEM cloud.

[0068] like Figure 4 As shown, the present invention also provides an electronic device 400, which can be an OEM server or a vehicle advanced controller. The electronic device 400 includes a processor 401, a memory 402, and a display 403. Figure 4 Only some components of the electronic device 400 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0069] In some embodiments, memory 402 may be an internal storage unit of electronic device 400, such as a hard disk or memory of electronic device 400. In other embodiments, memory 402 may also be an external storage device of electronic device 400, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 400.

[0070] Furthermore, the memory 402 may include both internal storage units of the electronic device 400 and external storage devices. The memory 402 is used to store application software and various types of data installed on the electronic device 400.

[0071] In some embodiments, processor 401 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 402 or process data, such as the whole vehicle software flashing method of the present invention.

[0072] In some embodiments, display 403 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 403 is used to display information from electronic device 400 and to display a visual user interface. Components 401-403 of electronic device 400 communicate with each other via a system bus.

[0073] In some embodiments of the present invention, when the processor 401 executes the vehicle software flashing program in the memory 402, the following steps can be implemented: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container. The encrypted software container is transmitted to the vehicle's advanced controller via a host computer or an in-vehicle TBOX. The vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller is used to send the encrypted software container to the target controller for decryption and signature verification after verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is normal.

[0074] Alternatively, the following steps can be performed: Obtain the encrypted software container sent by the OEM server via a host computer or in-vehicle TBOX; After verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is legitimate, the encrypted software container is sent to the target controller for decryption and signature verification. The encrypted software container is obtained from the OEM server through the following steps: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container.

[0075] It should be understood that when the processor 401 executes the vehicle software flashing program in the memory 402, in addition to the functions mentioned above, it can also perform other functions, as can be found in the description of the corresponding method embodiments above.

[0076] Furthermore, the embodiments of the present invention do not specifically limit the type of electronic device 400 mentioned. Electronic device 400 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the present invention, electronic device 400 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0077] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the vehicle software flashing method provided by the above methods, the method comprising: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container. The encrypted software container is transmitted to the vehicle's advanced controller via a host computer or an in-vehicle TBOX. The vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller is used to send the encrypted software container to the target controller for decryption and signature verification after verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is normal.

[0078] Alternatively, the method includes: Obtain the encrypted software container sent by the OEM server via a host computer or in-vehicle TBOX; After verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is legitimate, the encrypted software container is sent to the target controller for decryption and signature verification. The encrypted software container is obtained from the OEM server through the following steps: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container.

[0079] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0080] The above provides a detailed description of the vehicle software flashing method, OEM server, and advanced vehicle controller provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for flashing software on a vehicle, characterized in that, The method is applied to an OEM server, and the method includes: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container. The encrypted software container is transmitted to the vehicle's advanced controller via a host computer or an in-vehicle TBOX. The vehicle advanced controller includes a domain controller or a vehicle VCU controller; the vehicle advanced controller is used to send the encrypted software container to the target controller for decryption and signature verification after verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is normal.

2. The vehicle software flashing method according to claim 1, characterized in that, The vehicle-mounted TBOX is connected to the OEM server via OEM cloud communication.

3. The vehicle software flashing method according to claim 1, characterized in that, The software container is obtained by the ECU supplier based on the following steps: The plaintext software is encrypted using the AES key and initial value provided by the OEM server to generate AES ciphertext. The software hash value is calculated based on the HMAC key corresponding to the encryption. The AES ciphertext and the software hash value are packaged together to obtain a software container.

4. The vehicle software flashing method according to any one of claims 1-3, characterized in that, The software container is encrypted to obtain an encrypted software container, comprising: The software container is encrypted using the ECDSA encryption algorithm to obtain an encrypted software container.

5. The vehicle software flashing method according to claim 4, characterized in that, The vehicle advanced controller is used to verify the signature of the encrypted software container based on the ECDSA encryption algorithm.

6. A method for flashing software on a vehicle, characterized in that, The method is applied to a vehicle advanced controller, which includes a domain controller or a vehicle VCU controller; the method includes: Obtain the encrypted software container sent by the OEM server via a host computer or in-vehicle TBOX; After verifying the signature of the encrypted software container to confirm that the source of the encrypted software container is legitimate, the encrypted software container is sent to the target controller for decryption and signature verification. The encrypted software container is obtained from the OEM server through the following steps: Obtain the software container sent by the ECU supplier; the software container is obtained by the ECU supplier by packaging AES ciphertext obtained by encrypting software plaintext and software hash value; After verifying that the software container is functioning normally, the software container is encrypted to obtain an encrypted software container.

7. The vehicle software flashing method according to claim 6, characterized in that, Signature verification of the encrypted software container includes: The signature based on the ECDSA encryption algorithm is used to verify the signature of the encrypted software container.

8. An OEM server, characterized in that, Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps of the vehicle software flashing method as described in any one of claims 1 to 5.

9. A vehicle-mounted advanced controller, characterized in that, Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps of the vehicle software flashing method as described in any one of claims 6 to 7.

10. A vehicle software flashing system, characterized in that, include: The OEM server as described in claim 8 and the advanced vehicle controller as described in claim 9; the advanced vehicle controller is connected to the target controller via a CAN bus and is connected to the OEM server via a host computer or an in-vehicle TBOX; the in-vehicle TBOX is connected to the OEM server via the OEM cloud.

Images