WO2024119308A1 - 一种通信方法、节点、通信***和移动载体 - Google Patents

一种通信方法、节点、通信***和移动载体 Download PDF

Info

Publication number
WO2024119308A1
WO2024119308A1 PCT/CN2022/136574 CN2022136574W WO2024119308A1 WO 2024119308 A1 WO2024119308 A1 WO 2024119308A1 CN 2022136574 W CN2022136574 W CN 2022136574W WO 2024119308 A1 WO2024119308 A1 WO 2024119308A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
node
information
call chain
request
Prior art date
Application number
PCT/CN2022/136574
Other languages
English (en)
French (fr)
Inventor
张立
钟胤
柳凌胜
杨艳江
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2022/136574 priority Critical patent/WO2024119308A1/zh
Publication of WO2024119308A1 publication Critical patent/WO2024119308A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • the embodiments of the present application relate to the field of communication security and specifically design a communication method, a node, a communication system and a mobile carrier.
  • cryptographic technology is generally used to ensure the security and integrity of data transmission.
  • chained data transmission for example, in the service call chain scenario, if the intermediate node is hijacked, based on the current cryptographic technology between the two nodes, the hijacked intermediate node may unconditionally call the downstream node service.
  • the embodiments of the present application provide a communication method, a node, a communication system and a mobile carrier, which can improve the security of data transmission of each node, thereby improving the security of global chain call request transmission.
  • the mobile carrier in the present application may include road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc.
  • 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 the present application does not specifically limit the type of vehicle.
  • 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 a vehicle as an example.
  • a communication method is provided, the method is applied to a second node, the method comprising: receiving a first request from a first node, the first request is used to request first information, the first information is information related to a starting node, and the first request includes a first signature.
  • a third signature is determined 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, and the first call chain information includes the starting node information.
  • a second request is sent to a third node, the second request includes a third signature, and the second request is used to request the first information.
  • each node may represent a different platform. Or 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 a different service module or application module according to the type of each request.
  • each node represents a control application module or a control service module of each platform; if the type of the first request is a diagnosis request, each node represents a diagnosis application module or a diagnosis service module of each platform.
  • the first information may be instruction information generated by the starting node, so that the end node executes the operation indicated by the instruction information; or, the first information may be acquisition information required by the starting node, so that the end node feeds back corresponding acquisition information.
  • the application module or service module corresponding to the terminal node performs the operation indicated by the instruction information
  • the third node is the terminal 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.
  • the application module or service module corresponding to the terminal node feeds back the acquisition information, and if the third node is the terminal node, the second request is used to call the first information from the application module or service module corresponding to the third node.
  • the first information is instruction information generated by the first node or acquisition information required by the first node; when the first node is a non-starting node, the first information may be 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.
  • the first call chain information may also be understood as call chain information used to indicate the first information in the second node.
  • the first call chain information is used to indicate path information for requesting the first information in the second node.
  • the first call chain information includes first node information, for example, an identity identifier of the first node.
  • the third node verifies the third signature determined according to the first signature and the second signature after receiving the request.
  • 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. In this way, the security of data transmission of each node can be further improved, thereby improving the security of global chain call request transmission.
  • the third signature includes the first signature and the second signature.
  • the third signature includes signatures corresponding to multiple nodes, which can simply and efficiently improve the security of global chain call request transmission.
  • 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. Alternatively, 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.
  • the signature in the request is a single signature that is an integration of signatures corresponding to multiple nodes, which improves the security of global chain request transmission while saving the transmission bandwidth of the request.
  • 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. Alternatively, 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 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.
  • 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.
  • 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.
  • the counterfeiting, tampering and replay of the service call information can be effectively prevented, further improving the security of the call request.
  • the first request further includes first control flow information
  • the first control flow information includes a running path of a control program of the first node.
  • 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).
  • program code reuse attacks such as return-oriented programming (ROP) or jump-oriented programming (JOP).
  • 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.
  • 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 the delay.
  • a communication method is provided, the method is applied to a third node, the method comprising: receiving a second request from a second node, the second request comprising a third signature, the second request being used to request first information, the first information being information related to a starting node. 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 is from the first request of the first node, the second signature is obtained by the second node by signing first call chain information, 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 comprises starting node information.
  • 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.
  • the third signature is obtained by the second node based on the cumulative multiplication of the first signature and the second signature, or based on an elliptic curve, the first signature and the second signature are integrated.
  • the method also includes: obtaining a first public key, the first public key includes the public key of the second node and the node before the second node.
  • Verifying the third signature includes: 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 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.
  • the second request when the first call chain information and the second call chain information are different, includes the first call chain information and the second call chain information.
  • verifying the third signature includes: obtaining a first signature credential according to the first public key, the first call chain information, and the second call chain information. Obtaining the first information to be verified according to the third signature. Verifying whether the third signature passes according to the first signature credential and the first information to be verified.
  • the second request 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 includes: obtaining the sum of the public keys according to the first public key. Obtaining the second signature credential according to 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 according to the third signature. Verifying whether the third signature passes according to the second signature credential and the second information to be verified.
  • 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.
  • the second request also includes second control flow information
  • the second control flow information is used to indicate the running path of the control program of the second node.
  • the method also includes: verifying whether the second control flow information is correct.
  • the method when the third signature verification passes and the second control flow information verification passes, the method further includes: determining a fifth signature according to the third signature and the fourth signature, the fourth signature being obtained by the third node by signing the third call chain information, the third call chain information being used to indicate node information related to the first information in the third node. Sending a third request to the fourth node, the third request including the third and fifth signatures, the third request being used to request the first information.
  • the method 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.
  • a node in a third aspect, characterized in that the node includes a communication unit and a processing unit: the communication unit is used to receive a first request from a 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.
  • the processing unit is used to determine a 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, and the first call chain information includes the starting node information.
  • the communication unit is also used to send a second request to a third node, the second request includes a third signature, and the second request is used to request the first information.
  • the third signature includes the first signature and the second signature.
  • the processing unit is specifically used to: multiply the first signature and the second signature to obtain a third signature.
  • 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 the 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.
  • the processing unit is specifically configured to: multiply the first signature and the second signature to obtain a third signature.
  • 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.
  • 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.
  • the first request further includes first control flow information
  • the first control flow information includes a running path of a control program of the first node.
  • the processing unit is specifically configured to: when the first signature is verified and the first control flow information is verified, the second node determines a third signature based on the first signature and the second signature.
  • the processing unit is also 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.
  • 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.
  • the third signature is obtained by the second node based on the cumulative multiplication of the first signature and the second signature, or based on an elliptic curve, by integrating the first signature and the second signature.
  • 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 second node and the node before the second node.
  • the processing unit is specifically used to verify 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 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.
  • the second request when the first call chain information and the second call chain information are different, includes the first call chain information and the second call chain information.
  • the processing unit is specifically used 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. Verify whether the third signature passes based on the first signature credential and the first information to be verified.
  • the second request when the first call chain information and the second call chain information are the same, includes the first call chain information or the second call chain information.
  • the processing unit is specifically used to: obtain the sum of the public keys according to the first public key. Obtain a second signature certificate according to the first call chain information or the second call chain information, and the sum of the public keys. Obtain the second information to be verified according to the third signature. Verify whether the third signature passes according to the second signature certificate and the second information to be verified.
  • 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.
  • the second request further includes second control flow information
  • the second control flow information is used to indicate the running path of the control program of the second node.
  • the processing unit is further used to: verify whether the second control flow information is correct.
  • the processing unit when the third signature verification passes and the second control flow information verification passes, is further used to determine a fifth signature based on the third signature and the fourth signature, the fourth signature being obtained by the third node by signing the third call chain information, the third call chain information being used to indicate node information related to the first information in the third node.
  • the communication unit is also used to send a third request to the fourth node, the third request including the third and fifth signatures, the third request being used to request the first information.
  • the processing unit 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.
  • a node 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.
  • a communication system comprising any possible node in the third aspect and the fourth aspect.
  • a mobile carrier 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.
  • the mobile carrier is a vehicle.
  • a computer program product comprising: a computer program code, when the computer program code is run on a computer, so that the computer executes any possible method in the above-mentioned first aspect, or so that the device executes any possible method in the second aspect.
  • 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.
  • FIG4 is a schematic diagram of another communication method provided in an embodiment of the present application.
  • FIG6 is a schematic diagram of another communication method provided in an embodiment of the present application.
  • storage may refer to storage in one or more memories.
  • the one or more memories may be separately set or integrated in an encoder or decoder, a processor, or a communication device.
  • the one or more memories may also be partially separately set and partially integrated in a decoder, a processor, or a communication device.
  • the type of memory may be any form of storage medium, which is not limited in this application.
  • Service-oriented architecture is being adopted by more and more automakers because it can achieve software modularity, decouple software modules from hardware and operating environments, avoid duplicate development, and facilitate the rapid introduction of new services and expansions.
  • the automotive open system architecture (AUTOSAR) alliance proposed the scalable service-oriented middleware over IP protocol (SOME/IP) protocol.
  • SOME/IP protocol can effectively meet the interactive communication of in-vehicle services, but the SOME/IP protocol itself does not have any security mechanism and cannot guarantee the integrity, authenticity and security of information transmission.
  • IPSec Internet protocol security
  • TLS transport layer security
  • DTLS datagram transport layer security
  • 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.
  • 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 authenticate and decrypt 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.
  • certificates can realize secure communication between different services in the car.
  • the security level between services is transmitted through certificates.
  • the service provider will provide the corresponding service to the service caller. After meeting the security level conditions, the integrity and authenticity of the data transmission between the two are guaranteed based on digital signatures.
  • the service provider will generate a session key and encrypt it with the public key of the service caller, and then pass it to the service caller, thereby realizing 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. Certificate authentication also has certain requirements for computing resources. These problems are not very suitable for in-vehicle communication scenarios.
  • the above security mechanisms are to ensure the authentication and protection of both parties in data transmission, but cannot guarantee the security, integrity and authenticity of information transmission in the service call chain transmission scenario.
  • the following takes the service call chain scenario in the car as an example to illustrate.
  • FIG1 is a schematic diagram of a chain scenario of in-vehicle service calls provided in an embodiment of the present application.
  • the chain scenario of in-vehicle service call includes a service caller 110, which is usually a device related to in-vehicle and out-vehicle communication, such as a telematics box (T-BOX), a device related to the entertainment information domain, or a device related to the intelligent driving domain.
  • a service caller 110 which is usually a device related to in-vehicle and out-vehicle communication, such as a telematics box (T-BOX), a device related to the entertainment information domain, or a device related to the intelligent driving domain.
  • T-BOX telematics box
  • remote control or remote diagnosis of the intelligent networked vehicle is achieved through the 4G/5G interface of the T-BOX.
  • Control of the entertainment information domain of the intelligent networked vehicle is achieved through Bluetooth communication, etc.
  • the chain scenario of in-vehicle service calls may include multiple service providers.
  • 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.
  • 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 may be connected to specific control devices in the vehicle, such as the electronic stability program (ESP), the electric power steering system (EPS), the power system, the braking system and the collision system.
  • ESP electronic stability program
  • EPS electric power steering system
  • 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.
  • the service caller 110 when the service caller 110 receives a control signal or a diagnostic signal from outside the vehicle, the signal is converted into a corresponding service call request and sent to the service provider to obtain the corresponding service. For example, if the service caller 110 needs to call the relevant information of any service provider, the service call request can be sent through the transmission chain shown in FIG. 1, so that the corresponding service provider can feedback the corresponding service information. For another example, if the service caller 110 controls any service provider to perform a corresponding operation, the service call request can be sent through the transmission chain shown in FIG. 1, so that the corresponding service provider can respond to the service call request and perform the corresponding operation.
  • the above-mentioned in-vehicle secure communication mechanisms are all about authentication and protection between the two.
  • the intermediate node is hijacked, that is, when the first service provider 120 is hijacked, the security, integrity and authenticity of the service call request transmitted between the first service provider 120 and the second service provider 130 cannot be guaranteed.
  • 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 in conjunction with FIG. 2 to FIG. 8 .
  • Digital signature is the application of asymmetric key cryptographic encryption technology and digital summary technology.
  • a digital signature is a string of numbers that cannot be forged by the sender of information. This string of numbers can guarantee the integrity of the information sent by the sender and the authenticity of the sender's identity. Digital signature has non-repudiation.
  • a control flow graph is an abstract representation of a process or program. It is an abstract data structure used in compilers and maintained internally by the compiler. It represents all the paths that a program will traverse during execution.
  • a control flow graph uses a graph to represent the possible flow of execution of all basic blocks within a process, and can also reflect the real-time execution of a process.
  • Fig. 2 is a flow chart of a communication method provided by an embodiment of the present application.
  • Each node executing the method shown in Fig. 2 may represent a different platform.
  • each node may represent an application module or a service module of a different platform.
  • each platform may have multiple service modules or application modules according to the type of each request, and each request is used to request information from a corresponding service module or application module.
  • the first node may be the T-BOX in FIG1
  • the second node may be the in-vehicle computing platform shown in FIG1
  • the third node may be the gateway shown in FIG1.
  • the first node may be an application module or service module of the T-BOX
  • the second node may be an application module or service module of the in-vehicle computing platform
  • the third node may be an application module or service module of the gateway.
  • the specific execution subject of each node may be the electronic device corresponding to each platform.
  • 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.
  • the first information may be instruction information generated by the starting node, so that the end node executes the operation indicated by the instruction information; or, the first information may be acquisition information required by the starting node, so that the end node feeds back corresponding acquisition information.
  • the command information generated by the starting node may be door control command information, etc.
  • the information required to be obtained by the starting node may be vehicle speed information, etc.
  • the first information is instruction information generated by the first node or acquisition information required by the first node; when the first node is a non-starting node, the first information may be 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.
  • the first signature when the first node is the starting node, 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.
  • the first signature can be used to indicate the node signatures corresponding to the first node and the nodes before the first node. That is, 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.
  • 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, and the first call chain information includes the starting node information.
  • 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).
  • 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.
  • the first call chain information can also be understood as the call chain information used to indicate the first information in the second node. That is, the first call chain information is used to indicate the path information for requesting the first information in the second node.
  • the first call chain information can be used to indicate the starting node related to the first information in the second 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.
  • the first call chain information can be used to indicate a call chain from a starting node related to the first information in a second node to the current node.
  • the first call chain information may include first node information and second node information, for example, an identity identifier of the first node and an identity identifier of the second node.
  • 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 and the downstream nodes of the current node.
  • the first call chain information may include the first node information, the second node information and the third node information, for example, the identity of the first node, the identity of the second node and the identity of the third node.
  • the third signature includes the first signature and the second signature.
  • the first signature and the second signature are multiplied to obtain a third signature.
  • the first signature and the second signature are integrated to obtain a third signature.
  • the first call chain information and the second call chain information are different, and 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 the second call chain information.
  • the first signature and the second signature are multiplied to obtain a third signature.
  • the first signature and the second signature are integrated to obtain a 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.
  • the first request also includes first control flow information
  • the first control flow information includes the running path of the control program of the first node.
  • the second node sends a second request to the third node, the second request includes a third signature, and the second request is used to request the first information.
  • the second request may further include the first freshness value.
  • the second request may further include second control flow information, where 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.
  • the third node verifies the third signature.
  • 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 described in detail in conjunction with FIG.
  • a first public key is obtained, and the first public key includes public keys of the first node and the second node.
  • the third signature is verified 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.
  • the second request includes the first call chain information and the second call chain information.
  • a first signature credential is obtained.
  • the third signature the first information to be verified is obtained.
  • the first signature credential and the first information to be verified whether the third signature passes is verified.
  • the second request includes the first call chain information or the second call chain information.
  • the first public key the sum of the public keys is obtained.
  • the second signature certificate is obtained.
  • the third signature the second information to be verified is obtained.
  • the second signature certificate and the second information to be verified whether the third signature passes.
  • the third node verifies the third signature obtained based on the first signature and the second signature after receiving the request.
  • 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. In this way, the security of data transmission of each node can be further improved, thereby improving the security of global chain request transmission.
  • FIG3 is an interactive schematic diagram of another communication method provided in an embodiment of the present application.
  • the communication method shown in FIG3 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 chain calls in the communication, and the three nodes in the figure are only exemplary. Any node with a chain call can use the method shown in FIG3.
  • the specific execution subject of each node can be an electronic device corresponding to each platform, or a chip, a chip system, or a processor that supports the electronic device to implement the corresponding method, or a logic module or software that can implement all or part of the functions of the electronic device.
  • the second node is an intermediate node
  • the first node is an upstream node of the intermediate node
  • the third node is a downstream node of the intermediate node.
  • the first node is described in detail by taking the initial node as an example.
  • the first node can also be regarded as an intermediate node.
  • the first node in in-vehicle communication, can be the T-BOX in FIG1, the second node can be a device related to the in-vehicle computing platform in FIG1, and the third node can be the gateway in FIG1.
  • a first node determines a first request, where the first request is used to request first information and includes a first signature.
  • 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.
  • 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.
  • the second call chain information is used to indicate the node information related to the first information in the first node. That is, the second call chain information is used to indicate the call chain information of the first information in the first node.
  • the second call chain information can be used to indicate a starting node related to the first information in the first node.
  • the second call chain information can include the first node information, for example, the identity of the first node.
  • the second call chain information can be used to indicate a call chain from a starting node related to the first information in a first node to a downstream node of the current node.
  • the second call chain information includes first node information and second node information, for example, the identity of the first node and the identity of the second node.
  • the first signature can also be understood as the node signature of the first node.
  • the first node signs the second call chain information using the private key of the first node to obtain a first signature.
  • 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.
  • the first signature in the above manner may also be obtained by the second node signing the second call chain information and the second fresh value using the second node's private key.
  • the first request includes the second call chain information, the second fresh value and the first signature.
  • the second freshness value is used to indicate the real-time nature of the second call chain information.
  • the second freshness value may be generated by the first node through a timestamp verification mode, or may also be generated through a frame counter verification mode.
  • the counterfeiting, tampering and replay of the service call information can be effectively prevented, further improving the security of the request.
  • the first signature in the above method can also be obtained by the first node signing the second call chain information, the second fresh value and the first control flow information using the private key of the first node.
  • the first request includes the second call chain information, the second fresh value, the first control flow information and the first signature.
  • 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.
  • the first node requests the running path information of the program of the first information.
  • S320 The first node sends a first request to the second node, and the second node receives the first request from the first node.
  • the second node verifies the first signature of the first call request.
  • the second node verifies the first signature according to 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.
  • 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.
  • the third signature credential may be a hash value obtained by performing a hash operation on the above information.
  • the first signature verification passes.
  • the first signature verification fails.
  • S360 is executed, and the second node determines a second request, and the second request includes a third signature.
  • the second node determines the third signature according to the first signature and the second signature.
  • 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.
  • the second signature may also be obtained by the second node by signing the first call chain information and the first freshness value.
  • the first freshness value indicates the real-time nature of the first call chain information.
  • the specific method for generating the first freshness value can refer to the second freshness value, which will not be described in detail here.
  • the second signature may also be obtained by signing the second node through the first call chain information, the first freshness value and the second control flow information.
  • the second control flow information includes the running path of the control program of the second node, that is, the second control flow information is used to indicate the running path of the program corresponding to the control flow graph of the second node.
  • the second node requests the running path information of the program of the first information.
  • the second control flow information can be collected by the second node through hardware.
  • the third signature includes the first signature and the second signature.
  • 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.
  • the signature object signed by the second node using the second node's private key may be different from the signature object signed by the first node using the first node's private key, and the signature object signed by the second node using the second node's private key may be the same as the signature object signed by the first node using the first node's private key. That is, in this implementation, it is not limited that the signature objects signed by each node using their own private key are the same or different.
  • the first signature includes the node signatures of the first node and all upstream nodes before the first node.
  • the third signature includes the second signature and multiple node signatures of the node signatures of all upstream nodes before the second node.
  • 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.
  • the first signature is a single signature
  • the third signature is also a single signature.
  • the first signature when the first node is the initial node, the first signature is the node signature of the first node.
  • the first signature is a single signature obtained by integrating the node signatures of the first node and all nodes before the first node.
  • the second request also includes the first call chain information and/or the second call chain information, and 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.
  • the relevant explanation of the second call chain information can refer to S310.
  • 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.
  • the first node is the initial node, and the first call chain information and the second call chain information are different.
  • the first call chain information includes the identity identifiers of the first node, the second node and the third node
  • the second call chain information includes the identity identifiers of the first node and the second node.
  • the first call chain information and the second call chain information both include the identity of the first node.
  • the second node sends a second request to the third node, and the third node receives the second request from the second node, where the second request includes a third signature.
  • the third node verifies the third signature.
  • 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 FIG.
  • 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.
  • the third node obtains the first signature certificate according to the first public key, the first call chain information and the second call chain information; obtains the first information to be verified according to the third signature; and verifies whether the third signature passes according to the first signature certificate and the first information to be verified.
  • the detailed verification process will be described in conjunction with FIG5.
  • the sum of the public keys is obtained according to the first public key; the second signature certificate is obtained according to 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 according to the third signature; and the third signature is verified according to the second signature certificate and the second information to be verified.
  • the first public key includes the public keys of the second node and all nodes before the second node.
  • the second node is the initial node
  • the first public key includes the public key of the first node and the public key of the second node.
  • the third node verifies whether the second control flow information is correct.
  • the third node determines the fifth signature based on the third signature and the fourth signature, 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, the third request includes the fifth signature, and the third request is used to request the first information.
  • 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 that of the first call chain information. Please refer to the relevant description of the first call chain information in S220.
  • the third node may respond to the first information according to the second request.
  • 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.
  • the third signature that the third node, as the downstream node of the intermediate node, verifies after receiving the request is obtained based on the first signature and the second signature.
  • 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. In this way, the security of data transmission of each node can be further improved, thereby improving the security of global chain call request transmission.
  • FIG4 is a schematic diagram of another communication method provided by an embodiment of the present application.
  • FIG4 takes the first three nodes in the chain transmission as an example to illustrate the method in detail.
  • 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.
  • the relevant explanations of the first node, the second node, and the third node shown in FIG4 can refer to the relevant description in FIG3, and will not be repeated here.
  • the first node generates a signature A according to the private key A of the first node and the call chain information A.
  • the first node signs the call chain information A according to the private key A to generate signature A.
  • the call chain information A is used to indicate the node information related to the first information in the first node, that is, the call chain information A is the call chain information related to the first information in the first node.
  • the call chain information A indicates that the first information starts from the first node, and at this time, the call chain information A includes the node identity of the first node.
  • the call chain information A indicates that the first node requests the first information through the second node, and the call chain information A includes the node identities of the first node and the second node.
  • the first information may be a specific service instruction.
  • the first information may be a service call information of a brake signal.
  • the complete call chain is that the first node is T-BOX, the second node is the in-vehicle computing platform, the third node is the gateway, the fourth node is the in-vehicle control domain, and the fifth node is the ECU in the brake system.
  • the call chain information A can be a call chain in which T-BOX calls the ECU information of the brake system through the in-vehicle computing platform.
  • the call chain information A can be a call chain in which the ECU information of the brake system is called starting from the T-BOX node.
  • 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.
  • the signature A can also be obtained by signing the call chain information A and the fresh value A using the private key A.
  • 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.
  • the control flow information A is the running path of the calling control program of the first node.
  • the first node determines request A, which includes signature A and call chain information A.
  • request A also includes a fresh value A.
  • the first node sends request A to the second node, and the second node receives request A from the first node.
  • the signature A is verified based on the public key A of the first node and the call chain information A.
  • 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.
  • 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.
  • the second node performs a hash operation on the call chain information A and the fresh value A to obtain the hash value A’.
  • 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.
  • the second node When the signature A is verified successfully, S450, the second node generates a signature B according to the private key B of the second node and the call chain information B.
  • the second node signs the call chain information B according to the private key B to generate the signature B.
  • 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.
  • 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.
  • Freshness value B is used to indicate the timeliness of call chain information B, and the specific acquisition method is similar to freshness value A.
  • freshness value B can also indicate the timeliness of call chain information A, in which case, freshness value B is equal to freshness value A.
  • the call chain information B may represent a call chain in which the first node calls the third node through the second node, and the call chain information B may include the identity identifiers of the first node, the second node, and the third node.
  • the call chain information B may indicate that the first information starts from the first node, and the call chain information B may include the identity of the first node.
  • the call chain information A also includes the identity of the first node, the call chain information A and the call chain information B are the same.
  • 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 also includes the identity of the T-BOX.
  • the object signed by each node using the private key can be the same.
  • the objects signed by the first node and the second node using their respective private keys are the same.
  • the objects signed by each node using their respective private keys can also be different.
  • the second node determines request B, and request B includes signature A, signature B, call chain information A and/or call chain information B.
  • 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.
  • the request B includes the signature A, the signature B, the call chain information A, and the fresh value A.
  • the request B includes the signature A, the signature B, the call chain information B, and the fresh value B. Since the call chain information A and the call chain information B are the same, the fresh value A and the fresh value B are also the same.
  • the signature A and the signature B in S460 can be regarded as two specific signatures included in the third signature in S360.
  • the second node sends request B to the third node, and the third node receives request B from the second node.
  • 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, call chain information A and call chain information B.
  • the third node verifies signature A through the public key of the first node and call chain information A, and verifies signature B through the public key of the second node and call chain information B.
  • the specific verification method can be referred to S440, which will not be described in detail here.
  • 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.
  • method two is that when the third node is the end node that responds to the first information, it responds to the first information according to request B.
  • the third signature includes signatures corresponding to multiple nodes, which can simply and efficiently improve the security of global chain call request transmission.
  • the above method can be applied to the case where the information signed by each node using the private key is different or the same.
  • the information signed by each node is different, there can be another verification method, which will be described in detail in conjunction with Figure 5.
  • the information signed by each node is the same, there can be another verification method, which will be described in detail in conjunction with Figure 6.
  • FIG5 is a schematic diagram of another communication method provided by an embodiment of the present application.
  • FIG5 takes the first three nodes in the chain transmission as an example to explain the method in detail.
  • 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
  • the third node corresponds to the third node shown in FIG3.
  • the first node generates a signature A according to the private key A of the first node and the call chain information A.
  • S510 is similar to S410, and related descriptions may refer to S410, which will not be repeated here.
  • the call chain information A is used to indicate the call chain information in which the first node in the first node requests the first information through the second node, and the call chain information A includes the identity identifiers of the first node and the second node.
  • the first node determines request A, and request A includes signature A and call chain information A.
  • request A also includes a fresh value A.
  • the first node sends request A to the second node, and the second node receives request A from the first node.
  • the second node When the signature A is verified successfully, S550, the second node generates a signature B according to the private key B of the second node and the call chain information B.
  • Call chain information B is the call chain information related to the first information in the second node.
  • 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, and call chain information B includes the identity identifiers of the first node, the second node, and the third node.
  • the call chain information A and the call chain information B are different.
  • S560 The second node generates a third signature based on signature A and signature B.
  • signature A and signature B are integrated to obtain a third signature.
  • the specific integration method can be obtained by multiplying signature A and signature B.
  • signature A and signature B are integrated to obtain a third signature.
  • the embodiment of the present application does not limit the integration of node signatures of each node.
  • the second node determines request B, which includes the third signature, call chain information A and call chain information B.
  • request B includes a third signature, call chain information A, fresh value A, call chain information B and fresh value B.
  • the second node sends a request B to the third node, and the third node receives the request B from the second node.
  • the third node verifies the third signature in request B.
  • 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.
  • the third node generates signature voucher A based on public key A and call chain information A; generates signature voucher B based on public key B and call chain information B; and uses the sum of signature voucher A and signature voucher B as the first signature voucher.
  • the third node obtains the first information to be verified based on the third signature.
  • the third signature is verified based on the first signature voucher and the first information to be verified.
  • the third signature verification passes.
  • the third signature verification fails.
  • 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 the signature of the node after the third node can refer to the relevant method of the third node in the method shown in Figure 5.
  • the method for determining the request of the node after the third node can refer to the relevant method of the second node in the method shown in Figure 5.
  • method two when the third node is the end point node responding to the first information, it responds to the first information according to request B.
  • the signature in the request is a single signature that is an integration of signatures corresponding to multiple nodes, which improves the security of global chain request transmission while saving the transmission bandwidth of the request.
  • FIG6 is a schematic diagram of a communication method provided by an embodiment of the present application.
  • FIG6 takes the first three nodes in the chain transmission as an example to explain the method in detail. 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.
  • the relevant explanations of the first node, the second node, and the third node shown in FIG6 can refer to the relevant description in FIG3, and will not be repeated here.
  • the first node generates a signature A according to the private key A of the first node and the call chain information A.
  • S610 is similar to S410, and related descriptions may refer to S410, which will not be repeated here.
  • 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.
  • the first node determines request A, which includes signature A and call chain information A.
  • request A also includes a fresh value A.
  • the first node sends request A to the second node, and the second node receives request A from the first node.
  • the second node When the signature A is verified successfully, S650, the second node generates a signature B according to the private key B of the second node and the call chain information A.
  • the second node signs the call chain information A according to the private key B to generate the signature B.
  • the second node can perform a hash operation on the call chain information A to obtain a hash value A, and then use the second node's private key B to sign the hash value A to obtain signature B.
  • the second node can use the first node's public key to decrypt signature A to obtain a hash value A', and the hash value A is equal to the hash value A', and then use the second node's private key B to sign the hash value A' to obtain signature B.
  • 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 signature object of the private key A of the first node and the signature object of the private key B of the second node are the same, and both can be the call chain information A. Alternatively, both can be the call chain information A and the fresh value A.
  • S660 The second node generates a third signature based on signature A and signature B.
  • signature A and signature B are integrated to obtain a third signature.
  • the specific integration method can be obtained by multiplying signature A and signature B.
  • signature A and signature B are integrated to obtain a third signature.
  • the embodiment of the present application does not limit the integration of node signatures of each node.
  • the second node determines request B, which includes the third signature and call chain information A.
  • request B includes a third signature, call chain information A and fresh value A.
  • the second node sends a request B to the third node, and the third node receives the request B from the second node.
  • the third node verifies the third signature in request B.
  • 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.
  • the third node uses the sum of public key A and public key B as the sum of public keys; then obtains the second signature certificate based on the sum of public keys and call chain information A; obtains the second information to be verified based on the third signature. Verify the third signature based on the first signature certificate and the first information to be verified.
  • the third signature verification passes.
  • the third signature verification fails.
  • 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 the signature of the node 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 the request of the node after the third node can refer to the method related to the second node in the method shown in Figure 6.
  • method two when the third node is the end point node responding to the first information, it responds to the first information according to request B.
  • 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 signatures corresponding to multiple nodes. This improves the security of global chain request transmission, saves the transmission bandwidth of the request, and also saves computing power.
  • the first type is that each node has its own public-private key pair.
  • the public-private key pairs shown in Figures 4 to 6 belong to this case.
  • 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.
  • PSK pre-shared key
  • the service-level key of each node is the same.
  • the integrity protection of the call chain is realized by a message authentication code (MAC), that is, the first information is encrypted by the same service-level key of each node.
  • 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 limit this.
  • HMAC hash-based message authentication code
  • CMAC block encryption-based message authentication code
  • 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.
  • 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.
  • the third node verifies the third signature determined according to the first signature and the second signature after receiving the request.
  • the second fresh value in the first request can effectively prevent the counterfeiting, tampering and replay of the first request.
  • the second node of the call chain that is, the intermediate node in the call chain
  • the hijacked second node sends the second request to the third node
  • the third node cannot verify the signature of the first node. Therefore, through the scheme of the embodiment of the present application, it 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.
  • FIG7 is a schematic diagram of an in-vehicle call chain provided in an embodiment of the present application.
  • the first node of the in-vehicle call chain may be T-BOX710
  • the second node may be the in-vehicle computing platform 720
  • the third node may be a gateway 730
  • the specific gateway type may be a distributed gateway.
  • 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 process of verifying the integrity of the call chain by the intermediate node is described below using the remote control call chain and the remote diagnosis call chain respectively.
  • remote control application/service and the remote diagnosis application/service of each node shown in FIG. 7 are software modules of each node.
  • the first information requested by the remote control application/service 711 may be the first control information.
  • the first control information is used to instruct the control service module or control application module corresponding to the end node to perform a corresponding operation, or the first control information is used to instruct to obtain information from the control service module or application control module corresponding to the end node.
  • the specific steps for verifying the integrity of the remote control call chain are as follows.
  • the remote control application/service 711 in TBOX 710 receives the remote control signal from outside the vehicle via 4G/5G.
  • the remote control application/service 711 determines the first control request according to the remote signal, and sends the first control request to the remote control application/service 721 in the in-vehicle computing platform 720 through the AUTOSAR adaptive platform (automotive open system architecture adaptive platform, AUTOSAR AP) based on the in-vehicle Ethernet protocol COME/IP.
  • AUTOSAR adaptive platform automotive open system architecture adaptive platform, AUTOSAR AP
  • the specific determination of the first control request can refer to the method of determining request A of the first node in Figures 4 to 6.
  • the remote control application/service 721 verifies the first signature in the first control request.
  • the remote control application/service 721 determines the second control request and sends the second control request to the remote control application/service 731 in the gateway 730 through the AUTOSAR AP based on the in-vehicle Ethernet protocol COME/IP.
  • the second control request includes a third signature, which is used to indicate the signatures of the T-BOX and the in-vehicle computing platform.
  • the specific generation method of the third signature please refer to the generation method of the third signature of the second node in Figures 4 to 6.
  • the remote control application/service 731 verifies the third signature in the second control request.
  • the remote control application/service 731 can determine the new request and send the request to the next node.
  • the signature included in the new request indicates the node signatures generated by T-BOX710, the in-vehicle computing platform 720, and the gateway 730 respectively.
  • the remote control application/service 731 can also respond to the first control service according to the second control request.
  • the first information requested by the remote diagnosis application/service 712 may be the first diagnosis information.
  • the specific steps of verifying the integrity of the remote diagnosis call chain are similar to the above-mentioned verification of the integrity of the remote diagnosis call chain. The following will specifically illustrate, in conjunction with FIG. 7 , the specific process by which the communication method in the present application can effectively improve security after the second node 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.
  • the remote control application/service 732 of the gateway 730 verifies the third signature in the second diagnostic request, since the third signature cannot indicate the signature of the T-BOX, the third signature cannot pass the verification, and the request for diagnostic information in the second diagnostic request is also not allowed, as shown in FIG7 .
  • 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.
  • FIG8 is illustrated by taking the first node as T-BOX 810, the second node as in-vehicle computing platform 820, and the third node as gateway 830 as an example.
  • the predefined call chain is that T-BOX 810 requests remote diagnostic information from gateway 830 through in-vehicle computing platform 820.
  • T-BOX810 determines the first diagnostic request in the trusted execution environment (TEE) 812.
  • the first diagnostic request includes first control flow information, a second fresh value, second call chain information and a first signature.
  • the first control flow information may be collected based on the hardware of the T-BOX, and 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.
  • the first control flow information is directly collected through the specific hardware of the node, and no software module is needed to collect the first control flow information, which can reduce the delay.
  • the first signature may be obtained by T-BOX 810 signing the first control flow information, the first fresh value, and the first call chain information using the private key of T-BOX in TEE 812.
  • the first signature may be the signature A shown in FIGS. 4 to 6 , and a more specific implementation method may refer to FIGS. 4 to 6 .
  • the remote diagnosis application 811 of T-BOX 810 sends the first diagnosis request to the remote diagnosis application 821 of the in-vehicle computing platform 820.
  • the remote diagnosis application 811 of the T-BOX 810 can send a first diagnosis request to the remote diagnosis application 821 of the in-vehicle computing platform 820 via the in-vehicle Ethernet (e.g., COME/IP).
  • the in-vehicle Ethernet e.g., COME/IP
  • the in-vehicle computing platform 820 verifies the first signature in TEE822.
  • the first signature can be the signature A shown in Figures 4 to 6.
  • the in-vehicle computing platform 820 verifies the first control flow information in TEE822.
  • the in-vehicle computing platform 820 obtains the first control flow graph of T-BOX 810 in advance.
  • the in-vehicle computing platform 820 obtains first verification control flow information based on a 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.
  • control flow information of the upstream node is added to the first request, which can effectively prevent and discover program code reuse attacks, such as return-oriented programming ROP or jump-oriented programming JOP.
  • the in-vehicle computing platform 820 verifies the calling authority of T-BOX 810 through the identity and access management (IAM) module in TEE822.
  • IAM identity and access management
  • 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 T-BOX and the signature of the in-vehicle computing platform.
  • 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.
  • the second diagnostic request also includes the second fresh value and the second call chain information.
  • a detailed description may refer to FIG. 3.
  • the second diagnostic request includes second control flow information, which may 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.
  • 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.
  • 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).
  • the in-vehicle Ethernet eg, COME/IP
  • the gateway 830 verifies the third signature in TEE832.
  • the third signature may be the signature A and the signature B shown in FIG. 4 , or the third signature may be the specific implementations in FIG. 5 and FIG. 6 , and reference may be made to FIG. 4 to FIG. 6 .
  • the gateway 830 verifies the second control flow information in TEE 832.
  • the gateway 830 verifies the calling permissions of the T-BOX 810 and the in-vehicle computing platform 820 in the TEE 832.
  • the gateway 830 verifies the calling permissions of the T-BOX 810 and the in-vehicle computing platform 820 in the TEE832IAM module.
  • the diagnostic request related to the remote diagnostic information can continue to be transmitted along the chain node until it is transmitted to the end node that responds to the remote diagnostic information.
  • the gateway 830 when the gateway 830 is the end point node corresponding to the diagnostic information, it responds to the remote diagnostic information according to the second diagnostic request.
  • 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.
  • node 900 is an intermediate node, that is, a second node
  • communication unit 901 is used to receive a first request from a 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.
  • Processing unit 902 is used to determine a 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, and the first call chain information includes the starting node information.
  • the communication unit 901 is used 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.
  • node 900 is a downstream node of the intermediate node, that is, a third node
  • communication unit 901 is used to receive a second request from a second node, the second request includes a third signature, and the second request is used to request first information, and the first information is information related to the starting node.
  • 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, 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.
  • FIG10 is a schematic diagram of the hardware structure of a node provided by the implementation 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 through 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 part of the parameters of the second channel model.
  • the memory 1010 can be coupled to the processor 1020 through an interface, or integrated with the processor 1020.
  • the communication interface 1030 uses a transceiver such as but not limited to a transceiver to achieve communication between the communication device 1000 and other devices or communication networks.
  • the communication interface 1030 may also include an input/output interface.
  • each step of the above method can be completed by an integrated logic circuit of hardware in the processor 1020 or an instruction in the form of software.
  • the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in the processor for execution.
  • 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 conjunction with its hardware. To avoid repetition, it is not described in detail here.
  • the processor may be a central processing unit CPU, and the processor may also be other general-purpose processors, digital signal processors DSP, application-specific integrated circuits ASIC, off-the-shelf programmable gate arrays FPGA or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.
  • the memory may include a read-only memory and a random access memory, and provide instructions and data to the processor.
  • a portion of the processor may also include a non-volatile random access memory.
  • the processor may also store information about the device type.
  • 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.
  • An embodiment of the present application also 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.
  • 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.
  • An embodiment of the present application further provides a computer-readable medium, wherein the computer-readable medium stores a program code.
  • the computer 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 .
  • the embodiment of the present application further provides a computer program product, which includes: a computer program code, and when the computer program code is executed on a computer, the computer executes the above method.
  • 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 used to read and execute instructions in the memory to execute any one of the methods in Figures 2 to 8 above.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the units is only a logical function division. There may be other division methods in actual implementation, 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.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • 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.
  • 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.
  • the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art.
  • the computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供了一种通信方法、节点、通信***和移动载体。该通信方法包括:接收来自第一节点的第一请求,第一请求用于请求第一信息,第一信息为与起始节点相关的信息,第一请求包括第一签名。在第一签名校验通过的情况下,根据第一签名和第二签名,确定第三签名,第二签名是通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。向第三节点发送第二请求,第二请求包括第三签名,第二请求用于请求第一信息。这样,可以进一步提高每个节点的数据传输的安全性,从而提高了全局链式调用请求传输的安全性。

Description

一种通信方法、节点、通信***和移动载体 技术领域
本申请实施例涉及通信安全领域,具体设计一种通信方法、节点、通信***和移动载体。
背景技术
在通信安全领域,一般通过密码技术保证数据传输的安全性和完整性。目前,针对该密码技术发生在数据发送方和数据接收方这两者之间的情况,有较为完善的技术。但是,在数据存在链式传输的情况,例如,服务调用链场景下,如果中间节点被劫持,基于目前的两节点之间的密码技术,被劫持的中间节点可能存在无条件调用下游节点服务的情况。
因此,如何提高链式数据传输的安全性,成为亟待解决的问题。
发明内容
本申请实施例提供一种通信方法、节点、通信***和移动载体,可以提高每个节点的数据传输的安全性,从而提高了全局链式调用请求传输的安全性。
本申请中的移动载体可以包括路上交通工具、水上交通工具、空中交通工具、工业设备、农业设备、或娱乐设备等。例如移动载体可以为车辆,该车辆为广义概念上的车辆,可以是交通工具(如商用车、乘用车、摩托车、飞行车、火车等),工业车辆(如:叉车、挂车、牵引车等),工程车辆(如挖掘机、推土车、吊车等),农用设备(如割草机、收割机等),游乐设备,玩具车辆等,本申请实施例对车辆的类型不作具体限定。再如,移动载体可以为飞机、或轮船等交通工具。下文以移动载体是车辆为例进行说明。
第一方面,提供了一种通信方法,该方法应用于第二节点,该方法包括:接收来自第一节点的第一请求,第一请求用于请求第一信息,第一信息为与起始节点相关的信息,第一请求包括第一签名。在第一签名校验通过的情况下,根据第一签名和第二签名,确定第三签名,第二签名是通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。向第三节点发送第二请求,第二请求包括第三签名,第二请求用于请求第一信息。
应理解,每个节点可以代表不同的平台。或者每个节点可以代表不同平台的应用模块或服务模块。在每个节点代表不同平台的应用模块或服务模块时,每个平台根据每个请求的类型,可以具有不同的服务模块或应用模块。
例如,如果第一请求的类型为控制请求,那么每个节点代表每个平台的控制应用模块或控制服务模块;如果第一请求的类型为诊断请求,那么每个节点代表每个平台的诊断应用模块或诊断服务模块。
应理解,第一信息可以是起始节点产生的指令信息,使得终点节点执行指令信息指示的操作;或者,第一信息可以是起始节点需要的获取信息,使得终点节点反馈相应的获取 信息。
换句话说,在每个节点代表不同平台的应用模块或服务模块时,终点节点对应的应用模块或服务模块执行指令信息指示的操作,如果第三节点为终点节点,那么第二请求用于指示第三节点的应用模块或服务模块执行第一信息指示的操作。或者终点节点对应的应用模块或服务模块反馈获取信息,如果第三节点为终点节点,那么第二请求用于从第三节点对应的应用模块或服务模块调用第一信息。
在第一节点为起始节点时,第一信息为第一节点产生的指令信息或者为第一节点需要的获取信息;在第一节点为非起始节点时,第一信息可以是从起始节点,沿着调用链传输至第一节点,再通过第一请求发送至第二节点的指令信息或获取信息。
其中,第一调用链信息还可以理解为用于指示第一信息在第二节点中的调用链信息。
换句话说,第一调用链信息用于指示在第二节点中请求第一信息的路径信息。
在第一节点为起始节点时,第一调用链信息包括第一节点信息,例如,第一节点的身份标识。
在上述技术方案中,第三节点作为中间节点的下游节点在接收到请求之后会校验根据第一签名和第二签名确定的第三签名。这样,即使在第二节点被劫持后,被劫持后的第二节点向第三节点发送请求时,该请求中无第一节点的相关签名信息。因此,由于第三节点在校验签名时,无法校验到第一节点的相关签名信息,第三节点也不会无条件响应被劫持后的第二节点的请求。这样,可以进一步提高每个节点的数据传输的安全性,从而提高了全局链式调用请求传输的安全性。
结合第一方面,在第一方面的某些实现方式中,第三签名包括第一签名和第二签名。
在上述技术方案中,第三签名中包括多个节点对应的签名,可以简单高效地提高了全局链式调用请求传输的安全性。
结合第一方面,在第一方面的某些实现方式中,根据第一签名和第二签名,确定第三签名包括:将第一签名和第二签名进行累乘,得到第三签名。或者,基于椭圆曲线,整合第一签名和第二签名,得到第三签名。其中,第一调用链信息和第二调用链信息不同,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息和第二调用链信息。
在上述技术方案中,请求中的签名为多个节点对应的签名整合后的单签名,在提高了全局链式请求传输的安全性的同时,还节省了请求的传输带宽。
结合第一方面,在第一方面的某些实现方式中,根据第一签名和第二签名,确定第三签名包括:将第一签名和第二签名进行累乘,得到第三签名。或者,基于椭圆曲线,整合第一签名和第二签名,得到第三签名。其中,第一调用链信息和第二调用链信息相同,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息或第二调用链信息。
在上述技术方案中,每个节点生成各自节点的签名对象是相同的,并且节点之间传输的请求中的签名为多个节点对应的签名整合后的单签名,在提高了全局链式调用请求传输的安全性,并且节省了请求的传输带宽的同时,还节省了算力。
结合第一方面,在第一方面的某些实现方式中,第二请求还包括第一新鲜值,第一新鲜值用于指示第一调用链信息的实时性,第二签名是通过对第一调用链信息和第一新鲜值 签名得到的。
这样,在第二请求包括第一新鲜值的情况下,可以有效防止服务调用信息的仿冒、篡改和重放,进一步提高了调用请求的安全性。
结合第一方面,在第一方面的某些实现方式中,第一请求还包括第一控制流信息,第一控制流信息包括第一节点的控制程序的运行路径。在第一签名校验通过的情况下,根据第一签名和第二签名,确定第三签名包括:在对第一签名校验通过且对第一控制流信息校验通过的情况下,根据第一签名和第二签名,确定第三签名。
这样,在第一请求中加入了上游节点的控制流信息,可以有效防止和发现程序代码复用攻击,例如,面向返回的编程(return-oriented programming,ROP)或跳转导向编程(jump-oriented programming,JOP)。
结合第一方面,在第一方面的某些实现方式中,通过硬件收集第二节点的第二控制流信息,第二控制流信息包括第二节点的控制程序的运行路径,第二请求还包括第二控制流信息。
这样,直接通过节点对应的具体的硬件来收集第二控制流信息,不需要软件模块去收集第二控制流信息,可以降低时延。
第二方面,提供了一种通信方法,该方法应用于第三节点,该方法包括:接收来自第二节点的第二请求,第二请求包括第三签名,第二请求用于请求第一信息,第一信息为与起始节点相关的信息。校验第三签名,其中,第三签名为第二节点根据第一签名和第二签名确定的,第一签名来自第一节点的第一请求,第二签名是第二节点通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。
第二方面相关的技术效果可以参考第一方面的相关描述。
结合第二方面,在第二方面的某些实现方式中,第三签名包括第一签名和第二签名。其中,校验第三签名包括:逐一校验第三签名中的每个签名。
结合第二方面,在第二方面的某些实现方式中,第三签名为第二节点根据第一签名和第二签名累乘得到的,或基于椭圆曲线,整合第一签名和第二签名得到的。方法还包括:获取第一公钥,第一公钥包括第二节点和第二节点之前的节点的公钥。校验第三签名包括:根据第一公钥、第一调用链信息和第二调用链信息,校验第三签名。其中,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息和/或第二调用链信息。
结合第二方面,在第二方面的某些实现方式中,在第一调用链信息和第二调用链信息不同的情况下,第二请求包括第一调用链信息和第二调用链信息。根据第一公钥、第一调用链信息和第二调用链信息,校验第三签名包括:根据第一公钥、第一调用链信息和第二调用链信息,获得第一签名凭证。根据第三签名,获得第一待验证信息。根据第一签名凭证以及第一待验证信息,校验第三签名是否通过。
结合第二方面,在第二方面的某些实现方式中,在第一调用链信息和第二调用链信息相同的情况下,第二请求包括第一调用链信息或第二调用链信息。根据第一公钥、第一调用链信息和第二调用链信息,校验第三签名包括:根据第一公钥,获得公钥之和。根据第一调用链信息或第二调用链信息,以及公钥之和,获得第二签名凭证。根据第三签名,获 得第二待验证信息。根据第二签名凭证以及第二待验证信息,校验第三签名是否通过。
结合第二方面,在第二方面的某些实现方式中,第二请求还包括第一新鲜值,第一新鲜值用于指示第一调用链信息的实时性,第二签名是通过对第一调用链信息和第一新鲜值签名得到的。
结合第二方面,在第二方面的某些实现方式中,第二请求还包括第二控制流信息,第二控制流信息用于指示第二节点的控制程序的运行路径,在第三签名校验通过的情况下,方法还包括:校验第二控制流信息是否正确。
结合第二方面,在第二方面的某些实现方式中,在第三签名校验通过并且第二控制流信息校验通过的情况下,方法还包括:根据第三签名和第四签名,确定第五签名,第四签名是第三节点通过对第三调用链信息进行签名得到的,第三调用链信息用于指示第一信息在第三节点中相关的节点信息。向第四节点发送第三请求,第三请求包括第三第五签名,第三请求用于请求第一信息。
结合第二方面,在第二方面的某些实现方式中,在第三签名校验通过并且第二控制流信息校验通过的情况下,方法还包括:根据第二请求,响应第一信息。
第三方面,提供一种节点,其特征在于,节点包括通信单元和处理单元:通信单元用于,接收来自第一节点的第一请求,第一请求用于请求第一信息,第一信息为与起始节点相关的信息,第一请求包括第一签名。在第一签名校验通过的情况下,处理单元用于,根据第一签名和第二签名,确定第三签名,第二签名是通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。通信单元还用于,向第三节点发送第二请求,第二请求包括第三签名,第二请求用于请求第一信息。
第三方面相关的技术效果可以参考第一方面的相关描述。
结合第三方面,在第三方面的某些实现方式中,第三签名包括第一签名和第二签名。
结合第三方面,在第三方面的某些实现方式中,处理单元具体用于:将第一签名和第二签名进行累乘,得到第三签名。或者,基于椭圆曲线,整合第一签名和第二签名,得到第三签名。其中,第一调用链信息和第二调用链信息不同,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息和第二调用链信息。
结合第三方面,在第三方面的某些实现方式中,处理单元具体用于:将第一签名和第二签名进行累乘,得到第三签名。或者,基于椭圆曲线,整合第一签名和第二签名,得到第三签名。其中,第一调用链信息和第二调用链信息相同,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息或第二调用链信息。
结合第三方面,在第三方面的某些实现方式中,第二请求还包括第一新鲜值,第一新鲜值用于指示第一调用链信息的实时性,第二签名是通过对第一调用链信息和第一新鲜值签名得到的。
结合第三方面,在第三方面的某些实现方式中,第一请求还包括第一控制流信息,第一控制流信息包括第一节点的控制程序的运行路径。在第一签名校验通过的情况下,处理单元具体用于:在对第一签名校验通过且对第一控制流信息校验通过的情况下,第二节点根据第一签名和第二签名,确定第三签名。
结合第三方面,在第三方面的某些实现方式中,处理单元还用于:通过硬件收集第二 节点的第二控制流信息,第二控制流信息包括第二节点的控制程序的运行路径,第二请求还包括第二控制流信息。
第四方面提供一种节点,该节点包括通信单元和处理单元:通信单元用于,接收来自第二节点的第二请求,第二请求包括第三签名,第二请求用于请求第一信息,第一信息为与起始节点相关的信息。所处处理单元用于,校验第三签名,其中,第三签名为第二节点根据第一签名和第二签名确定的,第一签名来自第一节点的第一请求,第二签名是第二节点通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。
第四方面相关的技术效果可以参考第一方面的相关描述。
结合第四方面,在第四方面的某些实现方式中,第三签名包括第一签名和第二签名。处理单元具体用于:逐一校验第三签名中的每个签名。
结合第四方面,在第四方面的某些实现方式中,第三签名为第二节点根据第一签名和第二签名累乘得到的,或基于椭圆曲线,整合第一签名和第二签名得到的。节点还包括获取单元:获取单元用于,获取第一公钥,第一公钥包括第一第二节点和第二节点之前的节点的公钥。处理单元具体用于:根据第一公钥、第一调用链信息和第二调用链信息,校验第三签名。其中,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息和/或第二调用链信息。
结合第四方面,在第四方面的某些实现方式中,在第一调用链信息和第二调用链信息不同的情况下,第二请求包括第一调用链信息和第二调用链信息。处理单元具体用于:根据第一公钥、第一调用链信息和第二调用链信息,获得第一签名凭证。根据第三签名,获得第一待验证信息。根据第一签名凭证以及第一待验证信息,校验第三签名是否通过。
结合第四方面,在第四方面的某些实现方式中,在第一调用链信息和第二调用链信息相同的情况下,第二请求包括第一调用链信息或第二调用链信息。处理单元具体用于:根据第一公钥,获得公钥之和。根据第一调用链信息或第二调用链信息,以及公钥之和,获得第二签名凭证。根据第三签名,获得第二待验证信息。根据第二签名凭证以及第二待验证信息,校验第三签名是否通过。
结合第四方面,在第四方面的某些实现方式中,第二请求还包括第一新鲜值,第一新鲜值用于指示第一调用链信息的实时性,第二签名是通过对第一调用链信息和第一新鲜值签名得到的。
结合第四方面,在第四方面的某些实现方式中,第二请求还包括第二控制流信息,第二控制流信息用于指示第二节点的控制程序的运行路径。在第三签名校验通过的情况下,处理单元还用于:校验第二控制流信息是否正确。
结合第四方面,在第四方面的某些实现方式中,在第三签名校验通过并且第二控制流信息校验通过的情况下,处理单元还用于,根据第三签名和第四签名,确定第五签名,第四签名是第三节点通过对第三调用链信息进行签名得到的,第三调用链信息用于指示第一信息在第三节点中相关的节点信息。通信单元还用于,向第四节点发送第三请求,第三请求包括第三第五签名,第三请求用于请求第一信息。
结合第四方面,在第四方面的某些实现方式中,在第三签名校验通过并且第二控制流信息校验通过的情况下,处理单元还用于:第三节点根据第二请求,响应第一信息。
第五方面,提供了一种节点,该节点包括处理器和存储器,其中存储单元用于存储指令,处理单元执行存储单元所存储的指令,以使该节点执行第一方面中任一种可能的方法,或者以使该节点执行第二方面中任一种可能的方法。
第六方面,提供了一种通信***,该***包括第三方面和第四方面中任一种可能的节点。
第七方面,提供了一种移动载体,该移动载体包括第三方面或者第四方面或者第五方面中任一种可能的节点,或者,包括第六方面所述的***。
在一些可能的实现方式中,该移动载体为车辆。
第八方面,提供了一种计算机程序产品,计算机程序产品包括:计算机程序代码,当计算机程序代码在计算机上运行时,使得计算机执行上述第一方面中任一种可能的方法,或者,以使该装置执行第二方面中任一种可能的方法。
需要说明的是,上述计算机程序代码可以全部或者部分存储在第一存储介质上,其中第一存储介质可以与处理器封装在一起的,也可以与处理器单独封装,本申请实施例对此不作具体限定。
第九方面,提供了一种计算机可读介质,所述计算机可读介质存储有程序代码,当所述计算机程序代码在计算机上运行时,使得计算机执行上述第一方面中任一种可能的方法,或者,以使该装置执行第二方面中任一种可能的方法。
第十方面,本申请实施例提供了一种芯片***,该芯片***包括处理器,用于调用存储器中存储的计算机程序或计算机指令,以使得该处理器执行上述第一方面中任一种可能的方法,或者,以使该装置执行第二方面中任一种可能的方法。
结合第十方面,在一种可能的实现方式中,该处理器通过接口与存储器耦合。
结合第十方面,在一种可能的实现方式中,该芯片***还包括存储器,该存储器中存储有计算机程序或计算机指令。
附图说明
图1是本申请实施例提供的一种车内服务调用的链式场景的示意图;
图2是本申请实施例提供的一种通信方法的流程示意图;
图3是本申请实施例提供的另一种通信方法的交互示意图;
图4是本申请实施例提供的又一种通信方法的示意图;
图5是本申请实施例提供的再一种通信方法的示意图;
图6是本申请实施例提供的再一种通信方法的示意图;
图7是本申请实施例提供的一种车内调用链示意图;
图8是本申请实施例提供的一种车内远程诊断调用链通信方法的示意图;
图9是本申请实施例提供的一种节点的示意图;
图10是本申请实施提供的一种节点的硬件结构示意图。
具体实施方式
下面将结合附图,对本申请实施例中的技术方案进行描述。
为了便于理解本申请实施例,做出以下几点说明:
第一、在本申请中,如果没有特殊说明以及逻辑冲突,不同的实施例之间的术语和/或描述具有一致性、且可以相互引用,不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
第二、在本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。在本申请的文字描述中,字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a、b和c中的至少一项(个),可以表示:a,或,b,或,c,或,a和b,或,a和c,或,b和c,或,a、b和c。其中a、b和c分别可以是单个,也可以是多个。
第三、在本申请中,“第一”、“第二”指示为了描述方便进行的区分,并不用来限制本申请实施例的范围。例如,区分不同的节点等,而不是用于描述特定的顺序或先后次序。应理解,这样描述的对象在适当情况下可以互换,以便能够描述本申请的实施例以外的方案。
第四、在本申请中,“当……时”、“在……的情况下”以及“如果”等描述均指在某种客观情况下设备会做出相应的处理,并非是限定时间,且也不要求设备在实现时一定要有判断的动作,也不意味着存在其它限定。
第五、在本申请中,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
第六、在本申请中,“用于指示”可以包括用于直接指示和用于间接指示。当描述某一指示信息用于指示A时,可以包括该指示信息直接指示A或间接指示A,而并不代表该指示信息中一定携带有A。
第七、在本申请中,“存储”可以是指保存在一个或者多个存储器中。所述一个或者多个存储器可以是单独的设置,也可以是集成在编码器或者译码器、处理器、或通信装置中。所述一个或者多个存储器,也可以是一部分单独设置,一部分集成在译码器、处理器、或通信装置中。存储器的类型可以是任意形式的存储介质,本申请并不对此限定。
目前,通信安全中的密码技术主要是针对两个节点之间的数据传输的安全性和完整性。针对链式传输场景,例如,车内服务调用的链式场景,如果中间节点被劫持,基于目前的两节点之间的密码技术,下游节点将无条件被调用而无法识别出中间节点已经被攻击。
随着汽车的智能化和联网化,用户对个性化的功能和服务的需求日益提升。面向服务架构(service oriented architecture,SOA),由于其可以实现软件模块化,通过软件模块和硬件以及运行环境的解耦,避免重复开发,利于快速推出新的服务和扩展等优点,正被越来越多的汽车制造商所采用。
为了给SOA架构提供调用服务需求,汽车开放***架构(automotive open system architecture,AUTOSAR)联盟提出了车载以太网(scalable service-oriented middleware over IP protocol,SOME/IP)协议,该SOME/IP协议可以有效满足车内服务的交互通信,但是SOME/IP协议本身没有任何安全机制,无法保证信息传递的完整性、真实性以及安全性。
因此,目前一般是利用下层通用安全协议来满足车内通信的安全需求。但是,通用的安全协议仅考虑了服务调用的两点间的认证和保护。例如,网际网路安全协定(internet protocol security,IPSec)、传输层安全性协议(transport layer security,TLS)或数据包传输层安全性协议(datagram transport layer security,DTLS)是通用的安全协议等。
示例性地,IPSec是针对两个电子控制单元(electronic control unit,ECU)之间的调用服务的安全通信机制。具体而言,每个ECU都会预置密钥,并且每个ECU都会根据该预置密钥派生出各自的密钥。当目标ECU需要向源ECU请求信息或调用服务时,此时,源ECU需要给目标ECU发送报文,源ECU使用加密套件实现完整性认证和加密,其中,加密套件可以使用对称密钥算法AES-CGM-128。目标ECU使用加密套件对报文进行完整性认证和解密。IPSec存在如下问题:IPSec只能在ECU之间构建安全通信的渠道,不能保证同一ECU中不同服务和应用的安全通信。
示例性地,证书可以实现车内不同服务间的安全通信。通过证书来传递服务间的安全等级。当服务调用方(目标服务方)的最小安全等级小于或等于服务提供方(服务源方)的安全等级,服务提供方才会给服务调用方提供相应的服务。在满足安全等级的条件之后,基于数字签名保证两者之间数据传输的完整性和真实性,此外,服务提供方会生成会话密钥,并通过服务调用方的公钥加密之后,传递给服务调用方,从而实现服务提供方和服务调用方之间的安全通信。这两种安全协议应用在车内通信中,证书需要较大的存储空间,证书的传输也需要较大的带宽,并且会带来一些较大的时延,证书的认证对运算资源也有一定的要求,这些问题都不是太适合车内通信的场景。
上述安全机制都是保证双方在数据传输中的认证和保护,无法在服务调用链式传输场景中保证信息传输的安全性、完整性和真实性。下面以车内的服务调用链式场景为例进行说明。
图1是本申请实施例提供的一种车内服务调用的链式场景的示意图。
如图1所示,车内服务调用的链式场景包括服务调用方110,服务调用方110通常为车内和车外通信的相关设备,例如,通信盒子(telematics box,T-BOX)、娱乐信息域的相关设备或智能驾驶域的相关设备等。其中,通过T-BOX的4G/5G接口,实现对智能网联车的远程控制或远程诊断。通过蓝牙通信等实现对智能网联车的娱乐信息域的控制。
车内服务调用的链式场景可以包括多个服务提供方。如图1所示,车内服务调用的链式场景可以包括第一服务提供方120、第二服务提供方130以及第三服务提供方140。例如,第一服务提供方120可以是车内计算平台。第二服务提供方130可以是网关,本申请实施例对网关的类型不作限制,例如可以是分布式网关。第三服务提供方140可以是车内控制域。第三服务提供方140可以和车内的具体的控制设备连接,例如,车身电子稳定***(electronic stability program,ESP)、电子助力转向***(electric power steering,EPS)、动力***、制动***和碰撞***等。此外,车内服务调用的链式场景还可以应用于汽车热管理或座舱控制,在图1中未示出。
通常,当服务调用方110接收到车外的控制信号或诊断信号时,将该信号转化为相应的服务调用请求,发送给服务提供方以获得相应的服务。例如,如果服务调用方110需要调用任意一个服务提供方的相关信息,那么可以通过如图1所示的这样的传输链发送服务调用请求,从而使得相应的服务提供方反馈相应的服务信息。又如,如果服务调用方110 控制任意一个服务提供方案执行相应的操作,那么可以通过如图1所示的这样的传输链发送服务调用请求,从而使得相应的服务提供方响应服务调用请求执行相应的操作。
上述车内安全通信的机制,都是存在于两者之间的认证和保护,当中间节点被劫持,也就是第一服务提供方120被劫持时,无法保证第一服务提供方120和第二服务提供方130之前传输的服务调用请求的安全性、完整性和真实性。
为了解决上述问题,本申请实施例提出了一种通信方法、节点、通信***和移动载体。下面将结合图2至图8详细说明通信方法。
首先,对本申请实施例涉及的专业术语做简要说明。
1.数字签名
数字签名是非对称密钥密码加密技术和数字摘要技术的应用。数字签名是信息发送者产生的无法伪造的一段数字串,该段数字串可以保证信息发送者所发送信息的完整性以及发送者的身份的真实性。数字签名具有不可抵赖性。
2.控制流图(control flow graph,CFG)
控制流图是一个过程或程序的抽象表现,是用在编译器中的一个抽象数据结构,由编译器在内部维护,代表了一个程序执行过程中会遍历到的所有路径。控制流图用图的形式表示一个过程内所有基本块执行的可能流向,也能反映一个过程的实时执行过程。
图2是本申请实施例提供的一种通信方法的流程示意图。执行图2所示方法的每个节点可以代表不同的平台。或者每个节点可以代表不同平台的应用模块,或者服务模块。在每个节点代表不同平台的应用模块或服务模块时,每个平台根据每个请求的类型,可以具有多个服务模块或应用模块,每个请求用于从相应的服务模块或应用模块请求信息。
以图2所示方法应用于车内通信***为例,第一节点可以是图1中的T-BOX,第二节点可以是图1所示的车内计算平台,第三节点可以是图1所示的网关。或者,第一节点可以是T-BOX的应用模块或服务模块,第二节点可以是车内计算平台的应用模块或服务模块,第三节点可以是网关的应用模块或服务模块。每个节点具体的执行主体可以是每个平台对应的电子设备。
S210,第一节点向第二节点发送第一请求,第二节点接收来自第一节点的第一请求,第一请求用于请求第一信息,第一信息为与起始节点相关的信息,第一请求包括第一签名。
应理解,第一信息可以是起始节点产生的指令信息,使得终点节点执行指令信息指示的操作;或者,第一信息可以是起始节点需要的获取信息,使得终点节点反馈相应的获取信息。
示例性地,在车内通信***中,起始节点产生的指令信息可以是车门控制指令信息等,起始节点需要的获取信息可以是车速信息等。
在第一节点为起始节点时,第一信息为第一节点产生的指令信息或者为第一节点需要的获取信息;在第一节点为非起始节点时,第一信息可以是从起始节点,沿着调用链传输至第一节点,再通过第一请求发送至第二节点的指令信息或获取信息。
其中,在第一节点为起始节点时,第一签名可以理解为第一节点的节点签名,也就是是第一节点使用第一节点的私钥生成的节点签名。在第一节点为非起始节点时,第一签名可以用于指示第一节点及第一节点之前的节点对应的节点签名。也就是,第一签名可以包括第一节点及第一节点之前的节点的多个节点签名。第一签名也可以是一个单签名,该单 签名用于指示第一节点及第一节点之前的节点对应的节点签名。
S220,在第一签名校验通过的情况下,根据第一签名和第二签名,确定第三签名,第二签名是通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。
应理解,第二签名可以为第二节点的节点签名,也就是,第二签名可以是第二节点对签名对象(例如,第一调用链信息)进行签名得到的。
作为一种可能的实现方式,第二签名还可以是通过对第一调用信息和第一新鲜值签名得到的。其中,第一信息新鲜值用于指示第一调用链信息的实时性。
其中,第一调用链信息还可以理解为用于指示第一信息在第二节点中的调用链信息。也就是,第一调用链信息用于指示在第二节点中请求第一信息的路径信息。
示例性地,第一调用链信息可以用于指示在第二节点中第一信息相关的起始节点,在第一节点为起始节点时,第一调用链信息可以包括起始节点信息,例如,起始节点信息为第一节点的身份标识。
示例性地,第一调用链信息可以用于指示在第二节点中第一信息相关的起始节点至本节点的调用链,在第一节点为起始节点时,第一调用链信息可以包括第一节点信息和第二节点信息,例如,第一节点的身份标识和第二节点的身份标识。
示例性地,第一调用链信息可以用于指示第二节点中第一信息相关的起始节点至本节点以及本节点的下游节点的调用链。在第一节点为起始节点时,第一调用链信息可以包括第一节点信息、第二节点信息和第三节点信息,例如,第一节点的身份标识、第二节点的身份标识和第三节点的身份标识。
作为一种可能的实现方式,第三签名包括第一签名和第二签名。具体的解释将结合图4详细说明。
作为一种可能的实现方式,将第一签名和第二签名进行累乘,得到第三签名。或者,基于椭圆曲线,整合第一签名和第二签名,得到第三签名。其中,第一调用链信息和第二调用链信息不同,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息和第二调用链信息。具体的解释将结合图5详细说明。
作为一种可能的实现方式,将第一签名和第二签名进行累乘,得到第三签名。或者,基于椭圆曲线,整合第一签名和第二签名,得到第三签名。其中,第一调用链信息和第二调用链信息相同,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息或第二调用链信息。具体的解释将结合图6详细说明。
作为一种可能的实现方式,第一请求还包括第一控制流信息,第一控制流信息包括第一节点的控制程序的运行路径,在对第一签名校验通过且对第一控制流信息校验通过的情况下,根据第一签名和第二签名,确定第三签名。
S230,第二节点向第三节点发送第二请求,第二请求包括第三签名,第二请求用于请求第一信息。
作为一种可能的实现方式,第二请求还可以包括第一新鲜值。
作为一种可能的实现方式,第二请求还可以包括第二控制流信息,第二控制流信息是第二节点通过硬件收集得到的,第二控制流信息包括第二节点的控制程序的运行路径。
S240,第三节点校验第三签名。
作为一种可能的实现方式,第三签名包括第一签名和第二签名,逐一校验第三签名中的每个签名。具体的解释将结合图4详细说明。
作为一种可能的实现方式,获取第一公钥,第一公钥包括第一节点和第二节点的公钥。根据第一公钥、第一调用链信息和第二调用链信息,校验第三签名。其中,第二调用链信息用于指示第一信息在第一节点中相关的节点信息,第二请求还包括第一调用链信息和/或第二调用链信息。
在第一调用链信息和第二调用链信息不同的情况下,第二请求包括第一调用链信息和第二调用链信息。根据第一公钥、第一调用链信息和第二调用链信息,获得第一签名凭证。根据第三签名,获得第一待验证信息。根据第一签名凭证以及第一待验证信息,校验第三签名是否通过。具体的解释将结合图5详细说明。
在第一调用链信息和第二调用链信息相同的情况下,第二请求包括第一调用链信息或第二调用链信息。根据第一公钥,获得公钥之和。根据第一调用链信息或第二调用链信息,以及公钥之和,获得第二签名凭证。根据第三签名,获得第二待验证信息。根据第二签名凭证以及第二待验证信息,校验第三签名是否通过。具体的解释将结合图6详细说明。
在上述技术方案中,第三节点作为中间节点的下游节点在接收到请求之后会校验根据第一签名和第二签名得到的第三签名。这样,即使在第二节点被劫持后,被劫持后的第二节点向第三节点发送请求时,该请求中无第一节点的相关签名信息。因此,由于第三节点在校验签名时,无法校验到第一节点的相关签名信息,第三节点也不会无条件响应被劫持后的第二节点的请求。这样,可以进一步提高每个节点的数据传输的安全性,从而提高了全局链式请求传输的安全性。
图3是本申请实施例提供的另一种通信方法的交互示意图。图3示出的通信方法发生在第一节点、第二节点以及第三节点之间,本申请实施例并不限制通信中链式调用的节点个数,图中的3个节点仅为示例性表示。任何存在链式调用的节点都可以使用图3所示的方法。每个节点的具体的执行主体可以每个平台对应的电子设备,也可以是支持电子设备实现相应方法的芯片、芯片***或处理器,还可以是能实现全部或部分电子设备功能的逻辑模块或软件。
应理解,在图3中,第二节点为中间节点,第一节点为中间节点的上游节点,第三节点为中间节点的下游节点。在图3中的详细描述中,第一节点以初始节点为例进行详细说明,当第一节点为非初始节点时,第一节点也可以看作为中间节点。示例性地,在车内通信中,第一节点可以是图1中的T-BOX,第二节点可以是图1中的车内计算平台相关的设备,第三节点可以是图1中网关。
S310,第一节点确定第一请求,第一请求用于请求第一信息。第一请求包括第一签名。
示例性地,在车内通信场景中,第一信息可以为远程控制服务,或远程诊断服务等服务。本申请实施例对请求的具体请求的服务的类型不作限定。
作为一种可能的实现方式,在第一节点为调用链的初始节点时,第一签名可以为第一节点通过对第二调用链信息进行签名得到的。第一请求还可以包括第二调用链信息。
应理解,第二调用链信息用于指示第一信息在第一节点中相关的节点信息。也就是,第二调用链信息用于指示第一信息在第一节点中的调用链信息。
示例性地,第二调用链信息可以用于指示在第一节点中第一信息相关的起始节点,在 第一节点为起始节点时,第二调用链信息可以包括第一节点信息,例如,第一节点的身份标识。
示例性地,第二调用链信息可以用于指示在第一节点中第一信息相关的起始节点至本节点的下游节点的调用链,在第一节点为起始节点时,第二调用链信息包括第一节点信息和第二节点信息,例如,第一节点的身份标识和第二节点的身份标识。
在第一节点为调用链的初始节点的情况下,第一签名还可以理解为第一节点的节点签名。
具体地,第一节点使用第一节点的私钥对第二调用链信息进行签名,得到第一签名。
应理解,第一节点的私钥可以为第一节点生成的私钥,或者第一节点对应的平台的设备级私钥。
可选地,上述方式中的第一签名还可以是第二节点通过对第二调用链信息和第二新鲜值使用第二节点的私钥进行签名得到的。第一请求包括第二调用链信息、第二新鲜值和第一签名。
其中,第二新鲜值用于表示第二调用链信息的实时性。例如,第二新鲜值可以是第一节点通过时间戳校验模式生成,或者还可以通过帧计数器校验模式生成。
这样,在第一请求包括第二新鲜值的情况下,可以有效防止服务调用信息的仿冒、篡改和重放,进一步提高了请求的安全性。
可选地,上述方式中的第一签名还可以是第一节点通过对第二调用链信息、第二新鲜值和第一控制流信息使用第一节点的私钥进行签名得到的。第一请求包括第二调用链信息、第二新鲜值、第一控制流信息和第一签名。
其中,第一控制流信息包括第一节点的控制程序的运行路径,也就是,第一控制流信息用于指示第一节点的控制流图对应的程序的运行路径。例如,第一节点请求第一信息的程序的运行路径信息。
S320,第一节点向第二节点发送第一请求,第二节点接收来自第一节点的第一请求。
S330,第二节点校验第一调用请求请求的第一签名。
作为一种可能的实现方式,在第一节点为初始节点的情况下,第二节点根据第一节点的公钥和第一请求,对第一签名进行校验。其中,第一节点的公钥可以是第一节点提前获得。
具体地,第二节点根据第一节点的公钥和第一签名,得到第三待验证信息;第二节点根据第一请求中的第二调用链信息,或者第二调用链信息和第二新鲜值,或者第二调用链信息、第二新鲜值和第一控制流信息,得到第三签名凭证;根据第三待验证信息和第三签名凭证,校验第一签名是否通过。
示例性地,第三签名凭证可以是通过对上述信息进行哈希运算,得到的哈希散列值。
S340,判断第一签名是否检验通过。
作为一种可能的实现方式,如果第三待验证信息和第三签名凭证相同,那么第一签名校验通过。
作为一种可能的实现方式,如果第三待验证信息和第三签名凭证不同,那么第一签名校验不通过。
在第一签名校验成功并且第一请求包括第一控制流信息的情况下,执行S350,第二 节点校验第一控制流信息。具体的控制流信息的校验过程将结合图8具体说明。
在第一签名校验成功并且第一控制流信息校验成功的情况下,执行S360,第二节点确定第二请求,第二请求包括第三签名。
作为一种可能的实现方式,第二节点根据第一签名和第二签名,确定第三签名。
其中,第二签名是通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息。第一调用链信息为第一节点中与所述第一信息相关的调用链信息。
关于第一调用链信息的详细解释可以参考S220,在此不做赘述。
可选地,第二签名还可以是第二节点通过对第一调用链信息和第一新鲜值进行签名得到的。
其中,第一新鲜值为表示第一调用链信息的实时性。具体的第一新鲜值的生成方式可以参考第二新鲜值,在此不做赘述。
可选地,第二签名还可以是第二节点通过第一调用链信息、第一新鲜值和第二控制流信息进行签名得到的。
其中,第二控制流信息包括第二节点的控制程序的运行路径,也就是,第二控制流信息用于指示第二节点的控制流图对应的程序的运行路径。例如,第二节点请求第一信息的程序的运行路径信息。第二控制流信息可以是第二节点通过硬件收集得到的。
作为一种可能的实现方式,第三签名包括第一签名和第二签名。
应理解,在图3中第一节点为初始节点为例,也就是第三签名中包括第一签名和第二签名这两个签名信息。
具体地,第二节点使用第二节点的私钥进行签名的签名对象可以和第一节点使用第一节点的私钥进行签名的签名对象不同,第二节点使用第二节点的私钥进行签名的签名对象可以和第一节点使用第一节点的私钥进行签名的签名对象相同。也就是,在该实现方式中,并不限制每个节点使用各自私钥进行签名的签名对象相同或者不同。
需要说明的是,如果第一节点为非初始节点,那么第一签名包括第一节点及第一节点之前的所有上游节点的节点签名,此时,第三签名包括第二签名和第二节点之前的所有上游节点的节点签名的多个节点签名。
作为一种可能的实现方式,第二节点整合第一签名和第二签名,得到单个签名作为第三签名。其中,第一签名也可以是第一节点通过整合第一节点及第一节点以前的所有节点的节点签名得到的单签名。
也就是,在该实现方式中,第一签名为单个签名,第三签名也为单个签名。在图3中第一节点为初始节点时,第一签名为第一节点的节点签名。在第一节点为非初始节点时,第一签名为第一节点和第一节点之前所有节点的节点签名整合后的单个签名。
应理解,第二请求还包括第一调用链信息和/或第二调用链信息,第一调用链信息和第二调用链信息可以不同,或者第一调用链信息和第二调用链信息可相同。其中,在第一节点为初始节点时,第二调用链信息的相关解释可以参考S310。在第一节点为非初始节点时,第二调用链信息包括第一节点及第一节点之前的节点中与第一信息相关的调用链信息。
例如,在图3中第一节点为初始节点,并且第一调用链信息和第二调用链信息不同时, 例如,第一调用链信息包括第一节点、第二节点以及第三节点的身份标识,第二调用链信息包括第一节点和第二节点的身份标识。
又如,在图3中第二节点为初始节点,并且第一调用链信息和第二调用链信息相同时,第一调用链信息和第二调用链信息均包括第一节点的身份标识。
需要说明的是,具体整合第一签名和第二签名的方式将在图5和图6中详细说明。
S370,第二节点向第三节点发送第二请求,第三节点接收来自第二节点的第二请求,第二请求包括第三签名。
S380,第三节点校验第三签名。
作为一种可能的实现方式,第三签名包括第一签名和第二签名,逐一校验第三签名中的每个签名。更具体的实现方式将结合图4进行说明。
作为一种可能的实现方式,第三签名为第二节点整合第一签名和第二签名得到的单签名,根据第一公钥、第一调用链信息和第二调用链信息,校验第三签名。
在第一调用链信息和第二调用链信息相不同时,第三节点根据第一公钥、第一调用链信息和第二调用链信息,获得第一签名凭证;根据第三签名,获得第一待验证信息;根据第一签名凭证以及第一待验证信息,校验第三签名是否通过。详细的校验过程将结合图5说明。
在第一调用链信息和第二调用链信息相相同时,根据第一公钥,获得公钥之和;根据公钥之和,以及第一调用链信息和第二调用链信息,获得第二签名凭证;根据第三签名,获得第二待验证信息;根据第二签名凭证以及第二待验证信息,校验第三签名是否通过。详细的校验过程将结合图6说明。
其中,第一公钥包括第二节点及第二节点之前的所有节点的公钥,在图3中,第二节点为初始节点,第一公钥包括第一节点的公钥和第二节点的公钥。
可选地,在第二请求包括第二控制流信息的情况下,在校验第三签名成功之后,第三节点校验第二控制流信息是否正确。
作为一种可能的实现方式,在第三签名和第二控制信息校验通过的情况下,第三节点根据第三签名和第四签名,确定第五签名,第四签名是通过对第三调用链信息进行签名得到的,第三调用链信息用于指示所述第一信息在所述第三节点中相关的节点信息;向第四节点发送第三请求,第三请求包括第五签名,第三请求用于请求第一信息。
其中,第三调用链信息还可以理解为第三节点中与第一信息相关的调用链信息,更详细的第三调用链信息的解释和第一调用链信息类似,可以参考S220中第一调用链信息的相关描述。
作为一种可能的实现方式,在第三签名和第二控制信息校验通过的情况下,第三节点可以根据第二请求,响应第一信息。
例如,第三节点可以执行第一信息指示的操作,或者,第三节点可以反馈第一信息对应的起始节点需要调用的信息。
在上述技术方案中,第三节点作为中间节点的下游节点在接收到请求之后会校验的第三签名是根据第一签名和第二签名得到的。这样,即使在第二节点被劫持后,被劫持后的第二节点向第三节点发送请求时,该请求中无第一节点的相关签名信息。因此,由于第三节点在校验签名时,无法校验到第一节点的相关签名信息,第三节点也不会无条件响应被 劫持后的第二节点的请求。这样,可以进一步提高每个节点的数据传输的安全性,从而提高了全局链式调用请求传输的安全性。
下面将结合图4至图6详细说明通信方法中每个节点校验签名的具体方式。
图4是本申请实施例提供的又一种通信方法的示意图。图4以链式传输中前三个节点为例进行详细说明该方法。图4所示的第1个节点对应于图3所示的第一节点,第2个节点对应于图3所示的第二节点,第3个节点对应于图3所示的第三节点。应理解,图4所示的第1个节点、第2个节点以及第3个节点的相关解释说明可以参考图3中相关描述,在此不做赘述。
S410,第1个节点根据第1个节点的私钥A和调用链信息A,生成签名A。
作为一种可能的实现方式,第1个节点根据私钥A对调用链信息A进行签名,生成签名A。
应理解,调用链信息A用于指示第一信息在第1个节点中相关的节点信息,也就是调用链信息A为第1个节点中与第一信息相关的调用链信息。例如,调用链信息A表示第一信息起始于第1个节点,此时,调用链信息A包括第1个节点的节点身份标识。或者,调用链信息A表示第1个节点通过第2个节点请求第一信息,调用链信息A包括第1个节点和第2个节点的节点身份标识。
第一信息可以为针对具体服务指令。例如,在车内通信的远程诊断场景中,如图1所示,当需要诊断制动***ECU的情况时,第一信息可以是制动信号的服务调用信息。
例如,在车内通信的远程诊断场景中,如图1所示,当需要诊断制动***ECU的情况时,完整的调用链为第1个节点为T-BOX,第2个节点为车内计算平台,第3个节点为网关,第4个节点为车内控制域,第5个节点为制动***中的ECU。调用链信息A可以为T-BOX通过车内计算平台调用制动***的ECU信息的调用链。或者,调用链信息A可以为调用制动***的ECU信息起始于T-BOX节点。
具体地,首先,对调用链信息A进行哈希运算,得到哈希值A;随后,使用第1个节点的私钥A对哈希值A签名,得到签名A。
可选地,签名A还可以通过对调用链信息A和新鲜值A,使用私钥A进行签名得到的。
新鲜值A用于表示调用链信息A的实时性,新鲜值A可以是第1个节点通过时间戳校验模式生成,或者还可以通过帧计数器校验模式生成。
控制流信息A为第1个节点的调用控制程序的运行路径。
S420,第1个节点确定请求A,请求A包括签名A和调用链信息A。
可选地,请求A还包括新鲜值A。
S430,第1个节点向第2个节点发送请求A,第2个节点接收来自第1个节点的请求A。
S440,第2个节点校验请求A中的签名A。
作为一种可能的实现方式,根据第1个节点的公钥A和调用链信息A,校验签名A。
具体地,首先,第2个节点使用第1个节点的公钥A对签名A解密,得到哈希值A;第2个节点对调用链信息A进行哈希运算,得到哈希值A’。随后,第2个节点比较哈希值A和哈希值A’。如果哈希值A等于哈希值A’,那么签名A校验成功,第2个节点可 以确定请求A的来自于第1个节点。如果哈希值A不等于哈希值A’,那么签名A校验失败。
作为一种可能的实现方式,根据第1个节点的公钥A、调用链信息A和新鲜值A,校验签名A。
具体过程和上述可能的实现方式类似,在得到哈希值A’的步骤中,第2个节点对调用链信息A和新鲜值A进行哈希运算,得到哈希值A’。
应理解,第2个节点提前获得第1个节点的公钥A,并且提前获知第1个节点的私钥A的签名对象。
在签名A校验成功的情况下,S450,第2个节点根据第2个节点的私钥B和调用链信息B,生成签名B。
作为一种可能的实现方式,第2个节点根据私钥B对调用链信息B进行签名,生成签名B。
具体地,首先,对调用链信息B进行哈希运算,得到哈希值B;随后,使用第2个节点的私钥B对哈希值B签名,得到签名B。
可选地,第2个节点还可以使用私钥B对调用链信息B和新鲜值B进行签名,生成签名B。
新鲜值B用于表示调用链信息B的时效性,具体的获得方式和新鲜值A类似。或者,新鲜值B也可以表示调用链信息A的时效性,此时,新鲜值B和新鲜值A相等。
调用链信息B可以表示第1个节点通过第2个节点调用第3个节点的调用链,调用链信息B可以包括第1个节点、第2个节点和第3个节点的身份标识。
或者,调用链信息B可以表示第一信息起始于第1个节点,调用链信息B可以包括第1个节点的身份标识。在调用链信息A也包括第1个节点的身份标识时,调用链信息A和调用链信息B相同。
同样以在车内通信的远程诊断场景中为例,调用链信息B可以包括T-BOX、车内计算平台和网关的身份标识。或者,调用链信息B还包括T-BOX的身份标识。
需要说明的是,在图4所示的方法中每个节点使用私钥签名的对象可以是相同的。例如,在调用链信息A和调用链信息B相同,并且新鲜值B和新鲜值A相等的情况下,那么在该方法中第1个节点和第2个节点的使用各自私钥签名的对象是相同的。或者,在该方法中每个节点使用各自私钥签名的对象也可以是不同的。
S460,第2个节点确定请求B,请求B包括签名A、签名B、调用链信息A和/或调用链信息B。
可选地,请求B包括签名A、签名B、调用链信息A和/或调用链信息B,以及新鲜值A和/或新鲜值B。
应理解,当调用链信息A和调用链信息B相同时,请求B包括签名A、签名B、调用链信息A和新鲜值A。或者,请求B包括签名A、签名B、调用链信息B和新鲜值B。由于调用链信息A和调用链信息B相同,因此新鲜值A和新鲜值B也相同。
应理解,S460中的签名A和签名B可以看做是S360中第三签名中包括的具体的两个签名。
S470,第2个节点向第3个节点发送请求B,第3个节点接收来自第2个节点的请求 B。
S480,第3个节点校验请求B中的签名A和签名B。
作为一种可能的实现方式,第3个节点根据第1个节点的公钥A、第2个节点的公钥B、调用链信息A和调用链信息B,校验签名A和签名B。
具体地,第3个节点分别通过第1个节点的公钥和调用链信息A,校验签名A;通过第2个节点的公钥和调用链信息B,校验签名B。具体的校验方式可以参考S440,在此不做赘述。
可选地,在签名A和签名B校验通过之后,方式一,当第3个节点不是响应第一信息的终点节点,和第一信息相关的请求可以沿链式节点继续传递下去,直至传输到响应第一信息的终点节点。第3个节点以后的节点校验签名的方式可以参考图4所示的方法中的第3个节点的相关方法。第3个节点以后的节点确定请求的方式,可以参考图4所示的方法中的第2个节点的相关方法。
可选地,在签名A和签名B校验通过之后,方式二,当第3个节点是响应第一信息的终点节点,根据请求B,响应第一信息。
在上述技术方案中,第三签名中包括多个节点对应的签名,可以简单高效地提高了全局链式调用请求传输的安全性。
上述方法可以适用于每个节点使用私钥签名的信息不同或者相同的情况,而针对每个节点签名的信息不同时,还可以有另外一种校验方法,具体将结合图5详细描述。针对每个节点签名的信息相同时,还可以有另外一种校验方法,具体将结合图6详细描述。
图5是本申请实施例提供的再一种通信方法的示意图。图5以链式传输中前三个节点为例进行详细说明该方法。同理,图5所示的第1个节点对应于图3所示的第一节点,第2个节点对应于图3所示的第二节点,第3个节点对应于图3所示的第三节点。图5所示的第1个节点、第2个节点以及第3个节点的相关解释说明可以参考图3中相关描述,在此不做赘述。
S510,第1个节点根据第1个节点的私钥A和调用链信息A,生成签名A。
应理解,S510和S410类似,相关描述可以参考S410,在此不做赘述。
还应理解,在图5所示的方法中,调用链信息A用于指示在第1个节点中第1个节点通过第2个节点请求第一信息的调用链信息,调用链信息A包括第1个节点和第2个节点的身份标识。
S520,第1个节点确定请求A,请求A包括签名A和调用链信息A。
可选地,请求A还包括新鲜值A。
S530,第1个节点向第2个节点发送请求A,第2个节点接收来自第1个节点的请求A。
S540,第2个节点校验请求A中的签名A。
应理解,S540中校验签名A的方式和S440类似,可参考S440,在此不做赘述。
在签名A校验成功的情况下,S550,第2个节点根据第2个节点的私钥B和调用链信息B,生成签名B。
应理解,S540中校验签名A的方式和S450类似,可参考S450,在此不做赘述。S550中生成签名B的方式和S450类似,可参考S450,在此不做赘述。
需要说明的是,在图5所示的方法中,每个节点使用私钥签名的对象是不同的,也就是哈希运算的对象是不同的。调用链信息B为第2个节点中和第一信息相关的调用链信息。例如,调用链信息B用于指示第2个节点向第3个节点请求第1个节点对应的第一信息的调用链信息,调用链信息B包括第1个节点、第2个节点和第3个节点的身份标识。
也就是,在图5所示的方法中,调用链信息A和调用链信息B不同。
S560,第2个节点根据签名A和签名B,生成第三签名。
作为一种可能的实现方式,整合签名A和签名B,得到第三签名。具体的整合方式可以是通过累乘签名A和签名B得到的。或者,基于椭圆曲线Ed25519的EdDSA,整合签名A和签名B,得到第三签名。本申请实施例对整合每个节点的节点签名不作限制。
S570,第2个节点确定请求B,请求B包括第三签名、调用链信息A和调用链信息B。
可选地,请求B包括第三签名、调用链信息A、新鲜值A、调用链信息B和新鲜值B。
S580,第2个节点向第3个节点发送请求B,第3个节点接收来自第2个节点的请求B。
S590,第3个节点校验请求B中的第三签名。
作为一种可能的实现方式,第3个节点根据第1个节点的公钥A、第2个节点的公钥B、调用链信息A和调用链信息B,校验第三签名。
具体地,第3个节点根据公钥A和调用链信息A,生成签名凭证A;根据公钥B和调用链信息B,生成签名凭证B;将签名凭证A与签名凭证B的和,作为第一签名凭证。第3个节点根据第三签名,得到第一待验证信息。根据第一签名凭证和第一待验证信息,校验第三签名。
示例性地,在第一签名凭证和第一待验证信息相同时,第三签名校验通过。在第一签名凭证和第一待验证信息不同时,第三签名校验不通过。
可选地,在第三签名校验通过之后,方式一,当第3个节点不是响应第一信息的终点节点,和第一信息相关的请求可以沿链式节点继续传递下去,直至传输到响应第一信息的终点节点。第3个节点以后的节点校验签名的方式可以参考图5所示的方法中的第3个节点的相关方法。第3个节点以后的节点确定请求的方式,可以参考图5所示的方法中的第2个节点的相关方法。
可选地,在第三签名校验通过之后,方式二,当第3个节点是响应第一信息的终点节点,根据请求B,响应第一信息。
在上述技术方案中,请求中的签名为多个节点对应的签名整合后的单签名,在提高了全局链式请求传输的安全性的同时,还节省了请求的传输带宽。
图6是本申请实施例提供的一种通信方法的示意图。图6以链式传输中前三个节点为例进行详细说明该方法。应理解,同理,图6所示的第1个节点对应于图3所示的第一节点,第2个节点对应于图3所示的第二节点,第3个节点对应于图3所示的第三节点。图6所示的第1个节点、第2个节点以及第3个节点的相关解释说明可以参考图3中相关描述,在此不做赘述。
S610,第1个节点根据第1个节点的私钥A和调用链信息A,生成签名A。
应理解,S610和S410类似,相关描述可以参考S410,在此不做赘述。
还应理解,在图6所示的方法中,调用链信息A可以用于指示第一信息相关的节点为 第1个节点。也就是调用链信息A用于指示第一信息的调用链的起始节点为第1个节点。调用链信息A包括第1个节点的身份标识
S620,第1个节点确定请求A,请求A包括签名A和调用链信息A。
可选地,请求A还包括新鲜值A。
S630,第1个节点向第2个节点发送请求A,第2个节点接收来自第1个节点的请求A。
S640,第2个节点校验请求A中的签名A。
应理解,S640中校验签名A的方式和S440类似,可参考S440,在此不做赘述。
在签名A校验成功的情况下,S650,第2个节点根据第2个节点的私钥B和调用链信息A,生成签名B。
作为一种可能的实现方式,第2个节点根据私钥B对调用链信息A进行签名,生成签名B。
具体地,第2个节点可以对调用链信息A做哈希运算得到的哈希值A,再对哈希值A使用第2个节点的私钥B签名,得到签名B。或者,由于第2个节点校验签名A成功,第2个节点可以使用第1个节点的公钥解密签名A得到的哈希值A’,哈希值A等于哈希值A’,再使用第2个节点的私钥B对哈希值A’签名,得到签名B。
需要说明的是,在图6所示的方法中,每个节点使用私钥签名的对象是相同的,也就是哈希运算的对象是相同的。第1个节点的私钥A的签名对象和第2个节点的私钥B的签名对象是相同的,都可以是调用链信息A。或者,都可以是调用链信息A和新鲜值A。
S660,第2个节点根据签名A和签名B,生成第三签名。
作为一种可能的实现方式,整合签名A和签名B,得到第三签名。具体的整合方式可以是通过累乘签名A和签名B得到的。或者,基于椭圆曲线Ed25519的EdDSA,整合签名A和签名B,得到第三签名。本申请实施例对整合每个节点的节点签名不作限制。
S670,第2个节点确定请求B,请求B包括第三签名和调用链信息A。
可选地,请求B包括第三签名、调用链信息A和新鲜值A。
S680,第2个节点向第3个节点发送请求B,第3个节点接收来自第2个节点的请求B。
S690,第3个节点校验请求B中的第三签名。
作为一种可能的实现方式,第3个节点根据第1个节点的公钥A、第2个节点的公钥A和调用链信息A,校验第三签名。
具体地,第3个节点将公钥A与公钥B的和,作为公钥之和;再根据公钥之和,以及调用链信息A,得到第二签名凭证;根据第三签名,得到第二待验证信息。根据第一签名凭证和第一待验证信息,校验第三签名。
示例性地,在第二签名凭证和第二待验证信息相同时,第三签名校验通过。在第二签名凭证和第二待验证信息不同时,第三签名校验不通过。
可选地,在第三签名校验通过之后,方式一,当第3个节点不是响应第一信息的终点节点,和第一信息相关的请求可以沿链式节点继续传递下去,直至传输到响应第一信息的终点节点。第3个节点以后的节点校验签名的方式可以参考图6所示的方法中的第3个节点的相关方法。第3个节点以后的节点确定请求的方式,可以参考图6所示的方法中的第 2个节点的相关方法。
可选地,在第三签名校验通过之后,方式二,当第3个节点是响应第一信息的终点节点,根据请求B,响应第一信息。
在上述技术方案中,每个节点生成各自节点的签名对象是相同的,并且节点之间传输的请求中的签名为多个节点对应的签名整合后的单签名,在提高了全局链式请求传输的安全性,并且节省了请求的传输带宽的同时,还节省了算力。
对于每个节点的私钥和公钥,有两种可能的实现方式。
第一种,每个节点具有自己的公私密钥对。例如,图4至图6中所示的公私密钥对属于这种情况。
第二种,在每个节点对应的设备具有设备级公私密钥对,每个节点可以基于设备级公私密钥对生成预共享密钥(pre-shared key,PSK),再基于PSK生成服务级密钥。其中,每个节点的服务级密钥相同。随后,通过消息验证码(message authentication code,MAC)来实现调用链的完整性保护,也就是,通过每个节点相同的服务级密钥,对第一信息进行加密。其中,消息验证码可以是通过基于哈希的消息验证码(hash-based message authentication code,HMAC)或基于分组加密的消息认证码(cipher block chaining-message authentication code,CMAC)等消息验证码算法得到的,本申请对此不作限制。最后,为了实现图4至图6中所示的第3个节点对第1个节点和第2个节点的身份的认证,每个调用链上的节点可以使用设备级私钥对消息验证码MAC进行签名。具体的签名方式可以参考图4至图6。
这样,通过设备级的公私钥对,每个节点无需生成自己独立的公私密钥对,相同的服务级密钥可以简化消息验证码的生成和校验,这样可以降低每个节点对应的设备的安全存储能力的需求。
在上述技术方案中,第三节点作为中间节点的下游节点在接收到请求之后会校验根据第一签名和第二签名确定的第三签名。与此同时,第一请求中的第二新鲜值,可以有效防止第一请求的仿冒、篡改和重放。即使调用链的第二节点(也就是调用链中的中间节点)被劫持,当被劫持的第二节点向第三节点发送第二请求时,由于第三节点无法验证到第一节点的签名。因此,通过本申请实施例的方案,可以有助于及时发现中间节点被攻击以及防止对中间节点的攻击向下级节点扩散。
以车内通信为例,图7是本申请实施例提供的一种车内调用链示意图。
如图7所示,车内调用链的节点的第1个节点可以是T-BOX710,第2个节点可以是车内计算平台720,以及第3个节点可以是网关730,具体的网关类型可以是分布式网关。以这3个节点为例,可以实现对智能网联车的远程控制和远程诊断。本申请实施例的方案也可以适用于其他调用链,本申请仅以远程控制服务/应用,以及远程诊断服务/应用为例进行详细说明通信方法。
其中图7中所示的实线调用链为远程控制调用链,虚线调用链为远程诊断调用链。下面分别以远程控制调用链和远程诊断调用链来说明中间节点校验调用链完整性的过程。
应理解,图7所示的每个节点的远程控制应用/服务,和远程诊断应用/服务为每个节点的软件模块。
例如,远程控制应用/服务711请求的第一信息可以是第一控制信息。例如,第一控 制信息用于指示终点节点对应的控制服务模块或控制应用模块执行相应操作,或者第一控制信息用于指示从终点节点对应的控制服务模块或应用控制模块获取信息。校验远程控制调用链的完整性的具体步骤如下。
第一步,TBOX 710中的远程控制应用/服务711,通过4G/5G接收来自车外的远程控制信号。
第二步,远程控制应用/服务711根据远程信号,确定第一控制请求,并将该第一控制请求,基于车载以太网协议COME/IP,通过AUTOSAR自适应平台(automotive open system architecture adaptive platform,AUTOSAR AP)发送给车内计算平台720中的远程控制应用/服务721。具体确定第一控制请求可以参考图4至图6中第1个节点的确定请求A的方式。
第三步,远程控制应用/服务721,校验第一控制请求中的第一签名,具体的校验方式可以参考图4至图6中第2个节点的校验方式。在校验通过之后,远程控制应用/服务721,确定第二控制请求,并将第二控制请求,基于车载以太网协议COME/IP,通过AUTOSAR AP发送给网关730中的远程控制应用/服务731。第二控制请求包括第三签名,第三签名用于指示T-BOX和车内计算平台的签名。第三签名具体的生成方式,可以参考图4至图6中第2个节点的第三签名的生成方式。
第四步,远程控制应用/服务731,校验第二控制请求中的第三签名,具体的校验方式可以参考图4至图6中第3个节点的校验方式。如果检验通过,远程控制应用/服务731可以确定新的请求,并将请求发送给下一个节点,新的请求中包括的签名指示了T-BOX710、车内计算平台720以及网关730分别生成的节点签名。或者,如果校验通过,远程控制应用/服务731还可以根据第二控制请求,响应第一控制服务。
又如,远程诊断应用/服务712请求的第一信息可以是第一诊断信息。校验远程诊断调用链的完整性的具体步骤和上述校验远程诊断调用链的完整性是类似的。下面将结合图7具体说明,在第2个节点车内计算平台720被劫持之后,通过本申请中的通信方法可以有效提高安全性的具体过程。
当第2个节点车内计算平台720被劫持之后,车内计算平台720的远程控制应用/服务722,向网关730的远程控制应用/服务732发送第二诊断请求。当网关730的远程控制应用/服务732在校验第二诊断请求中的第三签名时,由于第三签名无法指示T-BOX的签名,因此,第三签名无法通过校验,进而第二诊断请求中的诊断信息的请求也不被允许,如图7所示。
下面将结合图8详细说明在车内通信中局部控制流信息的校验过程。
图8是本申请实施例提供的一种车内远程诊断调用链安全校验方法800的示意图。
图8以第1个节点为T-BOX810,第2个节点为车内计算平台820,第3个节点为网关830为例进行说明。其中,预定义的调用链为T-BOX810通过车内计算平台820请求网关830的远程诊断信息。
S1,T-BOX810在可信执行环境(trusted execution environment,TEE)812中确定第一诊断请求。
其中,第一诊断请求包括第一控制流信息、第二新鲜值、第二调用链信息和第一签名。
第一控制流信息可以是根据T-BOX的硬件收集得到的,第一控制流信息用于指示 T-BOX的第一控制流图对应的程序的运行路径。
这样,直接通过节点具体的硬件来收集第一控制流信息,不需要软件模块去收集第一控制流信息,可以降低时延。
第二新鲜值和第二调用链信息的相关解释可以参考S310,在此不做赘述。
例如,第一签名可以是T-BOX810在TEE 812中使用T-BOX的私钥对第一控制流信息、第一新鲜值和第一调用链信息进行签名得到的。第一签名可以是图4至图6中所示的签名A,更加具体的实现方式可以参考图4至图6。
S2,T-BOX 810的远程诊断应用811,将第一诊断请求发送给车内计算平台820的远程诊断应用821。
示例性地,T-BOX 810的远程诊断应用811,可以通过车载以太网(例如,COME/IP),将第一诊断请求发送给车内计算平台820的远程诊断应用821。
S3,车内计算平台820在TEE822中校验第一签名。
应理解,第一签名可以是图4至图6中所示的签名A,更加具体的实现方式,可以参考图4至图6中第2个节点校验签名A的方式。
在第一签名校验通过之后,S4,车内计算平台820在TEE822中校验第一控制流信息。
应理解,车内计算平台820提前获得T-BOX810的第一控制流图。
示例性地,车内计算平台820根据提前获得的第一控制流图,得到第一检验控制流信息,随后,通过比较第一控制流信息和第一校验控制流信息,来判断第一控制流信息是否校验成功。
这样,在第一请求中加入了上游节点的控制流信息,可以有效防止和发现程序代码复用攻击,例如,面向返回的编程ROP或跳转导向编程JOP。
在第一控制流信息校验成功的情况下,S5,车内计算平台820在TEE822中验证T-BOX810的调用权限。
作为一种可能的实现方式,车内计算平台820在TEE822中通过身份与访问管理(identity and access management,IAM)模块,验证T-BOX 810的调用权限。
在T-BOX的调用权限校验通过的情况下,S6,车内计算平台820在TEE822中确定第二诊断请求,第二诊断请求包括第三签名,第三签名用于指示T-BOX的签名和车内计算平台的签名。
第二诊断请求还包括第一新鲜值、第二调用链信息、第二新鲜值和第一调用链信息。或者第二诊断请求还包括第二新鲜值和第二调用链信息。针对第二新鲜值、第二调用链信息、第一新鲜值和第一调用链信息,详细描述可以参考图3。
第二诊断请求包括第二控制流信息,第二控制流信息可以是根据车内计算平台的硬件收集得到的,第二控制流信息用于指示车内计算平台的第二控制流图对应的程序的运行路径。
S7,车内计算平台820的远程诊断应用821,将第二诊断请求发送给网关830的远程诊断应用831。
示例性地,车内计算平台820的远程诊断应用821,可以通过车载以太网(例如,COME/IP),将第二诊断请求发送给网关830的远程诊断应用831。
S8,网关830在TEE832中校验第三签名。
应理解,第三签名可以是图4中所示的签名A和签名B,或者第三签名可以是图5和图6中的具体实现方式,可以参考图4至图6。
在第三签名校验通过之后,S9,网关830在TEE 832中校验第二控制流信息。
具体校验第二控制流信息的方式,可以参考S3中校验第一控制流信息的方式。
在第二控制流信息校验成功的情况下,S10,网关830在TEE 832中验证T-BOX 810和车内计算平台820的调用权限。
作为一种可能的实现方式,网关830在TEE832IAM模块,验证T-BOX 810和车内计算平台820的调用权限。
可选地,在调用权限验证通过之后,当网关830为不是远程诊断信息对应的终点节点,和远程诊断信息相关的诊断请求可以沿链式节点继续传递下去,直至传输到响应远程诊断信息的终点节点。
可选地,在调用权限验证通过之后,当网关830为是诊断信息对应的终点节点,根据第二诊断请求,响应远程诊断信息。
上述内容为本申请实施例的通信方法,下面将结合图14和图15对节点做详细说明。应理解,装置实施例的描述和方法实施例的描述相互对应。因此,未详细描述的内容可以参见上文方法实施例,为了简洁,在此不作赘述。
图9是本申请实施例提供的一种节点的示意图。该节点900包括:通信单元901和处理模块902。,
当节点900为中间节点,也就是第二节点时,通信单元901用于,接收来自第一节点的第一请求,第一请求用于请求第一信息,第一信息为与起始节点相关的信息,第一请求包括第一签名。
处理单元902用于,在第一签名校验通过的情况下,根据第一签名和第二签名,确定第三签名,第二签名是通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。
通信单元901用于,向第三节点发送第二请求,第二请求包括第三签名,第二请求用于请求第一信息。
当节点900为中间节点的下游节点,也就是第三节点时,通信单元901用于,接收来自第二节点的第二请求,第二请求包括第三签名,第二请求用于请求第一信息,第一信息为与起始节点相关的信息。
处理单元902用于,校验第三签名,其中,第三签名为第二节点根据第一签名和第二签名确定的,第一签名来自第一节点的第一请求,第二签名是第二节点通过对第一调用链信息进行签名得到的,第一调用链信息用于指示第一信息在第二节点中相关的节点信息,第一调用链信息包括起始节点信息。
应理解,上述内容仅是一种示例性描述,该节点是用于执行前述方法实施例所提及的方法或者步骤,因此,该节点与前述的方法实施例是对应的。具体内容可以参考前述方法实施例的描述,在此不再赘述。
图10是本申请实施提供的一种节点的硬件结构示意图。图10所示的节点1000可以包括:存储器1010、处理器1020、以及通信接口1030。其中,存储器1010、处理器1020,通信接口1030通过内部连接通路相连,该存储器1010用于存储指令,该处理器1020用 于执行该存储器1020存储的指令,以控制输入/输出接口1030接收/发送第二信道模型的至少部分参数。可选地,存储器1010既可以和处理器1020通过接口耦合,也可以和处理器1020集成在一起。
需要说明的是,上述通信接口1030使用例如但不限于收发器一类的收发装置,来实现通信设备1000与其他设备或通信网络之间的通信。上述通信接口1030还可以包括输入/输出接口(input/output interface)。
在实现过程中,上述方法的各步骤可以通过处理器1020中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1010,处理器1020读取存储器1010中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
应理解,本申请实施例中,该处理器可以为中央处理单元CPU,该处理器还可以是其他通用处理器、数字信号处理器DSP、专用集成电路ASIC、现成可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解,本申请实施例中,该存储器可以包括只读存储器和随机存取存储器,并向处理器提供指令和数据。处理器的一部分还可以包括非易失性随机存取存储器。例如,处理器还可以存储设备类型的信息。
应理解,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
本申请实施例还提供了一种节点,该节点包括处理单元和存储单元,其中存储单元用于存储指令,处理单元执行存储单元所存储的指令,以使该节点执行上述通信方法。
本申请实施例还提供一种移动载体,包括上述节点900或节点1000。该移动载体可以是车辆。
本申请实施例还提供一种计算机可读介质,所述计算机可读介质存储有程序代码,当所述计算机程序代码在计算机上运行时,使得所述计算机执行上述图2至图8中的任一种方法。
本申请实施例还提供了一种计算机程序产品,所述计算机程序产品包括:计算机程序代码,当所述计算机程序代码在计算机上运行时,使得计算机执行上述方法。
本申请实施例还提供一种芯片,包括:至少一个处理器和存储器,所述至少一个处理器与所述存储器耦合,用于读取并执行所述存储器中的指令,以执行上述图2至图8中的任一种方法。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以 硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的***、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。

Claims (39)

  1. 一种通信方法,其特征在于,所述方法应用于第二节点,所述方法包括:
    接收来自第一节点的第一请求,所述第一请求用于请求第一信息,所述第一信息为与起始节点相关的信息,所述第一请求包括第一签名;
    在所述第一签名校验通过的情况下,根据所述第一签名和第二签名,确定第三签名,所述第二签名是通过对第一调用链信息进行签名得到的,所述第一调用链信息用于指示所述第一信息在所述第二节点中相关的节点信息,所述第一调用链信息包括起始节点信息;
    向第三节点发送第二请求,所述第二请求包括所述第三签名,所述第二请求用于请求所述第一信息。
  2. 如权利要求1所述的方法,其特征在于,所述第三签名包括所述第一签名和所述第二签名。
  3. 如权利要求1所述的方法,其特征在于,根据所述第一签名和所述第二签名,确定所述第三签名包括:
    将所述第一签名和所述第二签名进行累乘,得到所述第三签名;或者,
    基于椭圆曲线,整合所述第一签名和所述第二签名,得到所述第三签名;
    其中,所述第一调用链信息和第二调用链信息不同,所述第二调用链信息用于指示所述第一信息在所述第一节点中相关的节点信息,所述第二请求还包括所述第一调用链信息和所述第二调用链信息。
  4. 如权利要求1所述的方法,其特征在于,根据所述第一签名和所述第二签名,确定所述第三签名包括:
    将所述第一签名和所述第二签名进行累乘,得到所述第三签名;或者,
    基于椭圆曲线,整合所述第一签名和所述第二签名,得到所述第三签名;
    其中,所述第一调用链信息和第二调用链信息相同,所述第二调用链信息用于指示所述第一信息在所述第一节点中相关的节点信息,所述第二请求还包括所述第一调用链信息或所述第二调用链信息。
  5. 如权利要求1至4任一项所述的方法,其特征在于,所述第二请求还包括第一新鲜值,所述第一新鲜值用于指示所述第一调用链信息的实时性,所述第二签名是通过对所述第一调用链信息和所述第一新鲜值签名得到的。
  6. 如权利要求1至5任一项所述的方法,其特征在于,所述第一请求还包括第一控制流信息,所述第一控制流信息包括所述第一节点的控制程序的运行路径,
    所述在所述第一签名校验通过的情况下,根据所述第一签名和第二签名,确定第三签名包括:
    在对所述第一签名校验通过且对所述第一控制流信息校验通过的情况下,根据所述第一签名和所述第二签名,确定所述第三签名。
  7. 如权利要求6所述的方法,其特征在于,所述方法还包括:
    通过硬件收集所述第二节点的第二控制流信息,所述第二控制流信息包括所述第二节点的控制程序的运行路径,所述第二请求还包括所述第二控制流信息。
  8. 一种通信方法,其特征在于,所述方法应用于第三节点所述方法包括:
    接收来自第二节点的第二请求,所述第二请求包括第三签名,所述第二请求用于请求第一信息,所述第一信息为与起始节点相关的信息;
    校验所述第三签名,其中,所述第三签名为所述第二节点根据第一签名和第二签名确定的,所述第一签名来自第一节点的第一请求,所述第二签名是所述第二节点通过对第一调用链信息进行签名得到的,所述第一调用链信息用于指示所述第一信息在所述第二节点中相关的节点信息,所述第一调用链信息包括起始节点信息。
  9. 如权利要求8所述的方法,其特征在于,所述第三签名包括所述第一签名和所述第二签名;
    其中,所述校验所述第三签名包括:
    逐一校验所述第三签名中的每个签名。
  10. 如权利要求8所述的方法,其特征在于,所述第三签名为所述第二节点根据所述第一签名和所述第二签名累乘得到的,或基于椭圆曲线,整合所述第一签名和所述第二签名得到的;所述方法还包括:
    获取第一公钥,所述第一公钥包括所述第二节点和所述第二节点之前的节点的公钥;
    所述校验所述第三签名包括:
    根据所述第一公钥、所述第一调用链信息和第二调用链信息,校验所述第三签名;
    其中,所述第二调用链信息用于指示所述第一信息在所述第一节点中相关的节点信息,所述第二请求还包括所述第一调用链信息和/或所述第二调用链信息。
  11. 如权利要求10所述的方法,其特征在于,在所述第一调用链信息和所述第二调用链信息不同的情况下,所述第二请求包括所述第一调用链信息和所述第二调用链信息,所述根据所述第一公钥、所述第一调用链信息和所述第二调用链信息,校验所述第三签名包括:
    根据所述第一公钥、所述第一调用链信息和所述第二调用链信息,获得第一签名凭证;
    根据所述第三签名,获得第一待验证信息;
    根据所述第一签名凭证以及所述第一待验证信息,校验所述第三签名是否通过。
  12. 如权利要求10所述的方法,其特征在于,在所述第一调用链信息和所述第二调用链信息相同的情况下,所述第二请求包括所述第一调用链信息或所述第二调用链信息,根据所述第一公钥、所述第一调用链信息和所述第二调用链信息,校验所述第三签名包括:
    根据所述第一公钥,获得公钥之和;
    根据所述第一调用链信息或所述第二调用链信息,以及所述公钥之和,获得第二签名凭证;
    根据所述第三签名,获得第二待验证信息;
    根据所述第二签名凭证以及所述第二待验证信息,校验所述第三签名是否通过。
  13. 如权利要求8至12任一项所述的方法,其特征在于,所述第二请求还包括第一新鲜值,所述第一新鲜值用于指示所述第一调用链信息的实时性,所述第二签名是通过对所述第一调用链信息和所述第一新鲜值签名得到的。
  14. 如权利要求8至13任一项所述的方法,其特征在于,所述第二请求还包括第二控制流信息,所述第二控制流信息用于指示所述第二节点的控制程序的运行路径,
    在所述第三签名校验通过的情况下,所述方法还包括:
    校验所述第二控制流信息是否正确。
  15. 如权利要求8至14任一项所述的方法,其特征在于,在所述第三签名校验通过并且所述第二控制流信息校验通过的情况下,所述方法还包括:
    根据所述第三签名和第四签名,确定第五签名,所述第四签名是所述第三节点通过对第三调用链信息进行签名得到的,所述第三调用链信息用于指示所述第一信息在所述第三节点中相关的节点信息;
    向第四节点发送第三请求,所述第三请求包括所述第五签名,所述第三请求用于请求所述第一信息。
  16. 如权利要求8至14任一项所述的方法,其特征在于,在所述第三签名校验通过并且所述第二控制流信息校验通过的情况下,
    所述方法还包括:
    根据所述第二请求,响应所述第一信息。
  17. 一种节点,其特征在于,所述节点包括通信单元和处理单元:
    所述通信单元用于,接收来自第一节点的第一请求,所述第一请求用于请求第一信息,所述第一信息为与起始节点相关的信息,所述第一请求包括第一签名;
    在所述第一签名校验通过的情况下,所述处理单元用于,根据所述第一签名和第二签名,确定第三签名,所述第二签名是通过对第一调用链信息进行签名得到的,所述第一调用链信息用于指示所述第一信息在第二节点中相关的节点信息,所述第一调用链信息包括起始节点信息;
    所述通信单元还用于,向第三节点发送第二请求,所述第二请求包括所述第三签名,所述第二请求用于请求所述第一信息。
  18. 如权利要求17所述的节点,其特征在于,所述第三签名包括所述第一签名和所述第二签名。
  19. 如权利要求17所述的节点,其特征在于,所述处理单元具体用于:
    将所述第一签名和所述第二签名进行累乘,得到所述第三签名;或者,
    基于椭圆曲线,整合所述第一签名和所述第二签名,得到所述第三签名;
    其中,所述第一调用链信息和第二调用链信息不同,所述第二调用链信息用于指示所述第一信息在所述第一节点中相关的节点信息,所述第二请求还包括所述第一调用链信息和所述第二调用链信息。
  20. 如权利要求17所述的节点,其特征在于,所述处理单元具体用于:
    将所述第一签名和所述第二签名进行累乘,得到所述第三签名;或者,
    基于椭圆曲线,整合所述第一签名和所述第二签名,得到所述第三签名;
    其中,所述第一调用链信息和第二调用链信息相同,所述第二调用链信息用于指示所述第一信息在所述第一节点中相关的节点信息,所述第二请求还包括所述第一调用链信息或所述第二调用链信息。
  21. 如权利要求17至20任一项所述的节点,其特征在于,所述第二请求还包括第一新鲜值,所述第一新鲜值用于指示所述第一调用链信息的实时性,所述第二签名是通过对所述第一调用链信息和所述第一新鲜值签名得到的。
  22. 如权利要求17至21任一项所述的节点,其特征在于,所述第一请求还包括第一控制流信息,所述第一控制流信息包括所述第一节点的控制程序的运行路径,
    所述在所述第一签名校验通过的情况下,所述处理单元具体用于:
    在对所述第一签名校验通过且对所述第一控制流信息校验通过的情况下,所述第二节点根据所述第一签名和所述第二签名,确定所述第三签名。
  23. 如权利要求22所述的节点,其特征在于,所述处理单元还用于:
    通过硬件收集所述第二节点的第二控制流信息,所述第二控制流信息包括所述第二节点的控制程序的运行路径,所述第二请求还包括所述第二控制流信息。
  24. 一种节点,其特征在于,所述节点包括通信单元和处理单元:
    所述通信单元用于,接收来自第二节点的第二请求,所述第二请求包括第三签名,所述第二请求用于请求第一信息,所述第一信息为与起始节点相关的信息;
    所处处理单元用于,校验所述第三签名,其中,所述第三签名为所述第二节点根据第一签名和第二签名确定的,所述第一签名来自第一节点的第一请求,所述第二签名是所述第二节点通过对第一调用链信息进行签名得到的,所述第一调用链信息用于指示所述第一信息在所述第二节点中相关的节点信息,所述第一调用链信息包括起始节点信息。
  25. 如权利要求24所述的节点,其特征在于,所述第三签名包括所述第一签名和所述第二签名;
    所述处理单元具体用于:
    逐一校验所述第三签名中的每个签名。
  26. 如权利要求24所述的节点,其特征在于,所述第三签名为所述第二节点根据所述第一签名和所述第二签名累乘得到的,或基于椭圆曲线,整合所述第一签名和所述第二签名得到的;
    所述节点还包括获取单元:
    所述获取单元用于,获取第一公钥,所述第一公钥包括所述第二节点和所述第二节点之前的节点的公钥;
    所述处理单元具体用于:
    根据所述第一公钥、所述第一调用链信息和第二调用链信息,校验所述第三签名;
    其中,所述第二调用链信息用于指示所述第一信息在所述第一节点中相关的节点信息,所述第二请求还包括所述第一调用链信息和/或所述第二调用链信息。
  27. 如权利要求26所述的节点,其特征在于,在所述第一调用链信息和所述第二调用链信息不同的情况下,所述第二请求包括所述第一调用链信息和所述第二调用链信息,所述处理单元具体用于:
    根据所述第一公钥、所述第一调用链信息和所述第二调用链信息,获得第一签名凭证;
    根据所述第三签名,获得第一待验证信息;
    根据所述第一签名凭证以及所述第一待验证信息,校验所述第三签名是否通过。
  28. 如权利要求26所述的节点,其特征在于,在所述第一调用链信息和所述第二调用链信息相同的情况下,所述第二请求包括所述第一调用链信息或所述第二调用链信息,所述处理单元具体用于:
    根据所述第一公钥,获得公钥之和;
    根据所述第一调用链信息或所述第二调用链信息,以及所述公钥之和,获得第二签名凭证;
    根据所述第三签名,获得第二待验证信息;
    根据所述第二签名凭证以及所述第二待验证信息,校验所述第三签名是否通过。
  29. 如权利要求24至28任一项所述的节点,其特征在于,所述第二请求还包括第一新鲜值,所述第一新鲜值用于指示所述第一调用链信息的实时性,所述第二签名是通过对所述第一调用链信息和所述第一新鲜值签名得到的。
  30. 如权利要求24至29任一项所述的节点,其特征在于,所述第二请求还包括第二控制流信息,所述第二控制流信息用于指示所述第二节点的控制程序的运行路径,
    在所述第三签名校验通过的情况下,所述处理单元还用于:
    校验所述第二控制流信息是否正确。
  31. 如权利要求24至30任一项所述的节点,其特征在于,在所述第三签名校验通过并且所述第二控制流信息校验通过的情况下,
    所述处理单元还用于,根据所述第三签名和第四签名,确定第五签名,所述第四签名是所述第三节点通过对第三调用链信息进行签名得到的,所述第三调用链信息用于指示所述第一信息在所述第三节点中相关的节点信息;
    所述通信单元还用于,向第四节点发送第三请求,所述第三请求包括所述第五签名,所述第三请求用于请求所述第一信息。
  32. 如权利要求24至30任一项所述的节点,其特征在于,在所述第三签名校验通过并且所述第二控制流信息校验通过的情况下,
    所述处理单元还用于:
    所述第三节点根据所述第二请求,响应所述第一信息。
  33. 一种节点,其特征在于,包括:
    存储器,用于存储计算机程序;
    处理器,用于执行所述存储器中存储的计算机程序,以使得所述节点执行如权利要求1至7中任一项所述的方法,或者,以使得所述节点执行如权利要求8至16中任一项所述的方法。
  34. 一种通信***,其特征在于,包括如权利要求17至23中任一项所述的节点和如权利要求24至32中任一项所述的节点。
  35. 一种移动载体,其特征在于,包括如权利要求17至23中任一项所述的节点,或者包括如权利要求24至32中任一项所述的节点,或者包括如权利要求34所述的通信***。
  36. 根据权利要求35所述的移动载体,其特征在于,所述移动载体为车辆。
  37. 一种计算机可读存储介质,其特征在于,其上存储有计算机程序,所述计算机程序被计算机执行时,以使得实现如权利要求1至7中任一项所述的方法,或者,以使得实现如权利要求8至16中任一项所述的方法。
  38. 一种计算机程序产品,其特征在于,所述计算机程序产品包括:计算机程序代码,当所述计算机程序代码在计算机上运行时,以使得实现如权利要求1至7中任一项所述的方法,或者,以使得实现如权利要求8至16中任一项所述的方法。
  39. 一种芯片,其特征在于,包括电路,所述电路用于执行如权利要求1至7中任一项所述的方法,或者所述电路用于执行如权利要求8至16所述的方法。
PCT/CN2022/136574 2022-12-05 2022-12-05 一种通信方法、节点、通信***和移动载体 WO2024119308A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/136574 WO2024119308A1 (zh) 2022-12-05 2022-12-05 一种通信方法、节点、通信***和移动载体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/136574 WO2024119308A1 (zh) 2022-12-05 2022-12-05 一种通信方法、节点、通信***和移动载体

Publications (1)

Publication Number Publication Date
WO2024119308A1 true WO2024119308A1 (zh) 2024-06-13

Family

ID=91378397

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/136574 WO2024119308A1 (zh) 2022-12-05 2022-12-05 一种通信方法、节点、通信***和移动载体

Country Status (1)

Country Link
WO (1) WO2024119308A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111464315A (zh) * 2020-04-03 2020-07-28 腾讯科技(深圳)有限公司 数字签名处理方法、装置、计算机设备以及存储介质
CN111784338A (zh) * 2019-04-10 2020-10-16 北京沃东天骏信息技术有限公司 信息处理方法、装置、***及存储介质
WO2021012574A1 (zh) * 2019-07-24 2021-01-28 深圳壹账通智能科技有限公司 多重签名方法、签名中心、介质及电子设备
CN112785307A (zh) * 2021-01-28 2021-05-11 联想(北京)有限公司 一种请求消息处理方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111784338A (zh) * 2019-04-10 2020-10-16 北京沃东天骏信息技术有限公司 信息处理方法、装置、***及存储介质
WO2021012574A1 (zh) * 2019-07-24 2021-01-28 深圳壹账通智能科技有限公司 多重签名方法、签名中心、介质及电子设备
CN111464315A (zh) * 2020-04-03 2020-07-28 腾讯科技(深圳)有限公司 数字签名处理方法、装置、计算机设备以及存储介质
CN112785307A (zh) * 2021-01-28 2021-05-11 联想(北京)有限公司 一种请求消息处理方法及装置

Similar Documents

Publication Publication Date Title
US10285051B2 (en) In-vehicle networking
CN109687976B (zh) 基于区块链与pki认证机制的车队组建及管理方法及***
WO2022105176A1 (zh) 基于区块链网络的车联网认证方法、装置、设备和介质
US11985238B2 (en) Vehicle-mounted device upgrade method and related device
CN107105060B (zh) 一种实现电动汽车信息安全的方法
US10868667B2 (en) Blockchain enhanced V2X communication system and method
Bernardini et al. Security and privacy in vehicular communications: Challenges and opportunities
US20200029209A1 (en) Systems and methods for managing wireless communications by a vehicle
Hazem et al. Lcap-a lightweight can authentication protocol for securing in-vehicle networks
WO2019083440A2 (zh) 一种车载设备升级方法及相关设备
Zelle et al. On using TLS to secure in-vehicle networks
Iorio et al. Securing SOME/IP for in-vehicle service protection
WO2013005730A1 (ja) 車載ネットワークシステム
Fassak et al. A secure protocol for session keys establishment between ECUs in the CAN bus
Limbasiya et al. Iovcom: Reliable comprehensive communication system for internet of vehicles
EP4144116A1 (en) Method and system for establishing trust for a cybersecurity posture of a v2x entity
CN114362993A (zh) 一种区块链辅助的车联网安全认证方法
Carvajal-Roca et al. A semi-centralized dynamic key management framework for in-vehicle networks
CN114867014A (zh) 一种车联网访问控制方法、***、介质、设备及终端
CN108881494B (zh) 基于车载网络和区块链的安全信息传输方法
CN113115309B (zh) 车联网的数据处理方法、装置、存储介质和电子设备
CN117439740A (zh) 一种车内网络身份认证与密钥协商方法、***及终端
WO2024119308A1 (zh) 一种通信方法、节点、通信***和移动载体
Wang et al. A secure solution of V2G communication based on trusted computing
CN112187468B (zh) 一种基于身份标识的can网络数据源身份认证方法