Method and device for establishing interoperation channel, chip and storage medium

Abstract

The invention provides a method and device for establishing an interoperation channel, a chip and a storage medium. The method comprises: a first device negotiating 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 an interoperation channel based on the shared key (220); the first device sends a control instruction to a second device through 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 the embodiment of the invention, the first equipment and the second equipment can negotiate the shared key corresponding to the interoperation channel based on the key pair, so that the communication security and reliability of the interoperation channel are ensured, and the security control of the first equipment on the second equipment is realized. The mode of negotiating the shared key based on the key pair is simple to implement and easy to operate.

Description

Method, device, chip and storage medium for establishing an interoperability channel Technical Field

[0001] 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 Art

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

[0003] In related technologies, to ensure the security and reliability of interoperability channel communications, encrypted communication over the interoperability channel can be performed based on a shared key. However, how devices negotiate the shared key corresponding to the interoperability channel is an urgent problem to be solved.

[0004] Summary of the Invention

[0005] The present application provides a method, device, chip, and storage medium for establishing an interoperability channel. The following introduces various aspects of the present application.

[0006] In a first aspect, a method for establishing an interoperability channel is provided, comprising: a first device negotiates a shared key with a second device based on a key pair of the first device, 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 an interoperability channel based on the shared key; the first device sends a control instruction 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.

[0007] In a second aspect, a method for establishing an interoperability channel is provided, including: a second device negotiates a shared key with a first device based on a key pair of the second device, the key pair of the second device including 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 a control instruction of the first device through the interoperability channel, wherein the first device is a terminal device and the second device is a vehicle device.

[0008] In a third aspect, a device for establishing an interoperability channel is provided, which is configured on a first device and includes: a first negotiation module, used to negotiate a shared key with a second device based on a key pair of the first device, wherein 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; and a control module, used to send a control instruction 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.

[0009] In a fourth aspect, a device for establishing an interoperability channel is provided, which is configured on a second device and includes: a first negotiation module, used to negotiate a shared key with the first device based on a key pair of the second device, the key pair of the second device including the second public key and the second private key; an establishment module, used to establish an interoperability channel based on the shared key with the first device; a first receiving module, used to receive control of the first device through the interoperability channel, wherein the first device is a terminal device and the second device is a vehicle device.

[0010] In a fifth aspect, a communication device is provided, which is configured in a first device, and 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 call the computer program in the memory so that the first device performs some or all of the steps in the method of the first aspect.

[0011] In the sixth aspect, a communication device is provided, which is configured in a second device, and 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 call the computer program in the memory so that the second device performs some or all of the steps in the method of the second aspect.

[0012] In a seventh aspect, an embodiment of the present application provides a communication system, which includes the above-mentioned communication device. In another possible design, the system may also include other devices that interact with the communication device in the solution provided in the embodiment of the present application.

[0013] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program enables a communication device to execute part or all of the steps in the methods of the above aspects.

[0014] 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, wherein the computer program is operable to cause a communication device to perform some or all of the steps of the methods described in each of the above aspects. In some implementations, the computer program product may be a software installation package.

[0015] In the tenth aspect, an embodiment of the present application provides 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.

[0016] In the embodiment of the present application, the first device and the second device can negotiate a shared key corresponding to the interoperability channel based on a key pair to ensure the security and reliability of communication in the interoperability channel and implement secure control of the second device by the first device. The method of negotiating a shared key based on a key pair is simple to implement and easy to operate. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG1 is a diagram illustrating an example architecture of a wireless communication system applicable to an embodiment of the present application.

[0018] FIG2 is a flow chart of a method for establishing an interoperability channel provided in an embodiment of the present application.

[0019] FIG3 is a flow chart of a possible implementation of step S210 in FIG2 .

[0020] FIG4 is a schematic diagram of a process of negotiating a first identity identification code according to an embodiment of the present application.

[0021] FIG5 is a schematic diagram of a process of negotiating a first identity identification code according to another embodiment of the present application.

[0022] FIG6 is a flow chart of a method for negotiating a shared key according to an embodiment of the present application.

[0023] FIG7 is a flowchart of a method for establishing an interoperability channel provided in another embodiment of the present application.

[0024] FIG8 is a flowchart of a method for establishing an interoperability channel provided in another embodiment of the present application.

[0025] FIG9 is a schematic structural diagram of an apparatus for establishing an interoperability channel provided in an embodiment of the present application.

[0026] FIG10 is a schematic structural diagram of an apparatus for establishing an interoperability channel provided in another embodiment of the present application.

[0027] FIG11 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The technical solution in this application will be described below with reference to the accompanying drawings.

[0029] Figure 1 is a diagram illustrating an exemplary architecture of a wireless communication system 100 applicable to embodiments of the present application. As shown in Figure 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 interoperability channel to implement interoperability between the first device 110 and the second device 120. For example, this may enable the first device to control the second device.

[0030] In some embodiments, the first device 110 and the second device 120 can establish a connection for communication through a wired (e.g., USB interface) or wireless network (e.g., Bluetooth or mobile network) to achieve interoperability between the first device 110 and the second device 120.

[0031] Figure 1 exemplarily shows a first device 110 and a second device 120, but the embodiments of the present application are 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 control from multiple first devices.

[0032] Optionally, the wireless communication system 100 may further 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 may communicate with the third device through the second device 120. For example, the first device 110 may control or access the third device through the second device 120. Optionally, in this scenario, the second device 120 may be understood as a relay device or a bridge device.

[0033] 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 (5G) system or new radio (NR), long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD) system, Bluetooth system, wireless fidelity (WiFi) system, etc. The technical solutions provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system, satellite communication system, etc.

[0034] In some embodiments, the first device and the second device in the embodiments of the present application may be referred to as a first terminal device and a second terminal device, respectively. The terminal device may also be referred to as user equipment (UE), access terminal, subscriber unit, subscriber station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device.

[0035] The first device and the second device in the embodiments of the present application may refer to devices that provide voice and / or data connectivity to users, and may be used to connect people, objects, and machines, such as handheld devices and vehicle-mounted devices with wireless connection capabilities. For example, the first device and / or the second device in the embodiments of the present application may be a mobile phone, a tablet computer (Pad), a laptop computer, a PDA, a mobile internet device (MID), a wearable device, an Internet of Things (IoT) device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc.

[0036] The embodiments of this application do not limit the types of IoT devices. In some embodiments, IoT devices may include smart transportation vehicles, ships, and other smart travel tools. In some embodiments, IoT devices may include smart home appliances such as smart TVs, smart air conditioners, smart refrigerators, and robot vacuums. In some embodiments, IoT devices may include smart monitoring devices such as surveillance cameras, temperature sensors, and sound sensors.

[0037] Furthermore, when the IoT device is a vehicle, the vehicle may 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 may be, for example, a floor-standing air conditioner, a wall-mounted air conditioner, etc., and this application does not limit this.

[0038] In some embodiments, the first device 110 and the second device 120 can be different types of devices to enable interoperability between different types of devices. For example, the first device 110 can be a handheld terminal device such as a mobile phone or tablet computer, and the second device 120 can be an IoT device (e.g., a vehicle, smart air conditioner, etc.). Based on this, the handheld terminal device can control the IoT device (vehicle, smart air conditioner, etc.).

[0039] In some embodiments, the first device 110 and the second device 120 may be devices from different manufacturers to enable interoperability between devices from 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 can control the device produced by the second manufacturer.

[0040] The embodiments of the present 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 can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted.

[0041] 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).

[0042] It should be understood that the interoperability between the first device and the second device, or the control of the second device by the first device mentioned in the embodiments of the present application may refer to interoperability or control between different types of devices, or may refer to interoperability or control between devices of different manufacturers, etc. The embodiments of the present application are not limited to this. For example, it may also refer to interoperability or control between devices of the same manufacturer, etc., as long as the first device and the second device can achieve interoperability, or control and be controlled.

[0043] It should be understood that the technical solutions provided in the embodiments of the present application can be applied to any scenario where devices interoperate with each other, such as between terminal devices and IoT devices. The following describes the application scenarios of the embodiments of the present application with reference to two specific examples, which are not intended to limit the present application.

[0044] As an example, the second device can be a smart travel tool such as a vehicle or ship, and the first device can be a terminal device that can control the smart travel tool, such as a mobile phone, tablet computer, or laptop computer. 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 establish an interoperability channel to enable the mobile phone to control the vehicle, for example, the mobile phone can control the vehicle to open the door or window.

[0045] As another example, the second device may be a smart home device such as a smart air conditioner or a smart TV, and the first device may also be a terminal device that controls the smart home device, such as a mobile phone or tablet. After the first device establishes an interoperability channel with the smart home device, the first device can control the smart home device, for example, turning on the air conditioner, turning on the TV, adjusting the air conditioner temperature, or adjusting the air conditioner mode.

[0046] In recent years, with the rapid development of communication technologies, the application scenarios of interoperability between different devices have become more frequent. In some communication systems (for example, NR systems), different devices can achieve interoperability by establishing interoperability channels, for example, enabling one device to control another device.

[0047] However, current solutions for establishing interoperability channels between different devices are incomplete and inconsistent. One possible implementation approach, to ensure the security and reliability of interoperability channels, is to encrypt communication using a shared key. However, how devices negotiate the shared key for the interoperability channel remains an urgent issue.

[0048] To address the above issues, the present invention provides a method, device, chip, storage medium, and program product for establishing an interoperability channel. These methods facilitate negotiation of a shared key corresponding to the interoperability channel based on a key pair, thus simplifying and simplifying operations. The following describes the method embodiments provided by the present invention in detail, with reference to the accompanying drawings.

[0049] FIG2 is a flow chart of a method for establishing an interoperability channel according to an embodiment of the present application. The method shown in FIG2 is described from the perspective of interaction between a first device and a second device. The first device and the second device may be, for example, the first device 110 and the second device 120 in FIG1 .

[0050] The embodiments of this 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 with each other or the first device can control the second device. For example, the second device can be an IoT device, such as a smart travel tool such as a vehicle or ship, or a smart home device such as a smart air conditioner or smart TV, etc.; the first device can be a terminal device that can control the IoT device. For example, in some embodiments, the first device can be a terminal device, and the second device can be a vehicle device.

[0051] The method shown in FIG2 may include steps S210 to S230 , which are described in detail below.

[0052] In step S210, the first device and the second device negotiate a shared key based on a key pair. It should be understood that the first device and the second device negotiate a shared key with each other based on their respective key pairs. Specifically, the first device can negotiate a shared key with the second device based on the first device's key pair, and the second device can negotiate a shared key with the first device based on the second device's key pair.

[0053] It should be understood that the key pair mentioned in the embodiment of the present application may include a public key and a private key. In other words, the key pair of the first device may include a first public key and a 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 may include a second public key and a second private key (or, the second public key and the second private key constitute the key pair of the second device). The 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 the process of negotiating the shared key. In some embodiments, the key pair of the first device and the key pair of the second device may be preconfigured.

[0054] In some embodiments, before negotiating a shared key, the first device and the second device may negotiate to determine a shared key negotiation method based on the key negotiation methods (or types) supported by the first device and the second device, respectively. In an embodiment of the present application, the shared key negotiation method determined by the first device and the second device is: negotiating the shared key based on a key pair. How the first device and the second device negotiate to determine the shared key negotiation method will be described in detail later and will not be elaborated on here.

[0055] In the embodiments of the present application, the shared key negotiated between the first and second devices is known only to the first and second devices, and the first and second devices can perform encrypted communication based on the negotiated shared key. During the negotiation of the shared key, the first and second devices can generate the shared key based on one or more pieces of information. A detailed description of how the first and second devices negotiate or generate the shared key is provided below and is not further elaborated here.

[0056] In some embodiments, the first device and the second device may use some key algorithms to generate a shared key. For example, both devices may use the same key algorithm to generate a shared key to ensure the correspondence and consistency of the generated shared keys. The embodiments of the present application do not limit the specific type of the key algorithm. Exemplarily, the key algorithm may be a symmetric encryption algorithm, such as the Data Encryption Standard (DES) algorithm, the Advanced Encryption Standard (AES) algorithm, etc.

[0057] In step S220, the first device and the second device establish an interoperability channel based on a 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 secure 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 the security of communication.

[0058] As mentioned above, the first device and the second device can use the interoperability channel to realize the control of the first device over the second device (interoperability between devices). In the embodiment of the present application, the interoperability channel can be understood as a control channel (or, a secure control channel). After the interoperability channel is established between the first device and the second device, the first device can control the second device through the interoperability channel. After the first device and the second device establish an interoperability channel based on a 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 parties, thereby strengthening the security protection of information (such as data, instructions, etc.) in the interoperability channel and improving the security level of communication.

[0059] In some embodiments, when the first device and the second device establish an interoperability channel based on a shared key, the shared key corresponding to each establishment of the interoperability channel can be different and random, that is, before the first device and the second device establish an interoperability channel each time, they can first agree on a new shared key, and then use the shared key to perform encrypted communication and other processing, thereby further improving the security of communication in the interoperability channel.

[0060] In step S230, the first device controls the second device through the interoperability channel. For example, the first device can send a control instruction (or control command, control signaling, etc.) to the second device through the interoperability channel to control the second device.

[0061] In some embodiments, a first device controlling a second device may mean that the first device controls the second device to perform certain operations, such as opening, closing, or adjusting operations. As an example, when the second device is a vehicle, the first device controlling the second device may mean opening a door or closing a window. As another example, when the second device is a smart air conditioner, the first device controlling the second device may mean turning on the air conditioner, adjusting the air conditioner mode, or adjusting the temperature.

[0062] In some embodiments, a first device controlling a second device may refer to the first device accessing a resource of the second device. For 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, the first device performs some operation on the second device.

[0063] In the embodiment of the present application, the first device and the second device can negotiate a shared key corresponding to the interoperability channel based on a key pair to ensure the security and reliability of communication in the interoperability channel and implement secure control of the second device by the first device. The method of negotiating a shared key based on a key pair is simple to implement and easy to operate.

[0064] The present embodiment does not limit the implementation of step S210. A possible implementation of step S210 is provided below in conjunction with FIG3 , detailing the process by which the first device and the second device negotiate a shared key based on the key pair. For example, step S210 may include steps S212 through S218, which are described in detail below.

[0065] In step S212, the first device sends a first message to the second device. The first message may be used to request the second device to negotiate a shared key. Therefore, in some embodiments, the first message may also be referred to as a key negotiation request message, or a key exchange request message, etc.

[0066] In an embodiment of the present application, the first message includes first data, and the first data includes a first public key. As mentioned above, the present 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 can include multiple sources. For example, the first public key and the first private key can be generated by the first device, such as a temporary public key and a temporary private key generated before sending the first message, and the temporary public key and the temporary private key constitute a key pair.

[0067] In some embodiments, the first data may include other information in addition to the first public key. For example, the first data may include one or more of the following information: a random number generated by the first device, a device identifier of the first device, and a first signature, where the first signature is a signature generated by the first device using the first private key.

[0068] The random number generated by the first device can be used to prevent replay attacks. In authentication protocols or data encryption transmission systems, random numbers can be used as seed data or seed vectors to participate in identity verification or data validity determination between the first and second devices. It should be understood that the random number generated by the first device can be different and random each time the first and second devices negotiate a shared key. Preferably, the random number generated by the first device can be a true random number.

[0069] 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 this information using a 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 can use the first public key to verify the first signature sent by the first device to verify the identity of the first device and prove that the key pair of the first device is authentic and not counterfeit.

[0070] 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 contains the first public key, the random number generated by the first device, and the device identification of the first device. Then, in addition to the first signature, the corresponding first data should also contain the first public key, the random number generated by the first device, and the device identification of the first device.

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

[0072] 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 generated by the second device, such as a temporary public key and a temporary private key generated after receiving the first message sent by the first device, and the temporary public key and the temporary private key constitute a key pair.

[0073] In some embodiments, the second device generating a shared key based on the first public key and the second private key may mean that the second device generates a second key based on the first public key and the second private key, and then generates the shared key based on the second key. For example, the second device may generate the shared key based on the second key and one or more of the following information: a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity identification code of the first device. As an implementation, the second device may use one or more of this information as key parameters and use a key algorithm to generate the shared key.

[0074] It should be noted that the random number generated by the first device and the device identifier 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 identity identification code of the first device may be configured in advance by the first device for the second device or may be generated by the second device. The identity identification code of the first device will be described in detail later and will not be repeated here.

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

[0076] 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 below may also refer to a response message returned in response to a specific message, which will not be further described below. The first response includes second data. The second data includes the second public key.

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

[0078] In some embodiments, the second data may include other information in addition to the second public key. For example, the second data may include one or more of the following information: a random number generated by the second device, a device identifier of the second device, and a second signature, where the second signature is a signature generated by the second device using the second private key.

[0079] For the sake of brevity, the description of the random number generated by the second device can refer to the description of the random number generated by the first device above, which will not be repeated here.

[0080] 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 the device identification of the second device. For details on the verification process of the second signature by the first device, see the previous section on the verification process of the first signature by the second device.

[0081] The embodiment of the present application does not limit the execution order of step S214 and step S216. In some embodiments, step S216 can be executed earlier than step S214, or step S214 and step S216 can be executed at the same time.

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

[0083] In some embodiments, the first device generating a shared key based on the second public key and the first private key may mean that the first device generates a first key based on the second public key and the first private key, and then generates a shared key based on the first key. For example, the first device may generate the shared key based on the first key and one or more of the following information: a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity identification code of the first device. As an implementation, the first device may use one or more of this information as key parameters and a key algorithm to generate the shared key. For example, the first device may use the same key algorithm as the second device to generate the shared key.

[0084] As described above, the first message sent by the first device to the second device includes first data. In some embodiments, the first data is encrypted data. The encryption of the first data by the first device will be described in detail below with reference to FIG3 .

[0085] 3 , in some embodiments, before step S212 , the method provided in the embodiment of the present application may further include step S211 . In step S211 , the first device encrypts the first data according to the identity identification code of the first device.

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

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

[0088] After the first device encrypts the first data using its identification code, the second device, upon receiving the first data, needs to decrypt it using the first device's identification code. Only after the second device successfully decrypts the first data can it obtain the first public key and other information in the first data, thus avoiding the vulnerability of the first public key to leaks due to plaintext transmission.

[0089] In some embodiments, the identity identification code of the first device can be determined by negotiation between the first device and the second device. That is to say, before the first device encrypts the first data according to the identity identification code of the first device, the first device can also negotiate the first identity identification code with the second device, and the first identity identification code can be used for the device corresponding to the first identity identification code to access the second device, that is, when a certain device wants to access the second device, it needs to use its corresponding first identity identification code as a credential to achieve access to the second device. This application does not specifically limit the implementation method of the negotiation of the first identity identification code between the first device and the second device. By way of example, two implementation methods of the negotiation of the first identity identification code between the first device and the second device are introduced below in conjunction with Figures 4 and 5 respectively.

[0090] Figure 4 is a schematic diagram of a process for a first device and a second device to negotiate a first identity code, 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, where the second message is used to configure the first identity code. In other words, in this embodiment, the first identity code can be configured by the first device. In this way, each first device can correspond to a fixed identity code. Therefore, in some embodiments, the scheme of using the first device to configure the first identity code can also be referred to as a scheme using a fixed identity code.

[0091] As an implementation method, during the configuration phase, the first device may pre-configure the first identity code for the second device. After the first identity code is configured, the device corresponding to the first identity code can access the second device.

[0092] In order to avoid the plain text transmission of the identity identification code, in some embodiments, when configuring the first identity identification code, the first device may configure the first identity identification code and the index corresponding to the first identity identification code to the second device in the form of tuple information, for example<pincode,pincode_index> . In other words, the first device can configure the first identity identification code and the index of the first identity identification code to the second device, and there is a one-to-one mapping relationship between the first identity identification code and the index of the first identity identification code. In this way, after the first device uses the identity identification code of the first device to encrypt the first data, there is no need to transmit the identity identification code of the first device to the second device for the second device to decrypt it. Instead, it only needs to transmit the index corresponding to the identity identification code to the second device. The second device can know the correct identity identification code based on the identity identification code index, thereby decrypting the first data, further improving the security of communication.

[0093] In some embodiments, if a first device configures a first identity identification code and an index corresponding to the first identity identification code for a second device, when the first device sends a first message to the second device, the first message may include, in addition to the first data, the index corresponding to the identity identification code of the first device. The first data in the first message is encrypted using the identity identification code of the first device, while the index corresponding to the identity identification code of the first device is not encrypted.

[0094] In some embodiments, the first device may configure a list containing multiple groups of first identity identification codes to the second device, where the list may contain multiple tuple information, each tuple information being used to represent a group of first identity identification codes and an index corresponding to the first identity identification code, and the device corresponding to the first identity identification code in each tuple information can access the second device.

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

[0096] In some embodiments, after the first device configures the second device with information related to the first identity identification code (eg, the identity identification code and the corresponding index), the first device may store the configured information related to the first identity identification code.

[0097] In some embodiments, the second device may also store information related to the first identity code configured by the first device, for example, the first identity code that can be used to access the second device and an index corresponding to the first identity code.

[0098] The embodiments of the present application do not limit the manner in which the second device stores the information. In some embodiments, the second device may store the information related to the first identity identification code in a resource of the second device. In some embodiments, the second device may store the information related to the first identity identification code in a function cluster, such as a newly defined function cluster.

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

[0100] Figure 5 is a schematic diagram of a process for a first device and a second device to negotiate a first identity code, 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, instructing the second device to return the first identity code. After the second device returns the first identity code, the device corresponding to the first identity code can access the second device. In other words, in this embodiment, the first identity code can be generated by the second device.

[0101] In some embodiments, when the first device and the second device negotiate a shared key, the second device can return a temporary identity identification code to the first device. Therefore, in some embodiments, the scheme of using the second device to return a temporary identity identification code to the first device can also be referred to as a scheme using a temporary identity identification code.

[0102] As an implementation method, before sending the first message to the second device, the first device may send a third message to the second device. The third message may carry information indicating that the first device does not have an identity identification code. For example, the third message may carry data with an identity identification code index value of 0. The identity identification code index value of 0 indicates that the first device does not have an identity identification code.

[0103] In step S520, after receiving the third message, the second device returns the first identity code to the first device. In some embodiments, the first identity code returned by the second device to the first device is a temporary identity code, and the first device can access the second device based on the returned temporary identity code.

[0104] As an implementation method, after receiving the third message, the second device knows from the third message that the first device does not have an identity identification code. Based on this, the second device can generate a temporary identity identification code and display the temporary identity identification code on the display screen of the second device so that the first device can know the temporary identity identification code.

[0105] In some embodiments, after the second device knows that the first device does not have the identity 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 enter the temporary identity identification code returned by the second device to the first device.

[0106] In some embodiments, after the first device inputs the temporary identity identification code of the first device, it can send a first message to the second device. Optionally, when the first device sends the first message to the second device, in addition to the first data, the first message may also include an index corresponding to the temporary identity identification code of the first device, where the index corresponding to the temporary identity identification code is used to indicate that the first device already has an identity identification code. Exemplarily, the index corresponding to the temporary identity identification code contained in the first message can be a full F value, which is used to indicate that the first device has a temporary identity identification code.

[0107] In some embodiments, after the first device inputs the temporary identity identification code, the temporary identity identification code may not be saved.

[0108] As mentioned above, in some embodiments, before negotiating a shared key, the first device and the second device may negotiate and determine a shared key negotiation method based on the key negotiation methods (or types) supported by the first device and the second device, respectively. The following, in conjunction with FIG6 , details the process by which the first device and the second device negotiate a shared key negotiation method.

[0109] In step S610, the first device sends a fourth message to the second device, where the fourth message is used to indicate a key negotiation mode supported by the first device.

[0110] 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: negotiation based on key pairs, negotiation based on node interoperability certificates, and negotiation based on sigma protocols.

[0111] It should be understood that after the first device and the second device negotiate and determine the negotiation method for 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 the shared key based on a key pair, and the corresponding type of interoperability channel is an interoperability channel based on a key pair. In other words, the key negotiation method supported by the first device can also be referred to as the type of interoperability establishment supported by the first device. Therefore, in some embodiments, the fourth message can also be referred to as an interoperability session establishment request message, which is not limited in this application.

[0112] In step S620 , the second device sends a fourth response to the first device, where the fourth response is used to indicate that a shared key is negotiated based on the key pair.

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

[0114] As another implementation, after receiving the fourth message, the second device may indicate, in a fourth response, a key agreement method supported by the second device, and the first device may determine a shared key agreement method. The key agreement methods supported by the second device may include one or more of the following: key pair-based negotiation, node interoperability certificate-based negotiation, and sigma protocol-based negotiation.

[0115] For example, if the second device only supports key-pair-based negotiation of a shared key, then the fourth response only includes a key-pair-based negotiation method for a shared key. After receiving the fourth response, the first device can directly determine to negotiate a shared key with the second device based on the key pair. Alternatively, if the second device supports multiple key negotiation methods, for example, key-pair-based negotiation and sigma protocol-based negotiation, then after receiving the fourth response, the first device can select one of the key negotiation methods supported by the second device. 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.

[0116] To facilitate those skilled in the art to understand the implementation process of the technical solutions of the embodiments of the present application, two specific examples are given below. It should be understood that the examples are not intended to limit the technical solutions of the present application. For example, not all steps in the examples are required, and in actual implementation, only some steps may be used, or more steps may be used than the steps listed. Alternatively, the order in which the steps in the examples are executed is not required, and some steps can be executed simultaneously or in a different order.

[0117] Example 1 (using a fixed ID)

[0118] Figure 7 is a flow chart of a method for establishing an interoperability channel according to another embodiment of the present application. As shown in Figure 7 , the method may include steps S7010 to S7140.

[0119] In step S7010, a first device establishes a configuration channel with a second device. The configuration channel may be a secure configuration channel used for performing configuration operations between the first device and the second device.

[0120] In step S7020, the first device sends a second message to the second device. The second message is used to configure the first identity identification code and the index corresponding to the first identity identification code, such as the configuration tuple information.<pincode,pincode_index> , so that the device corresponding to the first identity identification code can access the second device.

[0121] In some embodiments, the first device may configure multiple sets of first identity identification codes and indexes corresponding to the first identity identification codes, i.e., multiple sets of tuple information, to the second device. The multiple sets of tuple information may form a configuration list indicating information related to the first identity identification codes that can access the second device.

[0122] In some embodiments, after the first device configures the first identity identification code and the index corresponding to the first identity identification code to the second device, the first device may store the first identity identification code and the index corresponding to the first identity identification code.

[0123] In step S7030, the second device stores the first identity code configured by the first device and the index corresponding to the first identity code, for example, in the resources of the second device, or in the function set of the second device (such as a newly defined function set).

[0124] In step S7040, the configuration between the first device and the second device is completed, and the configuration channel is exited.

[0125] In some embodiments, in addition to configuring the first identity identification code for the second device, the first device may also configure some basic configurations for the second device. After completing the identity identification code and basic configuration, the configuration between the first device and the second device is completed and the configuration channel is exited.

[0126] In step S7050, the first device sends a fourth message to the second device, where the fourth message is used to indicate a key negotiation mode supported by the first device.

[0127] In some embodiments, the key negotiation methods supported by the first device may include one or more of the following methods: negotiation based on a key pair, negotiation based on a node interoperability certificate, and negotiation based on a sigma protocol.

[0128] In step S7060, the second device returns a fourth response to the first device. The fourth response may be used to indicate a key negotiation method supported by the second device, for example, the key negotiation method supported by the second device is key pair-based negotiation.

[0129] In step S7070, the first device encrypts the first data using the identity identification code of the first device.

[0130] As an implementation method, the first device can first generate a random number r1 and a temporary key pair (a first public key and a first private key). Then, the first private key is used to encrypt one or more of the first public key, the random number r1, and the device identification of the first device to obtain a signature sign1. The first data can then be obtained. The first data may include one or more of the following information: the first public key, the random number r1, the device identification of the first device, and the signature sign1. After obtaining the first data, the first device can encrypt the first data using the first device's identity identification code.

[0131] In step S7080, the first device sends a first message to the second device. The first message may carry first data encrypted using the identity identification code of the first device and an index corresponding to the identity identification code, and the index is not encrypted.

[0132] In some embodiments, the index corresponding to the identity identification code is a non-zero value and a non-full F value.

[0133] In step S7090, the second device generates a shared key based on the first public key and the second private key.

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

[0135] In some embodiments, after decrypting the first data, the second device may 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.

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

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

[0138] 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.

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

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

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

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

[0143] In step S7130, the first device and the second device establish an interoperability channel based on a shared key.

[0144] In step S7140, the first device controls the second device through the interoperability channel.

[0145] Example 2 (using a temporary ID)

[0146] Figure 8 is a flow chart of a method for establishing an interoperability channel according to another embodiment of the present application. As shown in Figure 8 , the method may include steps S8010 to S8130.

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

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

[0149] In some embodiments, the key negotiation methods supported by the first device may include one or more of the following methods: negotiation based on a key pair, negotiation based on a node interoperability certificate, and negotiation based on a sigma protocol.

[0150] In step S8030, the second device returns a fourth response to the first device. The fourth response may be used to indicate a key negotiation method supported by the second device, for example, the key negotiation method supported by the second device is key pair-based negotiation.

[0151] In step S8040, 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 identity identification code.

[0152] In some embodiments, the third message may carry information indicating that the first device does not have an identity identification code. For example, the third message may carry data with an identity identification code index of 0 to indicate that the first device does not have an identity identification code.

[0153] In step S8050, the second device returns a first identity identification code to the first device, where the first identity identification code may be a temporary identity identification code.

[0154] In some embodiments, the second device may send a third response to the first device, returning an error code, informing the first device that it needs to input the temporary identity identification code returned by the second device to the first device.

[0155] In some embodiments, the second device may display the temporary identity code that needs to be input on a display screen of the second device.

[0156] In step S8060, the first device encrypts the first data using the identity identification code of the first device.

[0157] As an implementation method, after the first device inputs the temporary identity identification code, it can first generate a random number r1 and a temporary key pair (a first public key and a first private key). Then, it uses the first private key to encrypt one or more of the first public key, the random number r1, and the device identification of the first device to obtain a signature sign1. Further, it obtains first data, which may include one or more of the following information: the first public key, the random number r1, the device identification of the first device, and the signature sign1. After obtaining the first data, the first device can encrypt the first data using the identity identification code of the first device.

[0158] In some embodiments, after the first device inputs the temporary identity code, the identity code may not be saved.

[0159] In step S8070, the first device sends a first message to the second device. The first message may carry first data encrypted using the identity identification code of the first device and an index corresponding to the identity identification code, and the index is not encrypted.

[0160] In some embodiments, the index corresponding to the identity identification code is a full F value, and the full F value is used to indicate that the first device has a temporary identity identification code.

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

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

[0163] In some embodiments, after decrypting the first data, the second device may 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.

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

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

[0166] 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.

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

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

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

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

[0171] In step S8120, the first device and the second device establish an interoperability channel based on a shared key.

[0172] In step S8130, the first device controls the second device through the interoperability channel.

[0173] The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 8 . The device embodiment of the present application is described in detail below in conjunction with Figures 9 to 11 . It should be understood that the description of the method embodiment corresponds to the description of the device embodiment. Therefore, for portions not described in detail, reference can be made to the above method embodiment.

[0174] FIG9 is a schematic diagram of the structure of an apparatus for establishing an interoperability channel according to an embodiment of the present application. The apparatus can be configured in the first device described above. The apparatus 900 shown in FIG9 may include a first negotiation module 910, an establishment module 920, and a control module 930.

[0175] The first negotiation module 910 may be configured to negotiate a shared key with the 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.

[0176] The establishing module 920 may be configured to establish an interoperability channel based on a shared key with the second device.

[0177] The control module 930 can be used to send a control instruction 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.

[0178] Optionally, the first negotiation module further includes: a first sending module, used to send a first message to the second device, the first message includes first data, the first data includes a first public key, and the first public key is used to generate a shared key for the second device; a first receiving module, used to receive 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 a key pair of the second device; a generating module, used to generate a shared key based on the second public key and the first private key.

[0179] 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 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.

[0180] 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.

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

[0182] Optionally, the apparatus 900 further includes: a second negotiation module, configured to negotiate a first identity identification code with the second device, where the first identity identification code is used for the device corresponding to the first identity identification code to access the second device.

[0183] 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 identification code.

[0184] 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 identification code.

[0185] Optionally, the third message carries information indicating that the first device does not have an identity identification code. The apparatus 900 further includes: a second receiving module configured to receive a first identity identification code returned by the second device for the first device.

[0186] Optionally, the first identity identification code returned by the second device is displayed on a display screen of the second device.

[0187] Optionally, the first identity identification code returned by the second device is a temporary identity identification code.

[0188] Optionally, the apparatus 900 further includes: a third negotiation module, configured to negotiate with the second device a negotiation method for sharing a key.

[0189] Optionally, the third negotiation module further includes: a fourth sending module, used to send a fourth message to the second device, the fourth message is used to indicate the key negotiation method supported by the first device; a third receiving module, used to receive a fourth response from the second device, the fourth response is used to indicate the negotiation of a shared key based on a key pair.

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

[0191] Optionally, the shared key is generated by the first device based on one or more of the following information: a first key, a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity 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.

[0192] FIG10 is a schematic diagram of the structure of an apparatus for establishing an interoperability channel according to another embodiment of the present application. The apparatus can be configured on the second device described above. The apparatus 1000 shown in FIG10 can include a first negotiation module 1010, an establishment module 1020, and a first receiving module 1030.

[0193] The first negotiation module 1010 may be configured to negotiate a shared key with the first device based on 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.

[0194] The establishing module 1020 may be configured to establish an interoperability channel based on a shared key with the first device.

[0195] The first receiving module 1030 may be configured to receive a control instruction of a first device through an interoperability channel, wherein the first device is a terminal device and the second device is a vehicle device.

[0196] Optionally, the first negotiation module further includes: a second receiving module, used to receive a 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 constitute a key pair of the first device; a generating module, used to generate a shared key based on the first public key and the second private key; a first sending module, used to send a first response to the first device, the first response contains second data, the second data contains a second public key, and the second public key is used by the first device to generate a shared key.

[0197] 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 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.

[0198] 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.

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

[0200] Optionally, the apparatus 1000 further includes: a second negotiation module, configured to negotiate a first identity identification code with the first device, where the first identity identification code is used for the device corresponding to the first identity identification code to access the second device.

[0201] 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 identification code.

[0202] 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 identification code.

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

[0204] Optionally, the first identity identification code returned by the second device is displayed on a display screen of the second device.

[0205] Optionally, the first identity identification code returned by the second device is a temporary identity identification code.

[0206] Optionally, the apparatus 1000 further includes: a third negotiation module, configured to negotiate with the first device a negotiation method for sharing a key.

[0207] Optionally, the third negotiation module further includes: a fifth receiving module, used to receive a fourth message sent by the first device, the fourth message being used to indicate a key negotiation method supported by the first device; and a second sending module, used to send a fourth response to the first device, the fourth response being used to indicate a shared key negotiated based on a key pair.

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

[0209] Optionally, the shared key is generated by the second device based on one or more of the following information: a second key, a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity 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.

[0210] In an optional embodiment, the apparatus 900 for establishing an interoperability channel and / or the apparatus 1000 for establishing an interoperability channel may further include a transceiver 1130 and a memory 1120 , as specifically shown in FIG. 11 .

[0211] Figure 11 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 11 indicate that the unit or module is optional. The device 1100 may be used to implement the method described in the above method embodiment. The device 1100 may be a chip, a terminal device, or a network device.

[0212] The device 1100 may include one or more processors 1110. The processor 1110 may support the device 1100 to implement the method described in the method embodiment above. 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 may be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0213] The apparatus 1100 may further include one or more memories 1120. The memories 1120 store programs that can be executed by the processor 1110, causing the processor 1110 to perform the methods described in the above method embodiments. The memories 1120 may be independent of the processor 1110 or integrated into the processor 1110.

[0214] The apparatus 1100 may further include a transceiver 1130. The processor 1110 may communicate with other devices or chips via the transceiver 1130. For example, the processor 1110 may transmit and receive data with other devices or chips via the transceiver 1130.

[0215] The present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to a terminal or network device provided in the present application, and the program enables a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0216] The present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal or network device provided in the present application, and the program causes a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0217] The embodiments of the present application also provide a computer program. The computer program can be applied to the terminal or network device provided in the embodiments of the present application, and the computer program enables a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0218] It should be understood that the terms "system" and "network" in this application can be used interchangeably. In addition, the terms used in this application are only used to explain the specific embodiments of this application and are not intended to limit this application. The terms "first", "second", "third", and "fourth" in the specification and claims of this application and the accompanying drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0219] In the embodiments of this application, the term "indication" can refer to direct indications, indirect indications, or an association relationship. For example, "A indicates B" can mean that A directly indicates B, for example, B can obtain information through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can obtain information through C; it can also mean that A and B have an association relationship.

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

[0221] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

[0222] In the embodiments of the present application, "pre-definition" or "pre-configuration" may be implemented by pre-storing corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., a terminal device and a network device). The present application does not limit the specific implementation method. For example, pre-definition may refer to information defined in a protocol.

[0223] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communications field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0224] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

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

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

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

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

[0229] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can 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 process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

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

Claims

1. A method for establishing an interoperability channel, characterized in that: include: The first device negotiates a shared key with the 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; The first device and the second device establish an interoperability channel based on the shared key; The first device sends a control instruction to the second device through the interoperation channel to control the second device; The first device is a terminal device, and the second device is a vehicle device.

2. The method according to claim 1, characterized in that The first device negotiates a shared key with the second device according to the key pair of the first device, including: The first device sends a first message to the second device, where the first message includes first data, the first data includes the first public key, and the first public key is used by the second device to generate the shared key; The first device receives a first response from the second device, the first response including second data, the second data including a second public key, and the second public key and a second private key forming a key pair of the second device; The first device generates the shared key according to the second public key and the first private key.

3. The method according to claim 2, wherein: The first data further 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 further 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.

4. The method according to claim 3, characterized in that 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 a device identifier 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 a device identifier of the second device.

5. The method according to any one of claims 2 to 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 identity identification code of the first device.

6. The method according to claim 5, characterized in that Before the first device encrypts the first data according to the identity identification code of the first device, the method further includes: The first device negotiates a first identity identification code with the second device, where the first identity identification code is used by a device corresponding to the first identity identification code to access the second device.

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

8. The method according to claim 6, characterized in that The first device and the second device negotiate a first identity code, including: The first device sends a third message to the second device, where the third message is used to instruct the second device to return the first identity identification code.

9. The method according to claim 8, characterized in that The third message carries information indicating that the first device does not have an identity identification code, The method further comprises: The first device receives the first identity identification code returned by the second device.

10. The method according to claim 9, characterized in that The first identity identification code returned by the second device is displayed on a display screen of the second device.

11. The method according to any one of claims 8 to 10, characterized in that The first identity identification code returned by the second device is a temporary identity identification code.

12. The method according to any one of claims 1 to 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 on a negotiation method for the shared key.

13. The method according to claim 12, characterized in that The negotiation method of the shared key between the first device and the second device includes: The first device sends a fourth message to the second device, where the fourth message is used to indicate a key agreement mode supported by the first device; The first device receives a fourth response from the second device, where the fourth response is used to indicate that the shared key is negotiated based on the key pair.

14. The method according to claim 13, characterized in that The key negotiation methods supported by the first device and / or the second device include one or more of the following methods: negotiation based on a key pair, negotiation based on a node interoperability certificate, and negotiation based on a sigma protocol.

15. The method according to any one of claims 1 to 14, characterized in that The shared key is generated by the first device based on one or more of the following information: a first key, a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity 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.

16. A method for establishing an interoperability channel, characterized in that: include: The second device negotiates a shared key with the first device based on 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 second device establishes an interoperability channel with the first device based on the shared key; The second device receives the control instruction of the first device through the interoperation channel; The first device is a terminal device, and the second device is a vehicle device.

17. The method according to claim 16, characterized in that The second device negotiates a shared key with the first device according to the key pair of the second device, including: The second device receives a first message sent by the first device, where the first message includes first data, the first data includes a first public key, and the first public key and a first private key constitute a key pair of the first device; The second device generates the shared key according to the first public key and the second private key; The second device sends a first response to the first device, where the first response includes second data, and the second data includes the second public key, which is used by the first device to generate the shared key.

18. The method according to claim 17, wherein: The first data further 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 further 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.

19. The method according to claim 18, characterized in that 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 a device identifier 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 a device identifier of the second device.

20. The method according to any one of claims 17 to 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 identity identification code of the first device.

21. The method according to claim 20, characterized in that Before the second device decrypts the first data according to the identity identification code of the first device, the method further includes: The second device negotiates a first identity identification code with the first device, and the first identity identification code is used for a device corresponding to the first identity identification code to access the second device.

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

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

24. The method according to claim 23, wherein The third message carries information indicating that the first device does not have an identity identification code, The method further comprises: The second device returns the first identity code to the first device.

25. The method according to claim 24, characterized in that The first identity identification code returned by the second device is displayed on a display screen of the second device.

26. The method according to any one of claims 23 to 25, characterized in that The first identity identification code returned by the second device is a temporary identity identification code.

27. The method according to any one of claims 16 to 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 on a negotiation method for the shared key.

28. The method according to claim 27, characterized in that The negotiation method of the shared key between the second device and the first device includes: The second device receives a fourth message sent by the first device, where the fourth message is used to indicate a key negotiation mode supported by the first device; The second device sends a fourth response to the first device, where the fourth response is used to indicate that the shared key is negotiated based on the key pair.

29. The method according to claim 28, characterized in that The key negotiation methods supported by the first device and / or the second device include one or more of the following methods: negotiation based on a key pair, negotiation based on a node interoperability certificate, and negotiation based on a sigma protocol.

30. The method according to any one of claims 16 to 29, wherein: The shared key is generated by the second device based on one or more of the following information: a second key, a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity 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.

31. A device for establishing an interoperability channel, characterized in that: The apparatus is configured on a first device, and includes: a first negotiation module, configured to negotiate a shared key with the 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 establishing module, configured to establish an interoperability channel based on the shared key with the second device; a control module, configured to send a control instruction to the second device through the interoperability channel to control the second device; The first device is a terminal device, and the second device is a vehicle device.

32. The device according to claim 31, characterized in that The first negotiation module further includes: A first sending module, configured to send a first message to the second device, where the first message includes first data, the first data includes the first public key, and the first public key is used by the second device to generate the shared key; a first receiving module, configured to receive a first response from the second device, where the first response includes second data, the second data includes a second public key, and the second public key and a second private key constitute a key pair of the second device; A generating module is used to generate the shared key according to the second public key and the first private key.

33. The device according to claim 32, characterized in that: The first data further 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 further 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.

34. The device according to claim 33, characterized in that 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 a device identifier 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 a device identifier of the second device.

35. The device according to any one of claims 32 to 34, characterized in that The device further comprises: An encryption module is configured to encrypt the first data according to the identity identification code of the first device.

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

37. 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 identification code.

38. The device according to claim 36, characterized in that The second negotiation module further includes: The 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 identity identification code.

39. The device according to claim 38, characterized in that The third message carries information indicating that the first device does not have an identity identification code, The device further comprises: The second receiving module is configured to receive the first identity identification code returned by the second device.

40. The device according to claim 39, characterized in that The first identity identification code returned by the second device is displayed on a display screen of the second device.

41. The device according to any one of claims 38 to 40, characterized in that The first identity identification code returned by the second device is a temporary identity identification code.

42. The device according to any one of claims 31 to 41, characterized in that The device further comprises: A third negotiation module is configured to negotiate with the second device on a negotiation method for the shared key.

43. 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 a key agreement mode supported by the first device; The third receiving module is configured to receive a fourth response from the second device, where the fourth response is used to indicate that the shared key is negotiated based on the key pair.

44. The device according to claim 43, characterized in that The key negotiation methods supported by the first device and / or the second device include one or more of the following methods: negotiation based on a key pair, negotiation based on a node interoperability certificate, and negotiation based on a sigma protocol.

45. The device according to any one of claims 31 to 44, characterized in that The shared key is generated by the first device based on one or more of the following information: a first key, a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity 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.

46. ​​A device for establishing an interoperability channel, characterized in that The apparatus is configured on a second device, and includes: a first negotiation module, configured to negotiate a shared key with the first device based on 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; An establishing module, configured to establish an interoperability channel based on the shared key with the first device; A first receiving module, configured to receive a control instruction of the first device through the interoperation channel; The first device is a terminal device, and the second device is a vehicle device.

47. The device according to claim 46, characterized in that The first negotiation module further includes: a second receiving module, configured to receive a first message sent by the first device, where the first message includes first data, the first data includes a first public key, and the first public key and a first private key constitute 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; The first sending module is 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 by the first device to generate the shared key.

48. The device according to claim 47, characterized in that: The first data further 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 further 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.

49. The device according to claim 48, characterized in that 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 a device identifier 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 a device identifier of the second device.

50. The device according to any one of claims 47 to 49, characterized in that The device further comprises: A decryption module is configured to decrypt the first data according to the identity identification code of the first device.

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

52. 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 identification code.

53. The device according to claim 51, characterized in that The second negotiation module further includes: The fourth receiving module is used 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 identification code.

54. The device according to claim 53, characterized in that The third message carries information indicating that the first device does not have an identity identification code, The device further comprises: A returning module is configured to return the first identity identification code to the first device.

55. The device according to claim 54, characterized in that The first identity identification code returned by the second device is displayed on a display screen of the second device.

56. The device according to any one of claims 53 to 55, characterized in that The first identity identification code returned by the second device is a temporary identity identification code.

57. The device according to any one of claims 46 to 56, characterized in that The device further comprises: A third negotiation module is configured to negotiate with the first device on a negotiation method for the shared key.

58. 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 a key agreement mode 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 that the shared key is negotiated based on the key pair.

59. The device according to claim 58, characterized in that The key negotiation methods supported by the first device and / or the second device include one or more of the following methods: negotiation based on a key pair, negotiation based on a node interoperability certificate, and negotiation based on a sigma protocol.

60. The device according to any one of claims 46 to 59, characterized in that The shared key is generated by the second device based on one or more of the following information: a second key, a random number generated by the first device, a random number generated by the second device, a device identifier of the first device, a device identifier of the second device, and an identity 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.

61. A communication device, characterized in that The communication device is configured in a first device, and the device includes a memory and a processor. The memory is used to store a program, and the processor is used to call the program in the memory to enable the first device to execute the method according to any one of claims 1 to 15.

62. A communication device, characterized in that The communication device is configured in a second device, and the device includes a memory and a processor. The memory is used to store a program, and the processor is used to call the program in the memory to enable the second device to execute the method according to any one of claims 16 to 30.

63. A device, characterized in that The device comprises a processor configured to call a program from a memory so as to enable the device to execute the method according to any one of claims 1 to 30.

64. A chip, characterized in that The device comprises a processor configured to call a program from a memory so that a device equipped with the chip executes the method according to any one of claims 1 to 30.

65. A computer-readable storage medium, characterized in that A program is stored thereon, the program causing a computer to execute the method according to any one of claims 1 to 30.

66. A computer program product, characterized in that The method comprises a program for causing a computer to execute the method according to any one of claims 1 to 30.

67. A computer program, characterized in that The computer program causes a computer to execute the method according to any one of claims 1 to 30.

Images