Communication method, node, communication system and mobile carrier

Abstract

The embodiment of the invention provides a communication method, a node, a communication system and a mobile carrier. The communication method comprises the steps that a first request from a first node is received, the first request is used for requesting first information, the first information is information related to an initial node, and the first request comprises a first signature; and under the condition that the verification of the first signature is passed, a third signature is determined according to the first signature and a second signature, the second signature is obtained by signing first call chain information, the first call chain information is used for indicating related node information of the first information in the second node, and the first call chain information comprises initial node information. And sending a second request to a third node, the second request comprising the third signature, the second request being used for requesting the first information. Therefore, the security of data transmission of each node can be further improved, so that the security of global chain call request transmission is improved.

Description

A communication method, node, communication system and mobile carrier Technical Field

[0001] The embodiments of the present application relate to the field of communication security, and specifically design a communication method, node, communication system and mobile carrier. Background Art

[0002] In the field of communications security, cryptographic techniques are generally used to ensure the security and integrity of data transmission. Currently, relatively sophisticated technologies exist for situations where this cryptographic technology occurs between data senders and receivers. However, in situations where data is transmitted in a chain, such as a service call chain, if an intermediate node is hijacked, current cryptographic techniques between two nodes could allow the hijacked intermediate node to unconditionally call downstream node services.

[0003] Therefore, how to improve the security of chain data transmission has become an urgent problem to be solved.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a communication method, node, communication system and mobile carrier, which can improve the security of data transmission of each node, thereby improving the security of global chain call request transmission.

[0006] The mobile carrier in this application may include road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, the mobile carrier may be a vehicle, which is a vehicle in a broad sense, and may be a vehicle (such as a commercial vehicle, a passenger car, a motorcycle, a flying car, a train, etc.), an industrial vehicle (such as a forklift, a trailer, a tractor, etc.), an engineering vehicle (such as an excavator, a bulldozer, a crane, etc.), agricultural equipment (such as a lawn mower, a harvester, etc.), amusement equipment, a toy vehicle, etc. The embodiment of this application does not specifically limit the type of vehicle. For another example, the mobile carrier may be a vehicle such as an airplane or a ship. The following description will be given by taking the mobile carrier as an example.

[0007] In a first aspect, a communication method is provided, which is applied to a second node and includes: receiving a first request from a first node, the first request being for requesting first information related to a starting node, and the first request including a first signature. If the first signature passes verification, determining a third signature based on the first signature and a second signature, the second signature being obtained by signing first call chain information, the first call chain information being for indicating node information related to the first information in the second node, and the first call chain information including information about the starting node. Sending a second request to a third node, the second request including a third signature, and requesting the first information.

[0008] It should be understood that each node can represent a different platform. Alternatively, each node can represent an application module or service module of a different platform. When each node represents an application module or service module of a different platform, each platform can have a different service module or application module depending on the type of each request.

[0009] For example, if the first request type is a control request, each node represents a control application module or a control service module of each platform; if the first request type is a diagnosis request, each node represents a diagnosis application module or a diagnosis service module of each platform.

[0010] It should be understood that the first information may be instruction information generated by the starting node, causing the end node to execute the operation indicated by the instruction information; or, the first information may be acquisition information required by the starting node, causing the end node to feedback corresponding acquisition information.

[0011] In other words, when each node represents an application module or service module on a different platform, the application module or service module corresponding to the destination node performs the operation indicated by the instruction information. If the third node is the destination node, the second request is used to instruct the application module or service module of the third node to perform the operation indicated by the first information. Alternatively, if the application module or service module corresponding to the destination node feeds back the acquired information, if the third node is the destination node, the second request is used to retrieve the first information from the application module or service module corresponding to the third node.

[0012] When the first node is the starting node, the first information is the instruction information generated by the first node or the acquisition information required by the first node; when the first node is a non-starting node, the first information can be the instruction information or acquisition information transmitted from the starting node along the call chain to the first node, and then sent to the second node through the first request.

[0013] The first call chain information may also be understood as call chain information indicating the first information in the second node.

[0014] In other words, the first call chain information is used to indicate path information for requesting the first information in the second node.

[0015] When the first node is the starting node, the first call chain information includes first node information, for example, the identity of the first node.

[0016] In the above technical solution, the third node, as a downstream node of the intermediate node, verifies the third signature determined based on the first and second signatures after receiving the request. This way, even after the second node is hijacked, when the hijacked second node sends a request to the third node, the request does not contain the relevant signature information of the first node. Therefore, since the third node cannot verify the relevant signature information of the first node when verifying the signature, the third node will not unconditionally respond to the request of the hijacked second node. This can further improve the security of data transmission at each node, thereby improving the security of global chain call request transmission.

[0017] In combination with the first aspect, in some implementations of the first aspect, the third signature includes the first signature and the second signature.

[0018] In the above technical solution, the third signature includes signatures corresponding to multiple nodes, which can simply and efficiently improve the security of global chain call request transmission.

[0019] In conjunction with the first aspect, in certain implementations of the first aspect, determining the third signature based on the first signature and the second signature includes: multiplying the first signature and the second signature to obtain the third signature. Alternatively, the first signature and the second signature are integrated based on an elliptic curve to obtain the third signature. The first call chain information and the second call chain information are different, the second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information and the second call chain information.

[0020] In the above technical solution, the signature in the request is a single signature that is the result of integrating the signatures corresponding to multiple nodes. This not only improves the security of the global chain request transmission, but also saves the transmission bandwidth of the request.

[0021] In conjunction with the first aspect, in certain implementations of the first aspect, determining the third signature based on the first signature and the second signature includes: multiplying the first signature and the second signature to obtain the third signature. Alternatively, the first signature and the second signature are integrated based on an elliptic curve to obtain the third signature. The first call chain information and the second call chain information are the same, the second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information or the second call chain information.

[0022] In the above technical solution, the signature object generated by each node is the same, and the signature in the request transmitted between nodes is a single signature that is the integration of the signatures corresponding to multiple nodes. This improves the security of the global chain call request transmission, saves the transmission bandwidth of the request, and also saves computing power.

[0023] In combination with the first aspect, in some implementations of the first aspect, the second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information, and the second signature is obtained by signing the first call chain information and the first freshness value.

[0024] In this way, when the second request includes the first fresh value, the counterfeiting, tampering and replay of the service call information can be effectively prevented, further improving the security of the call request.

[0025] In conjunction with the first aspect, in certain implementations of the first aspect, the first request further includes first control flow information, where the first control flow information includes an execution path of a control program of the first node. If the first signature passes verification, determining the third signature based on the first signature and the second signature includes: if both the first signature and the first control flow information pass verification, determining the third signature based on the first signature and the second signature.

[0026] In this way, the control flow information of the upstream node is added to the first request, which can effectively prevent and detect program code reuse attacks, such as return-oriented programming (ROP) or jump-oriented programming (JOP).

[0027] In combination with the first aspect, in certain implementations of the first aspect, second control flow information of the second node is collected through hardware, the second control flow information includes a running path of a control program of the second node, and the second request also includes the second control flow information.

[0028] In this way, the second control flow information is directly collected through the specific hardware corresponding to the node, and no software module is needed to collect the second control flow information, which can reduce latency.

[0029] In a second aspect, a communication method is provided, which is applied to a third node and includes: receiving a second request from a second node, the second request including a third signature, the second request being used to request first information, the first information being information related to a starting node; and verifying the third signature, wherein the third signature is determined by the second node based on the first signature and the second signature, the first signature being from the first request of the first node, the second signature being obtained by the second node by signing first call chain information, the first call chain information being used to indicate node information related to the first information in the second node, the first call chain information including information about the starting node.

[0030] For the technical effects related to the second aspect, please refer to the relevant description of the first aspect.

[0031] In conjunction with the second aspect, in certain implementations of the second aspect, the third signature includes the first signature and the second signature. Verifying the third signature includes verifying each signature in the third signature one by one.

[0032] In conjunction with the second aspect, in certain implementations of the second aspect, the third signature is obtained by the second node by multiplying the first signature and the second signature, or by integrating the first signature and the second signature based on an elliptic curve. The method also includes: obtaining a first public key, the first public key including the public key of the second node and the node before the second node. Verifying the third signature includes: verifying the third signature based on the first public key, the first call chain information, and the second call chain information. The second call chain information is used to indicate the node information related to the first information in the first node, and the second request also includes the first call chain information and / or the second call chain information.

[0033] In conjunction with the second aspect, in certain implementations of the second aspect, when the first call chain information and the second call chain information are different, the second request includes the first call chain information and the second call chain information. Verifying the third signature based on the first public key, the first call chain information, and the second call chain information includes: obtaining a first signature credential based on the first public key, the first call chain information, and the second call chain information. Obtaining first information to be verified based on the third signature. Verifying whether the third signature passes based on the first signature credential and the first information to be verified.

[0034] In combination with the second aspect, in certain implementations of the second aspect, when the first call chain information and the second call chain information are the same, the second request includes the first call chain information or the second call chain information. Verifying the third signature based on the first public key, the first call chain information, and the second call chain information includes: obtaining the sum of the public keys based on the first public key. Obtaining the second signature certificate based on the first call chain information or the second call chain information, and the sum of the public keys. Obtaining the second information to be verified based on the third signature. Verifying whether the third signature passes based on the second signature certificate and the second information to be verified.

[0035] In combination with the second aspect, in some implementations of the second aspect, the second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information, and the second signature is obtained by signing the first call chain information and the first freshness value.

[0036] In combination with the second aspect, in certain implementations of the second aspect, the second request also includes second control flow information, and the second control flow information is used to indicate the running path of the control program of the second node. When the third signature verification passes, the method also includes: verifying whether the second control flow information is correct.

[0037] In conjunction with the second aspect, in certain implementations of the second aspect, if the third signature passes verification and the second control flow information passes verification, the method further includes: determining a fifth signature based on the third signature and the fourth signature, where the fourth signature is obtained by the third node signing third call chain information, where the third call chain information is used to indicate node information related to the first information in the third node. Sending a third request to the fourth node, where the third request includes the third and fifth signatures and is used to request the first information.

[0038] In combination with the second aspect, in some implementations of the second aspect, when the third signature verification passes and the second control flow information verification passes, the method further includes: responding to the first information according to the second request.

[0039] According to a third aspect, a node is provided, characterized in that the node includes a communication unit and a processing unit: the communication unit is configured to receive a first request from a first node, the first request being configured to request first information, the first information being information related to a starting node, and the first request including a first signature. If the first signature is verified, the processing unit is configured to determine a third signature based on the first signature and a second signature, the second signature being obtained by signing first call chain information, the first call chain information being configured to indicate node information related to the first information in the second node, the first call chain information including starting node information. The communication unit is further configured to send a second request to a third node, the second request including a third signature, and the second request being configured to request the first information.

[0040] For the technical effects related to the third aspect, please refer to the relevant description of the first aspect.

[0041] In combination with the third aspect, in some implementations of the third aspect, the third signature includes the first signature and the second signature.

[0042] In conjunction with the third aspect, in certain implementations of the third aspect, the processing unit is specifically configured to: multiply the first signature and the second signature to obtain a third signature. Alternatively, based on an elliptic curve, the first signature and the second signature are integrated to obtain the third signature. The first call chain information and the second call chain information are different, the second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information and the second call chain information.

[0043] In conjunction with the third aspect, in certain implementations of the third aspect, the processing unit is specifically configured to: multiply the first signature and the second signature to obtain a third signature. Alternatively, based on an elliptic curve, the first signature and the second signature are integrated to obtain the third signature. The first call chain information and the second call chain information are the same, the second call chain information is used to indicate node information related to the first information in the first node, and the second request further includes the first call chain information or the second call chain information.

[0044] In combination with the third aspect, in certain implementations of the third aspect, the second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information, and the second signature is obtained by signing the first call chain information and the first freshness value.

[0045] In conjunction with the third aspect, in certain implementations of the third aspect, the first request further includes first control flow information, where the first control flow information includes an execution path of a control program of the first node. If the first signature passes verification, the processing unit is specifically configured to: if both the first signature and the first control flow information are verified, determine, by the second node, a third signature based on the first signature and the second signature.

[0046] In combination with the third aspect, in certain implementations of the third aspect, the processing unit is further used to: collect second control flow information of the second node through hardware, the second control flow information includes the running path of the control program of the second node, and the second request also includes the second control flow information.

[0047] A fourth aspect provides a node, comprising a communication unit and a processing unit: the communication unit is configured to receive a second request from a second node, the second request including a third signature, the second request being configured to request first information, the first information being information related to a starting node. The processing unit is configured to verify the third signature, wherein the third signature is determined by the second node based on the first signature and the second signature, the first signature being from the first request of the first node, the second signature being obtained by the second node by signing first call chain information, the first call chain information being configured to indicate node information related to the first information in the second node, and the first call chain information including starting node information.

[0048] For the technical effects related to the fourth aspect, please refer to the relevant description of the first aspect.

[0049] In conjunction with the fourth aspect, in certain implementations of the fourth aspect, the third signature includes the first signature and the second signature. The processing unit is specifically configured to verify each signature in the third signature one by one.

[0050] In conjunction with the fourth aspect, in certain implementations of the fourth aspect, the third signature is obtained by the second node based on the cumulative multiplication of the first signature and the second signature, or is obtained by integrating the first signature and the second signature based on an elliptic curve. The node also includes an acquisition unit: the acquisition unit is used to obtain a first public key, and the first public key includes the public key of the first and second nodes and the node before the second node. The processing unit is specifically used to verify the third signature based on the first public key, the first call chain information and the second call chain information. The second call chain information is used to indicate the node information related to the first information in the first node, and the second request also includes the first call chain information and / or the second call chain information.

[0051] In conjunction with the fourth aspect, in certain implementations of the fourth aspect, when the first call chain information and the second call chain information are different, the second request includes the first call chain information and the second call chain information. The processing unit is specifically configured to: obtain a first signature credential based on the first public key, the first call chain information, and the second call chain information; obtain first information to be verified based on the third signature; and verify whether the third signature passes based on the first signature credential and the first information to be verified.

[0052] In conjunction with the fourth aspect, in certain implementations of the fourth aspect, when the first call chain information and the second call chain information are the same, the second request includes the first call chain information or the second call chain information. The processing unit is specifically configured to: obtain the sum of the public keys based on the first public key. Obtain a second signature certificate based on the first call chain information or the second call chain information, and the sum of the public keys. Obtain second information to be verified based on the third signature. Verify whether the third signature passes based on the second signature certificate and the second information to be verified.

[0053] In combination with the fourth aspect, in certain implementations of the fourth aspect, the second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information, and the second signature is obtained by signing the first call chain information and the first freshness value.

[0054] In conjunction with the fourth aspect, in certain implementations of the fourth aspect, the second request further includes second control flow information, where the second control flow information is used to indicate an execution path of the control program of the second node. If the third signature verification passes, the processing unit is further configured to verify whether the second control flow information is correct.

[0055] In conjunction with the fourth aspect, in certain implementations of the fourth aspect, if the third signature passes verification and the second control flow information passes verification, the processing unit is further configured to determine a fifth signature based on the third signature and the fourth signature, where the fourth signature is obtained by the third node by signing third call chain information, where the third call chain information is used to indicate node information related to the first information in the third node. The communication unit is further configured to send a third request to the fourth node, where the third request includes the third and fifth signatures and is used to request the first information.

[0056] In combination with the fourth aspect, in certain implementations of the fourth aspect, when the third signature verification passes and the second control flow information verification passes, the processing unit is further used to: the third node responds to the first information according to the second request.

[0057] In a fifth aspect, a node is provided, which includes a processor and a memory, wherein the storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to enable the node to execute any possible method in the first aspect, or to enable the node to execute any possible method in the second aspect.

[0058] In a sixth aspect, a communication system is provided, which includes any possible node in the third aspect and the fourth aspect.

[0059] In a seventh aspect, a mobile carrier is provided, which includes any possible node in the third aspect, the fourth aspect, or the fifth aspect, or includes the system described in the sixth aspect.

[0060] In some possible implementations, the mobile carrier is a vehicle.

[0061] In an eighth aspect, a computer program product is provided, which includes: computer program code, which, when the computer program code runs on a computer, enables the computer to execute any possible method in the first aspect above, or enables the device to execute any possible method in the second aspect.

[0062] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately packaged with the processor, and the embodiments of the present application do not specifically limit this.

[0063] In the ninth aspect, a computer-readable medium is provided, wherein the computer-readable medium stores a program code, and when the computer program code is run on a computer, the computer is caused to execute any possible method in the first aspect, or the device is caused to execute any possible method in the second aspect.

[0064] In the tenth aspect, an embodiment of the present application provides a chip system, which includes a processor for calling a computer program or computer instructions stored in a memory so that the processor executes any possible method in the above-mentioned first aspect, or so that the device executes any possible method in the second aspect.

[0065] In combination with the tenth aspect, in a possible implementation, the processor is coupled to the memory through an interface.

[0066] In combination with the tenth aspect, in a possible implementation, the chip system also includes a memory, in which a computer program or computer instructions are stored. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] FIG1 is a schematic diagram of a chain scenario of in-vehicle service invocation provided by an embodiment of the present application;

[0068] FIG2 is a flow chart of a communication method provided in an embodiment of the present application;

[0069] FIG3 is an interactive diagram of another communication method provided in an embodiment of the present application;

[0070] FIG4 is a schematic diagram of another communication method provided in an embodiment of the present application;

[0071] FIG5 is a schematic diagram of another communication method provided in an embodiment of the present application;

[0072] FIG6 is a schematic diagram of another communication method provided in an embodiment of the present application;

[0073] FIG7 is a schematic diagram of an in-vehicle call chain provided by an embodiment of the present application;

[0074] FIG8 is a schematic diagram of an in-vehicle remote diagnosis call chain communication method provided by an embodiment of the present application;

[0075] FIG9 is a schematic diagram of a node provided in an embodiment of the present application;

[0076] FIG10 is a schematic diagram of the hardware structure of a node provided in the implementation of this application. DETAILED DESCRIPTION

[0077] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0078] To facilitate understanding of the embodiments of the present application, the following points are explained:

[0079] First, in this application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments based on their internal logical relationships.

[0080] Second, in this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c can mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b and c. Wherein a, b and c can be single or multiple, respectively.

[0081] Third, in this application, the terms "first" and "second" are used to distinguish between different nodes for ease of description and are not intended to limit the scope of the embodiments of this application. For example, they are used to distinguish between different nodes, rather than to describe a specific order or precedence. It should be understood that the terms described in this manner are interchangeable where appropriate to describe solutions beyond the embodiments of this application.

[0082] Fourth, in this application, descriptions such as "when...", "in the case of...", and "if" all mean that the device will take corresponding actions under certain objective circumstances. They do not limit the time, nor do they require the device to perform judgment actions when implementing them, nor do they mean that there are other limitations.

[0083] Fifth, in this application, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or are inherent to these processes, methods, products or apparatuses.

[0084] Sixth, in this application, "used to indicate" can include being used for direct indication and being used for indirect indication. When describing that a certain indication information is used to indicate A, it can include that the indication information directly indicates A or indirectly indicates A, and it does not mean that the indication information must carry A.

[0085] Seventh, in this application, "storage" may refer to storage in one or more memories. The one or more memories may be provided separately or integrated into an encoder or decoder, a processor, or a communication device. The one or more memories may also be provided in part separately and in part integrated into a decoder, a processor, or a communication device. The memory may be any type of storage medium and is not limited in this application.

[0086] Currently, cryptographic technology in communication security primarily focuses on ensuring the security and integrity of data transmission between two nodes. In chained transmission scenarios, such as those involving in-vehicle service calls, if an intermediate node is hijacked, the current cryptographic technology used between the two nodes will allow downstream nodes to be unconditionally called without being able to detect that the intermediate node has been compromised.

[0087] As cars become increasingly intelligent and connected, users are increasingly demanding personalized features and services. Service-oriented architecture (SOA) is being adopted by a growing number of automakers due to its advantages, such as software modularity. This decoupling of software modules from hardware and the operating environment avoids duplication of development and facilitates the rapid introduction of new services and expansions.

[0088] To meet the service call requirements of the SOA architecture, the Automotive Open System Architecture (AUTOSAR) Alliance proposed the scalable service-oriented middleware over IP protocol (SOME / IP). This SOME / IP protocol can effectively meet the interactive communication needs of in-vehicle services. However, the SOME / IP protocol itself lacks any security mechanisms and cannot guarantee the integrity, authenticity, and security of information transmission.

[0089] Therefore, currently, the security requirements for in-vehicle communications are generally met by using lower-level, general-purpose security protocols. However, these general-purpose security protocols only consider the authentication and protection between the two points of a service call. For example, Internet Protocol Security (IPSec), Transport Layer Security (TLS), and Datagram Transport Layer Security (DTLS) are general-purpose security protocols.

[0090] For example, IPSec is a secure communication mechanism for calling services between two electronic control units (ECUs). Specifically, each ECU will have a preset key, and each ECU will derive its own key based on the preset key. When the target ECU needs to request information or call a service from the source ECU, the source ECU needs to send a message to the target ECU. The source ECU uses an encryption suite to implement integrity authentication and encryption, where the encryption suite can use the symmetric key algorithm AES-CGM-128. The target ECU uses the encryption suite to perform integrity authentication and decryption on the message. IPSec has the following problems: IPSec can only build a secure communication channel between ECUs, and cannot guarantee secure communication between different services and applications in the same ECU.

[0091] For example, certificates can achieve secure communication between different services in the car. The security level between services is transmitted through certificates. When the minimum security level of the service caller (target service party) is less than or equal to the security level of the service provider (service source party), the service provider will provide the corresponding service to the service caller. After the security level conditions are met, the integrity and authenticity of the data transmission between the two are guaranteed based on digital signatures. In addition, the service provider will generate a session key, and after encrypting it with the public key of the service caller, it will be passed to the service caller, thereby achieving secure communication between the service provider and the service caller. These two security protocols are used in in-vehicle communications. Certificates require a large storage space, and the transmission of certificates also requires a large bandwidth and will bring some large delays. The authentication of certificates also has certain requirements for computing resources. These problems are not very suitable for in-vehicle communication scenarios.

[0092] The aforementioned security mechanisms only ensure authentication and protection of both parties during data transmission. They cannot guarantee the security, integrity, and authenticity of information transmission in a chained service call scenario. The following uses an in-car service call chaining scenario as an example to illustrate this.

[0093] FIG1 is a schematic diagram of a chain scenario of in-vehicle service calls provided in an embodiment of the present application.

[0094] As shown in Figure 1, the chained scenario for in-vehicle service invocation includes a service caller 110, which is typically a device related to in-vehicle and out-of-vehicle communication, such as a telematics box (T-BOX), devices related to the infotainment domain, or devices related to the intelligent driving domain. The T-BOX's 4G / 5G interface enables remote control or remote diagnosis of the intelligent connected vehicle. Bluetooth communication, for example, enables control of the infotainment domain of the intelligent connected vehicle.

[0095] The chain scenario of in-vehicle service calls may include multiple service providers. As shown in Figure 1, the chain scenario of in-vehicle service calls may include a first service provider 120, a second service provider 130 and a third service provider 140. For example, the first service provider 120 may be an in-vehicle computing platform. The second service provider 130 may be a gateway. The embodiment of the present application does not limit the type of gateway, for example, it may be a distributed gateway. The third service provider 140 may be an in-vehicle control domain. The third service provider 140 can be connected to specific control devices in the vehicle, such as the electronic stability program (ESP), electronic power steering system (EPS), power system, braking system and collision system. In addition, the chain scenario of in-vehicle service calls can also be applied to automotive thermal management or cabin control, which is not shown in Figure 1.

[0096] Typically, when service caller 110 receives a control signal or diagnostic signal from outside the vehicle, it converts the signal into a corresponding service call request and sends it to the service provider to obtain the corresponding service. For example, if service caller 110 needs to access relevant information from any service provider, it can send a service call request through the transmission chain shown in Figure 1, so that the corresponding service provider can provide the corresponding service information. For another example, if service caller 110 controls any service provider to perform a corresponding operation, it can send a service call request through the transmission chain shown in Figure 1, so that the corresponding service provider can respond to the service call request and perform the corresponding operation.

[0097] The above-mentioned mechanisms for secure in-vehicle communication all involve authentication and protection between the two parties. When the intermediate node is hijacked, that is, when the first service provider 120 is hijacked, the security, integrity, and authenticity of the service call requests transmitted between the first service provider 120 and the second service provider 130 cannot be guaranteed.

[0098] In order to solve the above problems, the embodiments of the present application provide a communication method, a node, a communication system and a mobile carrier. The communication method will be described in detail below with reference to Figures 2 to 8.

[0099] First, a brief description of the professional terms involved in the embodiments of this application is given.

[0100] 1. Digital Signature

[0101] A digital signature is an application of asymmetric key cryptography and digital digest technology. A digital signature is a string of numbers generated by the sender that cannot be forged. This string of numbers guarantees the integrity of the information sent and the authenticity of the sender's identity. Digital signatures offer non-repudiation.

[0102] 2. Control flow graph (CFG)

[0103] A control flow graph is an abstract representation of a process or program. It is an abstract data structure used by compilers and maintained internally by the compiler. It represents all the paths traversed during program execution. A control flow graph graphically illustrates the possible execution flows of all basic blocks within a process and can also reflect the real-time execution of a process.

[0104] FIG2 is a flow chart of a communication method provided by an embodiment of the present application. Each node executing the method shown in FIG2 may represent a different platform. Alternatively, each node may represent an application module or service module of a different platform. When each node represents an application module or service module of a different platform, each platform may have multiple service modules or application modules depending on the type of each request, and each request is used to request information from a corresponding service module or application module.

[0105] Taking the method shown in Figure 2 as an example, applied to an in-vehicle communication system, the first node can be the T-BOX in Figure 1, the second node can be the in-vehicle computing platform shown in Figure 1, and the third node can be the gateway shown in Figure 1. Alternatively, the first node can be an application module or service module of the T-BOX, the second node can be an application module or service module of the in-vehicle computing platform, and the third node can be an application module or service module of the gateway. The specific execution entity of each node can be the electronic device corresponding to each platform.

[0106] S210, the first node sends a first request to the second node, and the second node receives the first request from the first node. The first request is used to request first information, the first information is information related to the starting node, and the first request includes a first signature.

[0107] It should be understood that the first information may be instruction information generated by the starting node, causing the end node to execute the operation indicated by the instruction information; or, the first information may be acquisition information required by the starting node, causing the end node to feedback corresponding acquisition information.

[0108] For example, in an in-vehicle communication system, the command information generated by the starting node may be door control command information, etc., and the information required by the starting node to be obtained may be vehicle speed information, etc.

[0109] When the first node is the starting node, the first information is the instruction information generated by the first node or the acquisition information required by the first node; when the first node is a non-starting node, the first information can be the instruction information or acquisition information transmitted from the starting node along the call chain to the first node, and then sent to the second node through the first request.

[0110] Among them, when the first node is the starting node, the first signature can be understood as the node signature of the first node, that is, the node signature generated by the first node using the private key of the first node. When the first node is a non-starting node, the first signature can be used to indicate the node signatures corresponding to the first node and the nodes before the first node. In other words, the first signature can include multiple node signatures of the first node and the nodes before the first node. The first signature can also be a single signature, which is used to indicate the node signatures corresponding to the first node and the nodes before the first node.

[0111] S220. When the first signature verification passes, determine the third signature based on the first signature and the second signature. The second signature is obtained by signing the first call chain information. The first call chain information is used to indicate the node information related to the first information in the second node. The first call chain information includes the starting node information.

[0112] It should be understood that the second signature may be a node signature of the second node, that is, the second signature may be obtained by the second node signing the signature object (eg, the first call chain information).

[0113] As a possible implementation, the second signature may also be obtained by signing the first call information and the first freshness value, wherein the first information freshness value is used to indicate the real-time nature of the first call chain information.

[0114] The first call chain information can also be understood as call chain information for indicating the first information in the second node. That is, the first call chain information is used to indicate path information for requesting the first information in the second node.

[0115] Exemplarily, the first call chain information can be used to indicate the starting node related to the first information in the second node. When the first node is the starting node, the first call chain information can include the starting node information, for example, the starting node information is the identity identifier of the first node.

[0116] Exemplarily, the first call chain information can be used to indicate the call chain from the starting node related to the first information in the second node to the current node. When the first node is the starting node, the first call chain information may include the first node information and the second node information, for example, the identity of the first node and the identity of the second node.

[0117] Exemplarily, the first call chain information may be used to indicate a call chain from a starting node related to the first information in the second node to the current node and downstream nodes of the current node. When the first node is the starting node, the first call chain information may include first node information, second node information, and third node information, for example, the identity of the first node, the identity of the second node, and the identity of the third node.

[0118] As a possible implementation, the third signature includes the first signature and the second signature. Specific explanation will be provided in conjunction with FIG4 .

[0119] As one possible implementation, the first signature and the second signature are multiplied to obtain a third signature. Alternatively, the first and second signatures are combined based on an elliptic curve to obtain the third signature. The first call chain information and the second call chain information are different. The second call chain information indicates the node information related to the first information in the first node. The second request also includes the first and second call chain information. A detailed explanation will be provided in conjunction with Figure 5.

[0120] As one possible implementation, the first signature and the second signature are multiplied to obtain a third signature. Alternatively, the first signature and the second signature are combined based on an elliptic curve to obtain the third signature. The first call chain information and the second call chain information are identical, and the second call chain information indicates the node information related to the first information in the first node. The second request also includes the first call chain information or the second call chain information. A detailed explanation will be provided in conjunction with Figure 6.

[0121] As a possible implementation method, the first request also includes first control flow information, and the first control flow information includes the running path of the control program of the first node. When the first signature is verified and the first control flow information is verified, the third signature is determined based on the first signature and the second signature.

[0122] S230: The second node sends a second request to the third node, where the second request includes a third signature and is used to request the first information.

[0123] As a possible implementation manner, the second request may further include the first freshness value.

[0124] As a possible implementation manner, the second request may further include second control flow information. The second control flow information is collected by the second node through hardware, and the second control flow information includes a running path of a control program of the second node.

[0125] S240: The third node verifies the third signature.

[0126] As a possible implementation, the third signature includes the first signature and the second signature, and each signature in the third signature is verified one by one. The specific explanation will be detailed in conjunction with Figure 4.

[0127] As a possible implementation, a first public key is obtained, where the first public key includes the public keys of the first node and the second node. The third signature is verified based on the first public key, the first call chain information, and the second call chain information. The second call chain information indicates node information related to the first information in the first node, and the second request also includes the first call chain information and / or the second call chain information.

[0128] If the first call chain information and the second call chain information are different, the second request includes the first call chain information and the second call chain information. A first signature credential is obtained based on the first public key, the first call chain information, and the second call chain information. The first information to be verified is obtained based on the third signature. The third signature is verified based on the first signature credential and the first information to be verified. A detailed explanation will be provided in conjunction with FIG5.

[0129] If the first call chain information and the second call chain information are the same, the second request includes the first call chain information or the second call chain information. Based on the first public key, a sum of the public keys is obtained. Based on the first call chain information or the second call chain information and the sum of the public keys, a second signature credential is obtained. Based on the third signature, the second information to be verified is obtained. Based on the second signature credential and the second information to be verified, the third signature is verified to determine whether it passes. A detailed explanation will be provided in conjunction with FIG6 .

[0130] In the above technical solution, the third node, as a downstream node of the intermediate node, verifies the third signature obtained based on the first and second signatures after receiving the request. This way, even if the second node is hijacked, when the hijacked second node sends a request to the third node, the request does not contain the relevant signature information of the first node. Therefore, since the third node cannot verify the relevant signature information of the first node when verifying the signature, the third node will not unconditionally respond to the request of the hijacked second node. This can further improve the security of data transmission at each node, thereby improving the security of global chain request transmission.

[0131] Figure 3 is an interactive diagram of another communication method provided by an embodiment of the present application. The communication method shown in Figure 3 occurs between a first node, a second node, and a third node. The embodiment of the present application does not limit the number of nodes in the chain call in the communication. The three nodes in the figure are only exemplary. Any node with a chain call can use the method shown in Figure 3. The specific execution subject of each node can be the electronic device corresponding to each platform, or it can be a chip, chip system or processor that supports the electronic device to implement the corresponding method, or it can be a logic module or software that can implement all or part of the functions of the electronic device.

[0132] It should be understood that in Figure 3, the second node is an intermediate node, the first node is an upstream node of the intermediate node, and the third node is a downstream node of the intermediate node. In the detailed description of Figure 3, the first node is described in detail using the initial node as an example. When the first node is not an initial node, the first node can also be considered an intermediate node. For example, in in-vehicle communication, the first node can be the T-BOX in Figure 1, the second node can be a device related to the in-vehicle computing platform in Figure 1, and the third node can be the gateway in Figure 1.

[0133] S310: A first node determines a first request, where the first request is used to request first information and includes a first signature.

[0134] For example, in an in-vehicle communication scenario, the first information may be a remote control service, a remote diagnosis service, etc. The embodiment of the present application does not limit the type of the specific requested service.

[0135] As a possible implementation, when the first node is the initial node of the call chain, the first signature can be obtained by the first node signing the second call chain information. The first request can also include the second call chain information.

[0136] It should be understood that the second call chain information is used to indicate node information related to the first information in the first node. In other words, the second call chain information is used to indicate call chain information of the first information in the first node.

[0137] Exemplarily, the second call chain information may be used to indicate a starting node related to the first information in the first node. When the first node is the starting node, the second call chain information may include the first node information, for example, the identity of the first node.

[0138] Exemplarily, the second call chain information can be used to indicate a call chain from the starting node related to the first information in the first node to the downstream node of the current node. When the first node is the starting node, the second call chain information includes the first node information and the second node information, for example, the identity of the first node and the identity of the second node.

[0139] In the case where the first node is the initial node of the call chain, the first signature can also be understood as the node signature of the first node.

[0140] Specifically, the first node uses the private key of the first node to sign the second call chain information to obtain a first signature.

[0141] It should be understood that the private key of the first node may be a private key generated by the first node, or a device-level private key of a platform corresponding to the first node.

[0142] Optionally, the first signature in the above manner may also be obtained by the second node signing the second call chain information and the second freshness value using the second node's private key. The first request includes the second call chain information, the second freshness value, and the first signature.

[0143] The second freshness value is used to indicate the real-time nature of the second call chain information. For example, the second freshness value may be generated by the first node through a timestamp verification mode, or may be generated through a frame counter verification mode.

[0144] In this way, when the first request includes the second fresh value, the counterfeiting, tampering and replay of the service call information can be effectively prevented, thereby further improving the security of the request.

[0145] Optionally, the first signature in the above method can also be obtained by the first node signing the second call chain information, the second freshness value, and the first control flow information using the first node's private key. The first request includes the second call chain information, the second freshness value, the first control flow information, and the first signature.

[0146] The first control flow information includes the running path of the control program of the first node, that is, the first control flow information is used to indicate the running path of the program corresponding to the control flow graph of the first node. For example, the first node requests the running path information of the program of the first information.

[0147] S320: The first node sends a first request to the second node, and the second node receives the first request from the first node.

[0148] S330: The second node verifies the first signature of the first call request.

[0149] As a possible implementation, when the first node is the initial node, the second node verifies the first signature based on the public key of the first node and the first request. The public key of the first node may be obtained in advance by the first node.

[0150] Specifically, the second node obtains the third information to be verified based on the public key and the first signature of the first node; the second node obtains the third signature certificate based on the second call chain information in the first request, or the second call chain information and the second fresh value, or the second call chain information, the second fresh value and the first control flow information; and verifies whether the first signature passes based on the third information to be verified and the third signature certificate.

[0151] Exemplarily, the third signature credential may be a hash value obtained by performing a hash operation on the above information.

[0152] S340: Determine whether the first signature passes verification.

[0153] As a possible implementation manner, if the third information to be verified is identical to the third signature credential, the first signature verification passes.

[0154] As a possible implementation manner, if the third information to be verified is different from the third signature credential, the first signature verification fails.

[0155] If the first signature verification succeeds and the first request includes the first control flow information, S350 is executed, and the second node verifies the first control flow information. The specific control flow information verification process will be described in detail with reference to FIG8 .

[0156] If the first signature verification succeeds and the first control flow information verification succeeds, S360 is executed, and the second node determines a second request, where the second request includes a third signature.

[0157] As a possible implementation manner, the second node determines the third signature based on the first signature and the second signature.

[0158] The second signature is obtained by signing the first call chain information, and the first call chain information is used to indicate the node information related to the first information in the second node. The first call chain information is the call chain information related to the first information in the first node.

[0159] For a detailed explanation of the first call chain information, please refer to S220 and will not be repeated here.

[0160] Optionally, the second signature may also be obtained by the second node by signing the first call chain information and the first freshness value.

[0161] The first freshness value indicates the real-time nature of the first call chain information. A specific method for generating the first freshness value can refer to the second freshness value and will not be described in detail here.

[0162] Optionally, the second signature may also be obtained by the second node signing through the first call chain information, the first fresh value and the second control flow information.

[0163] The second control flow information includes the execution path of the control program of the second node. That is, the second control flow information is used to indicate the execution path of the program corresponding to the control flow graph of the second node. For example, the second node requests the execution path information of the program for which the first information was obtained. The second control flow information may be collected by the second node through hardware.

[0164] As a possible implementation manner, the third signature includes the first signature and the second signature.

[0165] It should be understood that, in FIG3 , the first node is taken as an example as the initial node, that is, the third signature includes two signature information of the first signature and the second signature.

[0166] Specifically, the signature object signed by the second node using its private key can be different from the signature object signed by the first node using its private key, and the signature object signed by the second node using its private key can be the same as the signature object signed by the first node using its private key. That is, in this implementation, there is no restriction on whether the signature objects signed by each node using its own private key are the same or different.

[0167] It should be noted that if the first node is a non-initial node, then the first signature includes the node signatures of the first node and all upstream nodes before the first node. At this time, the third signature includes multiple node signatures of the second signature and the node signatures of all upstream nodes before the second node.

[0168] As a possible implementation, the second node integrates the first signature and the second signature to obtain a single signature as the third signature. The first signature may also be a single signature obtained by the first node by integrating the node signatures of the first node and all nodes before the first node.

[0169] That is, in this implementation, the first signature is a single signature, and the third signature is also a single signature. In Figure 3, when the first node is the initial node, the first signature is the node signature of the first node. When the first node is a non-initial node, the first signature is a single signature that combines the node signatures of the first node and all nodes before the first node.

[0170] It should be understood that the second request also includes the first call chain information and / or the second call chain information. The first call chain information and the second call chain information may be different, or the first call chain information and the second call chain information may be the same. When the first node is the initial node, the relevant explanation of the second call chain information can refer to S310. When the first node is a non-initial node, the second call chain information includes the call chain information related to the first information in the first node and the nodes before the first node.

[0171] For example, in Figure 3, the first node is the initial node, and the first call chain information and the second call chain information are different. For example, the first call chain information includes the identity identifiers of the first node, the second node and the third node, and the second call chain information includes the identity identifiers of the first node and the second node.

[0172] For another example, in FIG3 , when the second node is the initial node and the first call chain information and the second call chain information are the same, both the first call chain information and the second call chain information include the identity identifier of the first node.

[0173] It should be noted that the specific method of integrating the first signature and the second signature will be described in detail in FIG5 and FIG6.

[0174] S370: The second node sends a second request to the third node. The third node receives the second request from the second node. The second request includes a third signature.

[0175] S380: The third node verifies the third signature.

[0176] As a possible implementation, the third signature includes the first signature and the second signature, and each signature in the third signature is verified one by one. A more specific implementation will be described in conjunction with FIG4.

[0177] As a possible implementation method, the third signature is a single signature obtained by the second node integrating the first signature and the second signature, and the third signature is verified according to the first public key, the first call chain information and the second call chain information.

[0178] If the first call chain information and the second call chain information differ, the third node obtains the first signature credential based on the first public key, the first call chain information, and the second call chain information; obtains the first information to be verified based on the third signature; and verifies whether the third signature passes based on the first signature credential and the first information to be verified. The detailed verification process is described in conjunction with Figure 5.

[0179] If the first call chain information and the second call chain information are identical, the sum of the public keys is obtained based on the first public key; the second signature credential is obtained based on the sum of the public keys, the first call chain information, and the second call chain information; the second information to be verified is obtained based on the third signature; and the third signature is verified based on the second signature credential and the second information to be verified. The detailed verification process is described in conjunction with Figure 6.

[0180] The first public key includes the public keys of the second node and all nodes before the second node. In FIG3 , the second node is the initial node, and the first public key includes the public key of the first node and the public key of the second node.

[0181] Optionally, in a case where the second request includes the second control flow information, after successfully verifying the third signature, the third node verifies whether the second control flow information is correct.

[0182] As a possible implementation method, when the third signature and the second control information are verified, the third node determines the fifth signature based on the third signature and the fourth signature, where the fourth signature is obtained by signing the third call chain information, and the third call chain information is used to indicate the node information related to the first information in the third node; a third request is sent to the fourth node, where the third request includes the fifth signature, and the third request is used to request the first information.

[0183] Among them, the third call chain information can also be understood as the call chain information related to the first information in the third node. The more detailed explanation of the third call chain information is similar to the first call chain information. Please refer to the relevant description of the first call chain information in S220.

[0184] As a possible implementation manner, when the third signature and the second control information are verified, the third node may respond to the first information according to the second request.

[0185] For example, the third node may execute the operation indicated by the first information, or the third node may feed back information that the starting node corresponding to the first information needs to call.

[0186] In the above technical solution, the third signature that the third node, as a downstream node of the intermediate node, verifies after receiving the request is derived from the first and second signatures. This way, even after the second node is hijacked, when the hijacked second node sends a request to the third node, the request does not contain the relevant signature information of the first node. Therefore, since the third node cannot verify the relevant signature information of the first node when verifying the signature, the third node will not unconditionally respond to the request of the hijacked second node. This can further improve the security of data transmission at each node, thereby improving the security of global chain call request transmission.

[0187] The specific manner in which each node verifies the signature in the communication method will be described in detail below with reference to FIG. 4 to FIG. 6 .

[0188] FIG4 is a schematic diagram of another communication method provided by an embodiment of the present application. FIG4 illustrates the method in detail using the first three nodes in a chain transmission as an example. The first node shown in FIG4 corresponds to the first node shown in FIG3 , the second node corresponds to the second node shown in FIG3 , and the third node corresponds to the third node shown in FIG3 . It should be understood that the relevant explanations of the first node, the second node, and the third node shown in FIG4 can be referred to the relevant description in FIG3 and are not repeated here.

[0189] S410, the first node generates a signature A based on the private key A of the first node and the call chain information A.

[0190] As a possible implementation method, the first node signs the call chain information A according to the private key A to generate signature A.

[0191] It should be understood that call chain information A is used to indicate the node information related to the first information in the first node, that is, call chain information A is the call chain information related to the first information in the first node. For example, call chain information A indicates that the first information starts from the first node. In this case, call chain information A includes the node identity of the first node. Alternatively, call chain information A indicates that the first node requests the first information through the second node. Call chain information A includes the node identities of the first node and the second node.

[0192] The first information may be a specific service instruction. For example, in a remote diagnosis scenario of in-vehicle communication, as shown in FIG1 , when a diagnosis of a brake system ECU is required, the first information may be a service call information of a brake signal.

[0193] For example, in a remote diagnostic scenario involving in-vehicle communication, as shown in Figure 1, when diagnosing the brake system ECU, the complete call chain consists of the T-BOX as the first node, the in-vehicle computing platform as the second, the gateway as the third, the in-vehicle control domain as the fourth, and the brake system ECU as the fifth. Call chain information A can represent the T-BOX invoking the brake system ECU information via the in-vehicle computing platform. Alternatively, call chain information A can represent the invoking of the brake system ECU information starting from the T-BOX node.

[0194] Specifically, first, a hash operation is performed on the call chain information A to obtain a hash value A; then, the hash value A is signed using the private key A of the first node to obtain a signature A.

[0195] Optionally, signature A can also be obtained by signing the call chain information A and the fresh value A using private key A.

[0196] The fresh value A is used to indicate the real-time nature of the call chain information A. The fresh value A may be generated by the first node through a timestamp verification mode, or may be generated through a frame counter verification mode.

[0197] The control flow information A is the running path of the calling control program of the first node.

[0198] S420, the first node determines request A, which includes signature A and call chain information A.

[0199] Optionally, request A also includes a fresh value A.

[0200] S430: The first node sends a request A to the second node, and the second node receives the request A from the first node.

[0201] S440, the second node verifies signature A in request A.

[0202] As a possible implementation method, the signature A is verified based on the public key A of the first node and the call chain information A.

[0203] Specifically, first, the second node uses the public key A of the first node to decrypt signature A and obtain hash value A; the second node performs a hash operation on the call chain information A to obtain hash value A'. Subsequently, the second node compares hash value A and hash value A'. If hash value A is equal to hash value A', then signature A is verified successfully, and the second node can determine that request A comes from the first node. If hash value A is not equal to hash value A', then signature A fails to be verified.

[0204] As a possible implementation method, the signature A is verified based on the public key A of the first node, the call chain information A and the fresh value A.

[0205] The specific process is similar to the possible implementation method described above. In the step of obtaining the hash value A', the second node performs a hash operation on the call chain information A and the fresh value A to obtain the hash value A'.

[0206] It should be understood that the second node obtains the public key A of the first node in advance, and knows the signature object of the private key A of the first node in advance.

[0207] When signature A is successfully verified, S450, the second node generates signature B based on the private key B of the second node and the call chain information B.

[0208] As a possible implementation method, the second node signs the call chain information B according to the private key B to generate signature B.

[0209] Specifically, first, a hash operation is performed on the call chain information B to obtain a hash value B; then, the hash value B is signed using the private key B of the second node to obtain a signature B.

[0210] Optionally, the second node may also use private key B to sign the call chain information B and the fresh value B to generate signature B.

[0211] Freshness value B is used to indicate the timeliness of call chain information B. The specific method of obtaining it is similar to freshness value A. Alternatively, freshness value B can also indicate the timeliness of call chain information A. In this case, freshness value B is equal to freshness value A.

[0212] The call chain information B may represent a call chain in which the first node calls the third node through the second node. The call chain information B may include the identity identifiers of the first node, the second node, and the third node.

[0213] Alternatively, call chain information B may indicate that the first information starts from the first node, and call chain information B may include the identity of the first node. When call chain information A also includes the identity of the first node, call chain information A and call chain information B are the same.

[0214] Taking the remote diagnosis scenario of in-vehicle communication as an example, the call chain information B may include the identities of the T-BOX, the in-vehicle computing platform, and the gateway. Alternatively, the call chain information B may also include the identity of the T-BOX.

[0215] It should be noted that in the method shown in Figure 4, the object signed by each node using the private key can be the same. For example, if call chain information A and call chain information B are the same, and freshness value B is equal to freshness value A, then in this method, the objects signed by the first and second nodes using their respective private keys are the same. Alternatively, in this method, the objects signed by each node using their respective private keys can be different.

[0216] S460, the second node determines request B, which includes signature A, signature B, call chain information A and / or call chain information B.

[0217] Optionally, request B includes signature A, signature B, call chain information A and / or call chain information B, and fresh value A and / or fresh value B.

[0218] It should be understood that when call chain information A and call chain information B are the same, request B includes signature A, signature B, call chain information A, and fresh value A. Alternatively, request B includes signature A, signature B, call chain information B, and fresh value B. Since call chain information A and call chain information B are the same, fresh value A and fresh value B are also the same.

[0219] It should be understood that the signature A and the signature B in S460 can be regarded as two specific signatures included in the third signature in S360.

[0220] S470: The second node sends a request B to the third node, and the third node receives the request B from the second node.

[0221] S480, the third node verifies signature A and signature B in request B.

[0222] As a possible implementation method, the third node verifies signature A and signature B based on the public key A of the first node, the public key B of the second node, the call chain information A and the call chain information B.

[0223] Specifically, the third node verifies signature A using the public key of the first node and call chain information A; and verifies signature B using the public key of the second node and call chain information B. The specific verification method can be referred to S440 and will not be described in detail here.

[0224] Optionally, after signatures A and B are verified, in method 1, when the third node is not the end node that responds to the first information, the request related to the first information can continue to be transmitted along the chain node until it is transmitted to the end node that responds to the first information. The method for verifying signatures by nodes after the third node can refer to the method related to the third node in the method shown in Figure 4. The method for determining requests by nodes after the third node can refer to the method related to the second node in the method shown in Figure 4.

[0225] Optionally, after signature A and signature B are verified, in method 2, when the third node is the end node responding to the first information, it responds to the first information according to request B.

[0226] In the above technical solution, the third signature includes signatures corresponding to multiple nodes, which can simply and efficiently improve the security of global chain call request transmission.

[0227] The above method can be applied to situations where the information signed by each node using the private key is different or the same. When the information signed by each node is different, another verification method can be used, which will be described in detail in conjunction with Figure 5. When the information signed by each node is the same, another verification method can be used, which will be described in detail in conjunction with Figure 6.

[0228] FIG5 is a schematic diagram of another communication method provided by an embodiment of the present application. FIG5 uses the first three nodes in a chain transmission as an example to illustrate the method in detail. Similarly, the first node shown in FIG5 corresponds to the first node shown in FIG3, the second node corresponds to the second node shown in FIG3, and the third node corresponds to the third node shown in FIG3. For the relevant explanations of the first node, the second node, and the third node shown in FIG5, please refer to the relevant description in FIG3 and will not be repeated here.

[0229] S510, the first node generates a signature A based on the private key A of the first node and the call chain information A.

[0230] It should be understood that S510 is similar to S410, and related descriptions can refer to S410, which will not be repeated here.

[0231] It should also be understood that in the method shown in Figure 5, the call chain information A is used to indicate the call chain information in which the first node requests the first information through the second node in the first node, and the call chain information A includes the identity identifiers of the first node and the second node.

[0232] S520, the first node determines request A, which includes signature A and call chain information A.

[0233] Optionally, request A also includes a fresh value A.

[0234] S530: The first node sends a request A to the second node, and the second node receives the request A from the first node.

[0235] S540, the second node verifies signature A in request A.

[0236] It should be understood that the method of verifying signature A in S540 is similar to that in S440, and reference may be made to S440, which will not be described in detail here.

[0237] When signature A is successfully verified, S550, the second node generates signature B according to the private key B of the second node and the call chain information B.

[0238] It should be understood that the method of verifying signature A in S540 is similar to that in S450, and reference may be made to S450, which is not described in detail here. The method of generating signature B in S550 is similar to that in S450, and reference may be made to S450, which is not described in detail here.

[0239] It should be noted that in the method shown in Figure 5, the object signed by each node using the private key is different, that is, the object of the hash operation is different. Call chain information B is the call chain information related to the first information in the second node. For example, call chain information B is used to indicate the call chain information of the second node requesting the first information corresponding to the first node from the third node. Call chain information B includes the identity identifiers of the first node, the second node, and the third node.

[0240] That is, in the method shown in FIG. 5 , the call chain information A and the call chain information B are different.

[0241] S560: The second node generates a third signature based on signature A and signature B.

[0242] As one possible implementation, signature A and signature B are combined to obtain a third signature. Specifically, the combination can be obtained by multiplying signature A and signature B. Alternatively, signature A and signature B can be combined using EdDSA based on the elliptic curve Ed25519 to obtain the third signature. This embodiment of the present application does not limit the integration of node signatures for each node.

[0243] S570, the second node determines request B, which includes the third signature, call chain information A and call chain information B.

[0244] Optionally, request B includes a third signature, call chain information A, fresh value A, call chain information B and fresh value B.

[0245] S580: The second node sends a request B to the third node, and the third node receives the request B from the second node.

[0246] S590, the third node verifies the third signature in request B.

[0247] As a possible implementation method, the third node verifies the third signature based on the public key A of the first node, the public key B of the second node, the call chain information A and the call chain information B.

[0248] Specifically, the third node generates signature certificate A based on public key A and call chain information A; generates signature certificate B based on public key B and call chain information B; and uses the sum of signature certificate A and signature certificate B as the first signature certificate. Based on the third signature, the third node obtains the first information to be verified. Based on the first signature certificate and the first information to be verified, the third signature is verified.

[0249] Exemplarily, when the first signature credential and the first information to be verified are the same, the third signature verification passes. When the first signature credential and the first information to be verified are different, the third signature verification fails.

[0250] Optionally, after the third signature verification passes, in method 1, when the third node is not the end node that responds to the first information, the request related to the first information can continue to be transmitted along the chain node until it is transmitted to the end node that responds to the first information. The method for verifying signatures by nodes after the third node can refer to the method related to the third node in the method shown in Figure 5. The method for determining requests by nodes after the third node can refer to the method related to the second node in the method shown in Figure 5.

[0251] Optionally, after the third signature verification is passed, in method 2, when the third node is the end node responding to the first information, it responds to the first information according to request B.

[0252] In the above technical solution, the signature in the request is a single signature that is the result of integrating the signatures corresponding to multiple nodes. This not only improves the security of the global chain request transmission, but also saves the transmission bandwidth of the request.

[0253] FIG6 is a schematic diagram of a communication method provided by an embodiment of the present application. FIG6 illustrates the method in detail using the first three nodes in a chain transmission as an example. It should be understood that, similarly, the first node shown in FIG6 corresponds to the first node shown in FIG3 , the second node corresponds to the second node shown in FIG3 , and the third node corresponds to the third node shown in FIG3 . For the relevant explanations of the first node, the second node, and the third node shown in FIG6 , please refer to the relevant description in FIG3 and will not be repeated here.

[0254] S610, the first node generates a signature A based on the private key A of the first node and the call chain information A.

[0255] It should be understood that S610 is similar to S410, and related descriptions can refer to S410, which will not be repeated here.

[0256] It should also be understood that in the method shown in FIG6, the call chain information A can be used to indicate that the node related to the first information is the first node. That is, the call chain information A is used to indicate that the starting node of the call chain of the first information is the first node. The call chain information A includes the identity identifier of the first node.

[0257] S620, the first node determines request A, which includes signature A and call chain information A.

[0258] Optionally, request A also includes a fresh value A.

[0259] S630: The first node sends a request A to the second node, and the second node receives the request A from the first node.

[0260] S640, the second node verifies signature A in request A.

[0261] It should be understood that the method of verifying signature A in S640 is similar to that in S440, and reference may be made to S440, which will not be described in detail here.

[0262] When the signature A is successfully verified, S650, the second node generates a signature B based on the private key B of the second node and the call chain information A.

[0263] As a possible implementation method, the second node signs the call chain information A according to the private key B to generate signature B.

[0264] Specifically, the second node can perform a hash operation on the call chain information A to obtain hash value A, and then use the second node's private key B to sign hash value A to obtain signature B. Alternatively, since the second node successfully verifies signature A, the second node can use the first node's public key to decrypt signature A to obtain hash value A', hash value A is equal to hash value A', and then use the second node's private key B to sign hash value A' to obtain signature B.

[0265] It should be noted that in the method shown in Figure 6, the object signed by each node using the private key is the same, that is, the object of the hash operation is the same. The object signed by the first node's private key A and the object signed by the second node's private key B are the same, both of which can be call chain information A. Alternatively, both can be call chain information A and fresh value A.

[0266] S660: The second node generates a third signature based on signature A and signature B.

[0267] As one possible implementation, signature A and signature B are combined to obtain a third signature. Specifically, the combination can be obtained by multiplying signature A and signature B. Alternatively, signature A and signature B can be combined using EdDSA based on the elliptic curve Ed25519 to obtain the third signature. This embodiment of the present application does not limit the integration of node signatures for each node.

[0268] S670, the second node determines request B, which includes the third signature and call chain information A.

[0269] Optionally, request B includes a third signature, call chain information A and fresh value A.

[0270] S680: The second node sends a request B to the third node, and the third node receives the request B from the second node.

[0271] S690, the third node verifies the third signature in request B.

[0272] As a possible implementation method, the third node verifies the third signature based on the public key A of the first node, the public key A of the second node and the call chain information A.

[0273] Specifically, the third node uses the sum of public keys A and B as the sum of public keys. Based on the sum of public keys and call chain information A, it obtains the second signature certificate. Based on the third signature, it obtains the second information to be verified. The third signature is then verified based on the first signature certificate and the first information to be verified.

[0274] Exemplarily, when the second signature credential and the second information to be verified are the same, the third signature verification passes. When the second signature credential and the second information to be verified are different, the third signature verification fails.

[0275] Optionally, after the third signature verification passes, in method 1, when the third node is not the end node that responds to the first information, the request related to the first information can continue to be transmitted along the chain node until it is transmitted to the end node that responds to the first information. The method for verifying signatures by nodes after the third node can refer to the method related to the third node in the method shown in Figure 6. The method for determining requests by nodes after the third node can refer to the method related to the second node in the method shown in Figure 6.

[0276] Optionally, after the third signature verification is passed, in method 2, when the third node is the end node responding to the first information, it responds to the first information according to request B.

[0277] In the above technical solution, the signature object generated by each node is the same, and the signature in the request transmitted between nodes is a single signature that is the integration of the signatures corresponding to multiple nodes. This improves the security of the global chain request transmission, saves the transmission bandwidth of the request, and also saves computing power.

[0278] There are two possible implementations for each node's private and public keys.

[0279] The first type is that each node has its own public-private key pair. For example, the public-private key pairs shown in Figures 4 to 6 belong to this type.

[0280] The second type is that the device corresponding to each node has a device-level public-private key pair, and each node can generate a pre-shared key (PSK) based on the device-level public-private key pair, and then generate a service-level key based on the PSK. Among them, the service-level key of each node is the same. Subsequently, the integrity protection of the call chain is achieved by a message authentication code (MAC), that is, the first information is encrypted by the same service-level key of each node. Among them, the message authentication code can be obtained by a message authentication code algorithm such as a hash-based message authentication code (HMAC) or a block encryption-based message authentication code (CMAC), and this application does not impose any restrictions on this. Finally, in order to realize the authentication of the identity of the first node and the second node by the third node shown in Figures 4 to 6, each node on the call chain can use the device-level private key to sign the message authentication code MAC. The specific signing method can refer to Figures 4 to 6.

[0281] In this way, through the device-level public-private key pair, each node does not need to generate its own independent public-private key pair. The same service-level key can simplify the generation and verification of message authentication codes, which can reduce the demand for secure storage capabilities of the device corresponding to each node.

[0282] In the above technical solution, the third node, as the downstream node of the intermediate node, will verify the third signature determined according to the first signature and the second signature after receiving the request. At the same time, the second fresh value in the first request can effectively prevent the counterfeiting, tampering and replay of the first request. Even if the second node of the call chain (that is, the intermediate node in the call chain) is hijacked, when the hijacked second node sends the second request to the third node, the third node cannot verify the signature of the first node. Therefore, the solution of the embodiment of the present application can help to promptly discover that the intermediate node is attacked and prevent the attack on the intermediate node from spreading to the lower-level nodes.

[0283] Taking in-vehicle communication as an example, FIG7 is a schematic diagram of an in-vehicle call chain provided in an embodiment of the present application.

[0284] As shown in Figure 7, the first node of the in-vehicle call chain can be T-BOX710, the second node can be the in-vehicle computing platform 720, and the third node can be the gateway 730. The specific gateway type can be a distributed gateway. Taking these three nodes as an example, remote control and remote diagnosis of intelligent connected vehicles can be achieved. The solution of the embodiment of the present application can also be applied to other call chains. This application only uses remote control services / applications and remote diagnosis services / applications as examples to explain the communication method in detail.

[0285] The solid line call chain shown in Figure 7 is the remote control call chain, and the dotted line call chain is the remote diagnosis call chain. The following uses the remote control call chain and the remote diagnosis call chain to illustrate the process of the intermediate node verifying the integrity of the call chain.

[0286] It should be understood that the remote control application / service and the remote diagnosis application / service of each node shown in FIG. 7 are software modules of each node.

[0287] For example, the first information requested by remote control application / service 711 may be first control information. For example, the first control information may be used to instruct the control service module or control application module corresponding to the endpoint node to perform a corresponding operation, or to instruct the control service module or application control module corresponding to the endpoint node to obtain information. The specific steps for verifying the integrity of the remote control call chain are as follows.

[0288] In the first step, the remote control application / service 711 in the TBOX 710 receives the remote control signal from outside the vehicle via 4G / 5G.

[0289] In the second step, remote control application / service 711 determines a first control request based on the remote signal and sends the first control request to remote control application / service 721 in in-vehicle computing platform 720 via the AUTOSAR AP (automotive open system architecture adaptive platform) based on the in-vehicle Ethernet protocol COME / IP. For details on determining the first control request, refer to the method for determining request A in the first node of Figures 4 to 6.

[0290] In the third step, remote control application / service 721 verifies the first signature in the first control request. For details on how to verify the first signature, refer to the verification method for the second node in Figures 4 through 6. After verification, remote control application / service 721 determines the second control request and sends it to remote control application / service 731 in gateway 730 via the AUTOSAR AP based on the in-vehicle Ethernet protocol COME / IP. The second control request includes a third signature, which indicates the signatures of the T-BOX and the in-vehicle computing platform. For details on how to generate the third signature, refer to the generation method for the second node in Figures 4 through 6.

[0291] In the fourth step, remote control application / service 731 verifies the third signature in the second control request. For details on the verification method, refer to the verification method for the third node in Figures 4 to 6. If the verification passes, remote control application / service 731 determines a new request and sends it to the next node. The signature included in the new request indicates the node signatures generated by T-BOX 710, in-vehicle computing platform 720, and gateway 730, respectively. Alternatively, if the verification passes, remote control application / service 731 may respond to the first control service based on the second control request.

[0292] For another example, the first information requested by the remote diagnostic application / service 712 may be first diagnostic information. The specific steps for verifying the integrity of the remote diagnostic call chain are similar to those described above. The following, in conjunction with FIG. 7 , specifically illustrates the specific process by which the communication method of this application can effectively improve security after the second node, the in-vehicle computing platform 720, is hijacked.

[0293] After the second node, the in-vehicle computing platform 720, is hijacked, the remote control application / service 722 of the in-vehicle computing platform 720 sends a second diagnostic request to the remote control application / service 732 of the gateway 730. When the remote control application / service 732 of the gateway 730 verifies the third signature in the second diagnostic request, because the third signature cannot indicate the T-BOX signature, the third signature fails the verification, and the request for diagnostic information in the second diagnostic request is also not allowed, as shown in Figure 7.

[0294] The verification process of the local control flow information in the in-vehicle communication will be described in detail below with reference to FIG. 8 .

[0295] FIG8 is a schematic diagram of an in-vehicle remote diagnosis call chain security verification method 800 provided in an embodiment of the present application.

[0296] Figure 8 illustrates an example in which the first node is T-BOX 810, the second node is in-vehicle computing platform 820, and the third node is gateway 830. The predefined call chain is that T-BOX 810 requests remote diagnostic information from gateway 830 through in-vehicle computing platform 820.

[0297] S1 , the T-BOX 810 determines a first diagnosis request in a trusted execution environment (TEE) 812 .

[0298] The first diagnostic request includes first control flow information, a second fresh value, second call chain information and a first signature.

[0299] The first control flow information may be collected based on the hardware of the T-BOX. The first control flow information is used to indicate the running path of the program corresponding to the first control flow graph of the T-BOX.

[0300] In this way, the first control flow information is collected directly through the specific hardware of the node, and no software module is needed to collect the first control flow information, which can reduce latency.

[0301] For the explanation of the second fresh value and the second call chain information, please refer to S310 and will not be elaborated here.

[0302] For example, the first signature may be obtained by T-BOX 810 using its private key to sign the first control flow information, the first fresh value, and the first call chain information in TEE 812. The first signature may be signature A shown in Figures 4 to 6 . For more specific implementations, please refer to Figures 4 to 6 .

[0303] S2, the remote diagnosis application 811 of the T-BOX 810 sends a first diagnosis request to the remote diagnosis application 821 of the in-vehicle computing platform 820.

[0304] For example, the remote diagnosis application 811 of the T-BOX 810 may send the first diagnosis request to the remote diagnosis application 821 of the in-vehicle computing platform 820 via the in-vehicle Ethernet (eg, COME / IP).

[0305] S3, the in-vehicle computing platform 820 verifies the first signature in TEE822.

[0306] It should be understood that the first signature can be the signature A shown in Figures 4 to 6. For a more specific implementation method, reference can be made to the method of verifying signature A at the second node in Figures 4 to 6.

[0307] After the first signature verification is passed, S4, the in-vehicle computing platform 820 verifies the first control flow information in TEE822.

[0308] It should be understood that the in-vehicle computing platform 820 obtains the first control flow graph of the T-BOX 810 in advance.

[0309] Exemplarily, the in-vehicle computing platform 820 obtains first verification control flow information based on the first control flow graph obtained in advance, and then determines whether the first control flow information is successfully verified by comparing the first control flow information with the first verification control flow information.

[0310] In this way, the control flow information of the upstream node is added to the first request, which can effectively prevent and detect program code reuse attacks, such as return-oriented programming ROP or jump-oriented programming JOP.

[0311] When the first control flow information verification is successful, S5 , the in-vehicle computing platform 820 verifies the calling authority of T-BOX 810 in TEE 822 .

[0312] As a possible implementation method, the in-vehicle computing platform 820 verifies the calling authority of the T-BOX 810 through the identity and access management (IAM) module in the TEE 822.

[0313] If the T-BOX's calling permission check passes, S6, the in-vehicle computing platform 820 determines the second diagnostic request in TEE822, and the second diagnostic request includes a third signature, which is used to indicate the signature of the T-BOX and the signature of the in-vehicle computing platform.

[0314] The second diagnostic request also includes the first fresh value, the second call chain information, the second fresh value, and the first call chain information. Alternatively, the second diagnostic request also includes the second fresh value and the second call chain information. For a detailed description of the second fresh value, the second call chain information, the first fresh value, and the first call chain information, please refer to Figure 3.

[0315] The second diagnostic request includes second control flow information, which can be collected based on the hardware of the in-vehicle computing platform. The second control flow information is used to indicate the running path of the program corresponding to the second control flow graph of the in-vehicle computing platform.

[0316] S7, the remote diagnosis application 821 of the in-vehicle computing platform 820 sends the second diagnosis request to the remote diagnosis application 831 of the gateway 830.

[0317] For example, the remote diagnosis application 821 of the in-vehicle computing platform 820 may send the second diagnosis request to the remote diagnosis application 831 of the gateway 830 via the in-vehicle Ethernet (eg, COME / IP).

[0318] S8. Gateway 830 verifies the third signature in TEE 832.

[0319] It should be understood that the third signature may be the signature A and signature B shown in FIG4 , or the third signature may be the specific implementations in FIG5 and FIG6 , and reference may be made to FIG4 to FIG6 .

[0320] After the third signature verification passes, S9 , the gateway 830 verifies the second control flow information in the TEE 832 .

[0321] For a specific method of verifying the second control flow information, reference may be made to the method of verifying the first control flow information in S3.

[0322] When the second control flow information verification is successful, S10 , the gateway 830 verifies the calling permissions of the T-BOX 810 and the in-vehicle computing platform 820 in the TEE 832 .

[0323] As a possible implementation method, the gateway 830 verifies the calling permissions of the T-BOX 810 and the in-vehicle computing platform 820 in the TEE832IAM module.

[0324] Optionally, after the call authority verification is passed, when the gateway 830 is not the end node corresponding to the remote diagnostic information, the diagnostic request related to the remote diagnostic information can continue to be passed along the chain node until it is transmitted to the end node that responds to the remote diagnostic information.

[0325] Optionally, after the calling authority verification is passed, when the gateway 830 is the end node corresponding to the diagnostic information, it responds to the remote diagnostic information according to the second diagnostic request.

[0326] The above content is a communication method according to an embodiment of the present application. The nodes will be described in detail below in conjunction with Figures 14 and 15. It should be understood that the description of the apparatus embodiment corresponds to the description of the method embodiment. Therefore, for matters not described in detail, please refer to the method embodiment above. For the sake of brevity, they will not be repeated here.

[0327] FIG9 is a schematic diagram of a node provided in an embodiment of the present application. The node 900 includes: a communication unit 901 and a processing module 902.

[0328] When node 900 is an intermediate node, that is, a second node, the communication unit 901 is used to receive a first request from a first node, where the first request is used to request first information, the first information is information related to the starting node, and the first request includes a first signature.

[0329] The processing unit 902 is used to determine the third signature based on the first signature and the second signature when the first signature verification passes. The second signature is obtained by signing the first call chain information. The first call chain information is used to indicate the node information related to the first information in the second node. The first call chain information includes the starting node information.

[0330] The communication unit 901 is configured to send a second request to a third node, where the second request includes a third signature and is used to request the first information.

[0331] When node 900 is a downstream node of the intermediate node, that is, a third node, the communication unit 901 is used to receive a second request from the second node, the second request includes a third signature, and the second request is used to request first information, which is information related to the starting node.

[0332] Processing unit 902 is used to verify the third signature, where the third signature is determined by the second node based on the first signature and the second signature, the first signature comes from the first request of the first node, and the second signature is obtained by the second node by signing the first call chain information. The first call chain information is used to indicate the node information related to the first information in the second node, and the first call chain information includes the starting node information.

[0333] It should be understood that the above content is only an exemplary description. This node is used to execute the method or steps mentioned in the above method embodiment. Therefore, this node corresponds to the above method embodiment. For specific content, please refer to the description of the above method embodiment and will not be repeated here.

[0334] FIG10 is a schematic diagram of the hardware structure of a node provided by an embodiment of the present application. The node 1000 shown in FIG10 may include: a memory 1010, a processor 1020, and a communication interface 1030. The memory 1010, the processor 1020, and the communication interface 1030 are connected via an internal connection path. The memory 1010 is used to store instructions, and the processor 1020 is used to execute the instructions stored in the memory 1020 to control the input / output interface 1030 to receive / send at least some parameters of the second channel model. Optionally, the memory 1010 can be coupled to the processor 1020 via an interface or integrated with the processor 1020.

[0335] It should be noted that the communication interface 1030 uses a transceiver device such as, but not limited to, a transceiver to implement communication between the communication device 1000 and other devices or a communication network. The communication interface 1030 may also include an input / output interface.

[0336] During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 1020 or by instructions in the form of software. The method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 1010, and the processor 1020 reads the information in the memory 1010 and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

[0337] It should be understood that in the embodiments of the present application, the processor may be a central processing unit (CPU), or may be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0338] It should also be understood that in the embodiments of the present application, the memory may include read-only memory and random access memory, and provide instructions and data to the processor. A portion of the processor may also include non-volatile random access memory. For example, the processor may also store device type information.

[0339] It should be understood that the term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0340] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean 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 the present application.

[0341] An embodiment of the present application further provides a node, which includes a processing unit and a storage unit, wherein the storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit, so that the node executes the above-mentioned communication method.

[0342] The embodiment of the present application further provides a mobile carrier, including the above-mentioned node 900 or node 1000. The mobile carrier may be a vehicle.

[0343] An embodiment of the present application further provides a computer-readable medium storing a program code. When the computer program code is executed on a computer, the computer executes any one of the methods in FIG. 2 to FIG. 8 .

[0344] An embodiment of the present application further provides a computer program product, which includes: computer program code, which enables the computer to execute the above method when the computer program code is run on a computer.

[0345] An embodiment of the present application also provides a chip, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is configured to read and execute instructions in the memory to execute any one of the methods in Figures 2 to 8 above.

[0346] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel 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.

[0347] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0348] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0350] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0351] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0352] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method, characterized in that: The method is applied to the second node, and the method includes: receiving a first request from a first node, where the first request is for requesting first information, the first information being information related to an originating node, and the first request including a first signature; If the first signature passes verification, determining a third signature based on the first signature and the second signature, where the second signature is obtained by signing first call chain information, where the first call chain information is used to indicate node information related to the first information in the second node, and the first call chain information includes starting node information; A second request is sent to a third node, where the second request includes the third signature and is used to request the first information.

2. The method according to claim 1, wherein The third signature includes the first signature and the second signature.

3. The method according to claim 1, wherein Determining the third signature according to the first signature and the second signature includes: Multiplying the first signature and the second signature to obtain the third signature; or Based on an elliptic curve, integrating the first signature and the second signature to obtain the third signature; The first call chain information and the second call chain information are different, the second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information and the second call chain information.

4. The method according to claim 1, wherein Determining the third signature according to the first signature and the second signature includes: Multiplying the first signature and the second signature to obtain the third signature; or Based on an elliptic curve, integrating the first signature and the second signature to obtain the third signature; The first call chain information and the second call chain information are the same, the second call chain information is used to indicate the node information related to the first information in the first node, and the second request also includes the first call chain information or the second call chain information.

5. The method according to any one of claims 1 to 4, characterized in that The second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information. The second signature is obtained by signing the first call chain information and the first freshness value.

6. The method according to any one of claims 1 to 5, characterized in that The first request further includes first control flow information, wherein the first control flow information includes a running path of a control program of the first node. When the first signature verification passes, determining the third signature according to the first signature and the second signature includes: When the first signature and the first control flow information are verified to be passed, the third signature is determined according to the first signature and the second signature.

7. The method according to claim 6, wherein The method further comprises: Second control flow information of the second node is collected through hardware, where the second control flow information includes a running path of a control program of the second node, and the second request also includes the second control flow information.

8. A communication method, characterized in that: The method is applied to the third node and includes: receiving a second request from a second node, the second request including a third signature, the second request being used to request first information, the first information being information related to the starting node; Verify the third signature, where the third signature is determined by the second node based on the first signature and the second signature, the first signature comes from the first request of the first node, the second signature is obtained by the second node by signing the first call chain information, the first call chain information is used to indicate the node information related to the first information in the second node, and the first call chain information includes the starting node information.

9. The method according to claim 8, wherein The third signature includes the first signature and the second signature; The verifying the third signature includes: Each of the third signatures is verified one by one.

10. The method according to claim 8, wherein The third signature is obtained by the second node based on the cumulative multiplication of the first signature and the second signature, or is obtained by integrating the first signature and the second signature based on an elliptic curve; the method further includes: Obtaining a first public key, where the first public key includes public keys of the second node and a node before the second node; The verifying the third signature comprises: Verifying the third signature according to the first public key, the first call chain information, and the second call chain information; The second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information and / or the second call chain information.

11. The method according to claim 10, wherein When the first call chain information and the second call chain information are different, the second request includes the first call chain information and the second call chain information, and verifying the third signature according to the first public key, the first call chain information, and the second call chain information includes: Obtaining a first signature certificate according to the first public key, the first call chain information, and the second call chain information; Obtaining first information to be verified based on the third signature; Verify whether the third signature passes based on the first signature certificate and the first information to be verified.

12. The method according to claim 10, wherein When the first call chain information and the second call chain information are the same, the second request includes the first call chain information or the second call chain information, and verifying the third signature according to the first public key, the first call chain information, and the second call chain information includes: Obtaining a sum of public keys according to the first public key; Obtaining a second signature certificate according to the first call chain information or the second call chain information and the sum of the public key; Obtaining second information to be verified based on the third signature; Verify whether the third signature passes based on the second signature certificate and the second information to be verified.

13. The method according to any one of claims 8 to 12, characterized in that The second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information. The second signature is obtained by signing the first call chain information and the first freshness value.

14. The method according to any one of claims 8 to 13, characterized in that The second request further includes second control flow information, where the second control flow information is used to indicate a running path of a control program of the second node. If the third signature verification passes, the method further includes: Check whether the second control flow information is correct.

15. The method according to any one of claims 8 to 14, characterized in that When the third signature verification passes and the second control flow information verification passes, the method further includes: Determine a fifth signature based on the third signature and the fourth signature, where the fourth signature is obtained by the third node by signing third call chain information, where the third call chain information is used to indicate node information related to the first information in the third node; A third request is sent to a fourth node, where the third request includes the fifth signature and is used to request the first information.

16. The method according to any one of claims 8 to 14, characterized in that If the third signature verification passes and the second control flow information verification passes, The method further comprises: Respond to the first information according to the second request.

17. A node, characterized in that: The node includes a communication unit and a processing unit: The communication unit is configured to receive a first request from a first node, where the first request is for requesting first information, the first information is information related to the starting node, and the first request includes a first signature; If the first signature verification passes, the processing unit is configured to determine a third signature based on the first signature and the second signature, where the second signature is obtained by signing first call chain information, where the first call chain information is used to indicate node information related to the first information in a second node, and the first call chain information includes starting node information; The communication unit is further configured to send a second request to a third node, where the second request includes the third signature and is used to request the first information.

18. The node according to claim 17, wherein: The third signature includes the first signature and the second signature.

19. The node according to claim 17, wherein: The processing unit is specifically configured to: Multiplying the first signature and the second signature to obtain the third signature; or Based on an elliptic curve, integrating the first signature and the second signature to obtain the third signature; The first call chain information and the second call chain information are different, the second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information and the second call chain information.

20. The node according to claim 17, wherein The processing unit is specifically configured to: Multiplying the first signature and the second signature to obtain the third signature; or Based on an elliptic curve, integrating the first signature and the second signature to obtain the third signature; The first call chain information and the second call chain information are the same, the second call chain information is used to indicate the node information related to the first information in the first node, and the second request also includes the first call chain information or the second call chain information.

21. The node according to any one of claims 17 to 20, characterized in that: The second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information. The second signature is obtained by signing the first call chain information and the first freshness value.

22. The node according to any one of claims 17 to 21, wherein: The first request further includes first control flow information, wherein the first control flow information includes a running path of a control program of the first node. When the first signature verification passes, the processing unit is specifically configured to: When the first signature and the first control flow information are verified to be passed, the second node determines the third signature according to the first signature and the second signature.

23. The node according to claim 22, wherein: The processing unit is further configured to: Second control flow information of the second node is collected through hardware, where the second control flow information includes a running path of a control program of the second node, and the second request also includes the second control flow information.

24. A node, characterized in that The node includes a communication unit and a processing unit: The communication unit is configured to receive a second request from a second node, where the second request includes a third signature and is used to request first information, where the first information is information related to the starting node; The processing unit is used to verify the third signature, wherein the third signature is determined by the second node based on the first signature and the second signature, the first signature comes from the first request of the first node, and the second signature is obtained by the second node by signing the first call chain information, the first call chain information is used to indicate the node information related to the first information in the second node, and the first call chain information includes the starting node information.

25. The node according to claim 24, wherein The third signature includes the first signature and the second signature; The processing unit is specifically configured to: Each of the third signatures is verified one by one.

26. The node according to claim 24, wherein The third signature is obtained by the second node based on the cumulative multiplication of the first signature and the second signature, or is obtained by integrating the first signature and the second signature based on an elliptic curve; The node further includes an acquisition unit: The acquiring unit is configured to acquire a first public key, where the first public key includes public keys of the second node and a node preceding the second node; The processing unit is specifically configured to: Verifying the third signature according to the first public key, the first call chain information, and the second call chain information; The second call chain information is used to indicate node information related to the first information in the first node, and the second request also includes the first call chain information and / or the second call chain information.

27. The node according to claim 26, wherein In a case where the first call chain information and the second call chain information are different, the second request includes the first call chain information and the second call chain information, and the processing unit is specifically configured to: Obtaining a first signature certificate according to the first public key, the first call chain information, and the second call chain information; Obtaining first information to be verified based on the third signature; Verify whether the third signature passes based on the first signature certificate and the first information to be verified.

28. The node according to claim 26, wherein In a case where the first call chain information and the second call chain information are the same, the second request includes the first call chain information or the second call chain information, and the processing unit is specifically configured to: Obtaining a sum of public keys according to the first public key; Obtaining a second signature certificate according to the first call chain information or the second call chain information and the sum of the public key; Obtaining second information to be verified based on the third signature; Verify whether the third signature passes based on the second signature certificate and the second information to be verified.

29. The node according to any one of claims 24 to 28, wherein: The second request also includes a first freshness value, which is used to indicate the real-time nature of the first call chain information. The second signature is obtained by signing the first call chain information and the first freshness value.

30. The node according to any one of claims 24 to 29, wherein: The second request further includes second control flow information, where the second control flow information is used to indicate a running path of a control program of the second node. If the third signature verification passes, the processing unit is further configured to: Check whether the second control flow information is correct.

31. The node according to any one of claims 24 to 30, wherein: If the third signature verification passes and the second control flow information verification passes, The processing unit is further configured to determine a fifth signature based on the third signature and the fourth signature, where the fourth signature is obtained by the third node by signing third call chain information, where the third call chain information is used to indicate node information related to the first information in the third node; The communication unit is further configured to send a third request to a fourth node, where the third request includes the fifth signature and is used to request the first information.

32. The node according to any one of claims 24 to 30, wherein: If the third signature verification passes and the second control flow information verification passes, The processing unit is further configured to: The third node responds to the first information according to the second request.

33. A node, characterized in that include: memory for storing computer programs; A processor, configured to execute the computer program stored in the memory, so that the node performs the method according to any one of claims 1 to 7, or so that the node performs the method according to any one of claims 8 to 16.

34. A communication system, characterized in that The method comprises a node according to any one of claims 17 to 23 and a node according to any one of claims 24 to 32.

35. A mobile carrier, characterized in that: comprising a node as claimed in any one of claims 17 to 23, or comprising a node as claimed in any one of claims 24 to 32, or comprising a communication system as claimed in claim 34.

36. The mobile carrier according to claim 35, characterized in that The mobile carrier is a vehicle.

37. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a computer, the method according to any one of claims 1 to 7 is implemented, or the method according to any one of claims 8 to 16 is implemented.

38. A computer program product, characterized in that The computer program product comprises: a computer program code, which, when running on a computer, enables the method according to any one of claims 1 to 7 to be implemented, or enables the method according to any one of claims 8 to 16 to be implemented.

39. A chip, characterized in that: The method comprises a circuit for performing the method according to any one of claims 1 to 7 or a circuit for performing the method according to claims 8 to 16.

Images