Certificate application method and device based on vehicle networking, electronic equipment and storage medium

Abstract

This application provides a certificate application method, apparatus, electronic device, and storage medium based on the Internet of Vehicles (IoV). The method, applied in the field of IoV technology, includes: when a vehicle is powered on, detecting whether the storage volume of pseudonym certificates in the vehicle is below a preset threshold; if so, sending a validity period message application request to a target service platform, causing the target service platform to respond to the validity period message application request and return a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service; based on the returned target validity period message, controlling the application for pseudonym certificates to the pseudonym certificate issuing authority. This method enables flexible management of vehicle PC certificate application behavior, avoids a large number of vehicles applying for PC certificates simultaneously, ensures an orderly and controllable certificate application process and balanced service pressure on the IoV platform side, and improves the overall system's operational stability.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and more specifically, to a certificate application method, apparatus, electronic device and storage medium based on vehicle networking technology. Background Technology

[0002] Vehicle-to-everything (V2X) is a branch of the Internet of Things (IoT) in the automotive field and an important application of mobile internet in the automotive sector. V2X is based on V2X technology, which refers to the exchange of information between vehicles and the outside world. It is a key technology of intelligent transportation systems, encompassing four communication modes: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and vehicle-to-network (V2N). This technology is based on two technical routes: cellular network (C-V2X) and dedicated short-range communication (DSRC). Through wireless communication, it enables real-time data interaction, acquiring information such as road conditions, pedestrian locations, and traffic signals, thereby improving driving safety and traffic efficiency.

[0003] Currently, vehicles with V2X capabilities need to use pseudonym certificates (PCs) to digitally sign their Basic Safety Messages (BSMs) broadcast in the vehicle-to-everything (V2X) network when communicating with the outside world. This ensures message trustworthiness and protects vehicle privacy, thus enabling secure communication between the vehicle and the outside world. However, to avoid revealing their driving trajectory, vehicles need to apply for multiple PC certificates from the certificate authority each week for periodic switching. For V2X networks with hundreds of thousands or even millions of vehicles, this PC certificate application method can easily lead to a large number of vehicles sending PC certificate application requests at the same time, creating request peaks. This not only causes network congestion but also seriously affects the operating performance of the certificate authority's servers. Summary of the Invention

[0004] This application provides a certificate application method, device, electronic device, and storage medium based on the Internet of Vehicles. The method enables flexible management of PC certificate application behavior by vehicles and avoids a large number of vehicles applying for PC certificates at the same time.

[0005] Firstly, this application provides a certificate application method based on the Internet of Vehicles (IoV), applied to vehicles, the method comprising:

[0006] When the vehicle is powered on, it is detected whether the amount of pseudonym certificates stored in the vehicle is lower than a preset threshold. If so, a validity period message request is sent to the target service platform, so that the target service platform responds to the validity period message request and returns a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Based on the returned target validity period message, control is used to apply for a pseudonym certificate from the pseudonym certificate issuing authority.

[0007] In conjunction with the first aspect, in some possible implementations, controlling the application for a pseudonym certificate from the pseudonym certificate issuing authority based on the returned target validity period message includes: Based on the returned target validity period message and the current time, determine whether the application triggering conditions for the pseudonym certificate are met; When the application triggering conditions are met, a pseudonym certificate application request is sent to the pseudonym certificate issuing authority, so that the pseudonym certificate issuing authority responds to the pseudonym certificate application request and returns the corresponding pseudonym certificate to the vehicle.

[0008] In conjunction with the first aspect, in some possible implementations, determining whether the application triggering conditions for the pseudonym certificate are met based on the returned target validity period message and the current time includes: Extract the message type identifier from the header of the returned target validity period message; According to the parsing rules corresponding to the extracted message type identifier, the target validity period message is parsed to obtain the service usage status and the service validity period; When the service usage status indicates that the service is enabled, and the current time is within the service validity period, the application triggering condition is determined to be met.

[0009] In conjunction with the first aspect, in some possible implementations, sending the validity period message request to the target service platform includes: Obtain the message type identifier of the requested target validity period message; Generate a validity period message request carrying the acquired message type identifier, and send the validity period message request to the target service platform.

[0010] Secondly, this application provides another certificate application method based on the Internet of Vehicles, applied to a target service platform, the method comprising: Receive the validity period request message sent by the target vehicle; In response to the validity period message application request, the target validity period message corresponding to the target vehicle is determined based on the preset validity period message library. Each validity period message in the validity period message library carries the service usage status and service validity period for the pseudonym certificate service. Send the target validity period message to the target vehicle so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

[0011] In conjunction with the second aspect, in some possible implementations, determining the target validity period message corresponding to the target vehicle based on a preset validity period message library includes: Check if a validity period message bound to the target vehicle exists in the preset validity period message database; If a validity period message bound to the target vehicle is found, the corresponding validity period message will be used as the target validity period message for the target vehicle. If no validity period message bound to the target vehicle is found, a target validity period message corresponding to the target vehicle is generated based on the configuration database and the receiving time of the validity period message application request, and the target validity period message is stored in the validity period message database.

[0012] In conjunction with the second aspect, in some possible implementations, the target validity period message also carries the use case type for the pseudonym certificate service. The step of generating the target validity period message corresponding to the target vehicle based on the configuration database and the reception time of the validity period message application request includes: Obtain the service usage status and usage scenario type of the target vehicle from the configuration database; The service validity period for the pseudonym certificate service is determined based on the usage scenario type and the time of receipt of the validity period message application request. Based on the preset message format, the service usage status, the service validity period, and the usage scenario type, a target validity period message corresponding to the target vehicle is generated.

[0013] In conjunction with the second aspect, in some possible implementations, determining the service validity period for the pseudonym certificate service based on the use case type and the time of receiving the validity period message request includes: Obtain the preset validity period corresponding to the usage scenario type; The sum of the preset validity period and the receiving time of the validity period message request is calculated and used as the service termination time, and the receiving time is used as the service start time to obtain the service validity period for the pseudonym certificate service.

[0014] In conjunction with the second aspect, in some possible implementations, the method further includes: Receive data change requests for the current lifecycle stage of the target vehicle or the service usage status; Update the corresponding data in the configuration database according to the data change request, and delete the target validity period message from the validity period message library.

[0015] Thirdly, this application provides a certificate application device based on the Internet of Vehicles (IoV) for use in vehicles, the device comprising: The detection unit is used to detect whether the amount of pseudonym certificates stored in the vehicle is lower than a preset threshold when the vehicle is powered on. The sending unit is configured to send a validity period message request to the target service platform if the condition is met, so that the target service platform responds to the validity period message request and returns a corresponding target validity period message to the vehicle, wherein the target validity period message carries the service usage status and service validity period for the pseudonym certificate service. The control unit is configured to control the application for a pseudonym certificate from the pseudonym certificate issuing authority based on the returned target validity period message.

[0016] Fourthly, this application provides another certificate application device based on the Internet of Vehicles, applied to a target service platform, the device comprising: The receiving unit is used to receive validity period request messages sent by the target vehicle. The determining unit is configured to, in response to the validity period message application request, determine the target validity period message corresponding to the target vehicle based on a preset validity period message library, wherein each validity period message in the validity period message library carries the service usage status and service validity period for the pseudonym certificate service; The sending unit is configured to send the target validity period message to the target vehicle, so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

[0017] Fifthly, this application provides an electronic device, the electronic device comprising: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the vehicle to perform the method described in the first aspect or any possible implementation thereof.

[0018] Sixthly, this application provides a computer program product comprising computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation thereof.

[0019] In a seventh aspect, this application provides a computer-readable storage medium storing computer program code that, when executed on a computer, causes the computer to perform the method described in the first aspect or any possible implementation thereof.

[0020] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: In one or more embodiments of this application, when the vehicle is powered on, the system detects whether the storage amount of pseudonym certificates in the vehicle is below a preset threshold. If so, a validity period message request is sent to the target service platform, causing the target service platform to respond to the validity period message request and return a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Based on the returned target validity period message, the system controls the application for pseudonym certificates from the pseudonym certificate issuing authority. That is, based on the local storage of PC certificates, the service usage status and service validity period of the PC certificate service are integrated by introducing the validity period message. As a necessary prerequisite for certificate application, it enables differentiated certificate application management for different vehicle usage scenarios based on service usage status and service validity period. This avoids the phenomenon of request peaks caused by relying solely on local stock for PC certificate applications, enabling flexible management of PC certificate application behavior, ensuring an orderly and controllable certificate application process, balancing service pressure on the vehicle networking platform, and improving the overall system's operational stability. On the other hand, it eliminates invalid certificate applications in abnormal scenarios such as PC certificate service shutdown or expiration, ensuring the stability of certificate supply for V2X communication in compliant scenarios while avoiding communication and resource waste in non-compliant scenarios.

[0021] The above description is merely an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

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

[0023] Figure 1 This is an exemplary system architecture diagram of a certificate application method based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 2This is a schematic flowchart of a certificate application method based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 3 This is a schematic diagram of the interaction process between a vehicle and a TSP provided in an exemplary embodiment of this application; Figure 4 This is a flowchart illustrating another certificate application method based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 5 This is a flowchart illustrating another certificate application method based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 6 This is a flowchart illustrating another certificate application method based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 7 This is a schematic diagram of the structure of a certificate application device based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 8 This is a schematic diagram of another certificate application device based on the Internet of Vehicles provided in an exemplary embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0025] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0026] Before introducing this application, the relevant technologies will be introduced first.

[0027] In related technologies, V2X vehicle-to-everything (V2X) networks include multiple nodes, such as vehicles connected to the V2X network, Telematics Service Providers (TSPs), Enrollment Certificate (EC) issuing authorities, Pseudonym Certificate (PC) issuing authorities, Roadside Units (RSUs), and V2X monitoring platforms. The TSP serves as the core middleware node of the V2X system, handling communication and data management between vehicles and backend platforms, certificate authorities, and application service providers. EC issuing authorities issue unique EC certificates to vehicles connected to the V2X network, serving as identification credentials for the vehicle within the V2X system. PC issuing authorities issue short-term, replaceable PC certificates to legitimate vehicles that have already obtained EC certificates, ensuring the privacy and security of V2X communication.

[0028] Specifically, when a V2X vehicle (i.e., a vehicle with V2X capabilities) sends messages (such as vehicle status broadcasts and collaborative sensing information) in the vehicle-to-everything (V2X) network, it needs to sign the message using the private key corresponding to the PC certificate. The receiving node (such as other vehicles or RSUs) verifies the signature using the public key in the PC certificate, confirming the legitimacy and integrity of the message source. The PC certificate is issued by the PC Certificate Authority (PCA) to the On-Board Unit (OBU), and its validity period is generally one week. Typically, vehicles need to apply for multiple PC certificates from the PCA each week for periodic switching to avoid leaking vehicle driving routes. To ensure sufficient PC certificates at the OBU, the OBU usually stores 2-3 weeks' worth of PC certificates, with a weekly limit of 20 certificates. Vehicles trigger a PC certificate application from the PCA according to default rules (e.g., when the PC certificate inventory is less than half full).

[0029] However, on the one hand, when the number of vehicles in a V2X vehicle network reaches hundreds of thousands or even millions, this method of triggering PC certificate applications may lead to a large number of vehicles sending applications to the PC certificate issuing authority at the same time, resulting in a request peak. This not only causes a surge in the load on the PC certificate issuing authority and an increase in response latency, but also causes network bandwidth to be occupied by a large amount of PC certificate download traffic, affecting other critical services of the V2X vehicle network. On the other hand, vehicles will have different PC certificate requirements under different usage scenarios (such as testing, production line production, normal V2X function enabled, and V2X function disabled). For example, vehicles in testing scenarios only need low-frequency PC certificates to support communication verification in closed areas, while operational vehicles with normal V2X function enabled need higher-frequency PC certificates to support their V2X communication, and vehicles with V2X function disabled (such as during fault repair or storage) do not need to apply for new PC certificates. If a unified PC certificate application triggering strategy is still adopted, it will result in invalid certificate applications for non-commercial vehicles such as test vehicles and discontinued vehicles. This will not only waste the computing and storage resources of the PC certificate issuing authority, but also occupy additional vehicle network communication bandwidth, and generate additional operating costs from the perspective of system operation.

[0030] To address at least one of the aforementioned technical problems, embodiments of this application provide a certificate application method, apparatus, electronic device, storage medium, and computer program product based on the Internet of Vehicles.

[0031] Please see Figure 1 , Figure 1 An exemplary system architecture diagram of a certificate application method based on the Internet of Vehicles provided for an exemplary embodiment of this application.

[0032] like Figure 1 As shown, the architecture system may include a vehicle 110, a network 120, and a target service platform 130. The target service platform 130 may be a telematics service provider (TSP). The TSP is mainly responsible for the remote service management of the vehicle, undertaking the communication interaction and data management between the vehicle 110 and other nodes in the vehicle network. The vehicle 110 and the target service platform 130 are connected through the network 120. The network 120 is the medium used to provide communication links. The network 120 may include various types of wireless communication links, including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, etc.

[0033] Inside vehicle 110, the vehicle includes an On-Board Unit (OBU), an on-board network, and a lower-level control system. The OBU, acting as a dedicated V2X communication and control terminal for vehicle 110, has the core function of broadcasting real-time vehicle status information to other nodes in the vehicle network (such as roadside units, other vehicles, and the cloud platform). The OBU establishes a two-way communication link with the lower-level control system through the on-board network, receiving vehicle operation data uploaded by the lower-level control system and sending control commands and signals to it. Specifically, the OBU acts as the command interaction hub: receiving and parsing various operation commands and interactive information input by the user, converting them into standardized control messages, and sending them to the lower-level control system to drive the corresponding lower-level functional modules to execute actions. The lower-level control system, as the execution carrier of vehicle functions, can respond to the commands and signals issued by the OBU and schedule and adjust the supporting modules for various vehicle functions. Each lower-level functional module is composed of hardware components and supporting software working together to achieve the predetermined functions of vehicle 110.

[0034] Specifically, when vehicle 110 is powered on, vehicle 110 can detect whether the storage amount of locally stored pseudonym certificates is lower than a preset threshold. If so, it sends a validity period message application request to the target service platform 130, so that the target service platform 130 responds to the validity period message application request and returns a corresponding target validity period message to vehicle 110. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Finally, based on the returned target validity period message, vehicle 110 applies for a pseudonym certificate from the pseudonym certificate issuing authority.

[0035] It should be understood that Figure 1 The number of vehicles 110, networks 120 and target service platforms 130 is only illustrative and can be any number of vehicles 110, networks 120 and target service platforms 130 as needed.

[0036] Based on the above system architecture, this application provides a certificate application method based on the Internet of Vehicles (IoV). Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating a certificate application method based on a vehicle-to-everything (V2X) network, provided in an exemplary embodiment of this application. This V2X-based certificate application method is applied to a vehicle, and the executing entity of this method can be either the vehicle executing the V2X-based certificate application method or the processor within the vehicle executing the V2X-based certificate application method. For ease of description, the following describes the specific execution process of the V2X-based certificate application method using the processor within the vehicle as an example. The V2X-based certificate application method specifically includes the following steps S202-S206, wherein: S202. When the vehicle is powered on, check whether the amount of fake certificates stored in the vehicle is lower than a preset threshold. If so, proceed to step S204.

[0037] When the vehicle is powered on, the on-board unit (OBU) automatically triggers a self-check process for the number of pseudonym certificates (PC certificates). A PC certificate is a short-term anonymous certificate that does not contain the vehicle's true identity (such as license plate or VIN) and is only used for signing and verification. The security protocol stack is a layered secure communication software architecture built into the OBU. Essentially, it is a standardized software module integrating encryption algorithms, authentication, certificate management, and secure message processing. The security protocol stack typically runs as a core firmware / software component of the OBU, working closely with the OBU's communication module and security chips (such as HSM / TPM) to achieve a combination of hardware-level secure storage and software-level secure processing.

[0038] The self-test process can be as follows: When the vehicle is powered on, the security protocol stack reads the local PC certificate list and counts the number of valid PC certificates (i.e., PC certificates that are valid and have not been revoked). The counted number is then compared with a preset threshold. The preset threshold can be determined based on the number of certificates that the OBU needs to store (certificate holdings). It can be set to half (50%) of the certificate holdings. For example, if the OBU needs to store PC certificates to meet the needs of two weeks of use, and the number of PC certificates per week is 20, then the preset threshold can be set to 20.

[0039] S204. Send a validity period message request to the target service platform, so that the target service platform responds to the validity period message request and returns a corresponding target validity period message to the vehicle, the target validity period message carrying the service usage status and service validity period for the pseudonym certificate service.

[0040] The target service platform can be the aforementioned TSP. Typically, the TSP and OBU continuously transmit various messages, which are the core data carriers for their interaction. Their format and content conform to vehicle networking industry standards (such as GB / T 32960, OMA DM, LWM2M, etc.). The TSP can store and flexibly manage the validity period messages for each vehicle. These validity period messages can be bound to vehicle-related identifiers (such as the vehicle's VIN code or OBU device serial number). The validity period message application request must include this identifier, allowing the TSP to subsequently query the corresponding bound validity period message and return it to the vehicle based on this identifier.

[0041] Each validity period message carries several extended fields, such as the service usage status and service validity period for the PC certificate service. The service usage status refers to the current usage status of the PC certificate service bound to the vehicle, mainly including two types: service on and service off, used to determine whether the vehicle has the business authority to initiate a PC certificate application. The service validity period indicates the timeliness information of the PC certificate service, including the service start time and service end time (accurate to the second, invalid value is FF), used to determine whether the PC certificate service is within the compliance period and avoid initiating invalid certificate applications.

[0042] In this embodiment, by setting a service validity period, certificate application times can be distributed, avoiding a large number of vehicles sending applications to the PC certificate issuing authority within the same time period, thus preventing request peaks and effectively reducing the computing load and network transmission pressure on the PC certificate issuing authority. Simultaneously, by setting service usage status, frequent allocation of PC certificates to inactive vehicles or vehicles not using V2X functionality can be avoided, allowing network resources allocated for PC certificates to be concentrated on vehicles with actual needs, improving the utilization rate of network and certificate resources. Furthermore, by directly linking the number of certificate applications with the number of vehicles effectively serving, relevant operators can achieve refined cost prediction and control, improving the economy and rationality of vehicle network certificate management.

[0043] In addition to the service usage status and validity period mentioned above, each validity period message can also carry other extended fields, such as the usage scenario type. This usage scenario type indicates the specific use case of the PC certificate service. Different usage scenarios can be adapted to different validity periods, thereby achieving refined and scenario-based management of the PC certificate service. Optionally, the usage scenario type includes, but is not limited to, production line activation phase, formal activation phase, testing activation phase, and shutdown phase, which can accurately match the management needs of the PC certificate service in different scenarios throughout the entire vehicle lifecycle, such as production line production, testing and verification, and formal operation (or the sold phase).

[0044] Specifically, to achieve standardized transmission and parsing of messages, each validity period message adopts a structured format. An exemplary format can be represented as: {Service Start Time, Service End Time, Usage Scenario Type, Service Usage Status}. Here, the service start time and service end time are timestamps accurate to the second. The service start time is denoted as T, representing the timestamp when the TSP first receives the validity period message application request in the corresponding usage scenario. The service end time is denoted as T+x, where x is the preset validity period for the corresponding usage scenario. Different usage scenarios can customize the configuration of the duration parameter. For example, x can be set to 14 days in the production line stage, 7 days in the testing stage, and dynamically determined based on the PC certificate service duration purchased by the user in the formal operation stage. To facilitate rapid identification and parsing by the OBU, the usage scenario type can be defined using a hexadecimal string enumeration value. The specific mapping relationship is as follows: 0x00 represents the vehicle being in the production line stage, 0x01 represents the vehicle being in the formal operation stage (the vehicle has been sold), 0x03 represents the vehicle being in the testing stage, and 0x04 represents the vehicle being in the shutdown stage (the vehicle has been sold and the PC certificate service has been actively closed). The service status can include two states: on and off. On means that the PC certificate service is enabled, and off means that the PC certificate service is disabled.

[0045] Please see Figure 3 , Figure 3 This is a schematic diagram of the interaction process between a vehicle and a TSP provided in an exemplary embodiment of this application. When the vehicle security protocol stack detects during self-check that the number of PC certificates is less than half of the total required, to avoid insufficient certificate availability to support subsequent V2X communication needs, the security protocol stack generates a business-level validity period message request and sends it to the OBU (Internal Communication Control Module) through the internal communication interface. This request typically carries a vehicle anonymity identifier, a message type identifier, and a request timestamp. The vehicle anonymity identifier can be a VIN code or an OBU device serial number to prevent the leakage of the vehicle's real identity information. The message type identifier is used by the TSP to quickly identify the purpose of the request, such as whether it requires a validity period message for PC certificate services or another type of message. The request timestamp is used to prevent replay attacks and ensure the timeliness of the request. Next, when the OBU receives the validity period message request, it performs protocol-level encapsulation processing and uses an asymmetric encryption algorithm to digitally sign and encrypt the request to prevent tampering or forgery. Then, it sends the encrypted request to the TSP through the V2X secure communication link. After receiving the request, the TSP first verifies the signature and legitimacy of the request to confirm that the request source is compliant and the message has not been tampered with. After the verification is successful, the TSP queries the internal database for the validity message corresponding to the vehicle based on the vehicle anonymity identifier and message type identifier carried in the request. The TSP then adds the platform's digital signature and response timestamp to the retrieved target validity message and returns it to the OBU through the original communication link, where it is further parsed by the security protocol stack.

[0046] S206. Based on the returned target validity period message, control the application for a pseudonym certificate to the pseudonym certificate issuing authority.

[0047] After receiving the target validity period message returned by the TSP, the vehicle's OBU first completes basic transport layer processing according to the vehicle-to-everything (V2X) communication specifications. This includes digital signature verification and decryption, message legality and integrity verification, and redundant field removal, retaining core business data. The parsed core business data is then sent back to the security protocol stack. The security protocol stack has a deeply integrated processing strategy for validity period messages. This strategy performs deep analysis and business verification on the returned data, extracting key information such as the service usage status and validity period of the PC certificate service. This provides a basis for determining whether to trigger the PC certificate application process. For example, after extracting the service usage status and validity period, the security protocol stack can confirm whether the service usage status is active and whether the current time is within the service validity period. Only when both conditions are met—that the PC certificate service is active and the current time is within the service validity period—does the security protocol stack confirm that the vehicle has the legal authority to apply for a PC certificate. Only then does the OBU initiate a certificate application process with the PC certificate issuing authority to obtain a new PC certificate.

[0048] As described above, the vehicle-to-everything (V2X) certificate application method provided in this embodiment is applied to vehicles. When a vehicle is powered on, it checks whether the amount of pseudonymous certificates stored in the vehicle is below a preset threshold. If so, it sends a validity period message application request to the target service platform, causing the target service platform to respond to the validity period message application request and return a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonymous certificate service. Based on the returned target validity period message, it controls the application for pseudonymous certificates to the pseudonymous certificate issuing authority. That is, based on the local storage of PC certificates, the service usage of PC certificate services is controlled by introducing a validity period message. Service status and service validity period serve as necessary prerequisites for certificate application. By relying on service usage status and service validity period, differentiated certificate application management can be achieved for different vehicle usage scenarios. On the one hand, this avoids the phenomenon of request peaks caused by relying solely on local stock for PC certificate applications, enabling flexible management of PC certificate application behavior, ensuring an orderly and controllable certificate application process, and balancing service pressure on the vehicle networking platform, thereby improving the overall system's operational stability. On the other hand, it can prevent invalid certificate applications in abnormal scenarios such as PC certificate service shutdown or expiration, ensuring the stability of certificate supply for V2X communication in compliant scenarios while avoiding communication and resource waste in non-compliant scenarios.

[0049] Based on the vehicle-to-everything (V2X) certificate application method described in the above embodiments, this application also provides another V2X certificate application method. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart illustrating another vehicle-to-everything (V2X) certificate application method provided in an exemplary embodiment of this application. This V2X certificate application method is applied to vehicles and specifically includes the following steps S302-S310, wherein: S302. When the vehicle is powered on, check whether the amount of fake certificates stored in the vehicle is lower than a preset threshold. If so, execute the following steps S304-S306.

[0050] The steps S302 and S202 are the same as those described above, and will not be repeated here.

[0051] S304. Obtain the message type identifier of the requested target validity period message.

[0052] The message type identifier is a unique identifier agreed upon between the TSP and the vehicle for each message type. Different message types correspond to different message type identifiers, which can be represented as a string. Various types of messages are transmitted between the vehicle and the TSP. For example, the vehicle transmits location reporting messages, fault code reporting messages, and battery status reporting messages to the TSP, while the TSP transmits remote vehicle control command messages, navigation map update messages, time synchronization messages, and the aforementioned expiration messages to the vehicle.

[0053] S306. Generate a validity period message request carrying the obtained message type identifier, and send the validity period message request to the target service platform, so that the target service platform responds to the validity period message request and returns a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service.

[0054] The vehicle generates a data packet requesting the validity period message according to a pre-agreed communication protocol format (such as JSON / Protobuf format) with the TSP. This data packet must carry the message type identifier obtained in step S304, and also attach auxiliary information such as the vehicle's unique identification information (such as VIN code, OBU device serial number), and request timestamp, for the TSP to verify the legitimacy and uniqueness of the request. Afterwards, the vehicle's OBU can send the above request to the TSP via an encrypted vehicle-to-everything (V2X) communication link (such as an HTTPS / TLS encrypted 4G / 5G channel). The sending process must ensure the integrity of the request data (e.g., adding an MD5 checksum) and its tamper-proof nature (e.g., attaching a vehicle digital signature) to prevent the request from being hijacked or tampered with. Upon receiving the request, the TSP first verifies the legitimacy of the request (e.g., verifying the vehicle's identity and whether the message type identifier is within the agreed range). After successful verification, the TSP retrieves the vehicle's validity period message based on the message type identifier and returns it to the vehicle's OBU as the target validity period message.

[0055] S308. Based on the returned target validity period message and the current time, determine whether the application triggering conditions for the pseudonym certificate are met; if the application triggering conditions are met, execute the following step S310.

[0056] The target validity period message must clearly contain two types of key information: the service usage status and service validity period of the PC certificate service. The vehicle receives and parses the message, extracts these two types of key information, and then determines whether it is necessary to apply for a certificate from the PC certificate issuing authority based on the key information.

[0057] In some embodiments, step S308 specifically includes: Extract the message type identifier from the header of the returned target validity period message; According to the parsing rules corresponding to the extracted message type identifier, the target validity period message is parsed to obtain the service usage status and service validity period; When the service usage status indicates that the service is enabled, and the current time is within the service's validity period, the application triggering conditions are determined to be met.

[0058] The vehicle's On-Board Unit (OBU) first performs basic parsing on the received target validity period messages, including digital signature verification and decryption, message legality and integrity verification, and redundant field removal. Then, it transmits the message to the on-board security protocol stack for deep parsing. Specifically, the security protocol stack extracts the message type identifier from the message header, matches it against locally stored parsing rules, and then decrypts, unpacks, and extracts fields from the message body according to the rules. Ultimately, it accurately parses key information such as service usage status (e.g., on (representing PC certificate service enabled) or off (representing PC certificate service disabled)) and service validity period. Typically, all message headers carry fixed fields to identify the message type; this field is the message type identifier. The vehicle locally stores parsing rules corresponding to different message type identifiers. These rules are stored in the OBU's local configuration library (such as configuration files or embedded databases) in key-value pairs of "message type identifier - parsing rule".

[0059] Next, the security protocol stack executes the PC certificate application trigger condition determination: the PC certificate application trigger condition is determined to be met only when both conditions are met simultaneously: "service usage status is on" and "service start time ≤ current time ≤ service end time", thus triggering the subsequent process of applying for a certificate from the PC certificate authority; if either condition is not met (such as service usage status being off or the current time exceeding the service validity period), the certificate application process is terminated, and a determination log is further recorded (such as "service status is off, application conditions are not met") for subsequent user review.

[0060] S310. Send a pseudonym certificate application request to a pseudonym certificate issuing authority, so that the pseudonym certificate issuing authority returns a corresponding pseudonym certificate to the vehicle in response to the pseudonym certificate application request.

[0061] After determining that the conditions for triggering a PC certificate application are met, the vehicle initiates a PC certificate application to the PC certificate issuing authority. For example, based on its own identity information, the vehicle constructs a complete data packet for the PC certificate application request according to the certificate application agreement specifications agreed upon with the PC certificate issuing authority, and sends the application request to the PC certificate issuing authority through a dedicated encrypted communication link. Upon receiving the request, the PC certificate issuing authority performs identity legitimacy verification, application parameter compliance verification, and service permission matching verification. After all verifications pass, it generates a PC certificate that conforms to the vehicle network security standard according to the application parameters (the certificate content usually includes core fields such as vehicle identity identifier, certificate validity / expiration time, and issuing authority digital signature), and returns the PC certificate to the vehicle through an encrypted link. After receiving the PC certificate, the vehicle first verifies the validity of the PC certificate (such as verifying the issuing authority signature and whether the certificate validity period matches). If the verification is successful, the vehicle stores the PC certificate in the secure storage area of ​​the OBU (such as an encryption chip), completing the PC certificate application and download process. If the verification fails or the application is rejected, the vehicle will record the reason for the failure (such as "identity verification failed" or "permissions exceeded") and trigger a retry mechanism or fault alarm.

[0062] Based on the vehicle-to-everything (V2X) certificate application method described in the above embodiments, this application also provides another V2X certificate application method. Please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a flowchart illustrating another certificate application method based on the Internet of Vehicles (IoV) provided in an exemplary embodiment of this application. This IoV-based certificate application method is applied to a target service platform, and its execution entity can be the target service platform itself or a processor within the target service platform. The target service platform can be the aforementioned TSP (Transport Service Platform). For ease of description, the following example uses a processor within the target service platform as the execution entity to illustrate the specific execution process of the IoV-based certificate application method. This IoV-based certificate application method includes the following steps S402-S406, wherein: S402. Receive the validity period message request sent by the target vehicle.

[0063] Among them, the TSP can receive validity period message request requests sent by each vehicle in the vehicle network through the vehicle network security communication link.

[0064] S404. In response to the validity period message request, determine the target validity period message corresponding to the target vehicle based on the preset validity period message database. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service.

[0065] The validity period message request typically includes the vehicle identification identifier and the message type identifier of the requested validity period message. Upon receiving this request, the TSP first verifies the legality of the vehicle identification identifier, confirming that the vehicle has been registered on the platform and its identity information has not been tampered with. Simultaneously, it verifies the validity of the message type identifier to determine if it falls within the preset message type range. If the verification passes, the TSP searches the preset validity period message database for the target vehicle's bound validity period message based on the vehicle identification identifier, using this as the target validity period message. Each validity period message in the validity period message database is pre-bound to the identification identifier of a registered vehicle within the vehicle network. Each validity period message must carry at least the service usage status for the PC certificate service (e.g., on (representing PC certificate service enabled), off (representing PC certificate service disabled)) and the service validity period (including service start and end times).

[0066] S406. Send the target validity period message to the target vehicle so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

[0067] After determining the target validity period message, the TSP encrypts the message using a vehicle-to-everything (V2X) encryption algorithm, such as SM4, and adds a digital signature from the TSP to prevent tampering or forgery during transmission. The encrypted target validity period message is then sent to the OBU of the target vehicle via the V2X secure communication link. Upon receiving the message, the OBU performs basic parsing at the transport layer, including digital signature verification and decryption, message legitimacy and integrity verification, and redundant field removal. The parsed content is then transmitted to the security protocol stack in the target vehicle for deep parsing to extract key information such as the service usage status and validity period of the PC certificate service. The security protocol stack then verifies whether the parsed service usage status is active and whether the current time is within the service validity period. Only when both conditions are met—that the PC certificate service is active and the current time is within the service validity period—does the security protocol stack confirm that the vehicle has the legal authority to apply for a PC certificate. At this point, the OBU initiates a certificate application process with the PC certificate authority to obtain a new PC certificate.

[0068] As described above, the certificate application method based on the Internet of Vehicles provided in this embodiment is applied to a target service platform. It receives a validity period message application request sent by a target vehicle; in response to the validity period message application request, it determines the target validity period message corresponding to the target vehicle based on a preset validity period message library. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service; and it sends the target validity period message to the target vehicle, enabling the target vehicle to apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message. In other words, by introducing a validity period message, the service usage status and service validity period of the PC certificate service are used together as the certificate. This system addresses the necessary prerequisites for certificate application, leveraging service usage status and validity periods to achieve differentiated certificate application management for different vehicle usage scenarios. On one hand, it avoids the surge in requests caused by relying solely on local stockpiles for PC certificate applications, enabling flexible management of PC certificate application behavior, ensuring an orderly and controllable certificate application process, balancing service pressure on the vehicle networking platform, and improving overall system stability. On the other hand, it eliminates invalid certificate applications in abnormal scenarios such as PC certificate service shutdowns or expiration, guaranteeing the stability of certificate supply for V2X communication in compliant scenarios while avoiding communication and resource waste in non-compliant scenarios.

[0069] Based on the vehicle-to-everything (V2X) certificate application method described in the above embodiments, this application also provides another V2X certificate application method. Please refer to [link to relevant documentation]. Figure 6 , Figure 6 This is a flowchart illustrating another certificate application method based on the Internet of Vehicles (IoV) provided in an exemplary embodiment of this application. This IoV-based certificate application method is applied to a target service platform and specifically includes the following steps S502-S510, wherein: S502. Receive the validity period message request sent by the target vehicle.

[0070] The steps S502 and S402 are the same as those described above, and will not be repeated here.

[0071] S504. In response to the validity period message application request, query the preset validity period message database to see if there is a validity period message bound to the target vehicle.

[0072] Upon receiving a validity period message request from any vehicle in the vehicle-to-everything (V2X) network, the TSP first parses the request, extracting core fields such as the target vehicle's unique identifier (e.g., VIN or OBU serial number), the requested message type (the message type identifier corresponding to the validity period message), the request initiation time, and the vehicle terminal signature. Simultaneously, it verifies the request's validity (e.g., signature validity, vehicle registration on the platform, and request format conforming to the TSP interface specification). If verification fails, the request is rejected, and only valid requests are subject to subsequent query operations. Afterward, the TSP calls the query interface of the pre-defined validity period message library, using the target vehicle's identifier as the search keyword to query the validity period messages bound to the target vehicle.

[0073] S506. If a validity period message bound to the target vehicle is found, the corresponding validity period message shall be used as the target validity period message corresponding to the target vehicle.

[0074] S508. If no validity period message bound to the target vehicle is found, a target validity period message corresponding to the target vehicle is generated based on the configuration database and the receiving time of the validity period message application request, and the target validity period message is stored in the validity period message database.

[0075] If the TSP query is successful (a matching validity period message exists), the retrieved validity period message will be returned to the target vehicle as the target validity period message. If the TSP query fails (no matching validity period message exists), the validity period message will be generated in real time based on the basic attribute information of the target vehicle in the configuration database, and the generated validity period message will be bound to the identity identifier of the target vehicle and stored in the validity period message library for subsequent queries.

[0076] Normally, when the basic attribute information of a vehicle in the configuration database changes (such as a change in the service usage status or usage scenario type of the PC certificate service), the deletion operation of the corresponding validity period message in the validity period message library is triggered simultaneously. Only when a request for the validity period message is received again (i.e., the first time a validity period message request is received after the information change) will a new validity period message be generated and stored based on the changed basic attribute information. This ensures that the validity period message always maintains a high degree of consistency with the current actual status of the vehicle, avoiding the misuse of expired / invalid validity period messages due to attribute information changes. On the other hand, regenerating the message only when a new request is received for the first time, rather than actively pushing it to the vehicle, reduces the unnecessary calculation and storage overhead of the TSP platform and avoids generating redundant messages for vehicles that do not currently need PC certificate services.

[0077] In some embodiments, the target validity period message also carries the use case type for the pseudonym certificate service. In this case, the above step "generating the target validity period message corresponding to the target vehicle based on the configuration database and the reception time of the validity period message application request" specifically includes: Retrieve the service usage status and usage scenario type of the target vehicle from the configuration database; Determine the service validity period for the pseudonym certificate service based on the type of use case and the time when the validity period message request is received; Based on the preset message format, the service usage status, the service validity period, and the usage scenario type, generate a target validity period message corresponding to the target vehicle.

[0078] The data in the configuration database is updated in real time based on change instructions pushed by the OEM's backend or related manufacturers (such as the OEM manually adjusting the PC certificate service status). The receipt time of this validity period message request can be considered as the time when the TSP first receives the request after the basic attribute information is updated. The preset message format is a standardized format uniformly defined by the connected vehicle industry or OEMs. Different types of messages can be set with different preset message formats. The message format corresponding to the validity period message can be represented as: {service start time, service end time, usage scenario type, service usage status}.

[0079] Optionally, the usage scenarios include, but are not limited to, the production line activation phase, the formal activation phase, the testing activation phase, and the shutdown phase. This allows for precise matching of PC certificate service management needs across different scenarios throughout the vehicle's lifecycle, such as production line production, testing and verification, and formal operation (or the sold phase). Accordingly, for the production line activation phase, the preset validity period can be set to 14 days; for the testing activation phase, the preset validity period can be set to 7 days; and for the formal activation phase, the preset validity period is dynamically determined based on the duration of the PC certificate service purchased by the user.

[0080] Furthermore, the above step of "determining the service validity period for the pseudonym certificate service based on the target validity period duration and the receipt time of the validity period message request" specifically includes: Get the preset validity period for this use case type; The sum of the preset validity period and the time of receiving the validity period message request is calculated and used as the service termination time. This receiving time is then used as the service start time to obtain the service validity period for the pseudonym certificate service.

[0081] Specifically, the preset validity period is the validity period of the PC certificate service configured for different use case types. The service validity period in the validity period message can be represented as {T, T+x}, where the service start time is denoted as T, representing the timestamp of the first time the TSP receives the validity period message application request in the corresponding use case; the service end time is denoted as T+x, where x is the preset validity period for the corresponding use case.

[0082] Furthermore, basic attribute information in the configuration database can be updated by the in-vehicle terminal or the automaker by sending a request. In this case, the aforementioned certificate application method based on vehicle networking also includes: Receive data change requests for the target vehicle's current lifecycle stage or service usage status; Update the corresponding data in the configuration database according to the data change request, and delete the target validity period message from the validity period message library.

[0083] The lifecycle stages include the production line stage, testing and verification stage, and formal operation (or sold stage). Data change requests regarding lifecycle stages and service usage status can be reported by the vehicle manufacturer or related suppliers. When a vehicle's lifecycle stage changes, the TSP can update the usage scenario type in the configuration database according to the changed lifecycle stage, and update the service validity period according to the preset validity period corresponding to the latest usage scenario type (i.e., x above), thereby updating the target validity period message. Subsequently, when the first validity period message request is received from the target vehicle, a new validity period message is generated based on the request reception time and data in the configuration database. This achieves the goal of dynamically updating PC certificate parameters on the TSP side according to the actual scenario, without modifying the vehicle-side and TSP-side firmware, realizing the certificate management capability of "deploy once, adjust flexibly".

[0084] S510. Send the target validity period message to the target vehicle so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

[0085] The steps S510 and S406 are the same as those described above, and will not be repeated here.

[0086] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0087] It should be noted that the scope of protection of the certificate application method based on the Internet of Vehicles provided in this application is not limited to the above embodiments. Any solution implemented by adding, deleting, or substituting steps in the prior art based on the principles of this application, according to the execution order of each embodiment, is included within the scope of protection of this application. Furthermore, any reasonable substitution or merging of steps between different embodiments based on the principles of this application is also included within the scope of protection of this application.

[0088] Based on the method described in the above embodiments, this application also provides a certificate application apparatus based on the Internet of Vehicles (IoV) for performing the steps in the above-described certificate application method based on the IoV. Please refer to... Figure 7 , Figure 7 This is a schematic diagram of the structure of a vehicle-to-everything (V2X) certificate application device 600 provided in this application embodiment. This V2X certificate application device 600 is applied to a vehicle. Specifically, the V2X certificate application device 600 includes a detection unit 601, a sending unit 602, and a control unit 603, wherein: The detection unit 601 is used to detect whether the amount of fake certificates stored in the vehicle is lower than a preset threshold when the vehicle is powered on. The sending unit 602 is configured to send a validity period message application request to the target service platform if the condition is met, so that the target service platform responds to the validity period message application request and returns a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Control unit 603 is used to control the application for a pseudonym certificate to a pseudonym certificate issuing authority based on the returned target validity period message.

[0089] In some embodiments, the control unit 603 is specifically used for: Based on the returned target validity period message and the current time, determine whether the application trigger conditions for the pseudonym certificate are met; When the application triggering conditions are met, a pseudonym certificate application request is sent to the pseudonym certificate issuing authority, so that the pseudonym certificate issuing authority responds to the pseudonym certificate application request and returns the corresponding pseudonym certificate to the vehicle.

[0090] In some embodiments, the control unit 603 is specifically used for: Extract the message type identifier from the header of the returned target validity period message; According to the parsing rules corresponding to the extracted message type identifier, the target validity period message is parsed to obtain the service usage status and the service validity period; When the service usage status indicates that the service is enabled, and the current time is within the service's validity period, the application triggering conditions are determined to be met.

[0091] In some embodiments, the sending unit 602 is specifically used for: Obtain the message type identifier of the requested target validity period message; Generate a validity period message request carrying the obtained message type identifier, and send the validity period message request to the target service platform.

[0092] As described above, the vehicle-to-everything (V2X) certificate application device 600 provided in this embodiment, when the vehicle is powered on, detects whether the storage amount of pseudonym certificates in the vehicle is lower than a preset threshold through the detection unit 601. If so, the sending unit 602 sends a validity period message application request to the target service platform, so that the target service platform responds to the validity period message application request and returns a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Based on the returned target validity period message, the control unit 603 controls the application for pseudonym certificates to the pseudonym certificate issuing authority. That is, based on the local storage of PC certificates, the PC certificate storage amount is increased by introducing a validity period message. The service usage status and validity period of the certificate service serve as necessary prerequisites for certificate application. By relying on the service usage status and validity period, differentiated certificate application management can be achieved for different vehicle usage scenarios. This avoids the phenomenon of request peaks caused by relying solely on local stock for PC certificate applications, enabling flexible management of PC certificate application behavior, ensuring an orderly and controllable certificate application process, and balancing service pressure on the vehicle networking platform, thereby improving the overall system's operational stability. On the other hand, it can prevent invalid certificate applications in abnormal scenarios such as PC certificate service shutdown or expiration, ensuring the stability of certificate supply for V2X communication in compliant scenarios while avoiding communication and resource waste in non-compliant scenarios.

[0093] Based on the method described in the above embodiments, this application also provides another certificate application apparatus based on the Internet of Vehicles (IoV) for performing the steps in the above-described certificate application method based on the IoV. Please refer to... Figure 8 , Figure 8 This is a schematic diagram of the structure of a vehicle-to-everything (V2X) certificate application device 700 provided in an embodiment of this application. The V2X certificate application device 700 is applied to a target service platform. Specifically, the V2X certificate application device 700 includes a receiving unit 701, a determining unit 702, and a sending unit 703, wherein: Receiving unit 701 is used to receive the validity period message request sent by the target vehicle; The determining unit 702 is used to respond to the validity period message application request by determining the target validity period message corresponding to the target vehicle based on the preset validity period message library. Each validity period message in the validity period message library carries the service usage status and service validity period for the pseudonym certificate service. The sending unit 703 is used to send the target validity period message to the target vehicle so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

[0094] In some embodiments, the determining unit 702 is specifically used for: Check if a validity period message bound to the target vehicle exists in the preset validity period message database; If a validity period message bound to the target vehicle is found, the corresponding validity period message will be used as the target validity period message for the target vehicle. If no validity period message bound to the target vehicle is found, a target validity period message corresponding to the target vehicle is generated based on the configuration database and the receiving time of the validity period message application request, and the target validity period message is stored in the validity period message database.

[0095] In some embodiments, the target validity period message also carries the use case type for the pseudonym certificate service, and the determining unit 702 is specifically used for: Retrieve the service usage status and usage scenario type of the target vehicle from the configuration database; Determine the service validity period for the pseudonym certificate service based on the type of use case and the time when the validity period message request is received; Based on the preset message format, the service usage status, the service validity period, and the usage scenario type, generate the target validity period message corresponding to the target vehicle.

[0096] In some embodiments, the determining unit 702 is specifically used for: Get the preset validity period for this use case type; The sum of the preset validity period and the receiving time of the validity period message request is calculated and used as the service termination time, and the receiving time is used as the service start time to obtain the service validity period for the pseudonym certificate service.

[0097] In some embodiments, the vehicle-to-everything (V2X) based certificate application device 700 further includes an update unit for: Receive data change requests for the current lifecycle stage of the target vehicle or the service usage status; Update the corresponding data in the configuration database according to the data change request, and delete the target validity period message from the validity period message library.

[0098] It should be understood that the division of the unit modules in the above-described vehicle-to-everything (V2X) certificate application device is only for illustrative purposes. In other embodiments, the V2X certificate application device can be divided into different unit modules as needed to complete all or part of the functions of the above-described V2X certificate application device.

[0099] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0100] For example, such as Figure 9 As shown, the electronic device 800 includes a memory 801 and a processor 802. The memory 801 stores executable program code 8011, and the processor 802 is used to call and execute the executable program code 8011 to execute any of the above-mentioned certificate application methods based on the Internet of Vehicles.

[0101] The processor 802 is the control center of the electronic device 800. It connects various parts of the electronic device 800 through various interfaces and lines. By running or loading the application program stored in the memory 801 and calling the data stored in the memory 801, it performs various functions of the electronic device 800 and processes data, thereby monitoring the electronic device 800 as a whole.

[0102] Memory 801 can be used to store application programs and data. The application programs stored in memory 801 contain instructions that can be executed in processor 802. The application programs can be composed of various functional modules. Processor 802 executes various functional applications and data processing by running the application programs stored in memory 801.

[0103] In some embodiments, the electronic device 800 further includes: a radio frequency (RF) circuit, an input unit, an audio circuit, a sensor, and a power supply. The processor 802 is electrically connected to the RF circuit, the input unit, the audio circuit, the sensor, and the power supply. The RF circuit is used to transmit and receive RF signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices. The input unit can be used to receive user-inputted numerical and character information, and to generate inputs related to user settings and function control. The audio circuit can provide an audio interface between the user and the electronic device 800 through a speaker or microphone. The power supply is used to power the various components of the electronic device 800. In some embodiments, the power supply can be logically connected to the processor 802 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0104] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform any of the above-described vehicle-to-everything (V2X) certificate application methods.

[0105] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0106] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0107] It should be understood that the device provided in this embodiment is used to execute any of the above-described certificate application methods based on the Internet of Vehicles, and therefore can achieve the same effect as the above-described implementation methods.

[0108] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0109] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0110] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute any of the vehicle-to-everything (V2X) certificate application methods provided in the above embodiments.

[0111] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement any of the vehicle-to-everything (V2X) certificate application methods provided in the above embodiments.

[0112] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement any of the vehicle-to-everything (V2X) certificate application methods provided in the above embodiments.

[0113] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0114] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0115] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0116] 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.

Claims

1. A certificate application method based on the Internet of Vehicles, characterized in that, Applied to vehicles, the method includes: When the vehicle is powered on, it is detected whether the amount of pseudonym certificates stored in the vehicle is lower than a preset threshold. If so, a validity period message request is sent to the target service platform, so that the target service platform responds to the validity period message request and returns a corresponding target validity period message to the vehicle. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Based on the returned target validity period message, control is used to apply for a pseudonym certificate from the pseudonym certificate issuing authority.

2. The method according to claim 1, characterized in that, The control of applying for a pseudonym certificate from a pseudonym certificate issuing authority based on the returned target validity period message includes: Based on the returned target validity period message and the current time, determine whether the application triggering conditions for the pseudonym certificate are met; When the application triggering conditions are met, a pseudonym certificate application request is sent to the pseudonym certificate issuing authority, so that the pseudonym certificate issuing authority responds to the pseudonym certificate application request and returns the corresponding pseudonym certificate to the vehicle.

3. The method according to claim 2, characterized in that, The step of determining whether the application triggering conditions for the pseudonym certificate are met based on the returned target validity period message and the current time includes: Extract the message type identifier from the header of the returned target validity period message; According to the parsing rules corresponding to the extracted message type identifier, the target validity period message is parsed to obtain the service usage status and the service validity period; When the service usage status indicates that the service is enabled, and the current time is within the service validity period, it is determined that the application triggering conditions for the pseudonym certificate are met.

4. The method according to any one of claims 1-3, characterized in that, The step of sending a validity period message request to the target service platform includes: Obtain the message type identifier of the requested target validity period message; Generate a validity period message request carrying the acquired message type identifier, and send the validity period message request to the target service platform.

5. A certificate application method based on the Internet of Vehicles, characterized in that, Applied to a target service platform, the method includes: Receive the validity period request message sent by the target vehicle; In response to the validity period message request, the target validity period message corresponding to the target vehicle is determined based on the preset validity period message library. The target validity period message carries the service usage status and service validity period for the pseudonym certificate service. Send the target validity period message to the target vehicle so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

6. The method according to claim 5, characterized in that, The step of determining the target validity period message corresponding to the target vehicle based on a preset validity period message library includes: Check if a validity period message bound to the target vehicle exists in the preset validity period message database; If a validity period message bound to the target vehicle is found, the corresponding validity period message will be used as the target validity period message for the target vehicle. If no validity period message bound to the target vehicle is found, a target validity period message corresponding to the target vehicle is generated based on the configuration database and the receiving time of the validity period message application request, and the target validity period message is stored in the validity period message database.

7. The method according to claim 6, characterized in that, The target validity period message also carries the use case type for the pseudonym certificate service. The generation of the target validity period message corresponding to the target vehicle based on the configuration database and the reception time of the validity period message application request includes: Obtain the service usage status and usage scenario type of the target vehicle from the configuration database; The service validity period for the pseudonym certificate service is determined based on the usage scenario type and the time of receipt of the validity period message application request. Based on the preset message format, the service usage status, the service validity period, and the usage scenario type, a target validity period message corresponding to the target vehicle is generated.

8. The method according to claim 7, characterized in that, The step of determining the service validity period for the pseudonym certificate service based on the usage scenario type and the receipt time of the validity period message application request includes: Obtain the preset validity period corresponding to the usage scenario type; The sum of the preset validity period and the receiving time of the validity period message request is calculated and used as the service termination time, and the receiving time is used as the service start time to obtain the service validity period for the pseudonym certificate service.

9. The method according to claim 7, characterized in that, The method further includes: Receive data change requests for the current lifecycle stage of the target vehicle or the service usage status; Update the corresponding data in the configuration database according to the data change request, and delete the target validity period message from the validity period message library.

10. A certificate application device based on the Internet of Vehicles, characterized in that, Applied to vehicles, the device includes: The detection unit is used to detect whether the amount of pseudonym certificates stored in the vehicle is lower than a preset threshold when the vehicle is powered on. The sending unit is configured to send a validity period message request to the target service platform if the condition is met, so that the target service platform responds to the validity period message request and returns a corresponding target validity period message to the vehicle, wherein the target validity period message carries the service usage status and service validity period for the pseudonym certificate service. The control unit is configured to control the application for a pseudonym certificate from the pseudonym certificate issuing authority based on the returned target validity period message.

11. A certificate application device based on the Internet of Vehicles, characterized in that, The device, applied to a target service platform, includes: The receiving unit is used to receive validity period request messages sent by the target vehicle. The determining unit is configured to, in response to the validity period message application request, determine the target validity period message corresponding to the target vehicle based on a preset validity period message library, wherein each validity period message in the validity period message library carries the service usage status and service validity period for the pseudonym certificate service; The sending unit is configured to send the target validity period message to the target vehicle, so that the target vehicle can apply for a pseudonym certificate from the pseudonym certificate issuing authority based on the target validity period message.

12. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1-4 or 5-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1-5 or 6-10.

14. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to perform the method as described in any one of claims 1-4 or 5-9.

Images