An ECU identity authentication method, a key management method, a device, a T-Box and a server

Abstract

This application provides an ECU identity authentication method, key management method, device, T-Box, and server. The vehicle is equipped with a target ECU and a remote information processor (T-Box). The target ECU communicates with the T-Box and the server. The method includes: receiving a public key for the target ECU's identity sent by the target ECU; the target ECU requesting the public key from the server; obtaining a pre-stored ECU whitelist on the server based on the T-Box's identity information; wherein the ECU whitelist includes the correspondence between the T-Box's identity information and the ECU's public key; and authenticating the target ECU based on the public key and the ECU whitelist. In this method, it is difficult for intrusion devices to forge digital identities by tampering with vehicle data, improving the security of the data used for authentication and thus enhancing the reliability of identity authentication. Furthermore, the amount of data exchanged during the entire identity authentication process is small, achieving lightweight identity authentication at the authentication end and effectively improving authentication efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically, to an ECU authentication method, a key management method, a device, a T-Box, and a server. Background Technology

[0002] With the development of vehicle-to-everything (V2X) technology, vehicles are gradually becoming part of the internet. While connecting vehicles to the internet allows them to access more services, the access of vehicle components also creates opportunities for unauthorized intrusion. Criminals can steal transmitted data, tamper with communication content, and launch cyberattacks by forging digital identities, seriously impacting the safety of vehicles and their owners. Security and trust are prerequisites for the healthy development of the V2X industry; how to ensure secure vehicle access to the network is a pressing technical problem that needs to be solved in this field. Summary of the Invention

[0003] The purpose of this application is to provide an ECU identity authentication method, key management method, device, T-Box, and server to achieve the technical effect of secure vehicle network access.

[0004] A first aspect of this application provides an ECU authentication method, wherein a vehicle is equipped with a target ECU and a remote information processor (T-Box); the target ECU, the T-Box, and a server are communicatively connected; the method includes:

[0005] Receive the target ECU identity public key sent by the target ECU; the target ECU obtains the target ECU identity public key from the server.

[0006] Based on the identity information of the T-Box, obtain the ECU whitelist pre-stored on the server; wherein, the ECU whitelist includes the correspondence between the identity information of the T-Box and the public key of the ECU identity;

[0007] The target ECU is authenticated based on its public key and the ECU whitelist.

[0008] In the above implementation process, the target ECU requiring identity authentication sends its public key to the authentication terminal. The authentication terminal only needs to obtain the ECU whitelist based on the T-Box's identity information and use the target ECU's public key and the ECU whitelist to determine whether the target ECU is a legitimate ECU of the vehicle containing the T-Box, thus completing the identity authentication process. Furthermore, since both the target ECU's public key and the ECU whitelist are generated by the server, it is difficult for intrusive devices to forge digital identities by tampering with vehicle data, improving the security of the data used for authentication and thus enhancing the reliability of identity authentication. In addition, the amount of data exchanged throughout the identity authentication process is small, achieving lightweight identity authentication at the authentication terminal and effectively improving authentication efficiency.

[0009] Furthermore, the correspondence between the T-Box and the ECU identity public key includes:

[0010] The correspondence between the T-Box's public key and the ECU's public key; the T-Box's public key is requested by the T-Box from the server.

[0011] In the above implementation process, both the T-Box identity public key and the target ECU identity public key are generated on the server side. This allows the server to generate an ECU whitelist that includes the correspondence between the T-Box identity public keys and the ECU identity public keys. This makes it difficult for intrusion devices to forge digital identities by tampering with vehicle data, improving the security of the data used for authentication and thus enhancing the reliability of identity authentication.

[0012] Further, the step of authenticating the target ECU based on the target ECU's public key and the ECU whitelist includes:

[0013] If the public key of the target ECU is found in the ECU whitelist, it is determined that the target ECU has passed identity authentication;

[0014] If the target ECU's identity public key is not found in the ECU whitelist, it is determined that the target ECU has failed identity authentication.

[0015] In the above implementation process, the identity authentication process can be completed simply by checking whether the target ECU's identity public key exists in the ECU whitelist. This process is simple and fast, greatly improving the efficiency of identity authentication.

[0016] Furthermore, the method is performed by the T-Box, and the method further includes:

[0017] Receive the target ECU's signature on the key combination; the key combination includes the T-Box identity public key and the target ECU identity public key;

[0018] The key combination is then verified by signature.

[0019] In the above implementation process, signature verification can confirm whether the data transmission has been tampered with, and can also confirm that the identity authentication request was indeed initiated by the target ECU, thereby further improving the reliability of identity authentication.

[0020] Furthermore, the method is executed by the server, and the method further includes:

[0021] Return the authentication result to the target ECU and / or the T-Box.

[0022] In the above implementation, the target ECU's identity authentication process is performed on the server side. This eliminates the need for vehicles to pre-store an ECU whitelist, making it difficult for intrusive devices to forge digital identities by tampering with vehicle data. This improves the security of the data used for authentication, thereby enhancing the reliability of identity authentication. Furthermore, the amount of data exchanged throughout the authentication process is small, achieving lightweight identity authentication on the server side and effectively improving authentication efficiency.

[0023] A second aspect of this application provides a key management method applied to a server, the method comprising:

[0024] In response to a first request sent by the vehicle-mounted T-Box, a T-Box identity public-private key pair is generated and stored based on the T-Box identifier carried in the first request, and the T-Box identity public-private key pair is sent to the T-Box.

[0025] In response to a second request sent by the vehicle's ECU, an ECU identity public-private key pair and an ECU whitelist are generated based on the ECU identifier and T-Box identity information carried in the second request, and the ECU identity public-private key pair is sent to the ECU; wherein, the ECU whitelist includes the correspondence between the T-Box identity information and the ECU identity public key;

[0026] In response to the third request sent by the T-Box, the ECU whitelist corresponding to the identity information of the T-Box is sent to the T-Box according to the identity information of the T-Box carried in the third request.

[0027] In the above implementation process, the server generates public and private key pairs for the T-Box and ECU, and can update them periodically to ensure that critical data is not tampered with. Simultaneously, the use of digital envelopes during the transmission of these public and private key pairs effectively prevents data tampering or theft, improving the security of interactions between the vehicle components and the server. Thus, secure communication with external devices is achieved through identity authentication and encrypted communication technologies.

[0028] Further, sending the T-Box identity public / private key pair to the T-Box includes:

[0029] The T-Box identity public and private keys are encrypted using a first encryption algorithm to obtain a T-Box digital envelope, and the T-Box digital envelope is sent to the T-Box so that the T-Box can decrypt the T-Box digital envelope using a first decryption algorithm to obtain the T-Box identity public and private key pair;

[0030] Sending the ECU identity public / private key pair to the ECU includes:

[0031] The ECU identity public and private keys are encrypted using a second encryption algorithm to obtain an ECU digital envelope, which is then sent to the ECU so that the ECU can decrypt the ECU digital envelope using a second decryption algorithm to obtain the ECU identity public and private key pair.

[0032] In the above implementation process, by encapsulating the public and private key pairs of identity into digital envelopes, the leakage or tampering of the public and private key pairs of identity during transmission can be effectively prevented, thereby improving the security of the interaction between vehicle components and the server.

[0033] A third aspect of this application provides an ECU identity authentication device, wherein a vehicle is equipped with a target ECU and a T-Box; the target ECU and the T-Box are communicatively connected to a server; the device includes:

[0034] The receiving module is used to receive the target ECU identity public key sent by the target ECU; the target ECU identity public key is obtained by the target ECU from the server.

[0035] The acquisition module is used to acquire the ECU whitelist pre-stored on the server based on the identity information of the T-Box; wherein, the ECU whitelist includes the correspondence between the identity information of the T-Box and the public key of the ECU identity;

[0036] The authentication module is used to authenticate the target ECU based on the target ECU's public key and the ECU whitelist.

[0037] A fourth aspect of this application provides a key management device applied to a server, the device comprising:

[0038] The first generation module is configured to respond to a first request sent by the vehicle-mounted T-Box, generate and store a T-Box identity public-private key pair according to the T-Box identifier carried in the first request, and send the T-Box identity public-private key pair to the T-Box;

[0039] The second generation module is used to respond to a second request sent by the vehicle's ECU, generate an ECU identity public-private key pair and an ECU whitelist based on the ECU identifier and T-Box identity information carried in the second request, and send the ECU identity public-private key pair to the ECU; wherein, the ECU whitelist includes the correspondence between the T-Box identity information and the ECU identity public key;

[0040] The sending module is used to respond to a third request sent by the T-Box and send an ECU whitelist corresponding to the identity information of the T-Box to the T-Box according to the identity information of the T-Box carried in the third request.

[0041] A fifth aspect of this application provides a T-Box, the T-Box comprising:

[0042] processor;

[0043] Memory used to store processor-executable instructions;

[0044] Wherein, when the processor invokes the executable instructions, it implements the operation of any of the methods described in the first aspect.

[0045] A sixth aspect of this application provides a server, the server comprising:

[0046] processor;

[0047] Memory used to store processor-executable instructions;

[0048] Wherein, when the processor invokes the executable instructions, it implements the operation of any of the methods described in the first aspect and / or the second aspect.

[0049] A seventh aspect of this application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first and / or second aspects. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This application provides an application scenario for an ECU authentication method and a key management method.

[0052] Figure 2 A flowchart illustrating an ECU authentication method provided in this application embodiment;

[0053] Figure 3 A flowchart illustrating another ECU authentication method provided in this application embodiment;

[0054] Figure 4 A flowchart illustrating another ECU authentication method provided in this application embodiment;

[0055] Figure 5 A flowchart illustrating another ECU authentication method provided in this application embodiment;

[0056] Figure 6 A flowchart illustrating another ECU authentication method provided in this application embodiment;

[0057] Figure 7 A flowchart illustrating a key management method provided in an embodiment of this application;

[0058] Figure 8 A flowchart illustrating another key management method provided in an embodiment of this application;

[0059] Figure 9 A flowchart illustrating another key management method provided in an embodiment of this application;

[0060] Figure 10 A structural block diagram of an ECU authentication device provided in this application embodiment;

[0061] Figure 11 A structural block diagram of a key management device provided in an embodiment of this application;

[0062] Figure 12 A hardware structure diagram of a T-Box provided in this application embodiment;

[0063] Figure 13 This is a hardware structure diagram of a server provided in an embodiment of this application. Detailed Implementation

[0064] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0065] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0066] With the development of vehicle-to-everything (V2X) technology, vehicles are gradually becoming part of the internet. While connecting vehicles to the internet allows them to access more services, the presence of vehicle components also creates opportunities for unauthorized intrusion.

[0067] To enhance the security of connected vehicles, vehicle components, such as ECUs, can undergo authentication before accessing the public internet. Only upon successful authentication can it be confirmed that the component requesting access is a legitimate vehicle component and not an intrusion device with a forged digital identity. If intrusion devices are not accurately blocked during the authentication process, they can illegally steal vehicle data from the internet, tamper with communication between the vehicle and other devices on the internet, and launch cyberattacks, seriously impacting the safety of the vehicle and its owner. Therefore, improving the reliability of pre-connection authentication is a primary prerequisite for ensuring secure vehicle access to the internet.

[0068] Therefore, this application proposes an ECU (Electronic Control Unit) authentication method. The ECU, also known as the vehicle's "on-board computer," uses data from various sensors and buses to determine the vehicle's status and obtain the driver's intentions, and controls the vehicle's movement and other driving functions through actuators. When performing driving functions, the ECU may need to connect to the vehicle network for data exchange; therefore, the ECU authentication method proposed in this application can be used to authenticate the ECU before it connects to the vehicle network. Of course, the ECU authentication method proposed in this application is not limited to the scenario of ECU connecting to the vehicle network; it can also be applied to any scenario requiring ECU authentication. This application does not limit the application scenarios.

[0069] To enable vehicle-to-everything (V2X) technology, vehicles are often equipped with a T-Box (Telematics-Box). The T-Box serves as a V2X communication terminal, remotely connecting to a TSP (Telematics Service Provider) platform via 3G / 4G / 5G technologies to achieve remote communication and services. The T-Box is a crucial node for data interaction between the vehicle's internal network and external networks, and an indispensable part of vehicle-to-cloud communication.

[0070] like Figure 1 As shown, vehicle 110 is equipped with target ECU 111 and T-Box 112. Target ECU 111, T-Box 112, and server 120 can communicate with each other. Target ECU 111 can be any ECU in the vehicle that requires authentication. For example, it could be an ECU that needs network connectivity. Target ECU 111 and T-Box 112 can establish a secure communication link with server 120 via the SSL (Secure Sockets Layer) protocol.

[0071] Based on this, the ECU authentication method provided in this application includes, as follows: Figure 2 The steps shown are as follows:

[0072] Step 210: Receive the target ECU identity public key sent by the target ECU;

[0073] The target ECU's public key is requested by the target ECU from the server.

[0074] Step 220: Obtain the ECU whitelist pre-stored on the server based on the identity information of the T-Box;

[0075] The ECU whitelist includes the correspondence between the T-Box's identity information and the ECU's public key.

[0076] Step 230: Authenticate the target ECU based on the target ECU's public key and the ECU whitelist.

[0077] The above methods can be executed by an authentication terminal, which can include a server or a T-Box. The specific process of executing methods by different authentication terminals will be described below.

[0078] The target ECU can request a public / private key pair from the server, including the target ECU's public key and private key. The request process for the target ECU's public / private key pair will be described below. Subsequently, when identity authentication is required, the target ECU can send its public key to the authentication server.

[0079] The authentication terminal can obtain the ECU whitelist pre-stored on the server based on the T-Box's identity information. The ECU whitelist includes the mapping between the T-Box's identity information and the ECU's public key.

[0080] Understandably, since the target ECU's public / private key pair is generated by the server, the server can record all requested ECU public / private key pairs. Furthermore, a vehicle typically contains one T-Box and multiple ECUs; therefore, the server can record T-Boxes and ECUs belonging to the same vehicle, generating an ECU whitelist. In the ECU whitelist, the identity information of one T-Box corresponds to at least one ECU public key. ECUs within the ECU whitelist are considered legitimate ECUs.

[0081] The T-Box's identity information may include a T-Box identifier and / or a T-Box identity public key. The T-Box identifier can be a unique identifier for each component of the T-Box. The T-Box identity public key can be obtained by the T-Box from the server; this process will be detailed below.

[0082] Thus, in some embodiments, the correspondence between the T-Box and the ECU identity public key can be a correspondence between the T-Box identity public key and the ECU identity public key. That is, the ECU whitelist records the correspondence between the T-Box identity public key and the ECU identity public key.

[0083] In some embodiments, the mapping between the T-Box and the ECU identity public key can be a mapping between the T-Box identifier and the ECU identity public key. That is, the ECU whitelist records the mapping between the T-Box identifier and the ECU identity public key.

[0084] Since the server pre-stores ECU whitelists corresponding to different T-Boxes, the corresponding ECU whitelist can be determined based on the T-Box's identity information. Then, the target ECU is authenticated using its public key and the ECU whitelist.

[0085] In some embodiments, step 230 above, which authenticates the target ECU based on the target ECU's public key and the ECU whitelist, may include, for example: Figure 3 The steps shown are as follows:

[0086] Step 231: If the public key of the target ECU is found in the ECU whitelist, it is determined that the target ECU has passed identity authentication;

[0087] Step 232: If the target ECU's identity public key is not found in the ECU whitelist, it is determined that the target ECU has failed identity authentication.

[0088] Since the ECU whitelist records the correspondence between the T-Box and the ECU's public key, we can check if the target ECU's public key exists in the whitelist. If it exists, it means the target ECU is the ECU of the vehicle where the T-Box is located; that is, the target ECU and the T-Box belong to the same vehicle and are components of the same vehicle. Therefore, we can confirm that the target ECU has passed authentication. If it does not exist, it means there is no correspondence between the T-Box and the target ECU. In this case, the target ECU is not the ECU of the vehicle where the T-Box is located; for example, it might be an unauthorized ECU or other intrusion device. Therefore, we can confirm that the target ECU has not passed authentication.

[0089] This application provides an ECU identity authentication method. The target ECU requiring authentication sends its public key to the authentication terminal. The authentication terminal only needs to obtain an ECU whitelist based on the T-Box's identity information and use the target ECU's public key and the whitelist to determine whether the target ECU is a legitimate ECU of the vehicle containing the T-Box, thus completing the authentication process. Furthermore, since both the target ECU's public key and the ECU whitelist are generated by the server, it is difficult for intrusive devices to forge digital identities by tampering with vehicle data, improving the security of the data used for authentication and thus enhancing the reliability of identity authentication. In addition, the entire authentication process involves a small amount of data exchanged, achieving lightweight identity authentication at the authentication terminal and effectively improving authentication efficiency.

[0090] Regarding the execution entity of the above method, in some embodiments, it can be executed by the T-Box. In this way, the target ECU can send its public key to the T-Box, where authentication is completed.

[0091] After receiving the target ECU's public key, the T-Box can query and authenticate its identity in real time through the online service interface provided by the server. For example, step 220 above, based on the T-Box's identity information, retrieves the ECU whitelist pre-stored by the server, which may include, for instance... Figure 4 The steps shown are as follows:

[0092] Step 221: Send a third request carrying the identity information of the T-Box to the server;

[0093] The third request is used to request the ECU whitelist;

[0094] Step 222: Receive the ECU whitelist determined by the server based on the T-Box's identity information.

[0095] After receiving the target ECU's public key, the T-Box can request an ECU whitelist from the server via an online service interface. As mentioned above, since the server stores ECU whitelists corresponding to different T-Boxes, the third request carries the T-Box's identity information, allowing the server to obtain the corresponding ECU whitelist based on the T-Box's identity information.

[0096] Subsequently, the T-Box authenticates the target ECU using its public key and the received ECU whitelist. Optionally, the T-Box can return the authentication result to the target ECU.

[0097] In this embodiment, the target ECU's identity authentication process is performed at the T-Box. When authentication is required, the T-Box obtains the ECU whitelist in real time through an online service interface. Thus, the T-Box does not need to pre-store the data used for authentication (including the ECU whitelist and the target ECU's public key), making it difficult for intrusive devices to forge digital identities by tampering with vehicle data. This improves the security of the data used for authentication, thereby enhancing the reliability of identity authentication. Furthermore, the amount of data exchanged throughout the authentication process is small, achieving lightweight identity authentication on the T-Box and effectively improving authentication efficiency.

[0098] Furthermore, in some embodiments, to further improve the reliability of identity authentication, when the T-Box performs identity authentication of the target ECU, it may also include, for example... Figure 5 The steps shown are as follows:

[0099] Step 241: Receive the signature of the key combination from the target ECU;

[0100] The key combination includes the T-Box identity public key and the target ECU identity public key;

[0101] Step 242: Perform signature verification on the key combination.

[0102] Before performing authentication, the target ECU can request the T-Box's public key. Then, the T-Box's public key and the target ECU's public key are assembled in a preset order to obtain a key combination. Subsequently, a digest is generated from the key combination using a preset algorithm, and the digest is encrypted using the target ECU's private key to obtain a signature of the key combination. The preset algorithm used is pre-negotiated with the T-Box; for example, it could be a hash algorithm.

[0103] After receiving the signature of the key combination, the T-Box can verify the signature using the target ECU's public key and a preset algorithm. Specifically, the T-Box first decrypts the signature using the target ECU's public key to obtain a decrypted digest. Then, the T-Box combines its own T-Box public key with the received target ECU's public key and uses the preset algorithm to generate a digest of the combined key. The two digests are compared; if they match, the verification passes; otherwise, the verification fails.

[0104] For example, such as Figure 6 The diagram illustrates an ECU authentication method provided in this application. First, the target ECU 111 sends a signature of its public key and a key combination to the T-Box 112 (step S11). Then, the T-Box 112 sends a third request to the server 120 (step S12). The server 120 obtains the corresponding ECU whitelist based on the T-Box's identity information carried in the third request and returns the ECU whitelist to the T-Box 112 (step S13). The T-Box 112 then uses the target ECU's public key and the ECU whitelist to authenticate the target ECU (step S14), and performs signature verification after successful authentication (step S15). After completing authentication and signature verification, the authentication result is returned to the target ECU 111 (step S16).

[0105] In this embodiment, signature verification can confirm whether data transmission has been tampered with and whether the authentication request was indeed initiated by the target ECU. If the signature verification fails, it indicates that the data may have been tampered with during transmission, or that the T-Box's public key and / or the target ECU's public key have been illegally stolen. The vehicle can then take protective measures. For example, the T-Box can request an update of its public / private key pair and / or the target ECU's public / private key pair from the server.

[0106] Regarding the entity responsible for executing the above methods, in some embodiments, it can be executed by the server.

[0107] Optionally, the target ECU can directly send its public key to the server, and the T-Box can also directly send its identity information, including its identifier and / or its public key, to the server.

[0108] Optionally, the target ECU can send its public key to the T-Box, and then the T-Box can send its own identity information and the target ECU's public key to the server.

[0109] The server then uses the T-Box's identity information to determine the corresponding ECU whitelist. It then authenticates the target ECU using the target ECU's public key and the ECU whitelist.

[0110] After completing the identity authentication, the server can return the authentication result to the target ECU and / or T-Box.

[0111] In this embodiment, the target ECU's identity authentication process is performed on the server side. This eliminates the need for the vehicle to pre-store an ECU whitelist, making it difficult for intrusion devices to forge digital identities by tampering with vehicle data. This improves the security of the data used for authentication, thereby enhancing the reliability of identity authentication. Furthermore, the amount of data exchanged throughout the authentication process is small, achieving lightweight identity authentication on the server side and effectively improving authentication efficiency.

[0112] In addition, this application also provides a key management method, such as Figure 1 As shown, it is applied to server 120. The method includes, as shown... Figure 7 The steps shown are as follows:

[0113] Step 310: In response to the first request sent by the vehicle-mounted T-Box, generate and store the T-Box identity public and private key pair according to the T-Box identifier carried in the first request, and send the T-Box identity public and private key pair to the T-Box;

[0114] Step 320: In response to the second request sent by the vehicle ECU, generate an ECU identity public-private key pair and an ECU whitelist based on the ECU identifier and T-Box identity information carried in the second request, and send the ECU identity public-private key pair to the ECU.

[0115] The ECU whitelist includes the mapping between the T-Box's identity information and the ECU's public key.

[0116] Step 330: In response to the third request sent by the T-Box, based on the identity information of the T-Box carried in the third request, send the ECU whitelist corresponding to the identity information of the T-Box to the T-Box.

[0117] The server is used to implement key management functions, which can distribute public and private key pairs, including public and private keys, to T-Boxes and ECUs of different vehicles.

[0118] When a T-Box requests a T-Box identity public / private key pair, the first request must include a T-Box identifier to uniquely identify the T-Box. After generating the T-Box identity public / private key pair, the server can record the T-Box identifier and / or the T-Box identity public / private key pair and return the T-Box identity public / private key pair to the T-Box.

[0119] In some embodiments, step 310, sending the T-Box identity public / private key pair to the T-Box, may include: encrypting the T-Box identity public / private key pair using a first encryption algorithm to obtain a T-Box digital envelope, and sending the T-Box digital envelope to the T-Box. The T-Box can then decrypt the T-Box digital envelope using a first decryption algorithm to obtain the T-Box identity public / private key pair. The first decryption algorithm may be the inverse operation of the first encryption algorithm.

[0120] Thus, the application process for the T-Box identity public / private key pair can be as follows: Figure 8 As shown. After establishing an SSL secure communication link between T-Box 112 and server 120 (step S21), T-Box 112 sends a first request carrying the T-Box identifier to server 120 (step S22). Subsequently, server 120 generates a T-Box identity public-private key pair and encapsulates it using a T-Box digital envelope (step S23). Server 120 may store the T-Box identifier and / or the T-Box identity public-private key pair. After server 120 returns the T-Box digital envelope to T-Box 112 (step S24), T-Box 112 can decrypt the T-Box digital envelope to obtain the T-Box identity public-private key pair.

[0121] In this way, by encapsulating the T-Box identity public and private key pair into a digital envelope, the leakage or tampering of the T-Box identity public and private key pair during transmission can be effectively prevented, thereby improving the security of the interaction between the T-Box and the server.

[0122] When an ECU requests an ECU identity public / private key pair, the second request needs to include the ECU identifier and the T-Box's identity information. Specifically, the ECU can request the T-Box's identity information, including the T-Box identifier and / or the T-Box's public key. Upon receiving the second request, the server, having stored the identity information of all T-Boxes that have requested the identity public / private key pair, first determines the legitimacy of the ECU and its corresponding T-Box based on the T-Box's identity information carried in the second request. Subsequently, it generates and stores the ECU identity public / private key pair and generates an ECU whitelist based on the T-Box's identity information and the ECU identity public / private key pair. Finally, it returns the ECU identity public / private key pair to the ECU.

[0123] In some embodiments, step 320, sending the ECU identity public-private key pair to the ECU, may include: encrypting the ECU identity public-private key pair using a second encryption algorithm to obtain an ECU digital envelope, and then sending the ECU digital envelope to the ECU. The ECU can then decrypt the ECU digital envelope using a second decryption algorithm to obtain the ECU identity public-private key pair. The second decryption algorithm may be the inverse operation of the second encryption algorithm.

[0124] Optionally, the first encryption algorithm and the second encryption algorithm can be the same encryption algorithm, such as the AES (Advanced Encryption Standard) encryption function; the first decryption algorithm and the second decryption algorithm can be the same decryption algorithm, such as the AES decryption function. Optionally, the first encryption algorithm and the second encryption algorithm can also be different encryption algorithms, and the first decryption algorithm and the second decryption algorithm can also be different decryption algorithms. This application does not impose any restrictions.

[0125] Thus, the application process for the ECU identity public / private key pair is as follows: Figure 9 As shown. After establishing an SSL secure communication link between ECU 111 and server 120 (step S31), ECU 111 sends a second request carrying the T-Box's identity information and ECU identifier to server 120 (step S32). Subsequently, server 120 generates an ECU identity public-private key pair and encapsulates it using an ECU digital envelope (step S33). Further, server 120 can generate an ECU whitelist based on the T-Box's identity information and the ECU identity public-private key pair (step S34) and return the ECU digital envelope to ECU 111 (step S25). ECU 111 can decrypt the ECU digital envelope to obtain the ECU identity public-private key pair.

[0126] In this way, by encapsulating the ECU identity public and private key pair in a digital envelope, the leakage or tampering of the ECU identity public and private key pair during transmission can be effectively prevented, thereby improving the security of the interaction between the ECU and the server.

[0127] In some embodiments, the server can periodically update in-vehicle components, including the public / private key pair of the T-Box and the ECU. For example, when a preset update cycle is reached, the server can send an update notification to the in-vehicle components. In response to the update notification, the T-Box can send a first request to the server, and the ECU can send a second request to the server, thereby triggering the update of the public / private key pair.

[0128] Furthermore, during the target ECU's identity authentication process, the server can provide an ECU whitelist. The server pre-stores the ECU whitelist corresponding to each vehicle's T-Box. In response to a third request sent by the T-Box, the server can retrieve the corresponding ECU whitelist based on the T-Box's identity information carried in the third request and return it to the T-Box.

[0129] Furthermore, the server can be used to implement identity authentication during the target ECU's authentication process. The server can receive the target ECU's public key and the T-Box's identity information, and determine the corresponding ECU whitelist based on the T-Box's identity information. Subsequently, it performs identity authentication based on the target ECU's public key and the ECU whitelist, and returns the authentication result to the target ECU and / or the T-Box.

[0130] This application provides a key management method that generates public-private key pairs for the T-Box and ECU via a server, and can periodically update these pairs to ensure that critical data is not tampered with. Simultaneously, the use of digital envelopes during the transmission of these public-private key pairs effectively prevents data tampering or theft, improving the security of interactions between vehicle components and the server. Thus, secure communication with external devices is achieved through identity authentication and encrypted communication technologies.

[0131] Based on the ECU authentication method provided in any of the above embodiments, this application also provides an ECU authentication device. The vehicle is equipped with a target ECU and a T-Box; the target ECU and the T-Box are communicatively connected to a server. Figure 10 As shown, the device 400 includes:

[0132] The receiving module 410 is used to receive the target ECU identity public key sent by the target ECU; the target ECU identity public key is obtained by the target ECU from the server.

[0133] The acquisition module 420 is used to acquire the ECU whitelist pre-stored on the server based on the identity information of the T-Box; wherein, the ECU whitelist includes the correspondence between the identity information of the T-Box and the public key of the ECU identity;

[0134] The authentication module 430 is used to authenticate the target ECU based on the target ECU's public key and the ECU whitelist.

[0135] In some embodiments, the authentication module 430 is specifically used for:

[0136] If the public key of the target ECU is found in the ECU whitelist, it is determined that the target ECU has passed identity authentication;

[0137] If the target ECU's identity public key is not found in the ECU whitelist, it is determined that the target ECU has failed identity authentication.

[0138] In some embodiments, the device 400 is applied to a T-Box, wherein the device 400 further includes:

[0139] The signature verification module is used to receive the signature of the key combination from the target ECU; the key combination includes the T-Box identity public key and the target ECU identity public key; and to verify the signature of the key combination.

[0140] In some embodiments, the device 400 is applied to a server, wherein the device 400 further includes:

[0141] The return module is used to return the authentication result to the target ECU and / or the T-Box.

[0142] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0143] Based on the key management method provided in any of the above embodiments, this application also provides a key management device applied to a server. For example... Figure 11 As shown, the device 500 includes:

[0144] The first generation module 510 is configured to respond to a first request sent by the vehicle-mounted T-Box, generate and store a T-Box identity public-private key pair according to the T-Box identifier carried in the first request, and send the T-Box identity public-private key pair to the T-Box.

[0145] The second generation module 520 is used to respond to a second request sent by the vehicle ECU, generate an ECU identity public-private key pair and an ECU whitelist based on the ECU identifier and T-Box identity information carried in the second request, and send the ECU identity public-private key pair to the ECU; wherein, the ECU whitelist includes the correspondence between the T-Box identity information and the ECU identity public key;

[0146] The sending module 530 is used to respond to a third request sent by the T-Box and send an ECU whitelist corresponding to the identity information of the T-Box to the T-Box according to the identity information of the T-Box carried in the third request.

[0147] In some embodiments, the first generation module 510 is specifically used for:

[0148] The T-Box identity public and private keys are encrypted using a first encryption algorithm to obtain a T-Box digital envelope, and the T-Box digital envelope is sent to the T-Box so that the T-Box can decrypt the T-Box digital envelope using a first decryption algorithm to obtain the T-Box identity public and private key pair;

[0149] The second generation module 520 is specifically used for:

[0150] The ECU identity public and private keys are encrypted using a second encryption algorithm to obtain an ECU digital envelope, which is then sent to the ECU so that the ECU can decrypt the ECU digital envelope using a second decryption algorithm to obtain the ECU identity public and private key pair.

[0151] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0152] Based on the above Figures 2-6 The ECU authentication method described in any embodiment also provides, as in the following example: Figure 12 The diagram shows a structural schematic of a T-Box. Figure 12 At the hardware level, the T-Box includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for various services. The processor reads the corresponding computer program from the non-volatile storage into memory and then executes it to achieve the above-mentioned functions. Figures 2-6 An ECU identity authentication method as described in any embodiment.

[0153] Based on the above Figures 2-3 An ECU authentication method described in any embodiment, and Figures 7-9 In addition to the key management method described in any embodiment, this application also provides, as... Figure 13 The diagram shows a server-side architecture. Figure 13 At the hardware level, the server includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to achieve the above. Figures 2-3 An ECU authentication method as described in any embodiment, and / or implementing the above. Figures 7-9 A key management method as described in any embodiment.

[0154] This application also provides a computer storage medium storing a computer program, which, when executed by a processor, can be used to perform an ECU authentication method and / or a key management method as described in any of the above embodiments.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0156] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0157] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they 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 a portion 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0158] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0159] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0160] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. An ECU identity authentication method, characterized by, The vehicle is equipped with a target ECU and a remote information processor T-Box; the target ECU, the T-Box, and the server are connected in communication; the method includes: Receive the target ECU identity public key sent by the target ECU; the target ECU obtains the target ECU identity public key from the server. Based on the identity information of the T-Box, obtain the ECU whitelist pre-stored on the server; wherein, the ECU whitelist includes the correspondence between the identity information of the T-Box and the public key of the ECU identity; The target ECU is authenticated based on its public key and the ECU whitelist.

2. The method of claim 1, wherein, The correspondence between the T-Box and the ECU identity public key includes: The correspondence between the T-Box's public key and the ECU's public key; the T-Box's public key is requested by the T-Box from the server.

3. The method according to claim 1, characterized in that, The step of authenticating the target ECU based on the target ECU's public key and the ECU whitelist includes: If the public key of the target ECU is found in the ECU whitelist, it is determined that the target ECU has passed identity authentication; If the target ECU's identity public key is not found in the ECU whitelist, it is determined that the target ECU has failed identity authentication.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: The T-Box receives the signature of the key combination from the target ECU; the key combination includes the T-Box's identity public key and the target ECU's identity public key. The key combination is signed and verified by the T-Box.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: The server returns the authentication result to the target ECU and / or the T-Box.

6. A key management method, characterized in that, Applied to the server side, the method includes: In response to a first request sent by the vehicle-mounted T-Box, a T-Box identity public-private key pair is generated and stored based on the T-Box identifier carried in the first request, and the T-Box identity public-private key pair is sent to the T-Box. In response to a second request sent by the vehicle's ECU, an ECU identity public-private key pair and an ECU whitelist are generated based on the ECU identifier and T-Box identity information carried in the second request, and the ECU identity public-private key pair is sent to the ECU; wherein, the ECU whitelist includes the correspondence between the T-Box identity information and the ECU identity public key; In response to the third request sent by the T-Box, the ECU whitelist corresponding to the identity information of the T-Box is sent to the T-Box according to the identity information of the T-Box carried in the third request.

7. The method according to claim 6, characterized in that, Sending the T-Box identity public / private key pair to the T-Box includes: The T-Box identity public and private key pair is encrypted using a first encryption algorithm to obtain a T-Box digital envelope, and the T-Box digital envelope is sent to the T-Box so that the T-Box can decrypt the T-Box digital envelope using a first decryption algorithm to obtain the T-Box identity public and private key pair; Sending the ECU identity public / private key pair to the ECU includes: The ECU identity public and private key pair is encrypted using a second encryption algorithm to obtain an ECU digital envelope, and the ECU digital envelope is sent to the ECU so that the ECU can decrypt the ECU digital envelope using a second decryption algorithm to obtain the ECU identity public and private key pair.

8. An ECU authentication device, characterized in that, The vehicle is equipped with a target ECU and a T-Box; the target ECU and the T-Box are communicatively connected to the server; the device includes: The receiving module is used to receive the target ECU identity public key sent by the target ECU; the target ECU identity public key is obtained by the target ECU from the server. The acquisition module is used to obtain the ECU whitelist pre-stored on the server based on the identity information of the T-Box; wherein, the ECU whitelist includes the correspondence between the identity information of the T-Box and the public key of the ECU identity; The authentication module is used to authenticate the target ECU based on the target ECU's public key and the ECU whitelist.

9. A key management device, characterized in that, Applied to the server side, the device includes: The first generation module is configured to respond to a first request sent by the vehicle-mounted T-Box, generate and store a T-Box identity public-private key pair according to the T-Box identifier carried in the first request, and send the T-Box identity public-private key pair to the T-Box; The second generation module is used to respond to a second request sent by the vehicle's ECU, generate an ECU identity public-private key pair and an ECU whitelist based on the ECU identifier and T-Box identity information carried in the second request, and send the ECU identity public-private key pair to the ECU; wherein, the ECU whitelist includes the correspondence between the T-Box identity information and the ECU identity public key; The sending module is used to respond to a third request sent by the T-Box and send an ECU whitelist corresponding to the identity information of the T-Box to the T-Box according to the identity information of the T-Box carried in the third request.

10. A T-Box, characterized in that, The T-Box includes: processor; Memory used to store processor-executable instructions; When the processor invokes the executable instructions, it implements the operation of any one of the methods described in claims 1-4.

11. A server, characterized in that, The server includes: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements the operation of any one of the methods described in claims 1-3 or 5-7.

12. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1-7.

Images