WO2023230975A1

WO2023230975A1 - Method and apparatus for establishing interoperation channel, and chip and storage medium

Info

Publication number: WO2023230975A1
Application number: PCT/CN2022/096777
Authority: WO
Inventors: 包永明; 吕小强; 茹昭; 张军; 杨宁
Original assignee: Oppo广东移动通信有限公司
Priority date: 2022-06-02
Filing date: 2022-06-02
Publication date: 2023-12-07

Abstract

Provided are a method and apparatus for establishing an interoperation channel, and a chip and a storage medium. The method comprises: a first device negotiating with a second device regarding a shared key according to a sigma protocol; the first device establishing with the second device an interoperation channel based on the shared key; and the first device sending a control instruction to the second device by means of the interoperation channel, so as to control the second device, wherein the first device is a terminal device, and the second device is a vehicle device. In the embodiments of the present application, a first device can negotiate with a second device and on the basis of a sigma protocol with regard to a shared key corresponding to an interoperation channel, such that the security and reliability of communication of the interoperation channel are ensured, thereby realizing the control of the first device over the second device in terms of security. The manner of performing negotiation with regard to a shared key on the basis of a sigma protocol facilitates the reduction of the risk of the shared key being divulged.

Description

Methods, devices, chips and storage media for establishing interoperability channels

Technical field

The present application relates to the field of communication technology, and more specifically, to a method, device, chip and storage medium for establishing an interoperability channel.

Background technique

With the rapid development of communication technology, different devices can achieve interoperability between devices by establishing interoperability channels, for example, to control devices.

In the related technology, in order to ensure the security and reliability of the communication of the interoperability channel, encrypted communication of the interoperability channel can be performed based on the shared key. However, how to negotiate the shared key corresponding to the interoperability channel between devices is an issue that needs to be solved urgently.

Contents of the invention

This application provides a method, device, chip and storage medium for establishing an interoperability channel. Each aspect involved in this application is introduced below.

In a first aspect, a method for establishing an interoperability channel is provided, including: a first device negotiates a shared key with a second device according to a sigma protocol; the first device and the second device establish a shared key based on the shared key. interoperation channel; the first device sends control instructions to the second device through the interoperation channel to control the second device, where the first device is a terminal device, and the first device The second equipment is vehicle equipment.

In a second aspect, a method for establishing an interoperability channel is provided, including: a second device negotiates a shared key with a first device according to a sigma protocol; and the second device and the first device establish a shared key based on the shared key. The interoperation channel; the second device receives the control instruction of the first device through the interoperation channel, wherein the first device is a terminal device and the second device is a vehicle device.

In a third aspect, a device for establishing an interoperability channel is provided. The device is configured on a first device. The device includes: a first negotiation module for negotiating a shared key with a second device according to the sigma protocol; an establishment module , configured to establish an interoperability channel based on the shared key with the second device; a control module configured to send control instructions to the second device through the interoperability channel to perform operations on the second device. Control, wherein the first device is a terminal device and the second device is a vehicle device.

In a fourth aspect, a device for establishing an interoperability channel is provided. The device is configured on a second device. The device includes: a first negotiation module for negotiating a shared key with the first device according to the sigma protocol; and an establishment module. , configured to establish an interoperability channel based on the shared key with the first device; a first receiving module, configured to receive control instructions of the first device through the interoperability channel, wherein the first The device is a terminal device, and the second device is a vehicle device.

In a fifth aspect, a communication device is provided. The communication device is configured in a first device. The device includes a processor, a memory and a communication interface. The memory is used to store one or more computer programs, and the processor is used to store one or more computer programs. Calling the computer program in the memory causes the first device to perform some or all of the steps in the method of the first aspect.

In a sixth aspect, a communication device is provided. The communication device is configured in a second device. The device includes a processor, a memory and a communication interface. The memory is used to store one or more computer programs, and the processor is used to store one or more computer programs. Calling the computer program in the memory causes the second device to perform some or all of the steps in the method of the second aspect.

In a seventh aspect, embodiments of the present application provide a communication system, which includes the above communication device. In another possible design, the system may also include other devices that interact with the communication device in the solution provided by the embodiments of the present application.

In an eighth aspect, embodiments of the present application provide a computer-readable storage medium that stores a computer program, and the computer program causes the communication device to perform some or all of the steps in the methods of the above aspects.

In a ninth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause the communication device to execute the above Some or all of the steps in various aspects of the method. In some implementations, the computer program product can be a software installation package.

In a tenth aspect, embodiments of the present application provide a chip, which includes a memory and a processor. The processor can call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects.

In the embodiment of this application, the first device and the second device can negotiate the shared key corresponding to the interoperability channel based on the sigma protocol to ensure the security and reliability of the communication of the interoperability channel and realize the communication between the first device and the second device. safely control. Negotiating the shared key based on the sigma protocol helps reduce the risk of the shared key being leaked.

Description of the drawings

FIG. 1 is an architectural example diagram of a wireless communication system applicable to embodiments of the present application.

Figure 2 is a schematic flowchart of key exchange based on the sigma protocol provided by an embodiment of the present application.

FIG. 3 is a schematic flowchart of a method for establishing an interoperability channel according to an embodiment of the present application.

FIG. 4 is a schematic flowchart of a possible implementation of step S310 in FIG. 3 .

Figure 5 is a schematic flowchart of negotiating a first identity code according to an embodiment of the present application.

Figure 6 is a schematic flowchart of negotiating a first identity code provided by another embodiment of the present application.

Figure 7 is a schematic flowchart of a negotiation method for negotiating a shared key provided by an embodiment of the present application.

Figure 8 is a schematic flowchart of a method for establishing an interoperability channel provided by another embodiment of the present application.

Figure 9 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application.

Figure 10 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application.

Figure 11 is a schematic structural diagram of a device for establishing an interoperability channel provided by an embodiment of the present application.

Figure 12 is a schematic structural diagram of an apparatus for establishing an interoperability channel provided by another embodiment of the present application.

Figure 13 is a schematic structural diagram of a communication device provided by an embodiment of the present application.

Detailed ways

The technical solutions in this application will be described below with reference to the accompanying drawings.

FIG. 1 is an architectural example diagram of a wireless communication system 100 applicable to embodiments of the present application. As shown in FIG. 1 , the wireless communication system 100 may include a first device 110 and a second device 120 . The first device 110 may communicate with the second device 120 using an interoperation channel to implement interoperation between the first device 110 and the second device 120 . For example, a first device controls a second device.

In some embodiments, the first device 110 and the second device 120 can establish a connection for communication through wired (for example, USB interface) or wireless network (for example, Bluetooth or mobile network), so that the first device 110 and the second device 120 can communicate with each other. Interoperation between two devices 120.

Figure 1 exemplarily shows a first device 110 and a second device 120, but the embodiment of the present application is not limited thereto. Optionally, the wireless communication system 100 may include multiple first devices and/or multiple second devices. For example, a first device may control multiple second devices, or a second device may receive multiple first devices. Equipment control, etc.

Optionally, the wireless communication system 100 may also include other devices, such as a third device, which is not limited in this embodiment of the present application. For example, the first device 110 can communicate with the third device through the second device 120. For example, the first device 110 can control or access the third device through the second device 120. Optionally, in this scenario, the second device 120 can be understood as a relay device or a bridge device.

It should be understood that the technical solutions of the embodiments of the present application can be applied to various communication systems, such as: fifth generation (5th generation, 5G) systems or new radio (NR), long term evolution (long term evolution, LTE) systems , LTE frequency division duplex (FDD) system, LTE time division duplex (TDD), Bluetooth system, wireless fidelity (wireless fidelity, WiFi) system, etc. The technical solution provided by this application can also be applied to future communication systems, such as the sixth generation mobile communication system, satellite communication systems, and so on.

In some embodiments, the first device and the second device in the embodiments of the present application may be referred to as the first terminal device and the second terminal device respectively. Among them, the terminal equipment can also be called user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (mobile terminal, MT), remote station , remote terminal, mobile device, user terminal, terminal, wireless communications device, user agent or user device.

The first device and the second device in the embodiment of the present application may be devices that provide voice and/or data connectivity to users, and may be used to connect people, things, and machines, such as handheld devices and vehicle-mounted devices with wireless connection functions. wait. Illustratively, the first device and/or the second device in the embodiment of the present application may be a mobile phone (mobile phone), a tablet computer (Pad), a notebook computer, a handheld computer, a mobile internet device (mobile internet device, MID), Wearable devices, Internet of things (IoT) devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control (industrial control), driverless ( Wireless terminals in self driving, wireless terminals in remote medical surgery, wireless terminals in smart grid, wireless terminals in transportation safety, wireless terminals in smart city Wireless terminals, wireless terminals in smart homes, etc.

The embodiments of this application do not limit the type of IoT devices. In some embodiments, IoT devices may include smart travel tools such as vehicles and ships. In some embodiments, IoT devices may include smart home devices such as smart TVs, smart air conditioners, smart refrigerators, and sweeping robots. In some embodiments, IoT devices may include smart monitoring devices such as surveillance cameras, temperature sensors, sound sensors, etc.

Further, when the IoT device is a vehicle, the vehicle can be, for example, a family car, a taxi, a bus, a motorcycle, etc.; when the IoT device is a smart air conditioner, the smart air conditioner can be, for example, a vertical air conditioner, a hanging air conditioner, or a vertical air conditioner. Air conditioning, etc., this application is not limited to this.

In some embodiments, the first device 110 and the second device 120 may be different types of devices to achieve interoperation between different types of devices. For example, the first device 110 can be a handheld terminal device such as a mobile phone or a tablet computer, and the second device 120 can be an IoT device (such as a vehicle, a smart air conditioner, etc.). Based on this, the handheld terminal device can be used to control IoT devices (vehicles, smart air conditioners, etc.). air conditioning, etc.).

In some embodiments, the first device 110 and the second device 120 may be devices from different manufacturers to achieve interoperability between devices of different manufacturers. For example, the first device 110 may be a device from a first manufacturer, and the second device 120 may be a device from a second manufacturer (different from the first manufacturer). Based on this, the device produced by the first manufacturer may be implemented. Control of equipment produced by second manufacturers.

The embodiments of this application do not limit the scenarios in which the first device and the second device are located. For example, the first device and the second device may be deployed on land, including indoors or outdoors, handheld or vehicle-mounted.

It should be understood that all or part of the functions of the communication device in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (such as a cloud platform).

It should be understood that the interoperation between the first device and the second device mentioned in the embodiments of this application, or the first device controlling the second device, may refer to the interoperation or control between different types of devices, or It may refer to interoperability or control between devices of different manufacturers. The embodiments of this application are not limited to this. For example, it may also refer to interoperation or control between devices of the same manufacturer, as long as the first It only suffices that the device and the second device can interoperate, or control and be controlled.

It should be understood that the technical solutions provided by the embodiments of this application can be applied to any scenario in which devices interoperate, such as interoperability between terminal devices and IoT devices. The application scenarios of the embodiments of the present application are introduced below with two specific examples. These examples are not intended to limit the present application.

As an example, the second device may refer to a vehicle, a ship, or other smart travel tool, and the first device may refer to a terminal device that can control the smart travel tool, such as a mobile phone, a tablet, a laptop, etc. Taking the first device as a mobile phone and the second device as a vehicle as an example, the mobile phone and the vehicle can realize the control of the vehicle by the mobile phone by establishing an interoperability channel. For example, the mobile phone controls the opening of the car door and the opening of the car window.

As another example, the second device may refer to a smart home device such as a smart air conditioner or a smart TV, and the first device may also refer to a terminal device that controls the smart home device, such as a mobile phone, a tablet computer, etc. After the first device establishes an interoperability channel with the smart home device, the first device can control the smart home device, for example, control to turn on the air conditioner, turn on the TV, control and adjust the air conditioner temperature or adjust the air conditioner mode, etc.

In recent years, with the rapid development of communication technology, interoperability application scenarios between different devices have become more frequent. In some communication systems (for example, NR systems), different devices can achieve interoperability between devices by establishing interoperability channels, for example, to enable a first device to control a second device.

However, the current solution for establishing interoperability channels between different devices is incomplete and inconsistent. As a possible implementation method, in order to ensure the security and reliability of the communication of interoperability channels, mutual interaction can be based on shared keys. Encrypted communication for operational channels. However, how to negotiate the shared key corresponding to the interoperability channel between devices is an issue that needs to be solved urgently.

In order to solve the above problems, embodiments of the present application provide a method, device, chip, storage medium and program product for establishing an interoperability channel to negotiate the shared key corresponding to the interoperability channel based on the sigma protocol, which helps to reduce the number of shared keys. Risk of leakage.

In order to facilitate understanding, related concepts are introduced first.

sigma protocol

On the one hand, the sigma protocol can be understood as an efficient interactive zero-knowledge proof protocol that allows the prover to prove to the verifier that he knows the secret without showing the secret to the verifier.

On the other hand, the sigma protocol can be understood as a key exchange protocol that can further ensure the security of key exchange by using digital signatures for authentication.

In some embodiments, the participants of the sigma protocol may include an initiator (initiator) of the initiating process and a receiver (responder) of the response process. The initiator and responder can exchange keys through one or more rounds of sigma messages. Figure 2 is a schematic flowchart of key exchange based on the sigma protocol provided by an embodiment of the present application. The following is an exemplary explanation of the key exchange between the initiator and the responder based on the sigma protocol in conjunction with Figure 2.

As shown in Figure 2, in step S210, the initiator constructs a sigma1 message and sends the sigma1 message to the responder.

The sigma1 message can be used to request the responder to perform key exchange or key negotiation. In some embodiments, the sigma1 message may be a clear text message. In some embodiments, the sigma1 message may be a ciphertext message.

In step S220, the responder generates a shared key based on the sigma1 message sent by the initiator, and sends the constructed sigma2 message to the initiator.

In some embodiments, before generating the shared key, the responder can verify the sigma1 message sent by the initiator, and execute step S220 after passing the verification.

In step S230, the initiator generates a shared key based on the sigma2 message sent by the responder, and sends the constructed sigma3 message to the responder.

In some embodiments, before generating the shared key, the initiator can verify the sigma2 message sent by the responder, and execute step S230 after passing the verification.

In step S240, the responder verifies the sigma3 message, and returns a sigma verification completion message to the initiator after passing the verification.

Node operational certificate (NOC)

A device's NOC can be used to authenticate the device's identity. In some embodiments, the NOC of the device can store the key information corresponding to the NOC. For example, the NOC of the device can store the public key information corresponding to the NOC, but the corresponding private key information cannot be stored in the NOC. For example, the NOC of the first device (or the first NOC) can store the public key corresponding to the NOC of the first device, and the NOC of the second device (or the second NOC) can store the public key of the second device. The public key corresponding to the NOC. However, the embodiments of the present application are not limited to this. For example, the NOC of the device may also store other information besides the key information corresponding to the NOC, such as the device identification of the device and so on.

In order to further improve the security of the shared key exchange process, in some embodiments, an interoperable certificate chain can be used to verify the NOC of the device. For example, an interoperable certificate chain issued by a device certification authority (certificate authority, CA) can be used. Verify the NOC of the device. For the sake of simplicity, the certificate issued by the CA will be referred to as the CA certificate in the following text.

The interoperability certificate chain mentioned in the embodiment of this application may include a two-level or multi-level certificate chain, which is not limited in the embodiment of this application.

In some embodiments, a three-level interoperability certificate chain may be used to verify the NOC of the device. The three-level interoperability certificate chain can include root CA certificate (Root CA Certificate, RCAC), intermediate CA certificate (Intermediate CA Certificate, ICAC) and NOC. Optionally, ICAC can be signed by RCAC, and NOC can be signed by ICAC. Correspondingly, when the three-level interoperability certificate chain is used to verify the NOC of the device, ICAC can be used to verify the NOC, and RCAC can be used to verify the ICAC.

In some embodiments, a secondary interoperability certificate chain may be used to verify the NOC of the device. Secondary interoperability certificate chains can include RCAC and NOC. Optionally, the NOC can be signed by RCAC. Correspondingly, when the secondary interoperability certificate chain is used to verify the NOC of the device, RCAC can be used to verify the NOC.

In some embodiments, the first device may configure an interoperability certificate chain to the second device, for example, configure a third-level interoperability certificate chain, or configure a second-level interoperability certificate chain. For example, when the interoperability certificate chain configured by the first device to the second device is a three-level interoperability certificate chain, the certificate chain may include the RCAC of the first device, the ICAC of the first device, and the NOC of the second device, The NOC of the second device may contain the public key corresponding to the NOC of the second device, and the private key corresponding to the NOC of the second device can only be stored in the second device. When the interoperability certificate chain configured by the first device to the second device is a secondary interoperability certificate chain, the certificate chain may include the RCAC of the first device and the NOC of the second device, and the NOC of the second device may include the second device. The public key corresponding to the NOC and the private key corresponding to the NOC of the second device can only be stored in the second device. However, the embodiments of the present application are not limited to this. The interoperability certificate chain of the second device may also be configured by other devices. The device used to configure the interoperability certificate chain to the second device may be called a commissioning specialist (commissioner).

The method embodiments provided by the embodiments of the present application will be introduced in detail below with reference to the accompanying drawings.

Figure 3 is a schematic flowchart of a method for establishing an interoperability channel provided by an embodiment of the present application. The method shown in Figure 3 is described from the perspective of interaction between the first device and the second device. The first device and the second device may be, for example, the first device 110 and the second device 120 in FIG. 1 .

The embodiments of the present application do not limit the specific types of the first device and the second device, as long as the first device and the second device can interoperate or realize the control of the second device by the first device. For example, the second device may refer to IoT devices, such as smart travel tools such as vehicles and ships, or smart home devices such as smart air conditioners and smart TVs, etc.; the first device may refer to a terminal device capable of controlling the IoT device. . For example, in some embodiments, the first device may be a terminal device, and the second device may be a vehicle device.

The method shown in Figure 3 may include steps S310 to S330, and these steps will be described in detail below.

In step S310, the first device and the second device negotiate a shared key based on the sigma protocol.

In this embodiment of the present application, the first device may be called an initiator, and the second device may be called a responder. The first device and the second device may negotiate a shared key based on one or more rounds of sigma messages.

In some embodiments, the first device and the second device may negotiate a shared key based on the sigma protocol and the device's NOC. For example, the NOC information of the device may be carried in the sigma message to negotiate the shared key between the first device and the second device.

In some embodiments, before negotiating the shared key, the first device and the second device may negotiate to determine a shared key negotiation method according to the key negotiation methods (or types) supported by the first device and the second device respectively. In this embodiment of the present application, the first device and the second device negotiate and determine the shared key in a negotiation manner: negotiating the shared key based on the sigma protocol. How the first device and the second device negotiate to determine the shared key will be introduced in detail later, and will not be described here.

In this embodiment of the present application, only the first device and the second device know the shared key negotiated by the first device and the second device, and the first device and the second device can perform encrypted communications based on the negotiated shared key. During the process of negotiating the shared key, the first device and the second device may generate the shared key based on one or more types of information. For a detailed description of how the first device and the second device negotiate or how to generate a shared key, please refer to the following text and will not be described again here.

In some embodiments, the first device and the second device may use some key algorithms to generate the shared key. For example, both devices may use the same key algorithm to generate the shared key to ensure the security of the generated shared key. Correspondence and consistency. The embodiments of this application do not limit the specific type of the key algorithm. For example, the key algorithm can be a symmetric encryption algorithm, such as the data encryption standard (data encryption standard, DES) algorithm, advanced encryption standard (advanced encryption standard, AES) Algorithms etc.

In step S320, the first device and the second device establish an interoperation channel based on the shared key. When the first device and the second device communicate (for example, send or receive control instructions) based on the interoperability channel, the shared key is used to encrypt and security protect the communication between the first device and the second device. In other words, when the first device and the second device communicate based on the interoperability channel, the shared key can be used to encrypt information transmitted in the interoperability channel to improve communication security.

As mentioned above, the first device and the second device can use the interoperation channel to realize the control of the second device by the first device (interoperation between devices). In the embodiment of this application, an interoperability channel can be understood as a control channel (or security control channel). After an interoperability channel is established between the first device and the second device, the first device can use the interoperability channel to The second device takes control. After the first device and the second device establish an interoperability channel based on the shared key, when the first device and the second device communicate using the interoperability channel, they can perform encrypted communication based on the shared key negotiated by the two, which strengthens the security of the communication. The security protection of information (such as data, instructions, etc.) in the interoperability channel improves the security level of communication.

In some embodiments, when the first device and the second device establish an interoperation channel based on a shared key, the shared key corresponding to each establishment of the interoperation channel may be different and random, that is, the first device and the second device Before each time a device establishes an interoperability channel, it can agree on a new shared key, and then use the shared key to encrypt communications and other processes to further improve the security of interoperability channel communications.

In step S330, the first device controls the second device through the interoperation channel. For example, the first device can send a control command (control instruction) to the second device through an interoperation channel to control the second device.

In some embodiments, the first device controlling the second device may mean that the first device controls the second device to perform some operations, such as opening operations, closing operations, adjusting operations, etc. As an example, when the second device is a vehicle, the first device controlling the second device may mean controlling opening of the vehicle door, closing of the vehicle window, etc. As another example, when the second device is a smart air conditioner, the first device controlling the second device may mean controlling to turn on the air conditioner, adjust the air conditioner mode, adjust the temperature, etc.

In some embodiments, the first device controlling the second device may refer to the first device accessing resources of the second device. As an example, when the second device is a temperature sensor, the first device controlling the second device may refer to checking the temperature of the second device, so that when the temperature of the second device exceeds a certain threshold, some operations are performed on the second device. .

The embodiment of the present application does not limit the implementation manner of step S310. A possible implementation manner of step S310 is given below with reference to Figure 4, and the process of the first device and the second device negotiating a shared key based on the sigma protocol is described in detail. For example, step S310 may include steps S312 to S318, and these steps will be described in detail below.

In step S312, the first device sends a first message to the second device, and the first message may be used to request the second device to negotiate a shared key. In some embodiments, the first message may also be called a sigma1 message.

In this embodiment of the present application, the first message includes first data, and the first data includes the temporary public key of the first device. The embodiment of the present application does not limit the source of the temporary public key of the first device. For example, the temporary public key of the first device may be generated by the first device, for example, before sending the first message. It should be understood that when the first device generates the temporary public key of the first device, it may also generate a temporary private key of the first device, and the temporary public key and the temporary private key form a temporary key pair of the first device.

In some embodiments, the first data may also include other information in addition to the temporary public key of the first device. Exemplarily, the first data may also include one or more of the following information: a session identifier of the first device, a random number generated by the first device.

In some embodiments, if the first data includes one or more of the temporary public key of the first device, the session identifier of the first device, and the random number generated by the first device, the first device may Encrypt. Specifically, the first device may encrypt the first data according to the identification code of the first device before sending the first message to the second device. The identification code of the first device may be configured by the first device for the second device in advance or may be generated by the second device. The identification code of the first device will be described in detail later and will not be described in detail here.

The session identifier of the first device may be used to identify a subsequent session with the first device. The random numbers generated by the first device can be used to prevent replay attacks. In an authentication protocol or data encryption transmission system, random numbers can be used as seed data and seed vectors to participate in the identification or data validity determination between the first device and the second device. It should be understood that in each process of the first device and the second device negotiating the shared key, the random number generated by the first device may be different and random. Preferably, the random number generated by the first device may be a true random number.

Correspondingly, after the first device encrypts the first data using the first device's identification code, and after the second device receives the first message sent by the first device, it can encrypt the first data according to the first device's identification code. Decrypt. After the second device successfully decrypts the first data, it can learn the temporary public key of the first device and other information in the first data, thus avoiding the problem of easy leakage caused by the clear text transmission of the temporary public key of the first device.

In some embodiments, the first data may also include a first destination identifier, and the first destination identifier may be used by the second device to verify the identity of the first device. In some embodiments, the first destination identifier can be used by the second device to find the correct NOC to establish a connection. The first data containing the first destination identifier may mean that the first data includes the temporary public key of the first device and the first destination identifier; or the first data includes, in addition to the temporary public key and the first destination identifier of the first device. , may also include at least one of a session identifier of the first device and a random number generated by the first device.

In some embodiments, the first destination identifier may be obtained by the first device encrypting the first information according to the identity code of the first device. The first information may include one or more of the following information: a random number generated by the first device, a device identification of the second device, and a public key corresponding to the CA certificate of the first device.

In some embodiments, the public key corresponding to the CA certificate of the first device may refer to the public key corresponding to the RCAC of the first device.

It should be understood that when the first data contains the first destination identifier, the first device can encrypt the first information according to the first device's identification code to obtain the first destination identifier, without using the first device's identification code to encrypt the first information. The first data is encrypted as a whole. In other words, when the first data does not contain the first destination identifier, the first device can encrypt the first data according to the identity identification code of the first device; when the first data contains the first destination identifier, the first device The device may encrypt the first information based on the identification code of the first device, and obtain the first destination identifier by encrypting the first information. Other information in the first data other than the first destination identifier may not be encrypted.

Correspondingly, when the first data contains the first destination identifier, after the second device receives the first message sent by the first device (the first message contains the first data, and the first data contains the first destination identifier), the second device The first information can be encrypted according to the identity identification code of the first device to obtain the second destination identifier, and the identity of the first device can be verified based on the first destination identifier and the second destination identifier.

In some embodiments, the first device verifying the identity of the first device based on the first destination identifier and the second destination identifier may mean that after the second device obtains the second destination identifier, it determines the first destination identifier and the second destination identifier. Regarding the consistency between the identifiers, if the second destination identifier is the same as the first destination identifier, the verification can be considered as passed; if the second destination identifier is different from the first destination identifier, the verification can be considered as failed.

In step S314, the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.

In some embodiments, the second device generating the shared key based on the temporary public key of the first device and the temporary private key of the second device may mean that the second device generates the shared key based on the temporary public key of the first device and the temporary private key of the second device. The temporary private key generates a second key, and then the shared key is generated based on the second key.

For example, the second device may generate the shared key based on the second key and one or more of the following information: a random number generated by the second device, and a temporary public key of the second device. As an implementation manner, the second device can use one or more of the information as key parameters and use a key algorithm (or key derivation algorithm) to generate the shared key.

The embodiment of the present application does not limit the key algorithm used by the second device. For example, DES algorithm, AES algorithm, etc. can be used.

In some embodiments, when the second device uses a key algorithm to generate a shared key, the key parameters corresponding to the key algorithm may include the second key, the salt value, the description information of the shared key generated by the second device, and One or more types of information such as the length information of the shared key generated by the second device. Exemplarily, the shared key generated by the second device can be described as: shared key = (second key, salt, description information of the shared key generated by the second device, length of the shared key generated by the second device information).

In some embodiments, the salt value may be randomly generated. For example, the salt value may be randomly generated based on one or more of the following information: an identity protection key (identify protection key, IPK), a random number generated by the second device, the temporary public key of the second device, and the second device's temporary public key. A hash value, wherein the first hash value may refer to a value obtained by hashing the first data using a hash algorithm.

It should be noted that the temporary public key of the first device may be carried by the first device in the first message. The random number generated by the second device and the temporary public key of the second device may be temporarily generated by the second device before generating the shared key. The embodiment of the present application does not limit the source of the temporary public key of the second device. For example, the temporary public key of the second device may be generated by the second device, for example, before the shared key of the second device is generated. Or generated after receiving the first message. It should be understood that when the second device generates the temporary public key of the second device, it can also generate a temporary private key of the second device, and the temporary public key and the temporary private key form a temporary key pair of the second device.

In some embodiments, after the second device generates the shared key, the second device may also use the generated shared key to encrypt the third data to obtain the first encryptData. The embodiments of this application do not limit the specific content of the third data. For example, the third data may include one or more of the following information: the NOC of the second device, the CA certificate of the first device, and the second signature. , the second signature can be understood as a signature generated by the second device using the private key corresponding to the NOC of the second device.

The CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment. For example, if the first device and the second device perform identity verification based on a three-level interoperability certificate chain, the CA certificate of the first device included in the third data may refer to the ICAC certificate of the first device; if the first device When the device and the second device perform identity verification based on the secondary interoperability certificate chain, the CA certificate of the first device included in the third data may refer to the RCAC certificate of the first device.

The second signature may include one or more of the following information: the NOC of the second device, the CA certificate of the first device, and the temporary public key of the second device. For example, the NOC of the second device may contain the public key corresponding to the NOC of the second device. The CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment.

In step S316, the second device sends a second message to the first device. In some embodiments, the second message may also be called a sigma2 message. The second message contains second data. The second data contains the temporary public key of the second device.

In some embodiments, the second data may include other information in addition to the temporary public key of the second device. Exemplarily, the second data may also include one or more of the following information: the session identifier of the second device, the random number generated by the second device, and the first encryptData.

The session identifier of the second device may be used to identify a subsequent session with the second device. For the description of the random number generated by the second device, please refer to the previous description of the random number generated by the first device, and will not be described again here.

In step S318, the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.

In some embodiments, the first device generating the shared key based on the temporary public key of the second device and the temporary private key of the first device may mean that the first device generates the shared key based on the temporary public key of the second device and the first device's temporary private key. The temporary private key generates a first key, and then a shared key is generated based on the first key.

For example, the first device may generate the shared key based on the first key and one or more of the following information: a random number generated by the first device, and a temporary public key of the first device. As an implementation manner, the first device can use one or more of the information as key parameters and use a key algorithm to generate the shared key. For example, the first device can use the same key algorithm as the second device to generate the shared key. Shared key.

The embodiment of the present application does not limit the key algorithm used by the first device. For example, DES algorithm, AES algorithm, etc. can be used.

In some embodiments, when the first device uses a key algorithm to generate a shared key, the key parameters corresponding to the key algorithm may include the first key, the salt value, the description information of the shared key generated by the first device, and One or more types of information such as the length information of the shared key generated by the first device. Exemplarily, the shared key generated by the first device can be described as: shared key = (first key, salt, description information of the shared key generated by the first device, length of the shared key generated by the first device information).

In some embodiments, the salt value may be randomly generated. For example, the salt value may be randomly generated based on one or more of the following information: an identity protection key (identify protection key, IPK), a random number generated by the first device, a temporary public key of the first device, and a Two hash values, where the second hash value may refer to a value obtained by hashing the first data or the second data using a hash algorithm.

It should be noted that the temporary public key of the second device may be carried by the second device in the second message.

In some embodiments, the first device may also verify the identity of the second device before generating the shared key based on the temporary public key of the second device and the temporary private key of the first device. For example, the first device can obtain the shared key based on the first key, use the shared key to decrypt the first encryptData in the second data, and parse out the corresponding data.

In some embodiments, the first device can also use the NOC to verify the identity of the second device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the first device can use the first device The RCAC is used to verify the ICAC sent by the second device, and the stored ICAC of the first device is used to verify the NOC of the second device; if the configured interoperability certificate chain is a second-level interoperability certificate chain, the first device can use the second-level interoperability certificate chain. One device's RCAC checks the second device's NOC.

In some embodiments, the first device can also use the public key corresponding to the NOC of the second device to verify the second signature generated by the second device.

In some embodiments, after the first device generates the shared key, the first device may also use the generated shared key to encrypt the fourth data to obtain the second encryptData. The embodiment of the present application does not limit the specific content of the fourth data. For example, the fourth data may include one or more of the following information: the NOC of the first device, the CA certificate of the first device, and the first signature. , the first signature can be understood as a signature generated by the first device using the private key corresponding to the NOC of the first device.

The CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment. For example, if the first device and the second device perform identity verification based on a three-level interoperability certificate chain, the CA certificate of the first device included in the fourth data may refer to the ICAC certificate of the first device; if the first device When the device and the second device perform identity verification based on the secondary interoperability certificate chain, the CA certificate of the first device included in the fourth data may refer to the RCAC certificate of the first device.

The first signature may include one or more of the following information: the NOC of the first device, the CA certificate of the first device, and the temporary public key of the first device. For example, the NOC of the first device may include a public key corresponding to the NOC of the first device. The CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment.

In some embodiments, after the first device generates the shared key based on the temporary public key of the second device and the temporary private key of the first device, the first device may send a sigma3 message to the second device, and the sigma3 message may include the third A second encryptData generated by a device.

In some embodiments, after receiving the sigma3 message sent by the first device, the second device may process the sigma3 message. Illustratively, the second device may decrypt the second encryptData using the generated shared key. The process of the second device generating the shared key can be found in the previous section and will not be described again here.

In some embodiments, after receiving the sigma3 message sent by the first device, the second device can verify the identity of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device can use the RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify NOC of the first device; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the second device can use the RCAC of the first device to verify the NOC of the first device.

In some embodiments, the second device can also use the public key corresponding to the NOC of the first device to verify the first signature generated by the first device.

In some embodiments, the second device may return a sigma verification completion message to the first device, and the sigma verification completion message may be used to indicate that the second device has determined the shared key.

The first device and the second device negotiate the shared key corresponding to the interoperability channel based on one or more rounds of sigma messages. The negotiation process is relatively complex, making the negotiated shared key more secure.

As mentioned above, in some embodiments, the first data is data encrypted using the identification code of the first device. In some embodiments, the first destination identifier is data encrypted using the identification code of the first device. The information is encrypted. The following describes the encryption performed by the first device according to the identification code of the first device. It should be understood that the encryption can be applied to encrypt the first data, or can also be applied to encrypt the first information to obtain the first purpose identifier. The application examples do not limit this.

On the one hand, the identity code of the first device can be used to indicate the identity of the first device, so that the second device can identify the identity of the first device. On the other hand, the identification code of the first device can be used to encrypt the first data or the first information to prevent the first data or the first information from being leaked during transmission.

In some embodiments, the identification code of the first device may be represented by a PIN code.

In some embodiments, when the first device encrypts the first data based on the identity code of the first device, after the second device receives the first data, it needs to encrypt the first data based on the identity code of the first device. Data is decrypted.

In some embodiments, when the first device encrypts the first information according to the identity code of the first device to obtain the first destination identifier, after receiving the first message, the second device needs to encrypt the first information according to the identity of the first device. The identification code encrypts the first information in the first message to obtain the second destination identifier, and then verifies the identity of the first device based on the first destination identifier and the second destination identifier.

In some embodiments, the identity code of the first device may be determined through negotiation between the first device and the second device. That is to say, before the first device encrypts the first data or the first information according to the first device's identification code, the first device can also negotiate the first identification code with the second device, and the first identification code The identification code can be used for the device corresponding to the first identification code to access the second device. That is, when a device wants to access the second device, it needs to use its corresponding first identification code as a credential to access the second device. Access. This application does not specifically limit the implementation method of negotiating the first identity code between the first device and the second device. Exemplarily, two implementation methods for the first device and the second device to negotiate the first identity code are introduced below with reference to FIG. 5 and FIG. 6 respectively.

Figure 5 is a schematic flowchart of a first device negotiating a first identity code with a second device according to an embodiment of the present application. As shown in Figure 5, in step S510, the first device sends a third message to the second device, and the third message is used to configure the first identity code. That is to say, in this embodiment, the first identification code may be configured by the first device. In this way, each first device may correspond to a fixed identification code. Therefore, in some embodiments, using This solution in which the first device configures the first identity code can also be called a solution in which a fixed identity code is used.

As an implementation manner, during the configuration phase, the first device may configure the first identity code to the second device in advance. After configuring the first identification code, the device corresponding to the first identification code can access the second device.

In order to avoid the clear text transmission of the identification code, in some embodiments, when configuring the first identification code, the first device can configure the first identification code and the first identification code to the second device in the form of tuple information. The corresponding index, such as <pincode, pincode_index>. In other words, the first device can configure the first identity code and the index of the first identity code to the second device, and there is a one-to-one mapping relationship between the first identity code and the index of the first identity code. In this way, after the first device uses the first device's identification code to encrypt the first data, it does not need to transmit the first device's identification code to the second device for decryption by the second device, but transmits it to the second device. The index corresponding to the identification code is sufficient. The second device can know the correct identification code according to the identification code index, thereby decrypting the first data, further improving the security of communication.

In some embodiments, if the first device configures the first identity code and the index corresponding to the first identity code to the second device, when the first device sends the first message to the second device, in the first message In addition to containing the first data, it may also contain an index corresponding to the identification code of the first device. Wherein, the first data in the first message (or the first information in the first data) is encrypted using the identification code of the first device, and the index corresponding to the identification code of the first device is not encrypted.

In some embodiments, the first device may configure a list containing multiple sets of first identity codes to the second device. The list may contain multiple tuple information, and each tuple information is used to represent a set of first identities. The identification code and the index corresponding to the first identification code. The device corresponding to the first identification code in each tuple information can access the second device.

In some embodiments, when the first device configures the first identification code and the index corresponding to the first identification code to the second device, the value of the index corresponding to the first identification code may be a non-zero value or a non-all-F value. value.

In some embodiments, in addition to configuring the first identity code to the second device during the configuration phase, the first device can also configure other information, such as configuring the interoperability certificate chain mentioned above, or configuring other basic configurations. wait.

In some embodiments, after the first device configures the related information of the first identification code (for example, the identification code and the corresponding index) to the second device, the first device can store the configured first identification code accordingly. Related Information.

In some embodiments, the second device may also store information related to the first identification code configured by the first device, for example, store the first identification code that can access the second device and the index corresponding to the first identification code.

The embodiment of the present application does not limit the storage method of the second device. In some embodiments, the second device may store information related to the first identity code in a resource of the second device. In some embodiments, the second device may store information related to the first identity code into a function cluster, for example, into a newly defined function cluster.

After the second device stores the relevant information of the first identification code, it can query the correct identification code according to the identification code index sent by the first device.

Figure 6 is a schematic flowchart of a first device negotiating a first identity code with a second device according to another embodiment of the present application. As shown in Figure 6, in step S610, the first device sends a fourth message to the second device, and the fourth message is used to instruct the second device to return the first identity code. After the second device returns the first identification code, the device corresponding to the first identification code can access the second device. That is to say, in this embodiment, the first identification code may be generated by the second device.

In some embodiments, when the first device and the second device negotiate a shared key, the second device can return a temporary identity code to the first device. Therefore, in some embodiments, this second device is used to provide the first device with a temporary identity code. The scheme in which a device returns a temporary identification code can also be called a scheme in which a temporary identification code is used.

As an implementation manner, before sending the first message to the second device, the first device may send a fourth message to the second device, and the fourth message may carry information indicating that the first device does not have an identification code, for example The fourth message may carry data with an identity code index value of 0. An identity code index value of 0 indicates that the first device does not have an identity code.

In step S620, after receiving the fourth message, the second device returns the first identification code to the first device. In some embodiments, the first identification code returned by the second device for the first device is a temporary identification code, and the first device can access the second device based on the returned temporary identification code.

As an implementation manner, after receiving the fourth message, the second device knows according to the fourth message that the first device does not have an identification code. Based on this, the second device can generate a temporary identification code and display the temporary identification code on on the display screen of the second device so that the first device knows the temporary identification code.

In some embodiments, after the second device knows that the first device does not have an identification code, it can also send a fourth response to the first device. The fourth response can be used to inform the first device to input and the second device returns a response for the first device. temporary identification code. It should be understood that the fourth response can be understood as a response message returned by the second device in response to the fourth message sent by the first device. The response mentioned later can also refer to a response message returned in response to a certain message, which will not be discussed further below. Repeat.

In some embodiments, after the first device inputs the temporary identification code of the first device, it may send the first message to the second device. Optionally, when the first device sends the first message to the second device, the first message, in addition to containing the first data, may also contain an index corresponding to the temporary identity code of the first device. The temporary identity code The corresponding index is used to indicate that the first device already has an identification code. For example, the index corresponding to the temporary identification code contained in the first message may be a full F value, and the full F value is used to indicate that the first device has a temporary identification code.

In some embodiments, after the first device inputs the temporary identification code, it may not save the temporary identification code.

As mentioned above, in some embodiments, before negotiating the shared key, the first device and the second device may negotiate to determine the shared key according to the key negotiation method (or type) supported by the first device and the second device respectively. negotiation method. The following describes in detail the process of the first device and the second device negotiating the shared key negotiation method with reference to Figure 7 .

In step S710, the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.

The key negotiation methods supported by the first device may include one or more. For example, the key negotiation methods supported by the first device may include one or more of the following methods: key pair negotiation, NOC-based Negotiation, and negotiation based on sigma protocol.

It should be understood that after the first device and the second device negotiate and determine the negotiation method of the shared key, they can negotiate the shared key based on the negotiation method and establish an interoperability channel based on the shared key. Therefore, in some embodiments, , the interoperability channel can be divided into different types according to the different ways in which the first device and the second device negotiate the shared key. For example, the first device and the second device negotiate a shared key based on the sigma protocol, and the type of the corresponding interoperation channel is an interoperation channel based on the sigma protocol. In other words, the key negotiation method supported by the first device may also be referred to as the type of interoperability establishment supported by the first device. Therefore, in some embodiments, the fifth message may also be called an interoperation session establishment request message, which is not limited by this application.

In step S720, the second device sends a fifth response to the first device, where the fifth response is used to indicate negotiating the shared key based on the sigma protocol.

As an implementation manner, the second device may determine to negotiate the shared key based on the sigma protocol according to the key negotiation mode supported by the first device, and notify the first device of the information through the fifth response.

As another implementation manner, after receiving the fifth message, the second device may indicate the key negotiation method supported by the second device in the fifth response, and the first device determines the negotiation method of the shared key. The key negotiation method supported by the second device may include one or more of the following methods: key pair-based negotiation, NOC-based negotiation, and sigma protocol-based negotiation.

For example, if the second device only supports the negotiation of shared keys based on the sigma protocol, then the fifth response only contains the method of negotiating the shared keys based on the sigma protocol. After receiving the fifth response, the first device can directly determine whether the shared key is negotiated based on the sigma protocol. The two devices negotiate a shared secret key. Alternatively, the second device supports multiple key negotiation methods, for example, including NOC-based negotiation and sigma protocol-based negotiation. Then, after receiving the fifth response, the first device can choose from the key negotiation methods supported by the second device. Choose one. In this embodiment of the present application, the key negotiation method selected by the first device is to negotiate a shared key with the second device based on the sigma protocol.

In order to facilitate those skilled in the art to understand the implementation process of the technical solutions of the embodiments of the present application, several specific examples are given below. It should be understood that this example is not used to limit the technical solution of the present application. For example, not all steps in the example are necessary, and only some of the steps may be used in actual implementation, or more steps than the listed steps may be used; or, The execution order of the steps in the example is not necessary. Some steps can be executed at the same time or the execution order is reversed.

Example 1 (using fixed identification code)

In Example 1, the first data does not include the first destination identifier. Example 1 will be described in detail below with reference to Figure 8 .

Figure 8 is a schematic flowchart of a method for establishing an interoperability channel provided by another embodiment of the present application. As shown in Figure 8, the method may include steps S8010 to S8170.

In step S8010, the first device establishes a configuration channel with the second device. The configuration channel may be a secure configuration channel, used for configuration operations between the first device and the second device.

In step S8020, the first device sends a third message to the second device. The third message is used to configure the first identification code and the index corresponding to the first identification code, such as configuring tuple information <pincode, pincode_index>, so that the first identification code and the index corresponding to the first identification code are configured. The device corresponding to one identification code can access the second device.

In some embodiments, the first device may configure multiple sets of first identification codes and indexes corresponding to the first identification codes to the second device, that is, configure multiple sets of tuple information. The multiple sets of tuple information may form a configuration list, used to indicate relevant information of the first identification code.

In some embodiments, after the first device configures the first identity code and the index corresponding to the first identity code to the second device, the first device can correspondingly store the first identity code and the index corresponding to the first identity code. index.

In step S8030, the second device stores the first identification code configured by the first device and the index corresponding to the first identification code, for example, in a resource of the second device, or in a function set of the second device (such as a new defined function set).

In some embodiments, after the second device stores the first identification code configured by the first device and the index corresponding to the first identification code, it may also return a configuration status to the first device. The configuration status may be used to indicate, for example, the third The second device has stored the first identification code and the index corresponding to the first identification code.

In step S8040, the first device configures the interoperability certificate chain to the second device. For example, the first device configures the RCAC of the first device and the NOC of the second device to the second device; or the first device configures the RCAC of the first device, the ICAC of the first device, and the NOC of the second device to the second device.

In step S8050, the configuration between the first device and the second device ends, and the configuration channel exits.

In some embodiments, in addition to configuring the first identity code and the interoperability certificate chain to the second device, the first device can also configure some basic configurations to the second device. The identity code and interoperability certificate are to be completed. After the chain and basic configuration are completed, the configuration between the first device and the second device is completed and the configuration channel is exited.

In step S8060, the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.

In some embodiments, the key negotiation method supported by the first device may include one or more of the following methods: key pair-based negotiation, NOC-based negotiation, and sigma protocol-based negotiation.

In step S8070, the second device returns a fifth response to the first device. The fifth response may be used to indicate the key negotiation method supported by the second device. For example, the key negotiation method supported by the second device is negotiation based on the sigma protocol.

In step S8080, the first device encrypts the first data using the identification code of the first device.

As an implementation manner, first, the first device can generate a random number r1, a session identifier of the first device, and a temporary key pair of the first device (including the temporary public key and the temporary private key of the first device) to obtain the first data. . The first data may include one or more of the following information: a random number r1 generated by the first device, a session identifier of the first device, and a temporary public key of the first device. The first device can then encrypt the first data using the first device's identification code.

In step S8090, the first device sends a first message to the second device. The first message may carry the first data encrypted using the identification code of the first device and the index corresponding to the identification code. The index is not encrypted. of.

In some embodiments, the index corresponding to the identification code is a non-zero value or a non-full F value.

In step S8100, the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.

In some embodiments, after receiving the first message, the second device can find the identification code corresponding to the index value carried in the first message, and use the identification code to decrypt the first data.

In some embodiments, after receiving the first message, the second device may generate a temporary key pair of the second device (including the temporary public key and the temporary private key of the second device).

In some embodiments, after the second device generates the temporary key pair of the second device, the second device may use the temporary public key of the first device and the temporary private key of the second device to generate the second key. It should be understood that the temporary public key of the first device may be carried in the first message.

In some embodiments, the second device can also use the private key corresponding to the NOC of the second device to sign one or more of the following data to generate the second signature sign2: the NOC of the second device, the CA of the first device Certificate (e.g., ICAC of the first device), temporary public key of the second device.

Based on this, the second device may generate a shared key based on one or more of the following information: the second key generated based on the temporary public key of the first device and the temporary private key of the second device, the second key generated by the second device. Random number r2, temporary public key of the second device, etc. Exemplarily, the shared key generated by the second device can be described as: shared key = (second key, salt, description information of the shared key generated by the second device, length of the shared key generated by the second device information). For a detailed description of each key parameter, please refer to the previous article.

In some embodiments, the second device may encrypt the fourth data using the shared key generated by the second device to obtain the first encryptData.

In some embodiments, the second device may generate a session identification for the second device.

In step S8110, the second device sends a second message to the first device, and the second message carries the second data. The second data includes one or more of the following information: the random number r2 generated by the second device, the session ID of the second device, the temporary public key of the second device, and the first encryptData.

In step S8120, the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.

In some embodiments, after receiving the second message, the first device may generate the first key using the temporary public key of the second device and the temporary private key of the first device.

In some embodiments, the first device can obtain the shared key based on the first key, use the shared key to decrypt the first encryptData in the second message, and parse out the corresponding data.

In some embodiments, the first device may verify the identity of the second device before generating the shared key. For example, the RCAC of the first device is used to verify the ICAC sent by the second device, and the ICAC of the first device is used to verify the NOC of the second device.

In some embodiments, the first device can use the public key corresponding to the NOC of the second device to verify the second signature sign2 generated by the second device.

In some embodiments, the first device can use the private key corresponding to the NOC of the first device to sign one or more of the following data to obtain the first signature sign1 of the first device: the NOC of the first device, the first The device's CA certificate (eg, the first device's ICAC), the first device's temporary public key.

Based on this, the first device may generate a shared key based on one or more of the following information: the first key generated based on the temporary public key of the second device and the temporary private key of the first device, the first key generated by the first device. Random number r1, temporary public key of the first device, etc. Exemplarily, the shared key generated by the first device can be described as: shared key = (first key, salt, description information of the shared key generated by the first device, length of the shared key generated by the first device information). For a detailed description of each key parameter, please refer to the previous article.

In some embodiments, the first device may encrypt the fourth data using the shared key generated by the first device to obtain the second encryptData.

In step S8130, the first device sends a sigma3 message to the second device, and the sigma3 message may include the second encryptData.

In step S8140, the second device processes the sigma3 message. For example, the second device can use the generated shared key to decrypt the second encryptData and parse the corresponding data.

In some embodiments, after receiving the sigma3 message sent by the first device, the second device can verify the identity of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device can use the RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify NOC of the first device; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the first device can use the RCAC of the first device to verify the NOC of the first device.

In step S8150, the second device returns a sigma verification completion message to the first device.

In step S8160, the first device and the second device establish an interoperation channel based on the shared key.

In step S8170, the first device controls the second device through the interoperation channel.

Example 2 (using fixed identification code)

In Example 2, the first data includes the first destination identifier. Example 2 will be described in detail below with reference to Figure 9 .

Figure 9 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application. As shown in Figure 9, the method may include steps S9010 to S9170.

In step S9010, the first device establishes a configuration channel with the second device. The configuration channel may be a secure configuration channel, used for configuration operations between the first device and the second device.

In step S9020, the first device sends a third message to the second device. The third message is used to configure the first identification code and the index corresponding to the identification code, for example, configure the tuple information <pincode, pincode_index> so that the first identity The device corresponding to the identification code can access the second device.

In step S9030, the second device stores the first identification code configured by the first device and the index corresponding to the first identification code, for example, in a resource of the second device, or in a function set of the second device (such as a new defined function set).

In step S9040, the first device configures the interoperability certificate chain to the second device. For example, the first device configures the RCAC of the first device and the NOC of the second device to the second device; or the first device configures the RCAC of the first device, the ICAC of the first device, and the NOC of the second device to the second device.

In step S9050, the configuration between the first device and the second device ends, and the configuration channel exits.

In step S9060, the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.

In step S9070, the second device returns a fifth response to the first device. The fifth response may be used to indicate the key negotiation method supported by the second device. For example, the key negotiation method supported by the second device is negotiation based on the sigma protocol.

In step S9080, the first device uses the identification code of the first device to encrypt the first destination identifier.

As an implementation manner, first, the first device can generate a random number r1, a session ID of the first device, and a temporary key pair of the first device (including the temporary public key and the temporary private key of the first device), and generate the first destination identifier. The first destination identifier is generated by the first device using the first device's identification code to encrypt the first information. The first information includes one or more of the following information: the random number r1 generated by the first device, the second The device identification of the device and the public key corresponding to the RCAC of the first device. Then, the first device generates first data. The first data may include the temporary public key of the first device and the first destination identifier. In addition, the first data may also include one or more of the following information: The first device generates The random number r1 and the session ID of the first device.

In step S9090, the first device sends a first message to the second device. The first message may carry the first data and an index corresponding to the identification code, and the index is not encrypted.

In step S9100, the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.

In some embodiments, after receiving the first message, the second device can find the identification code through the index value carried in the first message, and use the identification code to encrypt the first information to obtain the second destination identifier. In some embodiments, the second device can verify the identity of the first device according to the first destination identifier and the second destination identifier. For example, if the second device determines that the first destination identifier and the second destination identifier are the same, it means that the verification is passed.

In step S9110, the second device sends a second message to the first device, and the second message carries second data. The second data includes one or more of the following information: the random number r2 generated by the second device, the session ID of the second device, the temporary public key of the second device, and the first encryptData.

In step S9120, the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.

In step S9130, the first device sends a sigma3 message to the second device, and the sigma3 message may include the second encryptData.

In step S9140, the second device processes the sigma3 message. For example, the second device can use the generated shared key to decrypt the second encryptData and parse the corresponding data.

In some embodiments, the second device may also use the public key corresponding to the NOC of the first device to verify the first signature generated by the first device.

In step S9150, the second device returns a sigma verification completion message to the first device.

In step S9160, the first device and the second device establish an interoperation channel based on the shared key.

In step S9170, the first device controls the second device through the interoperation channel.

Example 3 (using temporary identification code)

In example three, the first data includes the first destination identifier. Example 3 will be described in detail below with reference to Figure 10.

Figure 10 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application. As shown in Figure 10, the method may include steps S1001 to S1017.

In step S1001, the first device establishes a configuration channel with the second device. The configuration channel may be a secure configuration channel, used for configuration operations between the first device and the second device.

In step S1002, the first device configures the interoperability certificate chain to the second device. For example, the first device configures the RCAC of the first device and the NOC of the second device to the second device; or the first device configures the RCAC of the first device, the ICAC of the first device, and the NOC of the second device to the second device.

In step S1003, the configuration between the first device and the second device ends, and the configuration channel exits.

In step S1004, the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.

In step S1005, the second device returns a fifth response to the first device. The fifth response may be used to indicate the key negotiation method supported by the second device. For example, the key negotiation method supported by the second device is negotiation based on the sigma protocol.

In step S1006, the first device sends a fourth message to the second device, and the fourth message is used to instruct the second device to return the first identification code.

In some embodiments, the fourth message may carry information indicating that the first device does not have an identity code. For example, data with an identity code index of 0 may be carried to indicate that the first device does not have an identity code.

In step S1007, the second device returns a first identification code to the first device. For example, the first identification code is a temporary identification code.

In some embodiments, the second device may send a fourth response to the first device, return an error code, and inform the first device that it needs to enter the temporary identity code returned by the second device for the first device.

In some embodiments, the second device may display the temporary identification code that needs to be entered on the display screen of the second device.

In step S1008, the first device uses the identification code of the first device to encrypt the first destination identifier.

In step S1009, the first device sends a first message to the second device. The first message may carry the first data and an index corresponding to the identification code, and the index is not encrypted.

In step S1010, the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.

In step S1011, the second device sends a second message to the first device, and the second message carries second data. The second data includes one or more of the following information: the random number r2 generated by the second device, the session ID of the second device, the temporary public key of the second device, and the first encryptData.

In step S1012, the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.

In step S1013, the first device sends a sigma3 message to the second device, and the sigma3 message may include the second encryptData.

In step S1014, the second device processes the sigma3 message. For example, the second device can use the generated shared key to decrypt the second encryptData and parse the corresponding data.

In step S1015, the second device returns a sigma verification completion message to the first device.

In step S1016, the first device and the second device establish an interoperation channel based on the shared key.

In step S1017, the first device controls the second device through the interoperation channel.

The method embodiments of the present application are described in detail above with reference to FIGS. 1 to 10 , and the device embodiments of the present application are described in detail below with reference to FIGS. 11 to 13 . It should be understood that the description of the method embodiments corresponds to the description of the device embodiments. Therefore, the parts not described in detail can be referred to the previous method embodiments.

Figure 11 is a schematic structural diagram of a device for establishing an interoperability channel provided by an embodiment of the present application. The device may be configured in the first device mentioned above. The device 1100 shown in FIG. 11 may include a first negotiation module 1110, an establishment module 1120 and a control module 1130.

The first negotiation module 1110 may be used to negotiate the shared key with the second device according to the sigma protocol.

The establishing module 1120 may be used to establish an interoperability channel based on the shared key with the second device.

The control module 1130 may be used to send control instructions to a second device through an interoperation channel to control the second device, where the first device is a terminal device and the second device is a vehicle device.

Optionally, the first negotiation module further includes: a first sending module, configured to send a first message to the second device, the first message includes first data, the first data includes the temporary public key of the first device, and the first device The temporary public key is used for the second device to generate the shared key; the first receiving module is used for receiving a second message from the second device, the second message includes second data, and the second data includes the temporary public key of the second device; A generating module, configured to generate a shared key based on the temporary public key of the second device and the temporary private key of the first device.

Optionally, the first data also includes one or more of the following information: the session ID of the first device, a random number generated by the first device; and/or the second data also includes one or more of the following information or Multiple types: session ID of the second device, random number generated by the second device.

Optionally, the apparatus 1100 further includes: an encryption module, configured to encrypt the first data according to the identification code of the first device.

Optionally, the first data also includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.

Optionally, the first destination identifier is obtained by the first device encrypting the first information according to the identity code of the first device, and the first information includes one or more of the following information: a random number generated by the first device , the device identification of the second device, and the public key corresponding to the CA certificate of the device certification center of the first device.

Optionally, the apparatus 1100 further includes: a second negotiation module, configured to negotiate a first identity code with the second device, and the first identity code is used for the device corresponding to the first identity code to access the second device.

Optionally, the second negotiation module further includes: a second sending module, configured to send a third message to the second device, where the third message is used to configure the first identity code.

Optionally, the second negotiation module further includes: a third sending module, configured to send a fourth message to the second device, where the fourth message is used to instruct the second device to return the first identity code.

Optionally, the fourth message carries information indicating that the first device does not have an identification code. The apparatus 1100 further includes: a second receiving module configured to receive the first identification code returned by the second device.

Optionally, the first identification code returned by the second device is displayed on the display screen of the second device.

Optionally, the first identification code returned by the second device is a temporary identification code.

Optionally, the apparatus 1100 further includes: a third negotiation module, configured to negotiate a shared key negotiation method with the second device.

Optionally, the third negotiation module further includes: a fourth sending module, configured to send a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device; and a third receiving module, configured to A fifth response is received from the second device, and the fifth response is used to indicate negotiating a shared key based on the sigma protocol.

Optionally, the key negotiation methods supported by the first device and/or the second device include one or more of the following methods: key pair-based negotiation, node interoperability certificate-based negotiation, and sigma protocol-based negotiation.

Optionally, the shared key is generated by the first device based on one or more of the following information: the first key, a random number generated by the first device, and a temporary public key of the first device, where the first The key is generated by the first device based on the temporary public key of the second device and the temporary private key of the first device.

Figure 12 is a schematic structural diagram of an apparatus for establishing an interoperability channel provided by another embodiment of the present application. The device may be configured in the aforementioned second device. The device 1200 shown in FIG. 12 may include a first negotiation module 1210, an establishment module 1220, and a first receiving module 1230.

The first negotiation module 1210 may be used to negotiate the shared key with the first device according to the sigma protocol.

The establishing module 1220 may be used to establish an interoperability channel based on the shared key with the first device.

The first receiving module 1230 may be configured to receive the control instruction of the first device through the interoperation channel, where the first device is a terminal device and the second device is a vehicle device.

Optionally, the first negotiation module further includes: a second receiving module, configured to receive the first message sent by the first device, the first message containing the first data, and the first data containing the temporary public key of the first device; and the generating module. , used to generate a shared key based on the temporary public key of the first device and the temporary private key of the second device; the first sending module is used to send a second message to the first device, where the second message contains the second data, The second data contains the temporary public key of the second device, and the temporary public key of the second device is used by the first device to generate the shared key.

Optionally, the apparatus 1200 further includes: a decryption module, configured to decrypt the first data according to the identification code of the first device.

Optionally, the device 1200 also includes: an encryption module, configured to encrypt the first information according to the identity code of the first device to obtain a second destination identifier; a verification module, configured to encrypt the first information according to the first destination identifier and the second destination identifier. Identification, verifying the identity of the first device.

Optionally, the apparatus 1200 further includes: a second negotiation module, configured to negotiate a first identity code with the first device. The first identity code is used for the device corresponding to the first identity code to access the identity of the second device. code.

Optionally, the second negotiation module further includes: a third receiving module, configured to receive a third message sent by the first device, where the third message is used to configure the first identity code.

Optionally, the second negotiation module further includes: a fourth receiving module, configured to receive a fourth message sent by the first device, where the fourth message is used to instruct the second device to return the first identity code.

Optionally, the fourth message carries information indicating that the first device does not have an identification code, and the apparatus 1200 further includes: a return module configured to return the first identification code for the first device.

Optionally, the apparatus 1200 further includes: a third negotiation module, configured to negotiate a shared key negotiation method with the first device.

Optionally, the third negotiation module further includes: a fifth receiving module, configured to receive a fifth message sent by the first device, where the fifth message is used to indicate the key negotiation method supported by the first device; a second sending module, configured to A fifth response is sent to the first device, where the fifth response is used to indicate that the shared key is negotiated based on the sigma protocol.

Optionally, the shared key is generated by the second device based on one or more of the following information: the second key, a random number generated by the second device, and a temporary public key of the second device, wherein the second device The key is generated by the second device based on the temporary public key of the first device and the temporary private key of the second device.

In an optional embodiment, the device 1100 for establishing an interoperation channel and/or the device 1200 for establishing an interoperation channel may also include a transceiver 1330 and a memory 1320, as specifically shown in FIG. 13 .

Figure 13 is a schematic structural diagram of a communication device according to an embodiment of the present application. The dashed line in Figure 13 indicates that the unit or module is optional. The device 1300 can be used to implement the method described in the above method embodiment. Device 1300 may be a chip, terminal device or network device.

Apparatus 1300 may include one or more processors 1310. The processor 1310 can support the device 1300 to implement the method described in the foregoing method embodiments. The processor 1310 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor can also be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or an off-the-shelf programmable gate array (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 be any conventional processor, etc.

Apparatus 1300 may also include one or more memories 1320. The memory 1320 stores a program, which can be executed by the processor 1310, so that the processor 1310 executes the method described in the foregoing method embodiment. The memory 1320 may be independent of the processor 1310 or integrated in the processor 1310.

Apparatus 1300 may also include a transceiver 1330. Processor 1310 may communicate with other devices or chips through transceiver 1330. For example, the processor 1310 can transmit and receive data with other devices or chips through the transceiver 1330.

An embodiment of the present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.

An embodiment of the present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.

An embodiment of the present application also provides a computer program. The computer program can be applied to the terminal or network device provided by the embodiments of the present application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.

It should be understood that the terms "system" and "network" may be used interchangeably in this application. In addition, the terms used in this application are only used to explain specific embodiments of the application and are not intended to limit the application. The terms “first”, “second”, “third” and “fourth” in the description, claims and drawings of this application are used to distinguish different objects, rather than to describe a specific sequence. . Furthermore, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion.

In the embodiments of this application, the "instruction" mentioned may be a direct instruction, an indirect instruction, or an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association between A and B. relation.

In the embodiment of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B only based on A. B can also be determined based on A and/or other information.

In the embodiments of this application, the term "correspondence" can mean that there is a direct correspondence or indirect correspondence between the two, or it can also mean that there is an association between the two, or it can also mean indicating and being instructed, configuring and being configured, etc. relation.

In the embodiment of this application, "predefinition" or "preconfiguration" can be achieved by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in devices (for example, including terminal devices and network devices). The application does not limit its specific implementation method. For example, predefined can refer to what is defined in the protocol.

In the embodiment of this application, the "protocol" may refer to a standard protocol in the communication field, which may include, for example, LTE protocol, NR protocol, and related protocols applied in future communication systems. This application does not limit this.

The term "and/or" in the embodiment of this application is only an association relationship describing associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A exists alone, and A and B exist simultaneously. , there are three situations of B alone. In addition, the character "/" in this article generally indicates that the related objects are an "or" relationship.

In the various embodiments of the present application, the size of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its functions and internal logic, and should not be determined by the implementation process of the embodiments of the present application. constitute any limitation.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in 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 they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of this embodiment.

In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center integrated with one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVD)) or semiconductor media (e.g., solid state disks (SSD) )wait.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application. should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

A method for establishing an interoperability channel, which is characterized by including:

The first device negotiates a shared key with the second device according to the sigma protocol;

The first device and the second device establish an interoperability channel based on the shared key;

The first device sends control instructions to the second device through the interoperation channel to control the second device;

Wherein, the first device is a terminal device, and the second device is a vehicle device.
The method according to claim 1, characterized in that the first device negotiates a shared key with the second device according to the sigma protocol, including:

The first device sends a first message to the second device, the first message includes first data, the first data includes a temporary public key of the first device, and the temporary public key of the first device The key is used by the second device to generate the shared key;

The first device receives a second message from the second device, the second message includes second data, the second data includes a temporary public key of the second device;

The first device generates the shared key based on the temporary public key of the second device and the temporary private key of the first device.
The method according to claim 2, characterized in that:

The first data also includes one or more of the following information: a session identifier of the first device, a random number generated by the first device; and/or

The second data also includes one or more of the following information: a session identifier of the second device and a random number generated by the second device.
The method according to claim 2 or 3, characterized in that, before the first device sends the first message to the second device, the method further includes:

The first device encrypts the first data according to the identification code of the first device.
The method of claim 2, wherein the first data further includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.
The method according to claim 5, characterized in that the first destination identifier is obtained by the first device encrypting first information according to the identification code of the first device, and the first information includes One or more of the following information: the random number generated by the first device, the device identification of the second device, and the public key corresponding to the device certification center CA certificate of the first device.
The method according to claim 4 or 6, characterized in that, the method further includes:

The first device negotiates with the second device a first identity code, and the first identity code is used for the device corresponding to the first identity code to access the second device.
The method according to claim 7, characterized in that the first device and the second device negotiate a first identity code, including:

The first device sends a third message to the second device, where the third message is used to configure the first identity code.
The method according to claim 7, characterized in that the first device and the second device negotiate a first identity code, including:

The first device sends a fourth message to the second device, where the fourth message is used to instruct the second device to return the first identification code.
The method of claim 9, wherein the fourth message carries information indicating that the first device does not have an identification code,

The method also includes:

The first device receives the first identification code returned by the second device.
The method according to claim 10, characterized in that the first identification code returned by the second device is displayed on the display screen of the second device.
The method according to any one of claims 9-11, characterized in that the first identification code returned by the second device is a temporary identification code.
The method according to any one of claims 1-12, characterized in that, before the first device negotiates a shared key with the second device according to the sigma protocol, the method further includes:

The first device negotiates with the second device a negotiation method for the shared key.
The method according to claim 13, characterized in that the first device and the second device negotiate a negotiation method for the shared key, including:

The first device sends a fifth message to the second device, where the fifth message is used to indicate a key negotiation method supported by the first device;

The first device receives a fifth response from the second device, the fifth response being used to indicate negotiating the shared key based on the sigma protocol.
The method according to claim 14, characterized in that the key negotiation method supported by the first device and/or the second device includes one or more of the following methods: based on key pair negotiation, based on Node interoperability certificate negotiation, and negotiation based on sigma protocol.
The method according to any one of claims 1-15, characterized in that the shared key is generated by the first device according to one or more of the following information: the first key, the The random number generated by the first device, and the temporary public key of the first device, wherein the first key is the temporary public key of the first device based on the temporary public key of the second device and the first device's temporary public key. Temporary private key generated.
A method for establishing an interoperability channel, which is characterized by including:

The second device negotiates the shared key with the first device according to the sigma protocol;

The second device establishes an interoperability channel based on the shared key with the first device;

The second device receives the control instruction of the first device through the interoperation channel;

Wherein, the first device is a terminal device, and the second device is a vehicle device.
The method according to claim 17, characterized in that the second device negotiates a shared key with the first device according to the sigma protocol, including:

The second device receives the first message sent by the first device, the first message includes first data, and the first data includes the temporary public key of the first device;

The second device generates the shared key based on the temporary public key of the first device and the temporary private key of the second device;

The second device sends a second message to the first device, the second message includes second data, the second data includes the temporary public key of the second device, and the temporary public key of the second device The key is used by the first device to generate the shared key.
The method according to claim 18, characterized in that:

The first data also includes one or more of the following information: a session identifier of the first device, a random number generated by the first device; and/or

The second data also includes one or more of the following information: a session identifier of the second device and a random number generated by the second device.
The method according to claim 18 or 19, characterized in that, after the second device receives the first message sent by the first device, the method further includes:

The second device decrypts the first data according to the identification code of the first device.
The method of claim 18, wherein the first data further includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.
The method according to claim 21, characterized in that the first destination identifier is obtained by the first device encrypting first information according to the identification code of the first device, and the first information includes One or more of the following information: the random number generated by the first device, the device identification of the second device, and the public key corresponding to the device certification center CA certificate of the first device.
The method according to claim 22, characterized in that, after the second device receives the first message sent by the first device, the method further includes:

The second device encrypts the first information according to the identification code of the first device to obtain a second destination identifier;

The second device verifies the identity of the first device according to the first destination identifier and the second destination identifier.
The method according to any one of claims 20 and 22-23, characterized in that the method further includes:

The second device negotiates a first identity code with the first device, and the first identity code is used for the device corresponding to the first identity code to access the second device.
The method according to claim 24, characterized in that the second device negotiates the first identity code with the first device, including:

The second device receives a third message sent by the first device, where the third message is used to configure the first identity code.
The method according to claim 24, characterized in that the second device negotiates the first identity code with the first device, including:

The second device receives a fourth message sent by the first device, and the fourth message is used to instruct the second device to return the first identification code.
The method of claim 26, wherein the fourth message carries information indicating that the first device does not have an identification code,

The method also includes:

The second device returns the first identification code to the first device.
The method according to claim 27, characterized in that the first identification code returned by the second device is displayed on the display screen of the second device.
The method according to any one of claims 26 to 28, characterized in that the first identification code returned by the second device is a temporary identification code.
The method according to any one of claims 17-29, characterized in that, before the second device negotiates a shared key with the first device according to the sigma protocol, the method further includes:

The second device negotiates with the first device a negotiation method for the shared key.
The method according to claim 30, characterized in that the second device and the first device negotiate a negotiation method for the shared key, including:

The second device receives a fifth message sent by the first device, where the fifth message is used to indicate a key negotiation method supported by the first device;

The second device sends a fifth response to the first device, where the fifth response is used to indicate negotiating the shared key based on the sigma protocol.
The method according to claim 31, characterized in that the key negotiation method supported by the first device and/or the second device includes one or more of the following methods: based on key pair negotiation, based on Node interoperability certificate negotiation, and negotiation based on sigma protocol.
The method according to any one of claims 17-32, characterized in that the shared key is generated by the second device according to one or more of the following information: the second key, the The random number generated by the second device, and the temporary public key of the second device, wherein the second key is the temporary public key of the second device based on the first device and the second device's temporary public key. Temporary private key generated.
A device for establishing an interoperability channel, characterized in that the device is configured on a first device, and the device includes:

The first negotiation module is used to negotiate the shared key with the second device according to the sigma protocol;

An establishment module, configured to establish an interoperability channel based on the shared key with the second device;

A control module, configured to send control instructions to the second device through the interoperability channel to control the second device;

Wherein, the first device is a terminal device, and the second device is a vehicle device.
The device according to claim 34, wherein the first negotiation module further includes:

A first sending module, configured to send a first message to the second device, where the first message includes first data, the first data includes the temporary public key of the first device, and the The temporary public key is used by the second device to generate the shared key;

A first receiving module configured to receive a second message from the second device, the second message containing second data, and the second data containing the temporary public key of the second device;

A generating module configured to generate the shared key according to the temporary public key of the second device and the temporary private key of the first device.
The device according to claim 35, characterized in that:

The first data also includes one or more of the following information: a session identifier of the first device, a random number generated by the first device; and/or

The second data also includes one or more of the following information: a session identifier of the second device and a random number generated by the second device.
The device according to claim 35 or 36, characterized in that the device further includes:

An encryption module, configured to encrypt the first data according to the identification code of the first device.
The apparatus according to claim 35, wherein the first data further includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.
The device according to claim 38, characterized in that the first destination identifier is obtained by the first device encrypting first information according to the identification code of the first device, and the first information includes One or more of the following information: the random number generated by the first device, the device identification of the second device, and the public key corresponding to the device certification center CA certificate of the first device.
The device according to claim 37 or 39, characterized in that the device further includes:

The second negotiation module is configured to negotiate a first identity code with the second device. The first identity code is used for the device corresponding to the first identity code to access the second device.
The device according to claim 40, characterized in that the second negotiation module further includes:

The second sending module is configured to send a third message to the second device, where the third message is used to configure the first identity code.
The device according to claim 40, characterized in that the second negotiation module further includes:

A third sending module is configured to send a fourth message to the second device, where the fourth message is used to instruct the second device to return the first identification code.
The device according to claim 42, wherein the fourth message carries information indicating that the first device does not have an identification code,

The device also includes:

The second receiving module is configured to receive the first identification code returned by the second device.
The device according to claim 43, characterized in that the first identification code returned by the second device is displayed on the display screen of the second device.
The device according to any one of claims 42 to 44, characterized in that the first identification code returned by the second device is a temporary identification code.
The device according to any one of claims 34-45, characterized in that the device further includes:

The third negotiation module is configured to negotiate the negotiation method of the shared key with the second device.
The device according to claim 46, characterized in that the third negotiation module further includes:

A fourth sending module, configured to send a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device;

The third receiving module is configured to receive a fifth response from the second device, where the fifth response is used to indicate negotiating the shared key based on the sigma protocol.
The device according to claim 47, wherein the key negotiation method supported by the first device and/or the second device includes one or more of the following methods: based on key pair negotiation, based on Node interoperability certificate negotiation, and negotiation based on sigma protocol.
The device according to any one of claims 34-48, wherein the shared key is generated by the first device according to one or more of the following information: the first key, the The random number generated by the first device, and the temporary public key of the first device, wherein the first key is the temporary public key of the first device based on the temporary public key of the second device and the first device's temporary public key. Temporary private key generated.
A device for establishing an interoperability channel, characterized in that the device is configured on a second device, and the device includes:

The first negotiation module is used to negotiate the shared key with the first device according to the sigma protocol;

An establishment module, configured to establish an interoperability channel based on the shared key with the first device;

A first receiving module, configured to receive control instructions of the first device through the interoperation channel;

Wherein, the first device is a terminal device, and the second device is a vehicle device.
The device according to claim 50, characterized in that the first negotiation module further includes:

a second receiving module, configured to receive the first message sent by the first device, the first message containing first data, and the first data containing the temporary public key of the first device;

A generation module configured to generate the shared key based on the temporary public key of the first device and the temporary private key of the second device;

A first sending module, configured to send a second message to the first device, where the second message includes second data, the second data includes the temporary public key of the second device, and the second message contains the temporary public key of the second device. The temporary public key is used by the first device to generate the shared key.
The device according to claim 51, characterized in that:

The first data also includes one or more of the following information: a session identifier of the first device, a random number generated by the first device; and/or

The second data also includes one or more of the following information: a session identifier of the second device and a random number generated by the second device.
The device according to claim 51 or 52, characterized in that the device further includes:

A decryption module, configured to decrypt the first data according to the identification code of the first device.
The device according to claim 51, wherein the first data further includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.
The device according to claim 54, characterized in that the first destination identifier is obtained by the first device encrypting first information according to the identification code of the first device, and the first information includes One or more of the following information: the random number generated by the first device, the device identification of the second device, and the public key corresponding to the device certification center CA certificate of the first device.
The device of claim 55, further comprising:

An encryption module, configured to encrypt the first information according to the identification code of the first device to obtain a second destination identifier;

A verification module, configured to verify the identity of the first device according to the first destination identifier and the second destination identifier.
The device according to any one of claims 53 and 55-56, characterized in that the device further includes:

The second negotiation module is configured to negotiate a first identity code with the first device. The first identity code is used for the device corresponding to the first identity code to access the second device.
The device according to claim 57, characterized in that the second negotiation module further includes:

A third receiving module is configured to receive a third message sent by the first device, where the third message is used to configure the first identity code.
The device according to claim 58, characterized in that the second negotiation module further includes:

A fourth receiving module is configured to receive a fourth message sent by the first device, where the fourth message is used to instruct the second device to return the first identification code.
The device according to claim 59, wherein the fourth message carries information indicating that the first device does not have an identification code,

The device also includes:

A return module, configured to return the first identification code to the first device.
The device according to claim 60, characterized in that the first identification code returned by the second device is displayed on the display screen of the second device.
The device according to any one of claims 59-61, wherein the first identification code returned by the second device is a temporary identification code.
The device according to any one of claims 50-62, characterized in that the device further includes:

The third negotiation module is configured to negotiate the negotiation method of the shared key with the first device.
The device according to claim 63, characterized in that the third negotiation module further includes:

A fifth receiving module, configured to receive a fifth message sent by the first device, where the fifth message is used to indicate the key negotiation method supported by the first device;

The second sending module is configured to send a fifth response to the first device, where the fifth response is used to indicate negotiating the shared key based on the sigma protocol.
The device according to claim 64, wherein the key negotiation method supported by the first device and/or the second device includes one or more of the following methods: based on key pair negotiation, based on Node interoperability certificate negotiation, and negotiation based on sigma protocol.
The device according to any one of claims 50-65, characterized in that the shared key is generated by the second device according to one or more of the following information: the second key, the The random number generated by the second device, and the temporary public key of the second device, wherein the second key is the temporary public key of the second device based on the first device and the second device's temporary public key. Temporary private key generated.
A communication device, characterized in that the communication device is configured in a first device, the device includes a memory and a processor, the memory is used to store programs, and the processor is used to call the program in the memory to The first device is caused to perform the method according to any one of claims 1-16.
A communication device, characterized in that the communication device is configured in a second device, the device includes a memory and a processor, the memory is used to store programs, and the processor is used to call the program in the memory to The second device is caused to perform the method according to any one of claims 17-33.
A device, characterized by comprising a processor for calling a program from a memory, so that the device executes the method according to any one of claims 1-33.
A chip, characterized in that it includes a processor for calling a program from a memory, so that a device equipped with the chip executes the method according to any one of claims 1-33.
A computer-readable storage medium, characterized in that a program is stored thereon, and the program causes the computer to execute the method according to any one of claims 1-33.
A computer program product, characterized by comprising a program that causes a computer to execute the method according to any one of claims 1-33.
A computer program, characterized in that the computer program causes the computer to perform the method according to any one of claims 1-33.