WO2022016426A1 - 一种跨平台的设备配网方法及装置、电子设备 - Google Patents

一种跨平台的设备配网方法及装置、电子设备 Download PDF

Info

Publication number
WO2022016426A1
WO2022016426A1 PCT/CN2020/103590 CN2020103590W WO2022016426A1 WO 2022016426 A1 WO2022016426 A1 WO 2022016426A1 CN 2020103590 W CN2020103590 W CN 2020103590W WO 2022016426 A1 WO2022016426 A1 WO 2022016426A1
Authority
WO
WIPO (PCT)
Prior art keywords
installation code
gateway
target device
platform
confirmation value
Prior art date
Application number
PCT/CN2020/103590
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/CN2020/103590 priority Critical patent/WO2022016426A1/zh
Priority to CN202080100270.3A priority patent/CN115462105A/zh
Publication of WO2022016426A1 publication Critical patent/WO2022016426A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the embodiments of the present application relate to the technical field of the Internet of Things, and in particular, to a cross-platform device network distribution method and device, and an electronic device.
  • the Bluetooth mesh device If the Bluetooth mesh device is in an unconfigured state after being powered on, it needs to send a broadcast packet, so that the gateway can discover the Bluetooth mesh device through the broadcast packet.
  • the Bluetooth Mesh device and the gateway do not belong to the same manufacturer, it is necessary to configure the Bluetooth Mesh device in a cross-platform manner.
  • the broadcast packets of the Bluetooth Mesh devices are public information, any gateway within a certain range can monitor the broadcast packets, which will cause great problems. Security Risk.
  • Embodiments of the present application provide a cross-platform device network distribution method and device, and an electronic device.
  • the gateway receives the first confirmation value sent by the second platform cloud through the first platform cloud, and sends the first confirmation value to the target device for verification, wherein the first confirmation value is installed by the second platform cloud based on the installation
  • the code is calculated and obtained, and the installation code is dynamically generated or input by the user;
  • the gateway receives the second confirmation value sent by the target device, and sends the second confirmation value to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is sent by the The target device is calculated based on the installation code.
  • the second platform cloud sends a first confirmation value to the gateway through the first platform cloud, and the first confirmation value is forwarded by the gateway to the target device for verification, wherein the first confirmation value is sent by the second platform cloud Calculated based on the installation code, the installation code is dynamically generated or input by the user;
  • the second platform cloud verifies the second confirmation value based on the installation code.
  • the target device sends a second confirmation value to the gateway, and the second confirmation value is forwarded by the gateway to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is determined by the target device based on the installation code Calculated, the installation code is dynamically generated or input by the user;
  • the target device verifies the first confirmation value based on the installation code.
  • the cross-platform device network distribution device provided by the embodiment of the present application is applied to a gateway, and the device includes:
  • a receiving unit configured to receive the first confirmation value sent by the second platform cloud through the first platform cloud
  • a sending unit configured to send the first confirmation value to the target device for verification, wherein the first confirmation value is calculated by the second platform cloud based on an installation code, and the installation code is dynamically generated or user input;
  • the receiving unit is further configured to receive the second confirmation value sent by the target device
  • the sending unit is further configured to send the second confirmation value to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is determined by the target device based on the The installation code is calculated.
  • the cross-platform device network distribution device provided by the embodiment of the present application is applied to the second platform cloud, and the device includes:
  • a sending unit configured to send a first confirmation value to the gateway through the first platform cloud, the first confirmation value is forwarded by the gateway to the target device for verification, wherein the first confirmation value is sent by the second platform
  • the cloud is calculated based on the installation code, and the installation code is dynamically generated or input by the user
  • a receiving unit configured to receive a second confirmation value sent by the gateway through the first platform cloud, wherein the second confirmation value is calculated by the target device based on the installation code
  • a verification unit configured to verify the second confirmation value based on the installation code.
  • the cross-platform device network distribution device provided by the embodiment of the present application is applied to a target device, and the device includes:
  • a sending unit configured to send a second confirmation value to the gateway, where the second confirmation value is forwarded by the gateway to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is sent by the target device Calculated based on the installation code, the installation code is dynamically generated or input by the user;
  • a receiving unit configured to receive a first confirmation value sent by the gateway, wherein the first confirmation value is calculated by the second platform cloud based on the installation code
  • a verification unit configured to verify the first confirmation value.
  • the electronic device provided by the embodiments of the present application includes a processor and a memory.
  • the memory is used to store a computer program
  • the processor is used to call and run the computer program stored in the memory to execute the above-mentioned cross-platform device network configuration method.
  • the storage medium provided by the embodiment of the present application is used to store a computer program, and the computer program enables a computer to execute the above-mentioned cross-platform device network configuration method.
  • the second platform cloud calculates the first confirmation value based on the dynamically generated installation code, and the target device verifies the first confirmation value based on the installation code; similarly, the target device calculates the first confirmation value based on the dynamically generated installation code Second confirmation value, the second platform cloud verifies the second confirmation value based on the installation code.
  • the target device refers to the Bluetooth Mesh device. In this way, the user can control the distribution network of his own Bluetooth Mesh device, which prevents the user's Bluetooth Mesh device from being illegally or incorrectly bound by other users, and improves the security of cross-platform Bluetooth Mesh device distribution network. sex.
  • FIG. 1 is a schematic flowchart of communication between a client device and a server device provided by an embodiment of the present application
  • Fig. 2 is the verification flow chart between the Bluetooth Mesh network distribution device provided by the embodiment of the present application and the Bluetooth Mesh device to be distributed (ie, a new device);
  • 3 is a flow chart of network distribution of cross-platform Bluetooth Mesh devices provided by an embodiment of the present application.
  • FIG. 4 is a schematic flowchart 1 of a cross-platform device network distribution method provided by an embodiment of the present application.
  • FIG. 5 is a second schematic flowchart of a cross-platform device network distribution method provided by an embodiment of the present application.
  • FIG. 6 is a schematic flowchart 3 of a cross-platform device network distribution method provided by an embodiment of the present application.
  • FIG. 7 is a fourth schematic flowchart of a cross-platform device network distribution method provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram 1 of the structure and composition of a cross-platform device network distribution device provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram 2 of the structure and composition of the cross-platform device network distribution device provided by the embodiment of the present application.
  • FIG. 10 is a schematic diagram 3 of the structure of the cross-platform device network distribution device provided by the embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a hardware composition of an electronic device according to an embodiment of the present invention.
  • the Open Connectivity Foundation (OCF, Open Connectivity Foundation) is an emerging IoT application layer technology standards organization.
  • OCF formulates a Restful service framework for interconnection between IoT devices.
  • information such as IoT devices, functional services of OCF devices, and status of OCF devices are represented by resources.
  • the entity that provides the resource is an OCF server device (hereinafter referred to as the server device), and the entity that accesses the resource is the OCF client (hereinafter referred to as the client device).
  • the business interaction between the client device and the server device is realized through resource operation methods such as creating, reading, updating, deleting or notifying resources.
  • the communication process between the client device and the server device is shown in Figure 1: the client device sends an update resource request for the resources on the server device to the server device.
  • the server device performs a corresponding resource operation according to the update resource request, and sends an update resource response to the client device, wherein the update resource response carries an expression of the resource.
  • the resource update request carries a uniform resource identifier (Uniform Resource Identifier, URI) of the resource and a resource operation method.
  • URI Uniform Resource Identifier
  • the resource representation includes: resource URI, resource type, resource interface, and resource function attributes, etc. The following describes the information included in the resource representation:
  • the URI of the resource represented by "href” in the resource description, provides the address of the resource of the OCF server device.
  • the value of "href” is the URI of the specific resource.
  • the OCF client device accesses the OCF server device through the URI of the resource. Resources.
  • the resource type represented by "rt" in the representation of the resource, indicates the type of the resource.
  • the resource interface represented by "if” in the representation of the resource, provides the view of the resource and the response of the resource support.
  • Resource attributes describe the attribute information of resources in the representation of resources.
  • OCF defines the resource discovery resource "/oic/res" that all OCF devices must support.
  • the resource discovery resource is used for OCF device and resource discovery; the resource discovery resource provides the function of device resource discovery, and the URI of the resource discovery resource is fixed as " /oic/res”.
  • Resource links include:
  • Context URI indicating the URI of the owner resource that contains the resource link.
  • Target URI that is, the URI of the target resource referenced in the resource link.
  • eps Endpoints that can access the target resource.
  • each OCF server device needs to have an endpoint, and each OCF device must be associated with at least one endpoint for sending and receiving messages;
  • the client device can access the target resource of the server device through the endpoint.
  • the "eps" array is used to represent the endpoint of the target resource, and the specific endpoint is represented by "ep", that is, the target resource can be accessed through the address of the "ep" value in the "eps" parameter.
  • Bluetooth Mesh Network A mesh device network based on Bluetooth low energy technology, which can realize many-to-many Bluetooth device communication.
  • Gateway Bluetooth Mesh network configuration device, responsible for configuring devices connected to the Bluetooth Mesh network.
  • the Bluetooth Mesh device to be configured needs to join the Bluetooth Mesh network through the Bluetooth Mesh configuration process.
  • the Bluetooth Mesh device After the Bluetooth Mesh device is powered on, if it is in an unconfigured state, it needs to send a broadcast packet, that is, broadcast an Unprovisioned Device Beacon packet.
  • the broadcast packet carries the Universal Unique Identifier (UUID) of the Bluetooth Mesh device, which is referred to as Device UUID (Device UUID).
  • Device UUID is the key information for identifying Bluetooth Mesh devices.
  • the format of Device UUID is shown in Table 1 below:
  • the authentication method of Bluetooth Mesh devices adopts the static out-of-band (Static Out of Band, Static OOB) authentication method specified in the Bluetooth Mesh protocol or no out-of-band (No Out of Band, No OOB) authentication method. )Ways of identifying.
  • the static OOB verification method is: calculating the confirmation value based on the static OOB information (ie Provisiong Confirmation).
  • No OOB verification method directly replace the OOB information with the value 0 to calculate the confirmation value.
  • the network configuration process of the Bluetooth Mesh device can be completed without the need for the user to input the authorization value (AuthValue) and other user confirmation operations during the network configuration process.
  • AuthValue authorization value
  • the verification process between the Bluetooth Mesh configuration network device and the Bluetooth Mesh device to be deployed includes the following steps:
  • Step 201 The Bluetooth Mesh network configuration device sends a first confirmation value to the Bluetooth Mesh device to be configured.
  • the Bluetooth Mesh configuration network device calculates the first confirmation value based on the static OOB information.
  • the Bluetooth Mesh configuration network device uses the value 0 to replace the OOB information to calculate the first confirmation value.
  • Step 202 The Bluetooth Mesh device to be configured sends a second confirmation value to the Bluetooth Mesh configuration device.
  • the Bluetooth Mesh device to be deployed on the network calculates the second confirmation value based on the static OOB information.
  • the Bluetooth Mesh device to be configured replaces the OOB information with a value of 0 to calculate the second confirmation value.
  • Step 203 The Bluetooth Mesh network configuration device sends a first random number to the Bluetooth Mesh device to be configured.
  • the Bluetooth Mesh distribution network device calculates the first confirmation value, it will use the first random number.
  • Step 204 The Bluetooth Mesh device to be configured verifies the first confirmation value based on the first random number.
  • Step 205 The Bluetooth Mesh device to be configured sends a second random number to the Bluetooth Mesh configuration device.
  • the Bluetooth Mesh device to be deployed on the network calculates the second confirmation value
  • the second random number will be used.
  • Step 206 The Bluetooth Mesh distribution network device verifies the second confirmation value based on the second random number.
  • the Bluetooth Mesh network configuration device can be implemented through a gateway, and the Bluetooth Mesh device to be configured can also be referred to as a device for short.
  • the cross-platform Bluetooth Mesh device configuration process is shown in Figure 3. , including the following steps:
  • Step 301 The user activates the device scanning function of the A platform gateway through voice or APP.
  • Step 302 The equipment of company E sends broadcast packets (including UUID and CID) according to the specification.
  • the device of company E refers to the device developed by company E based on platform B, which belongs to the Bluetooth Mesh device to be distributed.
  • the broadcast packet refers to the Bluetooth Mesh unconfigured broadcast packet, which carries the UUID of the device of E company and the CID of the B platform.
  • Step 303 Platform A sends a device type query message (including UUID and CID) to Platform A cloud.
  • a device type query message including UUID and CID
  • the gateway of platform A sends the UUID of the device of company E and the CID of platform B to the cloud of platform A through the query device type message, and queries the device of the device of company E through the cloud of platform A. type.
  • Step 303.1 Based on the CID, the A platform cloud determines whether the device of the E company is a device of the A platform, if not, step 303.2 is performed.
  • the cloud of platform A determines whether the device of company E is a device developed based on platform A through the CID in the device type query message (that is, whether the device of company E belongs to platform A or not). equipment).
  • Step 303.2 A platform cloud queries the interconnection server for platform information corresponding to the equipment of E company.
  • the A platform cloud determines that the device of the company E is not a device developed based on the platform A, other platforms (that is, the platform that develops the device of the company E) are required for authorization.
  • platform A obtains the information of platform B corresponding to the CID through the interconnection server (including information such as the authentication server (Auth Server) of platform B).
  • Auth Server authentication server
  • a platform cloud queries the interconnection server for the platform information corresponding to the equipment of E company, it provides the CID to the interconnection server, so that the interconnection server can query the information of the B platform through the CID.
  • Step 303.3 The interconnection server sends the information of the B platform to the A platform cloud.
  • Step 303.4 A platform cloud sends a query device type message (including the information of B platform, CID and UUID) to B platform cloud.
  • the query device type message is used to query the device type of the device of the E company.
  • Step 303.5 The B platform cloud sends the device type information to the A platform cloud.
  • the device type information is used to determine the device type of the E company device.
  • Step 304 The A platform cloud sends the device type information to the A platform gateway.
  • Step 305 A platform gateway broadcasts device type information.
  • Step 306 The user performs an input operation on the platform A gateway to operate the platform A gateway to connect the device of the company E.
  • Step 307 The platform A gateway sends a provisioning invitation (Provisioning Invite) message to the device of company E.
  • Provisioning Invite Provisioning Invite
  • Step 308 The device of the E company sends a provisioning capability (Provisioning Capabilities) message to the A platform gateway.
  • Provisioning Capabilities Provisioning Capabilities
  • Step 309 The platform A gateway sends a provisioning start (Provisioning Start) message to the device of company E.
  • Step 310 The gateway of platform A and the device of company E complete the public key (Public Key) exchange through platform A cloud and platform B cloud.
  • Step 311 Platform B cloud calculates the first confirmation value.
  • the B platform cloud calculates the first confirmation value according to the static OOB information or no OBB information.
  • the first confirmation value is calculated based on the first random number.
  • Step 312 The platform cloud B sends the authentication information (including the first confirmation value and the first random number) to the platform cloud A.
  • Step 313 The platform A cloud sends authentication information (including the first confirmation value and the first random number) to the platform A gateway.
  • Step 314 The platform A gateway sends the first confirmation value to the device of the company E.
  • Step 315 The device of company E sends the second confirmation value to the gateway of platform A.
  • the device of company E calculates the second confirmation value according to static OOB information or no OBB information.
  • the second confirmation value is calculated based on the second random number.
  • Step 316 The platform A gateway sends the first random number to the device of the company E.
  • Step 317 The device of E company verifies the first confirmation value based on the first random number.
  • Step 318 The device of company E sends the second random number to the gateway of platform A.
  • Step 319 the A platform network sends the device authentication information (including the second confirmation value and the second random number) to the A platform cloud.
  • Step 320 The A platform cloud sends the device authentication information (including the second confirmation value and the second random number) to the B platform cloud.
  • Step 321 The B platform cloud verifies the second confirmation value based on the second random number.
  • Step 322 the B platform cloud sends the authentication result (including the device information of the E company's device) to the A platform cloud.
  • Step 323 Platform A cloud stores the device information of the device of E company.
  • the device information includes information such as control functions and control commands supported by the device.
  • Step 324 The A platform cloud sends the authentication result to the A platform gateway.
  • Step 325 The platform A gateway sends configuration data to the equipment of company E.
  • Step 326 The platform A gateway broadcasts the authentication result.
  • the device of company E officially becomes the node of the Bluetooth Mesh network, and the configuration process is completed.
  • the calculation of the first confirmation value or the second confirmation value is based on static OOB information or no OOB information, that is to say, the verification method between the B platform cloud and the E company's equipment is the static OOB verification method Or no OOB authentication method. Since the broadcast packet of the device of E company is public information, any gateway within the scanning distance can monitor the broadcast packet. If the static OOB verification method or no OOB verification method is adopted, it may happen that the device of user A's company E is blocked by the gateway of user B. Bind the distribution network, so that user B can control the device of user A's company E, but user A cannot control it himself, and there is a great security risk (for example, devices such as door locks and cameras are bound by non-owner devices).
  • the technical solution of the embodiments of the present application proposes a cross-platform Bluetooth Mesh device network distribution method (referred to as a cross-platform device network distribution method), in which a dynamic OOB verification method needs to be adopted during the network distribution process, that is, a user operation is required to input an installation code Only then can the network distribution of Bluetooth Mesh devices be realized.
  • a cross-platform device network distribution method a cross-platform Bluetooth Mesh device network distribution method
  • a dynamic OOB verification method needs to be adopted during the network distribution process, that is, a user operation is required to input an installation code Only then can the network distribution of Bluetooth Mesh devices be realized.
  • FIG. 4 is a schematic flowchart 1 of a cross-platform device network distribution method provided by an embodiment of the present application. As shown in FIG. 4 , the cross-platform device network distribution method includes the following steps:
  • Step 401 The gateway receives the first confirmation value sent by the second platform cloud through the first platform cloud, and sends the first confirmation value to the target device for verification, wherein the first confirmation value is sent by the second platform
  • the cloud is calculated based on the installation code, which is dynamically generated or input by the user.
  • the gateway refers to the gateway of the first platform, that is, the gateway can directly communicate with the cloud of the first platform.
  • the communication between the gateway and the second platform cloud needs to be forwarded through the first platform cloud.
  • the gateway may also be referred to as a Bluetooth Mesh network configuration device, and the target device may also be referred to as a Bluetooth Mesh device to be configured.
  • the gateway before the gateway receives the first confirmation value sent by the second platform cloud through the first platform cloud, the gateway sends the installation code to the second platform cloud through the first platform cloud, wherein, the installation code is used for the second platform cloud to calculate the first confirmation value.
  • the first confirmation value is calculated by the second platform cloud based on an installation code and a first random number, where the first random number is generated by the second platform cloud.
  • the gateway receives the first random number sent by the second platform cloud through the first platform cloud; A random number is sent to the target device, wherein the first random number and the installation code are used by the target device to verify the first confirmation value.
  • the calculation of the first confirmation value may be as follows:
  • ConfirmationProvisioner AES-CMAC ConfirmationKey (RandomProvisioner
  • ConfirmationProvisioner is the first confirmation value
  • RandomProvisioner is the first random number generated by the second platform cloud
  • SetupCode is the installation code
  • the encryption algorithm is AES-CMAC
  • the encryption key is ConfirmationKey.
  • the second platform cloud may calculate the first confirmation value by using other calculation methods.
  • the second platform cloud may also add other parameters to calculate the first confirmation value.
  • the encryption algorithm and calculation parameters used by the target device to verify the first confirmation value need to be the same as the encryption algorithm and calculation parameters used by the second platform cloud to calculate the first confirmation value, so that the network can be successfully distributed.
  • Step 402 The gateway receives the second confirmation value sent by the target device, and sends the second confirmation value to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is Calculated by the target device based on the installation code.
  • the second confirmation value is calculated by the target device based on the installation code and a second random number, and the second random number is generated by the target device.
  • the gateway receives the second random number sent by the target device; the gateway passes the second random number through the first The platform cloud sends to the second platform cloud, wherein the second random number and the installation code are used by the second platform cloud to verify the second confirmation value.
  • the calculation of the second confirmation value may be in the following manner:
  • ConfirmationDevice is the second confirmation value
  • RandomDevice is the second random number generated by the target device
  • SetupCode is the installation code
  • the encryption algorithm is AES-CMAC
  • the encryption key is ConfirmationKey.
  • the target device may calculate the second confirmation value by using other calculation methods.
  • the target device can also add other parameters to calculate the second confirmation value.
  • the encryption algorithm and calculation parameters used by the second platform cloud to verify the second confirmation value need to be the same as the encryption algorithm and calculation parameters used by the target device to calculate the second confirmation value, so that the network can be successfully distributed.
  • the method further includes: a process for the gateway to query the device type of the target device, a process for the gateway and the target device to invite, and a process for the gateway and the target device to exchange public keys.
  • the gateway receives, through the first platform cloud, the device type information of the target device (such as security equipment, smart door locks, etc.) sent by the second platform cloud;
  • the gateway sends an invitation message to the target device
  • the gateway receives the configuration capability message sent by the target device
  • the gateway sends a configuration start message to the target device
  • the gateway exchanges public keys with the target device through the first platform cloud and the second platform cloud;
  • At least one of the device type information, the invitation message and the configuration capability message carries first indication information, and the first indication information is used to indicate that the output out-of-band OOB verification method and/or input OOB authentication mode;
  • the configuration start message carries second indication information, and the second indication information is used to indicate that the OOB authentication mode is determined to be adopted or the OOB authentication mode is input.
  • the method further includes: the gateway determines to adopt an OOB verification method or an input OOB verification method based on at least one of the following: the The device type information of the target device, the first indication information carried in the device type information, and the first indication information carried in the configuration capability message.
  • the installation code is dynamically generated or input by the user.
  • the installation code is dynamically generated.
  • the gateway dynamically generates and outputs the installation code.
  • the target device dynamically generates and outputs the installation code.
  • the installation code is entered by the user.
  • the target device outputs a dynamic or static installation code, and the user inputs the installation code to the gateway after seeing it.
  • the gateway outputs a dynamic or static installation code, and the user inputs the installation code to the target device after seeing it.
  • a static installation code is printed on the manual, and after seeing the installation code on the manual, the user inputs the installation code into the target device or gateway.
  • the technical solutions of the embodiments of the present application are based on the dynamic OOB verification method. Further, there are two dynamic OOB verification methods, one is an output OOB verification method, and the other is an input OOB verification method. These two methods are described below.
  • Mode 1 In the case of the output OOB verification mode, the installation code is output by the target device, and the installation code is input by the user on the gateway.
  • the target device outputs an installation code, which can be a dynamic or static random value, for example, the target device outputs the random value through screen display, sound, flashing, vibration, two-dimensional code, manual, and the like.
  • the user inputs the installation code on the gateway.
  • the gateway has user input devices such as a screen, a microphone, a camera, and a button. The user can input the installation code through the input device to confirm the installation code output by the target device. That is, the user can obtain the installation code through the output of the target device, and input the installation code into the gateway.
  • Mode 2 In the case of the input OOB verification mode, the installation code is output by the gateway, and the installation code is input by the user on the target device.
  • the gateway outputs an installation code, which can be a dynamic or static random value, for example, the gateway outputs the random value through screen display, sound, flashing, vibration, two-dimensional code, manual, and the like.
  • the user inputs the installation code on the target device.
  • the target device has user input devices such as screen, microphone, camera, and buttons.
  • the user can input the installation code through the input device to confirm the installation code output by the gateway. That is, the user can obtain the installation code through the output of the gateway, and input the installation code into the target device.
  • OBB verification methods are also available: a static installation code is printed on the manual, and the user enters the installation code on the target device or gateway after seeing the installation code on the manual.
  • the method further includes: the gateway receives the authentication result sent by the second platform cloud through the first platform cloud, and sends the authentication result sent by the second platform cloud to the gateway.
  • the target device sends configuration data.
  • FIG. 5 is a second schematic flowchart of a cross-platform device network distribution method provided by an embodiment of the present application. As shown in FIG. 5 , the cross-platform device network distribution method includes the following steps:
  • Step 501 The second platform cloud sends a first confirmation value to the gateway through the first platform cloud, and the first confirmation value is forwarded by the gateway to the target device for verification, wherein the first confirmation value is sent by the first confirmation value.
  • the second platform cloud is calculated based on the installation code, and the installation code is dynamically generated or input by the user.
  • the gateway refers to the gateway of the first platform, that is, the gateway can directly communicate with the cloud of the first platform.
  • the communication between the gateway and the second platform cloud needs to be forwarded through the first platform cloud.
  • the gateway may also be referred to as a Bluetooth Mesh network configuration device, and the target device may also be referred to as a Bluetooth Mesh device to be configured.
  • the second platform cloud before the second platform cloud sends the first confirmation value to the gateway through the first platform cloud, the second platform cloud receives the installation code sent by the gateway through the first platform cloud, wherein, The installation code is used for the second platform cloud to calculate the first confirmation value.
  • the first confirmation value is calculated by the second platform cloud based on an installation code and a first random number, where the first random number is generated by the second platform cloud.
  • the second platform cloud sends the first random number to the gateway through the first platform cloud, and the first random number is sent by the The gateway forwards it to the target device, wherein the first random number and the installation code are used by the target device to verify the first confirmation value.
  • Step 502 The second platform cloud receives a second confirmation value sent by the gateway through the first platform cloud, where the second confirmation value is calculated by the target device based on the installation code.
  • the second confirmation value is calculated by the target device based on the installation code and a second random number, and the second random number is generated by the target device.
  • the second platform cloud receives the second random number sent by the gateway through the first platform cloud, wherein the second The random number and the installation code are used for the second platform cloud to verify the second confirmation value.
  • the calculation of the second confirmation value may be in the following manner:
  • ConfirmationDevice is the second confirmation value
  • RandomDevice is the second random number generated by the target device
  • SetupCode is the installation code
  • the encryption algorithm is AES-CMAC
  • the encryption key is ConfirmationKey.
  • the target device may calculate the second confirmation value by using other calculation methods.
  • the target device can also add other parameters to calculate the second confirmation value.
  • Step 503 The second platform cloud verifies the second confirmation value based on the installation code.
  • the second platform cloud calculates a first check value based on the second random number and the installation code, and compares the first check value with the second confirmation value; if the first check value is If a verification value is the same as the second verification value, the second platform cloud confirms that the verification of the second verification value is successful; if the first verification value and the second verification value are different, then The second platform cloud confirms that the verification of the second confirmation value fails.
  • the encryption algorithm that is, the calculation of the first check value
  • the calculation parameters used by the second platform cloud to verify the second confirmation value are the same as the encryption algorithm and calculation parameters used by the target device to calculate the second confirmation value. It needs to be the same, so that the network can be successfully distributed.
  • the technical solutions of the embodiments of the present application are based on the dynamic OOB verification method. Further, there are two dynamic OOB verification methods, one is an output OOB verification method, and the other is an input OOB verification method. These two methods are described below.
  • Mode 1 In the case of the output OOB verification mode, the installation code is output by the target device, and the installation code is input by the user on the gateway.
  • Mode 2 In the case of the input OOB verification mode, the installation code is output by the gateway, and the installation code is input by the user on the target device.
  • OBB verification methods are also available: a static installation code is printed on the manual, and the user enters the installation code on the target device or gateway after seeing the installation code on the manual.
  • FIG. 6 is a schematic flowchart 3 of a cross-platform device network distribution method provided by an embodiment of the present application. As shown in FIG. 6 , the cross-platform device network distribution method includes the following steps:
  • Step 601 The target device sends a second confirmation value to the gateway, and the second confirmation value is forwarded by the gateway to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is sent by the target device It is calculated based on the installation code, where the installation code is dynamically generated or input by the user.
  • the gateway refers to the gateway of the first platform, that is, the gateway can directly communicate with the cloud of the first platform.
  • the communication between the gateway and the second platform cloud needs to be forwarded through the first platform cloud.
  • the gateway may also be referred to as a Bluetooth Mesh network configuration device, and the target device may also be referred to as a Bluetooth Mesh device to be configured.
  • the second confirmation value is calculated by the target device based on the installation code and a second random number, and the second random number is generated by the target device.
  • the target device sends the second random number to the gateway, and the second random number is passed by the gateway through the first random number.
  • the platform cloud forwards it to the second platform cloud, wherein the second random number and the installation code are used by the second platform cloud to verify the second confirmation value.
  • Step 602 The target device receives a first confirmation value sent by the gateway, where the first confirmation value is calculated by the second platform cloud based on the installation code.
  • the first confirmation value is calculated by the second platform cloud based on an installation code and a first random number, where the first random number is generated by the second platform cloud.
  • the target device receives the first random number sent by the gateway, wherein the first random number and the installation code are used for the The target device verifies the first confirmation value.
  • the calculation of the first confirmation value may be as follows:
  • ConfirmationProvisioner AES-CMAC ConfirmationKey (RandomProvisioner
  • ConfirmationProvisioner is the first confirmation value
  • RandomProvisioner is the first random number generated by the second platform cloud
  • SetupCode is the installation code
  • the encryption algorithm is AES-CMAC
  • the encryption key is ConfirmationKey.
  • the second platform cloud may calculate the first confirmation value by using other calculation methods.
  • the second platform cloud may also add other parameters to calculate the first confirmation value.
  • Step 603 The target device verifies the first confirmation value based on the installation code.
  • the target device calculates a second check value based on the first random number and the installation code, and compares the second check value with the first confirmation value; if the second check value is If the verification value is the same as the first verification value, the target device confirms that the verification of the first verification value is successful; if the second verification value is different from the first verification value, the target device confirms that the verification is successful. Confirm that the verification of the first confirmation value fails.
  • the encryption algorithm and calculation parameters used by the target device to verify the first confirmation value are the same as the encryption algorithm and calculation parameters used by the second platform cloud to calculate the first confirmation value. It needs to be the same, so that the network can be successfully distributed.
  • the technical solutions of the embodiments of the present application are based on the dynamic OOB verification method. Further, there are two dynamic OOB verification methods, one is an output OOB verification method, and the other is an input OOB verification method. These two methods are described below.
  • Mode 1 In the case of the output OOB verification mode, the installation code is output by the target device, and the installation code is input by the user on the gateway.
  • Mode 2 In the case of the input OOB verification mode, the installation code is output by the gateway, and the installation code is input by the user on the target device.
  • OBB verification methods are also available: a static installation code is printed on the manual, and the user enters the installation code on the target device or gateway after seeing the installation code on the manual.
  • FIG. 7 is a fourth schematic flowchart of a cross-platform device network distribution method provided by an embodiment of the present application, wherein the gateway of platform A corresponds to the gateway in the embodiment of the present application, and the device of company E corresponds to the target device in the embodiment of the present application, Platform cloud A corresponds to the first platform cloud in the embodiment of the present application, and platform cloud B corresponds to the second platform cloud in the embodiment of the present application.
  • the cross-platform device network distribution method includes the following steps :
  • Step 701 The user activates the device scanning function of the A platform gateway through voice or APP.
  • Step 702 The equipment of company E sends a broadcast packet (including UUID and CID) according to the specification.
  • the device of company E refers to the device developed by company E based on platform B, which belongs to the Bluetooth Mesh device to be distributed.
  • the broadcast packet refers to the Bluetooth Mesh unconfigured broadcast packet, which carries the UUID of the device of E company and the CID of the B platform.
  • Step 703 Platform A sends a device type query message (including UUID and CID) to Platform A cloud.
  • a device type query message including UUID and CID
  • the gateway of platform A sends the UUID of the device of company E and the CID of platform B to the cloud of platform A through the query device type message, and queries the device of the device of company E through the cloud of platform A. type.
  • Step 703.1 Based on the CID, the cloud of platform A determines whether the device of company E is the device of platform A. If not, step 703.2 is executed.
  • the cloud of platform A determines whether the device of company E is a device developed based on platform A through the CID in the device type query message (that is, whether the device of company E belongs to platform A or not). equipment).
  • Step 703.2 A platform cloud queries the interconnection server for platform information corresponding to the equipment of E company.
  • platform A determines that the device of the company E is not a device developed based on the platform A, other platforms (that is, the platform that develops the device of the company E) are required for authorization.
  • platform A obtains the information of platform B corresponding to the CID through the interconnection server (including information such as the authentication server (Auth Server) of platform B).
  • Auth Server authentication server
  • platform A queries the interconnection server for the platform information corresponding to the equipment of company E, it provides the CID to the interconnection server, so that the interconnection server can query the information of platform B through the CID.
  • Step 703.3 The interconnection server sends the information of the B platform to the A platform cloud.
  • Step 703.4 A platform cloud sends a query device type message (including the information of B platform, CID and UUID) to B platform cloud.
  • the query device type message is used to query the device type of the device of the E company.
  • Step 703.5 The B platform cloud sends the device type information to the A platform cloud.
  • the device type information is used to determine the device type of the E company device.
  • the B platform cloud instructs the output OOB verification method and/or the input OOB verification method to be preferentially adopted. That is to say, when the gateway of platform A and the device of company E support the output OOB verification method and/or the input OOB verification method, the output OOB verification method and/or the input OOB verification method shall be preferentially adopted instead of the static OOB verification method and no OOB verification method. Ways of identifying.
  • the device of company E outputs the installation code, and the user enters the installation code on the gateway of platform A.
  • the gateway of platform A outputs the installation code, and the user enters the installation code on the device of company E.
  • the OOB verification process is described by taking the output OOB verification method as an example, but the solution is also applicable to the input OOB verification method, and the difference only lies in the different roles of the devices that output and input the installation code.
  • Step 704 The A platform cloud sends the device type information to the A platform gateway.
  • the B platform cloud instructs the output OOB verification method and/or the input OOB verification method to be preferentially adopted. That is to say, when the gateway of platform A and the device of company E support the output OOB verification method and/or the input OOB verification method, the output OOB verification method and/or the input OOB verification method shall be preferentially adopted instead of the static OOB verification method and no OOB verification method. Ways of identifying.
  • Step 705 A platform gateway broadcasts device type information.
  • Step 706 The user performs an input operation on the platform A gateway to operate the platform A gateway to connect the device of the company E.
  • Step 707 The platform A gateway sends a provisioning invitation (Provisioning Invite) message to the device of company E.
  • Provisioning Invite Provisioning Invite
  • the platform A gateway instructs the output OOB verification method and/or the input OOB verification method to be preferentially used.
  • Step 708 The device of company E sends a provisioning capability (Provisioning Capabilities) message to the gateway of platform A.
  • the device of Company E indicates that the output OOB verification method and/or the input OOB verification method is preferentially adopted.
  • Step 709 Platform A gateway determines to adopt the output OOB verification method according to one or more of the device type information, the indication of platform A cloud (from step 704) and the indication of the device of E company (from step 708). Or enter the OOB authentication method.
  • Step 710 The platform A gateway sends a provisioning start (Provisioning Start) message to the device of company E.
  • the configuration start message indicates that the output OOB verification mode or the input OOB verification mode is determined to be adopted.
  • Step 711 The gateway of platform A and the device of company E complete the exchange of public keys through platform A cloud and platform B cloud.
  • Step 712 The device of E company outputs the installation code.
  • the device of E company outputs the installation code, which can be a dynamic or static random value. way to output the random value.
  • Step 713 The user enters the installation code on the A platform gateway.
  • the platform A gateway has user input devices such as a screen, a microphone, a camera, and a button, and the user can input the installation code through the input device to confirm the installation code output by the equipment of E company.
  • Step 714 The platform A gateway reports the installation code to the platform A cloud.
  • Step 715 A platform cloud reports the installation code to B platform cloud.
  • Step 716 The B platform cloud uses the installation code to calculate the first confirmation value.
  • the calculation of the first confirmation value may be as follows:
  • ConfirmationProvisioner AES-CMAC ConfirmationKey (RandomProvisioner
  • ConfirmationProvisioner is the first confirmation value
  • RandomProvisioner is the first random number generated by the B platform cloud
  • SetupCode is the installation code
  • the encryption algorithm is AES-CMAC
  • the encryption key is ConfirmationKey.
  • the B platform cloud may calculate the first confirmation value by using other calculation methods.
  • the B platform cloud can also add other parameters to calculate the first confirmation value.
  • the encryption algorithm and calculation parameters used by the equipment of E company to verify the first confirmation value need to be the same as the encryption algorithm and calculation parameters used by the cloud computing of the B platform for the first confirmation value, so that the network can be successfully distributed.
  • Step 717 Platform B cloud sends authentication information (including the first confirmation value and the first random number) to platform A cloud.
  • Step 718 The platform A cloud sends authentication information (including the first confirmation value and the first random number) to the platform A gateway.
  • Step 719 The platform A gateway sends the first confirmation value to the device of the company E.
  • Step 720 The device of the E company uses the installation code to calculate the second confirmation value.
  • the calculation of the second confirmation value may be in the following manner:
  • ConfirmationDevice is the second confirmation value
  • RandomDevice is the second random number generated by the target device
  • SetupCode is the installation code
  • the encryption algorithm is AES-CMAC
  • the encryption key is ConfirmationKey.
  • the equipment of company E may calculate the second confirmation value by using other calculation methods.
  • the equipment of company E can also add other parameters to calculate the second confirmation value.
  • the encryption algorithm and calculation parameters used by platform B to verify the second confirmation value need to be the same as the encryption algorithm and calculation parameters used by the equipment of E company to calculate the second confirmation value, so that the network can be successfully distributed.
  • Step 721 The device of company E sends a second confirmation value to the gateway of platform A.
  • Step 722 The platform A gateway sends the first random number to the equipment of company E.
  • Step 723 The device of E company verifies the first confirmation value based on the first random number and the installation code.
  • the device of E company calculates the verification value using the same calculation method in step 716, and compares it with the first confirmation value obtained in step 719 to see if it is the same. If it is the same, step 724 is executed.
  • Step 724 The device of company E sends the second random number to the gateway of platform A.
  • Step 725 The A platform network sends the device authentication information (including the second confirmation value and the second random number) to the A platform cloud.
  • Step 726 Platform A cloud sends device authentication information (including a second confirmation value and a second random number) to platform B cloud.
  • Step 727 The B platform cloud verifies the second confirmation value based on the second random number and the installation code.
  • the B platform cloud uses the same calculation method in step 720 to calculate the verification value, and compares it with the second confirmation value obtained in step 726 to see if it is the same. If it is the same, step 728 is executed.
  • Step 728 The platform cloud B sends the authentication result (including the device information of the device of the company E) to the platform cloud A.
  • Step 729 Platform A cloud stores the device information of company E's device.
  • the device information includes information such as control functions and control commands supported by the device.
  • Step 730 The A platform cloud sends the authentication result to the A platform gateway.
  • Step 731 The platform A gateway sends configuration data to the device of the company E.
  • Step 732 A platform gateway broadcasts the authentication result.
  • the device of company E officially becomes the node of the Bluetooth Mesh network, and the configuration process is completed.
  • the device of E company outputs the installation code after entering the network distribution mode, and the user operates on the A platform gateway to input the installation code.
  • steps 712 and 713 may be moved to be performed before step 703 .
  • Step 714 is deleted, and the platform A gateway uploads the installation code to the platform A cloud through step 703 .
  • Step 715 is deleted, and platform cloud A sends the installation code to platform cloud B through step 703.4, and other processes remain unchanged.
  • FIG. 8 is a schematic structural diagram 1 of a cross-platform device network distribution device provided by an embodiment of the present application, which is applied to a gateway, and the device includes:
  • a receiving unit 801, configured to receive, through the first platform cloud, the first confirmation value sent by the second platform cloud;
  • the sending unit 802 is configured to send the first confirmation value to the target device for verification, wherein the first confirmation value is calculated by the second platform cloud based on an installation code, and the installation code is dynamically generated or user input;
  • the receiving unit 801 is further configured to receive the second confirmation value sent by the target device;
  • the sending unit 802 is further configured to send the second confirmation value to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is determined by the target device based on the The above installation code is calculated.
  • the sending unit 802 is further configured to send the installation code to the second platform cloud through the first platform cloud, where the installation code is used for the second platform cloud The first confirmation value is calculated.
  • the first confirmation value is calculated by the second platform cloud based on an installation code and a first random number, wherein the first random number is generated by the second platform cloud.
  • the receiving unit 801 is further configured to receive, through the first platform cloud, the first random number sent by the second platform cloud;
  • the sending unit 802 is further configured to send the first random number to the target device, wherein the first random number and the installation code are used by the target device to perform the first confirmation value on the target device. check.
  • the second confirmation value is calculated by the target device based on the installation code and a second random number, and the second random number is generated by the target device.
  • the receiving unit 801 is further configured to receive the second random number sent by the target device;
  • the sending unit 802 is further configured to send the second random number to the second platform cloud through the first platform cloud, wherein the second random number and the installation code are used for the first platform cloud.
  • the second platform cloud verifies the second confirmation value.
  • the receiving unit 801 is further configured to receive, through the first platform cloud, the device type information of the target device sent by the second platform cloud;
  • the sending unit 802 is further configured to send an invitation message to the target device
  • the receiving unit 801 is further configured to receive a configuration capability message sent by the target device;
  • the sending unit 802 is further configured to send a configuration start message to the target device;
  • At least one of the device type information, the invitation message and the configuration capability message carries first indication information, and the first indication information is used to indicate that the output OOB verification method and/or the input OOB verification method are preferentially adopted mode;
  • the configuration start message carries second indication information, and the second indication information is used to indicate that the OOB authentication mode is determined to be adopted or the OOB authentication mode is input.
  • the device further includes:
  • a determining unit (not shown in the figure), configured to determine to adopt an OOB verification method or an input OOB verification method based on at least one of the following: the device type information of the target device, the first indication information carried in the device type information , the first indication information carried in the configuration capability message.
  • the installation code is output by the target device, and the installation code is input by the user on the gateway.
  • the installation code is output by the gateway, and the installation code is input by a user on the target device.
  • the receiving unit 801 is further configured to receive, through the first platform cloud, the authentication result sent by the second platform cloud;
  • the sending unit 802 is further configured to send configuration data to the target device.
  • FIG. 9 is a schematic diagram 2 of the structure and composition of a cross-platform device network distribution device provided by an embodiment of the present application, which is applied to a second platform cloud, and the device includes:
  • a sending unit 901 configured to send a first confirmation value to a gateway through a first platform cloud, the first confirmation value is forwarded by the gateway to a target device for verification, wherein the first confirmation value is sent by the second confirmation value
  • the platform cloud is calculated based on the installation code, and the installation code is dynamically generated or input by the user;
  • a receiving unit 902 configured to receive a second confirmation value sent by the gateway through the first platform cloud, wherein the second confirmation value is calculated by the target device based on the installation code;
  • a verification unit 903 configured to verify the second confirmation value based on the installation code.
  • the receiving unit 902 is further configured to receive an installation code sent by the gateway through the first platform cloud, where the installation code is used for the second platform cloud to calculate the first A confirmation value.
  • the first confirmation value is calculated by the second platform cloud based on an installation code and a first random number, wherein the first random number is generated by the second platform cloud.
  • the sending unit 901 is further configured to send the first random number to the gateway through the first platform cloud, and the first random number is forwarded by the gateway to the target device, wherein the first random number and the installation code are used by the target device to verify the first confirmation value.
  • the second confirmation value is calculated by the target device based on the installation code and a second random number, and the second random number is generated by the target device.
  • the receiving unit 902 is further configured to receive the second random number sent by the gateway through the first platform cloud, wherein the second random number and the installation code are used for The second confirmation value is verified on the second platform cloud.
  • the verification unit 903 is configured to calculate a first verification value based on the second random number and the installation code, and compare the first verification value and the second confirmation value. Compare; if the first verification value and the second verification value are the same, confirm that the verification of the second verification value is successful; if the first verification value and the second verification value are different, Then it is confirmed that the verification of the second confirmation value fails.
  • the installation code is output by the target device, and the installation code is input by the user on the gateway.
  • the installation code is output by the gateway, and the installation code is input by the user on the target device.
  • FIG. 10 is a schematic diagram 3 of the structure and composition of a cross-platform device network distribution device provided by an embodiment of the present application, which is applied to a target device, and the device includes:
  • a sending unit 1001 configured to send a second confirmation value to the gateway, where the second confirmation value is forwarded by the gateway to the second platform cloud through the first platform cloud for verification, wherein the second confirmation value is sent by the target
  • the device is calculated based on the installation code, and the installation code is dynamically generated or input by the user
  • a receiving unit 1002 configured to receive a first confirmation value sent by the gateway, wherein the first confirmation value is calculated by the second platform cloud based on the installation code;
  • a verification unit 1003, configured to verify the first confirmation value.
  • the first confirmation value is calculated by the second platform cloud based on an installation code and a first random number, wherein the first random number is generated by the second platform cloud.
  • the receiving unit 1002 is further configured to receive the first random number sent by the gateway, wherein the first random number and the installation code are used for the target device to The first confirmation value is used for verification.
  • the verification unit 1003 is configured to calculate a second verification value based on the first random number and the installation code, and compare the second verification value with the first confirmation value. Compare; if the second verification value is the same as the first verification value, then confirm that the verification of the first verification value is successful; if the second verification value is different from the first verification value, Then it is confirmed that the verification of the first confirmation value fails.
  • the second confirmation value is calculated by the target device based on the installation code and a second random number, and the second random number is generated by the target device.
  • the sending unit 1001 is further configured to send the second random number to the gateway, and the second random number is forwarded to the gateway by the gateway through the first platform cloud.
  • the second platform cloud wherein the second random number and the installation code are used for the second platform cloud to verify the second confirmation value.
  • the installation code is output by the target device, and the installation code is input by the user on the gateway.
  • the installation code is output by the gateway, and the installation code is input by the user on the target device.
  • An embodiment of the present invention further provides a gateway, including a processor and a memory for storing a computer program that can be executed on the processor, wherein the processor is configured to execute the above-mentioned cross-platform device configuration when the computer program is executed. steps of the net method.
  • An embodiment of the present invention further provides a platform cloud, including a processor and a memory for storing a computer program that can be executed on the processor, wherein the processor is configured to execute the above-mentioned cross-platform device when the computer program is executed The steps of the distribution network method.
  • An embodiment of the present invention further provides a device, including a processor and a memory for storing a computer program that can run on the processor, wherein the processor is configured to execute the above-mentioned cross-platform device configuration when running the computer program. steps of the net method.
  • the electronic device 1100 includes: at least one processor 1101 , memory 1102 and at least one network interface 1104 .
  • the various components in electronic device 1100 are coupled together by bus system 1105 .
  • bus system 1105 is used to implement the connection communication between these components.
  • the bus system 1105 also includes a power bus, a control bus, and a status signal bus.
  • the various buses are labeled as bus system 1105 in FIG. 11 .
  • the memory 1102 may be either volatile memory or non-volatile memory, and may include both volatile and non-volatile memory.
  • the non-volatile memory can be ROM, Programmable Read-Only Memory (PROM, Programmable Read-Only Memory), Erasable Programmable Read-Only Memory (EPROM, Erasable Programmable Read-Only Memory), Electrically Erasable Programmable Read-Only Memory Programmable read-only memory (EEPROM, Electrically Erasable Programmable Read-Only Memory), magnetic random access memory (FRAM, ferromagnetic random access memory), flash memory (Flash Memory), magnetic surface memory, optical disk, or CD-ROM -ROM, Compact Disc Read-Only Memory); magnetic surface memory can be disk memory or tape memory.
  • RAM Random Access Memory
  • SRAM Static Random Access Memory
  • SSRAM Synchronous Static Random Access Memory
  • DRAM Dynamic Random Access Memory
  • SDRAM Synchronous Dynamic Random Access Memory
  • DDRSDRAM Double Data Rate Synchronous Dynamic Random Access Memory
  • ESDRAM Enhanced Type Synchronous Dynamic Random Access Memory
  • SLDRAM Synchronous Link Dynamic Random Access Memory
  • DRRAM Direct Rambus Random Access Memory
  • the memory 1102 described in the embodiments of the present invention is intended to include, but not be limited to, these and any other suitable types of memory.
  • the memory 1102 in the embodiment of the present invention is used to store various types of data to support the operation of the electronic device 1100 .
  • Examples of such data include: any computer program used to operate on electronic device 1100, such as application program 11022.
  • the program for implementing the method of the embodiment of the present invention may be included in the application program 11022 .
  • the methods disclosed in the above embodiments of the present invention may be applied to the processor 1101 or implemented by the processor 1101 .
  • the processor 1101 may be an integrated circuit chip with signal processing capability. In the implementation process, each step of the above-mentioned method may be completed by an integrated logic circuit of hardware in the processor 1101 or an instruction in the form of software.
  • the above-mentioned processor 1101 may be a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like.
  • the processor 1101 may implement or execute the methods, steps, and logical block diagrams disclosed in the embodiments of the present invention.
  • a general purpose processor may be a microprocessor or any conventional processor or the like.
  • the steps of the method disclosed in combination with the embodiments of the present invention can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module may be located in a storage medium, and the storage medium is located in the memory 1102, and the processor 1101 reads the information in the memory 1102, and completes the steps of the foregoing method in combination with its hardware.
  • the electronic device 1100 may be implemented by one or more of Application Specific Integrated Circuit (ASIC), DSP, Programmable Logic Device (PLD), Complex Programmable Logic Device (CPLD). , Complex Programmable Logic Device), FPGA, general-purpose processor, controller, MCU, MPU, or other electronic component implementation for performing the aforementioned method.
  • ASIC Application Specific Integrated Circuit
  • DSP Digital Signal processor
  • PLD Programmable Logic Device
  • CPLD Complex Programmable Logic Device
  • FPGA field-programmable Logic Device
  • controller MCU
  • MPU or other electronic component implementation for performing the aforementioned method.
  • Embodiments of the present application further provide a storage medium for storing a computer program.
  • the storage medium can be applied to the gateway in the embodiment of the present application, and the computer program enables the computer to execute the corresponding processes in each method executed by the gateway in the embodiment of the present application, which is not repeated here for brevity.
  • the storage medium can be applied to the second platform cloud in the embodiments of the present application, and the computer program causes the computer to execute the corresponding processes in each method executed by the second platform cloud in the embodiments of the present application. This will not be repeated here.
  • the storage medium can be applied to the target device in the embodiments of the present application, and the computer program causes the computer to execute the corresponding processes in each method executed by the target device in the embodiments of the present application.
  • the computer program causes the computer to execute the corresponding processes in each method executed by the target device in the embodiments of the present application.
  • details are not repeated here. .
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions
  • the apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

Landscapes

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

Abstract

本申请实施例提供一种跨平台的设备配网方法及装置、设备，该方法包括：网关通过第一平台云接收第二平台云发送的第一确认值，将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；所述网关接收目标设备发送的第二确认值，将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。

Description

一种跨平台的设备配网方法及装置、电子设备 技术领域
本申请实施例涉及物联网技术领域，具体涉及一种跨平台的设备配网方法及装置、电子设备。
背景技术
蓝牙网格(Mesh)设备上电后如果处于未配网状态，则需要发送广播包，从而网关可以通过该广播包发现该蓝牙Mesh设备。当蓝牙Mesh设备与网关不属于同一厂商时，需要通过跨平台的方式对蓝牙Mesh设备进行配网。在通过跨平台的方式对蓝牙Mesh设备进行配网的过程中，由于蓝牙Mesh设备的广播消包是公开信息，处于一定范围内的任何网关都可以监听到该广播包，这会存在极大的安全风险。
发明内容
本申请实施例提供一种跨平台的设备配网方法及装置、电子设备。
本申请实施例提供的跨平台的设备配网方法，包括：
网关通过第一平台云接收第二平台云发送的第一确认值，将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
所述网关接收目标设备发送的第二确认值，将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
本申请实施例提供的跨平台的设备配网方法，包括：
第二平台云通过第一平台云向网关发送第一确认值，所述第一确认值由所述网关转发给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
所述第二平台云通过所述第一平台云接收所述网关发送的第二确认值，其中，所述第二确认值由所述目标设备基于所述安装码计算得到；
所述第二平台云基于所述安装码对所述第二确认值进行校验。
本申请实施例提供的跨平台的设备配网方法，包括：
目标设备向网关发送第二确认值，所述第二确认值由所述网关通过第一平台云转发给第二平台云进行验证，其中，所述第二确认值由所述目标设备基于安装码计算得到，所述安装码为动态生成的或用户输入的；
所述目标设备接收所述网关发送的第一确认值，其中，所述第一确认值由所述第二平台云基于所述安装码计算得到；
所述目标设备基于所述安装码对所述第一确认值进行校验。
本申请实施例提供的跨平台的设备配网装置，应用于网关，所述装置包括：
接收单元，用于通过第一平台云接收第二平台云发送的第一确认值；
发送单元，用于将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
所述接收单元，还用于接收目标设备发送的第二确认值；
所述发送单元，还用于将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
本申请实施例提供的跨平台的设备配网装置，应用于第二平台云，所述装置包括：
发送单元，用于通过第一平台云向网关发送第一确认值，所述第一确认值由所述网关转发给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码 为动态生成的或用户输入的；
接收单元，用于通过所述第一平台云接收所述网关发送的第二确认值，其中，所述第二确认值由所述目标设备基于所述安装码计算得到；
校验单元，用于基于所述安装码对所述第二确认值进行校验。
本申请实施例提供的跨平台的设备配网装置，应用于目标设备，所述装置包括：
发送单元，用于向网关发送第二确认值，所述第二确认值由所述网关通过第一平台云转发给第二平台云进行验证，其中，所述第二确认值由所述目标设备基于安装码计算得到，所述安装码为动态生成的或用户输入的；
接收单元，用于接收所述网关发送的第一确认值，其中，所述第一确认值由所述第二平台云基于所述安装码计算得到；
校验单元，用于对所述第一确认值进行校验。
本申请实施例提供的电子设备，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述的跨平台的设备配网方法。
本申请实施例提供的存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述的跨平台的设备配网方法。
通过上述技术方案，第二平台云基于动态生成的安装码来计算第一确认值，目标设备基于该安装码对第一确认值进行验证；同理，目标设备基于动态生成的安装码来计算第二确认值，第二平台云基于该安装码对第二确认值进行验证，如此，可以正确实现目标设备与云平台之间的验证，从而网关可以准确对目标设备进行配网。其中，目标设备指蓝牙Mesh设备，如此，用户可以控制自己的蓝牙Mesh设备的配网，避免了用户的蓝牙Mesh设备被其他用户非法或错误绑定，提高了跨平台蓝牙Mesh设备配网的安全性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是本申请实施例提供的客户端设备和服务端设备通信的流程示意图；
图2是本申请实施例提供的蓝牙Mesh配网设备和待配网蓝牙Mesh设备(即新设备)之间的验证流程图；
图3是本申请实施例提供的跨平台蓝牙Mesh设备配网流程图；
图4是本申请实施例提供的跨平台的设备配网方法的流程示意图一；
图5是本申请实施例提供的跨平台的设备配网方法的流程示意图二；
图6是本申请实施例提供的跨平台的设备配网方法的流程示意图三；
图7是本申请实施例提供的跨平台的设备配网方法的流程示意图四；
图8是本申请实施例提供的跨平台的设备配网装置的结构组成示意图一；
图9是本申请实施例提供的跨平台的设备配网装置的结构组成示意图二；
图10是本申请实施例提供的跨平台的设备配网装置的结构组成示意图三；
图11是本发明实施例电子设备的硬件组成结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
开放连接基金会(OCF，Open Connectivity Foundation)是新兴的物联网应用层技术标准组织，OCF为物联网设备之间实现互联互通制定Restful服务框架。在OCF Restful服务框架中，通过资源来表述物联网设备、OCF设备的功能服务和OCF设备的状态等信息。其中，提供资源的实体是OCF服务端设备(以下简称服务端设备)，访问资源的实体是OCF客户端(以下简称客户端设备)。客户端设备和服务端设备的业务交互是通过对资源的创建、读取、更新、删除或者通知等资源操作方法而实现。
客户端设备和服务端设备通信的流程，如图1所示：客户端设备向服务端设备发送针对服务端 设备上的资源的更新资源请求。服务端设备根据所述更新资源请求，执行相应的资源操作，并向客户端设备发送更新资源响应；其中，所述更新资源响应中携带资源的表述。
这里，所述更新资源请求中携带资源的统一资源标识符(Uniform Resource Identifier，URI)以及资源操作方法。
资源的表述包括：资源的URI、资源类型、资源接口和资源的功能属性等，下面对资源的表述所包括的信息分别进行说明：
资源的URI，在资源的表述中用“href”表示，提供OCF服务端设备资源的地址，“href”的值是具体的资源的URI，OCF客户端设备通过资源的URI来访问OCF服务端设备的资源。
资源类型，在资源的表述中用“rt”表示，表示资源的类型。
资源接口，在资源的表述中用“if”表示，提供对资源的查看以及资源支持的响应。
资源属性，在资源的表述中描述资源的属性信息。
OCF定义了所有OCF设备都必须支持的资源发现资源“/oic/res”，资源发现资源用于OCF设备以及资源的发现；资源发现资源提供设备资源发现的功能，资源发现资源的URI固定为“/oic/res”。
为表示资源之间的关联关系，OCF定义了资源链接，即资源Links；OCF服务端设备可以以资源链接的形式提供自己所拥有的资源，便于OCF客户端设备发现OCF服务端设备的资源。资源链接的内容包括：
anchor:上下文URI，表示包含资源链接的属主资源的URI。
href:目标URI，即资源链接中引用的目标资源的URI。
rt:目标资源的资源类型标识。
if:目标资源支持的接口。
eps:可以访问目标资源的端点。
由于OCF标准协议在传输层采用受限制的应用协议(Constrained Application Protocol，CoAP)承载OCF消息，每个OCF服务端设备需要具有端点，每一个OCF设备必须关联至少一个端点用于发送和接收消息；客户端设备通过端点可以访问服务端设备的目标资源。在资源链接的参数中用“eps”数组表示目标资源的端点，具体端点用“ep”表示，即可以通过"eps"参数中"ep"值的地址访问目标资源。
为便于理解本申请实施例的技术方案，以下对本申请实施例涉及到的相关概念及技术进行说明。
●相关概念
蓝牙Mesh网络：一种基于低功耗蓝牙技术构建的网状设备网络，可以实现多对多的蓝牙设备通信。
网关：蓝牙Mesh配网设备，负责配置接入蓝牙Mesh网络的设备。
设备：待配网的蓝牙Mesh设备，需要通过蓝牙Mesh配网流程加入蓝牙Mesh网络。
●相关技术
蓝牙Mesh设备上电后如果处于未配网状态，则需要发送广播包，即广播未配置的设备信标(Unprovisioned Device Beacon)包。其中，广播包中携带蓝牙Mesh设备的通用唯一标识符(Universally Unique Identifier，UUID)，简称为设备UUID(Device UUID)。Device UUID是识别蓝牙Mesh设备的关键信息，Device UUID的格式参照如下表1所示：
Figure PCTCN2020103590-appb-000001
Figure PCTCN2020103590-appb-000002
表1
为了提升蓝牙Mesh设备配网的效率，蓝牙Mesh设备认证鉴权方式采用蓝牙Mesh协议中规定的静态带外(Static Out of Band，Static OOB)验证方式或无带外(No Out of Band，No OOB)验证方式。其中，静态OOB验证方式即：基于静态OOB信息计算确认值(即Provisiong Confirmation)。无OOB验证方式即：直接以数值0代替OOB信息来计算确认值。无论是静态OOB验证方式还是无OOB验证方式，在配网过程中不需要用户输入授权值(AuthValue)等用户确认操作，即可完成蓝牙Mesh设备的配网过程。
如图2所示，蓝牙Mesh配网设备和待配网蓝牙Mesh设备(即新设备)之间的验证流程包括以下步骤：
步骤201：蓝牙Mesh配网设备向待配网蓝牙Mesh设备发送第一确认值。
对于静态OOB验证方式的情况来说，蓝牙Mesh配网设备基于静态OOB信息计算第一确认值。
对于无OOB验证方的情况来说，蓝牙Mesh配网设备以数值0代替OOB信息来计算第一确认值。
步骤202：待配网蓝牙Mesh设备向蓝牙Mesh配网设备发送第二确认值。
对于静态OOB验证方式的情况来说，待配网蓝牙Mesh设备基于静态OOB信息计算第二确认值。
对于无OOB验证方的情况来说，待配网蓝牙Mesh设备以数值0代替OOB信息来计算第二确认值。
步骤203：蓝牙Mesh配网设备向待配网蓝牙Mesh设备发送第一随机数。
这里，蓝牙Mesh配网设备计算第一确认值的时候，会采用第一随机数。
步骤204：待配网蓝牙Mesh设备基于第一随机数对第一确认值进行校验。
步骤205：待配网蓝牙Mesh设备向蓝牙Mesh配网设备发送第二随机数。
这里，待配网蓝牙Mesh设备计算第二确认值的时候，会采用第二随机数。
步骤206：蓝牙Mesh配网设备基于第二随机数对第二确认值进行校验。
需要说明的是，蓝牙Mesh配网设备可以通过网关来实现，待配网蓝牙Mesh设备也可以简称为设备。
需要说明的是，本申请实施例中的“确认值”也可以称为“Provisiong Confirmation”。本申请实施例中的“随机数”也可以称为“Provisiong Random”。
当蓝牙Mesh设备与网关不属于同一厂商时，需要通过跨平台(即跨两个物联网云平台)认证的方式对蓝牙Mesh设备进行配网，跨平台蓝牙Mesh设备配网过程如图3所示，包括以下步骤：
步骤301：用户通过语音或APP激活A平台网关的设备扫描功能。
步骤302：E公司设备按规范发送广播包(包含UUID和CID)。
这里，E公司设备是指E公司基于B平台开发的设备，属于待配网蓝牙Mesh设备。
这里，广播包是指蓝牙Mesh未配网广播包，该广播包中携带E公司设备的UUID和B平台的CID。
步骤303：A平台向A平台云发送查询设备类型消息(包含UUID和CID)。
这里，A平台网关通过步骤302获取E公司设备发送的广播包后，将E公司设备的UUID和B平台的CID通过查询设备类型消息发送给A平台云，通过A平台云查询E公司设备的设备类型。
步骤303.1：A平台云基于CID判定E公司设备是否为A平台的设备，若不是，则执行步骤303.2。
这里，A平台云在收到A平台网关发送的查询设备类型消息后，通过该查询设备类型消息中的CID判断E公司设备是不是基于A平台开发的设备(即E公司设备是否为A平台的设备)。
步骤303.2：A平台云向互联互通服务器查询E公司设备对应的平台信息。
这里，若A平台云判断E公司设备不是基于A平台开发的设备，则需要其它平台(即开发E公司设备的平台)进行授权。为了查询开发E公司设备的平台，A平台通过互联互通服务器获取CID对应的B平台的信息(包含B平台认证服务器(Auth Server)等信息)。这里，A平台云向互联互通服务器查询E公司设备对应的平台信息时，向互联互通服务器提供CID，以便互联互通服务器通过CID查询B平台的信息。
步骤303.3：互联互通服务器向A平台云发送B平台的信息。
步骤303.4：A平台云向B平台云发送查询设备类型消息(包含B平台的信息、CID和UUID)。
这里，查询设备类型消息用于查询E公司设备的设备类型。
步骤303.5：B平台云向A平台云发送设备类型信息。
这里，设备类型信息用于确定E公司设备的设备类型。
步骤304：A平台云向A平台网关发送设备类型信息。
步骤305：A平台网关播报设备类型信息。
步骤306：用户在A平台网关上执行输入操作，以操作A平台网关连接E公司设备。
步骤307：A平台网关向E公司设备发送配置邀请(Provisioning Invite)消息。
步骤308：E公司设备向A平台网关发送配置能力(Provisioning Capabilities)消息。
步骤309：A平台网关向E公司设备发送配置开始(Provisioning Start)消息。
步骤310：A平台网关和E公司设备通过A平台云、B平台云完成公共密钥(Public Key)交换。
步骤311：B平台云计算第一确认值。
这里，B平台云根据静态OOB信息或者无OBB信息计算第一确认值。其中，第一确认值基于第一随机数计算。
步骤312：B平台云向A平台云发送认证信息(包含第一确认值和第一随机数)。
步骤313：A平台云向A平台网关发送认证信息(包含第一确认值和第一随机数)。
步骤314：A平台网关向E公司设备发送第一确认值。
步骤315：E公司设备向A平台网关发送第二确认值。
这里，E公司设备根据静态OOB信息或者无OBB信息计算第二确认值。其中，第二确认值基于第二随机数计算。
步骤316：A平台网关向E公司设备发送第一随机数。
步骤317：E公司设备基于第一随机数对第一确认值进行校验。
步骤318：E公司设备向A平台网关发送第二随机数。
步骤319：A平台网向A平台云发送设备认证信息(包含第二确认值和第二随机数)。
步骤320：A平台云向B平台云发送设备认证信息(包含第二确认值和第二随机数)。
步骤321：B平台云基于第二随机数对第二确认值进行校验。
步骤322：B平台云向A平台云发送认证结果(包含E公司设备的设备信息)。
步骤323：A平台云存储E公司设备的设备信息。
这里，设备信息包含设备支持的控制功能和控制指令等信息。
步骤324：A平台云向A平台网关发送认证结果。
步骤325：A平台网关向E公司设备发送配置数据。
步骤326：A平台网关播报认证结果。
通过上述流程，E公司设备正式成为蓝牙Mesh网络的节点，完成配置过程。
图3所示的流程中，第一确认值或者第二确认值的计算是基于静态OOB信息或者无OOB信息，也就是说，B平台云和E公司设备之间的验证方式是静态OOB验证方式或者无OOB验证方式。由于E公司设备的广播包是公开信息，处于扫描距离内的任何网关都可以监听到广播包，如果采用静态OOB验证方式或者无OOB验证方式，可能发生用户A的E公司设备被用户B的网关进行配网绑定，从而用户B可以控制用户A的E公司设备，而用户A自己却无法控制，存在极大的安全风险(例如，门锁、摄像头等设备被非主人设备绑定)。
为此，提出了本申请实施例的以下技术方案。本申请实施例的技术方案提出一种跨平台的蓝牙Mesh设备配网方法(简称为跨平台的设备配网方法)，在配网过程中需要采用动态OOB验证方式，即需要用户操作输入安装码才可以实现对蓝牙Mesh设备的配网。为更好理解本申请的技术方案，下面结合实施例进行说明。
图4是本申请实施例提供的跨平台的设备配网方法的流程示意图一，如图4所示，所述跨平台的设备配网方法包括以下步骤：
步骤401：网关通过第一平台云接收第二平台云发送的第一确认值，将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的。
本申请实施例中，网关是指第一平台的网关，也就是说，网关可以与第一平台云进行直接通信。网关与第二平台云之间的通信需要通过第一平台云进行转发。
本申请实施例中，网关也可以称为蓝牙Mesh配网设备，目标设备也可以称为待配网蓝牙Mesh 设备。
本申请实施例中，所述网关通过第一平台云接收第二平台云发送的第一确认值之前，所述网关通过所述第一平台云向所述第二平台云发送所述安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
本申请实施例中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。为了让目标设备实现对所述第一确认值进行校验，所述网关通过所述第一平台云接收所述第二平台云发送的所述第一随机数；所述网关将所述第一随机数发送给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
在一个示例中，第一确认值的计算可以采用以下方式：
ConfirmationProvisioner＝AES-CMAC ConfirmationKey(RandomProvisioner||SetupCode)；
其中，ConfirmationProvisioner是第一确认值，RandomProvisioner是第二平台云产生的第一随机数，SetupCode是安装码，加密算法为AES-CMAC，加密密钥为ConfirmationKey。
需要说明的是，第二平台云可以采用其他的计算方式计算第一确认值。另外，第二平台云也可以增加其他参数来计算第一确认值。目标设备对第一确认值进行验证时所采用的加密算法和计算参数与第二平台云计算第一确认值所采用的加密算法和计算参数需要相同，如此才能够成功进行配网。
步骤402：所述网关接收目标设备发送的第二确认值，将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
本申请实施例中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。为了让第二平台云实现对所述第二确认值进行校验，所述网关接收所述目标设备发送的所述第二随机数；所述网关将所述第二随机数通过所述第一平台云发送给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
在一个示例中，第二确认值的计算可以采用以下方式：
ConfirmationDevice＝AES-CMAC ConfirmationKey(RandomDevice||SetupCode)；
其中，ConfirmationDevice是第二确认值，RandomDevice是目标设备产生的第二随机数，SetupCode是安装码，加密算法为AES-CMAC，加密密钥为ConfirmationKey。
需要说明的是，目标设备可以采用其他的计算方式计算第二确认值。另外，目标设备也可以增加其他参数来计算第二确认值。第二平台云对第二确认值进行验证时所采用的加密算法和计算参数与目标设备计算第二确认值所采用的加密算法和计算参数需要相同，如此才能够成功进行配网。
本申请实施例中，所述方法还包括：网关查询目标设备的设备类型的流程，网关和目标设备进行邀请的流程，以及网关和目标设备交换公共密钥的流程。具体地，
1、所述网关通过所述第一平台云接收所述第二平台云发送的所述目标设备的设备类型信息(例如安防设备，智能门锁等类型)；
2、所述网关向所述目标设备发送邀请消息；
3、所述网关接收所述目标设备发送的配置能力消息；
4、所述网关向所述目标设备发送配置开始消息；
5、所述网关通过所述第一平台云和所述第二平台云与所述目标设备，进行公共密钥交换；
其中，所述设备类型信息、所述邀请消息和所述配置能力消息中的至少之一携带第一指示信息，所述第一指示信息用于指示优先采用输出带外OOB验证方式和/或输入OOB验证方式；所述配置开始消息携带第二指示信息，所述第二指示信息用于指示确定采用OOB验证方式或者输入OOB验证方式。
在一可选方式中，所述网关接收所述目标设备发送的配置能力消息之后，所述方法还包括：所述网关基于以下至少之一，确定采用OOB验证方式或者输入OOB验证方式：所述目标设备的设备类型信息、所述设备类型信息中携带的第一指示信息、所述配置能力消息中携带的第一指示信息。
上述技术方案中，安装码为动态生成的或用户输入的。
在一个示例中，安装码是动态生成的。例如网关动态生成并输出安装码。再例如目标设备动态生成并输出安装码。
在另一个示例中，安装码为用户输入的。例如目标设备输出动态或静态的安装码，用户看到后将该安装码输入到网关上。再例如网关输出动态或静态的安装码，用户看到后将该安装码输入到目标设备上。又例如静态的安装码印在说明书上，用户看到说明书上的安装码后将该安装码输入到目标设备或者网关上。
本申请实施例的技术方案是基于动态OOB验证方式。进一步，动态OOB验证方式有两种，一种是输出OOB验证方式，另一种输入OOB验证方式。以下对这两种方式进行说明。
方式一：所述输出OOB验证方式的情况下，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
在一个示例中，目标设备输出安装码，该安装码可以是一个动态或静态的随机值，例如目标设备通过屏幕显示、声音、闪烁、震动、二维码、说明书等方式输出该随机值。用户在网关上输入安装码，这里，网关带有屏幕、麦克风、摄像头、按键等用户输入装置，用户可以通过输入装置输入安装码，以确认目标设备输出的安装码。即：用户可以通过目标设备的输出获得安装码，将该安装码输入到网关上。
方式二：所述输入OOB验证方式的情况下，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
在一个示例中，网关输出安装码，该安装码可以是一个动态或静态的随机值，例如网关通过屏幕显示、声音、闪烁、震动、二维码、说明书等方式输出该随机值。用户在目标设备上输入安装码，这里，目标设备带有屏幕、麦克风、摄像头、按键等用户输入装置，用户可以通过输入装置输入安装码，以确认网关输出的安装码。即：用户可以通过网关的输出获得安装码，将该安装码输入到目标设备上。
除了上述方式一和方式二以外，还可以有如下OBB验证方式：静态的安装码印在说明书上，用户看到说明书上的安装码后将该安装码输入到目标设备或者网关上。
通过本申请实施例的技术方案完成网关和目标设备之间相互认证后，进一步，所述方法还包括：所述网关通过所述第一平台云接收所述第二平台云发送的认证结果，向所述目标设备发送配置数据。
图5是本申请实施例提供的跨平台的设备配网方法的流程示意图二，如图5所示，所述跨平台的设备配网方法包括以下步骤：
步骤501：第二平台云通过第一平台云向网关发送第一确认值，所述第一确认值由所述网关转发给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的。
本申请实施例中，网关是指第一平台的网关，也就是说，网关可以与第一平台云进行直接通信。网关与第二平台云之间的通信需要通过第一平台云进行转发。
本申请实施例中，网关也可以称为蓝牙Mesh配网设备，目标设备也可以称为待配网蓝牙Mesh设备。
本申请实施例中，所述第二平台云通过第一平台云向网关发送第一确认值之前，所述第二平台云通过所述第一平台云接收所述网关发送的安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
本申请实施例中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。为了让目标设备实现对所述第一确认值进行校验，所述第二平台云通过所述第一平台云向所述网关发送所述第一随机数，所述第一随机数由所述网关转发给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
步骤502：所述第二平台云通过所述第一平台云接收所述网关发送的第二确认值，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
本申请实施例中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。为了让第二平台云实现对所述第二确认值进行校验，所述第二平台云通过所述第一平台云接收所述网关发送的所述第二随机数，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
在一个示例中，第二确认值的计算可以采用以下方式：
ConfirmationDevice＝AES-CMAC ConfirmationKey(RandomDevice||SetupCode)；
其中，ConfirmationDevice是第二确认值，RandomDevice是目标设备产生的第二随机数，SetupCode是安装码，加密算法为AES-CMAC，加密密钥为ConfirmationKey。
需要说明的是，目标设备可以采用其他的计算方式计算第二确认值。另外，目标设备也可以增加其他参数来计算第二确认值。
步骤503：所述第二平台云基于所述安装码对所述第二确认值进行校验。
具体地，所述第二平台云基于所述第二随机数和所述安装码计算第一校验值，将所述第一校验值和所述第二确认值进行比较；若所述第一校验值和所述第二确认值相同，则所述第二平台云确认对所述第二确认值校验成功；若所述第一校验值和所述第二确认值不同，则所述第二平台云确认对所述第二确认值校验失败。
需要说明的是，第二平台云对第二确认值进行验证时所采用的加密算法(即计算第一校验值)和计算参数与目标设备计算第二确认值所采用的加密算法和计算参数需要相同，如此才能够成功进行配网。
本申请实施例的技术方案是基于动态OOB验证方式。进一步，动态OOB验证方式有两种，一种是输出OOB验证方式，另一种输入OOB验证方式。以下对这两种方式进行说明。
方式一：所述输出OOB验证方式的情况下，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
方式二：所述输入OOB验证方式的情况下，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
除了上述方式一和方式二以外，还可以有如下OBB验证方式：静态的安装码印在说明书上，用户看到说明书上的安装码后将该安装码输入到目标设备或者网关上。
图6是本申请实施例提供的跨平台的设备配网方法的流程示意图三，如图6所示，所述跨平台的设备配网方法包括以下步骤：
步骤601：目标设备向网关发送第二确认值，所述第二确认值由所述网关通过第一平台云转发给第二平台云进行验证，其中，所述第二确认值由所述目标设备基于安装码计算得到，所述安装码为动态生成的或用户输入的。
本申请实施例中，网关是指第一平台的网关，也就是说，网关可以与第一平台云进行直接通信。网关与第二平台云之间的通信需要通过第一平台云进行转发。
本申请实施例中，网关也可以称为蓝牙Mesh配网设备，目标设备也可以称为待配网蓝牙Mesh设备。
本申请实施例中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。为了让第二平台云实现对所述第二确认值进行校验，所述目标设备将所述第二随机数发送给所述网关，所述第二随机数由所述网关通过所述第一平台云转发给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
步骤602：所述目标设备接收所述网关发送的第一确认值，其中，所述第一确认值由所述第二平台云基于所述安装码计算得到。
本申请实施例中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。为了让目标设备实现对所述第一确认值进行校验，所述目标设备接收所述网关发送的所述第一随机数，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
在一个示例中，第一确认值的计算可以采用以下方式：
ConfirmationProvisioner＝AES-CMAC ConfirmationKey(RandomProvisioner||SetupCode)；
其中，ConfirmationProvisioner是第一确认值，RandomProvisioner是第二平台云产生的第一随机数，SetupCode是安装码，加密算法为AES-CMAC，加密密钥为ConfirmationKey。
需要说明的是，第二平台云可以采用其他的计算方式计算第一确认值。另外，第二平台云也可以增加其他参数来计算第一确认值。
步骤603：所述目标设备基于所述安装码对所述第一确认值进行校验。
具体地，所述目标设备基于所述第一随机数和所述安装码计算第二校验值，将所述第二校验值和所述第一确认值进行比较；若所述第二校验值和所述第一确认值相同，则所述目标设备确认对所述第一确认值校验成功；若所述第二校验值和所述第一确认值不同，则所述目标设备确认对所述第一确认值校验失败。
需要说明的是，目标设备对第一确认值进行验证时(即计算第二校验值)所采用的加密算法和计算参数与第二平台云计算第一确认值所采用的加密算法和计算参数需要相同，如此才能够成 功进行配网。
本申请实施例的技术方案是基于动态OOB验证方式。进一步，动态OOB验证方式有两种，一种是输出OOB验证方式，另一种输入OOB验证方式。以下对这两种方式进行说明。
方式一：所述输出OOB验证方式的情况下，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
方式二：所述输入OOB验证方式的情况下，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
除了上述方式一和方式二以外，还可以有如下OBB验证方式：静态的安装码印在说明书上，用户看到说明书上的安装码后将该安装码输入到目标设备或者网关上。
以下结合具体流程对本申请实施例的技术方案进行举例说明。
图7是本申请实施例提供的跨平台的设备配网方法的流程示意图四，其中，A平台网关对应于本申请实施例中的网关，E公司设备对应于本申请实施例中的目标设备，A平台云对应于本申请实施例中的第一平台云，B平台云对应于本申请实施例中的第二平台云，如图7所示，所述跨平台的设备配网方法包括以下步骤：
步骤701：用户通过语音或APP激活A平台网关的设备扫描功能。
步骤702：E公司设备按规范发送广播包(包含UUID和CID)。
这里，E公司设备是指E公司基于B平台开发的设备，属于待配网蓝牙Mesh设备。
这里，广播包是指蓝牙Mesh未配网广播包，该广播包中携带E公司设备的UUID和B平台的CID。
步骤703：A平台向A平台云发送查询设备类型消息(包含UUID和CID)。
这里，A平台网关通过步骤702获取E公司设备发送的广播包后，将E公司设备的UUID和B平台的CID通过查询设备类型消息发送给A平台云，通过A平台云查询E公司设备的设备类型。
步骤703.1：A平台云基于CID判定E公司设备是否为A平台的设备，若不是，则执行步骤703.2。
这里，A平台云在收到A平台网关发送的查询设备类型消息后，通过该查询设备类型消息中的CID判断E公司设备是不是基于A平台开发的设备(即E公司设备是否为A平台的设备)。
步骤703.2：A平台云向互联互通服务器查询E公司设备对应的平台信息。
这里，若A平台云判断E公司设备不是基于A平台开发的设备，则需要其它平台(即开发E公司设备的平台)进行授权。为了查询开发E公司设备的平台，A平台通过互联互通服务器获取CID对应的B平台的信息(包含B平台认证服务器(Auth Server)等信息)。这里，A平台云向互联互通服务器查询E公司设备对应的平台信息时，向互联互通服务器提供CID，以便互联互通服务器通过CID查询B平台的信息。
步骤703.3：互联互通服务器向A平台云发送B平台的信息。
步骤703.4：A平台云向B平台云发送查询设备类型消息(包含B平台的信息、CID和UUID)。
这里，查询设备类型消息用于查询E公司设备的设备类型。
步骤703.5：B平台云向A平台云发送设备类型信息。
这里，设备类型信息用于确定E公司设备的设备类型。
可选地，B平台云根据设备类型信息，指示优先采用输出OOB验证方式和/或输入OOB验证方式。也就是说，在A平台网关和E公司设备支持输出OOB验证方式和/或输入OOB验证方式时，优先采用输出OOB验证方式和/或输入OOB验证方式，而不采用静态OOB验证方式和无OOB验证方式。
说明：输出OOB验证方式下，E公司设备输出安装码，用户在A平台网关上输入安装码。输入OOB验证方式下，A平台网关输出安装码，用户在E公司设备上输入安装码。本实施例OOB验证流程以输出OOB验证方式为例进行介绍，但方案也适用于输入OOB验证方式，区别仅在于输出和输入安装码的设备角色不同。
步骤704：A平台云向A平台网关发送设备类型信息。
可选地，B平台云根据设备类型信息，指示优先采用输出OOB验证方式和/或输入OOB验证方式。也就是说，在A平台网关和E公司设备支持输出OOB验证方式和/或输入OOB验证方式时，优先采用输出OOB验证方式和/或输入OOB验证方式，而不采用静态OOB验证方式和无OOB验证方式。
步骤705：A平台网关播报设备类型信息。
步骤706：用户在A平台网关上执行输入操作，以操作A平台网关连接E公司设备。
步骤707：A平台网关向E公司设备发送配置邀请(Provisioning Invite)消息。
可选地，A平台网关根据设备的设备类型信息和/或A平台云的指示(来自步骤704)，A平台网关指示优先采用输出OOB验证方式和/或输入OOB验证方式。
步骤708：E公司设备向A平台网关发送配置能力(Provisioning Capabilities)消息。
可选地，E公司设备指示优先采用输出OOB验证方式和/或输入OOB验证方式。
步骤709(可选步骤)：A平台网关根据设备类型信息、A平台云的指示(来自步骤704)和E公司设备的指示(来自步骤708)中的一个或多个，确定采用输出OOB验证方式或者输入OOB验证方式。
步骤710：A平台网关向E公司设备发送配置开始(Provisioning Start)消息。
可选地，该配置开始消息指示确定采用输出OOB验证方式或者输入OOB验证方式。
步骤711：A平台网关和E公司设备通过A平台云、B平台云完成公共密钥(Public Key)交换。
步骤712：E公司设备输出安装码。
这里，以输出OOB验证方式为例，E公司设备输出安装码，该安装码可以是一个动态或静态的随机值，例如E公司设备通过屏幕显示、声音、闪烁、震动、二维码、说明书等方式输出该随机值。
步骤713：用户在A平台网关上输入安装码。
这里，A平台网关带有屏幕、麦克风、摄像头、按键等用户输入装置，用户可以通过输入装置输入安装码，以确认E公司设备输出的安装码。
步骤714：A平台网关将安装码上报给A平台云。
步骤715：A平台云将安装码上报给B平台云。
步骤716：B平台云使用安装码计算第一确认值。
在一个示例中，第一确认值的计算可以采用以下方式：
ConfirmationProvisioner＝AES-CMAC ConfirmationKey(RandomProvisioner||SetupCode)；
其中，ConfirmationProvisioner是第一确认值，RandomProvisioner是B平台云产生的第一随机数，SetupCode是安装码，加密算法为AES-CMAC，加密密钥为ConfirmationKey。
需要说明的是，B平台云可以采用其他的计算方式计算第一确认值。另外，B平台云也可以增加其他参数来计算第一确认值。E公司设备对第一确认值进行验证时所采用的加密算法和计算参数与B平台云计算第一确认值所采用的加密算法和计算参数需要相同，如此才能够成功进行配网。
步骤717：B平台云向A平台云发送认证信息(包含第一确认值和第一随机数)。
步骤718：A平台云向A平台网关发送认证信息(包含第一确认值和第一随机数)。
步骤719：A平台网关向E公司设备发送第一确认值。
步骤720：E公司设备使用安装码计算第二确认值。
在一个示例中，第二确认值的计算可以采用以下方式：
ConfirmationDevice＝AES-CMAC ConfirmationKey(RandomDevice||SetupCode)；
其中，ConfirmationDevice是第二确认值，RandomDevice是目标设备产生的第二随机数，SetupCode是安装码，加密算法为AES-CMAC，加密密钥为ConfirmationKey。
需要说明的是，E公司设备可以采用其他的计算方式计算第二确认值。另外，E公司设备也可以增加其他参数来计算第二确认值。B平台云对第二确认值进行验证时所采用的加密算法和计算参数与E公司设备计算第二确认值所采用的加密算法和计算参数需要相同，如此才能够成功进行配网。
步骤721：E公司设备向A平台网关发送第二确认值。
步骤722：A平台网关向E公司设备发送第一随机数。
步骤723：E公司设备基于第一随机数和安装码对第一确认值进行校验。
这里，E公司设备采用步骤716相同的计算方法计算验证值，并与步骤719得到的第一确认值比较是否相同，相同的情况下，执行步骤724。
步骤724：E公司设备向A平台网关发送第二随机数。
步骤725：A平台网向A平台云发送设备认证信息(包含第二确认值和第二随机数)。
步骤726：A平台云向B平台云发送设备认证信息(包含第二确认值和第二随机数)。
步骤727：B平台云基于第二随机数和安装码对第二确认值进行校验。
这里，B平台云采用步骤720相同的计算方法计算验证值，并与步骤726得到的第二确认值比较是否相同，相同的情况下，执行步骤728。
步骤728：B平台云向A平台云发送认证结果(包含E公司设备的设备信息)。
步骤729：A平台云存储E公司设备的设备信息。
这里，设备信息包含设备支持的控制功能和控制指令等信息。
步骤730：A平台云向A平台网关发送认证结果。
步骤731：A平台网关向E公司设备发送配置数据。
步骤732：A平台网关播报认证结果。
通过上述流程，E公司设备正式成为蓝牙Mesh网络的节点，完成配置过程。
在一可选实施例中，E公司设备进入配网模式后输出安装码，用户在A平台网关上操作输入安装码。参照图7，可以将步骤712和步骤713移至步骤703之前执行。将步骤714删除，A平台网关通过步骤703向A平台云上传安装码。将步骤715删除，A平台云通过步骤703.4向B平台云发送安装码，其他流程保持不变。
图8是本申请实施例提供的跨平台的设备配网装置的结构组成示意图一，应用于网关，所述装置包括：
接收单元801，用于通过第一平台云接收第二平台云发送的第一确认值；
发送单元802，用于将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
所述接收单元801，还用于接收目标设备发送的第二确认值；
所述发送单元802，还用于将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
在一可选方式中，所述发送单元802，还用于通过所述第一平台云向所述第二平台云发送所述安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
在一可选方式中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
在一可选方式中，所述接收单元801，还用于通过所述第一平台云接收所述第二平台云发送的所述第一随机数；
所述发送单元802，还用于将所述第一随机数发送给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
在一可选方式中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
在一可选方式中，所述接收单元801，还用于接收所述目标设备发送的所述第二随机数；
所述发送单元802，还用于将所述第二随机数通过所述第一平台云发送给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
在一可选方式中，所述接收单元801，还用于通过所述第一平台云接收所述第二平台云发送的所述目标设备的设备类型信息；
所述发送单元802，还用于向所述目标设备发送邀请消息；
所述接收单元801，还用于接收所述目标设备发送的配置能力消息；
所述发送单元802，还用于向所述目标设备发送配置开始消息；
其中，所述设备类型信息、所述邀请消息和所述配置能力消息中的至少之一携带第一指示信息，所述第一指示信息用于指示优先采用输出OOB验证方式和/或输入OOB验证方式；所述配置开始消息携带第二指示信息，所述第二指示信息用于指示确定采用OOB验证方式或者输入OOB验证方式。
在一可选方式中，所述装置还包括：
确定单元(图中未示出)，用于基于以下至少之一，确定采用OOB验证方式或者输入OOB验证方式：所述目标设备的设备类型信息、所述设备类型信息中携带的第一指示信息、所述配置能力消息中携带的第一指示信息。
在一可选方式中，所述输出OOB验证方式的情况下，
所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
在一可选方式中，所述输入OOB验证方式的情况下，
所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
在一可选方式中，所述接收单元801，还用于通过所述第一平台云接收所述第二平台云发送的认证结果；
所述发送单元802，还用于向所述目标设备发送配置数据。
本领域技术人员应当理解，本申请实施例的上述跨平台的设备配网装置的相关描述可以参照本 申请实施例的跨平台的设备配网方法的相关描述进行理解。
图9是本申请实施例提供的跨平台的设备配网装置的结构组成示意图二，应用于第二平台云，所述装置包括：
发送单元901，用于通过第一平台云向网关发送第一确认值，所述第一确认值由所述网关转发给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
接收单元902，用于通过所述第一平台云接收所述网关发送的第二确认值，其中，所述第二确认值由所述目标设备基于所述安装码计算得到；
校验单元903，用于基于所述安装码对所述第二确认值进行校验。
在一可选方式中，所述接收单元902，还用于通过所述第一平台云接收所述网关发送的安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
在一可选方式中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
在一可选方式中，所述发送单元901，还用于通过所述第一平台云向所述网关发送所述第一随机数，所述第一随机数由所述网关转发给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
在一可选方式中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
在一可选方式中，所述接收单元902，还用于通过所述第一平台云接收所述网关发送的所述第二随机数，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
在一可选方式中，所述校验单元903，用于基于所述第二随机数和所述安装码计算第一校验值，将所述第一校验值和所述第二确认值进行比较；若所述第一校验值和所述第二确认值相同，则确认对所述第二确认值校验成功；若所述第一校验值和所述第二确认值不同，则确认对所述第二确认值校验失败。
在一可选方式中，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
在一可选方式中，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
本领域技术人员应当理解，本申请实施例的上述跨平台的设备配网装置的相关描述可以参照本申请实施例的跨平台的设备配网方法的相关描述进行理解。
图10是本申请实施例提供的跨平台的设备配网装置的结构组成示意图三，应用于目标设备，所述装置包括：
发送单元1001，用于向网关发送第二确认值，所述第二确认值由所述网关通过第一平台云转发给第二平台云进行验证，其中，所述第二确认值由所述目标设备基于安装码计算得到，所述安装码为动态生成的或用户输入的；
接收单元1002，用于接收所述网关发送的第一确认值，其中，所述第一确认值由所述第二平台云基于所述安装码计算得到；
校验单元1003，用于对所述第一确认值进行校验。
在一可选方式中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
在一可选方式中，所述接收单元1002，还用于接收所述网关发送的所述第一随机数，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
在一可选方式中，所述校验单元1003，用于基于所述第一随机数和所述安装码计算第二校验值，将所述第二校验值和所述第一确认值进行比较；若所述第二校验值和所述第一确认值相同，则确认对所述第一确认值校验成功；若所述第二校验值和所述第一确认值不同，则确认对所述第一确认值校验失败。
在一可选方式中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
在一可选方式中，所述发送单元1001，还用于将所述第二随机数发送给所述网关，所述第二随机数由所述网关通过所述第一平台云转发给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
在一可选方式中，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
在一可选方式中，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
本领域技术人员应当理解，本申请实施例的上述跨平台的设备配网装置的相关描述可以参照本申请实施例的跨平台的设备配网方法的相关描述进行理解。
本发明实施例还提供一种网关，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器用于运行所述计算机程序时，执行上述跨平台的设备配网方法的步骤。
本发明实施例还提供一种平台云，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器用于运行所述计算机程序时，执行上述跨平台的设备配网方法的步骤。
本发明实施例还提供一种设备，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器用于运行所述计算机程序时，执行上述跨平台的设备配网方法的步骤。
图11是本发明实施例的电子设备(网关、第二平台云、设备)的硬件组成结构示意图，电子设备1100包括：至少一个处理器1101、存储器1102和至少一个网络接口1104。电子设备1100中的各个组件通过总线系统1105耦合在一起。可理解，总线系统1105用于实现这些组件之间的连接通信。总线系统1105除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图11中将各种总线都标为总线系统1105。
可以理解，存储器1102可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是ROM、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本发明实施例描述的存储器1102旨在包括但不限于这些和任意其它适合类型的存储器。
本发明实施例中的存储器1102用于存储各种类型的数据以支持电子设备1100的操作。这些数据的示例包括：用于在电子设备1100上操作的任何计算机程序，如应用程序11022。实现本发明实施例方法的程序可以包含在应用程序11022中。
上述本发明实施例揭示的方法可以应用于处理器1101中，或者由处理器1101实现。处理器1101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1101中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1101可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器1101可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器1102，处理器1101读取存储器1102中的信息，结合其硬件完成前述方法的步骤。
在示例性实施例中，电子设备1100可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、FPGA、通用处理器、控制器、MCU、MPU、或其他电子元件实现，用于执行前述方法。
本申请实施例还提供了一种存储介质，用于存储计算机程序。
可选的，该存储介质可应用于本申请实施例中的网关，并且该计算机程序使得计算机执行本申请实施例网关执行的各个方法中的相应流程，为了简洁，在此不再赘述。
可选的，该存储介质可应用于本申请实施例中的第二平台云，并且该计算机程序使得计算机执行本申请实施例的第二平台云执行的各个方法中的相应流程，为了简洁，在此不再赘述。
可选的，该存储介质可应用于本申请实施例中的目标设备，并且该计算机程序使得计算机执行本申请实施例的目标设执行的各个方法中的相应流程，为了简洁，在此不再赘述。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (58)

  1. 一种跨平台的设备配网方法，所述方法包括：
    网关通过第一平台云接收第二平台云发送的第一确认值，将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
    所述网关接收目标设备发送的第二确认值，将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
  2. 根据权利要求1所述的方法，其中，所述网关通过第一平台云接收第二平台云发送的第一确认值之前，所述方法还包括：
    所述网关通过所述第一平台云向所述第二平台云发送所述安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
  3. 根据权利要求1或2所述的方法，其中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
  4. 根据权利要求3所述的方法，其中，所述方法还包括：
    所述网关通过所述第一平台云接收所述第二平台云发送的所述第一随机数；
    所述网关将所述第一随机数发送给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
  5. 根据权利要求1至4中任一项所述的方法，其中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
  6. 根据权利要求5所述的方法，其中，所述方法还包括：
    所述网关接收所述目标设备发送的所述第二随机数；
    所述网关将所述第二随机数通过所述第一平台云发送给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
  7. 根据权利要求1至6中任一项所述的方法，其中，所述方法还包括：
    所述网关通过所述第一平台云接收所述第二平台云发送的所述目标设备的设备类型信息；
    所述网关向所述目标设备发送邀请消息；
    所述网关接收所述目标设备发送的配置能力消息；
    所述网关向所述目标设备发送配置开始消息；
    所述网关通过所述第一平台云和所述第二平台云与所述目标设备，进行公共密钥交换；
    其中，所述设备类型信息、所述邀请消息和所述配置能力消息中的至少之一携带第一指示信息，所述第一指示信息用于指示优先采用输出带外OOB验证方式和/或输入OOB验证方式；所述配置开始消息携带第二指示信息，所述第二指示信息用于指示确定采用OOB验证方式或者输入OOB验证方式。
  8. 根据权利要求7所述的方法，其中，所述网关接收所述目标设备发送的配置能力消息之后，所述方法还包括：
    所述网关基于以下至少之一，确定采用OOB验证方式或者输入OOB验证方式：所述目标设备的设备类型信息、所述设备类型信息中携带的第一指示信息、所述配置能力消息中携带的第一指示信息。
  9. 根据权利要求7或8所述的方法，其中，所述输出OOB验证方式的情况下，
    所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
  10. 根据权利要求7或8所述的方法，其中，所述输入OOB验证方式的情况下，
    所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
  11. 根据权利要求1至10中任一项所述的方法，其中，所述方法还包括：
    所述网关通过所述第一平台云接收所述第二平台云发送的认证结果，向所述目标设备发送配置数据。
  12. 一种跨平台的设备配网方法，所述方法包括：
    第二平台云通过第一平台云向网关发送第一确认值，所述第一确认值由所述网关转发给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动 态生成的或用户输入的；
    所述第二平台云通过所述第一平台云接收所述网关发送的第二确认值，其中，所述第二确认值由所述目标设备基于所述安装码计算得到；
    所述第二平台云基于所述安装码对所述第二确认值进行校验。
  13. 根据权利要求12所述的方法，其中，所述第二平台云通过第一平台云向网关发送第一确认值之前，所述方法还包括：
    所述第二平台云通过所述第一平台云接收所述网关发送的安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
  14. 根据权利要求12或13所述的方法，其中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
  15. 根据权利要求14所述的方法，其中，所述方法还包括：
    所述第二平台云通过所述第一平台云向所述网关发送所述第一随机数，所述第一随机数由所述网关转发给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
  16. 根据权利要求12至15中任一项所述的方法，其中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
  17. 根据权利要求16所述的方法，其中，所述方法还包括：
    所述第二平台云通过所述第一平台云接收所述网关发送的所述第二随机数，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
  18. 根据权利要求17所述的方法，其中，所述第二平台云基于所述安装码对所述第二确认值进行校验，包括：
    所述第二平台云基于所述第二随机数和所述安装码计算第一校验值，将所述第一校验值和所述第二确认值进行比较；
    若所述第一校验值和所述第二确认值相同，则所述第二平台云确认对所述第二确认值校验成功；
    若所述第一校验值和所述第二确认值不同，则所述第二平台云确认对所述第二确认值校验失败。
  19. 根据权利要求12至18中任一项所述的方法，其中，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
  20. 根据权利要求12至18中任一项所述的方法，其中，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
  21. 一种跨平台的设备配网方法，所述方法包括：
    目标设备向网关发送第二确认值，所述第二确认值由所述网关通过第一平台云转发给第二平台云进行验证，其中，所述第二确认值由所述目标设备基于安装码计算得到，所述安装码为动态生成的或用户输入的；
    所述目标设备接收所述网关发送的第一确认值，其中，所述第一确认值由所述第二平台云基于所述安装码计算得到；
    所述目标设备基于所述安装码对所述第一确认值进行校验。
  22. 根据权利要求21所述的方法，其中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
  23. 根据权利要求22所述的方法，其中，所述方法还包括：
    所述目标设备接收所述网关发送的所述第一随机数，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
  24. 根据权利要求23所述的方法，其中，所述目标设备基于所述安装码对所述第一确认值进行校验，包括：
    所述目标设备基于所述第一随机数和所述安装码计算第二校验值，将所述第二校验值和所述第一确认值进行比较；
    若所述第二校验值和所述第一确认值相同，则所述目标设备确认对所述第一确认值校验成功；
    若所述第二校验值和所述第一确认值不同，则所述目标设备确认对所述第一确认值校验失败。
  25. 根据权利要求21至24中任一项所述的方法，其中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
  26. 根据权利要求25所述的方法，其中，所述方法还包括：
    所述目标设备将所述第二随机数发送给所述网关，所述第二随机数由所述网关通过所述第一平台云转发给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
  27. 根据权利要求21至26中任一项所述的方法，其中，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
  28. 根据权利要求21至26中任一项所述的方法，其中，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
  29. 一种跨平台的设备配网装置，应用于网关，所述装置包括：
    接收单元，用于通过第一平台云接收第二平台云发送的第一确认值；
    发送单元，用于将所述第一确认值发送给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
    所述接收单元，还用于接收目标设备发送的第二确认值；
    所述发送单元，还用于将所述第二确认值通过所述第一平台云发送给所述第二平台云进行校验，其中，所述第二确认值由所述目标设备基于所述安装码计算得到。
  30. 根据权利要求29所述的装置，其中，所述发送单元，还用于通过所述第一平台云向所述第二平台云发送所述安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
  31. 根据权利要求29或30所述的装置，其中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
  32. 根据权利要求31所述的装置，其中，
    所述接收单元，还用于通过所述第一平台云接收所述第二平台云发送的所述第一随机数；
    所述发送单元，还用于将所述第一随机数发送给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
  33. 根据权利要求29至32中任一项所述的装置，其中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
  34. 根据权利要求33所述的装置，其中，
    所述接收单元，还用于接收所述目标设备发送的所述第二随机数；
    所述发送单元，还用于将所述第二随机数通过所述第一平台云发送给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
  35. 根据权利要求29至34中任一项所述的装置，其中，
    所述接收单元，还用于通过所述第一平台云接收所述第二平台云发送的所述目标设备的设备类型信息；
    所述发送单元，还用于向所述目标设备发送邀请消息；
    所述接收单元，还用于接收所述目标设备发送的配置能力消息；
    所述发送单元，还用于向所述目标设备发送配置开始消息；
    其中，所述设备类型信息、所述邀请消息和所述配置能力消息中的至少之一携带第一指示信息，所述第一指示信息用于指示优先采用输出OOB验证方式和/或输入OOB验证方式；所述配置开始消息携带第二指示信息，所述第二指示信息用于指示确定采用OOB验证方式或者输入OOB验证方式。
  36. 根据权利要求35所述的装置，其中，所述装置还包括：
    确定单元，用于基于以下至少之一，确定采用OOB验证方式或者输入OOB验证方式：所述目标设备的设备类型信息、所述设备类型信息中携带的第一指示信息、所述配置能力消息中携带的第一指示信息。
  37. 根据权利要求35或36所述的装置，其中，所述输出OOB验证方式的情况下，
    所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
  38. 根据权利要求35或36所述的装置，其中，所述输入OOB验证方式的情况下，
    所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
  39. 根据权利要求29至38中任一项所述的装置，其中，
    所述接收单元，还用于通过所述第一平台云接收所述第二平台云发送的认证结果；
    所述发送单元，还用于向所述目标设备发送配置数据。
  40. 一种跨平台的设备配网装置，应用于第二平台云，所述装置包括：
    发送单元，用于通过第一平台云向网关发送第一确认值，所述第一确认值由所述网关转发给目标设备进行校验，其中，所述第一确认值由所述第二平台云基于安装码计算得到，所述安装码为动态生成的或用户输入的；
    接收单元，用于通过所述第一平台云接收所述网关发送的第二确认值，其中，所述第二确认值由所述目标设备基于所述安装码计算得到；
    校验单元，用于基于所述安装码对所述第二确认值进行校验。
  41. 根据权利要求40所述的装置，其中，所述接收单元，还用于通过所述第一平台云接收所述网关发送的安装码，其中，所述安装码用于所述第二平台云计算所述第一确认值。
  42. 根据权利要求40或41所述的装置，其中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
  43. 根据权利要求42所述的装置，其中，所述发送单元，还用于通过所述第一平台云向所述网关发送所述第一随机数，所述第一随机数由所述网关转发给所述目标设备，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
  44. 根据权利要求40至43中任一项所述的装置，其中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
  45. 根据权利要求44所述的装置，其中，所述接收单元，还用于通过所述第一平台云接收所述网关发送的所述第二随机数，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
  46. 根据权利要求45所述的装置，其中，所述校验单元，用于基于所述第二随机数和所述安装码计算第一校验值，将所述第一校验值和所述第二确认值进行比较；若所述第一校验值和所述第二确认值相同，则确认对所述第二确认值校验成功；若所述第一校验值和所述第二确认值不同，则确认对所述第二确认值校验失败。
  47. 根据权利要求40至46中任一项所述的装置，其中，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
  48. 根据权利要求40至46中任一项所述的装置，其中，所述安装码由所述网关输出，且所述安装码由用户在所述目标设备上输入。
  49. 一种跨平台的设备配网装置，应用于目标设备，所述装置包括：
    发送单元，用于向网关发送第二确认值，所述第二确认值由所述网关通过第一平台云转发给第二平台云进行验证，其中，所述第二确认值由所述目标设备基于安装码计算得到，所述安装码为动态生成的或用户输入的；
    接收单元，用于接收所述网关发送的第一确认值，其中，所述第一确认值由所述第二平台云基于所述安装码计算得到；
    校验单元，用于对所述第一确认值进行校验。
  50. 根据权利要求49所述的装置，其中，所述第一确认值由所述第二平台云基于安装码和第一随机数计算得到，其中，所述第一随机数由所述第二平台云产生。
  51. 根据权利要求50所述的装置，其中，所述接收单元，还用于接收所述网关发送的所述第一随机数，其中，所述第一随机数和所述安装码用于所述目标设备对所述第一确认值进行校验。
  52. 根据权利要求51所述的装置，其中，所述校验单元，用于基于所述第一随机数和所述安装码计算第二校验值，将所述第二校验值和所述第一确认值进行比较；若所述第二校验值和所述第一确认值相同，则确认对所述第一确认值校验成功；若所述第二校验值和所述第一确认值不同，则确认对所述第一确认值校验失败。
  53. 根据权利要求49至52中任一项所述的装置，其中，所述第二确认值由所述目标设备基于所述安装码和第二随机数计算得到，所述第二随机数由所述目标设备产生。
  54. 根据权利要求53所述的装置，其中，所述发送单元，还用于将所述第二随机数发送给所述网关，所述第二随机数由所述网关通过所述第一平台云转发给所述第二平台云，其中，所述第二随机数和所述安装码用于所述第二平台云对所述第二确认值进行校验。
  55. 根据权利要求49至54中任一项所述的装置，其中，所述安装码由所述目标设备输出，且所述安装码由用户在所述网关上输入。
  56. 根据权利要求49至54中任一项所述的装置，其中，所述安装码由所述网关输出，且所 述安装码由用户在所述目标设备上输入。
  57. 一种电子设备，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求1至11中任一项所述的方法，或者权利要求12至20中任一项所述的方法，或者权利要求21至28中任一项所述的方法。
  58. 一种存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1至11中任一项所述的方法，或者权利要求12至20中任一项所述的方法，或者权利要求21至28中任一项所述的方法。
PCT/CN2020/103590 2020-07-22 2020-07-22 一种跨平台的设备配网方法及装置、电子设备 WO2022016426A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2020/103590 WO2022016426A1 (zh) 2020-07-22 2020-07-22 一种跨平台的设备配网方法及装置、电子设备
CN202080100270.3A CN115462105A (zh) 2020-07-22 2020-07-22 一种跨平台的设备配网方法及装置、电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/103590 WO2022016426A1 (zh) 2020-07-22 2020-07-22 一种跨平台的设备配网方法及装置、电子设备

Publications (1)

Publication Number Publication Date
WO2022016426A1 true WO2022016426A1 (zh) 2022-01-27

Family

ID=79728451

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/103590 WO2022016426A1 (zh) 2020-07-22 2020-07-22 一种跨平台的设备配网方法及装置、电子设备

Country Status (2)

Country Link
CN (1) CN115462105A (zh)
WO (1) WO2022016426A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1661959A (zh) * 2004-02-27 2005-08-31 微软公司 设备的安全性关联
US20120322466A1 (en) * 2011-06-17 2012-12-20 Qualcomm Incorporated Out-of-band paging with group identifier to reduce mobile detection latency
US20160087949A1 (en) * 2014-09-24 2016-03-24 Intel Corporation Establishing secure digital relationship using symbology
US20190044794A1 (en) * 2018-06-27 2019-02-07 Intel Corporation Edge or fog gateway assisted ide redirection for failover remote management applications
CN110418322A (zh) * 2019-08-09 2019-11-05 四川虹美智能科技有限公司 基于蓝牙Mesh网络的配网方法及系统、一种节点
CN110505606A (zh) * 2018-05-18 2019-11-26 阿里巴巴集团控股有限公司 蓝牙Mesh网络及其配网鉴权方法、设备和存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1661959A (zh) * 2004-02-27 2005-08-31 微软公司 设备的安全性关联
US20120322466A1 (en) * 2011-06-17 2012-12-20 Qualcomm Incorporated Out-of-band paging with group identifier to reduce mobile detection latency
US20160087949A1 (en) * 2014-09-24 2016-03-24 Intel Corporation Establishing secure digital relationship using symbology
CN110505606A (zh) * 2018-05-18 2019-11-26 阿里巴巴集团控股有限公司 蓝牙Mesh网络及其配网鉴权方法、设备和存储介质
US20190044794A1 (en) * 2018-06-27 2019-02-07 Intel Corporation Edge or fog gateway assisted ide redirection for failover remote management applications
CN110418322A (zh) * 2019-08-09 2019-11-05 四川虹美智能科技有限公司 基于蓝牙Mesh网络的配网方法及系统、一种节点

Also Published As

Publication number Publication date
CN115462105A (zh) 2022-12-09

Similar Documents

Publication Publication Date Title
WO2020220865A1 (zh) 网络功能服务的身份校验方法及相关装置
US11429960B2 (en) Network configuration management for networked client devices using a distributed ledger service
US11284258B1 (en) Managing access of a computing device to a network
WO2021098140A1 (zh) 区块链网络部署方法、电子装置及计算机可读存储介质
US11770702B2 (en) Session establishment method and means and communication system
JP5643292B2 (ja) 複数のドメインのシステムおよびドメイン所有権
WO2019011179A1 (zh) 证书管理方法、系统、网络设备及计算机可读存储介质
WO2019105470A1 (zh) 一种用户群组的建立方法及装置
WO2019028837A1 (zh) Pdu类型的设置方法、ue策略的设置方法及相关实体
WO2020147441A1 (zh) 信息更新方法、装置、计算机设备及存储介质
WO2021197347A1 (zh) 通信系统、方法及装置
US11989284B2 (en) Service API invoking method and related apparatus
WO2019056971A1 (zh) 一种鉴权方法及设备
WO2018001023A1 (zh) 一种云终端登录虚拟桌面方法及装置
WO2022016426A1 (zh) 一种跨平台的设备配网方法及装置、电子设备
US11575667B1 (en) System and method for secure communications
CN114650182B (zh) 身份认证方法、系统、装置、网关设备、设备和终端
WO2022016435A1 (zh) 接入认证方法、装置、设备及存储介质
CN114845355A (zh) 网络接入方法及装置、终端设备、网络设备、存储介质
CN114666155A (zh) 设备接入方法、系统、装置、物联网设备和网关设备
WO2022067831A1 (zh) 一种建立安全通信方法及装置
WO2016197637A1 (zh) 一种实现远程访问的方法、AllJoyn网关代理、云服务器及移动设备
WO2021035740A1 (zh) 访问控制方法、服务器、访问设备及存储介质
WO2016165443A1 (zh) 一种保护机器类通信设备的方法、网络实体及mtc设备
WO2024094105A1 (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: 20945892

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20945892

Country of ref document: EP

Kind code of ref document: A1