Safe flashing method and system for vehicle, client side and server side

Abstract

The invention provides a safe flashing method and system for a vehicle, a client side and a server side, and relates to the technical field of electronic control unit data flashing, and the method comprises the steps that the server side and the client side are authenticated through an APCE bidirectional identity authentication service, and after the authentication succeeds, a temporary secret key is generated and sent to the client side; the server side erases the memory to generate a to-be-written memory area, acquires the to-be-written application program from the client side and writes the to-be-written application program into the to-be-written memory area; the client determines a first hash value based on the application program to be written, and generates a first CMAC based on the first hash value and the temporary key; and the server calculates a second hash value based on the content of the application program written in the current memory area to be written, generates a second CMAC based on the second hash value and the temporary key, and gives an alarm when the comparison result of the first CMAC and the second CMAC is not matched. Therefore, the security of the vehicle software security flashing scheme is effectively improved.

Description

Technical Field

[0001] This application relates to the field of electronic control unit data flashing technology, and more specifically, to a secure flashing method, system, client, and server for vehicles. Background Technology

[0002] Electronic control unit (ECU) data flashing (also known as ECU data loading) involves sending data to the vehicle's engine control unit via the ECU communication network using external tools (such as a diagnostic tool) to update and manage the program and parameters. Its core applications include vehicle factory packaging, repair upgrades, and modification adjustments. In ECU data flashing, the ECU is typically used as the server, and the diagnostic tool as the client.

[0003] Currently, the mainstream software security flashing solutions used by car manufacturers typically include pre-programming, reprogramming, and post-programming. However, current reprogramming methods usually cannot guarantee that only personnel with specific identities can flash the ECU.

[0004] Current software flashing security solutions cannot guarantee complete security, resulting in security vulnerabilities. Attackers may exploit these vulnerabilities to forge or tamper with flashing packages, implanting malware into vehicles. This could lead to vehicle malfunctions (such as interference with braking and steering systems), the theft of user privacy data (such as location and call logs), or even turning the vehicle into a remotely controlled "zombie device."

[0005] Therefore, there is an urgent need for a method that can effectively improve the security of vehicle software flashing schemes. Summary of the Invention

[0006] This application provides a secure flashing method, system, client, and server for vehicles, to at least address the technical problem of improving the security of vehicle software flashing solutions.

[0007] According to a first aspect of the embodiments of this application, a method for securely flashing a vehicle is provided, the method comprising: The client uses APCE two-way authentication service to authenticate the server; After the server successfully authenticates with the client through the APCE two-way authentication service, it generates a temporary key and sends it to the client. The server erases memory to generate a memory region to be written, obtains the application to be written from the client, and writes the application to be written into the memory region to be written. The client determines a first hash value based on the application to be written, generates a first CMAC based on the first hash value and the temporary key, and sends the first CMAC to the server. The server calculates a second hash value based on the content of the application being written to the memory region to be written, and generates a second CMAC based on the second hash value and the temporary key. The server compares the first CMAC and the second CMAC. If the comparison results of the first CMAC and the second CMAC do not match, an alarm is triggered.

[0008] Optionally, if the comparison results of the first CMAC and the second CMAC match, the server does not perform signature verification and integrity verification, but directly performs programming dependency verification.

[0009] Optionally, the client uses APCE two-way authentication service to authenticate the server, including: The client sends a client-side random number challenge value and the client certificate to the server; After receiving the client certificate, the server verifies the CA signature of the client certificate. If the verification is successful, the server generates a server-side true random number challenge value and uses the private key in combination with the client random number challenge value to generate server certificate ownership. The server then sends the server-side true random number challenge value, the server certificate ownership value, and the server certificate to the client. The client verifies the ownership of the server certificate and the server certificate. After the verification is successful, the client generates the ownership of the client certificate by combining the private key with the second challenge value, and sends the ownership of the client certificate to the server. The server verifies the ownership of the client's certificate; if the verification passes, authentication is successful.

[0010] Optionally, at least one of the server certificate and the client certificate consists of the following parts: Role permission values, public key coefficients, modulus, and CA signature.

[0011] Optionally, the client uses APCE two-way authentication service to authenticate the server, including: The client sends its certificate to the server; After the server verifies the client's identity based on the client certificate, it obtains the role permission value from the client certificate. The server determines the corresponding operation permissions of the client based on the role permission value.

[0012] Optionally, the role permission values ​​include: First security level permission value, second security level permission value; When the server determines that the client's role permission value is the first security level permission value, it determines that it can obtain the application provided by the client; When the server determines that the client's role permission value is the second security level permission value, it determines that the client cannot obtain the application provided by the client.

[0013] Optionally, the client determines the first hash value based on the application to be written, including: The client calculates a first hash value based on the content of the application to be written, wherein the first hash value is calculated in the same way as the second hash value; or, The client obtains the hash value in the tail address of the application to be written as the first hash value, wherein the hash value in the tail address of the application to be written is a hash value pre-calculated based on the content of the application, and the calculation method of the hash value pre-calculated based on the content of the application is consistent with the method of the server calculating the second hash value based on the content of the application.

[0014] A second aspect of this application also provides a security flashing system for vehicles, the system being used to perform the method provided in the embodiments of this application, the system comprising: The client is used to authenticate the server using the APCE two-way authentication service, receive a temporary key sent by the server, determine a first hash value based on the application to be written, generate a first CMAC based on the first hash value and the temporary key, and send the first CMAC to the server. The server, after successfully authenticating with the client via APCE two-way authentication service, generates a temporary key and sends the temporary key to the client. It erases memory to generate a memory area to be written, obtains the application to be written from the client, writes the application to be written into the memory area to be written, calculates a second hash value based on the content of the application currently written into the memory area to be written, generates a second CMAC based on the second hash value and the temporary key, compares the first CMAC and the second CMAC, and issues an alarm if the comparison results of the first CMAC and the second CMAC do not match.

[0015] A third aspect of this application also provides a client, the client comprising: First processor; A first memory stores first computer-readable instructions, which, when executed by the first processor, implement the following method: The system uses APCE two-way authentication service to authenticate the server, receives a temporary key from the server, determines a first hash value based on the application to be written, generates a first CMAC based on the first hash value and the temporary key, and sends the first CMAC to the server.

[0016] A fourth aspect of this application also provides a server, the server comprising: Second processor; A second memory stores second computer-readable instructions, which, when executed by the second processor, implement the following method: The system authenticates with the client via APCE two-way authentication service. After successful authentication, a temporary key is generated and sent to the client. Memory is erased to create a memory area to be written. The system retrieves the application to be written from the client and writes it into the memory area. A second hash value is calculated based on the content of the application currently written to the memory area. A second CMAC is generated based on the second hash value and the temporary key. The first CMAC and the second CMAC are compared. If the comparison results of the first CMAC and the second CMAC are mismatched, an alarm is triggered.

[0017] In this embodiment of the application, authentication is performed by the client and the server using the APCE two-way identity authentication service, and verification is performed by hash value. This can improve the security of identity determination between the client and the server. Furthermore, since the hash value is used for verification after successful authentication, it can prevent software attackers from taking advantage of the authentication window to transmit incorrect applications and affect vehicle safety. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of a method for securely flashing a vehicle, provided in an embodiment of this application. Figure 2 This is a schematic diagram of an APCE two-way authentication service provided in an embodiment of this application; Figure 3 This is a schematic diagram of a vehicle security flashing system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a client provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] According to an embodiment of this application, a method embodiment for a vehicle security flashing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0022] This application provides a secure flashing method, system, client, and server for vehicles, to at least address the technical problem of improving the security of vehicle software flashing solutions.

[0023] In some implementations, the server can be an ECU and the client can be a diagnostic tool.

[0024] like Figure 1 As shown, according to a first aspect of the embodiments of this application, a method for securely flashing a vehicle is provided, the method comprising: S101. The client uses APCE two-way authentication service to authenticate the server; S102. After the server successfully authenticates with the client through the APCE two-way authentication service, it generates a temporary key and sends it to the client. S103. The server erases memory to generate a memory area to be written, and obtains the application to be written from the client, and writes the application to be written into the memory area to be written. S104. The client determines a first hash value based on the application to be written, generates a first CMAC based on the first hash value and the temporary key, and sends the first CMAC to the server. S105. The server calculates a second hash value based on the content of the application written to the memory area to be written, and generates a second CMAC based on the second hash value and the temporary key. The server compares the first CMAC and the second CMAC. If the comparison result of the first CMAC and the second CMAC is mismatched, an alarm is triggered.

[0025] APCE two-way authentication service can achieve more secure and reliable identity authentication between clients and servers. Once APCE two-way authentication is successful, it proves the authenticity and non-repudiation of the identities of both the client and the server.

[0026] By combining a temporary key to generate a CMAC value and then verifying the CMAC value, security can be improved while increasing the efficiency of secure flashing.

[0027] Optionally, if the comparison results of the first CMAC and the second CMAC match, the server does not perform signature verification and integrity verification, but directly performs programming dependency verification.

[0028] Optionally, the client uses APCE two-way authentication service to authenticate the server, including: The client sends a client-side random number challenge value and the client certificate to the server; After receiving the client certificate, the server verifies the CA signature of the client certificate. If the verification is successful, the server generates a server-side true random number challenge value and uses the private key in combination with the client random number challenge value to generate server certificate ownership. The server then sends the server-side true random number challenge value, the server certificate ownership value, and the server certificate to the client. The client verifies the ownership of the server certificate and the server certificate. After the verification is successful, the client generates the ownership of the client certificate by combining the private key with the second challenge value, and sends the ownership of the client certificate to the server. The server verifies the ownership of the client's certificate; if the verification passes, authentication is successful.

[0029] The client certificate and the server certificate are issued by a CA (Certificate Authority) jointly recognized by the server and the client. Optionally, the client uses APCE (Advanced Persistent Authentication Center) two-way authentication service to authenticate the server, including: The client sends its certificate to the server; After the server verifies the client's identity based on the client certificate, it obtains the role permission value from the client certificate. The server determines the corresponding operation permissions of the client based on the role permission value.

[0030] By setting role permission values, it is possible to flexibly assign flashing permissions to clients, and not to assign flashing permissions to clients that are not suitable for flashing.

[0031] Optionally, the APCE two-way authentication service is service 29.

[0032] In some implementations, server-side authentication is first performed using the 29 service. When the client uses the 29 service for server-side authentication, such as... Figure 2 As shown, this is achieved in the following way: The client sends a client-side random number challenge value and the client certificate to the server; After receiving the client certificate, the server verifies the CA signature of the client certificate. If the verification is successful, the server generates a server-side true random number challenge value and uses the private key in combination with the client random number challenge value to generate server certificate ownership. The server then sends the server-side true random number challenge value, the server certificate ownership value, and the server certificate to the client. The client verifies the ownership of the server certificate and the server certificate. After the verification is successful, the client generates the ownership of the client certificate by combining the private key with the second challenge value, and sends the ownership of the client certificate to the server. The server verifies the ownership of the client's certificate; if the verification passes, authentication is successful.

[0033] In some implementations, the client sends a client-side random number challenge value and a client certificate to the server, which is achieved in the following way: Step a: The client creates a client random number challenge value and sends the client certificate and the client random number challenge value to the server.

[0034] Step b: After receiving the client certificate, the server uses the root public key to verify the client certificate.

[0035] a) If the client certificate is invalid, the process will stop, verification will fail, and a negative response will be returned; b) If the client certificate is valid, continue the process.

[0036] In some implementations, after receiving the client certificate, the server verifies the CA signature of the client certificate. If the verification is successful, the server generates a server-side true random number challenge value and uses its private key in combination with the client's random number challenge value to generate server certificate ownership. The server-side true random number challenge value, the server certificate ownership value, and the server certificate are then sent to the client. This is achieved in the following way: Step c: The server uses a random number generator to create a 16-byte server-side true random number challenge value.

[0037] Step d: The server uses its private key to calculate the server certificate ownership based on the client's random number challenge value.

[0038] a) Server certificate ownership = RSA-2048-PSS (SHA-256 (client random number challenge value)).

[0039] Step e: The server sends a server-side true random number challenge value, server certificate ownership, and server certificate to the client.

[0040] In some implementations, the client verifies the ownership of the server certificate and the server certificate. Upon successful verification, the client generates client certificate ownership using its private key and the second challenge value, and then sends the client certificate ownership to the server. This is achieved in the following way: Step f: The client uses the root public key to verify the server certificate.

[0041] a) If the server certificate is invalid, the process will stop, verification will fail, and a negative response will be returned; b) If the server certificate is valid, proceed to step two.

[0042] Step g: The client uses the server's public key to verify the ownership of the server certificate and checks whether the verification is successful.

[0043] a) If the check fails, stop the process and return a negative response; b) If the verification is successful, proceed to step three.

[0044] Step h: The client uses its private key to calculate the server's true random number challenge value to determine the ownership of the client certificate.

[0045] a) Client certificate ownership = RSA-2048-PSS(SHA-256(server-side true random number challenge value)).

[0046] Step i: The client sends the client certificate ownership to the server.

[0047] In some implementations, the server verifies the ownership of the client's certificate; upon successful verification, authentication is complete. This is achieved in the following way: Step j: The server uses the client's public key to verify the ownership of the client's certificate and checks whether the verification is successful.

[0048] a) If the check fails, stop the process and return a negative response; b) If the verification is successful, proceed to step two.

[0049] Step k: Grant access to the diagnostic object and send a corresponding response to the client indicating successful authentication.

[0050] The client certificate and the server certificate are issued by a Certificate Authority (CA) mutually recognized by both the server and the client. In some implementations, the core process of the APCE two-way authentication service includes: certificate (CA) exchange between the client and the server, identity verification, and temporary session key negotiation, thereby ensuring the authenticity of the identities of both parties. The certificates exchanged between the client and the server are issued by CAs trusted by both parties, guaranteeing the verification of the true identity information of both parties, which is unforgeable.

[0051] Meanwhile, APCE two-way authentication uses true random numbers to generate challenge values. After receiving the challenge value sent by the other party, the server and client use their private keys to digitally sign it, and then send the digital signature along with the certificate to the other party, thereby proving that the server and client have private keys that match their respective certificate public keys.

[0052] Secondly, the APCE two-way authentication service can also authorize different permissions, i.e., user permission values, based on user roles with different security levels. It can specify that only the manufacturer or vehicle OEM is allowed to perform flashing, while after-sales personnel and other non-security-related personnel are not permitted to perform flashing. In practical applications, optionally, the role permission values ​​include: a first security level permission value and a second security level permission value. When the server determines that the client's role permission value is the first security level permission value, it determines that the client can access the application provided by the client; when the server determines that the client's role permission value is the second security level permission value, it determines that the client cannot access the application provided by the client.

[0053] APCE two-way authentication service can prove the legitimacy of the identities of both parties involved in the data transfer. The hash algorithm has good avalanche property, meaning that a small change in the source data will result in a large change in the digest value. Therefore, after the data transfer is completed, the CMAC is calculated using the hash value, and the consistency of the CMAC is compared to determine whether the software has been tampered with or replaced.

[0054] The core of secure data flashing lies in the legitimacy of the identity and the integrity of the data. Therefore, the method provided in this application embodiment can significantly improve the security of the secure data flashing scheme. It determines the legitimacy and permissions of the application through authentication before downloading, and then checks whether it has been tampered with by comparing the CMAC generated based on the hash value after downloading.

[0055] In some implementations, optionally, at least one of the server certificate and the client certificate consists of the following components: role permission value, public key coefficient, modulus, and CA signature.

[0056] In some embodiments, the certificate involved in the present invention may include a 1-byte role permission value, a 256-byte public key coefficient N, a 4-byte modulus E, and a 256-byte CA signature. In some embodiments, the certificate involved in the present invention may also include a public key algorithm, a signature algorithm, an issuer, a certificate validity date, a serial number, and a certificate version.

[0057] In some implementations, a hash value is filled into the tail address of the application to be written. The client generates a first CMAC based on the hash value of the tail address of the application to be written and a temporary key. Then, the server calculates a second hash value based on the application content. The server then generates a second CMAC based on the second hash value and the temporary key. The client and server compare the first and second CMACs to determine whether the application written to the server has been tampered with. The hash value of the tail address of the application to be written is a hash value pre-calculated based on the application content, and the calculation method is consistent with the method used by the server to calculate the second hash value based on the application content.

[0058] In some implementations, the client calculates a first hash value based on the content of the application to be written, and generates a first CMAC based on the first hash value and a temporary key. Then, the server calculates a second hash value based on the application content, and generates a second CMAC based on the second hash value and the temporary key. The client and server compare the first and second CMACs to determine whether the application written to the server has been tampered with. The calculation methods for the first and second hash values ​​are the same.

[0059] like Figure 3 As shown, a second aspect of this application also provides a security flashing system for vehicles, the system being used to perform the method provided in the embodiments of this application, the system comprising: Client 301 is used to authenticate the server using APCE two-way authentication service, receive a temporary key sent by the server, determine a first hash value based on the application to be written, generate a first CMAC based on the first hash value and the temporary key, and send the first CMAC to the server. Server 302 is configured to generate a temporary key and send the temporary key to the client after successful authentication with the client 301 via APCE two-way authentication service; erase memory to generate a memory area to be written; obtain the application to be written from the client 301; write the application to be written to the memory area to be written; calculate a second hash value based on the content of the application currently written to the memory area to be written; generate a second CMAC based on the second hash value and the temporary key; and issue an alarm if the comparison result of the first CMAC and the second CMAC does not match.

[0060] like Figure 4 As shown, in a third aspect of this application, a client is also provided, the client comprising: First processor 401; A first memory 402 stores a first computer-readable instruction. When the first processor 401 executes the first computer-readable instruction, it implements the following method: The system uses APCE two-way authentication service to authenticate the server, receives a temporary key from the server, determines a first hash value based on the application to be written, generates a first CMAC based on the first hash value and the temporary key, and sends the first CMAC to the server.

[0061] The first memory 402 and the first processor 401 can communicate via the first bus 403. The first memory 402 is used to store computer programs. The first processor 401 is used to execute computer programs.

[0062] like Figure 5 As shown, in a fourth aspect of this application, a server is also provided, the server comprising: Second processor 501; The second memory 502 stores a second computer-readable instruction, which, when executed by the second processor 501, implements the following method: The system authenticates with the client via APCE two-way authentication service. After successful authentication, a temporary key is generated and sent to the client. Memory is erased to create a memory area to be written. The system retrieves the application to be written from the client and writes it into the memory area. A second hash value is calculated based on the content of the application currently written to the memory area. A second CMAC is generated based on the second hash value and the temporary key. The first CMAC and the second CMAC are compared. If the comparison results of the first CMAC and the second CMAC are mismatched, an alarm is triggered.

[0063] The second memory 502 and the second processor 501 can communicate via the second bus 503. The second memory 502 is used to store computer programs. The second processor 501 is used to execute computer programs.

[0064] In this embodiment of the application, authentication is performed by the client and server using the APCE two-way identity authentication service, and verification is performed by hash value. This can improve the security of identity determination between the client and server. Furthermore, since the hash value in the application's tail address is used for verification after successful authentication, it can prevent software attackers from taking advantage of the authentication window to transmit incorrect applications and affect vehicle safety.

[0065] Optionally, the first processor 401 and the second processor 501 described above can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps in the method embodiments disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0066] The serial numbers in the embodiments of this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0067] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0068] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0069] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0070] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0071] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0072] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A secure flashing method for a vehicle, characterized by, The method comprises: The client authenticates the server using the APCE two-way identity authentication service; The server generates a temporary secret key after successfully authenticating the client through the APCE two-way identity authentication service and sends it to the client; The server erases the memory to generate a to-be-written memory area, and obtains a to-be-written application program from the client and writes the to-be-written application program into the to-be-written memory area; The client determines a first hash value based on the to-be-written application program, generates a first CMAC based on the first hash value and the temporary secret key, and sends the first CMAC to the server; The server calculates a second hash value based on the content of the application program written in the to-be-written memory area, generates a second CMAC based on the second hash value and the temporary secret key, compares the first CMAC and the second CMAC, and alarms in the case that the comparison result of the first CMAC and the second CMAC is mismatched.

2. The method of claim 1, wherein, In the case that the comparison result of the first CMAC and the second CMAC is matched, the server does not perform signature verification and integrity check, and directly performs programming dependency check.

3. The method of claim 1, wherein, The client authenticates the server using the APCE two-way identity authentication service, comprising: The client sends a client random number challenge value and a client certificate to the server; After receiving the client certificate, the server verifies the CA signature of the client certificate, generates a second challenge value after verification, generates a server certificate ownership using a private key combined with the client random number challenge value, and sends the server true random number challenge value, the server certificate ownership and the server certificate to the client; The client verifies the server certificate ownership and the server certificate, generates a client certificate ownership by combining the second challenge value through a private key after verification, and sends the client certificate ownership to the server; The server verifies the client certificate ownership, and authenticates successfully after verification.

4. The method of claim 3, wherein, At least one of the server certificate and the client certificate is composed of: Role permission value, public key coefficient, modulus and CA signature.

5. The method of claim 1, wherein, The client authenticates the server using the APCE two-way identity authentication service, comprising: The client sends a client certificate to the server; After confirming that the client identity is legal according to the client certificate, the server obtains the role permission value in the client certificate; The server determines the operation permission corresponding to the client according to the role permission value.

6. The method of claim 5, wherein, The role permission value includes: First security level permission value and second security level permission value; When the server determines that the role permission value of the client is the first security level permission value, it is determined that the application program provided by the client can be obtained; When the server determines that the role permission value of the client is the second security level permission value, it is determined that the application program provided by the client cannot be obtained.

7. The method of claim 1, wherein, The client determines a first hash value based on the to-be-written application program, comprising: The client calculates a first hash value based on the content of the application to be written, wherein the first hash value is calculated in the same way as the second hash value; or The client obtains a hash value in a tail address of the application to be written as the first hash value, wherein the hash value in the tail address of the application to be written is a hash value calculated in advance based on the content of the application, and the hash value calculated in advance based on the content of the application is calculated in the same way as the second hash value calculated by the server based on the content of the application.

8. A secure flashing system for a vehicle, characterized in that, The system is used to execute the method according to any one of claims 1-7, and the system comprises: The client is used to authenticate the server by using the APCE two-way identity authentication service, receive a temporary secret key sent by the server, determine a first hash value based on the application to be written, generate a first CMAC based on the first hash value and the temporary secret key, and send the first CMAC to the server. The server is used to generate a temporary secret key after successful authentication with the client by using the APCE two-way identity authentication service, send the temporary secret key to the client, erase the memory to generate a to-be-written memory area, obtain the application to be written from the client, write the application to be written into the to-be-written memory area, calculate a second hash value based on the content of the application written in the to-be-written memory area, generate a second CMAC based on the second hash value and the temporary secret key, compare the first CMAC and the second CMAC, and perform an alarm in the case that the comparison result of the first CMAC and the second CMAC is mismatched.

Images