WO2023230975A1 - 建立互操作通道的方法、装置、芯片和存储介质 - Google Patents

建立互操作通道的方法、装置、芯片和存储介质 Download PDF

Info

Publication number
WO2023230975A1
WO2023230975A1 PCT/CN2022/096777 CN2022096777W WO2023230975A1 WO 2023230975 A1 WO2023230975 A1 WO 2023230975A1 CN 2022096777 W CN2022096777 W CN 2022096777W WO 2023230975 A1 WO2023230975 A1 WO 2023230975A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
message
identification code
negotiation
data
Prior art date
Application number
PCT/CN2022/096777
Other languages
English (en)
French (fr)
Inventor
包永明
吕小强
茹昭
张军
杨宁
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to PCT/CN2022/096777 priority Critical patent/WO2023230975A1/zh
Publication of WO2023230975A1 publication Critical patent/WO2023230975A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • the 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.
  • This application provides a method, device, chip and storage medium for establishing an interoperability channel. Each aspect involved in this application is introduced below.
  • a method for establishing an interoperability channel including: a first device negotiates a shared key with a second device according to a sigma protocol; the first device and the second device establish a shared key based on the shared key. interoperation channel; the first device sends control instructions to the second device through the interoperation channel to control the second device, where the first device is a terminal device, and the first device
  • the second equipment is vehicle equipment.
  • a method for establishing an interoperability channel including: a second device negotiates a shared key with a first device according to a sigma protocol; and the second device and the first device establish a shared key based on the shared key.
  • a device for establishing an interoperability channel is provided.
  • the device is configured on a first device.
  • the device includes: a first negotiation module for negotiating a shared key with a second device according to the sigma protocol; an establishment module , configured to establish an interoperability channel based on the shared key with the second device; a control module configured to send control instructions to the second device through the interoperability channel to perform operations on the second device.
  • Control wherein the first device is a terminal device and the second device is a vehicle device.
  • a device for establishing an interoperability channel is provided.
  • the device is configured on a second device.
  • the device includes: a first negotiation module for negotiating a shared key with the first device according to the sigma protocol; and an establishment module. , configured to establish an interoperability channel based on the shared key with the first device; a first receiving module, configured to receive control instructions of the first device through the interoperability channel, wherein the first The device is a terminal device, and the second device is a vehicle device.
  • a communication device 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.
  • a communication device 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
  • 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.
  • embodiments of the present application provide a communication system, which includes the above communication device.
  • the system may also include other devices that interact with the communication device in the solution provided by the embodiments of the present application.
  • 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.
  • 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.
  • the computer program product can be a software installation package.
  • 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.
  • the first device and the second device can negotiate the shared key corresponding to the interoperability channel based on the sigma protocol to ensure the security and reliability of the communication of the interoperability channel and realize the communication between the first device and the second device. safely control.
  • Negotiating the shared key based on the sigma protocol helps reduce the risk of the shared key being leaked.
  • FIG. 1 is an architectural example diagram of a wireless communication system applicable to embodiments of the present application.
  • Figure 2 is a schematic flowchart of key exchange based on the sigma protocol provided by an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of a method for establishing an interoperability channel according to an embodiment of the present application.
  • FIG. 4 is a schematic flowchart of a possible implementation of step S310 in FIG. 3 .
  • Figure 5 is a schematic flowchart of negotiating a first identity code according to an embodiment of the present application.
  • Figure 6 is a schematic flowchart of negotiating a first identity code provided by another embodiment of the present application.
  • Figure 7 is a schematic flowchart of a negotiation method for negotiating a shared key provided by an embodiment of the present application.
  • Figure 8 is a schematic flowchart of a method for establishing an interoperability channel provided by another embodiment of the present application.
  • Figure 9 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application.
  • Figure 10 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application.
  • Figure 11 is a schematic structural diagram of a device for establishing an interoperability channel provided by an embodiment of the present application.
  • Figure 12 is a schematic structural diagram of an apparatus for establishing an interoperability channel provided by another embodiment of the present application.
  • Figure 13 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • FIG. 1 is an architectural example diagram of a wireless communication system 100 applicable to embodiments of the present application.
  • 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 .
  • a first device controls a second device.
  • 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.
  • wired for example, USB interface
  • wireless network for example, Bluetooth or mobile network
  • Figure 1 exemplarily shows a first device 110 and a second device 120, but the embodiment of the present application is not limited thereto.
  • the wireless communication system 100 may include multiple first devices and/or multiple second devices.
  • a first device may control multiple second devices, or a second device may receive multiple first devices.
  • 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.
  • the first device 110 can communicate with the third device through the second device 120.
  • the first device 110 can control or access the third device through the second device 120.
  • the second device 120 can be understood as a relay device or a bridge device.
  • 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.
  • 5G fifth generation
  • NR new radio
  • long term evolution long term evolution
  • LTE long term evolution
  • TDD LTE time division duplex
  • Bluetooth wireless fidelity
  • wireless fidelity wireless fidelity
  • WiFi wireless fidelity
  • 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.
  • 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.
  • 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.
  • IoT Internet of things
  • VR virtual reality
  • AR augmented reality
  • IoT devices may include smart travel tools such as vehicles and ships.
  • IoT devices may include smart home devices such as smart TVs, smart air conditioners, smart refrigerators, and sweeping robots.
  • IoT devices may include smart monitoring devices such as surveillance cameras, temperature sensors, sound sensors, etc.
  • the vehicle can be, for example, a family car, a taxi, a bus, a motorcycle, etc.
  • 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.
  • the first device 110 and the second device 120 may be different types of devices to achieve interoperation between different types of devices.
  • the first device 110 can be a handheld terminal device such as a mobile phone or a tablet computer
  • 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.).
  • the first device 110 and the second device 120 may be devices from different manufacturers to achieve interoperability between devices of different manufacturers.
  • the first device 110 may be a device from a first manufacturer
  • 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.
  • first device and the second device are located.
  • the first device and the second device may be deployed on land, including indoors or outdoors, handheld or vehicle-mounted.
  • 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.
  • the second device may refer to a vehicle, a ship, or other smart travel tool
  • 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.
  • the mobile phone and the vehicle can realize the control of the vehicle by the mobile phone by establishing an interoperability channel.
  • the mobile phone controls the opening of the car door and the opening of the car window.
  • the second device may refer to a smart home device such as a smart air conditioner or a smart TV
  • 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.
  • 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.
  • different devices can achieve interoperability between devices by establishing interoperability channels, for example, to enable a first device to control a second device.
  • embodiments of the present application provide a method, device, chip, storage medium and program product for establishing an interoperability channel to negotiate the shared key corresponding to the interoperability channel based on the sigma protocol, which helps to reduce the number of shared keys. Risk of leakage.
  • the sigma protocol can be understood as an efficient interactive zero-knowledge proof protocol that allows the prover to prove to the verifier that he knows the secret without showing the secret to the verifier.
  • the sigma protocol can be understood as a key exchange protocol that can further ensure the security of key exchange by using digital signatures for authentication.
  • the participants of the sigma protocol may include an initiator (initiator) of the initiating process and a receiver (responder) of the response process.
  • the initiator and responder can exchange keys through one or more rounds of sigma messages.
  • Figure 2 is a schematic flowchart of key exchange based on the sigma protocol provided by an embodiment of the present application. The following is an exemplary explanation of the key exchange between the initiator and the responder based on the sigma protocol in conjunction with Figure 2.
  • step S210 the initiator constructs a sigma1 message and sends the sigma1 message to the responder.
  • the sigma1 message can be used to request the responder to perform key exchange or key negotiation.
  • the sigma1 message may be a clear text message.
  • the sigma1 message may be a ciphertext message.
  • step S220 the responder generates a shared key based on the sigma1 message sent by the initiator, and sends the constructed sigma2 message to the initiator.
  • the responder before generating the shared key, can verify the sigma1 message sent by the initiator, and execute step S220 after passing the verification.
  • step S230 the initiator generates a shared key based on the sigma2 message sent by the responder, and sends the constructed sigma3 message to the responder.
  • the initiator before generating the shared key, can verify the sigma2 message sent by the responder, and execute step S230 after passing the verification.
  • step S240 the responder verifies the sigma3 message, and returns a sigma verification completion message to the initiator after passing the verification.
  • Node operational certificate (NOC)
  • a device's NOC can be used to authenticate the device's identity.
  • the NOC of the device can store the key information corresponding to the NOC.
  • the NOC of the device can store the public key information corresponding to the NOC, but the corresponding private key information cannot be stored in the NOC.
  • the NOC of the first device (or the first NOC) can store the public key corresponding to the NOC of the first device
  • the NOC of the second device (or the second NOC) can store the public key of the second device.
  • the embodiments of the present application are not limited to this.
  • the NOC of the device may also store other information besides the key information corresponding to the NOC, such as the device identification of the device and so on.
  • an interoperable certificate chain can be used to verify the NOC of the device.
  • an interoperable certificate chain issued by a device certification authority (certificate authority, CA) can be used. Verify the NOC of the device.
  • 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.
  • 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.
  • ICAC can be signed by RCAC
  • NOC can be signed by ICAC.
  • ICAC can be used to verify the NOC
  • RCAC can be used to verify the ICAC.
  • a secondary interoperability certificate chain may be used to verify the NOC of the device.
  • Secondary interoperability certificate chains can include RCAC and NOC.
  • the NOC can be signed by RCAC.
  • RCAC can be used to verify the NOC.
  • 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.
  • the certificate chain may include the RCAC of the first device, the ICAC of the first device, and the NOC of the second device,
  • the NOC of the second device may contain the public key corresponding to the NOC of the second device, and the private key corresponding to the NOC of the second device can only be stored in the second device.
  • the certificate chain may include the RCAC of the first device and the NOC of the second device, and the NOC of the second device may include the second device.
  • the public key corresponding to the NOC and the private key corresponding to the NOC of the second device can only be stored in the second device.
  • 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).
  • Figure 3 is a schematic flowchart of a method for establishing an interoperability channel provided by an embodiment of the present application. The method shown in Figure 3 is described from the perspective of interaction between the first device and the second device.
  • the first device and the second device may be, for example, the first device 110 and the second device 120 in FIG. 1 .
  • the embodiments of the present application do not limit the specific types of the first device and the second device, as long as the first device and the second device can interoperate or realize the control of the second device by the first device.
  • 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.
  • the first device may be a terminal device
  • the second device may be a vehicle device.
  • the method shown in Figure 3 may include steps S310 to S330, and these steps will be described in detail below.
  • step S310 the first device and the second device negotiate a shared key based on the sigma protocol.
  • the first device may be called an initiator, and the second device may be called a responder.
  • the first device and the second device may negotiate a shared key based on one or more rounds of sigma messages.
  • the first device and the second device may negotiate a shared key based on the sigma protocol and the device's NOC.
  • the NOC information of the device may be carried in the sigma message to negotiate the shared key between the first device and the second device.
  • 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.
  • the first device and the second device negotiate and determine the shared key in a negotiation manner: negotiating the shared key based on the sigma protocol. How the first device and the second device negotiate to determine the shared key will be introduced in detail later, and will not be described here.
  • 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.
  • the first device and the second device may generate the shared key based on one or more types of information.
  • the first device and the second device may use some key algorithms to generate the shared key.
  • both devices may use the same key algorithm to generate the shared key to ensure the security of the generated shared key.
  • 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.
  • step S320 the first device and the second device establish an interoperation channel based on the shared key.
  • the shared key is used to encrypt and security protect the communication between the first device and the second device.
  • the shared key can be used to encrypt information transmitted in the interoperability channel to improve communication security.
  • an interoperability channel can be understood as a control channel (or security control channel).
  • the first device can use the interoperability channel to The second device takes control.
  • 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.
  • 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.
  • step S330 the first device controls the second device through the interoperation channel.
  • the first device can send a control command (control instruction) to the second device through an interoperation channel to control the second device.
  • 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.
  • the first device controlling the second device may mean controlling opening of the vehicle door, closing of the vehicle window, etc.
  • 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.
  • the first device controlling the second device may refer to the first device accessing resources of the second device.
  • the first device controlling the second device may refer to checking the temperature of the second device, so that when the temperature of the second device exceeds a certain threshold, some operations are performed on the second device. .
  • the first device and the second device can negotiate the shared key corresponding to the interoperability channel based on the sigma protocol to ensure the security and reliability of the communication of the interoperability channel and realize the communication between the first device and the second device. safely control.
  • Negotiating the shared key based on the sigma protocol helps reduce the risk of the shared key being leaked.
  • step S310 does not limit the implementation manner of step S310.
  • a possible implementation manner of step S310 is given below with reference to Figure 4, and the process of the first device and the second device negotiating a shared key based on the sigma protocol is described in detail.
  • step S310 may include steps S312 to S318, and these steps will be described in detail below.
  • 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.
  • the first message may also be called a sigma1 message.
  • the first message includes first data
  • the first data includes the temporary public key of the first device.
  • the embodiment of the present application does not limit the source of the temporary public key of the first device.
  • the temporary public key of the first device may be generated by the first device, for example, before sending the first message. It should be understood that when the first device generates the temporary public key of the first device, it may also generate a temporary private key of the first device, and the temporary public key and the temporary private key form a temporary key pair of the first device.
  • the first data may also include other information in addition to the temporary public key of the first device.
  • the first data may also include one or more of the following information: a session identifier of the first device, a random number generated by the first device.
  • the first device may Encrypt. Specifically, the first device may encrypt the first data according to the identification code of the first device before sending the first message to the second device.
  • the identification code of the first device may be configured by the first device for the second device in advance or may be generated by the second device. The identification code of the first device will be described in detail later and will not be described in detail here.
  • the session identifier of the first device may be used to identify a subsequent session with the first device.
  • the random numbers generated by the first device can be used to prevent replay attacks.
  • 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 device after the first device encrypts the first data using the first device's identification code, and after the second device receives the first message sent by the first device, it can encrypt the first data according to the first device's identification code. Decrypt. After the second device successfully decrypts the first data, it can learn the temporary public key of the first device and other information in the first data, thus avoiding the problem of easy leakage caused by the clear text transmission of the temporary public key of the first device.
  • the first data may also include a first destination identifier, and the first destination identifier may be used by the second device to verify the identity of the first device. In some embodiments, the first destination identifier can be used by the second device to find the correct NOC to establish a connection.
  • the first data containing the first destination identifier may mean that the first data includes the temporary public key of the first device and the first destination identifier; or the first data includes, in addition to the temporary public key and the first destination identifier of the first device. , may also include at least one of a session identifier of the first device and a random number generated by the first device.
  • the first destination identifier may be obtained by the first device encrypting the first information according to the identity code of the first device.
  • the first information may include one or more of the following information: a random number generated by the first device, a device identification of the second device, and a public key corresponding to the CA certificate of the first device.
  • the public key corresponding to the CA certificate of the first device may refer to the public key corresponding to the RCAC of the first device.
  • the first device when the first data contains the first destination identifier, the first device can encrypt the first information according to the first device's identification code to obtain the first destination identifier, without using the first device's identification code to encrypt the first information.
  • the first data is encrypted as a whole.
  • the first device when the first data does not contain the first destination identifier, the first device can encrypt the first data according to the identity identification code of the first device; when the first data contains the first destination identifier, the first device The device may encrypt the first information based on the identification code of the first device, and obtain the first destination identifier by encrypting the first information. Other information in the first data other than the first destination identifier may not be encrypted.
  • the second device when the first data contains the first destination identifier, after the second device receives the first message sent by the first device (the first message contains the first data, and the first data contains the first destination identifier), the second device
  • the first information can be encrypted according to the identity identification code of the first device to obtain the second destination identifier, and the identity of the first device can be verified based on the first destination identifier and the second destination identifier.
  • the first device verifying the identity of the first device based on the first destination identifier and the second destination identifier may mean that after the second device obtains the second destination identifier, it determines the first destination identifier and the second destination identifier. Regarding the consistency between the identifiers, if the second destination identifier is the same as the first destination identifier, the verification can be considered as passed; if the second destination identifier is different from the first destination identifier, the verification can be considered as failed.
  • step S314 the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.
  • the second device generating the shared key based on the temporary public key of the first device and the temporary private key of the second device may mean that the second device generates the shared key based on the temporary public key of the first device and the temporary private key of the second device.
  • the temporary private key generates a second key, and then the shared key is generated based on the second key.
  • the second device may generate the shared key based on the second key and one or more of the following information: a random number generated by the second device, and a temporary public key of the second device.
  • the second device can use one or more of the information as key parameters and use a key algorithm (or key derivation algorithm) to generate the shared key.
  • the embodiment of the present application does not limit the key algorithm used by the second device.
  • DES algorithm For example, DES algorithm, AES algorithm, etc. can be used.
  • the key parameters corresponding to the key algorithm may include the second key, the salt value, the description information of the shared key generated by the second device, and One or more types of information such as the length information of the shared key generated by the second device.
  • the salt value may be randomly generated.
  • the salt value may be randomly generated based on one or more of the following information: an identity protection key (identify protection key, IPK), a random number generated by the second device, the temporary public key of the second device, and the second device's temporary public key.
  • IPK identity protection key
  • a hash value, wherein the first hash value may refer to a value obtained by hashing the first data using a hash algorithm.
  • the temporary public key of the first device may be carried by the first device in the first message.
  • the random number generated by the second device and the temporary public key of the second device may be temporarily generated by the second device before generating the shared key.
  • the embodiment of the present application does not limit the source of the temporary public key of the second device.
  • the temporary public key of the second device may be generated by the second device, for example, before the shared key of the second device is generated. Or generated after receiving the first message. It should be understood that when the second device generates the temporary public key of the second device, it can also generate a temporary private key of the second device, and the temporary public key and the temporary private key form a temporary key pair of the second device.
  • the second device may also use the generated shared key to encrypt the third data to obtain the first encryptData.
  • the embodiments of this application do not limit the specific content of the third data.
  • the third data may include one or more of the following information: the NOC of the second device, the CA certificate of the first device, and the second signature.
  • the second signature can be understood as a signature generated by the second device using the private key corresponding to the NOC of the second device.
  • the CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment.
  • the CA certificate of the first device included in the third data may refer to the ICAC certificate of the first device; if the first device When the device and the second device perform identity verification based on the secondary interoperability certificate chain, the CA certificate of the first device included in the third data may refer to the RCAC certificate of the first device.
  • the second signature may include one or more of the following information: the NOC of the second device, the CA certificate of the first device, and the temporary public key of the second device.
  • the NOC of the second device may contain the public key corresponding to the NOC of the second device.
  • the CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment.
  • the second device sends a second message to the first device.
  • the second message may also be called a sigma2 message.
  • the second message contains second data.
  • the second data contains the temporary public key of the second device.
  • the second data may include other information in addition to the temporary public key of the second device.
  • the second data may also include one or more of the following information: the session identifier of the second device, the random number generated by the second device, and the first encryptData.
  • the session identifier of the second device may be used to identify a subsequent session with the second device.
  • 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.
  • step S318 the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.
  • the first device generating the shared key based on the temporary public key of the second device and the temporary private key of the first device may mean that the first device generates the shared key based on the temporary public key of the second device and the first device's temporary private key.
  • the temporary private key generates a first key, and then a shared key is generated based on the first key.
  • the first device may generate the shared key based on the first key and one or more of the following information: a random number generated by the first device, and a temporary public key of the first device.
  • the first device can use one or more of the information as key parameters and use a key algorithm to generate the shared key.
  • the first device can use the same key algorithm as the second device to generate the shared key. Shared key.
  • the embodiment of the present application does not limit the key algorithm used by the first device.
  • DES algorithm For example, DES algorithm, AES algorithm, etc. can be used.
  • the key parameters corresponding to the key algorithm may include the first key, the salt value, the description information of the shared key generated by the first device, and One or more types of information such as the length information of the shared key generated by the first device.
  • the salt value may be randomly generated.
  • the salt value may be randomly generated based on one or more of the following information: an identity protection key (identify protection key, IPK), a random number generated by the first device, a temporary public key of the first device, and a Two hash values, where the second hash value may refer to a value obtained by hashing the first data or the second data using a hash algorithm.
  • IPK identity protection key
  • IPK identify protection key
  • Two hash values where the second hash value may refer to a value obtained by hashing the first data or the second data using a hash algorithm.
  • the temporary public key of the second device may be carried by the second device in the second message.
  • the first device may also verify the identity of the second device before generating the shared key based on the temporary public key of the second device and the temporary private key of the first device. For example, the first device can obtain the shared key based on the first key, use the shared key to decrypt the first encryptData in the second data, and parse out the corresponding data.
  • the first device can also use the NOC to verify the identity of the second device.
  • the configured interoperability certificate chain is a three-level interoperability certificate chain
  • the first device can use the first device
  • the RCAC is used to verify the ICAC sent by the second device, and the stored ICAC of the first device is used to verify the NOC of the second device;
  • the configured interoperability certificate chain is a second-level interoperability certificate chain
  • the first device can use the second-level interoperability certificate chain.
  • One device's RCAC checks the second device's NOC.
  • the first device can also use the public key corresponding to the NOC of the second device to verify the second signature generated by the second device.
  • the first device may also use the generated shared key to encrypt the fourth data to obtain the second encryptData.
  • the embodiment of the present application does not limit the specific content of the fourth data.
  • the fourth data may include one or more of the following information: the NOC of the first device, the CA certificate of the first device, and the first signature.
  • the first signature can be understood as a signature generated by the first device using the private key corresponding to the NOC of the first device.
  • the CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment.
  • the CA certificate of the first device included in the fourth data may refer to the ICAC certificate of the first device; if the first device When the device and the second device perform identity verification based on the secondary interoperability certificate chain, the CA certificate of the first device included in the fourth data may refer to the RCAC certificate of the first device.
  • the first signature may include one or more of the following information: the NOC of the first device, the CA certificate of the first device, and the temporary public key of the first device.
  • the NOC of the first device may include a public key corresponding to the NOC of the first device.
  • the CA certificate of the first device may refer to the RCAC certificate of the first device, or may refer to the ICAC certificate of the first device, which is not limited in this application embodiment.
  • the first device may send a sigma3 message to the second device, and the sigma3 message may include the third A second encryptData generated by a device.
  • the second device may process the sigma3 message.
  • the second device may decrypt the second encryptData using the generated shared key. The process of the second device generating the shared key can be found in the previous section and will not be described again here.
  • the second device can verify the identity of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device can use the RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify NOC of the first device; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the second device can use the RCAC of the first device to verify the NOC of the first device.
  • the second device can also use the public key corresponding to the NOC of the first device to verify the first signature generated by the first device.
  • the second device may return a sigma verification completion message to the first device, and the sigma verification completion message may be used to indicate that the second device has determined the shared key.
  • the first device and the second device negotiate the shared key corresponding to the interoperability channel based on one or more rounds of sigma messages.
  • the negotiation process is relatively complex, making the negotiated shared key more secure.
  • the first data is data encrypted using the identification code of the first device.
  • the first destination identifier is data encrypted using the identification code of the first device.
  • the information is encrypted. The following describes the encryption performed by the first device according to the identification code of the first device. It should be understood that the encryption can be applied to encrypt the first data, or can also be applied to encrypt the first information to obtain the first purpose identifier. The application examples do not limit this.
  • 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.
  • the identification code of the first device can be used to encrypt the first data or the first information to prevent the first data or the first information from being leaked during transmission.
  • the identification code of the first device may be represented by a PIN code.
  • the first device when the first device encrypts the first data based on the identity code of the first device, after the second device receives the first data, it needs to encrypt the first data based on the identity code of the first device. Data is decrypted.
  • the second device when the first device encrypts the first information according to the identity code of the first device to obtain the first destination identifier, after receiving the first message, the second device needs to encrypt the first information according to the identity of the first device.
  • the identification code encrypts the first information in the first message to obtain the second destination identifier, and then verifies the identity of the first device based on the first destination identifier and the second destination identifier.
  • the identity code of the first device may be determined through negotiation between the first device and the second device. That is to say, before the first device encrypts the first data or the first information according to the first device's identification code, the first device can also negotiate the first identification code with the second device, and the first identification code The identification code can be used for the device corresponding to the first identification code to access the second device. That is, when a device wants to access the second device, it needs to use its corresponding first identification code as a credential to access the second device. Access.
  • This application does not specifically limit the implementation method of negotiating the first identity code between the first device and the second device. Exemplarily, two implementation methods for the first device and the second device to negotiate the first identity code are introduced below with reference to FIG. 5 and FIG. 6 respectively.
  • FIG. 5 is a schematic flowchart of a first device negotiating a first identity code with a second device according to an embodiment of the present application.
  • the first device sends a third message to the second device, and the third message is used to configure the first identity code. That is to say, in this embodiment, the first identification code may be configured by the first device. In this way, each first device may correspond to a fixed identification code. Therefore, in some embodiments, using This solution in which the first device configures the first identity code can also be called a solution in which a fixed identity code is used.
  • 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.
  • the first device when configuring the first identification code, 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>.
  • 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.
  • 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.
  • 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.
  • the first data in the first message (or the first information in the first data) is encrypted using the identification code of the first device, and the index corresponding to the identification code of the first device is not encrypted.
  • 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 device corresponding to the first identification code in each tuple information can access 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.
  • the first device in addition to configuring the first identity code to the second device during the configuration phase, can also configure other information, such as configuring the interoperability certificate chain mentioned above, or configuring other basic configurations. wait.
  • the first device 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.
  • the related information of the first identification code for example, the identification code and the corresponding index
  • 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 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.
  • the second device After the second device stores the relevant information of the first identification code, it can query the correct identification code according to the identification code index sent by the first device.
  • Figure 6 is a schematic flowchart of a first device negotiating a first identity code with a second device according to another embodiment of the present application.
  • the first device sends a fourth message to the second device, and the fourth message is used to instruct the second device to return the first identity code.
  • 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.
  • the second device 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.
  • the first device may send a fourth message to the second device, and the fourth message may carry information indicating that the first device does not have an identification code, for example
  • the fourth message may carry data with an identity code index value of 0.
  • An identity code index value of 0 indicates that the first device does not have an identity code.
  • step S620 after receiving the fourth message, the second device returns the first identification code to the first device.
  • 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.
  • the second device after receiving the fourth message, the second device knows according to the fourth message that the first device does not have an identification code. Based on this, the second device can generate a temporary identification code and display the temporary identification code on on the display screen of the second device so that the first device knows the temporary identification code.
  • the second device after the second device knows that the first device does not have an identification code, it can also send a fourth response to the first device.
  • the fourth response can be used to inform the first device to input and the second device returns a response for the first device. temporary identification code.
  • the fourth response can be understood as a response message returned by the second device in response to the fourth message sent by the first device.
  • the response mentioned later can also refer to a response message returned in response to a certain message, which will not be discussed further below. Repeat.
  • the first device may send 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.
  • 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.
  • the first device after the first device inputs the temporary identification code, it may not save the temporary identification code.
  • the first device and the second device may negotiate to determine the shared key according to the key negotiation method (or type) supported by the first device and the second device respectively. negotiation method. The following describes in detail the process of the first device and the second device negotiating the shared key negotiation method with reference to Figure 7 .
  • step S710 the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.
  • the key negotiation methods supported by the first device may include one or more.
  • 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.
  • 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.
  • the first device and the second device negotiate a shared key based on the sigma protocol
  • the type of the corresponding interoperation channel is an interoperation channel based on the sigma protocol.
  • the key negotiation method supported by the first device may also be referred to as the type of interoperability establishment supported by the first device. Therefore, in some embodiments, the fifth message may also be called an interoperation session establishment request message, which is not limited by this application.
  • step S720 the second device sends a fifth response to the first device, where the fifth response is used to indicate negotiating the shared key based on the sigma protocol.
  • the second device may determine to negotiate the shared key based on the sigma protocol according to the key negotiation mode supported by the first device, and notify the first device of the information through the fifth response.
  • the second device may indicate the key negotiation method supported by the second device in the fifth response, and the first device determines the negotiation method of the shared key.
  • the key negotiation method supported by the second device may include one or more of the following methods: key pair-based negotiation, NOC-based negotiation, and sigma protocol-based negotiation.
  • the fifth response only contains the method of negotiating the shared keys based on the sigma protocol.
  • the first device can directly determine whether the shared key is negotiated based on the sigma protocol.
  • the two devices negotiate a shared secret key.
  • the second device supports multiple key negotiation methods, for example, including NOC-based negotiation and sigma protocol-based negotiation.
  • the first device can choose from the key negotiation methods supported by the second device. Choose one.
  • the key negotiation method selected by the first device is to negotiate a shared key with the second device based on the sigma protocol.
  • Example 1 the first data does not include the first destination identifier.
  • Example 1 will be described in detail below with reference to Figure 8 .
  • Figure 8 is a schematic flowchart of a method for establishing an interoperability channel provided by another embodiment of the present application. As shown in Figure 8, the method may include steps S8010 to S8170.
  • 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.
  • the first device sends a third message to the second device.
  • the third message is used to configure the first identification code and the index corresponding to the first identification code, such as configuring tuple information ⁇ pincode, pincode_index>, so that the first identification code and the index corresponding to the first identification code are configured.
  • the device corresponding to one identification code can access the second device.
  • the first device may configure multiple sets of first identification codes and indexes corresponding to the first identification codes to the second device, that is, configure multiple sets of tuple information.
  • the multiple sets of tuple information may form a configuration list, used to indicate relevant information of the first identification code.
  • the first device can correspondingly store the first identity code and the index corresponding to the first identity code. index.
  • 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).
  • the second device 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.
  • the first device configures the interoperability certificate chain to the second device. For example, the first device configures the RCAC of the first device and the NOC of the second device to the second device; or the first device configures the RCAC of the first device, the ICAC of the first device, and the NOC of the second device to the second device.
  • step S8050 the configuration between the first device and the second device ends, and the configuration channel exits.
  • the first device 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.
  • step S8060 the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.
  • 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.
  • the second device returns a fifth response to the first device.
  • the fifth response may be used to indicate the key negotiation method supported by the second device.
  • the key negotiation method supported by the second device is negotiation based on the sigma protocol.
  • step S8080 the first device encrypts the first data using the identification code of the first device.
  • the first device can generate a random number r1, a session identifier of the first device, and a temporary key pair of the first device (including the temporary public key and the temporary private key of the first device) to obtain the first data.
  • the first data may include one or more of the following information: a random number r1 generated by the first device, a session identifier of the first device, and a temporary public key of the first device.
  • the first device can then encrypt the first data using the first device's identification code.
  • 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.
  • the index corresponding to the identification code is a non-zero value or a non-full F value.
  • step S8100 the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.
  • the second device after receiving the first message, 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.
  • the second device may generate a temporary key pair of the second device (including the temporary public key and the temporary private key of the second device).
  • the second device may use the temporary public key of the first device and the temporary private key of the second device to generate the second key. It should be understood that the temporary public key of the first device may be carried in the first message.
  • the second device can also use the private key corresponding to the NOC of the second device to sign one or more of the following data to generate the second signature sign2: the NOC of the second device, the CA of the first device Certificate (e.g., ICAC of the first device), temporary public key of the second device.
  • the NOC of the second device the NOC of the second device
  • the CA of the first device Certificate e.g., ICAC of the first device
  • the second device may generate a shared key based on one or more of the following information: the second key generated based on the temporary public key of the first device and the temporary private key of the second device, the second key generated by the second device. Random number r2, temporary public key of the second device, etc.
  • the second device may encrypt the fourth data using the shared key generated by the second device to obtain the first encryptData.
  • the second device may generate a session identification for the second device.
  • the second device sends a second message to the first device, and the second message carries the second data.
  • the second data includes one or more of the following information: the random number r2 generated by the second device, the session ID of the second device, the temporary public key of the second device, and the first encryptData.
  • step S8120 the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.
  • the first device may generate the first key using the temporary public key of the second device and the temporary private key of the first device.
  • the first device can obtain the shared key based on the first key, use the shared key to decrypt the first encryptData in the second message, and parse out the corresponding data.
  • the first device may verify the identity of the second device before generating the shared key.
  • the RCAC of the first device is used to verify the ICAC sent by the second device
  • the ICAC of the first device is used to verify the NOC of the second device.
  • the first device can use the public key corresponding to the NOC of the second device to verify the second signature sign2 generated by the second device.
  • the first device can use the private key corresponding to the NOC of the first device to sign one or more of the following data to obtain the first signature sign1 of the first device: the NOC of the first device, the first The device's CA certificate (eg, the first device's ICAC), the first device's temporary public key.
  • the first device may generate a shared key based on one or more of the following information: the first key generated based on the temporary public key of the second device and the temporary private key of the first device, the first key generated by the first device. Random number r1, temporary public key of the first device, etc.
  • the first device may encrypt the fourth data using the shared key generated by the first device to obtain the second encryptData.
  • step S8130 the first device sends a sigma3 message to the second device, and the sigma3 message may include the second encryptData.
  • step S8140 the second device processes the sigma3 message.
  • the second device can use the generated shared key to decrypt the second encryptData and parse the corresponding data.
  • the second device can verify the identity of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device can use the RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify NOC of the first device; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the first device can use the RCAC of the first device to verify the NOC of the first device.
  • the second device can also use the public key corresponding to the NOC of the first device to verify the first signature generated by the first device.
  • step S8150 the second device returns a sigma verification completion message to the first device.
  • step S8160 the first device and the second device establish an interoperation channel based on the shared key.
  • step S8170 the first device controls the second device through the interoperation channel.
  • Example 2 the first data includes the first destination identifier.
  • Example 2 will be described in detail below with reference to Figure 9 .
  • Figure 9 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application. As shown in Figure 9, the method may include steps S9010 to S9170.
  • 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.
  • step S9020 the first device sends a third message to the second device.
  • the third message is used to configure the first identification code and the index corresponding to the identification code, for example, configure the tuple information ⁇ pincode, pincode_index> so that the first identity
  • the device corresponding to the identification code can access the second device.
  • the first device may configure multiple sets of first identification codes and indexes corresponding to the first identification codes to the second device, that is, configure multiple sets of tuple information.
  • the multiple sets of tuple information may form a configuration list, used to indicate relevant information of the first identification code.
  • the first device can correspondingly store the first identity code and the index corresponding to the first identity code. index.
  • 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).
  • the second device 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.
  • the first device configures the interoperability certificate chain to the second device. For example, the first device configures the RCAC of the first device and the NOC of the second device to the second device; or the first device configures the RCAC of the first device, the ICAC of the first device, and the NOC of the second device to the second device.
  • step S9050 the configuration between the first device and the second device ends, and the configuration channel exits.
  • the first device 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.
  • step S9060 the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.
  • 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.
  • the second device returns a fifth response to the first device.
  • the fifth response may be used to indicate the key negotiation method supported by the second device.
  • the key negotiation method supported by the second device is negotiation based on the sigma protocol.
  • step S9080 the first device uses the identification code of the first device to encrypt the first destination identifier.
  • the first device can generate a random number r1, a session ID of the first device, and a temporary key pair of the first device (including the temporary public key and the temporary private key of the first device), and generate the first destination identifier.
  • the first destination identifier is generated by the first device using the first device's identification code to encrypt the first information.
  • the first information includes one or more of the following information: the random number r1 generated by the first device, the second The device identification of the device and the public key corresponding to the RCAC of the first device.
  • the first device generates first data.
  • the first data may include the temporary public key of the first device and the first destination identifier.
  • the first data may also include one or more of the following information: The first device generates The random number r1 and the session ID of the first device.
  • step S9090 the first device sends a first message to the second device.
  • the first message may carry the first data and an index corresponding to the identification code, and the index is not encrypted.
  • the index corresponding to the identification code is a non-zero value or a non-full F value.
  • step S9100 the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.
  • the second device can find the identification code through the index value carried in the first message, and use the identification code to encrypt the first information to obtain the second destination identifier.
  • the second device can verify the identity of the first device according to the first destination identifier and the second destination identifier. For example, if the second device determines that the first destination identifier and the second destination identifier are the same, it means that the verification is passed.
  • the second device may generate a temporary key pair of the second device (including the temporary public key and the temporary private key of the second device).
  • the second device may use the temporary public key of the first device and the temporary private key of the second device to generate the second key. It should be understood that the temporary public key of the first device may be carried in the first message.
  • the second device can also use the private key corresponding to the NOC of the second device to sign one or more of the following data to generate the second signature sign2: the NOC of the second device, the CA of the first device Certificate (e.g., ICAC of the first device), temporary public key of the second device.
  • the NOC of the second device the NOC of the second device
  • the CA of the first device Certificate e.g., ICAC of the first device
  • the second device may generate a shared key based on one or more of the following information: the second key generated based on the temporary public key of the first device and the temporary private key of the second device, the second key generated by the second device. Random number r2, temporary public key of the second device, etc.
  • the second device may encrypt the fourth data using the shared key generated by the second device to obtain the first encryptData.
  • the second device may generate a session identification for the second device.
  • the second device sends a second message to the first device, and the second message carries second data.
  • the second data includes one or more of the following information: the random number r2 generated by the second device, the session ID of the second device, the temporary public key of the second device, and the first encryptData.
  • step S9120 the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.
  • the first device may generate the first key using the temporary public key of the second device and the temporary private key of the first device.
  • the first device can obtain the shared key based on the first key, use the shared key to decrypt the first encryptData in the second message, and parse out the corresponding data.
  • the first device may verify the identity of the second device before generating the shared key.
  • the RCAC of the first device is used to verify the ICAC sent by the second device
  • the ICAC of the first device is used to verify the NOC of the second device.
  • the first device can use the public key corresponding to the NOC of the second device to verify the second signature sign2 generated by the second device.
  • the first device can use the private key corresponding to the NOC of the first device to sign one or more of the following data to obtain the first signature sign1 of the first device: the NOC of the first device, the first The device's CA certificate (eg, the first device's ICAC), the first device's temporary public key.
  • the first device may generate a shared key based on one or more of the following information: the first key generated based on the temporary public key of the second device and the temporary private key of the first device, the first key generated by the first device. Random number r1, temporary public key of the first device, etc.
  • the first device may encrypt the fourth data using the shared key generated by the first device to obtain the second encryptData.
  • step S9130 the first device sends a sigma3 message to the second device, and the sigma3 message may include the second encryptData.
  • step S9140 the second device processes the sigma3 message.
  • the second device can use the generated shared key to decrypt the second encryptData and parse the corresponding data.
  • the second device can verify the identity of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device can use the RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify NOC of the first device; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the first device can use the RCAC of the first device to verify the NOC of the first device.
  • the second device may also use the public key corresponding to the NOC of the first device to verify the first signature generated by the first device.
  • step S9150 the second device returns a sigma verification completion message to the first device.
  • step S9160 the first device and the second device establish an interoperation channel based on the shared key.
  • step S9170 the first device controls the second device through the interoperation channel.
  • the first data includes the first destination identifier.
  • Example 3 will be described in detail below with reference to Figure 10.
  • Figure 10 is a schematic flowchart of a method for establishing an interoperability channel provided by yet another embodiment of the present application. As shown in Figure 10, the method may include steps S1001 to S1017.
  • 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.
  • the first device configures the interoperability certificate chain to the second device. For example, the first device configures the RCAC of the first device and the NOC of the second device to the second device; or the first device configures the RCAC of the first device, the ICAC of the first device, and the NOC of the second device to the second device.
  • step S1003 the configuration between the first device and the second device ends, and the configuration channel exits.
  • step S1004 the first device sends a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device.
  • 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.
  • step S1005 the second device returns a fifth response to the first device.
  • the fifth response may be used to indicate the key negotiation method supported by the second device.
  • the key negotiation method supported by the second device is negotiation based on the sigma protocol.
  • step S1006 the first device sends a fourth message to the second device, and the fourth message is used to instruct the second device to return the first identification code.
  • the fourth message may carry information indicating that the first device does not have an identity code. For example, data with an identity code index of 0 may be carried to indicate that the first device does not have an identity code.
  • the second device returns a first identification code to the first device.
  • the first identification code is a temporary identification code.
  • the second device may send a fourth response to the first device, return an error code, and inform the first device that it needs to enter the temporary identity code returned by the second device for the first device.
  • the second device may display the temporary identification code that needs to be entered on the display screen of the second device.
  • step S1008 the first device uses the identification code of the first device to encrypt the first destination identifier.
  • the first device can generate a random number r1, a session ID of the first device, and a temporary key pair of the first device (including the temporary public key and the temporary private key of the first device), and generate the first destination identifier.
  • the first destination identifier is generated by the first device using the first device's identification code to encrypt the first information.
  • the first information includes one or more of the following information: the random number r1 generated by the first device, the second The device identification of the device and the public key corresponding to the RCAC of the first device.
  • the first device generates first data.
  • the first data may include the temporary public key of the first device and the first destination identifier.
  • the first data may also include one or more of the following information: The first device generates The random number r1 and the session ID of the first device.
  • step S1009 the first device sends a first message to the second device.
  • the first message may carry the first data and an index corresponding to the identification code, and the index is not encrypted.
  • the index corresponding to the identification code is a non-zero value or a non-full F value.
  • step S1010 the second device generates a shared key based on the temporary public key of the first device and the temporary private key of the second device.
  • the second device can find the identification code through the index value carried in the first message, and use the identification code to encrypt the first information to obtain the second destination identifier.
  • the second device can verify the identity of the first device according to the first destination identifier and the second destination identifier. For example, if the second device determines that the first destination identifier and the second destination identifier are the same, it means that the verification is passed.
  • the second device may generate a temporary key pair of the second device (including the temporary public key and the temporary private key of the second device).
  • the second device may use the temporary public key of the first device and the temporary private key of the second device to generate the second key. It should be understood that the temporary public key of the first device may be carried in the first message.
  • the second device can also use the private key corresponding to the NOC of the second device to sign one or more of the following data to generate the second signature sign2: the NOC of the second device, the CA of the first device Certificate (e.g., ICAC of the first device), temporary public key of the second device.
  • the NOC of the second device the NOC of the second device
  • the CA of the first device Certificate e.g., ICAC of the first device
  • the second device may generate a shared key based on one or more of the following information: the second key generated based on the temporary public key of the first device and the temporary private key of the second device, the second key generated by the second device. Random number r2, temporary public key of the second device, etc.
  • the second device may encrypt the fourth data using the shared key generated by the second device to obtain the first encryptData.
  • the second device may generate a session identification for the second device.
  • the second device may generate a session identification for the second device.
  • step S1011 the second device sends a second message to the first device, and the second message carries second data.
  • the second data includes one or more of the following information: the random number r2 generated by the second device, the session ID of the second device, the temporary public key of the second device, and the first encryptData.
  • step S1012 the first device generates a shared key based on the temporary public key of the second device and the temporary private key of the first device.
  • the first device may generate the first key using the temporary public key of the second device and the temporary private key of the first device.
  • the first device can obtain the shared key based on the first key, use the shared key to decrypt the first encryptData in the second message, and parse out the corresponding data.
  • the first device may verify the identity of the second device before generating the shared key.
  • the RCAC of the first device is used to verify the ICAC sent by the second device
  • the ICAC of the first device is used to verify the NOC of the second device.
  • the first device can use the public key corresponding to the NOC of the second device to verify the second signature sign2 generated by the second device.
  • the first device can use the private key corresponding to the NOC of the first device to sign one or more of the following data to obtain the first signature sign1 of the first device: the NOC of the first device, the first The device's CA certificate (eg, the first device's ICAC), the first device's temporary public key.
  • the first device may generate a shared key based on one or more of the following information: the first key generated based on the temporary public key of the second device and the temporary private key of the first device, the first key generated by the first device. Random number r1, temporary public key of the first device, etc.
  • the first device may encrypt the fourth data using the shared key generated by the first device to obtain the second encryptData.
  • step S1013 the first device sends a sigma3 message to the second device, and the sigma3 message may include the second encryptData.
  • step S1014 the second device processes the sigma3 message.
  • the second device can use the generated shared key to decrypt the second encryptData and parse the corresponding data.
  • the second device can verify the identity of the first device. For example, if the configured interoperability certificate chain is a three-level interoperability certificate chain, the second device can use the RCAC of the first device to verify the ICAC sent by the first device, and use the stored ICAC of the first device to verify NOC of the first device; if the configured interoperability certificate chain is a secondary interoperability certificate chain, the first device can use the RCAC of the first device to verify the NOC of the first device.
  • the second device may also use the public key corresponding to the NOC of the first device to verify the first signature generated by the first device.
  • step S1015 the second device returns a sigma verification completion message to the first device.
  • step S1016 the first device and the second device establish an interoperation channel based on the shared key.
  • step S1017 the first device controls the second device through the interoperation channel.
  • Figure 11 is a schematic structural diagram of a device for establishing an interoperability channel provided by an embodiment of the present application.
  • the device may be configured in the first device mentioned above.
  • the device 1100 shown in FIG. 11 may include a first negotiation module 1110, an establishment module 1120 and a control module 1130.
  • the first negotiation module 1110 may be used to negotiate the shared key with the second device according to the sigma protocol.
  • the establishing module 1120 may be used to establish an interoperability channel based on the shared key with the second device.
  • the control module 1130 may be used to send control instructions to a second device through an interoperation channel to control the second device, where the first device is a terminal device and the second device is a vehicle device.
  • the first negotiation module further includes: a first sending module, configured to send a first message to the second device, the first message includes first data, the first data includes the temporary public key of the first device, and the first device The temporary public key is used for the second device to generate the shared key; the first receiving module is used for receiving a second message from the second device, the second message includes second data, and the second data includes the temporary public key of the second device; A generating module, configured to generate a shared key based on the temporary public key of the second device and the temporary private key of the first device.
  • the first data also includes one or more of the following information: the session ID of the first device, a random number generated by the first device; and/or the second data also includes one or more of the following information or Multiple types: session ID of the second device, random number generated by the second device.
  • the apparatus 1100 further includes: an encryption module, configured to encrypt the first data according to the identification code of the first device.
  • an encryption module configured to encrypt the first data according to the identification code of the first device.
  • the first data also includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.
  • the first destination identifier is obtained by the first device encrypting the first information according to the identity code of the first device, and the first information includes one or more of the following information: a random number generated by the first device , the device identification of the second device, and the public key corresponding to the CA certificate of the device certification center of the first device.
  • the apparatus 1100 further includes: a second negotiation module, configured to negotiate a first identity code with the second device, and the first identity code is used for the device corresponding to the first identity code to access the second device.
  • a second negotiation module configured to negotiate a first identity code with the second device, and the first identity code is used for the device corresponding to the first identity code to access the second device.
  • the second negotiation module further includes: a second sending module, configured to send a third message to the second device, where the third message is used to configure the first identity code.
  • a second sending module configured to send a third message to the second device, where the third message is used to configure the first identity code.
  • the second negotiation module further includes: a third sending module, configured to send a fourth message to the second device, where the fourth message is used to instruct the second device to return the first identity code.
  • a third sending module configured to send a fourth message to the second device, where the fourth message is used to instruct the second device to return the first identity code.
  • the fourth message carries information indicating that the first device does not have an identification code.
  • the apparatus 1100 further includes: a second receiving module configured to receive the first identification code returned by the second device.
  • the first identification code returned by the second device is displayed on the display screen of the second device.
  • the first identification code returned by the second device is a temporary identification code.
  • the apparatus 1100 further includes: a third negotiation module, configured to negotiate a shared key negotiation method with the second device.
  • a third negotiation module configured to negotiate a shared key negotiation method with the second device.
  • the third negotiation module further includes: a fourth sending module, configured to send a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device; and a third receiving module, configured to A fifth response is received from the second device, and the fifth response is used to indicate negotiating a shared key based on the sigma protocol.
  • a fourth sending module configured to send a fifth message to the second device, where the fifth message is used to indicate the key negotiation method supported by the first device
  • a third receiving module configured to A fifth response is received from the second device, and the fifth response is used to indicate negotiating a shared key based on the sigma protocol.
  • the key negotiation methods supported by the first device and/or the second device include one or more of the following methods: key pair-based negotiation, node interoperability certificate-based negotiation, and sigma protocol-based negotiation.
  • the shared key is generated by the first device based on one or more of the following information: the first key, a random number generated by the first device, and a temporary public key of the first device, where the first The key is generated by the first device based on the temporary public key of the second device and the temporary private key of the first device.
  • Figure 12 is a schematic structural diagram of an apparatus for establishing an interoperability channel provided by another embodiment of the present application.
  • the device may be configured in the aforementioned second device.
  • the device 1200 shown in FIG. 12 may include a first negotiation module 1210, an establishment module 1220, and a first receiving module 1230.
  • the first negotiation module 1210 may be used to negotiate the shared key with the first device according to the sigma protocol.
  • the establishing module 1220 may be used to establish an interoperability channel based on the shared key with the first device.
  • the first receiving module 1230 may be configured to receive the control instruction of the first device through the interoperation channel, where the first device is a terminal device and the second device is a vehicle device.
  • the first negotiation module further includes: a second receiving module, configured to receive the first message sent by the first device, the first message containing the first data, and the first data containing the temporary public key of the first device; and the generating module. , used to generate a shared key based on the temporary public key of the first device and the temporary private key of the second device; the first sending module is used to send a second message to the first device, where the second message contains the second data, The second data contains the temporary public key of the second device, and the temporary public key of the second device is used by the first device to generate the shared key.
  • a second receiving module configured to receive the first message sent by the first device, the first message containing the first data, and the first data containing the temporary public key of the first device
  • the generating module used to generate a shared key based on the temporary public key of the first device and the temporary private key of the second device
  • the first sending module is used to send a second message to the first device, where the second message contains the second data,
  • the second data contains
  • the first data also includes one or more of the following information: the session ID of the first device, a random number generated by the first device; and/or the second data also includes one or more of the following information or Multiple types: session ID of the second device, random number generated by the second device.
  • the apparatus 1200 further includes: a decryption module, configured to decrypt the first data according to the identification code of the first device.
  • a decryption module configured to decrypt the first data according to the identification code of the first device.
  • the first data also includes a first destination identifier, and the first destination identifier is used by the second device to verify the identity of the first device.
  • the first destination identifier is obtained by the first device encrypting the first information according to the identity code of the first device, and the first information includes one or more of the following information: a random number generated by the first device , the device identification of the second device, and the public key corresponding to the CA certificate of the device certification center of the first device.
  • the device 1200 also includes: an encryption module, configured to encrypt the first information according to the identity code of the first device to obtain a second destination identifier; a verification module, configured to encrypt the first information according to the first destination identifier and the second destination identifier. Identification, verifying the identity of the first device.
  • an encryption module configured to encrypt the first information according to the identity code of the first device to obtain a second destination identifier
  • a verification module configured to encrypt the first information according to the first destination identifier and the second destination identifier.
  • Identification verifying the identity of the first device.
  • the apparatus 1200 further includes: a second negotiation module, configured to negotiate a first identity code with the first device.
  • the first identity code is used for the device corresponding to the first identity code to access the identity of the second device. code.
  • the second negotiation module further includes: a third receiving module, configured to receive a third message sent by the first device, where the third message is used to configure the first identity code.
  • the second negotiation module further includes: a fourth receiving module, configured to receive a fourth message sent by the first device, where the fourth message is used to instruct the second device to return the first identity code.
  • a fourth receiving module configured to receive a fourth message sent by the first device, where the fourth message is used to instruct the second device to return the first identity code.
  • the fourth message carries information indicating that the first device does not have an identification code
  • the apparatus 1200 further includes: a return module configured to return the first identification code for the first device.
  • the first identification code returned by the second device is displayed on the display screen of the second device.
  • the first identification code returned by the second device is a temporary identification code.
  • the apparatus 1200 further includes: a third negotiation module, configured to negotiate a shared key negotiation method with the first device.
  • a third negotiation module configured to negotiate a shared key negotiation method with the first device.
  • the third negotiation module further includes: a fifth receiving module, configured to receive a fifth message sent by the first device, where the fifth message is used to indicate the key negotiation method supported by the first device; a second sending module, configured to A fifth response is sent to the first device, where the fifth response is used to indicate that the shared key is negotiated based on the sigma protocol.
  • a fifth receiving module configured to receive a fifth message sent by the first device, where the fifth message is used to indicate the key negotiation method supported by the first device
  • a second sending module configured to A fifth response is sent to the first device, where the fifth response is used to indicate that the shared key is negotiated based on the sigma protocol.
  • the key negotiation methods supported by the first device and/or the second device include one or more of the following methods: key pair-based negotiation, node interoperability certificate-based negotiation, and sigma protocol-based negotiation.
  • the shared key is generated by the second device based on one or more of the following information: the second key, a random number generated by the second device, and a temporary public key of the second device, wherein the second device The key is generated by the second device based on the temporary public key of the first device and the temporary private key of the second device.
  • the device 1100 for establishing an interoperation channel and/or the device 1200 for establishing an interoperation channel may also include a transceiver 1330 and a memory 1320, as specifically shown in FIG. 13 .
  • Figure 13 is a schematic structural diagram of a communication device according to an embodiment of the present application.
  • the dashed line in Figure 13 indicates that the unit or module is optional.
  • the device 1300 can be used to implement the method described in the above method embodiment.
  • Device 1300 may be a chip, terminal device or network device.
  • Apparatus 1300 may include one or more processors 1310.
  • the processor 1310 can support the device 1300 to implement the method described in the foregoing method embodiments.
  • the processor 1310 may be a general-purpose processor or a special-purpose processor.
  • the processor may be a central processing unit (CPU).
  • 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.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA off-the-shelf programmable gate array
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • Apparatus 1300 may also include one or more memories 1320.
  • the memory 1320 stores a program, which can be executed by the processor 1310, so that the processor 1310 executes the method described in the foregoing method embodiment.
  • the memory 1320 may be independent of the processor 1310 or integrated in the processor 1310.
  • Apparatus 1300 may also include a transceiver 1330.
  • Processor 1310 may communicate with other devices or chips through transceiver 1330.
  • the processor 1310 can transmit and receive data with other devices or chips through the transceiver 1330.
  • An embodiment of the present application also provides a computer-readable storage medium for storing a program.
  • the computer-readable storage medium can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • An embodiment of the present application also provides a computer program product.
  • the computer program product includes a program.
  • the computer program product can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • An embodiment of the present application also provides a computer program.
  • the computer program can be applied to the terminal or network device provided by the embodiments of the present application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • the "instruction" mentioned may be a direct instruction, an indirect instruction, or an association relationship.
  • 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.
  • B corresponding to A means that B is associated with A, and B can be determined based on A.
  • 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.
  • 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.
  • 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).
  • devices for example, including terminal devices and network devices.
  • predefined can refer to what is defined in the protocol.
  • 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 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.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of this embodiment.
  • 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.
  • the computer program product includes one or more computer instructions.
  • 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.
  • magnetic media e.g., floppy disks, hard disks, magnetic tapes
  • optical media e.g., digital video discs (DVD)
  • semiconductor media e.g., solid state disks (SSD)

Landscapes

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

Abstract

提供了一种建立互操作通道的方法、装置、芯片和存储介质。该方法包括：第一设备根据sigma协议与第二设备协商共享密钥；第一设备与第二设备建立基于共享密钥的互操作通道；第一设备通过互操作通道向第二设备发送控制指令，以对第二设备进行控制；其中，第一设备为终端设备，第二设备为车设备。本申请实施例中，第一设备和第二设备可以基于sigma协议协商互操作通道对应的共享密钥，以保证互操作通道的通信的安全性和可靠性，实现第一设备对第二设备的安全控制。基于sigma协议协商共享密钥的方式，有助于降低共享密钥被泄露的风险。

Description

建立互操作通道的方法、装置、芯片和存储介质 技术领域
本申请涉及通信技术领域，并且更为具体地，涉及一种建立互操作通道的方法、装置、芯片和存储介质。
背景技术
随着通信技术的快速发展，不同设备可以通过建立互操作通道实现设备之间的互操作，例如，对设备进行控制。
相关技术中，为了保证互操作通道的通信的安全性和可靠性，可以基于共享密钥进行互操作通道的加密通信。但是，设备之间如何协商互操作通道对应的共享密钥，是亟待解决的问题。
发明内容
本申请提供一种建立互操作通道的方法、装置、芯片和存储介质。下面对本申请涉及的各个方面进行介绍。
第一方面，提供了一种建立互操作通道的方法，包括：第一设备根据sigma协议与第二设备协商共享密钥；所述第一设备与所述第二设备建立基于所述共享密钥的互操作通道；所述第一设备通过所述互操作通道向所述第二设备发送控制指令，以对所述第二设备进行控制，其中，所述第一设备为终端设备，所述第二设备为车设备。
第二方面，提供了一种建立互操作通道的方法，包括：第二设备根据sigma协议与第一设备协商共享密钥；所述第二设备与所述第一设备建立基于所述共享密钥的互操作通道；所述第二设备通过所述互操作通道接收所述第一设备的控制指令，其中，所述第一设备为终端设备，所述第二设备为车设备。
第三方面，提供了一种建立互操作通道的装置，所述装置配置于第一设备，所述装置包括：第一协商模块，用于根据sigma协议与第二设备协商共享密钥；建立模块，用于与所述第二设备建立基于所述共享密钥的互操作通道；控制模块，用于通过所述互操作通道向所述第二设备发送控制指令，以对所述第二设备进行控制，其中，所述第一设备为终端设备，所述第二设备为车设备。
第四方面，提供了一种建立互操作通道的装置，所述装置配置于第二设备，所述装置包括：第一协商模块，用于根据sigma协议与第一设备协商共享密钥；建立模块，用于与所述第一设备建立基于所述共享密钥的互操作通道；第一接收模块，用于通过所述互操作通道接收所述第一设备的控制指令，其中，所述第一设备为终端设备，所述第二设备为车设备。
第五方面，提供一种通信装置，所述通信装置配置于第一设备，所述装置包括处理器、存储器以及通信接口，所述存储器用于存储一个或多个计算机程序，所述处理器用于调用所述存储器中的计算机程序使得所述第一设备执行第一方面的方法中的部分或全部步骤。
第六方面，提供一种通信装置，所述通信装置配置于第二设备，所述装置包括处理器、存储器以及通信接口，所述存储器用于存储一个或多个计算机程序，所述处理器用于调用所述存储器中的计算机程序使得所述第二设备执行第二方面的方法中的部分或全部步骤。
第七方面，本申请实施例提供了一种通信***，该***包括上述的通信装置。在另一种可能的设计中，该***还可以包括本申请实施例提供的方案中与该通信装置进行交互的其他设备。
第八方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序使得通信装置执行上述各个方面的方法中的部分或全部步骤。
第九方面，本申请实施例提供了一种计算机程序产品，其中，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序可操作来使通信装置执行上述各个方面的方法中的部分或全部步骤。在一些实现方式中，该计算机程序产品可以为一个软件安装包。
第十方面，本申请实施例提供了一种芯片，该芯片包括存储器和处理器，处理器可以从存储器中调用并运行计算机程序，以实现上述各个方面的方法中所描述的部分或全部步骤。
本申请实施例中，第一设备和第二设备可以基于sigma协议协商互操作通道对应的共享密钥，以保证互操作通道的通信的安全性和可靠性，实现第一设备对第二设备的安全控制。基于sigma协议协商共享密钥的方式，有助于降低共享密钥被泄露的风险。
附图说明
图1为可应用于本申请实施例的无线通信***的架构示例图。
图2为本申请实施例提供的基于sigma协议进行密钥交换的流程示意图。
图3为本申请一实施例提供的建立互操作通道的方法的流程示意图。
图4为图3中步骤S310的一种可能的实现方式的流程示意图。
图5为本申请一实施例提供的协商第一身份识别码的流程示意图。
图6为本申请另一实施例提供的协商第一身份识别码的流程示意图。
图7为本申请实施例提供的协商共享密钥的协商方式的流程示意图。
图8为本申请另一实施例提供的建立互操作通道的方法的流程示意图。
图9为本申请又一实施例提供的建立互操作通道的方法的流程示意图。
图10为本申请又一实施例提供的建立互操作通道的方法的流程示意图。
图11为本申请一实施例提供的建立互操作通道的装置的结构示意图。
图12为本申请另一实施例提供的建立互操作通道的装置的结构示意图。
图13为本申请实施例提供的通信装置的结构示意图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
图1为可应用于本申请实施例的无线通信***100的架构示例图。如图1所示，该无线通信***100可以包括第一设备110和第二设备120。第一设备110可以与第二设备120利用互操作通道进行通信，以实现第一设备110与第二设备120之间的互操作。例如，实现第一设备对第二设备的控制。
在一些实施例中，第一设备110和第二设备120可以通过有线(例如，USB接口)或者无线网络(例如，蓝牙或移动网络)等方式建立连接以进行通信，实现第一设备110与第二设备120之间的互操作。
图1示例性地示出了一个第一设备110和一个第二设备120，但本申请实施例对此并不限定。可选地，该无线通信***100可以包括多个第一设备和/或多个第二设备，例如，第一设备可以控制多个第二设备，或者，一个第二设备可以接收多个第一设备的控制等。
可选地，该无线通信***100还可以包括其他设备，例如第三设备，本申请实施例对此不作限定。示例性地，第一设备110可以通过第二设备120实现与第三设备的通信，例如，第一设备110可以通过第二设备120来控制或访问第三设备。可选地，在该场景下，第二设备120可以理解为一种中继设备，或者桥接设备。
应理解，本申请实施例的技术方案可以应用于各种通信***，例如：第五代(5th generation，5G)***或新无线(new radio，NR)、长期演进(long term evolution，LTE)***、LTE频分双工(frequency division duplex，FDD)***、LTE时分双工(time division duplex，TDD)、蓝牙***、无线保真(wireless fidelity，WiFi)***等。本申请提供的技术方案还可以应用于未来的通信***，如第六代移动通信***，又如卫星通信***，等等。
在一些实施例中，本申请实施例中的第一设备和第二设备可以分别称为第一终端设备和第二终端设备。其中，终端设备也可以称为用户设备(user equipment，UE)、接入终端、用户单元、用户站、移动站、移动台(mobile station，MS)、移动终端(mobile terminal，MT)、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。
本申请实施例中的第一设备和第二设备可以是指向用户提供语音和/或数据连通性的设备，可以用于连接人、物和机，例如具有无线连接功能的手持式设备、车载设备等。示例性地，本申请实施例中的第一设备和/或第二设备可以是手机(mobile phone)、平板电脑(Pad)、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，MID)、可穿戴设备，物联网(internet of things，IoT)设备、虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。
本申请实施例对IoT设备的类型不作限定。在一些实施例中，IoT设备可以包括车辆、船舶等智能出行工具。在一些实施例中，IoT设备可以包括智能电视、智能空调、智能冰箱、扫地机器人等智能家居设备。在一些实施例中，IoT设备可以包括监控摄像头、温度传感器、声音传感器等智能监控设备，等等。
进一步地，在IoT设备为车辆的情况下，车辆例如可以是家用汽车、出租车、公交车、摩托车等；在IoT设备为智能空调的情况下，智能空调例如可以是立式空调、挂式空调等，本申请对此并不限定。
在一些实施例中，第一设备110与第二设备120可以是不同类型的设备，以实现不同类型的设备之 间的互操作。例如，第一设备110可以是手机、平板电脑等手持终端设备，第二设备120可以是IoT设备(比如，车辆、智能空调等)，基于此，可以实现手持终端设备对IoT设备(车辆、智能空调等)的控制。
在一些实施例中，第一设备110与第二设备120可以是来自不同制造商的设备，以实现不同制造商的设备之间的互操作。例如，第一设备110可以是来自第一制造商的设备，第二设备120可以是来自第二制造商(与第一制造商不同)的设备，基于此，可以实现第一制造商生产的设备对第二制造商生产的设备的控制。
本申请实施例对第一设备和第二设备所处的场景不作限定。示例性地，第一设备和第二设备可以部署在陆地上，包括室内或室外、手持或车载。
应理解，本申请中的通信设备的全部或部分功能也可以通过在硬件上运行的软件功能来实现，或者通过平台(例如云平台)上实例化的虚拟化功能来实现。
应理解，本申请实施例提及的第一设备与第二设备之间的互操作，或者第一设备对第二设备进行控制，可以是指不同类型的设备之间进行互操作或控制，也可以是指不同制造商的设备之间进行互操作或控制等，本申请实施例对此并不限定，例如，还可以是指相同制造商的设备之间进行互操作或控制等，只要第一设备和第二设备之间能够实现互操作、或实现控制与被控制即可。
应理解，本申请实施例提供的技术方案可以应用于设备之间进行互操作的任意场景，例如终端设备和IoT设备之间进行互操作。下面结合两个具体示例对本申请实施例的应用场景进行介绍，该示例并不用于限定本申请。
作为一个示例，第二设备可以是指车辆、船舶等智能出行工具，第一设备可以是指可以控制该智能出行工具的终端设备，例如，手机、平板电脑、笔记本电脑等。以第一设备为手机、第二设备为车辆为例，手机和车辆可以通过建立互操作通道来实现手机对车辆的控制，例如，手机控制打开车门、打开车窗等。
作为另一个示例，第二设备可以是指智能空调、智能电视等智能家居设备，第一设备同样可以是指控制该智能家居设备的终端设备，例如，手机、平板电脑等。第一设备与智能家居设备建立互操作通道之后，第一设备可以对智能家居设备进行控制，例如，控制打开空调、打开电视、控制调节空调温度或调节空调模式等。
近年来，随着通信技术的快速发展，不同设备之间的互操作的应用场景愈加频繁。在某些通信***(例如，NR***)中，不同设备可以通过建立互操作通道来实现设备之间的互操作，例如，实现第一设备对第二设备的控制。
然而，目前关于不同设备之间建立互操作通道的方案并不完善且不统一，作为一种可能的实现方式，为了保证互操作通道的通信的安全性和可靠性，可以基于共享密钥进行互操作通道的加密通信。但是，设备之间如何协商互操作通道对应的共享密钥，是亟待解决的问题。
为了解决上述问题，本申请实施例提供一种建立互操作通道的方法、装置、芯片、存储介质和程序产品，以基于sigma协议协商互操作通道对应的共享密钥，有助于降低共享密钥泄露的风险。
为了便于理解，先对相关概念进行介绍。
sigma协议
一方面，sigma协议可以理解为是一种高效的交互式零知识证明协议，可以使证明者在不向验证者出示秘密的情况下，向验证者证明其知道该秘密。
另一方面，sigma协议可以理解为是一种密钥交换协议，可以通过使用数字签名进行身份验证，以进一步保证密钥交换的安全性。
在一些实施例中，sigma协议的参与方可以包括发起流程的配置端(initiator)和响应流程的接收端(responder)。initiator和responder可以通过一轮或多轮sigma消息来进行密钥交换。图2为本申请实施例提供的一种基于sigma协议进行密钥交换的流程示意图。下面结合图2，对initiator和responder基于sigma协议进行密钥交换进行示例性说明。
如图2所示，在步骤S210，initiator构造sigma1消息，发送sigma1消息给responder。
sigma1消息可以用于请求responder进行密钥交换，或者进行密钥协商。在一些实施例中，sigma1消息可以是明文消息。在一些实施例中，sigma1消息可以是密文消息。
在步骤S220，responder根据initiator发来的sigma1消息，生成共享密钥，并将构造的sigma2消息发送给initiator。
在一些实施例中，responder在生成共享密钥之前，可以对initiator发来的sigma1消息进行校验，校验通过后执行步骤S220。
在步骤S230，initiator根据responder发来的sigma2消息，生成共享密钥，并将构造的sigma3消息 发送给responder。
在一些实施例中，initiator在生成共享密钥之前，可以对responder发来的sigma2消息进行校验，校验通过后执行步骤S230。
在步骤S240，responder校验sigma3消息，校验通过后返回sigma校验完成消息给initiator。
节点互操作证书(node operational certificate，NOC)
设备的NOC可以用于对设备的身份进行验证。在一些实施例中，设备的NOC中可以存放NOC对应的密钥信息，例如，设备的NOC中可以存放NOC对应的公钥信息，而其对应的私钥信息不能存放在NOC中。示例性地，第一设备的NOC(或称，第一NOC)中可以存放第一设备的NOC对应的公钥，第二设备的NOC(或称，第二NOC)中可以存放第二设备的NOC对应的公钥。但本申请实施例并不限定于此，例如，设备的NOC中还可以存放除NOC对应的密钥信息之外的其他信息，比如设备的设备标识等等。
为了进一步提升共享密钥交换过程的安全性，在一些实施例中，可以采用互操作证书链对设备的NOC进行校验，例如可以采用设备认证中心(certificate authority，CA)签发的互操作证书链对设备的NOC进行校验。为了简洁，后文将CA签发的证书简称为CA证书。
本申请实施例提及的互操作证书链可以包括二级或多级证书链，本申请实施例对此并不限定。
在一些实施例中，可以采用三级互操作证书链对设备的NOC进行校验。三级互操作证书链可以包括根CA证书(Root CA Certificate，RCAC)、中间CA证书(Intermediate CA Certificate，ICAC)以及NOC。可选地，ICAC可以是由RCAC签名得到的，NOC可以是由ICAC签名得到的。对应地，采用三级互操作证书链对设备的NOC进行校验时，ICAC可以用于对NOC进行校验，RCAC可以用于对ICAC进行校验。
在一些实施例中，可以采用二级互操作证书链对设备的NOC进行校验。二级互操作证书链可以包括RCAC和NOC。可选地，NOC可以是由RCAC签名得到的。对应地，采用二级互操作证书链对设备的NOC进行校验时，RCAC可以用于对NOC进行校验。
在一些实施例中，第一设备可以向第二设备配置互操作证书链，例如配置三级互操作证书链，或配置二级互操作证书链。示例性地，第一设备向第二设备配置的互操作证书链为三级互操作证书链时，该证书链可以包括第一设备的RCAC、第一设备的ICAC、以及第二设备的NOC，第二设备的NOC中可以包含第二设备的NOC对应的公钥，第二设备的NOC对应的私钥只能存储于第二设备。第一设备向第二设备配置的互操作证书链为二级互操作证书链时，该证书链可以包括第一设备的RCAC以及第二设备的NOC，第二设备的NOC中可以包含第二设备的NOC对应的公钥，第二设备的NOC对应的私钥只能存储于第二设备。但本申请实施例并不限定于此，第二设备的互操作证书链也可以是其他设备配置的，用于向第二设备配置互操作证书链的设备可以称为调试专员(commissioner)。
下面结合附图，对本申请实施例提供的方法实施例进行详细介绍。
图3为本申请实施例提供的建立互操作通道的方法的流程示意图。图3所示的方法是站在第一设备和第二设备交互的角度描述的。第一设备和第二设备例如可以是图1中的第一设备110和第二设备120。
本申请实施例对第一设备和第二设备的具体类型不作限定，只要第一设备和第二设备之间能够实现互操作，或者实现第一设备对第二设备的控制即可。示例性地，第二设备可以是指IoT设备，例如车辆、船舶等智能出行工具，或者智能空调、智能电视等智能家居设备，等等；第一设备可以是指能够控制该IoT设备的终端设备。比如，在一些实施例中，第一设备可以为终端设备，第二设备可以为车设备。
图3所示的方法可以包括步骤S310至步骤S330，下面对这些步骤进行详细描述。
在步骤S310，第一设备与第二设备基于sigma协议协商共享密钥。
在本申请实施例中，第一设备可以称为initiator，第二设备可以称为responder。第一设备可以和第二设备可以基于一轮或多轮sigma消息来协商共享密钥。
在一些实施例中，第一设备和第二设备可以基于sigma协议和设备的NOC协商共享密钥。示例性地，可以在sigma消息中携带设备的NOC信息来协商第一设备和第二设备之间的共享密钥。
在一些实施例中，第一设备和第二设备在协商共享密钥前，可以根据第一设备和第二设备分别支持的密钥协商方式(或类型)，协商确定共享密钥的协商方式。在本申请实施例中，第一设备和第二设备协商确定的共享密钥的协商方式为：基于sigma协议协商共享密钥。关于第一设备和第二设备如何协商确定共享密钥的协商方式，后文将会详细介绍，此处暂不赘述。
在本申请实施例中，第一设备和第二设备协商出的共享密钥只有第一设备和第二设备彼此知道，第一设备和第二设备可以基于协商出的共享密钥进行加密通信。第一设备和第二设备在协商共享密钥的过程中，可以根据一种或多种信息生成该共享密钥。关于第一设备和第二设备如何协商或如何生成共享 密钥的具体描述，可以参见后文，此处暂不赘述。
在一些实施例中，第一设备和第二设备可以利用一些密钥算法来生成共享密钥，例如，两者可以使用相同的密钥算法来生成共享密钥，以保证生成的共享密钥的对应性和一致性。本申请实施例对密钥算法的具体类型不作限定，示例性地，密钥算法可以是对称加密算法，比如数据加密标准(data encryption standard，DES)算法、高级加密标准(advanced encryption standard，AES)算法等。
在步骤S320，第一设备与第二设备建立基于共享密钥的互操作通道。第一设备和第二设备基于互操作通道进行通信(例如，发送或接收控制指令)时，该共享密钥用于对第一设备和第二设备之间的通信进行加密和安全性保护。换句话说，第一设备和第二设备基于互操作通道进行通信时，该共享密钥可以用于对互操作通道中传输的信息进行加密，以提升通信的安全性。
如前文所述，第一设备和第二设备可以利用互操作通道实现第一设备对第二设备的控制(设备之间的互操作)。在本申请实施例中，互操作通道可以理解为一种控制信道(或，安全控制信道)，第一设备和第二设备之间建立互操作通道之后，第一设备可以通过该互操作通道对第二设备进行控制。第一设备与第二设备建立基于共享密钥的互操作通道后，第一设备与第二设备利用互操作通道进行通信时，可以基于两者协商出的共享密钥进行加密通信，加强了对互操作通道中的信息(比如数据、指令等)的安全性保护，提升了通信的安全等级。
在一些实施例中，第一设备与第二设备建立基于共享密钥的互操作通道时，每次建立互操作通道对应的共享密钥可以是不同的、随机的，即第一设备和第二设备每次建立互操作通道之前，可以先约定一个新的共享密钥，然后再用该共享密钥进行加密通信等处理，进一步提高互操作通道的通信的安全性。
在步骤S330，第一设备通过互操作通道对第二设备进行控制。示例性地，第一设备可以通过互操作通道向第二设备发送控制命令(控制指令)实现对第二设备的控制。
在一些实施例中，第一设备对第二设备进行控制可以是指第一设备控制第二设备执行一些操作，例如，打开操作、关闭操作、调节操作等。作为一个示例，第二设备为车辆时，第一设备对第二设备进行控制可以是指控制打开车门、关闭车窗等。作为另一个示例，第二设备为智能空调时，第一设备对第二设备进行控制可以是指控制打开空调、调节空调模式、调节温度等。
在一些实施例中，第一设备对第二设备进行控制可以是指第一设备访问第二设备的资源。作为一个示例，第二设备为温度传感器时，第一设备对第二设备进行控制可以是指查看第二设备的温度，以便第二设备的温度超过某一阈值时，对第二设备执行一些操作。
本申请实施例中，第一设备和第二设备可以基于sigma协议协商互操作通道对应的共享密钥，以保证互操作通道的通信的安全性和可靠性，实现第一设备对第二设备的安全控制。基于sigma协议协商共享密钥的方式，有助于降低共享密钥被泄露的风险。
本申请实施例对步骤S310的实现方式不作限定。下面结合图4，给出步骤S310的一种可能的实现方式，对第一设备和第二设备基于sigma协议协商共享密钥的过程进行详细描述。示例性地，步骤S310可以包括步骤S312至步骤S318，下面对这些步骤进行详细描述。
在步骤S312，第一设备向第二设备发送第一消息，第一消息可以用于请求第二设备协商共享密钥。在一些实施例中，第一消息也可以称为sigma1消息。
在本申请实施例中，第一消息包含第一数据，第一数据包含第一设备的临时公钥。本申请实施例对第一设备的临时公钥的来源不作限定，示例性地，第一设备的临时公钥可以是第一设备生成的，例如在发送第一消息之前生成的。应该理解，第一设备在生成第一设备的临时公钥时，也可以生成第一设备的临时私钥，该临时公钥与临时私钥组成第一设备的临时密钥对。
在一些实施例中，第一数据除包含第一设备的临时公钥之外，还可以包含其他信息。示例性地，第一数据还可以包含以下信息中的一种或多种：第一设备的会话标识、第一设备生成的随机数。
在一些实施例中，若第一数据包含第一设备的临时公钥、第一设备的会话标识、第一设备生成的随机数中的一种或多种时，第一设备可以对第一数据进行加密。具体地，第一设备可以在向第二设备发送第一消息之前，根据第一设备的身份识别码对第一数据进行加密。第一设备的身份识别码可以是第一设备提前为第二设备配置的或者也可以是第二设备生成的。关于第一设备的身份识别码后文将会详细描述，此处暂不赘述。
第一设备的会话标识可以用于标识第一设备接下来的会话。第一设备生成的随机数可以用于防止重放攻击(replay attacks)。在认证协议或数据加密传输体系中，随机数可以作为种子数据、种子向量参与到第一设备和第二设备之间的身份识别或数据有效性判别之中。应该理解，在第一设备和第二设备每次协商共享密钥的过程中，第一设备生成的随机数可以是不同的、随机的。优选地，第一设备生成的随机数可以是真随机数。
对应地，第一设备使用第一设备的身份识别码对第一数据进行加密后，第二设备接收到第一设备发 送的第一消息之后，可以根据第一设备的身份识别码对第一数据进行解密。第二设备成功解密第一数据后，能够获知第一设备的临时公钥以及第一数据中的其他信息，避免了第一设备的临时公钥明文传输导致的容易泄露的问题。
在一些实施例中，第一数据还可以包含第一目的标识，第一目的标识可以用于第二设备校验第一设备的身份。在一些实施例中，第一目的标识可以用于第二设备查找正确的NOC建立连接。第一数据包含第一目的标识可以是指，第一数据包含第一设备的临时公钥和第一目的标识；或者，第一数据除包含第一设备的临时公钥、第一目的标识之外，还可以包含第一设备的会话标识和第一设备生成的随机数中的至少一种。
在一些实施例中，第一目的标识可以是第一设备根据第一设备的身份识别码对第一信息进行加密得到的。第一信息可以包括以下信息中的一种或多种：第一设备生成的随机数、第二设备的设备标识、以及第一设备的CA证书对应的公钥。
在一些实施例中，第一设备的CA证书对应的公钥可以是指第一设备的RCAC对应的公钥。
应该理解，第一数据中包含第一目的标识时，第一设备可以根据第一设备的身份识别码对第一信息进行加密得到第一目的标识，而不会使用第一设备的身份识别码对第一数据整体进行加密。换句话说，当第一数据中不包含第一目的标识时，第一设备可以根据第一设备的身份识别码对第一数据进行加密；当第一数据中包含第一目的标识时，第一设备可以根据第一设备的身份识别码对第一信息进行加密即可，通过对第一信息进行加密得到第一目的标识，第一数据中除第一目的标识之外的其他信息可以不加密。
对应地，第一数据包含第一目的标识的情况下，第二设备接收第一设备发送的第一消息(第一消息包含第一数据，第一数据包含第一目的标识)之后，第二设备可以根据第一设备的身份识别码对第一信息进行加密，得到第二目的标识，并根据第一目的标识和第二目的标识，校验第一设备的身份。
在一些实施例中，第一设备根据第一目的标识和第二目的标识，校验第一设备的身份可以是指，第二设备得到第二目的标识后，判断第一目的标识和第二目的标识之间的一致性，如果第二目的标识与第一目的标识相同，则可以认为校验通过；如果第二目的标识与第一目的标识不同，则可以认为校验未通过。
在步骤S314，第二设备根据第一设备的临时公钥和第二设备的临时私钥，生成共享密钥。
在一些实施例中，第二设备根据第一设备的临时公钥和第二设备的临时私钥，生成共享密钥可以是指，第二设备根据第一设备的临时公钥和第二设备的临时私钥生成第二密钥，然后根据第二密钥生成共享密钥。
示例性地，第二设备可以根据第二密钥以及以下信息中的一种或多种来生成共享密钥：第二设备生成的随机数、第二设备的临时公钥。作为一种实现方式，第二设备可以以该信息中的一种或多种作为密钥参数，使用密钥算法(或称，密钥派生算法)来生成共享密钥。
本申请实施例对第二设备采用的密钥算法不作限定。示例性地，可以采用DES算法、AES算法等。
在一些实施例中，第二设备使用密钥算法生成共享密钥时，密钥算法对应的密钥参数可以包括第二密钥、salt值、第二设备生成的共享密钥的描述信息、以及第二设备生成的共享密钥的长度信息等信息中的一种或多种。示例性地，第二设备生成的共享密钥可以描述为：共享密钥＝(第二密钥，salt，第二设备生成的共享密钥的描述信息，第二设备生成的共享密钥的长度信息)。
在一些实施例中，salt值可以是随机生成的。例如，salt值可以是根据以下信息中的一种或多种随机生成的：身份保护密钥(identify protection key，IPK)、第二设备生成的随机数、第二设备的临时公钥、以及第一哈希值，其中，第一哈希值可以是指利用哈希算法对第一数据进行哈希运算得到的值。
需要说明的是，第一设备的临时公钥可以是第一设备在第一消息中携带的。第二设备生成的随机数以及第二设备的临时公钥可以是第二设备在生成共享密钥之前临时生成的。本申请实施例对第二设备的临时公钥的来源不作限定，示例性地，第二设备的临时公钥可以是第二设备生成的，例如在生成第二设备的共享密钥之前生成的，或者在接收第一消息之后生成的。应该理解，第二设备在生成第二设备的临时公钥时，也可以生成第二设备的临时私钥，该临时公钥与临时私钥组成第二设备的临时密钥对。
在一些实施例中，第二设备生成共享密钥之后，还可以利用生成的共享密钥对第三数据进行加密得到第一encryptData。本申请实施例对第三数据的具体内容不作限定，示例性地，第三数据可以包含以下信息中的一种或多种：第二设备的NOC、第一设备的CA证书，以及第二签名，第二签名可以理解为是第二设备使用第二设备的NOC对应的私钥生成的签名。
第一设备的CA证书可以是指第一设备的RCAC证书，也可以是指第一设备的ICAC证书，本申请实施例对此并不限定。示例性地，若第一设备和第二设备基于三级互操作证书链进行身份校验时，第三数据中包含的第一设备的CA证书可以是指第一设备的ICAC证书；若第一设备和第二设备基于二级互 操作证书链进行身份校验时，第三数据中包含的第一设备的CA证书可以是指第一设备的RCAC证书。
第二签名中可以包括以下信息中的一种或多种：第二设备的NOC、第一设备的CA证书、第二设备的临时公钥。示例性地，第二设备的NOC中可以包含第二设备的NOC对应的公钥。第一设备的CA证书可以是指第一设备的RCAC证书，也可以是指第一设备的ICAC证书，本申请实施例对此并不限定。
在步骤S316，第二设备向第一设备发送第二消息，在一些实施例中，第二消息也可以称为sigma2消息。第二消息包含第二数据。第二数据包含第二设备的临时公钥。
在一些实施例中，第二数据除包含第二设备的临时公钥之外，还可以包含其他信息。示例性地，第二数据还可以包含以下信息中的一种或多种：第二设备的会话标识、第二设备生成的随机数、以及第一encryptData。
第二设备的会话标识可以用于标识第二设备接下来的会话。第二设备生成的随机数的相关描述同样可以参见前文第一设备生成的随机数的相关描述，此处不再赘述。
在步骤S318，第一设备根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥。
在一些实施例中，第一设备根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥可以是指，第一设备根据第二设备的临时公钥和第一设备的临时私钥生成第一密钥，然后根据第一密钥生成共享密钥。
示例性地，第一设备可以根据第一密钥以及以下信息中的一种或多种来生成共享密钥：第一设备生成的随机数、第一设备的临时公钥。作为一种实现方式，第一设备可以以该信息中的一种或多种作为密钥参数，使用密钥算法来生成共享密钥，例如，可以与第二设备使用相同的密钥算法来生成共享密钥。
本申请实施例对第一设备采用的密钥算法不作限定。示例性地，可以采用DES算法、AES算法等。
在一些实施例中，第一设备使用密钥算法生成共享密钥时，密钥算法对应的密钥参数可以包括第一密钥、salt值、第一设备生成的共享密钥的描述信息、以及第一设备生成的共享密钥的长度信息等信息中的一种或多种。示例性地，第一设备生成的共享密钥可以描述为：共享密钥＝(第一密钥，salt，第一设备生成的共享密钥的描述信息，第一设备生成的共享密钥的长度信息)。
在一些实施例中，salt值可以是随机生成的。例如，salt值可以是根据以下信息中的一种或多种随机生成的：身份保护密钥(identify protection key，IPK)、第一设备生成的随机数、第一设备的临时公钥、以及第二哈希值，其中，第二哈希值可以是指利用哈希算法对第一数据或对第二数据进行哈希运算得到的值。
需要说明的是，第二设备的临时公钥可以是第二设备在第二消息中携带的。
在一些实施例中，第一设备在根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥之前，还可以对第二设备的身份进行验证。示例性地，第一设备可以根据第一密钥得到共享密钥，使用该共享密钥解密第二数据中的第一encryptData，解析出对应的数据。
在一些实施例中，第一设备还可以利用NOC对第二设备的身份进行验证，示例性地，若配置的互操作证书链为三级互操作证书链，则第一设备可以使用第一设备的RCAC校验第二设备发来的ICAC，使用存储的第一设备的ICAC校验第二设备的NOC；若配置的互操作证书链为二级互操作证书链，则第一设备可以使用第一设备的RCAC校验第二设备的NOC。
在一些实施例中，第一设备还可以使用第二设备的NOC对应的公钥对第二设备生成的第二签名进行校验。
在一些实施例中，第一设备生成共享密钥之后，还可以利用生成的共享密钥对第四数据进行加密得到第二encryptData。本申请实施例对第四数据的具体内容不作限定，示例性地，第四数据可以包含以下信息中的一种或多种：第一设备的NOC、第一设备的CA证书，以及第一签名，第一签名可以理解为是第一设备使用第一设备的NOC对应的私钥生成的签名。
第一设备的CA证书可以是指第一设备的RCAC证书，也可以是指第一设备的ICAC证书，本申请实施例对此并不限定。示例性地，若第一设备和第二设备基于三级互操作证书链进行身份校验时，第四数据中包含的第一设备的CA证书可以是指第一设备的ICAC证书；若第一设备和第二设备基于二级互操作证书链进行身份校验时，第四数据中包含的第一设备的CA证书可以是指第一设备的RCAC证书。
第一签名中可以包括以下信息中的一种或多种：第一设备的NOC、第一设备的CA证书、第一设备的临时公钥。示例性地，第一设备的NOC中可以包含第一设备的NOC对应的公钥。第一设备的CA证书可以是指第一设备的RCAC证书，也可以是指第一设备的ICAC证书，本申请实施例对此并不限定。
在一些实施例中，第一设备根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥之后，第一设备可以向第二设备发送sigma3消息，sigma3消息中可以包含第一设备生成的第二encryptData。
在一些实施例中，第二设备接收第一设备发送的sigma3消息后，可以对sigma3消息进行处理。示例性地，第二设备可以利用生成的共享密钥解密第二encryptData。第二设备生成共享密钥的过程可以参见前文，此处不再赘述。
在一些实施例中，第二设备接收第一设备发送的sigma3消息后，可以对第一设备的身份进行验证。示例性地，若配置的互操作证书链为三级互操作证书链，则第二设备可以使用第一设备的RCAC校验第一设备发来的ICAC，使用存储的第一设备的ICAC校验第一设备的NOC；若配置的互操作证书链为二级互操作证书链，则第二设备可以使用第一设备的RCAC校验第一设备的NOC。
在一些实施例中，第二设备还可以使用第一设备的NOC对应的公钥对第一设备生成的第一签名进行校验。
在一些实施例中，第二设备可以向第一设备返回sigma校验完成消息，该sigma校验完成消息可以用于指示第二设备已经确定共享密钥。
第一设备和第二设备基于一轮或多轮sigma消息协商互操作通道对应的共享密钥，协商过程相对复杂，使得协商的共享密钥的安全性更高。
如前文所述，在一些实施例中，第一数据为使用第一设备的身份识别码进行加密的数据，在一些实施例中，第一目的标识为使用第一设备的身份识别码对第一信息进行加密得到的。下面对第一设备根据第一设备的身份识别码进行加密进行描述，应该理解，该加密可以应用于对第一数据加密，也可以应用于对第一信息进行加密得到第一目的标识，本申请实施例对此并不限定。
一方面，第一设备的身份识别码可以用于指示第一设备的身份，以便第二设备对第一设备的身份进行识别。另一方面，第一设备的身份识别码可以用于对第一数据或第一信息进行加密，以避免第一数据或第一信息在传输的过程中泄露。
在一些实施例中，第一设备的身份识别码可以由PIN码(pincode)表示。
在一些实施例中，在第一设备根据第一设备的身份识别码对第一数据进行加密的情况下，第二设备接收到第一数据后，需要根据第一设备的身份识别码对第一数据进行解密。
在一些实施例中，在第一设备根据第一设备的身份识别码对第一信息进行加密得到第一目的标识的情况下，第二设备接收到第一消息后，需要根据第一设备的身份识别码对第一消息中的第一信息进行加密得到第二目的标识，进而根据第一目的标识和第二目的标识验证第一设备的身份。
在一些实施例中，第一设备的身份识别码可以是由第一设备和第二设备协商确定的。也就是说，在第一设备根据第一设备的身份识别码对第一数据或第一信息进行加密之前，第一设备还可以与第二设备协商第一身份识别码，该第一身份识别码可以用于第一身份识别码对应的设备访问第二设备的身份识别码，即某一设备想要访问第二设备时，需要以其对应的第一身份识别码作为凭证来实现对第二设备的访问。本申请对第一设备与第二设备协商第一身份识别码的实现方式不作具体限定。示例性地，下面分别结合图5和图6，介绍两种第一设备与第二设备协商第一身份识别码的实现方式。
图5为本申请一实施例提供的第一设备与第二设备协商第一身份识别码的流程示意图。如图5所示，在步骤S510，第一设备向第二设备发送第三消息，第三消息用于配置第一身份识别码。也就是说，在该实施例中，第一身份识别码可以是第一设备配置的，如此一来，每个第一设备可以对应一个固定的身份识别码，因此，在一些实施例中，采用这种第一设备配置第一身份识别码的方案也可以称为采用固定身份识别码的方案。
作为一种实现方式，第一设备在配置阶段，可以预先向第二设备配置第一身份识别码。配置第一身份识别码之后，第一身份识别码对应的设备便可以访问第二设备。
为了避免身份识别码的明文传输，在一些实施例中，第一设备在配置第一身份识别码时，可以以元组信息的形式向第二设备配置第一身份识别码以及第一身份识别码对应的索引，例如<pincode，pincode_index>。换句话说，第一设备可以向第二设备配置第一身份识别码以及第一身份识别码的索引，该第一身份识别码与第一身份识别码的索引存在一一映射关系。如此一来，第一设备使用第一设备的身份识别码对第一数据进行加密后，无需向第二设备传输第一设备的身份识别码以便于第二设备解密，而是向第二设备传输该身份识别码对应的索引即可，第二设备可以根据身份识别码索引知晓正确的身份识别码，从而对第一数据进行解密，进一步提高了通信的安全性。
在一些实施例中，若第一设备向第二设备配置了第一身份识别码以及第一身份识别码对应的索引时，第一设备在向第二设备发送第一消息时，第一消息中除包含第一数据之外，还可以包含第一设备的身份识别码对应的索引。其中，第一消息中的第一数据(或第一数据中的第一信息)使用第一设备的身份识别码进行加密，而第一设备的身份识别码对应的索引不加密。
在一些实施例中，第一设备可以向第二设备配置包含多组第一身份识别码的列表，该列表中可以包含多个元组信息，每个元组信息用于表示一组第一身份识别码以及第一身份识别码对应的索引，每个元 组信息中的第一身份识别码对应的设备均可以访问第二设备。
在一些实施例中，第一设备向第二设备配置第一身份识别码以及第一身份识别码对应的索引时，第一身份识别码对应的索引的取值可以为非零值、非全F值。
在一些实施例中，第一设备在配置阶段除了向第二设备配置第一身份识别码之外，还可以配置其他信息，例如，配置前文所述的互操作证书链，或者，配置其他基础配置等。
在一些实施例中，第一设备向第二设备配置了第一身份识别码的相关信息(例如，身份识别码及对应的索引)之后，第一设备可以对应存储配置的第一身份识别码的相关信息。
在一些实施例中，第二设备也可以存储第一设备配置的第一身份识别码的相关信息，例如，存储可访问第二设备的第一身份识别码以及第一身份识别码对应的索引。
本申请实施例对第二设备存储的方式不作限定。在一些实施例中，第二设备可以将第一身份识别码的相关信息存储至第二设备的资源中。在一些实施例中，第二设备可以将第一身份识别码的相关信息存储至功能集(cluster)中，例如存储至新定义的功能集中。
第二设备存储第一身份识别码的相关信息后，便可以根据第一设备发送的身份识别码索引查询正确的身份识别码。
图6为本申请另一实施例提供的第一设备与第二设备协商第一身份识别码的流程示意图。如图6所示，在步骤S610，第一设备向第二设备发送第四消息，第四消息用于指示第二设备返回第一身份识别码。第二设备返回第一身份识别码之后，第一身份识别码对应的设备便可以访问第二设备。也就是说，在该实施例中，第一身份识别码可以是第二设备生成的。
在一些实施例中，第一设备和第二设备协商共享密钥时，第二设备可以为第一设备返回一个临时身份识别码，因此，在一些实施例中，采用这种第二设备为第一设备返回临时身份识别码的方案也可以称为采用临时身份识别码的方案。
作为一种实现方式，第一设备在向第二设备发送第一消息之前，可以向第二设备发送第四消息，该第四消息中可以携带指示第一设备不具有身份识别码的信息，例如第四消息中可以携带身份识别码索引值为0的数据，身份识别码索引值为0表示第一设备不具有身份识别码。
在步骤S620，第二设备接收第四消息后，为第一设备返回第一身份识别码。在一些实施例中，第二设备为第一设备返回的第一身份识别码为临时身份识别码，第一设备可以根据返回的临时身份识别码，实现对第二设备的访问。
作为一种实现方式，第二设备接收第四消息后，根据第四消息知晓第一设备不具有身份识别码，基于此，第二设备可以生成临时身份识别码并将该临时身份识别码显示在第二设备的显示屏上，以便于第一设备知晓该临时身份识别码。
在一些实施例中，第二设备知晓第一设备不具有身份识别码后，还可以向第一设备发送第四响应，第四响应可以用于告知第一设备输入第二设备为第一设备返回的临时身份识别码。应该理解，第四响应可以理解为是第二设备针对第一设备发送的第四消息返回的响应消息，后文提及的响应也可指是针对某一消息返回的响应消息，后文不再赘述。
在一些实施例中，第一设备输入第一设备的临时身份识别码后，可以向第二设备发送第一消息。可选地，第一设备在向第二设备发送第一消息时，第一消息中除包含第一数据之外，还可以包含第一设备的临时身份识别码对应的索引，该临时身份识别码对应的索引用于表示第一设备已经具有身份识别码了。示例性地，第一消息中包含的临时身份识别码对应的索引可以为全F值，该全F值用于表示第一设备具有临时身份识别码了。
在一些实施例中，第一设备输入临时身份识别码后，可以不保存该临时身份识别码。
前文提及，在一些实施例中，第一设备和第二设备在协商共享密钥前，可以根据第一设备和第二设备分别支持的密钥协商方式(或类型)，协商确定共享密钥的协商方式。下面结合图7，对第一设备和第二设备协商共享密钥的协商方式的过程进行详细介绍。
在步骤S710，第一设备向第二设备发送第五消息，第五消息用于指示第一设备支持的密钥协商方式。
第一设备支持的密钥协商方式可以包括一种或多种，示例性地，第一设备支持的密钥协商方式可以包括以下方式中的一种或多种：基于密钥对协商、基于NOC协商、以及基于sigma协议协商。
应该理解，第一设备和第二设备协商确定出共享密钥的协商方式之后，可以基于该协商方式协商共享密钥，并建立基于该共享密钥的互操作通道，因此，在一些实施例中，可以根据第一设备和第二设备协商共享密钥的方式的不同，将互操作通道划分为不同的类型。示例性地，第一设备和第二设备基于sigma协议协商共享密钥，其对应的互操作通道的类型为基于sigma协议的互操作通道。或者说，第一设备支持的密钥协商方式也可以称为第一设备支持的建立互操作的类型。因此，在一些实施例中，第五 消息也可以称为互操作会话建立请求消息，本申请对此并不限定。
在步骤S720，第二设备向第一设备发送第五响应，第五响应用于指示基于sigma协议协商共享密钥。
作为一种实现方式，第二设备可以根据第一设备支持的密钥协商方式，确定基于sigma协议协商共享密钥，并将该信息通过第五响应通知给第一设备。
作为另一种实现方式，第二设备接收到第五消息之后，可以在第五响应中指示第二设备支持的密钥协商方式，由第一设备确定共享密钥的协商方式。第二设备支持的密钥协商方式可以包括以下方式的一种或多种：基于密钥对协商、基于NOC协商、以及基于sigma协议协商。
例如，第二设备仅支持基于sigma协议协商共享密钥，那么第五响应中仅包含基于sigma协议协商共享密钥的方式，第一设备接收到第五响应后，可以直接确定基于sigma协议与第二设备协商共享密钥。或者，第二设备支持的密钥协商方式包括多种，例如，包括基于NOC协商和基于sigma协议协商，那么第一设备接收到第五响应后，可以从第二设备支持的密钥协商方式中选择一种，在本申请实施例中，第一设备选择的密钥协商方式为基于sigma协议与第二设备协商共享密钥。
为了便于本领域技术人员理解本申请实施例的技术方案的实施过程，下面给出几个具体示例。应该理解，该示例并不用于限定本申请的技术方案，例如，示例中的步骤并不都是必须的，实际实施时可能只采用部分步骤，或者采用比列举的步骤更多的步骤；或者，示例中的步骤的执行顺序也不是必须的，某些步骤是可以同时执行或者调换执行顺序的。
示例一(采用固定身份识别码)
在示例一中，第一数据不包含第一目的标识。下面结合图8，对示例一进行详细描述。
图8为本申请另一实施例提供的建立互操作通道的方法的流程示意图。如图8所示，该方法可以包括步骤S8010至步骤S8170。
在步骤S8010，第一设备与第二设备建立配置通道。该配置通道可以是一种安全配置信道，用于第一设备与第二设备之间进行配置操作。
在步骤S8020，第一设备向第二设备发送第三消息，第三消息用于配置第一身份识别码以及第一身份识别码对应的索引，例如配置元组信息<pincode，pincode_index>，以便第一身份识别码对应的设备可以访问第二设备。
在一些实施例中，第一设备可以向第二设备配置多组第一身份识别码以及第一身份识别码对应的索引，即配置多组元组信息。该多组元组信息可以形成配置列表，用于指示第一身份识别码的相关信息。
在一些实施例中，第一设备向第二设备配置第一身份识别码以及第一身份识别码对应的索引后，第一设备可以对应存储该第一身份识别码以及第一身份识别码对应的索引。
在步骤S8030，第二设备存储第一设备配置的第一身份识别码以及第一身份识别码对应的索引，例如存储至第二设备的资源中，或者存储至第二设备的功能集(比如新定义的功能集)中。
在一些实施例中，第二设备存储第一设备配置的第一身份识别码以及第一身份识别码对应的索引之后，还可以向第一设备返回配置状态，该配置状态例如可以用于指示第二设备已存储第一身份识别码以及第一身份识别码对应的索引。
在步骤S8040，第一设备向第二设备配置互操作证书链。例如，第一设备向第二设备配置第一设备的RCAC、第二设备的NOC；或者，第一设备向第二设备配置第一设备的RCAC、第一设备的ICAC、第二设备的NOC。
在步骤S8050，第一设备与第二设备之间的配置结束，退出配置通道。
在一些实施例中，第一设备除了向第二设备配置第一身份识别码、以及配置互操作证书链之外，还可以向第二设备配置一些基础配置，待完成身份识别码、互操作证书链以及基础配置后，第一设备与第二设备之间的配置结束，退出配置通道。
在步骤S8060，第一设备向第二设备发送第五消息，第五消息用于指示第一设备支持的密钥协商方式。
在一些实施例中，第一设备支持的密钥协商方式可以包括以下方式中的一种或多种：基于密钥对协商、基于NOC协商、基于sigma协议协商。
在步骤S8070，第二设备向第一设备返回第五响应。第五响应可以用于指示第二设备支持的密钥协商方式，例如第二设备支持的密钥协商方式为基于sigma协议协商。
在步骤S8080，第一设备使用第一设备的身份识别码对第一数据进行加密。
作为一种实现方式，首先第一设备可以生成随机数r1、第一设备的会话标识以及第一设备的临时密钥对(包括第一设备的临时公钥和临时私钥)，得到第一数据。第一数据可以包括以下信息中的一种或多种：第一设备生成的随机数r1、第一设备的会话标识以及第一设备的临时公钥。然后第一设备可以使 用第一设备的身份识别码对第一数据进行加密。
在步骤S8090，第一设备向第二设备发送第一消息，第一消息中可以携带使用第一设备的身份识别码进行加密的第一数据以及该身份识别码对应的索引，该索引是不加密的。
在一些实施例中，该身份识别码对应的索引为非零值、非全F值。
在步骤S8100，第二设备根据第一设备的临时公钥和第二设备的临时私钥，生成共享密钥。
在一些实施例中，第二设备接收第一消息之后，可以通过第一消息中携带的索引值对应找到身份识别码，使用该身份识别码解密第一数据。
在一些实施例中，第二设备接收第一消息之后，可以生成第二设备的临时密钥对(包括第二设备的临时公钥和临时私钥)。
在一些实施例中，第二设备生成第二设备的临时密钥对后，可以使用第一设备的临时公钥和第二设备的临时私钥，生成第二密钥。应该理解，第一设备的临时公钥可以是携带于第一消息中的。
在一些实施例中，第二设备还可以使用第二设备的NOC对应的私钥对以下数据中的一种或多种进行签名生成第二签名sign2：第二设备的NOC、第一设备的CA证书(例如，第一设备的ICAC)、第二设备的临时公钥。
基于此，第二设备可以根据以下信息中的一种或多种生成共享密钥：根据第一设备的临时公钥和第二设备的临时私钥生成的第二密钥、第二设备生成的随机数r2、第二设备的临时公钥等。示例性地，第二设备生成的共享密钥可以描述为：共享密钥＝(第二密钥，salt，第二设备生成的共享密钥的描述信息，第二设备生成的共享密钥的长度信息)。关于各密钥参数的详细描述，可以参见前文。
在一些实施例中，第二设备可以使用第二设备生成的共享密钥对第四数据进行加密得到第一encryptData。
在一些实施例中，第二设备可以生成第二设备的会话标识。
在步骤S8110，第二设备向第一设备发送第二消息，第二消息中携带第二数据。第二数据包括以下信息中的一种或多种：第二设备生成的随机数r2、第二设备的会话标识、第二设备的临时公钥、以及第一encryptData。
在步骤S8120，第一设备根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥。
在一些实施例中，第一设备接收第二消息后，可以使用第二设备的临时公钥和第一设备的临时私钥，生成第一密钥。
在一些实施例中，第一设备可以根据第一密钥得到共享密钥，使用共享密钥解密第二消息中的第一encryptData，解析出对应的数据。
在一些实施例中，第一设备在生成共享密钥之前，可以对第二设备的身份进行验证。例如，使用第一设备的RCAC校验第二设备发来的ICAC，使用第一设备的ICAC校验第二设备的NOC。
在一些实施例中，第一设备可以利用第二设备的NOC对应的公钥对第二设备生成的第二签名sign2进行校验。
在一些实施例中，第一设备可以使用第一设备的NOC对应的私钥对以下数据中的一种或多种进行签名得到第一设备的第一签名sign1：第一设备的NOC、第一设备的CA证书(例如，第一设备的ICAC)、第一设备的临时公钥。
基于此，第一设备可以根据以下信息中的一种或多种生成共享密钥：根据第二设备的临时公钥和第一设备的临时私钥生成的第一密钥、第一设备生成的随机数r1、第一设备的临时公钥等。示例性地，第一设备生成的共享密钥可以描述为：共享密钥＝(第一密钥，salt，第一设备生成的共享密钥的描述信息，第一设备生成的共享密钥的长度信息)。关于各密钥参数的详细描述，可以参见前文。
在一些实施例中，第一设备可以使用第一设备生成的共享密钥对第四数据进行加密得到第二encryptData。
在步骤S8130，第一设备向第二设备发送sigma3消息，sigma3消息中可以包含第二encryptData。
在步骤S8140，第二设备对sigma3消息进行处理。示例性地，第二设备可以利用生成的共享密钥解密第二encryptData，解析对应的数据。
在一些实施例中，第二设备接收第一设备发送的sigma3消息后，可以对第一设备的身份进行验证。示例性地，若配置的互操作证书链为三级互操作证书链，则第二设备可以使用第一设备的RCAC校验第一设备发来的ICAC，使用存储的第一设备的ICAC校验第一设备的NOC；若配置的互操作证书链为二级互操作证书链，则第一设备可以使用第一设备的RCAC校验第一设备的NOC。
在一些实施例中，第二设备还可以使用第一设备的NOC对应的公钥对第一设备生成的第一签名进行校验。
在步骤S8150，第二设备向第一设备返回sigma校验完成消息。
在步骤S8160，第一设备和第二设备建立基于共享密钥的互操作通道。
在步骤S8170，第一设备通过互操作通道对第二设备进行控制。
示例二(采用固定身份识别码)
在示例二中，第一数据包含第一目的标识。下面结合图9，对示例二进行详细描述。
图9为本申请又一实施例提供的建立互操作通道的方法的流程示意图。如图9所示，该方法可以包括步骤S9010至步骤S9170。
在步骤S9010，第一设备与第二设备建立配置通道。该配置通道可以是一种安全配置信道，用于第一设备与第二设备之间进行配置操作。
在步骤S9020，第一设备向第二设备发送第三消息，第三消息用于配置第一身份识别码以及身份识别码对应的索引，例如配置元组信息<pincode，pincode_index>，以便第一身份识别码对应的设备可以访问第二设备。
在一些实施例中，第一设备可以向第二设备配置多组第一身份识别码以及第一身份识别码对应的索引，即配置多组元组信息。该多组元组信息可以形成配置列表，用于指示第一身份识别码的相关信息。
在一些实施例中，第一设备向第二设备配置第一身份识别码以及第一身份识别码对应的索引后，第一设备可以对应存储该第一身份识别码以及第一身份识别码对应的索引。
在步骤S9030，第二设备存储第一设备配置的第一身份识别码以及第一身份识别码对应的索引，例如存储至第二设备的资源中，或者存储至第二设备的功能集(比如新定义的功能集)中。
在一些实施例中，第二设备存储第一设备配置的第一身份识别码以及第一身份识别码对应的索引之后，还可以向第一设备返回配置状态，该配置状态例如可以用于指示第二设备已存储第一身份识别码以及第一身份识别码对应的索引。
在步骤S9040，第一设备向第二设备配置互操作证书链。例如，第一设备向第二设备配置第一设备的RCAC、第二设备的NOC；或者，第一设备向第二设备配置第一设备的RCAC、第一设备的ICAC、第二设备的NOC。
在步骤S9050，第一设备与第二设备之间的配置结束，退出配置通道。
在一些实施例中，第一设备除了向第二设备配置第一身份识别码、以及配置互操作证书链之外，还可以向第二设备配置一些基础配置，待完成身份识别码、互操作证书链以及基础配置后，第一设备与第二设备之间的配置结束，退出配置通道。
在步骤S9060，第一设备向第二设备发送第五消息，第五消息用于指示第一设备支持的密钥协商方式。
在一些实施例中，第一设备支持的密钥协商方式可以包括以下方式中的一种或多种：基于密钥对协商、基于NOC协商、基于sigma协议协商。
在步骤S9070，第二设备向第一设备返回第五响应。第五响应可以用于指示第二设备支持的密钥协商方式，例如第二设备支持的密钥协商方式为基于sigma协议协商。
在步骤S9080，第一设备使用第一设备的身份识别码对第一目的标识进行加密。
作为一种实现方式，首先第一设备可以生成随机数r1、第一设备的会话标识以及第一设备的临时密钥对(包括第一设备的临时公钥和临时私钥)，并生成第一目的标识。第一目的标识是第一设备使用第一设备的身份识别码对第一信息进行加密生成的，第一信息包括以下信息中的一种或多种：第一设备生成的随机数r1、第二设备的设备标识、以及第一设备的RCAC对应的公钥。然后，第一设备生成第一数据，第一数据可以包括第一设备的临时公钥和第一目的标识，此外，第一数据还可以包括以下信息中的一种或多种：第一设备生成的随机数r1、第一设备的会话标识。
在步骤S9090，第一设备向第二设备发送第一消息，第一消息中可以携带第一数据以及该身份识别码对应的索引，该索引是不加密的。
在一些实施例中，该身份识别码对应的索引为非零值、非全F值。
在步骤S9100，第二设备根据第一设备的临时公钥和第二设备的临时私钥，生成共享密钥。
在一些实施例中，第二设备接收第一消息之后，可以通过第一消息中携带的索引值对应找到身份识别码，使用该身份识别码对第一信息进行加密得到第二目的标识。在一些实施例中，第二设备可以根据第一目的标识和第二目的标识，校验第一设备的身份。示例性地，第二设备若判断第一目的标识与第二目的标识相同，则表示校验通过。
在一些实施例中，第二设备接收第一消息之后，可以生成第二设备的临时密钥对(包括第二设备的临时公钥和临时私钥)。
在一些实施例中，第二设备生成第二设备的临时密钥对后，可以使用第一设备的临时公钥和第二设备的临时私钥，生成第二密钥。应该理解，第一设备的临时公钥可以是携带于第一消息中的。
在一些实施例中，第二设备还可以使用第二设备的NOC对应的私钥对以下数据中的一种或多种进行签名生成第二签名sign2：第二设备的NOC、第一设备的CA证书(例如，第一设备的ICAC)、第二设备的临时公钥。
基于此，第二设备可以根据以下信息中的一种或多种生成共享密钥：根据第一设备的临时公钥和第二设备的临时私钥生成的第二密钥、第二设备生成的随机数r2、第二设备的临时公钥等。示例性地，第二设备生成的共享密钥可以描述为：共享密钥＝(第二密钥，salt，第二设备生成的共享密钥的描述信息，第二设备生成的共享密钥的长度信息)。关于各密钥参数的详细描述，可以参见前文。
在一些实施例中，第二设备可以使用第二设备生成的共享密钥对第四数据进行加密得到第一encryptData。
在一些实施例中，第二设备可以生成第二设备的会话标识。
在步骤S9110，第二设备向第一设备发送第二消息，第二消息中携带第二数据。第二数据包括以下信息中的一种或多种：第二设备生成的随机数r2、第二设备的会话标识、第二设备的临时公钥、以及第一encryptData。
在步骤S9120，第一设备根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥。
在一些实施例中，第一设备接收第二消息后，可以使用第二设备的临时公钥和第一设备的临时私钥，生成第一密钥。
在一些实施例中，第一设备可以根据第一密钥得到共享密钥，使用共享密钥解密第二消息中的第一encryptData，解析出对应的数据。
在一些实施例中，第一设备在生成共享密钥之前，可以对第二设备的身份进行验证。例如，使用第一设备的RCAC校验第二设备发来的ICAC，使用第一设备的ICAC校验第二设备的NOC。
在一些实施例中，第一设备可以利用第二设备的NOC对应的公钥对第二设备生成的第二签名sign2进行校验。
在一些实施例中，第一设备可以使用第一设备的NOC对应的私钥对以下数据中的一种或多种进行签名得到第一设备的第一签名sign1：第一设备的NOC、第一设备的CA证书(例如，第一设备的ICAC)、第一设备的临时公钥。
基于此，第一设备可以根据以下信息中的一种或多种生成共享密钥：根据第二设备的临时公钥和第一设备的临时私钥生成的第一密钥、第一设备生成的随机数r1、第一设备的临时公钥等。示例性地，第一设备生成的共享密钥可以描述为：共享密钥＝(第一密钥，salt，第一设备生成的共享密钥的描述信息，第一设备生成的共享密钥的长度信息)。关于各密钥参数的详细描述，可以参见前文。
在一些实施例中，第一设备可以使用第一设备生成的共享密钥对第四数据进行加密得到第二encryptData。
在步骤S9130，第一设备向第二设备发送sigma3消息，sigma3消息中可以包含第二encryptData。
在步骤S9140，第二设备对sigma3消息进行处理。示例性地，第二设备可以利用生成的共享密钥解密第二encryptData，解析对应的数据。
在一些实施例中，第二设备接收第一设备发送的sigma3消息后，可以对第一设备的身份进行验证。示例性地，若配置的互操作证书链为三级互操作证书链，则第二设备可以使用第一设备的RCAC校验第一设备发来的ICAC，使用存储的第一设备的ICAC校验第一设备的NOC；若配置的互操作证书链为二级互操作证书链，则第一设备可以使用第一设备的RCAC校验第一设备的NOC。
在一些实施例中，第二设备还可以使用第第一设备的NOC对应的公钥对第一设备生成的第一签名进行校验。
在步骤S9150，第二设备向第一设备返回sigma校验完成消息。
在步骤S9160，第一设备和第二设备建立基于共享密钥的互操作通道。
在步骤S9170，第一设备通过互操作通道对第二设备进行控制。
示例三(采用临时身份识别码)
在示例三中，第一数据包含第一目的标识。下面结合图10，对示例三进行详细描述。
图10为本申请又一实施例提供的建立互操作通道的方法的流程示意图。如图10所示，该方法可以包括步骤S1001至步骤S1017。
在步骤S1001，第一设备与第二设备建立配置通道。该配置通道可以是一种安全配置信道，用于第一设备与第二设备之间进行配置操作。
在步骤S1002，第一设备向第二设备配置互操作证书链。例如，第一设备向第二设备配置第一设备的RCAC、第二设备的NOC；或者，第一设备向第二设备配置第一设备的RCAC、第一设备的ICAC、第二设备的NOC。
在步骤S1003，第一设备与第二设备之间的配置结束，退出配置通道。
在步骤S1004，第一设备向第二设备发送第五消息，第五消息用于指示第一设备支持的密钥协商方式。
在一些实施例中，第一设备支持的密钥协商方式可以包括以下方式中的一种或多种：基于密钥对协商、基于NOC协商、基于sigma协议协商。
在步骤S1005，第二设备向第一设备返回第五响应。第五响应可以用于指示第二设备支持的密钥协商方式，例如第二设备支持的密钥协商方式为基于sigma协议协商。
在步骤S1006，第一设备向第二设备发送第四消息，第四消息用于指示第二设备返回第一身份识别码。
在一些实施例中，第四消息中可以携带指示第一设备不具有身份识别码的信息，例如，可以携带身份识别码索引为0的数据来指示第一设备不具有身份识别码。
在步骤S1007，第二设备为第一设备返回第一身份识别码，例如该第一身份识别码为临时身份识别码。
在一些实施例中，第二设备可以向第一设备发送第四响应，返回错误码，告知第一设备需要输入第二设备为第一设备返回的临时身份识别码。
在一些实施例中，第二设备可以将需要输入的临时身份识别码显示在第二设备的显示屏上。
在步骤S1008，第一设备使用第一设备的身份识别码对第一目的标识进行加密。
作为一种实现方式，首先第一设备可以生成随机数r1、第一设备的会话标识以及第一设备的临时密钥对(包括第一设备的临时公钥和临时私钥)，并生成第一目的标识。第一目的标识是第一设备使用第一设备的身份识别码对第一信息进行加密生成的，第一信息包括以下信息中的一种或多种：第一设备生成的随机数r1、第二设备的设备标识、以及第一设备的RCAC对应的公钥。然后，第一设备生成第一数据，第一数据可以包括第一设备的临时公钥和第一目的标识，此外，第一数据还可以包括以下信息中的一种或多种：第一设备生成的随机数r1、第一设备的会话标识。
在步骤S1009，第一设备向第二设备发送第一消息，第一消息中可以携带第一数据以及该身份识别码对应的索引，该索引是不加密的。
在一些实施例中，该身份识别码对应的索引为非零值、非全F值。
在步骤S1010，第二设备根据第一设备的临时公钥和第二设备的临时私钥，生成共享密钥。
在一些实施例中，第二设备接收第一消息之后，可以通过第一消息中携带的索引值对应找到身份识别码，使用该身份识别码对第一信息进行加密得到第二目的标识。在一些实施例中，第二设备可以根据第一目的标识和第二目的标识，校验第一设备的身份。示例性地，第二设备若判断第一目的标识与第二目的标识相同，则表示校验通过。
在一些实施例中，第二设备接收第一消息之后，可以生成第二设备的临时密钥对(包括第二设备的临时公钥和临时私钥)。
在一些实施例中，第二设备生成第二设备的临时密钥对后，可以使用第一设备的临时公钥和第二设备的临时私钥，生成第二密钥。应该理解，第一设备的临时公钥可以是携带于第一消息中的。
在一些实施例中，第二设备还可以使用第二设备的NOC对应的私钥对以下数据中的一种或多种进行签名生成第二签名sign2：第二设备的NOC、第一设备的CA证书(例如，第一设备的ICAC)、第二设备的临时公钥。
基于此，第二设备可以根据以下信息中的一种或多种生成共享密钥：根据第一设备的临时公钥和第二设备的临时私钥生成的第二密钥、第二设备生成的随机数r2、第二设备的临时公钥等。示例性地，第二设备生成的共享密钥可以描述为：共享密钥＝(第二密钥，salt，第二设备生成的共享密钥的描述信息，第二设备生成的共享密钥的长度信息)。关于各密钥参数的详细描述，可以参见前文。
在一些实施例中，第二设备可以使用第二设备生成的共享密钥对第四数据进行加密得到第一encryptData。
在一些实施例中，第二设备可以生成第二设备的会话标识。
在一些实施例中，第二设备可以生成第二设备的会话标识。
在步骤S1011，第二设备向第一设备发送第二消息，第二消息中携带第二数据。第二数据包括以下信息中的一种或多种：第二设备生成的随机数r2、第二设备的会话标识、第二设备的临时公钥、以及第一encryptData。
在步骤S1012，第一设备根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥。
在一些实施例中，第一设备接收第二消息后，可以使用第二设备的临时公钥和第一设备的临时私钥，生成第一密钥。
在一些实施例中，第一设备可以根据第一密钥得到共享密钥，使用共享密钥解密第二消息中的第一encryptData，解析出对应的数据。
在一些实施例中，第一设备在生成共享密钥之前，可以对第二设备的身份进行验证。例如，使用第一设备的RCAC校验第二设备发来的ICAC，使用第一设备的ICAC校验第二设备的NOC。
在一些实施例中，第一设备可以利用第二设备的NOC对应的公钥对第二设备生成的第二签名sign2进行校验。
在一些实施例中，第一设备可以使用第一设备的NOC对应的私钥对以下数据中的一种或多种进行签名得到第一设备的第一签名sign1：第一设备的NOC、第一设备的CA证书(例如，第一设备的ICAC)、第一设备的临时公钥。
基于此，第一设备可以根据以下信息中的一种或多种生成共享密钥：根据第二设备的临时公钥和第一设备的临时私钥生成的第一密钥、第一设备生成的随机数r1、第一设备的临时公钥等。示例性地，第一设备生成的共享密钥可以描述为：共享密钥＝(第一密钥，salt，第一设备生成的共享密钥的描述信息，第一设备生成的共享密钥的长度信息)。关于各密钥参数的详细描述，可以参见前文。
在一些实施例中，第一设备可以使用第一设备生成的共享密钥对第四数据进行加密得到第二encryptData。
在步骤S1013，第一设备向第二设备发送sigma3消息，sigma3消息中可以包含第二encryptData。
在步骤S1014，第二设备对sigma3消息进行处理。示例性地，第二设备可以利用生成的共享密钥解密第二encryptData，解析对应的数据。
在一些实施例中，第二设备接收第一设备发送的sigma3消息后，可以对第一设备的身份进行验证。示例性地，若配置的互操作证书链为三级互操作证书链，则第二设备可以使用第一设备的RCAC校验第一设备发来的ICAC，使用存储的第一设备的ICAC校验第一设备的NOC；若配置的互操作证书链为二级互操作证书链，则第一设备可以使用第一设备的RCAC校验第一设备的NOC。
在一些实施例中，第二设备还可以使用第第一设备的NOC对应的公钥对第一设备生成的第一签名进行校验。
在步骤S1015，第二设备向第一设备返回sigma校验完成消息。
在步骤S1016，第一设备和第二设备建立基于共享密钥的互操作通道。
在步骤S1017，第一设备通过互操作通道对第二设备进行控制。
上文结合图1至图10，详细描述了本申请的方法实施例，下面结合图11至图13，详细描述本申请的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图11为本申请一实施例提供的建立互操作通道的装置的结构示意图。该装置可以配置于前文所述的第一设备。图11所示的装置1100可以包括第一协商模块1110、建立模块1120以及控制模块1130。
第一协商模块1110可以用于根据sigma协议与第二设备协商共享密钥。
建立模块1120可以用于与第二设备建立基于共享密钥的互操作通道。
控制模块1130可以用于通过互操作通道向第二设备发送控制指令，以对第二设备进行控制，其中，所述第一设备为终端设备，所述第二设备为车设备。
可选地，第一协商模块进一步包括：第一发送模块，用于向第二设备发送第一消息，第一消息包含第一数据，第一数据包含第一设备的临时公钥，第一设备的临时公钥用于第二设备生成共享密钥；第一接收模块，用于从第二设备接收第二消息，第二消息包含第二数据，第二数据包含第二设备的临时公钥；生成模块，用于根据第二设备的临时公钥和第一设备的临时私钥，生成共享密钥。
可选地，第一数据还包含以下信息中的一种或多种：第一设备的会话标识、第一设备生成的随机数；和/或，第二数据还包含以下信息中的一种或多种：第二设备的会话标识、第二设备生成的随机数。
可选地，装置1100还包括：加密模块，用于根据第一设备的身份识别码对第一数据进行加密。
可选地，第一数据还包含第一目的标识，第一目的标识用于第二设备校验第一设备的身份。
可选地，第一目的标识是第一设备根据第一设备的身份识别码对第一信息进行加密得到的，第一信息包括以下信息中的一种或多种：第一设备生成的随机数、第二设备的设备标识、以及第一设备的设备认证中心CA证书对应的公钥。
可选地，装置1100还包括：第二协商模块，用于与第二设备协商第一身份识别码，第一身份识别码用于该第一身份识别码对应的设备访问第二设备。
可选地，第二协商模块进一步包括：第二发送模块，用于向第二设备发送第三消息，第三消息用于配置第一身份识别码。
可选地，第二协商模块进一步包括：第三发送模块，用于向第二设备发送第四消息，第四消息用于 指示第二设备返回第一身份识别码。
可选地，第四消息携带指示第一设备不具有身份识别码的信息，装置1100还包括：第二接收模块，用于接收第二设备返回的第一身份识别码。
可选地，第二设备返回的第一身份识别码显示在第二设备的显示屏上。
可选地，第二设备返回的第一身份识别码为临时身份识别码。
可选地，装置1100还包括：第三协商模块，用于与第二设备协商共享密钥的协商方式。
可选地，第三协商模块进一步包括：第四发送模块，用于向第二设备发送第五消息，第五消息用于指示第一设备支持的密钥协商方式；第三接收模块，用于从第二设备接收第五响应，第五响应用于指示基于sigma协议协商共享密钥。
可选地，第一设备和/或第二设备支持的密钥协商方式包括以下方式中的一种或多种：基于密钥对协商，基于节点互操作证书协商，以及基于sigma协议协商。
可选地，共享密钥是第一设备根据以下信息中的一种或多种生成的：第一密钥、第一设备生成的随机数、以及第一设备的临时公钥，其中，第一密钥是第一设备根据第二设备的临时公钥和第一设备的临时私钥生成的。
图12为本申请另一实施例提供的建立互操作通道的装置的结构示意图。该装置可以配置于前文的第二设备。图12所示的装置1200可以包括第一协商模块1210、建立模块1220、以及第一接收模块1230。
第一协商模块1210可以用于根据sigma协议与第一设备协商共享密钥。
建立模块1220可以用于与第一设备建立基于共享密钥的互操作通道。
第一接收模块1230可以用于通过互操作通道接收第一设备的控制指令，其中，第一设备为终端设备，第二设备为车设备。
可选地，第一协商模块进一步包括：第二接收模块，用于接收第一设备发送的第一消息，第一消息包含第一数据，第一数据包含第一设备的临时公钥；生成模块，用于根据第一设备的临时公钥和第二设备的临时私钥，生成共享密钥；第一发送模块，用于向第一设备发送第二消息，第二消息包含第二数据，第二数据包含第二设备的临时公钥，第二设备的临时公钥用于第一设备生成共享密钥。
可选地，第一数据还包含以下信息中的一种或多种：第一设备的会话标识、第一设备生成的随机数；和/或，第二数据还包含以下信息中的一种或多种：第二设备的会话标识、第二设备生成的随机数。
可选地，装置1200还包括：解密模块，用于根据第一设备的身份识别码对第一数据进行解密。
可选地，第一数据还包含第一目的标识，第一目的标识用于第二设备校验第一设备的身份。
可选地，第一目的标识是第一设备根据第一设备的身份识别码对第一信息进行加密得到的，第一信息包括以下信息中的一种或多种：第一设备生成的随机数、第二设备的设备标识、以及第一设备的设备认证中心CA证书对应的公钥。
可选地，装置1200还包括：加密模块，用于根据第一设备的身份识别码对第一信息进行加密，得到第二目的标识；校验模块，用于根据第一目的标识和第二目的标识，校验第一设备的身份。
可选地，装置1200还包括：第二协商模块，用于与第一设备协商第一身份识别码，第一身份识别码用于该第一身份识别码对应的设备访问第二设备的身份识别码。
可选地，第二协商模块进一步包括：第三接收模块，用于接收第一设备发送的第三消息，第三消息用于配置第一身份识别码。
可选地，第二协商模块进一步包括：第四接收模块，用于接收第一设备发送的第四消息，第四消息用于指示第二设备返回第一身份识别码。
可选地，第四消息携带指示第一设备不具有身份识别码的信息，装置1200还包括：返回模块，用于为第一设备返回第一身份识别码。
可选地，第二设备返回的第一身份识别码显示在第二设备的显示屏上。
可选地，第二设备返回的第一身份识别码为临时身份识别码。
可选地，装置1200还包括：第三协商模块，用于与第一设备协商共享密钥的协商方式。
可选地，第三协商模块进一步包括：第五接收模块，用于接收第一设备发送的第五消息，第五消息用于指示第一设备支持的密钥协商方式；第二发送模块，用于向第一设备发送第五响应，第五响应用于指示基于sigma协议协商共享密钥。
可选地，第一设备和/或第二设备支持的密钥协商方式包括以下方式中的一种或多种：基于密钥对协商，基于节点互操作证书协商，以及基于sigma协议协商。
可选地，共享密钥是第二设备根据以下信息中的一种或多种生成的：第二密钥、第二设备生成的随机数、以及第二设备的临时公钥，其中，第二密钥是第二设备根据第一设备的临时公钥和第二设备的临 时私钥生成的。
在可选的实施例中，建立互操作通道的装置1100和/或建立互操作通道的装置1200还可以包括收发器1330和存储器1320，具体如图13所示。
图13是本申请实施例的通信装置的示意性结构图。图13中的虚线表示该单元或模块为可选的。该装置1300可用于实现上述方法实施例中描述的方法。装置1300可以是芯片、终端设备或网络设备。
装置1300可以包括一个或多个处理器1310。该处理器1310可支持装置1300实现前文方法实施例所描述的方法。该处理器1310可以是通用处理器或者专用处理器。例如，该处理器可以为中央处理单元(central processing unit，CPU)。或者，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
装置1300还可以包括一个或多个存储器1320。存储器1320上存储有程序，该程序可以被处理器1310执行，使得处理器1310执行前文方法实施例所描述的方法。存储器1320可以独立于处理器1310也可以集成在处理器1310中。
装置1300还可以包括收发器1330。处理器1310可以通过收发器1330与其他设备或芯片进行通信。例如，处理器1310可以通过收发器1330与其他设备或芯片进行数据收发。
本申请实施例还提供一种计算机可读存储介质，用于存储程序。该计算机可读存储介质可应用于本申请实施例提供的终端或网络设备中，并且该程序使得计算机执行本申请各个实施例中的由终端或网络设备执行的方法。
本申请实施例还提供一种计算机程序产品。该计算机程序产品包括程序。该计算机程序产品可应用于本申请实施例提供的终端或网络设备中，并且该程序使得计算机执行本申请各个实施例中的由终端或网络设备执行的方法。
本申请实施例还提供一种计算机程序。该计算机程序可应用于本申请实施例提供的终端或网络设备中，并且该计算机程序使得计算机执行本申请各个实施例中的由终端或网络设备执行的方法。
应理解，本申请中术语“***”和“网络”可以被可互换使用。另外，本申请使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。
在本申请的实施例中，提到的“指示”可以是直接指示，也可以是间接指示，还可以是表示具有关联关系。举例说明，A指示B，可以表示A直接指示B，例如B可以通过A获取；也可以表示A间接指示B，例如A指示C，B可以通过C获取；还可以表示A和B之间具有关联关系。
在本申请实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
在本申请实施例中，术语“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。
本申请实施例中，“预定义”或“预配置”可以通过在设备(例如，包括终端设备和网络设备)中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。比如预定义可以是指协议中定义的。
本申请实施例中，所述“协议”可以指通信领域的标准协议，例如可以包括LTE协议、NR协议以及应用于未来的通信***中的相关协议，本申请对此不做限定。
本申请实施例中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的 需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字通用光盘(digital video disc，DVD))或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (73)

  1. 一种建立互操作通道的方法，其特征在于，包括：
    第一设备根据sigma协议与第二设备协商共享密钥；
    所述第一设备与所述第二设备建立基于所述共享密钥的互操作通道；
    所述第一设备通过所述互操作通道向所述第二设备发送控制指令，以对所述第二设备进行控制；
    其中，所述第一设备为终端设备，所述第二设备为车设备。
  2. 根据权利要求1所述的方法，其特征在于，所述第一设备根据sigma协议与第二设备协商共享密钥，包括：
    所述第一设备向所述第二设备发送第一消息，所述第一消息包含第一数据，所述第一数据包含所述第一设备的临时公钥，所述第一设备的临时公钥用于所述第二设备生成所述共享密钥；
    所述第一设备从所述第二设备接收第二消息，所述第二消息包含第二数据，所述第二数据包含所述第二设备的临时公钥；
    所述第一设备根据所述第二设备的临时公钥和所述第一设备的临时私钥，生成所述共享密钥。
  3. 根据权利要求2所述的方法，其特征在于：
    所述第一数据还包含以下信息中的一种或多种：所述第一设备的会话标识、所述第一设备生成的随机数；和/或
    所述第二数据还包含以下信息中的一种或多种：所述第二设备的会话标识、所述第二设备生成的随机数。
  4. 根据权利要求2或3所述的方法，其特征在于，在所述第一设备向所述第二设备发送第一消息之前，所述方法还包括：
    所述第一设备根据所述第一设备的身份识别码对所述第一数据进行加密。
  5. 根据权利要求2所述的方法，其特征在于，所述第一数据还包含第一目的标识，所述第一目的标识用于所述第二设备校验所述第一设备的身份。
  6. 根据权利要求5所述的方法，其特征在于，所述第一目的标识是所述第一设备根据所述第一设备的身份识别码对第一信息进行加密得到的，所述第一信息包括以下信息中的一种或多种：所述第一设备生成的随机数、所述第二设备的设备标识、以及所述第一设备的设备认证中心CA证书对应的公钥。
  7. 根据权利要求4或6所述的方法，其特征在于，所述方法还包括：
    所述第一设备与所述第二设备协商第一身份识别码，所述第一身份识别码用于所述第一身份识别码对应的设备访问所述第二设备。
  8. 根据权利要求7所述的方法，其特征在于，所述第一设备与所述第二设备协商第一身份识别码，包括：
    所述第一设备向所述第二设备发送第三消息，所述第三消息用于配置所述第一身份识别码。
  9. 根据权利要求7所述的方法，其特征在于，所述第一设备与所述第二设备协商第一身份识别码，包括：
    所述第一设备向所述第二设备发送第四消息，所述第四消息用于指示所述第二设备返回所述第一身份识别码。
  10. 根据权利要求9所述的方法，其特征在于，所述第四消息携带指示所述第一设备不具有身份识别码的信息，
    所述方法还包括：
    所述第一设备接收所述第二设备返回的所述第一身份识别码。
  11. 根据权利要求10所述的方法，其特征在于，所述第二设备返回的所述第一身份识别码显示在所述第二设备的显示屏上。
  12. 根据权利要求9-11中任一项所述的方法，其特征在于，所述第二设备返回的所述第一身份识别码为临时身份识别码。
  13. 根据权利要求1-12中任一项所述的方法，其特征在于，在所述第一设备根据sigma协议与第二设备协商共享密钥之前，所述方法还包括：
    所述第一设备与所述第二设备协商所述共享密钥的协商方式。
  14. 根据权利要求13所述的方法，其特征在于，所述第一设备与所述第二设备协商所述共享密钥的协商方式，包括：
    所述第一设备向所述第二设备发送第五消息，所述第五消息用于指示所述第一设备支持的密钥协商方式；
    所述第一设备从所述第二设备接收第五响应，所述第五响应用于指示基于sigma协议协商所述共享密钥。
  15. 根据权利要求14所述的方法，其特征在于，所述第一设备和/或所述第二设备支持的密钥协商方式包括以下方式中的一种或多种：基于密钥对协商，基于节点互操作证书协商，以及基于sigma协议协商。
  16. 根据权利要求1-15中任一项所述的方法，其特征在于，所述共享密钥是所述第一设备根据以下信息中的一种或多种生成的：第一密钥、所述第一设备生成的随机数、以及所述第一设备的临时公钥，其中，所述第一密钥是所述第一设备根据所述第二设备的临时公钥和所述第一设备的临时私钥生成的。
  17. 一种建立互操作通道的方法，其特征在于，包括：
    第二设备根据sigma协议与第一设备协商共享密钥；
    所述第二设备与所述第一设备建立基于所述共享密钥的互操作通道；
    所述第二设备通过所述互操作通道接收所述第一设备的控制指令；
    其中，所述第一设备为终端设备，所述第二设备为车设备。
  18. 根据权利要求17所述的方法，其特征在于，所述第二设备根据sigma协议与第一设备协商共享密钥，包括：
    所述第二设备接收所述第一设备发送的第一消息，所述第一消息包含第一数据，所述第一数据包含所述第一设备的临时公钥；
    所述第二设备根据所述第一设备的临时公钥和所述第二设备的临时私钥，生成所述共享密钥；
    所述第二设备向所述第一设备发送第二消息，所述第二消息包含第二数据，所述第二数据包含所述第二设备的临时公钥，所述第二设备的临时公钥用于所述第一设备生成所述共享密钥。
  19. 根据权利要求18所述的方法，其特征在于：
    所述第一数据还包含以下信息中的一种或多种：所述第一设备的会话标识、所述第一设备生成的随机数；和/或
    所述第二数据还包含以下信息中的一种或多种：所述第二设备的会话标识、所述第二设备生成的随机数。
  20. 根据权利要求18或19所述的方法，其特征在于，在所述第二设备接收所述第一设备发送的第一消息之后，所述方法还包括：
    所述第二设备根据所述第一设备的身份识别码对所述第一数据进行解密。
  21. 根据权利要求18所述的方法，其特征在于，所述第一数据还包含第一目的标识，所述第一目的标识用于所述第二设备校验所述第一设备的身份。
  22. 根据权利要求21所述的方法，其特征在于，所述第一目的标识是所述第一设备根据所述第一设备的身份识别码对第一信息进行加密得到的，所述第一信息包括以下信息中的一种或多种：所述第一设备生成的随机数、所述第二设备的设备标识、以及所述第一设备的设备认证中心CA证书对应的公钥。
  23. 根据权利要求22所述的方法，其特征在于，在所述第二设备接收所述第一设备发送的第一消息之后，所述方法还包括：
    所述第二设备根据所述第一设备的身份识别码对所述第一信息进行加密，得到第二目的标识；
    所述第二设备根据所述第一目的标识和所述第二目的标识，校验所述第一设备的身份。
  24. 根据权利要求20、22-23中任一项所述的方法，其特征在于，所述方法还包括：
    所述第二设备与所述第一设备协商第一身份识别码，所述第一身份识别码用于所述第一身份识别码对应的设备访问所述第二设备。
  25. 根据权利要求24所述的方法，其特征在于，所述第二设备与所述第一设备协商第一身份识别码，包括：
    所述第二设备接收所述第一设备发送的第三消息，所述第三消息用于配置所述第一身份识别码。
  26. 根据权利要求24所述的方法，其特征在于，所述第二设备与所述第一设备协商第一身份识别码，包括：
    所述第二设备接收所述第一设备发送的第四消息，所述第四消息用于指示所述第二设备返回所述第一身份识别码。
  27. 根据权利要求26所述的方法，其特征在于，所述第四消息携带指示所述第一设备不具有身份识别码的信息，
    所述方法还包括：
    所述第二设备为所述第一设备返回所述第一身份识别码。
  28. 根据权利要求27所述的方法，其特征在于，所述第二设备返回的所述第一身份识别码显示在所述第二设备的显示屏上。
  29. 根据权利要求26-28中任一项所述的方法，其特征在于，所述第二设备返回的所述第一身份识别码为临时身份识别码。
  30. 根据权利要求17-29中任一项所述的方法，其特征在于，在所述第二设备根据sigma协议与第一设备协商共享密钥之前，所述方法还包括：
    所述第二设备与所述第一设备协商所述共享密钥的协商方式。
  31. 根据权利要求30所述的方法，其特征在于，所述第二设备与所述第一设备协商所述共享密钥的协商方式，包括：
    所述第二设备接收所述第一设备发送的第五消息，所述第五消息用于指示所述第一设备支持的密钥协商方式；
    所述第二设备向所述第一设备发送第五响应，所述第五响应用于指示基于sigma协议协商所述共享密钥。
  32. 根据权利要求31所述的方法，其特征在于，所述第一设备和/或所述第二设备支持的密钥协商方式包括以下方式中的一种或多种：基于密钥对协商，基于节点互操作证书协商，以及基于sigma协议协商。
  33. 根据权利要求17-32中任一项所述的方法，其特征在于，所述共享密钥是所述第二设备根据以下信息中的一种或多种生成的：第二密钥、所述第二设备生成的随机数、以及所述第二设备的临时公钥，其中，所述第二密钥是所述第二设备根据所述第一设备的临时公钥和所述第二设备的临时私钥生成的。
  34. 一种建立互操作通道的装置，其特征在于，所述装置配置于第一设备，所述装置包括：
    第一协商模块，用于根据sigma协议与第二设备协商共享密钥；
    建立模块，用于与所述第二设备建立基于所述共享密钥的互操作通道；
    控制模块，用于通过所述互操作通道向所述第二设备发送控制指令，以对所述第二设备进行控制；
    其中，所述第一设备为终端设备，所述第二设备为车设备。
  35. 根据权利要求34所述的装置，其特征在于，所述第一协商模块进一步包括：
    第一发送模块，用于向所述第二设备发送第一消息，所述第一消息包含第一数据，所述第一数据包含所述第一设备的临时公钥，所述第一设备的临时公钥用于所述第二设备生成所述共享密钥；
    第一接收模块，用于从所述第二设备接收第二消息，所述第二消息包含第二数据，所述第二数据包含所述第二设备的临时公钥；
    生成模块，用于根据所述第二设备的临时公钥和所述第一设备的临时私钥，生成所述共享密钥。
  36. 根据权利要求35所述的装置，其特征在于：
    所述第一数据还包含以下信息中的一种或多种：所述第一设备的会话标识、所述第一设备生成的随机数；和/或
    所述第二数据还包含以下信息中的一种或多种：所述第二设备的会话标识、所述第二设备生成的随机数。
  37. 根据权利要求35或36所述的装置，其特征在于，所述装置还包括：
    加密模块，用于根据所述第一设备的身份识别码对所述第一数据进行加密。
  38. 根据权利要求35所述的装置，其特征在于，所述第一数据还包含第一目的标识，所述第一目的标识用于所述第二设备校验所述第一设备的身份。
  39. 根据权利要求38所述的装置，其特征在于，所述第一目的标识是所述第一设备根据所述第一设备的身份识别码对第一信息进行加密得到的，所述第一信息包括以下信息中的一种或多种：所述第一设备生成的随机数、所述第二设备的设备标识、以及所述第一设备的设备认证中心CA证书对应的公钥。
  40. 根据权利要求37或39所述的装置，其特征在于，所述装置还包括：
    第二协商模块，用于与所述第二设备协商第一身份识别码，所述第一身份识别码用于所述第一身份识别码对应的设备访问所述第二设备。
  41. 根据权利要求40所述的装置，其特征在于，所述第二协商模块进一步包括：
    第二发送模块，用于向所述第二设备发送第三消息，所述第三消息用于配置所述第一身份识别码。
  42. 根据权利要求40所述的装置，其特征在于，所述第二协商模块进一步包括：
    第三发送模块，用于向所述第二设备发送第四消息，所述第四消息用于指示所述第二设备返回所述第一身份识别码。
  43. 根据权利要求42所述的装置，其特征在于，所述第四消息携带指示所述第一设备不具有身份 识别码的信息，
    所述装置还包括：
    第二接收模块，用于接收所述第二设备返回的所述第一身份识别码。
  44. 根据权利要求43所述的装置，其特征在于，所述第二设备返回的所述第一身份识别码显示在所述第二设备的显示屏上。
  45. 根据权利要求42-44中任一项所述的装置，其特征在于，所述第二设备返回的所述第一身份识别码为临时身份识别码。
  46. 根据权利要求34-45中任一项所述的装置，其特征在于，所述装置还包括：
    第三协商模块，用于与所述第二设备协商所述共享密钥的协商方式。
  47. 根据权利要求46所述的装置，其特征在于，所述第三协商模块进一步包括：
    第四发送模块，用于向所述第二设备发送第五消息，所述第五消息用于指示所述第一设备支持的密钥协商方式；
    第三接收模块，用于从所述第二设备接收第五响应，所述第五响应用于指示基于sigma协议协商所述共享密钥。
  48. 根据权利要求47所述的装置，其特征在于，所述第一设备和/或所述第二设备支持的密钥协商方式包括以下方式中的一种或多种：基于密钥对协商，基于节点互操作证书协商，以及基于sigma协议协商。
  49. 根据权利要求34-48中任一项所述的装置，其特征在于，所述共享密钥是所述第一设备根据以下信息中的一种或多种生成的：第一密钥、所述第一设备生成的随机数、以及所述第一设备的临时公钥，其中，所述第一密钥是所述第一设备根据所述第二设备的临时公钥和所述第一设备的临时私钥生成的。
  50. 一种建立互操作通道的装置，其特征在于，所述装置配置于第二设备，所述装置包括：
    第一协商模块，用于根据sigma协议与第一设备协商共享密钥；
    建立模块，用于与所述第一设备建立基于所述共享密钥的互操作通道；
    第一接收模块，用于通过所述互操作通道接收所述第一设备的控制指令；
    其中，所述第一设备为终端设备，所述第二设备为车设备。
  51. 根据权利要求50所述的装置，其特征在于，所述第一协商模块进一步包括：
    第二接收模块，用于接收所述第一设备发送的第一消息，所述第一消息包含第一数据，所述第一数据包含所述第一设备的临时公钥；
    生成模块，用于根据所述第一设备的临时公钥和所述第二设备的临时私钥，生成所述共享密钥；
    第一发送模块，用于向所述第一设备发送第二消息，所述第二消息包含第二数据，所述第二数据包含所述第二设备的临时公钥，所述第二设备的临时公钥用于所述第一设备生成所述共享密钥。
  52. 根据权利要求51所述的装置，其特征在于：
    所述第一数据还包含以下信息中的一种或多种：所述第一设备的会话标识、所述第一设备生成的随机数；和/或
    所述第二数据还包含以下信息中的一种或多种：所述第二设备的会话标识、所述第二设备生成的随机数。
  53. 根据权利要求51或52所述的装置，其特征在于，所述装置还包括：
    解密模块，用于根据所述第一设备的身份识别码对所述第一数据进行解密。
  54. 根据权利要求51所述的装置，其特征在于，所述第一数据还包含第一目的标识，所述第一目的标识用于所述第二设备校验所述第一设备的身份。
  55. 根据权利要求54所述的装置，其特征在于，所述第一目的标识是所述第一设备根据所述第一设备的身份识别码对第一信息进行加密得到的，所述第一信息包括以下信息中的一种或多种：所述第一设备生成的随机数、所述第二设备的设备标识、以及所述第一设备的设备认证中心CA证书对应的公钥。
  56. 根据权利要求55所述的装置，其特征在于，所述装置还包括：
    加密模块，用于根据所述第一设备的身份识别码对所述第一信息进行加密，得到第二目的标识；
    校验模块，用于根据所述第一目的标识和所述第二目的标识，校验所述第一设备的身份。
  57. 根据权利要求53、55-56中任一项所述的装置，其特征在于，所述装置还包括：
    第二协商模块，用于与所述第一设备协商第一身份识别码，所述第一身份识别码用于所述第一身份识别码对应的设备访问所述第二设备。
  58. 根据权利要求57所述的装置，其特征在于，所述第二协商模块进一步包括：
    第三接收模块，用于接收所述第一设备发送的第三消息，所述第三消息用于配置所述第一身份识别 码。
  59. 根据权利要求58所述的装置，其特征在于，所述第二协商模块进一步包括：
    第四接收模块，用于接收所述第一设备发送的第四消息，所述第四消息用于指示所述第二设备返回所述第一身份识别码。
  60. 根据权利要求59所述的装置，其特征在于，所述第四消息携带指示所述第一设备不具有身份识别码的信息，
    所述装置还包括：
    返回模块，用于为所述第一设备返回所述第一身份识别码。
  61. 根据权利要求60所述的装置，其特征在于，所述第二设备返回的所述第一身份识别码显示在所述第二设备的显示屏上。
  62. 根据权利要求59-61中任一项所述的装置，其特征在于，所述第二设备返回的所述第一身份识别码为临时身份识别码。
  63. 根据权利要求50-62中任一项所述的装置，其特征在于，所述装置还包括：
    第三协商模块，用于与所述第一设备协商所述共享密钥的协商方式。
  64. 根据权利要求63所述的装置，其特征在于，所述第三协商模块进一步包括：
    第五接收模块，用于接收所述第一设备发送的第五消息，所述第五消息用于指示所述第一设备支持的密钥协商方式；
    第二发送模块，用于向所述第一设备发送第五响应，所述第五响应用于指示基于sigma协议协商所述共享密钥。
  65. 根据权利要求64所述的装置，其特征在于，所述第一设备和/或所述第二设备支持的密钥协商方式包括以下方式中的一种或多种：基于密钥对协商，基于节点互操作证书协商，以及基于sigma协议协商。
  66. 根据权利要求50-65中任一项所述的装置，其特征在于，所述共享密钥是所述第二设备根据以下信息中的一种或多种生成的：第二密钥、所述第二设备生成的随机数、以及所述第二设备的临时公钥，其中，所述第二密钥是所述第二设备根据所述第一设备的临时公钥和所述第二设备的临时私钥生成的。
  67. 一种通信装置，其特征在于，所述通信装置配置于第一设备，所述装置包括存储器和处理器，所述存储器用于存储程序，所述处理器用于调用所述存储器中的程序，以使所述第一设备执行如权利要求1-16中任一项所述的方法。
  68. 一种通信装置，其特征在于，所述通信装置配置于第二设备，所述装置包括存储器和处理器，所述存储器用于存储程序，所述处理器用于调用所述存储器中的程序，以使所述第二设备执行如权利要求17-33中任一项所述的方法。
  69. 一种装置，其特征在于，包括处理器，用于从存储器中调用程序，以使所述装置执行如权利要求1-33中任一项所述的方法。
  70. 一种芯片，其特征在于，包括处理器，用于从存储器调用程序，使得安装有所述芯片的设备执行如权利要求1-33中任一项所述的方法。
  71. 一种计算机可读存储介质，其特征在于，其上存储有程序，所述程序使得计算机执行如权利要求1-33中任一项所述的方法。
  72. 一种计算机程序产品，其特征在于，包括程序，所述程序使得计算机执行如权利要求1-33中任一项所述的方法。
  73. 一种计算机程序，其特征在于，所述计算机程序使得计算机执行如权利要求1-33中任一项所述的方法。
PCT/CN2022/096777 2022-06-02 2022-06-02 建立互操作通道的方法、装置、芯片和存储介质 WO2023230975A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/096777 WO2023230975A1 (zh) 2022-06-02 2022-06-02 建立互操作通道的方法、装置、芯片和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/096777 WO2023230975A1 (zh) 2022-06-02 2022-06-02 建立互操作通道的方法、装置、芯片和存储介质

Publications (1)

Publication Number Publication Date
WO2023230975A1 true WO2023230975A1 (zh) 2023-12-07

Family

ID=89026764

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/096777 WO2023230975A1 (zh) 2022-06-02 2022-06-02 建立互操作通道的方法、装置、芯片和存储介质

Country Status (1)

Country Link
WO (1) WO2023230975A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150372811A1 (en) * 2014-06-18 2015-12-24 Eric Le Saint Efficient methods for authenticated communication
CN107040369A (zh) * 2016-10-26 2017-08-11 阿里巴巴集团控股有限公司 数据传输方法、装置及***
CN109245900A (zh) * 2018-09-14 2019-01-18 北京清大智信科技有限公司 一种毫米级超微型计算机安全交互方法及***
CN112600668A (zh) * 2020-12-15 2021-04-02 上海银基信息安全技术股份有限公司 密钥协商方法、装置、电子设备和存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150372811A1 (en) * 2014-06-18 2015-12-24 Eric Le Saint Efficient methods for authenticated communication
CN107040369A (zh) * 2016-10-26 2017-08-11 阿里巴巴集团控股有限公司 数据传输方法、装置及***
CN109245900A (zh) * 2018-09-14 2019-01-18 北京清大智信科技有限公司 一种毫米级超微型计算机安全交互方法及***
CN112600668A (zh) * 2020-12-15 2021-04-02 上海银基信息安全技术股份有限公司 密钥协商方法、装置、电子设备和存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUAWEI, HISILICON: "Introduce D-H algorithm negotiation method in Solution #3.1", 3GPP TSG SA WG3 (SECURITY) MEETING #85 S3-161668, 31 October 2016 (2016-10-31), XP051170540 *

Similar Documents

Publication Publication Date Title
US11736304B2 (en) Secure authentication of remote equipment
US20140244723A1 (en) Systems and methods for cross-layer secure connection set up
CN110235424A (zh) 用于在通信***中提供和管理安全信息的设备和方法
JP2016540462A (ja) 鍵コンフィギュレーション方法、システム、および装置
WO2022140903A1 (zh) 一种ota升级方法及装置
JP2008042882A (ja) Ｗｐａ−ｐｓｋ環境の無線ネットワークでステーションを管理する方法及びその装置
CN109343515A (zh) 车辆故障诊断方法、***、设备及计算机可读存储介质
WO2019051776A1 (zh) 密钥的传输方法及设备
CN112994873B (zh) 一种证书申请方法及设备
WO2022160124A1 (zh) 一种服务授权管理方法及装置
CN112449323A (zh) 一种通信方法、装置和***
WO2019125758A1 (en) Cloud assisted accessory pairing
WO2023001082A1 (zh) 一种配网方法及装置
CN113301537B (zh) 用于建立通信连接的方法、装置、电子设备以及存储介质
CN112448808A (zh) 通信方法、设备、接入点、服务器、***及存储介质
WO2023279283A1 (zh) 建立车辆安全通信的方法、车辆、终端及***
CN114245375B (zh) 一种密钥跨设备分发方法及电子设备
WO2022041151A1 (zh) 设备验证方法、设备和云端
WO2023230975A1 (zh) 建立互操作通道的方法、装置、芯片和存储介质
WO2023230979A1 (zh) 建立互操作通道的方法、装置、芯片和存储介质
WO2023230983A1 (zh) 建立互操作通道的方法、装置、芯片和存储介质
CN113455032B (zh) 通信方法、通信装置及计算机可读介质
EP4184857A1 (en) Bluetooth node pairing method and related apparatus
US12009979B2 (en) Secure and adaptive mechanism to provision zero- touch network devices
WO2022204888A1 (zh) 一种配对方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22944306

Country of ref document: EP

Kind code of ref document: A1