System mutual recognition method, device and equipment for Internet of Vehicles

Abstract

The embodiment of the invention provides a system mutual recognition method, device and equipment for the Internet of Vehicles, and the method comprises the steps: obtaining a trusted root certificate of a platform, inputting a trusted root certificate list and a corresponding root certificate of each trusted domain, and updating the trusted root certificate list in real time; analyzing the trusted root certificate list, extracting a root certificate of each trust domain and the trusted root certificate list, and performing verification; providing a certificate verification service protocol based on all trust domains; receiving a construction request protocol of the equipment, analyzing the construction request protocol, and returning a response message of which a response protocol contains a certificate trust state so as to indicate the equipment to analyze the response message and confirm whether the queried certificate is trusted or not; the method is simple in process, supports efficient mutual recognition among multiple PKI systems, and solves the problems that the cost of interactive network resources of existing Internet of Vehicles equipment is large, and the efficiency of issuing a trusted root certificate list is low.

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Vehicles security authentication, and more specifically, to a system mutual recognition method, device and equipment for Internet of Vehicles. Background Art

[0002] Vehicle-to-Everything (V2X) is a new generation of information and communication technology that enables all-round connection and communication between vehicles and surrounding vehicles, people, transportation infrastructure and networks. Vehicle-to-Everything communications include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), vehicle-to-network (V2N), etc.

[0003] When the Internet of Vehicles security system is composed of multiple independent Internet of Vehicles security certificate management system PKI (Public Key Infrastructure) systems, these PKI systems can establish a trusted relationship as needed to achieve mutual recognition of certificates. The trusted relationship between multiple Internet of Vehicles PKI systems is achieved through a "Trusted Root Certificate List (TRCL)". The trusted list is issued by the Trusted Root Certificate List Authority (TRCLA). The existence or non-existence of the trusted root certificate list will not affect the operation of each independent PKI system, but it will affect whether the certificates of different PKI systems can be mutually recognized.

[0004] In a large-scale V2X vehicle networking application system, the system will contain hundreds of authentication domain CAs, and there may be hundreds of millions of V2X devices in each domain. In order to ensure secure communication, these V2X devices need to download TRCL, which contains the download address of the TDCL trust list of all authentication domain CAs. However, since the TDCL update cycle of each trust domain is different, the device must access each V2X trust domain service one by one to parse and download the updated trust chain. This process is not only cumbersome, but also requires layer-by-layer verification of the trust chain, which greatly increases the time complexity of the operation and the burden of network communication. This high frequency of link verification and trust chain updates undoubtedly increases the computing burden and network overhead of V2X devices, further affecting the efficiency and response speed of the overall system. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a system mutual recognition method, device and equipment for the Internet of Vehicles, so as to solve the problem that the existing Internet of Vehicles PKI system mutual recognition method is cumbersome and complex to operate, affecting the efficiency and response speed of the overall system.

[0006] In a first aspect, an embodiment of the present application provides a system mutual recognition method for an Internet of Vehicles, including:

[0007] Obtain the platform's trusted root certificate, enter the trusted root certificate list and corresponding root certificates of each trust domain, and update the trusted root certificate list in real time;

[0008] Parse the trusted root certificate list, extract the root certificates and trusted root certificate lists of each trust domain, and verify them;

[0009] Provide certificate verification service protocols based on all trust domains;

[0010] The device receives the construction request protocol and parses the construction request protocol, and returns a response message including the certificate trust status in the response protocol to instruct the device to parse the response message and confirm whether the queried certificate is trusted.

[0011] In the above implementation process, the platform's trusted root certificate is obtained, the trusted root certificate list and the corresponding root certificate of each trust domain are entered, and the trusted root certificate list is updated in real time; the trusted root certificate list is parsed, the root certificate and the trusted root certificate list of each trust domain are extracted, and verified; a certificate verification service protocol based on all trust domains is provided; the device's construction request protocol is received and parsed, and a response protocol is returned containing a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted; the process is simple, supports efficient mutual recognition between multiple PKI systems, and solves the pain points of large network resource overhead for interaction of existing Internet of Vehicles devices and low efficiency in issuing trusted root certificate lists.

[0012] Furthermore, before providing the certificate verification service agreement based on all trust domains, it also includes:

[0013] Set up a scheduled task to regularly update and store the valid trusted root certificate list.

[0014] In the above implementation process, through scheduled tasks, the system will regularly update and store the valid trusted root certificate list to ensure that the certificates in the system are always up-to-date and trusted.

[0015] Furthermore, the step of obtaining the trusted root certificate of the platform, entering the trusted root certificate list of each trust domain and the corresponding root certificate, and updating the trusted root certificate list in real time includes:

[0016] Issue the trusted root certificate of the trusted root certificate list management platform TRCLA, and enter the trusted root certificate list TDCL and the corresponding root certificate of each trust domain;

[0017] The trusted root certificate list management platform issues and updates the trusted root certificate list TRCL based on the latest trusted root certificate information.

[0018] In the above implementation process, the trustworthiness and integrity of the certificate is ensured and all communications on the platform are based on the latest certificate chain verification.

[0019] Furthermore, the parsing of the trusted root certificate list, extracting the root certificates and trusted root certificate lists of each trust domain, and performing verification include:

[0020] Parse TRCL and extract the root certificates and TDCL of each trust domain;

[0021] Verify the validity of each root certificate in TDCL and remove revoked or duplicate root certificates; verifying the validity of the root certificate includes checking the validity period of the root certificate, checking the correctness of the certificate signature, and the certificate revocation list CRL.

[0022] In the above implementation process, TRCL is parsed, and the root certificates and TDCL of each trust domain are extracted for subsequent trust verification; the validity of each root certificate in TDCL is verified to ensure that the certificates are valid.

[0023] Further, the receiving device's construction request protocol and parsing the construction request protocol include:

[0024] Receive a construction request protocol from a V2X device; wherein the construction request protocol includes a current version of the structure, a generation time of the current request, and a certificate identifier to query whether a specific certificate is trusted.

[0025] In the above implementation process, V2X devices (such as OBU and RSU) construct a request protocol to query whether a specific certificate is trusted. The device will send a verification request to the system, including the certificate information that needs to be verified.

[0026] Furthermore, the return response protocol includes a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted, including:

[0027] Return a response protocol containing a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted; wherein the response message includes: the current version of the structure, the hash value of the requested security protocol data unit, the certificate identifier and the certificate status;

[0028] The certificate status includes: trusted, revoked and unknown.

[0029] In the above implementation process, the system returns a response message containing the certificate trust status in the response protocol, and the V2X device uses the root certificate of the TRCLA platform to verify the signature of the response message to ensure the authenticity of the message. By parsing the response message, the device can confirm whether the queried certificate is trusted.

[0030] In a second aspect, an embodiment of the present application provides a system mutual recognition device for an Internet of Vehicles, including:

[0031] The certificate acquisition module is used to obtain the trusted root certificate of the platform, enter the trusted root certificate list and corresponding root certificates of each trust domain, and update the trusted root certificate list in real time;

[0032] List parsing module, used to parse the trusted root certificate list, extract the root certificate and trusted root certificate list of each trust domain, and verify them;

[0033] A protocol providing module, used to provide a certificate verification service protocol based on all trust domains;

[0034] The certificate verification module is used to receive the device's construction request protocol and parse the construction request protocol, and return a response message containing the certificate trust status in the response protocol to instruct the device to parse the response message and confirm whether the queried certificate is trusted.

[0035] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0036] A processor, a memory and a bus, wherein the processor is connected to the memory via the bus, and the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, they are used to implement the system mutual recognition method for the Internet of Vehicles as described above.

[0037] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a server, the system mutual recognition method for the Internet of Vehicles as described above is implemented.

[0038] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes instructions, and when the instructions are executed by a computer, the computer implements the method as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0040] Figure 1 A schematic diagram of establishing a trusted relationship between multiple PKI systems provided in an embodiment of the present application;

[0041] Figure 2 A cross-security domain authentication framework diagram provided for an embodiment of the present application;

[0042] Figure 3 A flowchart of a system mutual recognition method for an Internet of Vehicles provided in an embodiment of the present application;

[0043] Figure 4 A flowchart of a system mutual recognition method for an Internet of Vehicles provided in an embodiment of the present application;

[0044] Figure 5 It is a structural diagram of a system mutual recognition device for vehicle networking provided by an embodiment of the present application;

[0045] Figure 6 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0047] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0048] In the Internet of Vehicles system, there may be multiple independent PKI systems that provide certificate services for Internet of Vehicles devices. The service scope of each PKI is called an authentication domain. Cross-authentication domain authentication means that Internet of Vehicles devices located in one authentication domain can authenticate certificates issued to Internet of Vehicles devices in that domain by other authentication domains. The Internet of Vehicles PKI system of the embodiment of the present application is uniformly connected to the Internet of Vehicles security trust root management platform, which manages the root certificates of the PKI systems of various trust domains in the Internet of Vehicles industry, and realizes mutual trust and mutual trust across trust domains across the country.

[0049] Cross-security domain authentication framework Figure 1As shown, in order to implement cross-domain authentication, the device in one authentication domain needs to obtain the Certificate Authority (CA) certificate or certificate chain issued by another authentication domain. In an embodiment of the present application, the top-level CA certificate used for mutual trust operations provided by one authentication domain to another authentication domain is used as a trusted root certificate (Trusted Root Certificate). The top-level CA certificate can be a self-signed root CA certificate of the authentication domain, or it can be a non-self-signed sub-CA certificate of the authentication domain. Through multiple trusted root certificate lists: root certificate (CA-1), root certificate (CA-2),..., root certificate (CA-n), multiple trusted relationships are obtained: root CA-1 (RootCA), root CA-2 (RootCA),..., root CA-n (RootCA). Based on the cross-domain authentication framework, a PKI mutual trust architecture can be obtained, such as Figure 2 shown.

[0050] At present, for cross-domain authentication of Internet of Vehicles devices, the device side must first configure the service address of the Trusted Root Certificate List Management Agency (TRCLA). The V2X device pre-embeds the TRCLA platform root certificate, and then downloads the Trusted Root Certificate List (TRCL). The device first verifies the TRCL signature and then parses the TRCL to download the "Trusted Domain CA Certificate List" (TDCL) of each trusted CA. Since the TDCL update cycle of each trusted domain CA is different, the V2X device side needs to continuously update and download the latest TDCL, and then verify whether the certificate that the V2X device needs to authenticate is credible by downloading the TDCL.

[0051] In a large-scale V2X vehicle networking application system, the system will contain hundreds of authentication domain CAs, and there may be hundreds of millions of V2X devices in each domain. To ensure secure communication, these V2X devices need to download TRCL, which contains the download address of the TDCL trust list of all authentication domain CAs. However, since the TDCL update cycle of each trust domain is different, the device must access each V2X CA service one by one to parse and download the updated trust chain. This process is not only cumbersome, but also requires layer-by-layer verification of the trust chain, which greatly increases the time complexity of the operation and the burden of network communication. This high frequency of link verification and trust chain updates undoubtedly increases the computing burden and network overhead of V2X devices, further affecting the efficiency and response speed of the overall system.

[0052] Assume that there are 100 V2X CA centers in a V2X network, and there is a V2X device (either RSU (Roadside Unit) or OBU (On-Board Unit)). The size of each root certificate is about 1KB, and the total size of the institutional certificates in each TDCL is about 10KB. It can be seen that when a V2X device parses the TRCL, the size of the relevant files read is about 1MB. Given that each V2X device needs to perform this parsing and verification operation, the entire process is not only time-consuming but also consumes a large amount of data traffic. The transmission and parsing of this amount of information puts a certain amount of pressure on the network bandwidth, especially when there are a large number of devices and frequent data requests, which may cause network delays and reduced efficiency. Therefore, in response to such high-traffic and high-frequency operation requirements, the embodiment of the present application provides a system mutual recognition method for the Internet of Vehicles, optimizes the data processing method and the management mechanism of the trust chain, so as to reduce the burden on each device and improve the overall system performance and user experience.

[0053] Please see Figure 3 and Figure 4 , Figure 3 A schematic diagram of a flow chart of a system mutual recognition method for an Internet of Vehicles provided in an embodiment of the present application. The system mutual recognition method for an Internet of Vehicles includes:

[0054] 100. Obtain the trusted root certificate of the platform, enter the trusted root certificate list and corresponding root certificates of each trust domain, and update the trusted root certificate list in real time.

[0055] Specifically, the trusted root certificate of the trusted root certificate list management platform TRCLA is issued, and the trusted root certificate list TDCL of each trust domain and the corresponding root certificate are entered; the trusted root certificate list management platform issues and updates the trusted root certificate list TRCL based on the latest trusted root certificate information; thereby ensuring the integrity of the certificate and that all communications on the platform are based on the latest certificate chain.

[0056] On the basis of the above embodiment, the system mutual recognition method for the Internet of Vehicles can also be embodied as follows: after issuing the trusted root certificate of the trusted root certificate list management platform TRCLA, it also includes:

[0057] Verify the validity of TRCL. If the verification passes, parse the trusted root certificate list; if the verification fails, end the process to ensure that TRCL is valid.

[0058] 200. Parse the trusted root certificate list, extract the root certificate and trusted root certificate list of each trust domain, and perform verification.

[0059] Specifically, parse TRCL, extract the root certificates and TDCL of each trust domain; verify the validity of each root certificate in TDCL, and remove revoked or duplicate root certificates; verifying the validity of the root certificate includes checking the validity period of the root certificate, checking the correctness of the certificate signature, and the certificate revocation list CRL.

[0060] Among them, TRCL is parsed to extract the root certificates and TDCL of each trust domain for subsequent trust verification; the validity of each root certificate in TDCL is verified to ensure that all certificates are valid.

[0061] 300. Provide a certificate verification service protocol based on all trust domains.

[0062] Based on the above embodiment, the system mutual recognition method for the Internet of Vehicles can also be embodied as follows: before providing the certificate verification service protocol based on all trust domains, it also includes:

[0063] Set up a scheduled task to regularly update and store the valid trusted root certificate list.

[0064] Therefore, through scheduled tasks, the system will regularly update and store a list of valid trusted root certificates to ensure that the certificates in the system are always up-to-date and trusted.

[0065] 400. Receive a construction request protocol from a device and parse the construction request protocol, and return a response message including a certificate trust status in a response protocol to instruct the device to parse the response message and confirm whether the queried certificate is trusted.

[0066] Specifically, a construction request protocol of a V2X device is received; wherein the construction request protocol includes the current version of the structure (here the default is 1), the generation time of the current request and the certificate identifier, which is used to query whether a specific certificate is trusted; wherein the V2X device (such as OBU and RSU) queries whether a specific certificate is trusted through the construction request protocol, and the device sends a verification request to the system, including the certificate information that needs to be verified.

[0067] Optionally, a response protocol is returned containing a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted; wherein, the response message includes: the current version of the structure (here the default is 1), the hash value of the requested security protocol data unit spdu, the certificate identifier and the certificate status; wherein, the certificate status includes: trusted, revoked and unknown.

[0068] The system returns a response message containing the certificate trust status in the response protocol, and the V2X device verifies the signature of the response message using the root certificate of the TRCLA platform to ensure the authenticity of the message. By parsing the response message, the device can confirm whether the queried certificate is trusted.

[0069] Therefore, the embodiment of the present application provides a method for supporting efficient mutual recognition between multiple PKI systems in the V2X vehicle network, in order to solve the existing pain points of large network resource overhead for interaction between TRCLA and vehicle network devices and low efficiency in issuing trusted root certificate lists. Through this system, the TRCL authentication mechanism is reconstructed to alleviate the bandwidth limitation and cryptographic operation performance of V2X devices. With the popularization of vehicle network certificates and the participation of multiple CA institutions, TRCL will become too large, which effectively solves the problem of slow download of TRCL by V2X devices and interruption of re-download, and improves the efficiency of network resource utilization. V2X devices can call the system authentication trust chain, which greatly reduces the network resource overhead of a single authentication domain, and the overhead is reduced to about 10 times that of traditional methods.

[0070] As described above, the embodiment of the present application obtains the trusted root certificate of the platform, enters the trusted root certificate list and the corresponding root certificate of each trust domain, and updates the trusted root certificate list in real time; parses the trusted root certificate list, extracts the root certificate and the trusted root certificate list of each trust domain, and verifies them; provides a certificate verification service protocol based on all trust domains; receives the device's construction request protocol and parses the construction request protocol, and returns a response protocol containing a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted; the process is simple, supports efficient mutual recognition between multiple PKI systems, and solves the pain points of large network resource overhead for interaction of existing Internet of Vehicles devices and low efficiency in issuing trusted root certificate lists.

[0071] In addition, the protocol proposed in the embodiment of the present application is intended to verify the certificate credibility and current status of the V2X device, thereby eliminating the need to rely on the traditional certificate revocation list (CRL) and the TDCL of each authentication domain of multiple CAs; it effectively solves the problem of multi-CA cross-certification in the PKI system of vehicle network security certificate management, and supports real-time query of V2X certificate status. In this way, network bandwidth consumption can be significantly reduced, especially when the TDCL and CRL lists are very large. In addition, the deployment of an efficient solution that supports mutual recognition of multiple PKI systems can be centrally managed and maintained, thereby improving the scalability of the system to cope with the growing number of certificates and authentication query needs.

[0072] The system of the embodiment of the present application can be established by a trusted domain CA organization, or built and maintained by an authoritative Internet of Vehicles organization. To ensure the trustworthiness of the system, the TRCLA root certificate is usually pre-installed in the device when the V2X device is manufactured, thus forming the trust basis of the trusted root certificate. The configuration of the trusted root certificate ensures the security of the communication protocol of the V2X device during use, thereby improving the security and stability of the overall system. By establishing a standardized trust mechanism and verification process, users can rely on the authentication status of the V2X device with greater peace of mind, thereby promoting the safe development and widespread application of the Internet of Vehicles.

[0073] The system of the embodiment of the present application provides the function of issuing the TRCLA platform root certificate, and supports the entry of the trusted root certificate (TDCL) list. In this way, a global TRCLA service can be implemented, and the TRCLA trust platform certificate and TRCL can be downloaded. The system supports verification and parsing to obtain the TDCL address, and then downloads the corresponding TDCL trust certificate chain and CRL revocation list, verifies the validity of the parsed certificate, and stores the institution certificate that meets the requirements in the system memory. Provide a certificate trust verification protocol to the outside world. Meet the different verification requirements of the OBU and RSU clients in the V2X device, thereby improving the security and reliability of the entire Internet of Vehicles environment. Through this mechanism, users can efficiently and real-time implement trust management and dynamic updates of certificates, ensuring that they provide secure and reliable certificate status query capabilities in complex V2X communication environments.

[0074] The above steps are not to be performed in a strict order as described in the numbers, but should be understood as an overall solution.

[0075] In the second aspect, based on the above embodiments, Figure 5 This is a schematic diagram of a system mutual recognition device for a vehicle network provided by an embodiment of the present application. Figure 5 The system mutual recognition device for the Internet of Vehicles provided in this embodiment specifically includes:

[0076] The certificate acquisition module 501 is used to obtain the trusted root certificate of the platform, enter the trusted root certificate list of each trust domain and the corresponding root certificate, and update the trusted root certificate list in real time;

[0077] The list parsing module 502 is used to parse the trusted root certificate list, extract the root certificate and the trusted root certificate list of each trust domain, and perform verification;

[0078] The protocol providing module 503 is used to provide a certificate verification service protocol based on all trust domains;

[0079] The certificate verification module 504 is used to receive the device's construction request protocol and parse the construction request protocol, and return a response message containing the certificate trust status in the response protocol to instruct the device to parse the response message and confirm whether the queried certificate is trusted.

[0080] As described above, the embodiment of the present application obtains the trusted root certificate of the platform, enters the trusted root certificate list and the corresponding root certificate of each trust domain, and updates the trusted root certificate list in real time; parses the trusted root certificate list, extracts the root certificate and the trusted root certificate list of each trust domain, and verifies them; provides a certificate verification service protocol based on all trust domains; receives the device's construction request protocol and parses the construction request protocol, and returns a response protocol containing a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted; the process is simple, supports efficient mutual recognition between multiple PKI systems, and solves the pain points of large network resource overhead for interaction of existing Internet of Vehicles devices and low efficiency in issuing trusted root certificate lists.

[0081] Through the system of the embodiment of the present application, the TRCL authentication mechanism is reconstructed, which can reduce the communication bandwidth and computing limitations of V2X devices. There is no need for V2X devices to regularly pull the trust domain and uniformly hand it over to the system for authentication, filtering out untrusted and invalid institution certificates. The system also supports distributed deployment and horizontal expansion. This method can better meet the needs of the system and enable the system to cope with the growing number of users and data. An efficient method for multi-PKI mutual recognition in large-scale V2X vehicle networking systems is realized.

[0082] The system mutual recognition device for the Internet of Vehicles provided in the embodiment of the present application can be used to execute the system mutual recognition method for the Internet of Vehicles provided in the above embodiment, and has corresponding functions and beneficial effects.

[0083] In a third aspect, an embodiment of the present application further provides an electronic device that can integrate the system mutual recognition device for the Internet of Vehicles provided in an embodiment of the present application. Figure 6 Schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Figure 6 The electronic device includes: an input device 63, an output device 64, a memory 62 and one or more processors 61; the memory 62 is used to store one or more programs; when the one or more programs are executed by the one or more processors 61, the one or more processors 61 implement the system mutual recognition method for the Internet of Vehicles provided in the above embodiment. The input device 63, the output device 64, the memory 62 and the processor 61 can be connected by a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0084] The processor 61 executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory 62, that is, realizes the above-mentioned system mutual recognition method for the Internet of Vehicles.

[0085] The electronic device provided above can be used to execute the system mutual recognition method for the Internet of Vehicles provided in the above embodiment, and has corresponding functions and beneficial effects.

[0086] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium, which includes a stored computer program; wherein, when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the system mutual recognition method for the Internet of Vehicles as described above, and can achieve the same beneficial effects.

[0087] Of course, the storage medium containing computer executable instructions provided in an embodiment of the present application is not limited to the system mutual recognition method for the Internet of Vehicles as described above, and can also execute related operations in the system mutual recognition method for the Internet of Vehicles provided in any embodiment of the present application.

[0088] In a fifth aspect, the embodiments of the present application also provide a computer program product, and the methods described in the various embodiments of the present application can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed on a computer, the process or function described in the various embodiments of the present application is executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, a core network device, an OAM (Open Application Model) or other programmable device.

[0089] The computer program or instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer program or instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disk; it may also be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0090] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0091] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0092] If the functions are implemented in the form of software function 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 the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for enabling an electronic device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0093] The above description is only an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0094] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0095] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Claims

1. A system mutual recognition method for vehicle networking, characterized in that: For a PKI security certificate management system for a connected vehicle, the method includes: Obtain the platform's trusted root certificate, enter the trusted root certificate list and corresponding root certificates of each trust domain, and update the trusted root certificate list in real time; Parse the trusted root certificate list, extract the root certificates and trusted root certificate lists of each trust domain, and verify them; Provide certificate verification service protocols based on all trust domains; The device receives the construction request protocol and parses the construction request protocol, and returns a response message including the certificate trust status in the response protocol to instruct the device to parse the response message and confirm whether the queried certificate is trusted.

2. The system mutual recognition method for vehicle networking according to claim 1, characterized in that: Before providing the certificate verification service agreement based on all trust domains, it also includes: Set up a scheduled task to regularly update and store the valid trusted root certificate list.

3. The system mutual recognition method for vehicle networking according to claim 1, characterized in that: The step of obtaining the trusted root certificate of the platform, entering the trusted root certificate list and the corresponding root certificate of each trust domain, and updating the trusted root certificate list in real time includes: Issue the trusted root certificate of the trusted root certificate list management platform TRCLA, and enter the trusted root certificate list TDCL and the corresponding root certificate of each trust domain; The trusted root certificate list management platform issues and updates the trusted root certificate list TRCL based on the latest trusted root certificate information.

4. The system mutual recognition method for vehicle networking according to claim 1, characterized in that: The parsing of the trusted root certificate list, extracting the root certificate and the trusted root certificate list of each trust domain, and verifying them includes: Parse TRCL and extract the root certificates and TDCL of each trust domain; Verify the validity of each root certificate in TDCL and remove revoked or duplicate root certificates; verifying the validity of the root certificate includes checking the validity period of the root certificate, checking the correctness of the certificate signature, and the certificate revocation list CRL.

5. The system mutual recognition method for vehicle networking according to claim 1, characterized in that: The receiving device's construction request protocol and parsing the construction request protocol include: A construction request protocol of a receiving device is parsed; wherein the construction request protocol includes a current version of the structure, a generation time of the current request and a certificate identifier, for querying whether a specific certificate is trusted.

6. The system mutual recognition method for vehicle networking according to claim 1, characterized in that: The return response protocol includes a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted, including: Return a response protocol containing a response message of the certificate trust status to instruct the device to parse the response message and confirm whether the queried certificate is trusted; wherein the response message includes: the current version of the structure, the hash value of the requested security protocol data unit, the certificate identifier and the certificate status; The certificate status includes: trusted, revoked and unknown.

7. A system mutual recognition device for vehicle networking, characterized in that: include: The certificate acquisition module is used to obtain the trusted root certificate of the platform, enter the trusted root certificate list and corresponding root certificates of each trust domain, and update the trusted root certificate list in real time; List parsing module, used to parse the trusted root certificate list, extract the root certificate and trusted root certificate list of each trust domain, and verify them; A protocol providing module, used to provide a certificate verification service protocol based on all trust domains; The certificate verification module is used to receive the device's construction request protocol and parse the construction request protocol, and return a response message containing the certificate trust status in the response protocol to instruct the device to parse the response message and confirm whether the queried certificate is trusted.

8. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the processor is connected to the memory via the bus, and the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, they are used to implement the system mutual recognition method for the Internet of Vehicles as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a server, implements the system mutual recognition method for the Internet of Vehicles as described in any one of claims 1-6.

10. A computer program product, characterized in that The computer program product comprises instructions which, when executed by a computer, cause the computer to implement the method according to any one of claims 1-6.

Images