WO2023230983A1

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

Info

Publication number: WO2023230983A1
Application number: PCT/CN2022/096827
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, a chip, and a storage medium. The method comprises: a first device negotiates a shared key with a second device according to a key pair of the first device (210), the key pair of the first device comprising a first public key and a first private key; the first device and the second device establish a shared key-based interoperation channel (220); the first device sends a control instruction to the second device by means of the interoperation channel (230), to control the second device, the first device being a terminal device, and the second device being a vehicle device. In embodiments of the present application, the first device and the second device may negotiate, on the basis of the key pair, the shared key corresponding to the interoperation channel, so as to ensure the security and reliability of communication of the interoperation channel, and realize security control of the second device by the first device. The manner of negotiating the shared key on the basis of the key pair is simple and easy to operate.

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.

A first aspect provides a method for establishing an interoperability channel, including: a first device negotiating a shared key with a second device based on a key pair of the first device, the key pair of the first device including a third device. A public key and a first private key; the first device and the second device establish an interoperability channel based on the shared key; the first device sends a message to the second device through the interoperability channel Control instructions to control the second device, wherein the first device is a terminal device and the second device is a vehicle device.

In a second aspect, a method for establishing an interoperability channel is provided, including: a second device negotiating a shared key with a first device based on a key pair of the second device, where the key pair of the second device includes a third device. two public keys and a second private key; the second device and the first device establish an interoperability channel based on the shared key; the second device receives the information of the first device through the interoperability channel. Control instructions, 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 configured to negotiate with a second device based on a key pair of the first device. Negotiate a shared key, the key pair of the first device includes a first public key and a first private key; an establishment module, used to establish an interoperability channel based on the shared key with the second device; a control module , used to send 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.

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 configured to negotiate with the first device based on a key pair of the second device. Negotiate a shared key, where the key pair of the second device includes the second public key and a second private key; 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 of the first device through the interoperation channel, where the first 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 solutions provided by the embodiments of this 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 this embodiment of the present application, the first device and the second device can negotiate the shared key corresponding to the interoperability channel based on the key pair, so as 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. security control. The method of negotiating shared keys based on key pairs is simple to implement and easy to operate.

Description of the drawings

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

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

FIG. 3 is a schematic flowchart of a possible implementation of step S210 in FIG. 2 .

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

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

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

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

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

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

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

Figure 11 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 can control the opening of car doors and windows, etc.

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 a key pair, which is simple and easy to operate. The method embodiments provided by the embodiments of the present application will be introduced in detail below with reference to the accompanying drawings.

Figure 2 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 2 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 FIG. 2 may include steps S210 to S230, and these steps will be described in detail below.

In step S210, the first device and the second device negotiate a shared key based on a keypair. It should be understood that the first device and the second device negotiate a shared key with the other party based on the key pair they own. Specifically, the first device can negotiate the shared key with the second device based on the key pair of the first device. , the second device can negotiate a shared key with the first device based on the key pair of the second device.

It should be understood that the key pair mentioned in the embodiment of this application may include a public key and a private key. In other words, the key pair of the first device may include the first public key and the first private key (or the first public key and the first private key constitute the key pair of the first device), and the key pair of the second device The key pair may include a second public key and a second private key (or the second public key and the second private key form a key pair of the second device). This embodiment of the present application does not limit the sources of the key pair of the first device and the key pair of the second device. In some embodiments, the key pair of the first device may be generated by the first device, and the key pair of the second device may be generated by the second device. Optionally, the key pair generated by the first device and/or the second device may be a temporary key pair, that is, the key pair is only valid during this shared key negotiation process. In some embodiments, the first device's key pair and the second device's key pair may be preconfigured.

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 a key pair. 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 S220, 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 S230, the first device controls the second device through the interoperation channel. For example, the first device may send a control instruction (also known as a control command, control signaling, etc.) 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 S210. A possible implementation of step S210 is given below with reference to FIG. 3 , and the process of the first device and the second device negotiating a shared key based on the key pair is described in detail. For example, step S210 may include steps S212 to S218, and these steps will be described in detail below.

In step S212, 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 the shared key. Therefore, in some embodiments, the first message may also be called a key agreement request message, or a key exchange request message, or the like.

In this embodiment of the present application, the first message includes first data, and the first data includes the first public key. As mentioned above, this application does not limit the source of the key pair of the first device. That is, the sources of the first public key and the first private key may include multiple sources. For example, the first public key and the first private key may be the first public key and the first private key. Generated by the device, such as the temporary public key and temporary private key generated before sending the first message, the temporary public key and the temporary private key form a key pair.

In some embodiments, the first data may also include other information in addition to the first public key. Exemplarily, the first data may also include one or more of the following information: a random number generated by the first device, a device identification of the first device, and a first signature, where the first signature is a username generated by the first device. The signature generated by the first private key.

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.

Both the device identification and the first signature of the first device can be used by the second device to authenticate the first device. In some embodiments, the first signature may include one or more of the following information: a first public key, a random number generated by the first device, and a device identification of the first device. The first device may encrypt one or more of the information using the first private key to generate the first signature. The first device may send the first signature and the content in the first signature to the second device, so that the second device uses the first public key to verify the first signature sent by the first device to verify the first signature of the first device. Verify the identity and prove that the key pair of the first device is authentic and not counterfeit.

It should be understood that the information contained in the first signature may be consistent with the information in the first data other than the first signature. For example, the first signature includes the first public key, the random number generated by the first device, the first The device identification of the device, then, in addition to the first signature, the corresponding first data should also include the first public key, the random number generated by the first device, and the device identification of the first device.

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

As mentioned above, this application does not limit the source of the key pair of the second device. That is, the sources of the second public key and the second private key may include multiple sources. For example, the second public key and the second private key may be The temporary public key and the temporary private key are generated by the second device, for example, after receiving the first message sent by the first device. The temporary public key and the temporary private key form a key pair.

In some embodiments, the second device generating the shared key according to the first public key and the second private key may mean that the second device generates the second key according to the first public key and the second private key, and then generates the second key according to the first public key and the second private key. Two keys generate a shared secret. Exemplarily, 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 first device, a random number generated by the second device, the device of the first device identification, the device identification of the second device, and the identification code of the first device. As an implementation manner, the second device can use one or more of the information as key parameters and use a key algorithm to generate the shared key.

It should be noted that the random number generated by the first device and the device identification of the first device may be carried by the first device in the first message. The random number generated by the second device may be temporarily generated by the second device before generating the shared key. 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.

In some embodiments, the second device can first verify the identity of the first device before generating the shared key. The verification may mean that the second device can verify the first signature using the first public key.

In step S216, the second device sends a first response to the first device. The first response can be understood as a response message returned by the second device in response to the first message sent by the first device. The response mentioned later can also refer to The response message returned for a certain message will not be described in detail later. The first response contains the second data. The second data contains the second public key.

In some embodiments, the second data is data encrypted by the second device using the first public key.

In some embodiments, the second data may also contain other information in addition to the second public key. Exemplarily, the second data may also include one or more of the following information: a random number generated by the second device, a device identification of the second device, and a second signature, where the second signature is a username generated by the second device. The signature generated by the second private key.

For the sake of simplicity, the relevant description of the random number generated by the second device can be found in the previous relevant description of the random number generated by the first device, and will not be described again here.

Both the device identification and the second signature of the second device can be used by the first device to authenticate the second device. In some embodiments, the second signature may include one or more of the following information: a second public key, a random number generated by the second device, and a device identification of the second device. Regarding the verification process of the second signature by the first device, please refer to the aforementioned verification process of the first signature by the second device.

The embodiment of the present application does not limit the execution order of step S214 and step S216. In some embodiments, step S216 may be performed earlier than step S214, or step S214 and step S216 may be performed simultaneously.

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

In some embodiments, the first device generating the shared key according to the second public key and the first private key may mean that the first device generates the first key according to the second public key and the first private key, and then generates the first key according to the second public key and the first private key. A key generates a shared secret. Exemplarily, 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, a random number generated by the second device, a device of the first device identification, the device identification of the second device, and the identification code 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.

As mentioned above, the first message sent by the first device to the second device includes the first data. In some embodiments, the first data is encrypted data. Next, the encryption of the first data by the first device will be described in detail with reference to FIG. 3 .

Continuing to refer to Figure 3, in some embodiments, before step S212, the method provided by the embodiment of the present application may further include step S211. In step S211, the first device encrypts the first data according to the identification code of the first device.

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 to prevent the first data from being leaked during transmission.

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

After the first device encrypts the first data according to the identification code of the first device, after the second device receives the first data, it needs to decrypt the first data according to the identification code of the first device. Only after the second device successfully decrypts the first data can it learn the first public key and other information in the first data, thus avoiding the problem of easy leakage caused by the clear text transmission of the first public key.

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 according to the identification code of the first device, the first device can also negotiate the first identification code with the second device, and the first identification code can be used for the first identification code. When a device corresponding to one identification code accesses a second device, that is, when a device wants to access a second device, it needs its corresponding first identification code as a credential to achieve access to the second device. 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. 4 and FIG. 5 respectively.

Figure 4 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 4, in step S410, the first device sends a second message to the second device, and the second 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 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, 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 5 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 5, in step S510, the first device sends a third message to the second device, and the third 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 third message to the second device, and the third message may carry information indicating that the first device does not have an identity code, for example The third 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 S520, after receiving the third 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 third message, the second device knows that the first device does not have an identification code according to the third message. 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 third response to the first device. The third 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.

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 FIG. 6 .

In step S610, the first device sends a fourth message to the second device, where the fourth 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-based negotiation, node-based Interoperability certificate negotiation and sigma protocol negotiation.

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 a key pair, and the type of the corresponding interoperation channel is an interoperation channel based on the key pair. 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 fourth message may also be called an interoperation session establishment request message, which is not limited by this application.

In step S620, the second device sends a fourth response to the first device, where the fourth response is used to indicate negotiating a shared key based on the key pair.

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

As another implementation manner, after receiving the fourth message, the second device may indicate the key negotiation method supported by the second device in the fourth 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, node interoperability certificate-based negotiation, and sigma protocol-based negotiation.

For example, if the second device only supports shared key negotiation based on a key pair, then the fourth response only contains the method of negotiating a shared key based on a key pair. After receiving the fourth response, the first device can directly determine that the shared key is negotiated based on a key pair. Negotiate a shared secret key with the second device. Alternatively, the second device supports multiple key negotiation methods, for example, including key pair-based negotiation and sigma protocol-based negotiation. Then, after receiving the fourth response, the first device can use the key negotiation method supported by the second device. Choose one of the methods. 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 a key pair.

In order to facilitate those skilled in the art to understand the implementation process of the technical solutions of the embodiments of this application, two 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)

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

In step S7010, 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 S7020, the first device sends a second message to the second device. The second message is used to configure the first identification code and the index corresponding to the first identification code, for example, configure the tuple information <pincode, pincode_index>, so that the first 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 information related to the first identification code that can access the second device.

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 S7030, 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 S7040, 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 to the second device, the first device can also configure some basic configurations to the second device. After the identity code and basic configuration are completed, the first device communicates with the second device. The configuration between devices is completed and the configuration channel is exited.

In step S7050, the first device sends a fourth message to the second device, where the fourth 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, node interoperability certificate-based negotiation, and sigma protocol-based negotiation.

In step S7060, the second device returns a fourth response to the first device. The fourth 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 based on key pair negotiation.

In step S7070, 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 and a temporary key pair (the first public key and the first private key), and then use the first private key to pair the first public key, the random number r1, and the first private key. One or more of the device identification and other information of a device are encrypted to obtain the signature sign1, and further the first data is obtained. The first data may include one or more of the following information: the first public key, the random number r1, The device identification and signature of the first device, sign1. After obtaining the first data, the first device can encrypt the first data using the identification code of the first device.

In step S7080, the first device sends a first message to the second device. The first message may carry the first data encrypted using the identity code of the first device and the index corresponding to the identity 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 S7090, the second device generates a shared key based on the first public key and the second private key.

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 the second device decrypts the first data, it can use the first public key to verify the signature sign1 to verify the identity of the first device and the authenticity of the key pair of the first device.

In some embodiments, after the second device decrypts the first data, it can generate a random number r2 and a temporary key pair (the second public key and the second private key), and then use the second private key to pair the second public key and the random key. One or more of the number r2 and the device identification of the second device are encrypted to obtain the signature sign2, and further the second data is obtained. The second data may include one or more of the following information: the second public key , random number r2, device identification of the second device, and signature sign2.

Based on this, the second device can generate a shared key based on one or more of the following information: the second key generated based on the first public key and the second private key, the random number r1, the random number r2, the first device device identification, the device identification of the second device, the identification code of the first device, etc.

In step S7100, the second device sends a first response to the first device, where the first response carries second data encrypted using the first public key.

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

In some embodiments, after receiving the first response, the first device can decrypt the second data using the first private key and use the second public key to decrypt the signature sign2 to verify the identity of the second device.

Based on this, the first device can generate a shared key based on one or more of the following information: the first key generated based on the second public key and the first private key, the random number r1, the random number r2, the first device device identification, the device identification of the second device, the identification code of the first device, etc.

In step S7120, the first device may return a key negotiation result to the second device, and the result may be used to indicate that the first device has determined the shared key.

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

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

Example 2 (using temporary identification code)

Figure 8 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 8, the method may include steps S8010 to S8130.

In step S8010, the first device and the second device complete basic configuration and exit the configuration channel.

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

In step S8030, the second device returns a fourth response to the first device. The fourth 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 based on key pair negotiation.

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

In some embodiments, the third 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 S8050, the second device returns a first identification code to the first device. The first identification code may be a temporary identification code.

In some embodiments, the second device may send a third 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 S8060, the first device encrypts the first data using the identification code of the first device.

As an implementation method, after the first device inputs the temporary identity code, it can first generate a random number r1 and a temporary key pair (first public key and first private key), and then use the first private key to pair the first public key , random number r1, and the device identification of the first device and other information are encrypted to obtain the signature sign1, and further obtain the first data. The first data may include one or more of the following information: first Public key, random number r1, device identification of the first device, and signature sign1. After obtaining the first data, the first device can encrypt the first data using the identification code of the first device.

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

In step S8070, 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 full F value, and the full F value is used to indicate that the first device has a temporary identification code.

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

In step S8090, the second device sends a first response to the first device, where the first response carries second data encrypted using the first public key.

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

In step S8110, the first device may return a key negotiation result to the second device, and the result may be used to indicate that the first device has determined the shared key.

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

In step S8130, 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 8 , and the device embodiments of the present application are described in detail below with reference to FIGS. 9 to 11 . 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 9 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 900 shown in FIG. 9 may include a first negotiation module 910, an establishment module 920 and a control module 930.

The first negotiation module 910 may be configured to negotiate a shared key with the second device according to a key pair of the first device, where the key pair of the first device includes a first public key and a first private key.

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

The control module 930 may be used to send a control instruction 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, where the first message includes first data, the first data includes a first public key, and the first public key is used to The second device generates a shared key; a first receiving module is configured to receive a first response from the second device, the first response includes second data, and the second data includes a second public key, a second public key and a second private key. A key pair constituting the second device; a generating module configured to generate a shared key based on the second public key and the first private key.

Optionally, the first data also includes one or more of the following information: a random number generated by the first device, a device identification of the first device, and a first signature; and/or the second data also includes the following information. One or more of: the random number generated by the second device, the device identification of the second device, and the second signature.

Optionally, the first signature is obtained by the first device using the first private key to encrypt one or more of the following information: the first public key, a random number generated by the first device, and the device identification of the first device. ; The second signature is obtained by the second device using the second private key to encrypt one or more of the following information: the second public key, a random number generated by the second device, and the device identification of the second device.

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

Optionally, the apparatus 900 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 second message to the second device, where the second message is used to configure the first identity code.

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

Optionally, the third message carries information indicating that the first device does not have an identification code. The apparatus 900 further includes: a second receiving module configured to receive the first identification code returned by the second device for the first 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 900 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 fourth message to the second device, where the fourth message is used to indicate the key negotiation method supported by the first device; and a third receiving module, configured to A fourth response is received from the second device, the fourth response being used to indicate negotiating a shared key based on the key pair.

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, a random number generated by the second device, the device of the first device identification, the device identification of the second device, and the identification code of the first device, where the first key is generated by the first device based on the second public key and the first private key.

Figure 10 is a schematic structural diagram of a device for establishing an interoperability channel provided by another embodiment of the present application. The device may be configured in the second device mentioned above. The device 1000 shown in FIG. 10 may include a first negotiation module 1010, an establishment module 1020, and a first receiving module 1030.

The first negotiation module 1010 may be configured to negotiate a shared key with the first device according to a key pair of the second device, where the key pair of the second device includes a second public key and a second private key.

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

The first receiving module 1030 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 includes the first data, the first data includes the first public key, the first public key and The first private key forms a key pair of the first device; the generating module is used to generate a shared key based on the first public key and the second private key; the first sending module is used to send a first response to the first device, The first response includes second data, the second data includes a second public key, and the second public key is used by the first device to generate a shared key.

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

Optionally, the apparatus 1000 further includes: a second negotiation module, configured to negotiate 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.

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

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

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

Optionally, the apparatus 1000 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 fourth message sent by the first device, where the fourth message is used to indicate the key negotiation method supported by the first device; a second sending module, configured to A fourth response is sent to the first device, where the fourth response is used to indicate that the shared key is negotiated based on the key pair.

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

In an optional embodiment, the device 900 for establishing an interoperation channel and/or the device 1000 for establishing an interoperation channel may also include a transceiver 1130 and a memory 1120, as specifically shown in FIG. 11 .

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

Apparatus 1100 may include one or more processors 1110. The processor 1110 can support the device 1100 to implement the method described in the foregoing method embodiments. The processor 1110 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 1100 may also include one or more memories 1120. The memory 1120 stores a program, which can be executed by the processor 1110, so that the processor 1110 executes the method described in the foregoing method embodiment. The memory 1120 may be independent of the processor 1110 or integrated in the processor 1110 .

Device 1100 may also include a transceiver 1130. Processor 1110 may communicate with other devices or chips through transceiver 1130. For example, the processor 1110 can transmit and receive data with other devices or chips through the transceiver 1130 .

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 the solution 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 based on the key pair of the first device, where the key pair of the first device includes a first public key and a first private key;

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 of claim 1, wherein the first device negotiates a shared key with the second device based on the key pair of the first device, including:

The first device sends a first message to the second device, the first message includes first data, the first data includes the first public key, and the first public key is used for the first The second device generates the shared key;

The first device receives a first response from the second device, the first response includes second data, the second data includes a second public key, and the second public key and the second private key constitute the The key pair of the second device;

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

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

The second data also includes one or more of the following information: a random number generated by the second device, a device identification of the second device, and a second signature.
The method of claim 3, wherein the first signature is obtained by the first device using the first private key to encrypt one or more of the following information: the first Public key, random number generated by the first device, and device identification of the first device;

The second signature is obtained by the second device using the second private key to encrypt one or more of the following information: the second public key, a random number generated by the second device, The device identifier of the second device.
The method according to any one of claims 2-4, 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 according to claim 5, characterized in that, before the first device encrypts the first data according to the identification code of the first device, 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 6, characterized in that the first device negotiates the first identity code with the second device, including:

The first device sends a second message to the second device, where the second message is used to configure the first identity code.
The method according to claim 6, characterized in that the first device negotiates the first identity code with the second device, including:

The first device sends a third message to the second device, where the third message is used to instruct the second device to return the first identification code.
The method of claim 8, wherein the third 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 9, 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 8-10, 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-11, characterized in that, before the first device negotiates a shared key with the second device according to the key pair of the first device, the method further includes :

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

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

The first device receives a fourth response from the second device, the fourth response being used to indicate negotiating the shared key based on a key pair.
The method according to claim 13, 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-14, 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, the random number generated by the second device, the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein, The first key is generated by the first device based on the second public key and the first private key.
A method for establishing an interoperability channel, which is characterized by including:

The second device negotiates a shared key with the first device based on the key pair of the second device, where the key pair of the second device includes a second public key and a second private key;

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 of claim 16, wherein the second device negotiates a shared key with the first device based on the key pair of the second device, including:

The second device receives the first message sent by the first device, the first message contains first data, the first data contains a first public key, and the first public key and the first private key are composed of The key pair of the first device;

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

The second device sends a first response to the first device, the first response includes second data, the second data includes the second public key, and the second public key is used for the first A device generates the shared key.
The method according to claim 17, characterized in that:

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

The second data also includes one or more of the following information: a random number generated by the second device, a device identification of the second device, and a second signature.
The method of claim 18, wherein the first signature is obtained by the first device using the first private key to encrypt one or more of the following information: the first Public key, random number generated by the first device, and device identification of the first device;

The second signature is obtained by the second device using the second private key to encrypt one or more of the following information: the second public key, a random number generated by the second device, The device identifier of the second device.
The method according to any one of claims 17-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 according to claim 20, characterized in that, before the second device decrypts the first data according to the identification code of the first device, 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 21, characterized in that the second device negotiates the first identity code with the first device, including:

The second device receives a second message sent by the first device, and the second message is used to configure the first identity code.
The method according to claim 21, 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, and the third message is used to instruct the second device to return the first identification code.
The method of claim 23, wherein the third 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 24, 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 23 to 25, 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 16-26, characterized in that, before the second device negotiates a shared key with the first device according to the key pair of the second device, the method further includes :

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

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

The second device sends a fourth response to the first device, where the fourth response is used to indicate negotiating the shared key based on a key pair.
The method according to claim 28, 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 16-29, 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 first device, the random number generated by the second device, the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein, The second key is generated by the second device based on the first public key and the second private key.
A device for establishing an interoperability channel, characterized in that the device is configured on a first device, and the device includes:

A first negotiation module configured to negotiate a shared key with a second device based on a key pair of the first device, where the key pair of the first device includes a first public key and a first private key;

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 31, 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, where the first data includes the first public key, and the first public key is used for the The second device generates the shared key;

A first receiving module, configured to receive a first response from the second device, the first response containing second data, the second data containing a second public key, the second public key and a second private key A key pair constituting the second device;

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

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

The second data also includes one or more of the following information: a random number generated by the second device, a device identification of the second device, and a second signature.
The device according to claim 33, wherein the first signature is obtained by the first device using the first private key to encrypt one or more of the following information: the first Public key, random number generated by the first device, and device identification of the first device;

The second signature is obtained by the second device using the second private key to encrypt one or more of the following information: the second public key, a random number generated by the second device, The device identifier of the second device.
The device according to any one of claims 32-34, 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 device of claim 35, further comprising:

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 36, characterized in that the second negotiation module further includes:

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

A third sending module is configured to send a third message to the second device, where the third message is used to instruct the second device to return the first identification code.
The device according to claim 38, wherein the third 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 39, 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 38 to 40, 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 31-41, 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 42, characterized in that the third negotiation module further includes:

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

A third receiving module configured to receive a fourth response from the second device, where the fourth response is used to indicate negotiating the shared key based on a key pair.
The device according to claim 43, 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 device according to any one of claims 31-44, 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, the random number generated by the second device, the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein, The first key is generated by the first device based on the second public key and the first private key.
A device for establishing an interoperability channel, characterized in that the device is configured on a second device, and the device includes:

A first negotiation module configured to negotiate a shared key with the first device based on the key pair of the second device, where the key pair of the second device includes a second public key and a second private key;

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 46, wherein the first negotiation module further includes:

The second receiving module is configured to receive the first message sent by the first device, the first message includes first data, the first data includes a first public key, the first public key and the first private key. The key constitutes a key pair of the first device;

A generating module, configured to generate the shared key according to the first public key and the second private key;

A first sending module, configured to send a first response to the first device, where the first response includes second data, the second data includes the second public key, and the second public key is used for the The first device generates the shared key.
The device according to claim 47, characterized in that:

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

The second data also includes one or more of the following information: a random number generated by the second device, a device identification of the second device, and a second signature.
The apparatus according to claim 48, wherein the first signature is obtained by the first device using the first private key to encrypt one or more of the following information: the first Public key, random number generated by the first device, and device identification of the first device;

The second signature is obtained by the second device using the second private key to encrypt one or more of the following information: the second public key, a random number generated by the second device, The device identifier of the second device.
The device according to any one of claims 47-49, 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 50, 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 51, characterized in that the second negotiation module further includes:

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

The fourth receiving module is configured to receive a third message sent by the first device, where the third message is used to instruct the second device to return the first identification code.
The device according to claim 53, wherein the third 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 54, 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 53-55, 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 46-56, 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 57, characterized in that the third negotiation module further includes:

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

The second sending module is configured to send a fourth response to the first device, where the fourth response is used to indicate negotiating the shared key based on a key pair.
The device according to claim 58, 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 device according to any one of claims 46-59, 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 first device, the random number generated by the second device, the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein, The second key is generated by the second device based on the first public key and the second private key.
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-15.
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 16-30.
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-30.
A chip, characterized in that it includes a processor for calling a program from a memory, so that a device installed with the chip executes the method according to any one of claims 1-30.
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-30.
A computer program product, characterized by comprising a program that causes a computer to execute the method according to any one of claims 1-30.
A computer program, characterized in that the computer program causes the computer to perform the method according to any one of claims 1-30.