WO2023230979A1 - Method and apparatus for establishing interoperability channel, and chip and storage medium - Google Patents

Abstract

Provided are a method and apparatus for establishing an interoperability channel, and a chip and a storage medium. The method comprises: a first device negotiates with a second device for a shared key according to a first node interoperability certificate of the first device; the first device and the second device establish a shared key-based interoperability channel; and the first device sends a control instruction to the second device by means of the interoperability channel so as to control the second device, wherein the first device is a terminal device, and the second device is a vehicle device. In embodiments of the present application, the first device and the second device can negotiate, on the basis of the node interoperability certificate, the shared key corresponding to the interoperability channel, so that the security and reliability of communication of the interoperability channel are ensured, and the security control of the first device on the second device is achieved. By negotiating the shared key on the basis of the node interoperability certificate, the risk of the disclosure of the shared key is facilitated to be reduced.

Description

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

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

Background technique

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

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

Contents of the invention

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

In a first aspect, a method for establishing an interoperability channel is provided, including: a first device negotiates a shared key with a second device based on a first node interoperability certificate NOC of the first device; the first device and the first device negotiate a shared key. The second device establishes 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.

In a second aspect, a method for establishing an interoperability channel is provided, including: the second device negotiates a shared key with the first device based on the second node interoperability certificate NOC of the second device; the second device and the first device negotiate a shared key; The first device establishes an interoperability channel based on the shared key; the second device receives the control instruction of the first device through the interoperability channel, wherein the first device is a terminal device, and the The second device is the vehicle device.

In a third aspect, a device for establishing an interoperability channel is provided. The device is configured on a first device. The device includes: a first negotiation module configured to establish an interoperability channel based on the first node interoperability certificate NOC of the first device. Negotiate a shared key with the second device; an establishment module, configured to establish an interoperability channel based on the shared key with the second device; and a control module, configured to send a message to the second device through the interoperability channel. Control instructions to control the second device, wherein the first device is a terminal device and the second device is a vehicle device.

In a fourth aspect, a device for establishing an interoperability channel is provided. The device is configured on a second device. The device includes: a first negotiation module configured to establish a second node interoperability certificate NOC based on the second device. Negotiate a shared key with the first device; an establishment module configured to establish an interoperability channel based on the shared key with the first device; a first receiving module configured to receive the first interoperability channel through the interoperability channel Control instructions for equipment, wherein the first equipment is a terminal equipment and the second equipment is a vehicle equipment.

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

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

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

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

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

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

In the embodiment of this application, the first device and the second device can negotiate the shared key corresponding to the interoperability channel based on the node interoperability certificate to ensure the security and reliability of the communication of the interoperability channel and realize the first device's communication with the second device. Device security controls. Negotiating shared keys based on node interoperability certificates helps reduce the risk of shared keys being leaked.

Description of the drawings

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

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

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

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

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

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

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

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

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

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

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

Detailed ways

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In order to solve the above problems, embodiments of the present application provide a method, device, chip, storage medium and program product for establishing an interoperability channel to negotiate the shared key corresponding to the interoperability channel based on the node interoperability certificate, which helps to reduce the risk of sharing. Risk of key leakage. The method embodiments provided by the embodiments of the present application will be introduced in detail below with reference to the accompanying drawings.

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

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

The method shown in FIG. 2 may include steps S210 to S230, and these steps will be described in detail below.

In step S210, the first device and the second device negotiate a shared key based on a node operational certificate (NOC). It should be understood that the first device and the second device negotiate a shared key with the other party based on the NOC they own. Specifically, the first device can negotiate a shared key with the second device based on the first NOC of the first device. The second device may negotiate a shared key with the first device based on the second NOC of the second device.

In some embodiments, the NOC of the device may store key information corresponding to the NOC. It should be understood that the key information corresponding to the NOC may refer to the public key information corresponding to the NOC and/or the private key information corresponding to the NOC. Specifically, in this embodiment of the present application, the public key information corresponding to the NOC can be stored in the NOC of the device, but the corresponding private key information cannot be stored in the NOC. For example, the first NOC may store the public key corresponding to the first NOC, and the second NOC may store the public key corresponding to the second NOC. However, the embodiments of the present application are not limited to this. For example, the NOC of the device may also store other information in addition to the key information corresponding to the NOC, such as the device identification of the device, and so on.

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

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

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

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

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

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

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

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

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

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

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

In step S230, the first device controls the second device through the interoperation channel. For example, the first device may send a control instruction (also known as a control command, control signaling, etc.) to the second device through an interoperation channel to control the second device.

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

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

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

The embodiment of the present application does not limit the implementation manner of step S210. A possible implementation of step S210 is given below with reference to FIG. 3 , and the process of the first device and the second device negotiating a shared key based on the NOC is described in detail. For example, step S210 may include steps S212 to S218, and these steps will be described in detail below.

In step S212, the first device sends a first message to the second device, and the first message may be used to request the second device to negotiate a shared key. Therefore, in some embodiments, the first message may also be called a key agreement request message, or a key exchange request message, or the like.

In this embodiment of the present application, the first message includes the first data, and the first data includes the first NOC. In some embodiments, the first NOC may include the public key corresponding to the first NOC, or may also include the device identification of the first device, etc.

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

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

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

The first signature may 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: the first NOC, the CA certificate of the first device, and a random number generated by the first device. The first device may encrypt one or more of the information using the private key corresponding to the first NOC to generate the first signature. The first device may send the first signature and the content in the first signature to the second device, so that the second device uses the public key corresponding to the first NOC to verify the first signature sent by the first device to verify the second device. The identity of a device is verified, while proving that the first NOC is authentic and not counterfeit.

It should be understood that the information contained in the first signature generated by the first device may be consistent with the information in the first data other than the first signature. For example, the first signature generated by the first device includes the first NOC, the first The CA certificate of a device and the random number generated by the first device, then the corresponding first data should also include the first NOC, the CA certificate of the first device and the random number generated by the first device in addition to the first signature. Further, if the CA certificate of the first device contained in the first signature generated by the first device is the RCAC certificate of the first device, the first data also contains the RCAC certificate of the first device; if the CA certificate of the first device generated by the first device is When the CA certificate of the first device included in a signature is the ICAC certificate of the first device, the first data also contains the ICAC certificate of the first device.

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

As mentioned above, the second NOC may be configured in advance by the debugging specialist (for example, the first device). In some embodiments, the second device generating the shared key based on the first NOC and the second NOC may mean that the second device generates the shared key based on the public key corresponding to the first NOC and the private key corresponding to the second NOC. . Specifically, the second device may generate the second key based on the public key corresponding to the first NOC and the private key corresponding to the second NOC, and then generate the shared key based on the second key.

Exemplarily, the second device may generate the shared key based on the second key and one or more of the following information: a random number generated by the first device, a random number generated by the second device, the device of the first device identification, the device identification of the second device, and the identification code of the first device. As an implementation manner, the second device can use one or more of the information as key parameters and use a key algorithm to generate the shared key.

It should be noted that the random number generated by the first device and the device identification of the first device may be carried by the first device in the first message. For example, the device identification of the first device may be carried in the first NOC. The random number generated by the second device may be temporarily generated by the second device before generating the shared key. The identification code of the first device may be configured by the first device for the second device in advance or may be generated by the second device. The identification code of the first device will be described in detail later and will not be described in detail here.

In some embodiments, the second device can first verify the identity of the first device before generating the shared key. The verification may mean that the second device can use the public key corresponding to the first NOC to verify the identity of the first device generated by the first NOC. A signature is verified. In some embodiments, the second device verifying the identity of the first device may also include the second device using the CA certificate of the first device to verify the first NOC. For example, the second device uses the stored CA certificate to verify the first NOC. A NOC for verification. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device uses the stored RCAC of the first device to verify the ICAC sent by the first device, and uses the stored ICAC of the first device to verify the ICAC. Verify the first NOC; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the second device uses the stored RCAC of the first device to verify the first NOC.

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

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

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

It should be understood that the CA certificate of the first device may be the RCAC certificate of the first device or the ICAC certificate of the first device. For the sake of simplicity, the relevant description of the CA certificate of the first device can be found in the previous article and will not be repeated here. For the description of the random number generated by the second device, please refer to the previous description of the random number generated by the first device, and will not be described again here.

The second signature generated by the second device may be used by the first device to authenticate the second device. In some embodiments, the second signature generated by the second device may include one or more of the following information: the second NOC, the CA certificate of the first device, and a random number generated by the second device. For example, the CA certificate of the first device may be the CA certificate of the first device stored in the second device. The CA certificate of the first device may refer to the RCAC certificate of the first device or the ICAC certificate of the first device. Regarding the verification process of the second signature generated by the first device against the second device, please refer to the aforementioned verification process of the first signature by the second device against the first device.

In some embodiments, after the first device receives the first response from the second device, the first device may also verify the second NOC using the CA certificate of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the first device uses the RCAC of the first device to verify the ICAC sent by the second device, and uses the stored ICAC of the first device to verify the ICAC sent by the second device. Two NOCs; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the first device uses the RCAC of the first device to verify the second NOC.

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

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

In some embodiments, the first device generating the shared key based on the second NOC and the first NOC may mean that the first device generates the shared key based on the public key corresponding to the second NOC and the private key corresponding to the first NOC. . Specifically, the first device may generate the first key based on the public key corresponding to the second NOC and the private key corresponding to the first NOC, and then generate the shared key based on the first key.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In some embodiments, after the second device knows that the first device does not have an identification code, it can also send a third response to the first device. The third response can be used to inform the first device to input and the second device returns a response for the first device. temporary identification code.

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

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

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

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

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

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

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

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

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

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

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

Example 1 (using fixed identification code)

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

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

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

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

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

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

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

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

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

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

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

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

In step S7070, the second device returns a fourth response to the first device. The fourth response may be used to indicate the key negotiation method supported by the second device. For example, the key negotiation method supported by the second device is NOC-based negotiation.

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

As an implementation manner, first the first device can generate a random number r1, and then use the private key corresponding to the first NOC to pair the first NOC, the first device's CA certificate (for example, the first device's ICAC), and the random number r1 Encrypt one or more of the following information to obtain the first signature sign1, and further obtain the first data. The first data may include one or more of the following information: the first NOC, the CA certificate of the first device (for example, , ICAC of the first device), random number r1, first signature sign1. After obtaining the first data, the first device can encrypt the first data using the identification code of the first device.

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

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

In step S7100, the second device generates a shared key based on the first NOC and the second NOC.

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

In some embodiments, after the second device decrypts the first data, it can use the first NOC (for example, the public key corresponding to the first NOC) to verify the first signature sign1, verify the identity of the first device and the password of the first device. The authenticity of the key pair.

In some embodiments, the second device can also use the stored CA certificate to verify the NOC sent by the first device. Taking the interoperability certificate chain as a three-level interoperability certificate chain as an example, the second device can use the stored RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify the first NOC. .

In some embodiments, after the second device decrypts the first data, it can generate a random number r2, and then use the private key corresponding to the second NOC to compare the CA certificate of the first device stored in the second NOC and the second device (for example, store ICAC), random number r2 and other information are encrypted to obtain the second signature sign2, and further obtain the second data. The second data may include one or more of the following information: the second NOC, the third The second device stores the CA certificate of the first device (for example, the stored ICAC), the random number r2, and the second signature sign2.

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

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

In step S7120, the first device generates a shared key based on the second NOC and the first NOC.

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

In some embodiments, the first device can also use the CA certificate of the first device to verify the NOC sent by the second device. Taking the interoperability certificate chain as a three-level interoperability certificate chain as an example, the first device can use the RCAC of the first device to verify the ICAC sent by the second device, and use the stored ICAC of the first device to verify the second NOC.

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

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

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

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

Example 2 (using temporary identification code)

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

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

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

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

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

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

In step S8050, the second device returns a fourth response to the first device. The fourth response may be used to indicate the key negotiation method supported by the second device. For example, the key negotiation method supported by the second device is NOC-based negotiation.

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

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

In step S8070, the second device returns a first identification code to the first device. The first identification code may be a temporary identification code.

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

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

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

As an implementation manner, after the first device inputs the temporary identity code, it can first generate a random number r1, and then use the private key corresponding to the first NOC to compare the first NOC and the first device's CA certificate (for example, the first device's CA certificate). ICAC), random number r1 and other information are encrypted to obtain the first signature sign1, and further obtain the first data. The first data may include one or more of the following information: the first NOC, the first The CA certificate of the device (for example, the ICAC of the first device), the random number r1, and the first signature sign1. After obtaining the first data, the first device can encrypt the first data using the identification code of the first device.

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

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

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

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

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

In some embodiments, after the second device decrypts the first data, it can use the public key corresponding to the first NOC to verify the first signature sign1 to verify the identity of the first device and the authenticity of the key pair of the first device.

In some embodiments, the second device can also use the stored CA certificate to verify the NOC sent by the first device. Taking the interoperability certificate chain as a three-level interoperability certificate chain as an example, the second device can use the stored RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify the first NOC. .

In some embodiments, after the second device decrypts the first data, it can generate a random number r2, and then use the private key corresponding to the second NOC to compare the CA certificate of the first device stored in the second NOC and the second device (for example, store ICAC), random number r2 and other information are encrypted to obtain the second signature sign2, and further obtain the second data. The second data may include one or more of the following information: the second NOC, the third The second device stores the CA certificate of the first device (for example, the stored ICAC), the random number r2, and the second signature sign2.

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

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

In step S8120, the first device generates a shared key based on the second NOC and the first NOC.

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

In some embodiments, the first device can also use the CA certificate of the first device to verify the NOC sent by the second device. Taking the interoperability certificate chain as a three-level interoperability certificate chain as an example, the first device can use the RCAC of the first device to verify the ICAC sent by the second device, and use the stored ICAC of the first device to verify the second NOC.

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

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

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

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

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

Figure 9 is a schematic structural diagram of a device for establishing an interoperability channel provided by an embodiment of the present application. The device may be configured in the first device mentioned above. The device 900 shown in FIG. 9 may include a first negotiation module 910, an establishment module 920 and a control module 930.

The first negotiation module 910 may be configured to negotiate a shared key with the second device according to the first NOC of the first device.

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

The control module 930 may be configured to send a control instruction to a second device through the interoperation channel to control the second device, where the first device is a terminal device and the second device is a vehicle device.

Optionally, the first negotiation module further includes: a first sending module, configured to send a first message to the second device, where the first message includes first data, and the first data includes the first NOC. , the first NOC is used by the second device to generate the shared key; the first receiving module is used to receive the first response from the second device, where the first response contains second data, The second data includes the second NOC; a generating module is configured to generate the shared key according to the second NOC and the first NOC.

Optionally, the first data also includes one or more of the following information: the device certification center CA certificate of the first device, the random number generated by the first device, and the first signature; and/or, The second data also includes one or more of the following information: the CA certificate of the first device, a random number generated by the second device, and a second signature.

Optionally, the first signature is obtained by the first device using the private key corresponding to the first NOC to encrypt one or more of the following information: the first NOC, the first device's CA certificate, random number generated by the first device; the second signature is obtained by the second device using the private key corresponding to the second NOC to encrypt one or more of the following information: The second NOC, the CA certificate of the first device, and the random number generated by the second device.

Optionally, the apparatus 900 further includes: a verification module, configured to verify the second NOC using the CA certificate of the first device.

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

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

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

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

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

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

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

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

Optionally, the third negotiation module further includes: a fourth sending module, configured to send a fourth message to the second device, where the fourth message is used to indicate the key negotiation method supported by the first device; Three receiving modules, configured to receive the fourth response from the second device, where the fourth response is used to indicate negotiating the shared key based on the NOC.

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

Optionally, the shared key is generated by the first device based on one or more of the following information: a first key, a random number generated by the first device, a random number generated by the second device , the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein the first key is the first device according to the second NOC The corresponding public key and the private key corresponding to the first NOC are generated.

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

The first negotiation module 1010 may be configured to negotiate a shared key with the first device according to the second NOC of the second device.

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

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

Optionally, the first negotiation module further includes: a second receiving module, configured to receive a first message sent by the first device, where the first message includes first data, and the first data includes the first NOC; a generating module, configured to generate the shared key according to the first NOC and the second NOC; a first sending module, configured to send the first response to the first device, the A response includes second data, the second data includes the second NOC, and the second NOC is used by the first device to generate the shared key.

Optionally, the first data also includes one or more of the following information: the device certification center CA certificate of the first device, the random number generated by the first device, and the first signature; and/or, The second data also includes one or more of the following information: the CA certificate of the first device, a random number generated by the second device, and a second signature.

Optionally, the first signature is obtained by the first device using the private key corresponding to the first NOC to encrypt one or more of the following information: the first NOC, the first device's CA certificate, random number generated by the first device; the second signature is obtained by the second device using the private key corresponding to the second NOC to encrypt one or more of the following information: The second NOC, the CA certificate of the first device, and the random number generated by the second device.

Optionally, the apparatus 1000 further includes: a verification module, configured to verify the first NOC using the CA certificate of the first device.

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

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

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

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

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

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

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

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

Optionally, the third negotiation module further includes: a fifth receiving module, configured to receive a fourth message sent by the first device, where the fourth message is used to indicate the key negotiation method supported by the first device; The second sending module is configured to send the fourth response to the first device, where the fourth response is used to indicate negotiating the shared key based on the NOC.

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

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 , the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein the second key is the second device according to the first NOC The corresponding public key and the corresponding private key of the second NOC are generated.

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

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

Apparatus 1100 may include one or more processors 1110. The processor 1110 can support the device 1100 to implement the method described in the foregoing method embodiments. The processor 1110 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor can also be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or an off-the-shelf programmable gate array (FPGA) Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

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

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

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

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

Claims (71)

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

   The first device negotiates a shared key with the second device based on the first node interoperability certificate NOC of the first device;

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

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

   Wherein, the first device is a terminal device, and the second device is a vehicle device.
2. The method of claim 1, wherein the first device negotiates a shared key with the second device based on the first NOC of the first device, including:

   The first device sends a first message to the second device, the first message includes first data, the first data includes the first NOC, and the first NOC is for the second device. Generate the shared key;

   The first device receives a first response from the second device, the first response includes second data, and the second data includes a second NOC of the second device;

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

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

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

   The second signature is obtained by the second device using the private key corresponding to the second NOC to encrypt one or more of the following information: the second NOC, the CA certificate of the first device , a random number generated by the second device.
5. The method according to any one of claims 2-4, characterized in that, after the first device receives the first response from the second device, the method further includes:

   The first device verifies the second NOC using the CA certificate of the first device.
6. The method according to any one of claims 2-5, characterized in that, before the first device sends the first message to the second device, the method further includes:

   The first device encrypts the first data according to the identification code of the first device.
7. The method according to claim 6, characterized in that, before the first device encrypts the first data according to the identification code of the first device, the method further includes:

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

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

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

    The method also includes:

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

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

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

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

    The second device negotiates a shared key with the first device based on the second node interoperability certificate NOC of the second device;

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

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

    Wherein, the first device is a terminal device, and the second device is a vehicle device.
18. The method of claim 17, wherein the second device negotiates a shared key with the first device based on the second NOC of the second device, including:

    The second device receives the first message sent by the first device, the first message includes first data, and the first data includes the first NOC of the first device;

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

    The second device sends a first response to the first device, the first response includes second data, the second data includes the second NOC, and the second NOC is for the first device Generate the shared key.
19. The method according to claim 18, characterized in that:

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

    The second data also includes one or more of the following information: the CA certificate of the first device, a random number generated by the second device, and a second signature.
20. The method of claim 19, wherein the first signature is obtained by the first device using the private key corresponding to the first NOC to encrypt one or more of the following information: The first NOC, the CA certificate of the first device, and the random number generated by the first device;

    The second signature is obtained by the second device using the private key corresponding to the second NOC to encrypt one or more of the following information: the second NOC, the CA certificate of the first device , a random number generated by the second device.
21. The method according to any one of claims 18-20, characterized in that, after the second device receives the first message sent by the first device, the method further includes:

    The second device verifies the first NOC using the CA certificate of the first device.
22. The method according to any one of claims 18-21, characterized in that, after the second device receives the first message sent by the first device, the method further includes:

    The second device decrypts the first data according to the identification code of the first device.
23. The method according to claim 22, characterized in that, before the second device decrypts the first data according to the identification code of the first device, the method further includes:

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

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

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

    The method also includes:

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

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

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

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

    A first negotiation module configured to negotiate a shared key with the second device based on the first node interoperability certificate NOC of the first device;

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

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

    Wherein, the first device is a terminal device, and the second device is a vehicle device.
34. The device according to claim 33, 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, where the first data includes the first NOC, and the first NOC is used for the third device. The second device generates the shared key;

    A first receiving module configured to receive a first response from the second device, the first response including second data, and the second data including the second NOC;

    A generating module, configured to generate the shared key according to the second NOC and the first NOC.
35. The device according to claim 34, characterized in that:

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

    The second data also includes one or more of the following information: the CA certificate of the first device, a random number generated by the second device, and a second signature.
36. The device according to claim 35, wherein the first signature is obtained by the first device using the private key corresponding to the first NOC to encrypt one or more of the following information: The first NOC, the CA certificate of the first device, and the random number generated by the first device;

    The second signature is obtained by the second device using the private key corresponding to the second NOC to encrypt one or more of the following information: the second NOC, the CA certificate of the first device , a random number generated by the second device.
37. The device according to any one of claims 34-36, characterized in that the device further includes:

    A verification module, configured to use the CA certificate of the first device to verify the second NOC.
38. The device according to any one of claims 34-37, characterized in that the device further includes:

    An encryption module, configured to encrypt the first data according to the identification code of the first device.
39. The device of claim 38, further comprising:

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

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

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

    The device also includes:

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

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

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

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

    A first negotiation module configured to negotiate a shared key with the first device based on the second node interoperability certificate NOC of the second device;

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

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

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

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

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

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

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

    The second data also includes one or more of the following information: the CA certificate of the first device, a random number generated by the second device, and a second signature.
52. The device according to claim 51, wherein the first signature is obtained by the first device using the private key corresponding to the first NOC to encrypt one or more of the following information: The first NOC, the CA certificate of the first device, and the random number generated by the first device;

    The second signature is obtained by the second device using the private key corresponding to the second NOC to encrypt one or more of the following information: the second NOC, the CA certificate of the first device , a random number generated by the second device.
53. The device according to any one of claims 50-52, characterized in that the device further includes:

    A verification module, configured to verify the first NOC using the CA certificate of the first device.
54. The device according to any one of claims 50-53, characterized in that the device further includes:

    A decryption module, configured to decrypt the first data according to the identification code of the first device.
55. The device of claim 54, further comprising:

    The second negotiation module is configured to negotiate a first identity code with the first device. The first identity code is used for the device corresponding to the first identity code to access the second device.
56. The device according to claim 55, 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 identification code.
57. The device according to claim 55, characterized in that the second negotiation module further includes:

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

    The device also includes:

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

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

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

    The second sending module is configured to send a fourth response to the first device, where the fourth response is used to indicate negotiating the shared key based on the NOC.
63. The device according to claim 62, wherein the key negotiation method supported by the first device and/or the second device includes one or more of the following methods: based on key pair negotiation, based on NOC negotiation, and negotiation based on sigma protocol.
64. The device according to any one of claims 49-63, characterized in that the shared key is generated by the second device according to one or more of the following information: the second key, the The random number generated by the first device, the random number generated by the second device, the device identification of the first device, the device identification of the second device, and the identification code of the first device, wherein, The second key is generated by the second device based on the public key corresponding to the first NOC and the private key corresponding to the second NOC.
65. A communication device, characterized in that the communication device is configured in a first device, the device includes a memory and a processor, the memory is used to store programs, and the processor is used to call the program in the memory to The first device is caused to perform the method according to any one of claims 1-16.
66. A communication device, characterized in that the communication device is configured in a second device, the device includes a memory and a processor, the memory is used to store programs, and the processor is used to call the program in the memory to The second device is caused to perform the method according to any one of claims 17-32.
67. A device, characterized by comprising a processor for calling a program from a memory, so that the device executes the method according to any one of claims 1-32.
68. A chip, characterized in that it includes a processor for calling a program from a memory, so that a device equipped with the chip executes the method according to any one of claims 1-32.
69. A computer-readable storage medium, characterized in that a program is stored thereon, and the program causes the computer to execute the method according to any one of claims 1-32.
70. A computer program product, characterized by comprising a program that causes a computer to execute the method according to any one of claims 1-32.
71. A computer program, characterized in that the computer program causes the computer to perform the method according to any one of claims 1-32.

Images