Communication method, chip system, vehicle-mounted device, vehicle, medium and product

Abstract

The present application relates to the technical field of vehicles. Disclosed are a communication method, a chip system, a vehicle-mounted device, a vehicle, a medium and a product, which are used for implementing V2X technology-based vehicle communication on the premise of reducing the cost of the vehicle-mounted device. The method comprises: when the vehicle-mounted device is to send a first message to another device, an application core processor generates the first message to be sent; a communication core processor acquires the first message from the application core processor, adds a digital signature to the first message, and sends to said another device the first message to which the digital signature has been added; when the vehicle-mounted device receives a second message from said another device, the communication core processor receives the second message from said another device, verifies a digital signature of the second message, and sends the second message to the application core processor after the verification succeeds; and the application core processor processes the second message.

Description

Communication methods, chip systems, automotive equipment, vehicles, media and products

[0001] This application claims priority to Chinese Patent Application No. 202411759715.5, filed on November 29, 2024, entitled "Communication Method, Chip System, Vehicle-mounted Equipment, Vehicle, Medium and Product", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of vehicle technology, and more particularly to a communication method, chip system, vehicle-mounted equipment, vehicle, medium, and product. Background Technology

[0003] With the development of vehicle-to-everything (V2X) technology, vehicles are able to communicate with other devices in their surroundings to exchange information, thereby improving road safety, traffic efficiency, and driving comfort. However, the process of implementing vehicle communication based on V2X technology typically involves processing massive amounts of data for onboard equipment, posing a significant challenge to the computing power of these devices.

[0004] Currently, in order to meet the high computing power requirements for vehicle communication based on V2X technology, high computing power hardware facilities need to be deployed in the vehicle equipment to realize vehicle communication based on V2X technology. However, the cost of high computing power hardware facilities is high, which makes the cost of vehicle equipment high. Summary of the Invention

[0005] This application provides a communication method, chip system, in-vehicle equipment, vehicle, medium, and product for realizing vehicle communication based on V2X technology while reducing the cost of in-vehicle equipment.

[0006] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0007] Firstly, a communication method is provided, which can be executed by an in-vehicle device, or by a component of the in-vehicle device, such as a processor, chip, or chip system of the in-vehicle device, or by a logic module or software that can implement all or part of the functions of the in-vehicle device.

[0008] In this embodiment of the application, a chip system is taken as the execution entity. The chip system includes an application core processor and a communication core processor.

[0009] The application core processor is the core processor responsible for running applications and processing application data. It typically possesses high computing power and flexibility, supporting the operation of multiple operating systems and applications. The communication core processor is the core processor responsible for communication functions, used to enable data transmission and communication between devices. In essence, the application core processor handles the logic and data of the application, while the communication core processor is responsible for sending this data to external devices or networks through the communication interface. Through the collaboration between the communication core processor and the application core processor, it is possible to ensure that data within the in-vehicle equipment can correctly interact and be transmitted with external devices.

[0010] The method includes:

[0011] When an in-vehicle device needs to send a first message to other devices, the application core processor generates the first message to be sent. For example, the application core processor can collect current vehicle information (such as vehicle location, vehicle speed, etc.) and then generate the first message to be sent based on this information. The communication core processor obtains the first message from the application core processor, adds a digital signature to the first message, and sends the digitally signed first message to other devices. Here, the first message refers to the message to be sent to other devices.

[0012] When the in-vehicle device receives a second message from another device, the communication core processor receives the second message, verifies its digital signature, and, upon successful verification, sends it to the application core processor for processing. The second message refers to the message received from the other device. For example, the application core processor may process the second message by performing application modeling on the vehicle itself and surrounding vehicles to maintain the state of each vehicle, thereby predicting potential threats from surrounding vehicles, such as collisions.

[0013] In the above technical solution, considering that signature and verification processing frequently consume computing power in V2X-based vehicle communication, the existing communication core processor in the onboard unit's SOC is used to perform the signature and verification processes. This effectively utilizes the processing power of the communication core processor without requiring dedicated hardware such as high-specification application core processors or other external devices for signature and verification, thus enabling V2X-based vehicle communication while reducing the cost of onboard equipment.

[0014] In one possible implementation, the chip system is a system-on-a-chip (SOC), which also includes a Trusted Execution Environment (TEE) and a cryptographic engine. The TEE is an independent processing environment with computational and storage capabilities that provides security and integrity protection.

[0015] The communication core processor adds a digital signature to the first message, including: the communication core processor calls the encryption engine in the TEE to add a digital signature to the first message.

[0016] The communication core processor verifies the digital signature of the second message, including: the communication core processor calls the encryption engine in the TEE to verify the digital signature of the second message.

[0017] In the above implementation, by deploying an encryption engine in the SOC's TEE, since the SOC's communication core processor can directly access the TEE, all access is completed inside the SOC and is not exposed outside the chip. No additional security mechanisms are needed to ensure communication security, resulting in higher security.

[0018] In one possible implementation, the TEE also includes a storage module containing a private key.

[0019] The communication core processor calls the encryption engine in the TEE to add a digital signature to the first message, including: the communication core processor obtaining the private key from the storage module; and the communication core processor calling the encryption engine in the TEE to add a digital signature to the first message using the private key.

[0020] In the above implementation, since the basic idea of ​​TEE is to allocate a separate isolated memory block in the hardware for sensitive data, the calculation of sensitive data is carried out in this memory block, and other parts of the hardware cannot access the information in this isolated memory block except through authorized interfaces, storing the private key in the TEE's storage module can ensure the high security of the private key.

[0021] In one possible implementation, the chip system includes a system-on-a-chip (SOC) and a hardware security module (HSM). The SOC includes an application core processor and a communication core processor, and the HSM includes an encryption engine. The HSM is a hardware device specifically designed for protecting and managing digital keys and performing operations such as encryption, decryption, signing, and verification.

[0022] The communication core processor adds a digital signature to the first message, including: the communication core processor calls the encryption engine in the HSM to add a digital signature to the first message;

[0023] The communication core processor verifies the digital signature of the second message, including: the communication core processor calls the encryption engine in the HSM to verify the digital signature of the second message.

[0024] In the above implementation, by deploying an HSM in the vehicle-mounted device and an encryption engine in the HSM, and by accessing the HSM based on the SOC and then calling the encryption engine to complete the signature and verification process, vehicle communication based on V2X technology can also be realized.

[0025] In one possible implementation, the HSM further includes a storage module that includes a private key;

[0026] The communication core processor calls the encryption engine in the HSM to add a digital signature to the first message, including: the communication core processor obtaining the private key from the storage module; and the communication core processor calling the encryption engine in the HSM to add a digital signature to the first message using the private key.

[0027] In the above implementation, the private key is stored in the storage module of the HSM so that the encryption engine can be invoked to complete the signing and verification process.

[0028] In one possible implementation, the communication core processor sends a first message with an added digital signature to other devices, including: the communication core processor encoding the first message and the digital signature to obtain an encoded message; and the communication core processor sending the encoded message to other devices.

[0029] In one possible implementation, before the communication core processor verifies the digital signature of the second message, the method further includes: the communication core processor decoding the received second message to obtain the second message and the digital signature of the second message.

[0030] In the above implementation, in vehicle communication based on V2X technology, considering that encoding and decoding processes also frequently require computing power, the existing communication core processor in the onboard unit's SOC is used to perform the encoding and decoding processes. This effectively utilizes the processing power of the communication core processor without requiring dedicated hardware for encoding and decoding, enabling V2X-based vehicle communication while reducing the cost of onboard equipment.

[0031] In one possible implementation, after the application core processor generates the first message to be sent, the method further includes: the application core processor assembling the digital certificate of the vehicle-mounted device and the first message into a first message packet. Correspondingly, the communication core processor obtains the first message from the application core processor, including: the communication core processor reading the message content of the first message from the first message packet. Correspondingly, the communication core processor sends the digitally signed first message to other devices, including: the communication core processor replacing the first message with the digitally signed first message in the first message packet, and sending the replaced first message packet to the other devices.

[0032] In the above implementation, the signing operation is completed through cooperation between the application core processor and the communication core processor. Specifically, the application core processor first generates a first message packet including the digital certificate of the vehicle-mounted device and a first message; the communication core processor then reads the message content from the first message packet to complete the signing. Subsequently, the first message in the first message packet is replaced with the first message after the digital signature has been added.

[0033] In one possible implementation, the method further includes: applying a core processor to update the digital certificate of the in-vehicle device.

[0034] In the above implementation, considering that the digital certificate update process is highly customized and varies depending on the service provider selected by the vehicle, the application core processor is used to update the digital certificate of the in-vehicle device. Furthermore, since this service is infrequent and requires minimal computing power, it will not impact the computing power of the application core processor.

[0035] In one possible implementation, the communication core processor receives a second message from another device and verifies the digital signature of the second message, including: the communication core processor receiving a second message packet from the other device; the communication core processor unpacking the second message packet to obtain the second message, the digital signature of the second message, and the digital certificate of the other device. Then, the communication core processor verifies the digital certificate of the other device; after the digital certificate of the other device is verified, the communication core processor verifies the digital signature of the second message.

[0036] Secondly, a communication device is provided for implementing any of the methods provided in the first aspect. The communication device includes modules, units, or means corresponding to the methods described above. The actions performed by these modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0037] In one possible implementation, the apparatus may include a generation module and a signature module; wherein:

[0038] The generation module is used by the application core processor to generate the first message to be sent; the signature module is used by the communication core processor to obtain the first message from the application core processor, add a digital signature to the first message, and send the digitally signed first message to other devices.

[0039] And / or, the device may further include a signature verification module and a processing module; wherein:

[0040] The signature verification module is used by the communication core processor to receive the second message from other devices, verify the digital signature of the second message, and send the second message to the application core processor after successful verification; the processing module is used by the application core processor to process the second message.

[0041] Thirdly, a chip system is provided, including an application core processor, a communication core processor, and an interface circuit; the interface circuit is used to receive computer execution instructions and transmit them to the communication core processor; the application core processor and the communication core processor are used to run the computer execution instructions to perform the method of the first aspect or any implementation thereof.

[0042] In some embodiments, the chip system may be a System-on-a-Chip (SOC), which includes an application core processor, a communication core processor, and a TEE. In other embodiments, the chip system may include an SOC and an HSM, wherein the SOC includes an application core processor, a communication core processor, and a TEE.

[0043] Fourthly, an in-vehicle device is provided, comprising: a chip system, the chip system including an application core processor and a communication core processor; the application core processor and the communication core processor are used to invoke computer execution instructions to execute the method described in the first aspect or any implementation thereof.

[0044] In one possible implementation, the vehicle-mounted device further includes a memory for storing computer-executed instructions; the aforementioned application core processor and communication core processor are used to invoke the computer to execute the instructions, thereby implementing the method of the first aspect or any of its implementations.

[0045] The vehicle-mounted device in the fourth aspect can be: the vehicle-mounted device in any implementation of the first aspect, or a device containing the vehicle-mounted device, or a device contained in the vehicle-mounted device, such as a chip.

[0046] Fifthly, a vehicle is provided, the vehicle including an on-board device, the on-board device including a chip system, the chip system including an application core processor and a communication core processor; the application core processor and the communication core processor are used to invoke computer execution instructions to execute the method of the first aspect or any implementation thereof.

[0047] In a sixth aspect, a computer-readable storage medium is provided, comprising computer-executable instructions that, when executed on an in-vehicle device, cause the in-vehicle device to perform the method described in the first aspect or any implementation thereof.

[0048] In a seventh aspect, a computer program product is provided, including computer execution instructions that, when executed on an in-vehicle device, cause the in-vehicle device to perform the method described in the first aspect or any implementation thereof.

[0049] The technical effects of any of the implementation methods in aspects two through seven can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0050] All possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0051] Figure 1 is a schematic diagram of a vehicle communication service process provided by related technologies;

[0052] Figure 2 is a schematic diagram of a certificate chain verification process provided by related technologies;

[0053] Figure 3 is a schematic diagram of the system architecture of a communication method provided by related technologies;

[0054] Figure 4 is a schematic diagram of the system architecture of another communication method provided by related technologies;

[0055] Figure 5 is a schematic diagram of the system architecture of another communication method provided by related technologies;

[0056] Figure 6 is a schematic diagram of the system architecture of a communication method provided in an embodiment of this application;

[0057] Figure 7 is a schematic diagram of the system architecture of another communication method provided in an embodiment of this application;

[0058] Figure 8 is a schematic diagram of the hardware structure of a vehicle-mounted device provided in an embodiment of this application;

[0059] Figure 9 is a schematic diagram of the software architecture of an in-vehicle device provided in an embodiment of this application;

[0060] Figure 10 is a flowchart illustrating a communication method provided in an embodiment of this application;

[0061] Figure 11 is a flowchart illustrating a message sending scenario provided in an embodiment of this application;

[0062] Figure 12 is a flowchart illustrating a message receiving scenario provided in an embodiment of this application.

[0063] Figure 13 is a schematic diagram comparing the process of vehicle communication provided in an embodiment of this application;

[0064] Figure 14 is a comparative schematic diagram of another vehicle communication process provided in the embodiments of this application;

[0065] Figure 15 is a schematic diagram illustrating the effect of vehicle communication according to an embodiment of this application;

[0066] Figure 16 is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0067] In the description of this application, unless otherwise stated, "multiple" means two or more. At least one of the following or similar expressions refer to any combination of these terms, including any combination of single or plural terms. For example, at least one of a, b, and / or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0068] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0069] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0070] It is understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, throughout the specification, various embodiments do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0071] It is understood that some optional features in the embodiments of this application can be implemented independently in certain scenarios without relying on other features, such as the current solution on which they are based, to solve the corresponding technical problems and achieve the corresponding effects. Alternatively, they can be combined with other features as needed in certain scenarios. Correspondingly, the apparatus given in the embodiments of this application can also implement these features or functions, which will not be elaborated here.

[0072] In this application, unless otherwise specified, the same or similar parts between the various embodiments can be referred to each other. In the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The following embodiments of this application do not constitute a limitation on the scope of protection of this application.

[0073] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0074] Based on V2X technology, communication between vehicles (V2V), between vehicles and infrastructure (V2I), between vehicles and pedestrians (V2P), between vehicles and networks (V2N), and between vehicles and the cloud (V2C) can be realized, making vehicles increasingly intelligent and interconnected.

[0075] Among these technologies, V2V-based vehicle communication enables vehicles to share real-time data, such as speed, location, and turn signals. This helps prevent collisions and improves road safety. V2I-based vehicle communication supports communication between vehicles and infrastructure (such as traffic lights, intelligent parking systems, and road signs). This allows vehicles to anticipate traffic conditions and plan routes more effectively, thus avoiding congestion. V2P-based vehicle communication supports communication between vehicles and pedestrians' smartphones or other devices, such as pedestrians sending warning signals to vehicles while crossing the street. This helps protect pedestrian safety. V2N-based vehicle communication supports connectivity between vehicles and a wider range of communication networks, including cellular networks and Wi-Fi. This enables vehicles to access internet services such as navigation, entertainment, and remote monitoring. V2C-based vehicle communication supports connectivity between vehicles and cloud computing resources. This allows vehicles to access more powerful computing capabilities for data analysis, prediction, and decision support.

[0076] Typically, in the process of implementing vehicle communication based on V2X technology, the on-board equipment is involved in the signing, verification, encoding, decoding, packet assembly, and depacketization of messages, which poses a significant challenge to the computing power of the on-board equipment. For example, Figure 1 is a schematic diagram of a vehicle communication business process provided by related technologies. Referring to Figure 1, taking the communication process between a host vehicle and remote vehicles as an example, the vehicle communication business process may include the following steps (1) to (11).

[0077] Step (1) The remote vehicle collects vehicle information and generates message content to be sent.

[0078] Step (2) The remote vehicle encodes the content of the message to be sent to obtain the message to be sent.

[0079] Step (3) The remote vehicle signs the message to be sent to obtain the digital signature of the message.

[0080] Step (4) The remote vehicle encodes the message to be sent and the digital signature of the message to obtain the encoded message and digital signature.

[0081] Step (5) The remote vehicle assembles the encoded message, digital signature, and digital certificate of the remote vehicle into a message packet.

[0082] Step (6) The remote vehicle transmits the message packet to the host vehicle.

[0083] Step (7) The host vehicle unpacks the received message packet to obtain the encoded message, digital signature, and digital certificate of the remote vehicle.

[0084] Step (8) The host vehicle decodes the encoded message and digital signature to obtain the message and the digital signature of the message.

[0085] Step (9) The host vehicle verifies the digital certificate of the remote vehicle and verifies the digital signature of the message based on the digital certificate.

[0086] Step (10) The host vehicle decodes the message to obtain the message content.

[0087] Step (11) The host vehicle performs relevant processing of vehicle information based on the message content.

[0088] In this context, a digital signature refers to a signature created by the sender encrypting a message digest using their private key. After generating the digital signature, it can be attached to the message and sent to the recipient. Upon receiving the message, the recipient can decrypt the digital signature using the sender's public key to obtain the decrypted message digest. Simultaneously, the recipient regenerates the message digest and compares it with the decrypted message digest. If they match, it indicates that the message has not been corrupted or tampered with during transmission. In Figure 1, the remote vehicle corresponds to the sender, and the host vehicle corresponds to the recipient. Signing and verification ensure the authenticity of the message and prevent attacks caused by malicious devices impersonating or forging messages.

[0089] A digital certificate is an electronic document issued by a Certificate Authority (CA) to authenticate the legitimacy of a public key holder. It is understood that a digital certificate carries the sender's public key, enabling the receiver to perform subsequent decryption based on this public key. In some embodiments, digital certificate verification includes verifying each level of the certificate chain. This certificate chain consists of multiple levels of certificates, from the root certificate to the end-user's certificate, such as the root certificate, authority certificates (i.e., intermediate certificates), and pseudonym certificates (i.e., the end-user's certificate). That is, upon receiving a digital certificate, it is necessary to start from that digital certificate and verify upwards level by level to the root certificate to confirm the integrity and authenticity of the certificate chain. For example, Figure 2 is a schematic diagram of a certificate chain verification process provided by related technologies. Referring to Figure 2, taking a certificate chain of root certificate, authority certificate, and pseudonym certificate as an example, after receiving a pseudonym certificate for a message, it is necessary to start from that pseudonym certificate and verify upwards level by level to the root certificate, and then use the public key carried in the pseudonym certificate to verify the digital signature of the message. For example, different vehicles may have the same root certificate, and vehicles of the same model (or brand) may have the same agency certificate. Each vehicle corresponds to a unique pseudonym certificate.

[0090] Figure 1 above illustrates the business process of vehicle communication using the communication between a host vehicle and a remote vehicle as an example. When multiple remote vehicles exist around the host vehicle, more powerful computing power is needed to support this communication. For example, regarding the signature verification process (i.e., verifying pseudonym certificates and digital signatures), assuming the host vehicle's communication coverage is 700m, and there are 200 remote vehicles within 700m of the host vehicle transmitting messages at a rate of 10 Hz, then the host vehicle performs (200 + 2000) signature verifications per second, as shown in Figure 2. This means the pseudonym certificate is verified 200 times / s, and the digital signature is verified 2000 times / s. Each of the 200 remote vehicles corresponds to one pseudonym certificate, meaning the host vehicle needs to verify the pseudonym certificates of 200 remote vehicles per second. Furthermore, the remote vehicles transmit messages at a rate of 10 Hz, meaning each remote vehicle transmits 10 messages per second, each corresponding to a digital signature. This implies that the host vehicle needs to verify 2000 digital signatures per second. Clearly, the signature verification process alone poses a significant challenge to the host vehicle's computing power. In addition, the host vehicle needs to encode and decode the messages, and the encoding and decoding algorithms also consume considerable computing power. Moreover, the host vehicle needs to perform related vehicle information processing, such as application modeling of itself and surrounding vehicles to maintain the state of each vehicle and predict potential threats from surrounding vehicles, such as collisions. This also requires substantial computing power.

[0091] Currently, to realize the aforementioned vehicle communication services based on V2X technology, three types of chips are provided: system-on-chip (SOC), vehicle-to-everything (V2X) application processor, and hardware security module (HSM). SOC, also known as a system-on-a-chip, is a chip that integrates multiple functional modules such as a processor, memory, and peripheral interfaces. V2X AP refers to the application processor used in vehicle-to-everything (V2X) communication, responsible for processing large amounts of data and information in the V2X network to enable communication between vehicles and other entities (such as vehicles, pedestrians, and infrastructure). HSM is a hardware device specifically designed for protecting and managing digital keys and performing operations such as encryption, decryption, signing, and verification.

[0092] Based on this, the relevant technologies provide three system architectures for vehicle-mounted devices, which are described below.

[0093] System Architecture 1: System architecture based on SOC+V2X AP+HSM.

[0094] For example, Figure 3 is a schematic diagram of a system architecture for a communication method provided by related technologies. Referring to Figure 3, the system architecture includes: SOC, V2X AP, and HSM.

[0095] The System-on-a-Chip (SoC) comprises a communication core processor, an application core processor, and a trusted execution environment (TEE). The communication core processor is the core processor responsible for communication functions, enabling data transfer and communication between devices. The application core processor is the core processor responsible for running applications and processing application data; it typically has high computing power and flexibility, supporting the operation of multiple operating systems and applications. In essence, the application core processor handles the logic and data of the application, while the communication core processor is responsible for sending this data to external devices or networks through the communication interface. Through the collaboration between the communication core processor and the application core processor, it is ensured that data within the device can correctly interact and be transmitted with external devices. The TEE is an independent processing environment with computing and storage capabilities, providing security and integrity protection.

[0096] The communication core processor can include a modem, such as a cellular modem and a C-V2X modem as shown in Figure 3. A modem is a collective term for a modulator and demodulator, capable of converting digital signals into analog signals for transmission, and also demodulating received analog signals back into digital signals. It is understood that over-the-air transmission, i.e., data transmission via a wireless channel, is possible based on a modem. In System Architecture 1, the application core processor and TEE (Transport Equipment) are almost entirely uninvolved in V2X-based vehicle communication services, and therefore will not be discussed further.

[0097] A V2X AP comprises functional modules including a V2X application layer, security layer, messaging layer, network layer, access layer adapter, and communication key component. The V2X application layer collects vehicle information or performs related processing. The security layer signs, verifies, encodes, and decodes messages. The messaging layer encodes, decodes, assembles, and deassembles messages. The network layer handles message encoding, decoding, assembly, and deassembly. The access layer adapter transmits messages, such as sending messages from the V2X application layer to other devices or transmitting messages from other devices to the V2X application layer. The communication key component generates communication keys (such as public keys) and updates them periodically. It is understandable that in-vehicle devices can deploy V2X APs of different specifications based on varying computing power requirements.

[0098] HSM comprises a V2X security application, an encryption engine, and a storage module. The V2X security application invokes the encryption engine, which provides signing and verification functions. The storage module stores data such as the vehicle's digital certificates, private keys, and communication keys. The digital certificates can include root certificates, authority certificates, and pseudonymous certificates.

[0099] Referring to Figure 3, the C-V2X modem of the communication core processor and the access layer adapter of the V2X AP can be connected via secure inter-process communication (secure IPC) to enable communication between the communication core processor and the V2X AP. Secure IPC is a mechanism within the operating system or firmware framework that ensures secure communication between different processes or security partitions. For example, after receiving a message from another device, the C-V2X modem of the communication core processor can transmit it to the access layer adapter of the V2X AP. The access layer adapter of the V2X AP can then transmit the message to the V2X application layer of the V2X AP for processing related vehicle information. As another example, after the V2X application layer generates a message to be sent, it can be transmitted to the access layer adapter of the V2X AP. The access layer adapter of the V2X AP can then transmit the message to the C-V2X modem of the communication core processor, so that the C-V2X modem of the communication core processor can transmit the message to other devices.

[0100] Referring to Figure 3, the security layer of the V2X AP and the V2X security application of the HSM can be connected via secure IPC to enable communication between the V2X AP and the HSM. For example, the security layer of the V2X AP can use the V2X security application of the HSM to call the encryption engine to sign messages. As another example, the security layer of the V2X AP can use the V2X security application of the HSM to call the encryption engine to verify the signature on messages.

[0101] In the aforementioned system architecture one, the V2X AP needs to deploy a high-performance V2X application layer and a medium-performance security layer, placing high demands on the V2X AP's computing power, such as a requirement of greater than 5000 DMIPS. DMIPS represents millions of integer operations per second, meaning the V2X AP needs to execute at least 5000 instructions per second. Furthermore, the HSM needs to deploy a high-performance encryption engine, placing high demands on its computing power, such as a signature verification capacity of greater than 2500 transactions per second. This means that in the aforementioned system architecture one, both the V2X AP and HSM require high-specification chips, resulting in higher costs.

[0102] System Architecture 2: System Architecture Based on SOC+HSM.

[0103] For example, Figure 4 is a schematic diagram of the system architecture of another communication method provided by the related technology. Referring to Figure 4, the system architecture includes: SOC and HSM.

[0104] The SOC comprises a communication core processor, an application core processor, and a TEE. The internal structure of the communication core processor is the same as in System Architecture 1 described above and will not be repeated. The application core processor may include functional modules such as the V2X application layer, security layer, messaging layer, network layer, and access layer adaptation. The TEE may include a communication key component. The definitions of the V2X application layer, security layer, messaging layer, network layer, access layer adaptation, and communication key component are the same as in System Architecture 1 described above and will not be repeated.

[0105] Referring to Figure 4, the C-V2X modem of the communication core processor and the access layer adapter of the application core processor can be connected via an inter-chip connector (ICC) to enable communication between the two. The ICC is a connector used to connect different components. For example, after receiving a message from another device, the C-V2X modem of the communication core processor can transmit it to the access layer adapter of the application core processor. The access layer adapter can then transmit the message to the V2X application layer of the application core processor for processing vehicle information. As another example, after the V2X application layer of the application core processor generates a message to be sent, it can transmit it to the access layer adapter. The access layer adapter can then transmit the message to the C-V2X modem of the communication core processor, so that the C-V2X modem can transmit the message to other devices.

[0106] The internal structure of the HSM is the same as that of System Architecture 1 described above, and will not be repeated here. Referring to Figure 4, the security layer of the application core processor and the V2X security application of the HSM can be connected via secure IPC to enable communication between the application core processor and the HSM. For example, the security layer of the application core processor can call the encryption engine to sign messages through the V2X security application of the HSM. As another example, the security layer of the application core processor can call the encryption engine to verify the signature of messages through the V2X security application of the HSM.

[0107] It can be observed that, compared to System Architecture 1, System Architecture 2 utilizes the application core processor and TEE within the SOC, eliminating the need for external V2X APs. However, this also increases the computational power requirements on the SOC. Specifically, the SOC's application core processor needs to deploy high-performance V2X applications and a medium-performance security layer, placing significant demands on its computing power to simultaneously support traditional services and V2X-based vehicle communication services (referred to as V2X services), requiring a computing power exceeding 12,000 DMIPS. Furthermore, the HSM requires a high-performance encryption engine, placing high demands on its computing power, such as a signature verification capacity exceeding 2,500 messages per second. This means that in System Architecture 2, the SOC's application core processor must support not only traditional services but also V2X services, potentially impacting traditional or existing services due to insufficient computing power.

[0108] System Architecture 3: SOC-based System Architecture.

[0109] For example, Figure 5 is a schematic diagram of the system architecture of another communication method provided by the related technology. Referring to Figure 5, the system architecture includes: SOC.

[0110] The SOC comprises a communication core processor, an application core processor, and a TEE. The internal structure of the communication core processor is the same as in System Architecture 1 described above and will not be repeated. The application core processor may include functional modules such as the V2X application layer, security layer, messaging layer, network layer, and access layer adaptation. Furthermore, the application core processor is used to store data such as pseudonymous certificates and authority certificates. The TEE may include V2X security applications, an encryption engine, and a storage module. The storage module can be used to store data such as the root certificate and private key of the onboard device. The definitions of the V2X application layer, security layer, messaging layer, network layer, access layer adaptation, and communication key components are the same as in System Architecture 1 described above and will not be repeated.

[0111] It can be observed that, compared to System Architecture 1 and System Architecture 2, System Architecture 3 integrates HSM functionality onto the SOC. However, the SOC's application core processor needs to deploy high-performance V2X applications and a medium-performance security layer, placing extremely high demands on its computing power. It must simultaneously meet the needs of both traditional and V2X services, requiring a computing power exceeding 15,000 DMIPS. Consequently, the high specifications of the SOC lead to excessively high costs, making it suitable only for vehicle-mounted devices supporting V2X services, and not for other vehicle-mounted devices that do not support V2X services, resulting in a lack of chip universality.

[0112] In summary, to achieve vehicle communication based on V2X technology, related technologies require the additional deployment of high-performance hardware in the vehicle equipment, such as high-specification V2X APs or SoCs with high-specification application core processors, to meet the full computing power requirements of V2X services, resulting in high costs for the vehicle equipment. Furthermore, using SoCs with high-specification application core processors presents several challenges. First, the computing power of the SoC's application core processor must support not only traditional services but also V2X services, potentially impacting traditional or existing services due to insufficient computing power. Second, the SoC is only applicable to vehicle equipment supporting V2X services, and not to other vehicle equipment that does not support V2X services, leading to chip incompatibility.

[0113] In view of this, embodiments of this application provide a communication method. When an on-board device is about to send a first message to another device, the communication core processor in the on-board device's SOC adds a digital signature to the first message and sends the digitally signed first message to the other device. When the on-board device receives a second message from another device, the communication core processor in the on-board device's SOC verifies the digital signature of the second message and obtains the second message after successful verification. In vehicle communication based on V2X technology, considering that signature and verification processing requires frequent computational power, the existing communication core processor in the on-board device's SOC is used to perform the signature and verification processes. In this way, the processing power of the communication core processor can be effectively utilized without the need to deploy dedicated hardware facilities for signature and verification, enabling vehicle communication based on V2X technology while reducing the cost of on-board devices. This means that there is no need to deploy a SoC with a high-specification application core processor in the vehicle equipment. On the one hand, it can avoid the application core processor of the SoC from affecting traditional or existing businesses due to insufficient computing power. On the other hand, it reduces the cost of the application core processor of the SoC, making the SoC applicable to vehicle equipment that supports V2X services as well as other vehicle equipment that does not support V2X services, thus improving the versatility of the chip.

[0114] To facilitate understanding of the embodiments of this application, the following points will be explained before introducing the embodiments of this application.

[0115] 1. In the embodiments of this application, the descriptions such as "in the case of", "if" and "if" all refer to the fact that the device (e.g., vehicle-mounted device) will make corresponding processing under certain objective circumstances. They are not time limits, nor do they require the device (e.g., vehicle-mounted device) to have a judgment action when it is implemented, nor do they mean that there are other limitations.

[0116] 2. The system architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0117] 3. The actions, terms, etc., involved in the various embodiments of this application can be referred to each other without limitation. The message names or parameter names in the messages between the various devices in the embodiments of this application are just examples, and other names can be used in specific implementations without limitation.

[0118] The system architecture and application devices of the embodiments of this application will be described by way of example below.

[0119] In some embodiments, the communication method provided in this application can be applied to the system architecture shown in FIG6. For example, FIG6 is a schematic diagram of a system architecture for a communication method provided in an embodiment of this application. Referring to FIG6, the system architecture may include a System-on-Chip (SOC).

[0120] The System-on-Chip (SOC) comprises a communication core processor, an application core processor, and a TEE. Referring to Figure 6, the communication core processor includes a cellular modem, a C-V2X modem, an access layer, and a security layer. The application core processor includes a V2X application layer, a messaging layer, a network layer, and a certificate management component. The TEE includes a V2X security application, an encryption engine, and a storage module. In some embodiments, both the communication core processor and the application core processor can access the TEE.

[0121] In this embodiment of the application, the communication core processor is used to add a digital signature to a first message and send the digitally signed first message to other devices in a message sending scenario. And / or, the communication core processor is used to verify the digital signature of a second message and obtain the second message after successful verification in a message receiving scenario.

[0122] In the communication core processor, the access layer is used to communicate with other external devices, such as sending messages to or receiving messages from other devices. The security layer is used to perform cryptographic operations such as signing, verifying signatures, encoding, and decoding. In some embodiments, the security layer of the communication core processor and the network layer of the application core processor are connected via ICC, enabling communication between the communication core processor and the application core processor. In other embodiments, the security layer of the communication core processor can access V2X security applications in the TEE to invoke the encryption engine to perform cryptographic operations such as signing or verifying messages.

[0123] In this embodiment, the application core processor is used to generate a first message to be sent. And / or, the application core processor is used to process a second message that has passed verification.

[0124] In the application core processor, the V2X application layer provides data processing functions related to the aforementioned V2X services, such as collecting vehicle information or performing related processing. The message layer is used for encoding, decoding, packet assembly, and depacketization of messages. The network layer is also used for encoding, decoding, packet assembly, and depacketization of messages. The certificate management component generates digital certificates for in-vehicle devices and updates them periodically. For example, the certificate management component generates and periodically updates root certificates, authority certificates, and pseudonyms. In some embodiments, the certificate management component can periodically update root certificates, authority certificates, and pseudonyms based on public key infrastructure (PKI). It is understood that root certificates, authority certificates, and pseudonyms can each correspond to different update cycles; for example, root certificates may be updated annually, authority certificates every two weeks, and pseudonyms daily. PKI is a standard-compliant security platform technology and specification that utilizes public key cryptography to provide encryption and digital signature services, as well as the necessary key and certificate management system for all network applications.

[0125] The application core processor is also used to store pseudonym certificates for in-vehicle devices, such as storing the pseudonym certificate in the rich execution environment (REE) where the application core processor's operating system runs. This allows the application core processor (such as the V2X application layer or messaging layer) to use the pseudonym certificate to assemble outgoing messages after generating the first message to be sent, and also facilitates the application core processor (such as a certificate management component) to periodically update the pseudonym certificate.

[0126] In this embodiment, the TEE, acting as a secure zone, possesses two main functions: secure computation and secure storage. Within the TEE, a storage module can be used to store the root certificate, authority certificate, and private key of the on-board unit. In some embodiments, the certificate management component of the application core processor can access the TEE's storage module to update the root certificate and authority certificate. In other embodiments, the certificate management component also needs to synchronously derive the private key when generating pseudonymous certificates. It is noteworthy that throughout the entire lifecycle of vehicle communication, when operations such as signing or verification are required, the private key is accessed within the TEE and not accessed externally (e.g., by the REE). This means that the private key is securely stored within the TEE and does not leave this secure environment. This prevents the risk of private key leakage or misuse, ensuring the security and confidentiality of the private key within the TEE.

[0127] In some embodiments, during the message signing process, the security layer of the communication core processor can obtain a private key from the TEE's storage module to generate a digital signature. During the message verification process, the root certificate and authority certificate can be obtained from the TEE's storage module to complete the digital certificate verification.

[0128] It is worth noting that Figure 6 uses the example of storing the pseudonym certificate in the application core processor and the organization certificate in the TEE. In other embodiments, the pseudonym certificate can also be stored in the TEE and the organization certificate can also be stored in the application core processor. This application does not limit this.

[0129] In other embodiments, the communication method provided in this application can be applied to the system architecture shown in FIG7. For example, FIG7 is a schematic diagram of the system architecture of another communication method provided in this application. Referring to FIG7, the system architecture may include a SOC and an HSM.

[0130] The SOC comprises a communication core processor, an application core processor, and a TEE. Referring to Figure 7, the communication core processor includes a cellular modem, a C-V2X modem, an access layer, and a security layer. The application core processor includes the V2X application layer, messaging layer, network layer, and certificate management components. The TEE includes communication key components. The HSM includes V2X security applications, an encryption engine, and a storage module.

[0131] It can be observed that, compared to the system architecture shown in Figure 6, the SOC+HSM-based system architecture shown in Figure 7 uses an external HSM to replace the SOC's TEE. The SOC's communication core processor can directly access the HSM to perform cryptographic operations such as message signing, verification, encoding, and decoding.

[0132] The system architecture provided in this application deploys the security layer within the communication core processor, enabling the communication core processor to perform most of the security layer's tasks, especially the signature and verification operations that frequently consume computing power. Compared to system architecture one provided by related technologies, it eliminates the need for an external V2X AP, reducing hardware costs. Compared to system architecture two and system architecture three provided by related technologies, it eliminates the need to deploy the security layer within the application core processor. This reduces the load on the application core processor, effectively balancing the computing power consumption of the application core processor and the communication core processor, and lowering the system specification requirements for the application core processor. Furthermore, it allows the application core processor to utilize sufficient computing power to support traditional services, avoiding disruption to traditional or existing services due to insufficient computing power. This means that the embodiments of this application can utilize low-cost SOCs to implement V2X services, are applicable to currently standardized SOCs, and can meet V2X service requirements with minor modifications, without the need to design a new SOC.

[0133] Understandably, the system architecture provided in this application embodiment retains the original certificate management components in the security layer within the application core processor. This is because, on the one hand, this part of the work is highly customized and will vary depending on the PKI service provider selected by the vehicle. On the other hand, since this service is infrequent and requires low computing power, it will not impact the computing power of the application core processor.

[0134] The SOC-based system architecture shown in Figure 6 or the SOC+HSM-based system architecture shown in Figure 7 can be applied to in-vehicle equipment. In some embodiments, the in-vehicle equipment can be a telematics control unit box (TBOX) or a V2X box.

[0135] The TBOX box is a product integrating vehicle network and wireless communication functions. In some embodiments, the TBOX box connects to a backend telematics service provider (TSP) platform to achieve real-time uploading of vehicle data and remote control, thereby providing car owners with a more convenient and safer driving experience. The V2X box is an in-vehicle communication module integrating multiple communication technologies (such as cellular networks, Wi-Fi, Bluetooth, etc.) and a vehicle interface. In some embodiments, through the V2X box, vehicles can obtain real-time traffic information, road conditions, pedestrian dynamics, etc., thereby improving driving safety and traffic efficiency.

[0136] The aforementioned vehicle-mounted equipment can be applied to vehicles, trains, airplanes, ships, and other means of transportation. This application will subsequently use a vehicle as an example to illustrate the solution. In one possible implementation, the communication method provided in this application can be applied to a vehicle message sending scenario, such as when the vehicle-mounted equipment is about to send a message to other devices. This application will subsequently use the term "first message" to refer to the message to be sent by the vehicle-mounted equipment. Alternatively, in another possible implementation, the communication method provided in this application can be applied to a vehicle message receiving scenario, such as when the vehicle-mounted equipment receives a message from other devices. This application will subsequently use the term "second message" to refer to the message received by the vehicle-mounted equipment. These other devices can be vehicle-mounted equipment of surrounding vehicles, infrastructure equipment, pedestrian equipment, network equipment, or cloud equipment, etc.

[0137] In one example of this application, a schematic diagram of the hardware structure of the vehicle-mounted device is shown in Figure 8. Figure 8 is a schematic diagram of the hardware structure of a vehicle-mounted device provided in an embodiment of this application.

[0138] Referring to Figure 8, the vehicle-mounted device 800 may include: a processor 810, an internal memory 820, a universal serial bus (USB) interface 830, a charging management module 840, antenna 1 and antenna 2, a mobile communication module 850, a wireless communication module 860, an audio module 870, a sensor module 880, and a camera 890.

[0139] The sensor module 880 may include one or more of the following sensors: pressure sensor 880A, gyroscope sensor 880B, accelerometer sensor 880C, distance sensor 880D, ambient light sensor 880E, and touch sensor 880F.

[0140] The processor 810 may include one or more processing units, such as an application processor (AP), a microcontroller unit (MCU), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. For example, the application processor may include a graphics processor and a digital signal processor, and the microcontroller unit may include a graphics processor. In this embodiment, the processor 810 may include a communication core processor and an application core processor.

[0141] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0142] The processor 810 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 810 is a cache memory. This memory can store instructions or data that the processor 810 has just used or that are used repeatedly. If the processor 810 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 810, and thus improves the efficiency of the system.

[0143] The internal memory 820 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM). The RAM can be directly read and written by the processor 810 and can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, as well as user and application data. The NVM can also store executable programs and user and application data, and can be pre-loaded into the RAM for direct read and write operations by the processor 810. In this embodiment, the internal memory 820 may include a TEE.

[0144] The USB 830 interface is an interface that conforms to the USB standard specification, specifically it can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc.

[0145] The charging management module 840 is used to receive charging input from the charger. The charger can be a wireless charger or a wired charger.

[0146] The wireless communication function of the vehicle-mounted device 800 can be implemented through antenna 1, antenna 2, mobile communication module 850, wireless communication module 860, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the vehicle-mounted device 800 can be used to cover one or more communication frequency bands.

[0147] The mobile communication module 850 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for use in vehicle-mounted devices 800. The mobile communication module 850 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 850 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 850 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 850 may be housed in the processor 810. In some embodiments, at least some functional modules of the mobile communication module 850 and at least some modules of the processor 810 may be housed in the same device.

[0148] A modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor or microcontroller unit.

[0149] The wireless communication module 860 can provide solutions for wireless communication applications on the vehicle-mounted device 800, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), and intrabody communication (IBC). The wireless communication module 860 can be one or more devices integrating at least one communication processing module. The wireless communication module 860 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 810. The wireless communication module 860 can also receive signals to be transmitted from processor 810, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0150] In some embodiments, the antenna 1 of the vehicle-mounted device 800 is coupled to the mobile communication module 850, and the antenna 2 is coupled to the wireless communication module 860, enabling the vehicle-mounted device 800 to communicate with the network and other devices via wireless communication technology.

[0151] The in-vehicle device 800 can implement audio functions through the audio module 870 and the processor 810, such as music playback and recording. The audio module 870 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. The audio module 870 can also be used for encoding and decoding audio signals.

[0152] The 880A pressure sensor is used to sense pressure signals and convert them into electrical signals. There are many types of 880A pressure sensors, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors.

[0153] The gyroscope sensor 880B can be used to determine the motion attitude of the vehicle-mounted device 800. In some embodiments, the gyroscope sensor 880B can determine the angular velocity of the vehicle-mounted device 800 about three axes (i.e., the x, y, and z axes). The gyroscope sensor 880B can be used in navigation scenarios.

[0154] The accelerometer 880C can detect the magnitude of acceleration of the vehicle-mounted device 800 in various directions (typically three axes). When the vehicle-mounted device 800 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the attitude of the vehicle-mounted device 800.

[0155] The 880D distance sensor is used to measure distance.

[0156] The 880E ambient light sensor is used to detect ambient light intensity.

[0157] The touch sensor 880F, also known as a "touch device," is used to detect touch operations applied to or near it. The touch sensor 880F can then transmit the detected touch operation to the processor 810 (e.g., an application processor, microcontroller unit) to determine the type of touch event.

[0158] It should be noted that the structure shown in Figure 8 does not constitute a limitation on the vehicle-mounted device. In addition to the components shown in Figure 8, the vehicle-mounted device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0159] The vehicle-mounted device provided in this application embodiment can run an operating system (OS). The operating system can be various operating systems used in the industry, such as an operating system developed based on Open Harmony, such as Harmony OS; or other operating systems such as Android Automotive OS (which can be abbreviated as AAOS); it can also be various open-source operating systems or their derivative operating systems, such as Linux OS, and other embedded operating systems; or it can be a new type of operating system in the future, such as an AI operating system based on artificial intelligence.

[0160] For example, in this embodiment, the communication core processor may be equipped with a real-time operating system (RTOS), capable of handling the communication tasks of cellular modems and C-V2X modems with high real-time requirements. A real-time operating system is a type of operating system specifically designed for real-time applications, used to handle real-time tasks such as communication tasks. Specifically, a real-time operating system is an operating system that can accept and process external events or data at a sufficiently fast speed, provide a rapid response within a specified time, schedule all available resources to complete real-time tasks, and control all real-time tasks to run in a coordinated manner.

[0161] For example, in this embodiment, the application core processor can be installed with a multi-tasking operating system, such as Linux, which can be used to handle traditional services such as Telematics Service Provider (TSP) services, emergency call (eCall) services, and V2X services. Here, TSP services refer to the related services of a Telematics Service Provider. A Telematics Service Provider is a supplier that provides services in the field of vehicle networking, integrating communication technology, positioning technology, network technology, and automotive technology to provide a range of intelligent services for vehicles. eCall services refer to the related services of an emergency call system. An emergency call system is a system used by vehicles to automatically or manually call a rescue and dispatch platform center in emergency situations.

[0162] An operating system is a set of interconnected system software programs that manage and control the operation of in-vehicle equipment, utilize and run hardware and software resources, and provide public services to organize user interactions. In in-vehicle equipment, the operating system interfaces downwards with the physical hardware layer and provides a runtime environment for application software.

[0163] An operating system typically includes a kernel layer, a middleware layer, and an application layer. The application layer includes applications, which can include system applications and third-party applications. The middleware layer includes a suite of software providing various services to application developers, or frameworks providing services such as databases, multimedia, and graphics, or capabilities such as distributed scheduling and system scaling. For example, the middleware layer may include a framework layer and / or a system service layer. The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The system service layer includes the system's core capabilities, providing services to applications through the framework layer. The kernel layer is the layer between hardware and software. The kernel layer may include hardware drivers and the operating system kernel. In addition to providing hardware drivers, the kernel layer also supports functions such as memory management and system process management.

[0164] Depending on the form and function of different in-vehicle devices, different application scenarios, and different user needs, the operating systems used in these devices may also differ. The basic functions implemented by the in-vehicle device provided in this application can be implemented using a general-purpose operating system or a dedicated operating system. To more clearly illustrate the implementation of the embodiments of this application under a specific operating system, the architecture of Harmony OS is shown below. Those skilled in the art can deduce the implementation of the embodiments of this application under other specific operating systems, such as AAOS.

[0165] Figure 9 is a schematic diagram of the software architecture of an in-vehicle device provided in an embodiment of this application. Referring to Figure 9, the software architecture of the in-vehicle device can be divided into several layers. In some embodiments, from bottom to top, they are: kernel layer, system service layer, framework layer, and application layer. The layers communicate with each other through software interfaces. System functions can be tailored, added, or combined at the subsystem granularity in different device deployment scenarios, and each subsystem can also be tailored, added, or combined at the functional granularity.

[0166] The kernel layer includes the kernel abstract layer (KAL), the kernel subsystem, and the driver subsystem.

[0167] KAL provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including but not limited to process / thread management, memory management, file system, network management, and peripheral management. The kernel subsystem supports selecting a suitable OS kernel for different resource-constrained devices, not limited to Linux, HarmonyOS, LiteOS (lite operating system), etc. The driver subsystem's driver framework is the foundation for the open system hardware ecosystem, providing unified peripheral access capabilities and a framework for driver development and management. The driver framework includes: display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, etc. For example, in this embodiment, the in-vehicle device can control the sensors in the vehicle to collect vehicle data, such as vehicle speed and position, based on the sensor driver.

[0168] The system service layer comprises the core capabilities of the system, providing services to applications through the framework layer. This layer includes, but is not limited to, a set of subsystems for basic system capabilities, basic software services, enhanced software services, and hardware services.

[0169] The system's basic capability subsystem set provides fundamental capabilities for the operation, scheduling, and migration of distributed applications across multiple devices. This set may include distributed soft bus, distributed data management, distributed task scheduling, and Ark multi-language runtime; it may also include multi-modal input subsystem, graphics subsystem, security subsystem, and AI subsystem.

[0170] Among them, distributed task scheduling enables distributed service management (discovery, synchronization, registration, and invocation), supporting remote startup, remote invocation, remote connection, and migration of applications across devices. Distributed data management enables data synchronization, data storage, data sharing, and data access across all scenarios and devices. The distributed soft bus provides communication-related capabilities for seamless interconnection between multiple devices, including WLAN service capabilities, Bluetooth service capabilities, soft bus, inter-process communication (remote procedure call, RPC), and StarFlash communication capabilities. The Ark Multi-Language Runtime is a unified compilation runtime platform designed to support the joint compilation and execution of multiple programming languages ​​and multiple chip platforms.

[0171] Basic software service subsystem set: provides public and general software services; the basic software service subsystem set may include event notification subsystem, telephone service subsystem, multimedia subsystem, etc.

[0172] Enhanced software service subsystem suite: Provides differentiated enhanced software services for different devices; the enhanced software service subsystem suite may include smart screen proprietary business subsystem, wearable proprietary business subsystem, IoT proprietary business subsystem, etc.

[0173] Hardware service subsystem set: Provides hardware services; the hardware service subsystem set may include location service subsystem, unified identity and access management (IAM) subsystem, wearable proprietary hardware service subsystem, biometric identification, IoT proprietary hardware service subsystem, etc.

[0174] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. Referring to Figure 9, the framework layer includes: the ArkUI framework (which provides a complete infrastructure for UI development of system applications, including UI functions such as components, layouts, animations, and interactive events, as well as a real-time interface preview tool), the user application framework, and the Ability framework (an Ability is a lightweight application; the Ability framework schedules and manages the operation and lifecycle of Abilities). Different devices may run different operating systems, and the APIs they support may also differ.

[0175] The HarmonyOS API is a series of open capabilities provided to support HarmonyOS application development. The HarmonyOS API can be set at the framework layer or independently of the framework layer. The HarmonyOS API includes the Audio API (audio service), Push API (push service), and Account API (account service), among others.

[0176] Applications can include system apps and extended / third-party apps. System apps can include the desktop, control bar, settings, contacts, phone, camera, etc., while extended / third-party apps can include social apps, travel apps, etc.

[0177] For ease of understanding, the communication method provided in the embodiments of this application will be described below with reference to the above system architecture and accompanying drawings.

[0178] It is understood that in the embodiments of this application, the vehicle-mounted device may perform some or all of the steps in the embodiments of this application. These steps or operations are merely examples. The embodiments of this application may also perform other operations or variations of various operations.

[0179] Figure 10 is a flowchart illustrating a communication method provided in an embodiment of this application. In some possible implementations, this communication method can be applied to an in-vehicle device, which is equipped with a chip system. This chip system can be the system architecture shown in Figure 6 or Figure 7 above. Referring to Figure 10, taking the application core processor and communication core processor included in the chip system as the execution entities as an example, the method can include the following case one and / or case two.

[0180] Scenario 1: When the vehicle-mounted device is about to send a first message to other devices, the method may include the following steps S1001 to S1004.

[0181] S1001, The application core processor generates the first message to be sent.

[0182] In this context, the first message refers to a message to be sent to other devices. The first message can be a vehicle status message, indicating the vehicle's current location, speed, or time. Of course, in other embodiments, the first message can also be other types of messages, such as safety warning messages, emergency rescue messages, etc. This application does not limit the type of the first message.

[0183] In some embodiments, the application core processor collects vehicle information of the current vehicle. Then, based on the collected vehicle information, the application core processor generates a first message to be sent.

[0184] For example, vehicle information can be position-velocity-time (PVT) data, such as vehicle position, vehicle speed, or time. For another example, vehicle information can also be dead reckoning (DR) data. For yet another example, vehicle information can also be real-time kinematic (RTK) data. This application does not limit the type of vehicle information.

[0185] S1002, the communication core processor obtains the first message from the application core processor.

[0186] S1003, the communication core processor adds a digital signature to the first message.

[0187] In some embodiments, the signature can be implemented in different ways depending on the system architecture of the chip system. The process of the communication core processor adding a digital signature to the first message is described below based on the system architecture shown in Figure 6 or Figure 7.

[0188] Implementation Method 1: Taking the SOC-based system architecture shown in Figure 6 as an example, the process of the communication core processor adding a digital signature to the first message can be as follows: The communication core processor in the vehicle device's SOC calls the encryption engine in the TEE of the vehicle device's SOC to add a digital signature to the first message.

[0189] In one possible implementation, the communication core processor in the vehicle's SoC retrieves the private key from the storage module of the TEE (Transmission Equipment) within the SoC. Then, the communication core processor in the SoC invokes the encryption engine in the TEE to add a digital signature to the first message using the private key. Thus, since the basic idea of ​​a TEE is to allocate a separate, isolated memory block for sensitive data in the hardware, ensuring that all computations related to sensitive data are performed within this memory block, and that other parts of the hardware cannot access the information in this isolated memory block except through authorized interfaces, storing the private key in the TEE's storage module guarantees high security for the private key.

[0190] In the system architecture shown in Figure 6, by deploying a security layer in the communication core processor of the SOC and an encryption engine in the TEE of the SOC, the computing power requirements of V2X services can be met using a single SOC. This eliminates the need for high-specification application core processors or other external devices, reducing the cost of onboard equipment. Furthermore, since both the communication core processor and the TEE are deployed in the same SOC, on the one hand, all access is completed internally within the SOC, not exposed to the outside chip, eliminating the need for additional security mechanisms to ensure communication security, thus providing higher security. On the other hand, it allows the communication core processor to directly access the TEE, enabling it to quickly call the encryption engine within the TEE to complete the signing and verification process, significantly reducing message processing latency and ensuring low latency in message processing.

[0191] Implementation Method 2: Taking the system architecture based on SOC and HSM shown in Figure 7 as an example, the process of the communication core processor adding a digital signature to the first message can be as follows: The communication core processor in the SOC of the vehicle device calls the encryption engine in the HSM of the vehicle device to add a digital signature to the first message.

[0192] In one possible implementation, the communication core processor in the vehicle's SoC obtains the private key from the storage module of the vehicle's HSM. Then, the communication core processor in the vehicle's SoC invokes the encryption engine in the HSM to add a digital signature to the first message using the private key.

[0193] In the system architecture shown in Figure 7 above, by deploying a security layer in the communication core processor of the SOC and an encryption engine in the HSM, the computing power requirements of V2X services can be met based on the SOC and HSM, without the need to deploy application core processors or other external devices with high specifications, thus reducing the cost of vehicle equipment.

[0194] The process of adding a digital signature to the first message using a private key, as described above, may include: a communication core processor in the vehicle-mounted device's SOC extracting a digest of the first message using a message digest algorithm; the communication core processor in the vehicle-mounted device's SOC encrypting the digest of the first message using the private key to obtain a digital signature of the first message; and the communication core processor in the vehicle-mounted device's SOC adding the digital signature of the first message to the first message. For example, the message digest algorithm may be a secure hash algorithm (SHA) or a message-digest algorithm 5 (MD5), etc. This application does not limit this specific implementation.

[0195] S1004, the communication core processor sends the first message with the added digital signature to other devices.

[0196] In some embodiments, the communication core processor in the SoC of the vehicle-mounted device encodes the first message and a digital signature to obtain an encoded message. Then, the communication core processor in the SoC sends the encoded message to other devices. The encoding may be ASN.1 encoding.

[0197] In the embodiments shown in S1001 to S1004 above, when the vehicle-mounted device is about to send a first message to other devices, the communication core processor in the vehicle-mounted device's SOC adds a digital signature to the first message and sends the digitally signed first message to other devices. By utilizing the communication core processor deployed in the vehicle-mounted device's SOC to perform the signature processing, the processing power of the communication core processor can be effectively utilized to realize vehicle communication based on V2X technology. This eliminates the need for additional high-computing-power hardware, reducing the cost of the vehicle-mounted device.

[0198] Scenario 2: When the vehicle-mounted device receives a second message from another device, the method may include the following steps S1005 to S1008.

[0199] S1005, the communication core processor receives a second message from other devices.

[0200] In this context, the second message refers to a message received from another device. Taking the other device as an in-vehicle device of a nearby vehicle as an example, the second message could be a vehicle status message, indicating the vehicle's location, speed, or time. Taking the other device as infrastructure equipment such as a traffic light as an example, the second message could be the status of the traffic light, such as red, green, or yellow. Of course, in other embodiments, the second message can also be other types of messages, such as safety warning messages, emergency rescue messages, etc. This application does not limit the type of the second message.

[0201] S1006, The communication core processor verifies the digital signature of the second message.

[0202] In some embodiments, signature verification can be implemented in different ways depending on the system architecture of the chip system. The following describes the process by which the communication core processor verifies the digital signature of the second message, based on the system architecture shown in Figure 6 or Figure 7.

[0203] Implementation Method 1: Taking the SOC-based system architecture shown in Figure 6 as an example, the process of the communication core processor verifying the digital signature of the second message can be as follows: The communication core processor in the vehicle-mounted device's SOC calls the encryption engine in the TEE of the vehicle-mounted device's SOC to verify the digital signature of the second message.

[0204] Implementation Method 2: Taking the system architecture based on SOC and HSM shown in Figure 7 as an example, the process of the communication core processor verifying the digital signature of the second message can be as follows: the communication core processor in the SOC of the vehicle device calls the encryption engine in the HSM of the vehicle device to verify the digital signature of the second message.

[0205] The process of verifying the digital signature of the second message described above can include: The communication core processor in the vehicle-mounted device's SOC extracts a message digest information of the second message using a message digest algorithm. The communication core processor in the vehicle-mounted device's SOC decrypts the digital signature of the second message based on the public key of other devices to obtain the decrypted message digest information. The communication core processor in the vehicle-mounted device's SOC compares the decrypted message digest information with the newly extracted message digest information. If they match, the verification is successful. If they do not match, the verification fails.

[0206] In some embodiments, before performing S1006 above, the received second message is decoded based on the communication core processor in the vehicle-mounted device's SOC to obtain the second message and its digital signature. Then, the digital signature of the second message is verified based on the communication core processor in the vehicle-mounted device's SOC. The decoding can be ASN.1 decoding.

[0207] S1007. After successful verification, the communication core processor sends a second message to the application core processor.

[0208] S1008, the application core processor processes the second message.

[0209] In the embodiments shown in S1005 to S1008 above, when the vehicle-mounted device receives a second message from another device, the communication core processor in the vehicle-mounted device's SOC verifies the digital signature of the second message and obtains the second message after successful verification. By utilizing the communication core processor deployed in the vehicle-mounted device's SOC to perform the signature verification process, the processing power of the communication core processor can be effectively utilized to realize vehicle communication based on V2X technology. This eliminates the need for additional high-computing hardware, reducing the cost of the vehicle-mounted device.

[0210] Regarding the scenario shown in Figure 10 above, the process of sending messages in the scenario shown in Figure 11 will be described in detail below. Figure 11 is a schematic diagram of a message sending scenario provided by an embodiment of this application. Referring to Figure 11, taking the application core processor and communication core processor included in the chip system of the vehicle device as the execution entities as an example, the method includes the following S1101-S1106.

[0211] S1101, The application core processor generates the first message to be sent.

[0212] The content of S1101 can be found in the content of S1001 shown in Figure 10 above, and will not be repeated here.

[0213] S1102. The application core processor combines the digital certificate of the vehicle-mounted device with the first message to obtain the first message packet.

[0214] For example, the packet can be a DSMP packet. DSMP is a dedicated short message protocol, and DSMP packetization refers to combining multiple data units or information units into a single data packet based on this dedicated short message protocol for transmission, storage, or processing.

[0215] S1103, The communication core processor reads the message content of the first message from the first message packet.

[0216] In some embodiments, the communication core processor reads the message content (payload) of the first message packet according to an offset. Understandably, the offset can be used to locate a specific position in an array, string, or memory. The payload refers to the message content transmitted in the first message, also known as the actual information, actual data, or data body.

[0217] The above S1102 to S1103 describe the process by which the communication core processor obtains the first message to be sent from the application core processor, so that the communication core processor can subsequently perform the signature processing.

[0218] S1104, the communication core processor adds a digital signature to the first message based on the message content of the first message.

[0219] The content of S1104 can be found in S1003 shown in Figure 10 above, and will not be repeated here.

[0220] S1105, the communication core processor replaces the first message in the first message packet with the first message after adding a digital signature.

[0221] S1106, The communication core processor sends the replaced first message packet to other devices.

[0222] The above steps S1105 to S1106 describe the process by which the communication core processor sends the first message, after adding a digital signature, to other devices. Thus, by performing a replacement operation in the first message packet, the update of the first message packet is completed.

[0223] In the embodiment shown in Figure 11 above, when the vehicle-mounted device is about to send a first message to other devices, vehicle communication based on V2X technology is realized in the message sending scenario of the vehicle based on the cooperation between the application core processor and the communication core processor included in the system chip of the vehicle-mounted device.

[0224] Regarding scenario two shown in Figure 10 above, the process for message reception in scenario two will be described in detail below based on Figure 12. Figure 12 is a schematic diagram of a message reception scenario provided by an embodiment of this application. Referring to Figure 12, taking the communication core processor and application core processor deployed in the SOC of the vehicle-mounted device as the execution entities as an example, the method includes the following S1201-S1206.

[0225] S1201, The communication core processor receives a second message packet from other devices.

[0226] S1202, the communication core processor unpacks the second message packet to obtain the second message, the digital signature of the second message, and the digital certificates of other devices.

[0227] S1203, the communication core processor, verifies the digital certificates of other devices.

[0228] S1204. After the digital certificate verification of other devices is successful, the communication core processor verifies the digital signature of the second message.

[0229] S1205. After successful verification, the communication core processor sends a second message to the application core processor.

[0230] S1206, The application core processor processes the second message.

[0231] In the embodiment shown in Figure 12 above, when the vehicle-mounted device receives a second message from another device, vehicle communication based on V2X technology is realized in the vehicle message receiving scenario based on the cooperation between the application core processor and the communication core processor included in the chip system of the vehicle-mounted device.

[0232] For example, Figure 13 is a schematic diagram comparing the process of vehicle communication provided by an embodiment of this application. Referring to Figure 13, taking a message sending scenario as an example, the process of sending messages based on system architecture three in related technologies and the process of sending messages based on an embodiment of this application are shown.

[0233] Referring to (13-1) in Figure 13, the message sending process based on the system architecture 3 in the related technology is mainly executed by the application core processor. The specific process may include:

[0234] ① Application layer packet assembly. This means that the application layer of the application core processor (such as the V2X application layer) assembles vehicle information into vehicle information packets. For example, the application layer of the application core processor assembles vehicle information into basic safety messages (BSM) packets.

[0235] ② Application layer encoding. This means that the application layer of the application core processor encodes the vehicle information packet to obtain the message to be sent. For example, the application layer of the application core processor performs ASN.1 encoding on the vehicle information packet.

[0236] ③ Security layer signature. This means that the application kernel processor's security layer signs the message to be sent, obtaining the message's digital signature.

[0237] ④ Security layer encoding. This means that the application kernel processor's security layer encodes the message to be sent and its digital signature, resulting in the encoded message and digital signature. For example, the application kernel processor's security layer performs ASN.1 encoding on the message to be sent and its digital signature.

[0238] ⑤ Network Layer Packet Assembly. This means that the application core processor's network layer assembles the encoded message, digital signature, and vehicle pseudonym certificate into a message packet. For example, the application core processor's network layer performs DSMP packet assembly on the encoded message, digital signature, and vehicle pseudonym certificate.

[0239] ⑥ Access layer transmission. This means that the access layer of the communication core processor transmits message packets to other devices.

[0240] Referring to (13-2) in Figure 13, the message sending process based on the embodiments of this application can be completed by the application core processor and the communication core processor working together. The specific process may include:

[0241] ① Application layer packet assembly. This means that the application layer of the application core processor assembles vehicle information into a vehicle information packet.

[0242] ② Application layer encoding. This means that the application layer of the application core processor encodes the vehicle information packet to obtain the message to be sent.

[0243] ③ Network layer packet assembly. This means that the application processor's network layer assembles the message to be sent with the vehicle's pseudonym certificate to obtain a message packet.

[0244] ④ The network layer reads messages. This means that the network layer of the communication core processor extracts the message content from the message packet.

[0245] ⑤ Security layer signature. This means that the security layer of the communication core processor signs the message to be sent, obtaining the digital signature of the message.

[0246] ⑥ Security layer encoding. This means that the security layer of the communication core processor encodes the message to be sent and its digital signature to obtain the encoded message and digital signature.

[0247] ⑦ The network layer updates the message packet. This means that the network layer of the communication core processor replaces the original message packet with a message that has been digitally signed, resulting in an updated message packet.

[0248] ⑧ Access Layer Transmission. This means that the access layer of the communication core processor transmits the updated message packets to other devices.

[0249] For example, Figure 14 is a schematic diagram comparing another vehicle communication process provided by an embodiment of this application. Referring to Figure 14, taking a message receiving scenario as an example, the process of receiving messages based on system architecture three in related technologies and the process of receiving messages based on an embodiment of this application are shown.

[0250] Referring to (14-1) in Figure 14, the message receiving process in the system architecture 3 based on related technologies is mainly executed by the application core processor. The specific process may include:

[0251] ① Access layer transmission. This means that the access layer of the communication core processor receives messages from other devices.

[0252] ② Network layer unpacking. This means that the application core processor's network layer unpacks the received message to obtain the encoded message, digital signature, and vehicle pseudonym certificate. For example, the application core processor's network layer performs DSMP unpacking on the received message.

[0253] ③ Security layer decoding. This means that the application kernel processor's security layer decodes the encoded message and digital signature to obtain the message and its digital signature. For example, the application kernel processor's security layer performs ASN.1 decoding on the encoded message and digital signature.

[0254] ④ Security layer verification. This means that the application's core processor's security layer verifies the vehicle's pseudonym certificate and the digital signature of the message.

[0255] ⑤ Application layer decoding. This means that the application layer of the application core processor decodes the message to obtain the decoded message packet. For example, the application layer of the application core processor performs ASN.1 decoding on the message.

[0256] ⑥ Application layer unpacking. This means that the application layer of the application core processor unpacks the message packet to obtain vehicle information. For example, the application layer of the application core processor performs BSM unpacking on the message packet.

[0257] Referring to (14-2) in Figure 14, the message sending process based on the embodiments of this application can be completed by the application core processor and the communication core processor working together. The specific process may include:

[0258] ① Access layer transmission. This means that the access layer of the communication core processor receives messages from other devices.

[0259] ② Network layer unpacking. This means that the network layer of the communication core processor unpacks the received message to obtain the encoded message, digital signature, and vehicle pseudonym certificate. For example, the network layer of the communication core processor performs DSMP unpacking on the received message.

[0260] ③ Security layer decoding. This means that the security layer of the communication core processor decodes the encoded message and digital signature to obtain the message and its digital signature. For example, the security layer of the communication core processor performs ASN.1 decoding on the encoded message and digital signature.

[0261] ④ Security layer signature verification. This means that the security layer of the communication core processor verifies the vehicle's pseudonym certificate and the digital signature of the message.

[0262] ⑤ After successful verification, a message is sent to the application core processor. This means that after both the vehicle's pseudonym certificate and the message's digital signature have been verified, the communication core processor's network layer sends a message to the application core processor's network layer.

[0263] ⑥ Application layer decoding. This means that the application layer of the application core processor decodes the message to obtain the decoded message packet. For example, the application layer of the application core processor performs ASN.1 decoding on the message.

[0264] ⑦ Application layer unpacking. This means that the application layer of the application core processor unpacks the message packet to obtain vehicle information. For example, the application layer of the application core processor performs BSM unpacking on the message packet.

[0265] In this embodiment, a security layer is deployed in the communication core processor. In the message sending scenario, the security layer is used to sign and encode the message to be sent, thereby sending a digitally signed message. This eliminates the need for the application core processor to sign the message. In the message receiving scenario, the security layer verifies and decodes the received message. If the verification passes, the message is sent to the application core processor; otherwise, the message is discarded by the communication core processor. This eliminates the need for the application core processor to perform verification and decoding after receiving the message, effectively balancing the computing power consumption of the application core processor and the communication core processor, and reducing the system specification requirements for the application core processor.

[0266] Compared with the system architectures shown in related technologies, the embodiments of this application reduce the high computing power deployment requirements of the application core processor at the network and security layers, effectively reducing the computing power requirements of the application core processor. For example, Figure 15 is a schematic diagram of the effect of vehicle communication provided by an embodiment of this application. Referring to Figure 15, the computing power requirements of system architecture one, system architecture two, system architecture three in related technologies, and the system architectures shown in Figure 6 and Figure 7 in the embodiments of this application are illustrated. It can be seen that system architecture one requires the deployment of a SOC, V2XAP, and HSM. System architecture two requires the deployment of a SOC and HSM with high computing power application core processors. System architecture three requires the deployment of a SOC with high computing power application core processors.

[0267] The system architectures shown in Figure 6 and Figure 7 in this embodiment, compared to System Architecture 1, simplify the system architecture by eliminating the need for an external V2X AP for V2X services while reducing computing power requirements. Compared to System Architectures 2 and 3, this embodiment reduces the computing power requirements of the application core processor in the SOC, significantly lowering the design difficulty and cost of the SOC. Furthermore, it not only avoids the application core processor's inability to meet computing power requirements from impacting traditional or existing services, but also makes the SOC applicable to vehicle devices supporting V2X services as well as other vehicle devices that do not support V2X services, improving the chip's versatility.

[0268] The system architecture shown in Figure 6 of this application embodiment ensures that all access is completed within the SOC, without being exposed outside the chip. This reduces the risk of HSM spoofing and eliminates the need for additional security mechanisms to guarantee communication security, resulting in higher security. Furthermore, since V2X services are time-sensitive, placing some processing logic in the communication core processor significantly reduces message processing latency, improving V2X service processing efficiency and thus enhancing the user experience for V2X users.

[0269] It should be noted that the above description is for the purpose of more clearly explaining the communication method described in the embodiments of this disclosure, and should not be construed as limiting the specific implementation of this application.

[0270] The above mainly describes the solutions provided by the embodiments of this application from the perspective of processing flow. Correspondingly, the embodiments of this application also provide a communication device for implementing the various methods described above. This communication device can be one of the methods described above, or include the aforementioned devices, or be a usable component. It is understood that, in order to achieve the above functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0271] This application embodiment can divide the communication device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be understood that the module division in this application embodiment is illustrative and is only a logical functional division. In actual implementation, there may be other division methods.

[0272] For example, Figure 16 is a schematic diagram of a communication device provided in an embodiment of this application. Referring to Figure 16, the communication device includes a generation module 1601 and a signature module 1602, and / or a signature verification module 1603 and a processing module 1604. Wherein:

[0273] The generation module 1601 is used to execute S1001 shown in FIG10 or S1101 shown in FIG11.

[0274] The signature module 1602 is used to execute S1002 to S1004 shown in FIG10 or S1103 to S1106 shown in FIG11.

[0275] The signature verification module 1603 is used to execute S1005 to S1007 shown in Figure 10 or S1201 to S1205 shown in Figure 12.

[0276] Processing module 1604 is used to execute S1008 shown in FIG10 or S1206 shown in FIG12.

[0277] In some possible implementations, the device further includes a calling module for performing the process of calling the encryption engine to perform signing or verification in the embodiment shown in FIG10.

[0278] In some possible implementations, the device further includes an encoding module for performing the process of encoding the first message and digital signature in the embodiment shown in FIG11 above.

[0279] In some possible implementations, the device further includes a decoding module for performing the process of decoding the received second message in the embodiment shown in FIG12 above.

[0280] In some possible implementations, the device further includes a packet assembly module for performing the process of assembling the digital certificate, the first message, and the digital signature in the embodiment shown in FIG11 above.

[0281] In some possible implementations, the device further includes an unpacking module for performing the process of unpacking the second message packet in the embodiment shown in FIG12 above.

[0282] For a detailed description of the above-mentioned optional methods, please refer to the foregoing method embodiments, which will not be repeated here. Furthermore, the explanation of any of the communication devices provided above and the description of their beneficial effects can be found in the corresponding method embodiments described above, and will not be repeated here.

[0283] As an example, referring to FIG8, some or all of the functions implemented in the generation module 1601 and signature module 1602, and / or signature verification module 1603 and processing module 1604 of the communication device shown in FIG16 can be implemented by the processor 810 in FIG8 executing the computer execution instructions in the internal memory 820 in FIG8.

[0284] In this embodiment, the communication device is presented as an integrated unit divided into functional modules. Here, "module" can refer to a specific ASIC, circuitry, a processor and memory executing one or more software or firmware programs, integrated logic circuitry, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the communication device can take the form of the vehicle-mounted device shown in Figure 8.

[0285] For example, the processor 810 in the vehicle-mounted device shown in Figure 8 can call computer execution instructions stored in the internal memory 820 to enable the vehicle-mounted device to execute the communication method in the above method embodiment.

[0286] Since the communication device provided in this application embodiment can execute the above communication method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0287] It should be understood that one or more of the above modules or units can be implemented by software, hardware, or a combination of both. When any of the above modules or units are implemented by software, the software exists as computer program instructions and is stored in memory. The processor can be used to execute the program instructions and implement the above method flow. The processor can be built into a SoC (System-on-a-Chip) or ASIC, or it can be a separate semiconductor chip. In addition to the core that executes software instructions for computation or processing, the processor may further include necessary hardware accelerators, such as field-programmable gate arrays (FPGAs), PLDs (Programmable Logic Devices), or logic circuits that implement dedicated logic operations.

[0288] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a microprocessor, digital signal processing (DSP) chip, microcontroller unit (MCU), artificial intelligence processor, ASIC, SoC, FPGA, PLD, application-specific digital circuit, hardware accelerator, or non-integrated discrete device, which can run the necessary software or perform the above method flow independently of software.

[0289] This application also provides a chip system, including a communication core processor and an interface circuit; the interface circuit is used to receive computer execution instructions and transmit them to the communication core processor; the communication core processor is used to run the computer execution instructions to execute the method executed by the vehicle-mounted device in any of the above method embodiments.

[0290] In some embodiments, the chip system may be a System-on-a-Chip (SOC), which includes an application core processor, a communication core processor, and a TEE. In other embodiments, the chip system may include an SOC and an HSM, wherein the SOC includes an application core processor, a communication core processor, and a TEE.

[0291] This application also provides an in-vehicle device (e.g., the in-vehicle device may be a chip or a chip system), which includes a chip system and a communication core processor for implementing the methods executed by the communication core processor in any of the above method embodiments. In one possible design, the in-vehicle device further includes a memory. The memory is used to store necessary program instructions and data, and the processor can call the program code stored in the memory to instruct the communication core processor to execute the methods in any of the above method embodiments. Of course, the memory may not be in the in-vehicle device. When the in-vehicle device is a chip system, it may be composed of chips or may include chips and other discrete devices; this application does not specifically limit this.

[0292] This application also provides a computer-readable storage medium storing computer-executable instructions that, when executed on an in-vehicle device, cause the in-vehicle device to perform the method executed by any of the communication devices described above.

[0293] For explanations of the relevant content and descriptions of the beneficial effects in any of the computer-readable storage media provided above, please refer to the corresponding embodiments described above, which will not be repeated here.

[0294] This application also provides a chip. The chip integrates a control circuit for implementing the functions of the aforementioned communication device and one or more ports. Optionally, the functions supported by the chip can be referred to above, and will not be repeated here. Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, random access memory, etc. The aforementioned processing unit or processor can be a central processing unit, a general-purpose processor, an application-specific integrated circuit (ASIC), a microprocessor (digital signal processor, DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0295] This application also provides a computer program product containing computer-executable instructions, which, when executed on an in-vehicle device, cause the in-vehicle device to perform any of the methods described in the above embodiments. The computer program product includes one or more computer-executable instructions. When the computer-executable instructions are loaded and executed on the in-vehicle device, all or part of the flow or function according to the embodiments of this application is generated. The in-vehicle device may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0296] Computer-executable instructions can be stored in or transmitted from one computer-readable storage medium to another. For example, computer-executable instructions can be transmitted from one website, computer, vehicle-mounted device, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to the vehicle-mounted device or a data storage device, such as a vehicle-mounted device or data center, that can be integrated with one or more media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0297] It should be noted that the devices for storing computer instructions or computer programs provided in the embodiments of this application, such as but not limited to the memory, computer-readable storage medium and communication chip, are all non-transitory.

[0298] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product.

[0299] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0300] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A communication method characterized by comprising: Applied to a chip system, the chip system including an application core processor and a communication core processor, the method includes: The application core processor generates the first message to be sent; The communication core processor obtains the first message from the application core processor, adds a digital signature to the first message, and sends the first message with the added digital signature to other devices. And / or, The communication core processor receives a second message from another device, verifies the digital signature of the second message, and sends the second message to the application core processor after successful verification. The application core processor processes the second message.

2. The method of claim 1, wherein, The chip system is a system-on-a-chip (SOC), and the SOC also includes a Trusted Execution Environment (TEE), which includes an encryption engine. The communication core processor adds a digital signature to the first message, including: The communication core processor calls the encryption engine in the TEE to add a digital signature to the first message; The communication core processor verifies the digital signature of the second message, including: The communication core processor calls the encryption engine in the TEE to verify the digital signature of the second message.

3. The method of claim 2, wherein, The TEE also includes a storage module, which includes a private key; The communication core processor calls the encryption engine in the TEE to add a digital signature to the first message, including: The communication core processor obtains the private key from the storage module; The communication core processor calls the encryption engine in the TEE and uses the private key to add a digital signature to the first message.

4. The method of claim 1, wherein, The chip system includes a system-on-a-chip (SOC) and a hardware security module (HSM). The SOC includes the application core processor and the communication core processor. The HSM includes an encryption engine. The communication core processor adds a digital signature to the first message, including: The communication core processor calls the encryption engine in the HSM to add a digital signature to the first message; The communication core processor verifies the digital signature of the second message, including: The communication core processor invokes the encryption engine in the HSM to verify the digital signature of the second message.

5. The method of claim 4, wherein, The HSM also includes a storage module, which includes a private key; The communication core processor invokes the encryption engine in the HSM to add a digital signature to the first message, including: The communication core processor obtains the private key from the storage module; The communication core processor calls the encryption engine in the HSM and uses the private key to add a digital signature to the first message.

6. The method according to any one of claims 1 to 5, characterized in that, The communication core processor sends a first message to other devices after adding the digital signature, including: The communication core processor encodes the first message and the digital signature to obtain the encoded message; The communication core processor sends the encoded message to other devices.

7. The method according to any one of claims 1-6, characterized in that, Before the communication core processor verifies the digital signature of the second message, the method further includes: The communication core processor decodes the received second message to obtain the second message and its digital signature.

8. The method according to any one of claims 1-7, characterized in that, After the application core processor generates the first message to be sent, the method further includes: The application core processor combines the digital certificate of the vehicle-mounted device with the first message to obtain a first message packet; The communication core processor obtains the first message from the application core processor, including: The communication core processor reads the message content of the first message from the first message packet; The communication core processor sends a first message to other devices after adding the digital signature, including: The communication core processor replaces the first message in the first message packet with the first message after adding the digital signature, and sends the replaced first message packet to the other devices.

9. The method according to any one of claims 1-8, characterized in that, The communication core processor receives a second message from another device and verifies the digital signature of the second message, including: The communication core processor receives a second message packet from the other device; The communication core processor unpacks the second message packet to obtain the second message, the digital signature of the second message, and the digital certificate of the other device; The communication core processor verifies the digital certificates of the other devices; After the digital certificate of the other device is verified, the communication core processor verifies the digital signature of the second message.

10. A chip system, characterized by It includes an application core processor, a communication core processor, and an interface circuit; the interface circuit is used to receive computer execution instructions and transmit them to the application core processor and the communication core processor; the application core processor and the communication core processor are used to execute the computer execution instructions to perform the method as described in any one of claims 1-9.

11. A vehicle-mounted device, characterized in that, include: The chip system includes an application core processor and a communication core processor; The application core processor and the communication core processor are used to invoke computer execution instructions to execute the method as described in any one of claims 1-9.

12. A vehicle characterized by comprising: The device includes an in-vehicle device, which includes a chip system, the chip system including an application core processor and a communication core processor; the application core processor and the communication core processor are used to invoke computer execution instructions to execute the method as described in any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, Includes computer execution instructions, which, when executed on an in-vehicle device, cause the in-vehicle device to perform the method as described in any one of claims 1-9.

14. A computer program product, characterised in that, This includes computer-executed instructions that, when executed on an in-vehicle device, cause the in-vehicle device to perform the method as described in any one of claims 1-9.

Images