WO2022041151A1 - 设备验证方法、设备和云端 - Google Patents
设备验证方法、设备和云端 Download PDFInfo
- Publication number
- WO2022041151A1 WO2022041151A1 PCT/CN2020/112286 CN2020112286W WO2022041151A1 WO 2022041151 A1 WO2022041151 A1 WO 2022041151A1 CN 2020112286 W CN2020112286 W CN 2020112286W WO 2022041151 A1 WO2022041151 A1 WO 2022041151A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- cloud
- information
- key
- verified
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
Definitions
- the present application relates to the field of communications, and more particularly, to a device verification method, device and cloud.
- the Wi-Fi device can open a service access point (softAP for short) implemented by software and broadcast beacon (Beacon) data.
- the hardware part of the Wi-Fi device can include a standard wireless network card, but it can provide the same signal transfer, routing and other functions as the AP through the driver.
- An access device (such as a mobile phone) can start scanning and receive the Beacon data.
- the access device can connect to the softAP through the Wi-Fi protocol and communicate with the Wi-Fi device, set the SSID and password of the home Wi-Fi network to the Wi-Fi device, and the Wi-Fi device will use the home Wi-Fi
- the SSID and password of the Fi network establishes a connection with the AP of the home Wi-Fi network.
- the smart device can only communicate with the cloud service after accessing the network (such as connecting to the home Wi-Fi network) to perform authentication, which may have security risks, such as counterfeit devices It is possible to obtain the Wi-Fi password of the user's home network.
- the embodiments of the present application provide a device verification method, device, and cloud, which can improve the security of the network distribution process.
- the embodiment of the present application provides a device verification method, including:
- the first device obtains the information to be verified, and the information to be verified includes the device identification and encrypted data of the second device;
- the first device sends the to-be-verified information to the cloud to decrypt and verify the encrypted data.
- the embodiment of the present application provides a device verification method, including:
- the cloud of the first device receives the information to be verified from the first device, and the information to be verified includes the device identification and encrypted data of the second device;
- the cloud of the first device decrypts and verifies the encrypted data.
- the embodiment of the present application provides a device verification method, including:
- the cloud of the second device receives the information to be verified, and the information to be verified includes the device identification and encrypted data of the second device;
- the cloud of the second device decrypts and verifies the encrypted data based on the device identification.
- the embodiment of the present application provides a device verification method, including:
- the second device encrypts the first data based on the first secret key to obtain encrypted data
- the second device sends information to be verified to the first device, so as to send the information to be verified to the cloud through the first device to decrypt and verify the encrypted data, the information to be verified includes the device identification of the second device and the encrypted data.
- Embodiments of the present application provide a first device, including:
- an acquisition unit configured to acquire information to be verified, the information to be verified includes the device identification and encrypted data of the second device;
- a sending unit configured to send the information to be verified to the cloud to decrypt and verify the encrypted data.
- Embodiments of the present application provide a first cloud, including:
- a receiving unit for receiving the information to be verified from the first equipment, the information to be verified includes the device identification and encrypted data of the second equipment;
- a processing unit for decrypting and verifying the encrypted data.
- the embodiment of the present application provides a second cloud, including:
- a receiving unit configured to receive the information to be verified, the information to be verified includes the device identification and encrypted data of the second device;
- the processing unit is used for decrypting and verifying the encrypted data based on the device identification.
- An embodiment of the present application provides a second device, including:
- an encryption unit configured to encrypt the first data based on the first secret key to obtain encrypted data
- a sending unit configured to send the information to be verified to the first device, so as to send the information to be verified to the cloud through the first device to decrypt and verify the encrypted data, the information to be verified includes the device identification of the second device and the encrypted data.
- Embodiments of the present application provide a communication device including a processor and a memory.
- the memory is used for storing a computer program
- the processor is used for calling and running the computer program stored in the memory, so that the communication device executes any one of the above-mentioned device verification methods.
- An embodiment of the present application provides a chip for implementing any of the foregoing device verification methods.
- the chip includes: a processor for invoking and running a computer program from the memory, so that the device installed with the chip executes any one of the above-mentioned device verification methods.
- Embodiments of the present application provide a computer-readable storage medium for storing a computer program, which, when the computer program is run by a device, causes the device to execute any one of the above-mentioned device verification methods.
- An embodiment of the present application provides a computer program product, including computer program instructions, and the computer program instructions cause a computer to execute any one of the foregoing device verification methods.
- An embodiment of the present application provides a computer program, which, when running on a computer, enables the computer to execute any one of the foregoing device verification methods.
- the first device sends the to-be-verified information of the second device to the cloud for decryption and verification, and the device can be verified before being configured to access the network, thereby improving the security in the network distribution process.
- FIG. 1 is a schematic diagram of an application scenario according to an embodiment of the present application.
- FIG. 2 is a schematic flowchart of a device verification method according to an embodiment of the present application.
- FIG. 3 is a schematic flowchart of a device verification method according to another embodiment of the present application.
- FIG. 4 is a schematic flowchart of a device verification method according to another embodiment of the present application.
- FIG. 5 is a schematic flowchart of a device verification method according to another embodiment of the present application.
- FIG. 6 is a schematic diagram of an application example of a device verification method according to another embodiment of the present application.
- FIG. 7 is a schematic block diagram of a first device according to an embodiment of the present application.
- FIG. 8 is a schematic block diagram of a first cloud according to an embodiment of the present application.
- FIG. 9 is a schematic block diagram of a second cloud according to an embodiment of the present application.
- FIG. 10 is a schematic block diagram of a second device according to an embodiment of the present application.
- FIG. 11 is a schematic block diagram of a communication device according to an embodiment of the present application.
- FIG. 12 is a schematic block diagram of a chip according to an embodiment of the present application.
- FIG. 13 is a schematic block diagram of a communication system according to an embodiment of the present application.
- the technical solutions of the embodiments of the present application may be applied to, for example, the communication system shown in FIG. 1 .
- the communication system may include a cloud service platform 110, an application gateway 120, a control terminal 130, an application terminal 140, and the like.
- Cloud service platforms may be referred to as cloud services, cloud servers, cloud platforms, clouds, and the like.
- the cloud service platforms of the control terminal and the application terminal may be the same or different.
- the smart home cloud service platform can organize and flexibly call various smart home information resources through the network to realize the processing method of large-scale computing of smart home information.
- Cloud service platforms can use technologies such as distributed computing and virtual resource management to centralize decentralized ICT (Information Communications Technology, information, communication and technology) resources (including computing and storage, application operating platforms, software, etc.) through the network to form a shared smart home resource pool and provide services to users in a dynamic on-demand and measurable manner.
- the smart home cloud service platform can connect with various electrical appliances, home facilities and sensing devices in the home space based on the public communication network and the home local area network, and provide various home application services.
- the application gateway can be connected to the public communication network and smart home functional terminals at the same time, and has functions such as smart home terminal access management, data exchange, protocol conversion and application services.
- Application gateways can be used for home network formation, and can support wired, wireless or hybrid methods.
- the application gateway may comprise a router of a home Wi-Fi network.
- the control terminal comprehensively manages or controls each home application terminal in a local or remote manner, mainly to convert the user's operation or control behavior into actual command signals, and to coordinate the intelligent application service resources of the cloud service platform , and send it to the application terminal for it to perform specific operations.
- the control terminal may be installed with an application program (Application, APP) for controlling network configuration, and the APP of the control terminal may control the network configuration of the application terminal through interactive instructions.
- a control terminal may be called a Wi-Fi access device in a Wi-Fi network.
- the application terminal can be connected to the home network, can execute the interactive instructions of the control terminal, and meet the needs of people for the intelligent application of the living environment.
- Application terminals include, but are not limited to, various smart home appliances such as refrigerators, washing machines, air conditioners, televisions, projectors, and the like.
- the application terminal may be called a Wi-Fi device in a Wi-Fi network.
- the "instruction" mentioned in the embodiments of the present application may be a direct instruction, an indirect instruction, or an associated relationship.
- a indicates B it can indicate that A directly indicates B, for example, B can be obtained through A; it can also indicate that A indicates B indirectly, such as A indicates C, and B can be obtained through C; it can also indicate that there is an association between A and B relation.
- corresponding may indicate that there is a direct or indirect corresponding relationship between the two, or may indicate that there is an associated relationship between the two, or indicate and be instructed, configure and be instructed configuration, etc.
- FIG. 2 is a schematic flowchart of a device verification method 200 according to an embodiment of the present application.
- the method can optionally be applied to the system shown in Figure 1, but is not limited thereto.
- the method includes at least some of the following.
- the first device acquires information to be verified, and the information to be verified includes the device identification and encrypted data of the second device;
- the first device sends the to-be-verified information to the cloud to decrypt and verify the encrypted data.
- the first device may include a control terminal with a network configuration function, such as a mobile phone.
- an application program for network distribution may be installed in the first device, and the device verification method performed by the first device in the embodiment of the present application may be executed through the application program.
- the second device may be a device that needs to access the network, such as an application terminal such as a smart home appliance and a vehicle controller.
- the cloud (which may also be referred to as cloud, cloud service, cloud platform, cloud service platform, etc.) may include the cloud of the first device and/or the cloud of the second device. For example, if the first device and the second device belong to the same manufacturer, they can access the same cloud. If the first device and the second device belong to different manufacturers, they can access different clouds.
- preset data may be stored in advance in the second device, and encrypted data may be obtained by performing encryption calculation on the preset data by using a symmetric encryption or an asymmetric encryption algorithm.
- some auxiliary data for preventing replay attacks can also be obtained by using a specific algorithm.
- encrypting the combined data using a symmetric encryption or asymmetric encryption algorithm can obtain encrypted data.
- the encrypted data can be considered as the electronic signature of the second device.
- the key used in the encryption calculation in the second device may be a fixed key or a non-fixed key.
- the private key set can be stored in the second device, and the public key set can be stored in the cloud.
- a private key can be selected from the private key set for encryption, and in the cloud, the public key corresponding to the private key can be used for decryption.
- the first device obtains the information to be verified, including at least one of the following:
- the first device receives a broadcast message, and the broadcast message includes the to-be-verified information
- the first device scans the graphic code to obtain the to-be-verified information.
- the second device broadcasts a beacon (Beacon) frame
- the beacon frame may include the to-be-verified information.
- the first device that receives the beacon frame can parse the beacon frame to obtain the device identifier and encrypted data therein.
- the graphic encoding may include, for example, a two-dimensional code, a barcode, and the like that carry the information to be verified of the second device through graphics.
- the graphic code can be pasted on the second device, and the graphic code can be parsed by an application such as a scan to obtain the device identification of the second device and the encrypted data waiting for verification information.
- the broadcast message includes a beacon frame, and the basic service set identifier (Service Set Identifier, BSSID) field of the beacon frame includes the device identifier of the second device, and the service set identifier (Service Set) of the beacon frame.
- BSSID Service Set Identifier
- the encrypted data is included in the Identifier, SSID) field and/or the vendor-defined field.
- the BSSID field in the beacon (Beacon) frame may include a device ID, such as a device's MAC address.
- Data for specific functions can be set in the SSID field and/or the Vendor Specific field in the Beacon frame, such as a user-defined network name, a protocol name of an application protocol, and the like.
- encrypted data may be included in the SSID field and/or the vendor-defined field.
- the second device broadcasts the beacon frame, and the first device that receives the beacon frame can obtain data from the BSSID and SSID (and/or the manufacturer-defined field) in the beacon frame.
- the SSID field and/or the manufacturer-defined field of the beacon frame further includes an identifier for prompting whether the encrypted data exists. Preliminary determination can be made through this identification, so as to filter out some failures in advance. For example, for a beacon frame that does not include the identifier, it may not be necessary to continue to acquire encrypted data, or it may be directly determined that the verification fails. For the beacon frame including the identifier, the encrypted data is parsed from the SSID field and/or the manufacturer-defined field, and sent to the cloud for verification.
- the encrypted data is calculated by the second device on the first data based on the first secret key.
- the first secret key may be a symmetric encryption key or an asymmetrically encrypted private key.
- the first secret key may be pre-stored in the second device.
- the decryption key corresponding to the first key, that is, the second key may be stored in the cloud of the second device, or may be carried in the certificate.
- a digital signature is data contained in electronic form in a data message, attached to identify the signatory and to indicate that the signatory approves of the content therein. If the digital signature adopts an asymmetric encryption algorithm (such as DSA, RSA, ECC), you can use the private key to encrypt the target data to generate the signature data, use the public key to decrypt the signature data and compare the decrypted data with the aforementioned target data. Yes, the process is the process of verifying the signature.
- the target data may be original plaintext data or its hash digest data, for example, data generated by performing hash digest calculation on the set data by using the hash algorithm SHA.
- the first data includes preset data.
- the preset data is D0
- the first data includes hash digest data of preset data.
- the hash algorithm used for the hash operation can be stored on the second device and in the cloud. If the verification information is to be verified in the cloud of the second device, the hash algorithm may be saved in the cloud of the second device. If the information to be verified is verified in the cloud of the first device, the hash algorithm may also be stored in the cloud of the first device, or the hash algorithm may be carried in the certificate included in the information to be verified.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm, and the first algorithm is used to calculate the number of startups to obtain the first serial number.
- the second device can use the first algorithm to calculate N1 to obtain the first sequence number N1', and then use the preset data D0 (which can also be replaced with the hash digest data H of the preset data, this embodiment D0 is used as an illustration in the above, and the situation of H is similar to that of D0, so it is not repeated) and N1' to form the first data D1, and the encrypted data is obtained by encrypting and calculating D1 by using the first secret key.
- the preset data D0 which can also be replaced with the hash digest data H of the preset data, this embodiment D0 is used as an illustration in the above, and the situation of H is similar to that of D0, so it is not repeated
- the first algorithm may be saved in the cloud of the second device. If the information to be verified is verified in the cloud of the first device, the first algorithm may also be saved in the cloud of the first device, or the first algorithm may be carried in the certificate included in the information to be verified.
- the information to be verified further includes the start times.
- the to-be-verified information sent by the first device to the cloud of the second device includes the device identification, encrypted data S1 and the number of activations N1.
- the setting data D0 and the second secret key corresponding to the device identification can be obtained in the cloud of the second device.
- the first device sends the information to be verified to the cloud of the first device.
- the information to be verified includes device identification, encrypted data S1, startup times N1 and a certificate
- the certificate includes setting data D0, a second secret key and a first algorithm
- the certificate includes setting data D0 and a second secret key key
- the first algorithm is pre-stored in the cloud of the first device.
- the first data further includes a random number, and the random number has a corresponding second algorithm, and the second algorithm is used to calculate the random number to obtain the second serial number.
- the information to be verified further includes the random number.
- the information to be verified sent by the first device to the cloud of the second device includes the device identification, encrypted data S1 and random number N2.
- a second sequence number N2' can be obtained, and N2' can be used as the key sequence number. If there are multiple optional first keys, the first key corresponding to N2' can be selected.
- the cloud of the second device may obtain the setting data D0 corresponding to the device identifier.
- the first device sends the information to be verified to the cloud of the first device.
- the information to be verified includes device identification, encrypted data S1, random number N2 and a certificate
- the certificate includes setting data D0, a second key and a second algorithm
- the certificate includes setting data D0 and a second secret key
- the second algorithm is pre-stored in the cloud of the first device.
- the cloud of the first device or the second device use the second algorithm to calculate N2 to obtain the second serial number N2', obtain the second secret key corresponding to N2', and use the second secret key to decrypt S1 to obtain D2 ; and the first data D1 is obtained according to the combination of N2' and D0 calculated by the cloud. Compare whether D2 and D1 are consistent. If they are consistent, the verification is successful, and if they are inconsistent, the verification fails.
- the decryption key corresponding to the first key is the second key.
- the first secret key is a private key
- the public key corresponding to the first secret key is the second secret key. If a symmetric algorithm is used, the first key is the same as the second key.
- the first secret key may be stored in the second device. If the verification information is to be verified in the cloud of the second device, the second secret key may be stored in the cloud of the second device.
- the information to be verified further includes a certificate of the second device, and the certificate includes a second key corresponding to the first key.
- Smart devices generally ship with built-in device electronic identity certificates (or digital certificates, certificates, etc.).
- an electronic identity certificate contains clear text data for device identity information and a digital signature for that information.
- the device sends its own certificate to the cloud service.
- the device can send its own certificate to a proxy service such as a mobile phone application, and then the mobile phone application forwards it to the cloud service.
- the cloud service verifies the certificate to determine the identity of the device, preventing the access of counterfeit and illegal devices.
- the cloud service sends its own certificate to the device (or if the device itself cannot be directly connected to the network, the cloud service can send its own certificate to a proxy service such as a mobile application, which is then forwarded to the device).
- the device verifies the certificate to determine the identity of the cloud service and prevents itself from accessing counterfeit cloud services.
- the mobile phone application can use the mobile phone application as a proxy service.
- the device certificate is obtained, and then the mobile phone needs to switch to the home Wi-Fi network to connect to the cloud service, and forward the device certificate to the cloud service.
- the cloud service verification is passed and returned to the mobile phone application, the mobile phone needs to switch back to Set the ssid and password of the home Wi-Fi network on the softAP network of the device, which requires network switching, and the user experience is not good.
- the first device such as a mobile phone can obtain the certificate of the device before connecting to the softAP network of the second device, and does not need to perform network switching.
- the identity of the second device can be verified only through the cloud, and the problem of counterfeit devices can be solved without the need for the second device to verify the identity of the cloud.
- the information to be verified may include a certificate, and the certificate may carry the second secret key.
- the certificate, encrypted data, etc. can be verified in the cloud of the first device.
- the method of certificate chain verification can be adopted.
- An example of a certificate chain verification includes: a digital certificate generally contains the identity information (plaintext) of the certificate subject, the public key (plaintext) of the certificate subject, and the upper-level CA (Certification Authority, certificate authority) to the first two parts of the plaintext data. sign.
- the private key corresponding to the public key in the digital certificate is stored by the certificate subject.
- Individual A receives a certificate from B, and B's certificate contains the information of the CA that issued the certificate.
- a certificate chain can be formed until the root certificate.
- the signatures in each certificate are verified in the opposite direction, starting with the root certificate. Among them, the root certificate is self-signed and verified with its own public key. All the way up to verifying the signature in B's certificate. If all signature verifications pass, A can be sure that all certificates are correct, and if he trusts the root CA, he can trust B's certificate and public key.
- the method further includes: the first device sends an access token to the cloud, where the access token is used to access the cloud of the second device.
- the first device may obtain an access token when logging into the cloud. If the first device and the second device access the same cloud, the cloud assigns an access token. If the first device and the second device are connected to different clouds, the cloud of the second device allocates an access token and sends the access token to the cloud of the first device, and the first device can log in to the cloud of the first device to obtain the access token.
- an access token may be obtained using OAuth authorization.
- OAuth authorization Open Authorization
- OAuth authorization is an open authorization standard that allows users to authorize third-party mobile applications to access information they store on another service provider without providing usernames and passwords to third-party mobile applications or sharing their data of all content.
- the method further includes:
- the first device receives the verification result
- the first device sends network configuration information to the second device.
- the network configuration information sent by the first device to the second device may include an SSID, a password, and the like.
- the first device sends the SSID and password of the home Wi-Fi network to the second device, and the second device uses the SSID and password of the home Wi-Fi network to establish a connection with the AP of the home Wi-Fi network.
- FIG. 3 is a schematic flowchart of a device verification method 300 according to an embodiment of the present application.
- the method can optionally be applied to the system shown in Figure 1, but is not limited thereto.
- the method includes at least some of the following.
- the cloud of the first device receives information to be verified from the first device, where the information to be verified includes the device identification and encrypted data of the second device;
- the cloud of the first device decrypts and verifies the encrypted data.
- the encrypted data is calculated by the second device on the first data based on the first secret key.
- the first data includes preset data.
- the first data includes hash digest data of preset data.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm, and the first algorithm is used to calculate the number of startups to obtain the first serial number.
- the information to be verified further includes the start times.
- the first data further includes a random number, and the random number has a corresponding second algorithm, and the second algorithm is used to calculate the random number to obtain the second serial number.
- the information to be verified further includes the random number.
- the decryption key corresponding to the first secret key is a second secret key; wherein, the first secret key is a private key, and the public key corresponding to the first secret key is the second secret key; or, the The first key is the same as the second key.
- the cloud of the first device decrypts and verifies the encrypted data, including:
- the cloud of the first device sends the to-be-verified information to the cloud of the second device to decrypt and verify the encrypted data.
- the method further includes:
- the cloud of the first device receives the verification result from the cloud of the second device
- the cloud of the first device sends the verification result to the first device.
- the information to be verified further includes a certificate of the second device, and the certificate includes a second key corresponding to the first key.
- the cloud of the first device decrypts and verifies the encrypted data, including:
- the cloud of the first device verifies the certificate
- the cloud of the first device decrypts the encrypted data based on the second secret key in the certificate to obtain second data, and verifies the first data based on the second data;
- the cloud of the first device sends the verification result to the first device.
- the method further includes:
- the cloud of the first device receives an access token from the first device, the access token being used to access the cloud of the second device;
- the cloud of the first device sends the access token to the cloud of the second device for verification.
- FIG. 4 is a schematic flowchart of a device verification method 400 according to an embodiment of the present application.
- the method can optionally be applied to the system shown in Figure 1, but is not limited thereto.
- the method includes at least some of the following.
- the cloud of the second device receives the information to be verified, and the information to be verified includes the device identification and encrypted data of the second device;
- the cloud of the second device decrypts and verifies the encrypted data based on the device identifier.
- the cloud of the second device receives the information to be verified, including:
- the cloud of the second device receives the to-be-verified information from the first device or the cloud of the first device.
- the cloud of the second device decrypts and verifies the encrypted data based on the device identifier, including:
- the cloud of the second device obtains the second secret key according to the device identifier
- the cloud of the second device decrypts the encrypted data based on the second secret key to obtain second data
- the cloud of the second device verifies the first data based on the second data.
- the encryption key corresponding to the second secret key is the first secret key; wherein, the first secret key is a private key, and the public key corresponding to the first secret key is the second secret key; or, the The first key is the same as the second key.
- the cloud of the second device obtains the second secret key according to the device identifier, including:
- the cloud of the second device obtains the second secret key corresponding to the device identifier.
- the information to be verified further includes a random number
- the cloud of the second device obtains a second secret key according to the device identifier, including:
- the cloud of the second device obtains the key set corresponding to the device identifier
- the cloud of the second device calculates a secret key identifier based on the random number in the information to be verified, and obtains the second secret key corresponding to the secret key identifier.
- the encrypted data is calculated by the second device on the first data based on the first secret key.
- the first data includes preset data.
- the first data includes hash digest data of preset data.
- the cloud of the second device verifies the first data based on the second data, including:
- the cloud of the second device obtains the first data corresponding to the device identifier
- the cloud of the second device compares whether the second data is consistent with the first data
- the cloud of the second device determines that the verification of the encrypted data is successful.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm, and the first algorithm is used to calculate the number of startups to obtain the first serial number.
- the cloud of the second device verifies the first data based on the second data, including:
- the cloud of the second device obtains the setting data corresponding to the device identifier
- the cloud of the second device calculates the activation times included in the information to be verified based on the first algorithm to obtain a verification identifier, and calculates and obtains the first data based on the verification identifier and the setting data;
- the cloud of the second device compares whether the second data is consistent with the first data
- the cloud of the second device determines that the verification of the encrypted data is successful.
- the first data further includes a random number, and the random number has a corresponding second algorithm, and the second algorithm is used to calculate the random number to obtain the second serial number.
- the cloud of the second device verifies the first data based on the second data, including:
- the cloud of the second device obtains the setting data corresponding to the device identifier
- the cloud of the second device calculates the random number included in the information to be verified based on the second algorithm to obtain a secret key identifier, and calculates and obtains the first data based on the secret key identifier and the setting data;
- the cloud of the second device compares whether the second data is consistent with the first data
- the cloud of the second device determines that the verification of the encrypted data is successful.
- the method further includes:
- the cloud of the second device receives an access token from the first device or the cloud of the first device, the access token being used to access the cloud of the second device;
- the cloud of the second device verifies the access token
- the cloud of the second device performs the step of verifying the encrypted data again.
- the information to be verified further includes a certificate
- the certificate includes a second key corresponding to the first key
- the method further includes:
- the cloud of the second device verifies the certificate
- the cloud of the second device decrypts the encrypted data based on the second secret key in the certificate to obtain second data, and verifies the first data based on the second data;
- the cloud of the second device determines that the access verification is successful this time.
- FIG. 5 is a schematic flowchart of a device verification method 500 according to an embodiment of the present application.
- the method can optionally be applied to the system shown in Figure 1, but is not limited thereto.
- the method includes at least some of the following.
- the second device encrypts the first data based on the first secret key to obtain encrypted data
- the second device sends the information to be verified to the first device, so that the information to be verified is sent to the cloud through the first device to decrypt and verify the encrypted data, and the information to be verified includes the device identification of the second device and the encrypted data.
- the second device sends the information to be verified to the first device, including:
- the second device sends a broadcast message to the first device, where the broadcast message includes the to-be-verified information.
- the broadcast message includes a beacon frame
- the BSSID field of the basic service set identifier of the beacon frame includes the device identifier of the second device, the service set identifier SSID field of the beacon frame and/or the manufacturer-defined field. include the encrypted data.
- the SSID field and/or the manufacturer-defined field of the beacon frame further includes an identifier for indicating whether the encrypted data exists.
- the first data includes preset data.
- the first data includes hash digest data of preset data
- the method further includes:
- the second device calculates the preset data based on a hash algorithm to obtain the hash digest data.
- the first data further includes the number of startups, the number of startups has a corresponding first algorithm, and the method further includes:
- the second device calculates the number of activations based on the first algorithm to obtain a first serial number, and obtains the first data based on the first serial number and the preset data.
- the first data further includes a random number
- the random number has a corresponding second algorithm
- the method further includes:
- the second device calculates the random number based on the second algorithm to obtain a second serial number, and obtains the first data based on the second serial number and the preset data.
- the first data further includes the number of startups and a random number
- the number of startups has a corresponding first algorithm
- the random number has a corresponding second algorithm
- the method further includes:
- the second device calculates the number of starts based on the first algorithm to obtain a first serial number
- the second device calculates the random number based on the second algorithm to obtain a second serial number
- the second device obtains the first data based on the first serial number, the second serial number and the preset data.
- the decryption key corresponding to the first secret key is a second secret key; wherein, the first secret key is a private key, and the public key corresponding to the first secret key is the second secret key; or, the The first key is the same as the second key.
- the information to be verified further includes the certificate of the second device.
- the method further includes:
- the second device receives the network configuration information from the first device.
- the technical solutions of the embodiments of the present application can carry encrypted data for verifying the identity of the device in the Beacon of the Wi-Fi AP, so that in the softAP network configuration method, the SSID of the home Wi-Fi network can be set when the SSID of the home Wi-Fi network is set.
- an application program for network configuration may be installed in the first device, which may be referred to as an application (app of manufacturer B), and the second device may be referred to as a device of manufacturer A (device of manufacturer A).
- the cloud of the first device may be a cloud service of the application manufacturer (the cloud of manufacturer B, not shown in FIG. 6 , may act as a proxy between the APP of manufacturer B and the cloud of manufacturer A).
- the cloud of the second device may be a cloud service of the device manufacturer (the cloud of the manufacturer A).
- the plan may include:
- the device manufacturer allocates a pair of unique asymmetric keys (private key K1 and public key K2) to each device (which can be identified by a device ID).
- the private key K1 can be preset in the corresponding device, and the public key K2 and the corresponding device ID can be stored in the cloud service of the manufacturer.
- multiple pairs of asymmetric keys can also be allocated to the device, so that the set of private keys K1 can be preset in the corresponding device, and the set of public keys K2 and the corresponding device ID can be stored in the cloud service of the manufacturer.
- Wi-Fi devices such as smart refrigerators and other household appliances use the preset private key K1 to pair specific data D1.
- the predefined data specified by the equipment manufacturer is encrypted to obtain S1.
- the D1 of all devices may be the same, or the D1 of each device may be different.
- the manufacturer's cloud service can save the D1 corresponding to each device ID.
- the Wi-Fi device enables the softAP, and sets the device ID to the Basic Service Set Identifier (BSSID) field of the Beacon Frame.
- BSSID Basic Service Set Identifier
- the function identifier F1 can be set to the service set identifier (SSID) field and/or the vendor specific (Vendor Specific) field of the beacon frame (Beacon Frame), and F1 is used to indicate the Wi-Fi access device this information.
- Whether the frame data contains S1.
- Set S1 to the service set identification (SSID) field and/or vendor specific field data of the beacon frame (Beacon Frame) for broadcasting.
- a QR code can be generated from the device ID and S1 and printed to the device On the packaging or in the manual, the mobile phone can scan the QR code to obtain the device ID and S1, so that the Wi-Fi device does not need to open the softAP.
- the Wi-Fi device may record the number of times it starts the softAP, and each time the device starts the softAP, the Beacon frame also carries the number of times N1 of starting the softAP.
- the vendor cloud service also records the serial number of each verification (calculated according to a predefined algorithm based on the N1 sent by the mobile phone), and returns a failure to the verification request smaller than the recorded serial number, which can prevent replay attacks.
- a larger initial sequence number and a predefined algorithm for decreasing the sequence number may also be used, and the vendor cloud service returns a failure to a verification request with a sequence number greater than the recorded sequence number.
- the device manufacturer assigns multiple pairs of public and private keys to each device, and each time the device starts the softAP, it can also carry a random number N2 in the Beacon.
- Use manufacturer-predefined initial data eg, fixed data
- N2 as the original data D1.
- the manufacturer's predefined algorithm for example, the serial number of the private key is obtained by taking the modulo operation according to the total number of private keys
- one of the multiple private keys can be selected to encrypt D1 to obtain S1, which can also prevent playback. attack.
- the application program of the Wi-Fi access device receives and parses the beacon frame of the aforementioned Wi-Fi device, and obtains the device ID therein. According to the aforementioned F1, it is determined that the beacon frame includes the aforementioned S1 and the aforementioned S1 is obtained. Optionally, N1 and/or N2 in the beacon frame may also be acquired.
- the application of the Wi-Fi access device logs in to the cloud service of the application (the application manufacturer and the device manufacturer are the same manufacturer) to obtain an access token, or through the verification between the cloud services (the application manufacturer and the device manufacturer are different from each other). the same vendor, e.g. using OAuth authentication) to obtain an access token for the vendor cloud.
- this step may also be performed before the access device acquires S1 from the beacon frame.
- the application of the Wi-Fi access device sends the access token, device ID and S1 (and N1 and/or N2) to the cloud service of the device manufacturer.
- the cloud service queries the corresponding public key K2 from the stored public key list according to the device ID and the key selection policy corresponding to the aforementioned N1 and/or N2, and performs verification. Use K2 to decrypt the signature S1 to obtain D2. If D2 is the same as the known data D1, the verification passes, otherwise the verification fails.
- the application program of the Wi-Fi access device may not directly access the cloud service of the device manufacturer, but use the device ID and S1 ( and N1 and/or N2) to the cloud service of the application manufacturer, and the cloud service agent of the application manufacturer accesses the cloud service of the device manufacturer.
- the Wi-Fi access device (such as a mobile phone) receives the verification result, if the verification is successful, it will connect to the softAP network of the aforementioned Wi-Fi device, and set the SSID and SSID of the home Wi-Fi network for the Wi-Fi device. password. Otherwise the process ends.
- the service set identifier (SSID) field is used to transmit S1
- the maximum length of the SSID field value is 32 bytes
- the length of the S1 generated after encryption is required to be different from the length of the function identifier F1 (for example, F1 occupies at least 1 byte). more than 32 bytes.
- N1 and N2 are also transmitted at the same time, the total length of S1, F1, N1 and N2 does not exceed 32 bytes. That is, D1 does not exceed 31 bytes and uses an asymmetric algorithm with a key length of 31 bytes or less. Vendor Specific fields do not have this restriction.
- it can also be implemented as a general digital signature.
- K1 When encrypting, use K1 to encrypt the hash digest data H1 of D1 to obtain S1.
- the cloud service When verifying the signature, the cloud service needs to decrypt S1 to obtain H2, and it needs to perform a hash digest on D1. After calculating H3, the cloud service compares H2 and H3. If they are consistent, the verification passes, otherwise the verification fails.
- a certificate chain verification method can be used.
- the application manufacturer and the device manufacturer hold the same certificate CertR of the upper-level CA, and also hold the respective certificates CertA and CertB issued by the upper-level CA.
- CertR includes the public key Kr and the signature Srr of the higher-level CA, and the private key Kpr corresponding to Kr is held by the upper-level CA itself.
- CertA contains the public key Ka and the signature Sa encrypted with Kpr, and the private key Kpa corresponding to Ka is held by the application manufacturer itself.
- CertB contains the public key Kb and the signature Sb encrypted with Kpr, and the private key Kpb corresponding to Kb is held by the device manufacturer itself.
- the device holds the CertC issued by the above-mentioned superior CA, and the CertC contains the public key Kc and the signature Sc encrypted with Kpr, and the private key Kpc corresponding to Kc is held by the device itself.
- the device carries the following information in the aforementioned Beacon and/or the aforementioned two-dimensional code: original data D1 (as described above), signature data S1 and CertC encrypted by its own private key Kpc.
- the application manufacturer After receiving the information through the aforementioned process, the application manufacturer performs the following verification: use the public key Kr to verify CertC, determine that the public key Kc contained in CertC is valid, and then use the public key Kc contained in CertC to verify S1.
- the data to be carried in this method is relatively long, and generally a vendor-specific field or a QR code is used.
- a symmetric encryption algorithm such as AES, DES, etc.
- a symmetric key that is, K1 and K2 in the foregoing process are the same
- the device performs symmetric encryption on D1 using the key K1 to obtain S1.
- K2 (equal to K1) is used to decrypt S1 to obtain data D2. If D2 is the same as D1, the verification passes, otherwise the verification fails.
- Symmetric encryption schemes are easier to implement than asymmetric encryption schemes, and asymmetric encryption schemes are more secure.
- the technical solution completes the verification of the device identity before setting the SSID and password of the home Wi-Fi network, which can improve the security of the softAP network distribution.
- FIG. 7 is a schematic block diagram of the first device 20 according to an embodiment of the present application.
- the first device 20 may include:
- the obtaining unit 21 is used for obtaining the information to be verified, the information to be verified includes the device identification and encrypted data of the second device;
- the sending unit 22 is configured to send the information to be verified to the cloud to decrypt and verify the encrypted data.
- the obtaining unit 21 is configured to perform at least one of the following steps:
- the broadcast message includes the to-be-verified information
- the broadcast message includes a beacon frame
- the BSSID field of the basic service set identifier of the beacon frame includes the device identifier of the second device, the service set identifier SSID field of the beacon frame and/or the manufacturer-defined field. include the encrypted data.
- the SSID field and/or the manufacturer-defined field of the beacon frame further includes an identifier for indicating whether the encrypted data exists.
- the encrypted data is calculated by the second device on the first data based on the first secret key.
- the first data includes preset data.
- the first data includes hash digest data of preset data.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm, and the first algorithm is used to calculate the number of startups to obtain the first serial number.
- the information to be verified further includes the start times.
- the first data further includes a random number, and the random number has a corresponding second algorithm, and the second algorithm is used to calculate the random number to obtain the second serial number.
- the information to be verified further includes the random number.
- the decryption key corresponding to the first secret key is a second secret key; wherein, the first secret key is a private key, and the public key corresponding to the first secret key is the second secret key; or, the The first key is the same as the second key.
- the information to be verified further includes a certificate of the second device, and the certificate includes a second secret key corresponding to the first secret key.
- the sending unit 22 is further configured to send an access token to the cloud, where the access token is used to access the cloud of the second device.
- the obtaining unit 21 is further configured to receive the verification result
- the sending unit 22 is further configured to send network distribution information to the second device when the verification result is successful.
- the first device 20 in this embodiment of the present application can implement the corresponding functions of the first device in the foregoing method embodiments.
- each module (submodule, unit or component, etc.) in the first device 20 can implement the corresponding functions of the first device in the foregoing method embodiments.
- the functions described by each module (submodule, unit, or component, etc.) in the first device 20 of the application embodiment may be implemented by different modules (submodule, unit, or component, etc.), or by the same A module (submodule, unit or component, etc.) implementation.
- FIG. 8 is a schematic block diagram of the first cloud 30 according to an embodiment of the present application.
- the first cloud 30 may include:
- a receiving unit 31 configured to receive information to be verified from the first device, where the information to be verified includes the device identification and encrypted data of the second device;
- the processing unit 32 is used for decrypting and verifying the encrypted data.
- the encrypted data is calculated by the second device on the first data based on the first secret key.
- the first data includes preset data.
- the first data includes hash digest data of preset data.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm, and the first algorithm is used to calculate the number of startups to obtain the first sequence number.
- the information to be verified further includes the start times.
- the first data further includes a random number, and the random number has a corresponding second algorithm, and the second algorithm is used to calculate the random number to obtain the second serial number.
- the information to be verified further includes the random number.
- the decryption key corresponding to the first secret key is a second secret key; wherein, the first secret key is a private key, and the public key corresponding to the first secret key is the second secret key; or, the The first key is the same as the second key.
- processing unit 32 is further configured to send the to-be-verified information to the cloud of the second device to decrypt and verify the encrypted data.
- the receiving unit 31 is further configured to receive a verification result from the cloud of the second device;
- the processing unit 32 is further configured to send the verification result to the first device.
- the information to be verified further includes a certificate of the second device, and the certificate includes a second key corresponding to the first key.
- the processing unit 32 is further configured to verify the certificate; decrypt the encrypted data based on the second key in the certificate to obtain second data, and verify the first data based on the second data ; In the case that the verification of the certificate is successful and the verification of the first data is successful, it is determined that the access verification is successful this time; and the verification result is sent to the first device.
- the receiving unit 31 is further configured to receive an access token from the first device, where the access token is used to access the cloud of the second device;
- the processing unit 32 is further configured to send the access token to the cloud of the second device for verification.
- the first cloud 30 in the embodiment of the present application can implement the corresponding functions of the cloud of the first device in the foregoing method embodiments.
- each module (submodule, unit, or component, etc.) in the first cloud 30 may be implemented by different modules (submodule, unit, or component, etc.), or by the same module.
- FIG. 9 is a schematic block diagram of the second cloud 40 according to an embodiment of the present application.
- the second cloud 40 may include:
- a receiving unit 41 configured to receive the information to be verified, the information to be verified includes the device identification and encrypted data of the second device;
- the processing unit 42 is configured to decrypt and verify the encrypted data based on the device identification.
- the receiving unit 41 is further configured to receive the information to be verified from the first device or the cloud of the first device.
- the processing unit 42 is further configured to obtain a second secret key according to the device identifier; decrypt the encrypted data based on the second secret key to obtain second data; and verify the first data based on the second data.
- the encryption key corresponding to the second secret key is the first secret key; wherein, the first secret key is a private key, and the public key corresponding to the first secret key is the second secret key; or, the The first key is the same as the second key.
- the processing unit 42 is further configured to acquire the second key corresponding to the device identifier.
- the information to be verified further includes a random number
- the processing unit is also used to obtain a key set corresponding to the device identifier; calculate the key identifier based on the random number in the information to be verified, and obtain the key identifier corresponding to the second key.
- the encrypted data is calculated by the second device on the first data based on the first secret key.
- the first data includes preset data.
- the first data includes hash digest data of preset data.
- the processing unit 42 is further configured to obtain the first data corresponding to the device identifier; compare whether the second data is consistent with the first data; in the case that the second data is consistent with the first data, determine whether the second data is consistent with the first data Authentication of this encrypted data succeeded.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm, and the first algorithm is used to calculate the number of startups to obtain the first serial number.
- the processing unit 42 is also used to obtain the setting data corresponding to the device identification; based on the first algorithm, the number of activations included in the information to be verified is calculated to obtain a verification mark, based on the verification mark and the setting.
- the data is calculated to obtain the first data; whether the second data is consistent with the first data is compared; if the second data is consistent with the first data, it is determined that the verification of the encrypted data is successful.
- the first data further includes a random number, and the random number has a corresponding second algorithm, and the second algorithm is used to calculate the random number to obtain the second serial number.
- the processing unit 42 is also used to obtain the setting data corresponding to the device identifier; the random number included in the information to be verified is calculated based on the second algorithm to obtain a key identifier, based on the key identifier and the The first data is obtained by calculating the setting data; whether the second data is consistent with the first data is compared; if the second data is consistent with the first data, it is determined that the verification of the encrypted data is successful.
- the receiving unit 41 is further configured to receive an access token from the first device or the cloud of the first device, where the access token is used to access the cloud of the second device;
- the processing unit 42 is further configured to verify the access token; in the case that the verification of the access token is successful, the step of verifying the encrypted data is performed again.
- the information to be verified further includes a certificate
- the certificate includes a second key corresponding to the first key
- the processing unit 42 is further configured to verify the certificate; based on the second key in the certificate
- the secret key decrypts the encrypted data to obtain second data, and verifies the first data based on the second data; when the verification of the certificate is successful and the verification of the encrypted data is successful, it is determined that this access is Verification succeeded.
- the second cloud 40 in the embodiment of the present application can implement the corresponding functions of the cloud of the second device in the foregoing method embodiments.
- each module (sub-module, unit, or component, etc.) in the second cloud 40 reference may be made to the corresponding descriptions in the above method embodiments, which will not be repeated here.
- the functions described by each module (submodule, unit, or component, etc.) in the second cloud 40 of the application embodiment may be implemented by different modules (submodule, unit, or component, etc.), or by the same A module (submodule, unit or component, etc.) implementation.
- FIG. 10 is a schematic block diagram of a second device 50 according to an embodiment of the present application.
- the second device 50 may include:
- An encryption unit 51 configured to encrypt the first data based on the first secret key to obtain encrypted data
- the sending unit 52 is configured to send the information to be verified to the first device, so as to send the information to be verified to the cloud through the first device to decrypt and verify the encrypted data, the information to be verified includes the equipment of the second device identity and the encrypted data.
- the sending unit 52 is further configured to send a broadcast message to the first device, where the broadcast message includes the to-be-verified information.
- the broadcast message includes a beacon frame
- the BSSID field of the basic service set identifier of the beacon frame includes the device identifier of the second device, the service set identifier SSID field of the beacon frame and/or the manufacturer-defined field. include the encrypted data.
- the SSID field and/or the manufacturer-defined field of the beacon frame further includes an identifier for indicating whether the encrypted data exists.
- the first data includes preset data.
- the first data includes hash digest data of preset data
- the encryption unit 51 is further configured to calculate the preset data based on a hash algorithm to obtain the hash digest data.
- the first data further includes the number of startups, and the number of startups has a corresponding first algorithm
- the encryption unit 51 is further configured to calculate the number of startups based on the first algorithm to obtain a first serial number, and based on the first algorithm.
- a serial number and the preset data obtain the first data.
- the first data further includes a random number
- the random number has a corresponding second algorithm
- the encryption unit 51 is further configured to calculate the random number based on the second algorithm to obtain a second serial number, and based on the second algorithm.
- the second serial number and the preset data obtain the first data.
- the first data also includes the number of startups and a random number, the number of startups has a corresponding first algorithm, the random number has a corresponding second algorithm, and the encryption unit 51 is further configured to perform the encryption based on the first algorithm.
- the number of starts is calculated to obtain the first serial number; the random number is calculated based on the second algorithm to obtain the second serial number; the first data is obtained based on the first serial number, the second serial number and the preset data.
- the decryption key corresponding to the first key is the second key
- the first secret key is a private key
- the public key corresponding to the first secret key is the second secret key; or, the first secret key is the same as the second secret key.
- the information to be verified further includes the certificate of the second device.
- the second device further includes:
- the receiving unit is configured to receive the network distribution information from the first device when the verification result is successful.
- the second device 50 in this embodiment of the present application can implement the corresponding functions of the second device in the foregoing method embodiments.
- each module (submodule, unit, or component, etc.) in the second device 50 reference may be made to the corresponding descriptions in the above method embodiments, which will not be repeated here.
- the functions described by each module (submodule, unit, or component, etc.) in the second device 50 of the application embodiment may be implemented by different modules (submodule, unit, or component, etc.), or by the same A module (submodule, unit or component, etc.) implementation.
- FIG. 11 is a schematic structural diagram of a communication device 600 according to an embodiment of the present application.
- the communication device 600 includes a processor 610, and the processor 610 can call and run a computer program from a memory, so that the communication device 600 implements the methods in the embodiments of the present application.
- the communication device 600 may also include a memory 620 .
- the processor 610 may call and run a computer program from the memory 620, so that the communication device 600 implements the methods in the embodiments of the present application.
- the memory 620 may be a separate device independent of the processor 610 , or may be integrated in the processor 610 .
- the communication device 600 may further include a transceiver 630, and the processor 610 may control the transceiver 630 to communicate with other devices, specifically, may send information or data to other devices, or receive information or data sent by other devices .
- the transceiver 630 may include a transmitter and a receiver.
- the transceiver 630 may further include antennas, and the number of the antennas may be one or more.
- the communication device 600 may be the first device, the second device, the cloud of the first device, or the cloud of the second device of the embodiments of the present application, and the communication device 600 may implement the methods in the embodiments of the present application.
- the corresponding process implemented by the terminal device will not be repeated here.
- FIG. 12 is a schematic structural diagram of a chip 700 according to an embodiment of the present application.
- the chip 700 includes a processor 710, and the processor 710 can call and run a computer program from a memory, so as to implement the method in the embodiments of the present application.
- the chip 700 may further include a memory 720 .
- the processor 710 may call and run a computer program from the memory 720 to implement the method executed by the first device, the second device, the cloud of the first device, or the cloud of the second device in the embodiments of the present application.
- the memory 720 may be a separate device independent of the processor 710 , or may be integrated in the processor 710 .
- the chip 700 may further include an input interface 730 .
- the processor 710 may control the input interface 730 to communicate with other devices or chips, and specifically, may acquire information or data sent by other devices or chips.
- the chip 700 may further include an output interface 740 .
- the processor 710 can control the output interface 740 to communicate with other devices or chips, and specifically, can output information or data to other devices or chips.
- the chip can be applied to the first device, the second device, the cloud of the first device, or the cloud of the second device in the embodiments of the present application, and the chip can implement the methods described in the embodiments of the present application.
- the corresponding processes implemented by the first device, the second device, the cloud of the first device, or the cloud of the second device are not repeated here for brevity.
- the chips applied to the first device, the second device, the cloud of the first device, or the cloud of the second device may be the same chip or different chips.
- the chip mentioned in the embodiments of the present application may also be referred to as a system-on-chip, a system-on-chip, a system-on-chip, or a system-on-a-chip, or the like.
- the above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an off-the-shelf programmable gate array (field programmable gate array, FPGA), an application specific integrated circuit (ASIC) or Other programmable logic devices, transistor logic devices, discrete hardware components, etc.
- DSP digital signal processor
- FPGA field programmable gate array
- ASIC application specific integrated circuit
- the general-purpose processor mentioned above may be a microprocessor or any conventional processor or the like.
- the memory mentioned above may be either volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.
- the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically programmable Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
- Volatile memory may be random access memory (RAM).
- the memory in the embodiment of the present application may also be a static random access memory (static RAM, SRAM), a dynamic random access memory (dynamic RAM, DRAM), Synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection Dynamic random access memory (synch link DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM) and so on. That is, the memory in the embodiments of the present application is intended to include but not limited to these and any other suitable types of memory.
- FIG. 13 is a schematic block diagram of a communication system 800 according to an embodiment of the present application.
- the communication system 800 includes a first device 810, a second device 820 and a cloud.
- the first device 810 is configured to acquire information to be verified, the information to be verified includes the device identification of the second device and encrypted data; the information to be verified is sent to the cloud to decrypt and verify the encrypted data.
- a second device 820 configured to encrypt the first data based on the first secret key to obtain encrypted data
- a sending unit configured to send the information to be verified to the first device, so as to send the information to be verified to the cloud through the first device to decrypt and verify the encrypted data, the information to be verified includes the device identification of the second device and the encrypted data.
- the cloud is used to receive information to be verified, the information to be verified includes the device identification of the second device and encrypted data; decrypt and verify the encrypted data.
- the cloud may include the first cloud 830 and/or the second cloud 840 .
- the first cloud 830 configured to receive information to be verified from the first device, the information to be verified includes the device identification and encrypted data of the second device; decrypt and verify the encrypted data;
- the second cloud 840 is configured to receive information to be verified, the information to be verified includes a device identifier of the second device and encrypted data; decrypt and verify the encrypted data based on the device identifier.
- the first device 810 can be used to implement the corresponding functions implemented by the first device in the above method; the second device 820 can be used to implement the corresponding functions implemented by the second device in the above method; the first cloud 830 may be used to implement the corresponding function implemented by the cloud of the first device in the above method; the second cloud 840 may be used to implement the corresponding function implemented by the cloud of the second device in the above method.
- the first device 810 can be used to implement the corresponding functions implemented by the first device in the above method
- the second device 820 can be used to implement the corresponding functions implemented by the second device in the above method
- the first cloud 830 may be used to implement the corresponding function implemented by the cloud of the first device in the above method
- the second cloud 840 may be used to implement the corresponding function implemented by the cloud of the second device in the above method.
- the above-mentioned embodiments it may be implemented in whole or in part by software, hardware, firmware or any combination thereof.
- software it can be implemented in whole or in part in the form of a computer program product.
- the computer program product includes one or more computer instructions.
- the computer program instructions When the computer program instructions are loaded and executed on a computer, the procedures or functions according to the embodiments of the present application are generated in whole or in part.
- the computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
- the computer instructions may be stored on or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted over a wire from a website site, computer, server or data center (eg coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (eg infrared, wireless, microwave, etc.) means to another website site, computer, server or data center.
- the computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes one or more available media integrated.
- the available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a Solid State Disk (SSD)), and the like.
- a magnetic medium eg, a floppy disk, a hard disk, a magnetic tape
- an optical medium eg, a DVD
- a semiconductor medium eg, a Solid State Disk (SSD)
- the size of the sequence numbers of the above-mentioned processes does not mean the sequence of execution, and the execution sequence of each process should be determined by its functions and internal logic, and should not be dealt with in the embodiments of the present application. implementation constitutes any limitation.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请涉及一种设备验证方法、设备和云端。其中,该设备验证方法,包括:第一设备获取待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证。本申请实施例,第一设备将第二设备的待验证信息发送至云端进行解密和验证,可以先验证设备再配置入网,从而提高配网过程中的安全性。
Description
本申请涉及通信领域,更具体地,涉及一种设备验证方法、设备和云端。
在softAP(软接入点)配网方式中,Wi-Fi设备可以开启由软件实现的服务接入点(简称softAP),广播信标(Beacon)数据。Wi-Fi设备的硬件部分可以包括一块标准的无线网卡,但其通过驱动程序使其提供与AP一样的信号转接、路由等功能。接入设备(例如手机)可以开启扫描,接收该Beacon数据。接入设备可以通过Wi-Fi协议连接到该softAP并与该Wi-Fi设备进行通信,将家庭Wi-Fi网络的SSID和密码设置给该Wi-Fi设备,Wi-Fi设备将使用家庭Wi-Fi网络的SSID和密码与家庭Wi-Fi网络的AP建立连接。
但是,在softAP配网方式下,智能设备只能在接入网络(例如接入家庭Wi-Fi网络)后才能与云服务进行通信,从而进行身份验证,这可能有安全隐患,例如仿冒的设备有可能获取到用户家庭网络的Wi-Fi密码。
发明内容
本申请实施例提供一种设备验证方法、设备和云端,可以提高配网过程的安全性。
本申请实施例提供一种设备验证方法,包括:
第一设备获取待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证。
本申请实施例提供一种设备验证方法,包括:
第一设备的云端接收来自第一设备的待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
该第一设备的云端对该加密数据进行解密和验证。
本申请实施例提供一种设备验证方法,包括:
第二设备的云端接收待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
该第二设备的云端基于该设备标识对该加密数据进行解密和验证。
本申请实施例提供一种设备验证方法,包括:
第二设备基于第一秘钥对第一数据进行加密得到加密数据;
该第二设备向第一设备发送待验证信息,以通过该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证,该待验证信息中包括第二设备的设备标识和该加密数据。
本申请实施例提供一种第一设备,包括:
获取单元,用于获取待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
发送单元,用于将该待验证信息发送至云端以对该加密数据进行解密和验证。
本申请实施例提供一种第一云端,包括:
接收单元,用于接收来自第一设备的待验证信息,该待验证信息中包括第二设备的设备标识和加密 数据;
处理单元,用于对该加密数据进行解密和验证。
本申请实施例提供一种第二云端,包括:
接收单元,用于接收待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
处理单元,用于基于该设备标识对该加密数据进行解密和验证。
本申请实施例提供一种第二设备,包括:
加密单元,用于基于第一秘钥对第一数据进行加密得到加密数据;
发送单元,用于向第一设备发送待验证信息,以通过该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证,该待验证信息中包括第二设备的设备标识和该加密数据。
本申请实施例提供一种通信设备,包括处理器和存储器。该存储器用于存储计算机程序,该处理器用于调用并运行该存储器中存储的计算机程序,以使该通信设备执行上述的任意一种设备验证方法。
本申请实施例提供一种芯片,用于实现上述的任意一种设备验证方法。
具体地,该芯片包括:处理器,用于从存储器中调用并运行计算机程序,使得安装有该芯片的设备执行上述的任意一种设备验证方法。
本申请实施例提供一种计算机可读存储介质,用于存储计算机程序,当该计算机程序被设备运行时使得该设备执行上述的任意一种设备验证方法。
本申请实施例提供一种计算机程序产品,包括计算机程序指令,该计算机程序指令使得计算机执行上述的任意一种设备验证方法。
本申请实施例提供一种计算机程序,当其在计算机上运行时,使得计算机执行上述的任意一种设备验证方法。
本申请实施例,第一设备将第二设备的待验证信息发送至云端进行解密和验证,可以先验证设备再配置入网,从而提高配网过程中的安全性。
图1是根据本申请实施例的应用场景的示意图。
图2是根据本申请一实施例的设备验证方法的示意性流程图。
图3是根据本申请另一实施例的设备验证方法的示意性流程图。
图4是根据本申请另一实施例的设备验证方法的示意性流程图。
图5是根据本申请另一实施例的设备验证方法的示意性流程图。
图6是根据本申请另一实施例的设备验证方法的应用示例的示意图。
图7是根据本申请一实施例的第一设备的示意性框图。
图8是根据本申请一实施例的第一云端的示意性框图。
图9是根据本申请一实施例的第二云端的示意性框图。
图10是根据本申请一实施例的第二设备的示意性框图。
图11是根据本申请实施例的通信设备示意性框图。
图12是根据本申请实施例的芯片的示意性框图。
图13是根据本申请实施例的通信系统的示意性框图。
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
本申请实施例的技术方案可以应用于例如图1所示的通信系统中。该通信系统可以包括云服务平台110、应用网关120、控制类终端130和应用终端140等。云服务平台可以称为云服务、云服务器、云平台、云等。控制类终端和应用类终端的云服务平台可以相同,也可以不同。
以智能家居(smart home)系统为例,智能家居云服务平台可以通过网络统一组织和灵活调用各种智能家居信息资源,实现智能家居信息大规模计算的处理方式。云服务平台可以利用分布式计算和虚拟资源管理等技术,通过网络将分散的ICT(Information Communications Technology,信息、通信和技术)资源(包括计算与存储、应用运行平台、软件等)集中起来形成共享的智能家居资源池,并以动态按需和可度量的方式向用户提供服务。智能家居云服务平台可以基于公共通信网络以及家庭局域网络与家庭空间内各类电器、家居设施以及感知设备连接,提供各种家庭应用服务。
在智能家居系统中,应用网关可以同时与公共通信网络、智能家居功能类终端相连,具有智能家居终端接入管理、数据交换、协议转换和应用服务等功能。应用网关可以用于家庭网络组建,可以支持有线方式、无线方式或混合方式。例如应用网关可以包括家庭Wi-Fi网络的路由器。
在智能家居系统中,控制类终端以本地或者远程方式综合管理或控制各家居应用终端,主要实现将使用者的操作或控制行为转换成实际指令信号,并协调云服务平台的智能化应用服务资源,下发至应用终端以供其执行具体操作。例如,控制类终端可以安装有用于控制网络配置的应用程序(Application,APP),控制类终端的APP可以通过交互指令控制应用终端的网络配置。控制类终端在Wi-Fi网络中可以称为Wi-Fi接入设备。
在智能家居系统中,应用终端可以连接到家庭网络中,可以执行控制类终端的交互指令,并满足人们对居住环境的智能化应用需求的电子化、信息化产品。应用终端包括但不限于各种智能家电例如冰箱、洗衣机、空调、电视、投影仪等。应用终端在Wi-Fi网络中可以称为Wi-Fi设备。
应理解,本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
应理解,在本申请的实施例中提到的“指示”可以是直接指示,也可以是间接指示,还可以是表示具有关联关系。举例说明,A指示B,可以表示A直接指示B,例如B可以通过A获取;也可以表示A间接指示B,例如A指示C,B可以通过C获取;还可以表示A和B之间具有关联关系。
在本申请实施例的描述中,术语“对应”可表示两者之间具有直接对应或间接对应的关系,也可以表示两者之间具有关联关系,也可以是指示与被指示、配置与被配置等关系。
为便于理解本申请实施例的技术方案,以下对本申请实施例的相关技术进行说明,以下相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合,其均属于本申请实施例的保护范围。
图2是根据本申请一实施例的设备验证方法200的示意性流程图。该方法可选地可以应用于图1所示的系统,但并不仅限于此。该方法包括以下内容的至少部分内容。
S210、第一设备获取待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
S220、第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证。
示例性地,第一设备可以包括手机等具有网络配置功能的控制类终端。具体地,第一设备中可以安装有用于配网的应用程序,通过该应用程序可以执行本申请实施例中第一设备所执行的设备验证方法。第二设备可以为需要接入网络的设备例如智能家电、车辆控制器等应用终端。云端(也可以称为云、云服务、云平台、云服务平台等)可以包括第一设备的云端和/或第二设备的云端。例如,如果第一设备和第二设备属于同一厂商,二者可以接入相同的云端。如果第一设备和第二设备属于不同厂商,二者可以接入不同的云端。
示例性地,在第二设备中可以预先保存预设数据,采用对称加密或非对称加密算法对该预设数据进行加密计算可以得到加密数据。此外,也可以利用特定算法计算得到一些用于防止重放攻击的辅助数据,将预设数据和辅助数据组合后,采用对称加密或非对称加密算法对组合后的数据进行加密计算可以得到加密数据。该加密数据可以认为是第二设备的电子签名。
示例性地,在第二设备中加密计算所使用的密钥可以是一个固定的密钥,也可以是不固定的密钥。例如,如果是非对称加密,可以预先生成多组公私钥,在第二设备保存私钥集合,在云端保存公钥集合。在第二设备可以从私钥集合中选取一个私钥进行加密,在云端则利用与该私钥对应的公钥进行解密。
可选地,第一设备获取待验证信息,包括以下至少之一:
该第一设备接收广播消息,该广播消息中包括该待验证信息;
该第一设备扫描图形编码得到该待验证信息。
示例性地,第二设备广播信标(Beacon)帧,该信标帧中可以包括该待验证信息。收到该信标帧的第一设备,可以解析该信标帧得到其中的设备标识和加密数据。
示例性地,图形编码可以包括例如二维码、条形码等通过图形承载第二设备的待验证信息的编码。该图形编码可以贴在第二设备上,通过扫一扫等应用可以解析该图形编码得到第二设备的设备标识和加密数据等待验证信息。
可选地,该广播消息包括信标帧,该信标帧的基本服务集标识(Service Set Identifier,BSSID)字段中包括该第二设备的设备标识,该信标帧的服务集标识(Service Set Identifier,SSID)字段和/或厂商自定义字段中包括该加密数据。
示例性地,在SoftAP配网中,信标(Beacon)帧中的BSSID字段可以包括设备ID,例如设备的MAC地址。在信标(Beacon)帧中的SSID字段和/或厂商自定义(Vendor Specific)字段中可以设定用于特定功能的数据,例如用户自定义的网络名称,应用协议的协议名称等。在本实施例中,在SSID字段和/或厂商自定义字段中可以包括加密数据。第二设备广播信标帧,收到该信标帧的第一设备可以从其中的BSSID和SSID(和/或厂商自定义字段)获取数据。
可选地,该信标帧的SSID字段和/或厂商自定义字段中还包括用于提示是否存在该加密数据的标识。通过该标识可以进行初步的判定,从而提前过滤掉一部分失败的情况。例如,对于不包括该标识的信标帧,可以不用继续获取加密数据或者直接判定为验证失败。对于包括该标识的信标帧,再从SSID字段和/或厂商自定义字段中解析出加密数据,发送到云端进行验证。
可选地,该加密数据是该第二设备基于第一秘钥对第一数据计算得到的。
示例性地,该第一秘钥可以是对称加密的密钥,也可以是非对称加密的私钥。该第一秘钥可以预先保存在第二设备中。第一秘钥对应的解密秘钥、即第二秘钥可以保存在第二设备的云端,也可以携带在证书中。
示例性地,数字签名是数据电文中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。如果数字签名采用非对称加密算法(例如DSA,RSA,ECC),可以使用私钥对目标数据进行加密产生签名数据,使用公钥对签名数据进行解密并将解密得到的数据与前述目标数据进行比对,该过程即验证签名的过程。其中,目标数据可以是原始明文数据或其散列摘要数据,例如采用散列算法SHA对设定数据进行散列摘要计算生成的数据。
可选地,该第一数据包括预设数据。例如,预设数据为D0,可以利用第一秘钥对D0(也就说第一数据D1=D0)直接进行加密计算得到加密数据。
可选地,该第一数据包括预设数据的散列摘要数据。例如,预设数据为D0,可以对D0进行散列运算,得到D0的散列摘要数据H,再利用第一秘钥对H(也就说第一数据D1=H)进行加密计算得到加密数据。散列运算所采用的散列算法可以保存在第二设备和云端。如果是在第二设备的云端对待验证信息进行验证,可以在第二设备的云端保存该散列算法。如果是在第一设备的云端对待验证信息进行验证,也可以在第一设备的云端保存该散列算法,或者在待验证信息包括的证书中携带该散列算法。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该第一算法用于对该启动次数进行计算得到第一序号。例如,启动次数为N1,第二设备可以利用第一算法对N1进行计算得到第一序号N1’,然后利用预设数据D0(也可以替换为预设数据的散列摘要数据H,本实施例中以D0为进行说明,H的情况与D0类似,不赘述)和N1’组成第一数据D1,利用第一秘钥对D1进行加密计算得到加密数据。如果是在第二设备的云端对待验证信息进行验证,可以在第二设备的云端保存该第一算法。如果是在第一设备的云端对待验证信息进行验证,也可以在第一设备的云端保存该第一算法,或者在待验证信息包括的证书中携带该第一算法。
可选地,该待验证信息中还包括该启动次数。
例如,在第一设备向第二设备的云端发送的待验证信息中包括设备标识、加密数据S1和启动次数N1。在第二设备的云端可以获取设备标识对应的设定数据D0和第二秘钥。
再如,第一设备向第一设备的云端发送待验证信息。其中,该待验证信息中包括设备标识、加密数据S1、启动次数N1和证书,证书中包括设定数据D0、第二秘钥和第一算法,或者证书中包括设定数据D0和第二秘钥,第一算法预先保存在第一设备的云端。
然后,在第一设备或第二设备的云端,利用第二秘钥对S1进行解密得到D2;利用第一算法对启动次数N1进行计算可以得到第一序号N1’,并且根据云端算出的N1’和D0组合得到第一数据D1。比较D2和D1是否一致,如果一致表示验证成功,如果不一致表示验证失败。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该第二算法用于对该随机数进行计算得到第二序号。
可选地,该待验证信息中还包括该随机数。
例如,在第一设备向第二设备的云端发送的待验证信息中包括设备标识、加密数据S1和随机数N2。利用第二算法对N2进行计算可以得到第二序号N2’,N2’可以用于作为秘钥序号。如果有多个可选地第一密钥,可以选取N2’对应的第一秘钥。第二设备的云端可以获取设备标识对应的设定数据D0。
再如,第一设备向第一设备的云端发送待验证信息。其中,该待验证信息中包括设备标识、加密数据S1、随机数N2和证书,证书中包括设定数据D0、第二秘钥和第二算法,或者证书中包括设定数据D0和第二秘钥,第二算法预先保存在第一设备的云端。
然后,在第一设备或第二设备的云端,利用第二算法对N2进行计算可以得到第二序号N2’,获取N2’对应的第二秘钥,利用第二秘钥对S1进行解密得到D2;并且根据云端算出的N2’和D0组合得到第一数据D1。比较D2和D1是否一致,如果一致表示验证成功,如果不一致表示验证失败。
可选地,该第一秘钥对应的解密秘钥为第二秘钥。可选地,如果采用非对称算法,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥。如果采用对称算法,该第一秘钥与该第二秘钥相同。
可选地,可以在第二设备保存第一秘钥。如果是在第二设备的云端对待验证信息进行验证,可以在第二设备的云端保存第二秘钥。
可选地,该待验证信息中还包括该第二设备的证书,该证书中包括该第一秘钥对应的第二秘钥。
相关技术中的利用证书进行设备身份验证过程如下:
智能设备一般出厂内置设备电子身份证书(或称为数字证书、证书等)。例如,电子身份证书包含设备身份信息的明文数据和该信息的数字签名。当设备连上网络后,可选地,设备将自身证书发送给云服务。或者如果设备自身不能直接连接到网络中,则设备可以将自身证书发送给代理服务例如手机应用,再由手机应用转发给云服务。云服务对该证书进行校验确定设备身份,防止仿冒非法设备的接入。可选地,云服务将自身的证书发送给设备(或者如果设备自身不能直接连接到网络中,则云服务可以将自身证书发送给代理服务例如手机应用,再由手机应用转发给设备)。设备对该证书进行校验确定云服务的身份,防止自身接入到仿冒的云服务上。
若需要在softAP配网过程中进行设备身份验证,可以通过手机应用作为代理服务。当手机连上设备softAP网络时获取设备证书,然后手机需要切换到家庭Wi-Fi网络以连接上云服务,并转发设备证书给云服务,云服务验证通过返回给手机应用后,手机需要切换回设备softAP网络再设置家庭Wi-Fi网络的ssid和密码,这需要进行网络切换,用户体验不好。采用本申请实施例的设备验证方法,手机等第一设备在连上第二设备softAP网络之前就可以获取到设备的证书,不需要进行网络切换。并且,可以只通过云验证第二设备的身份,不需要第二设备验证云的身份,即可解决仿冒设备的问题。
本申请实施例中,可以在待验证信息中包括证书,在证书中可以携带该第二秘钥。这样可以在第一设备的云端对证书、加密数据等进行验证。示例性地,可以采用证书链验证的方式。
一种证书链验证的示例包括:一个数字证书一般包含证书主体的身份信息(明文),证书主体的公钥(明文),和上级CA(Certification Authority,证书授权机构)对前两部分明文数据的签名。数字证书中的公钥对应的私钥由证书主体保存。个体A收到B的一个证书,B的证书中含有签发该证书的CA的信息,沿着层次树往上找,可以构成一条证书链,直到根证书。在验证过程中,沿相反的方向,从根证书开始,依次往下验证每一个证书中的签名。其中,根证书是自签名的,用它自己的公钥进行验证。一直到验证B的证书中的签名。如果所有的签名验证都通过,则A可以确定所有的证书都是正确的,如果他信任根CA,则他可以相信B的证书和公钥。
可选地,该方法还包括:该第一设备向云端发送访问令牌,该访问令牌用于访问该第二设备的云端。
示例性地,第一设备可以在登录到云端时获取访问令牌。如果第一设备和第二设备接入同一云端,该云端分配访问令牌。如果第一设备和第二设备接入不同的云端,第二设备的云端分配访问令牌,并将该访问令牌发送到第一设备的云端,第一设备可以在登录到第一设备的云端时获取该访问令牌。
示例性地,可以采用OAuth授权获取访问令牌。OAuth授权(开放授权)是一个开放的授权标准,允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提 供给第三方移动应用或分享他们数据的所有内容。
可选地,该方法还包括:
该第一设备接收验证结果;
在该验证结果为成功的情况下,该第一设备向该第二设备发送配网信息。
示例性地,第一设备向该第二设备发送的配网信息可以包括SSID和密码等。例如,第一设备向第二设备发送家庭Wi-Fi网络的SSID和密码,第二设备使用该家庭Wi-Fi网络的SSID和密码与家庭Wi-Fi网络的AP建立连接。
图3是根据本申请一实施例的设备验证方法300的示意性流程图。该方法可选地可以应用于图1所示的系统,但并不仅限于此。该方法包括以下内容的至少部分内容。
S310、第一设备的云端接收来自第一设备的待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
S320、第一设备的云端对该加密数据进行解密和验证。
可选地,该加密数据是该第二设备基于第一秘钥对第一数据计算得到的。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该第一算法用于对该启动次数进行计算得到第一序号。
可选地,该待验证信息中还包括该启动次数。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该第二算法用于对该随机数进行计算得到第二序号。
可选地,该待验证信息中还包括该随机数。
可选地,该第一秘钥对应的解密秘钥为第二秘钥;其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该第一设备的云端对该加密数据进行解密和验证,包括:
该第一设备的云端将该待验证信息发送至该第二设备的云端以对该加密数据进行解密和验证。
可选地,该方法还包括:
该第一设备的云端接收来自该第二设备的云端的验证结果;
该第一设备的云端向该第一设备发送该验证结果。
可选地,该待验证信息中还包括该第二设备的证书,该证书中包括该第一秘钥对应的第二秘钥。
可选地,该第一设备的云端对该加密数据进行解密和验证,包括:
该第一设备的云端对该证书进行验证;
该第一设备的云端基于该证书中的该第二秘钥对该加密数据进行解密得到第二数据,并基于该第二数据对第一数据进行验证;
在对该证书的验证成功并且对该第一数据的验证成功的情况下,判定本次接入验证成功;
该第一设备的云端向该第一设备发送该验证结果。
可选地,该方法还包括:
该第一设备的云端接收来自该第一设备的访问令牌,该访问令牌用于访问该第二设备的云端;
该第一设备的云端将该访问令牌发送至该第二设备的云端进行验证。
本实施例的第一设备的云端执行方法300的具体示例可以参见上述方法200的中关于第一设备的云端的相关描述,为了简洁,在此不再赘述。
图4是根据本申请一实施例的设备验证方法400的示意性流程图。该方法可选地可以应用于图1所示的系统,但并不仅限于此。该方法包括以下内容的至少部分内容。
S410、第二设备的云端接收待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
S420、第二设备的云端基于该设备标识对该加密数据进行解密和验证。
可选地,第二设备的云端接收待验证信息,包括:
该第二设备的云端接收来自第一设备或该第一设备的云端的该待验证信息。
可选地,该第二设备的云端基于该设备标识对该加密数据进行解密和验证,包括:
该第二设备的云端根据该设备标识获取第二秘钥;
该第二设备的云端基于该第二秘钥对该加密数据进行解密得到第二数据;
该第二设备的云端基于该第二数据对第一数据进行验证。
可选地,该第二秘钥对应的加密秘钥为第一秘钥;其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该第二设备的云端根据该设备标识获取第二秘钥,包括:
该第二设备的云端获取该设备标识对应的该第二秘钥。
可选地,该待验证信息中还包括随机数,该第二设备的云端根据该设备标识获取第二秘钥,包括:
该第二设备的云端获取该设备标识对应的秘钥集合;
该第二设备的云端基于该待验证信息中的随机数计算秘钥标识,并获取该秘钥标识对应的该第二秘钥。
可选地,该加密数据是该第二设备基于第一秘钥对第一数据计算得到的。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据。
可选地,该第二设备的云端基于该第二数据对第一数据进行验证,包括:
该第二设备的云端获取该设备标识对应的第一数据;
该第二设备的云端比较该第二数据与该第一数据是否一致;
在该第二数据与该第一数据一致的情况下,该第二设备的云端判定对该加密数据的验证成功。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该第一算法用于对该启动次数进行计算得到第一序号。
可选地,该第二设备的云端基于该第二数据对第一数据进行验证,包括:
该第二设备的云端获取该设备标识对应的设定数据;
该第二设备的云端基于该第一算法对该待验证信息中包括的启动次数进行计算得到验证标识,基于该验证标识和该设定数据计算得到第一数据;
该第二设备的云端比较该第二数据与该第一数据是否一致;
在该第二数据与该第一数据一致的情况下,该第二设备的云端判定对该加密数据的验证成功。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该第二算法用于对该随机数进 行计算得到第二序号。
可选地,该第二设备的云端基于该第二数据对第一数据进行验证,包括:
该第二设备的云端获取该设备标识对应的设定数据;
该第二设备的云端基于该第二算法对该待验证信息中包括的随机数进行计算得到秘钥标识,基于该秘钥标识和该设定数据计算得到第一数据;
该第二设备的云端比较该第二数据与该第一数据是否一致;
在该第二数据与该第一数据一致的情况下,该第二设备的云端判定对该加密数据的验证成功。
可选地,该方法还包括:
该第二设备的云端接收来自第一设备或该第一设备的云端的访问令牌,该访问令牌用于访问该第二设备的云端;
该第二设备的云端对该访问令牌进行验证;
在对该访问令牌的验证成功的情况下,该第二设备的云端再执行对该加密数据进行验证的步骤。
可选地,该待验证信息中还包括证书,该证书中包括该第一秘钥对应的第二秘钥,该方法还包括:
该第二设备的云端对该证书进行验证;
该第二设备的云端基于该证书中的该第二秘钥对该加密数据进行解密得到第二数据,并基于该第二数据对第一数据进行验证;
在对该证书的验证成功并且对该加密数据的验证成功的情况下,该第二设备的云端判定本次接入验证成功。
本实施例的第二设备的云端执行方法400的具体示例可以参见上述方法200、300的中关于第二设备的云端的相关描述,为了简洁,在此不再赘述。
图5是根据本申请一实施例的设备验证方法500的示意性流程图。该方法可选地可以应用于图1所示的系统,但并不仅限于此。该方法包括以下内容的至少部分内容。
S510、第二设备基于第一秘钥对第一数据进行加密得到加密数据;
S520、第二设备向第一设备发送待验证信息,以通过该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证,该待验证信息中包括第二设备的设备标识和该加密数据。
可选地,该第二设备向第一设备发送待验证信息,包括:
该第二设备向该第一设备发送广播消息,该广播消息中包括该待验证信息。
可选地,该广播消息包括信标帧,该信标帧的基本服务集标识BSSID字段中包括该第二设备的设备标识,该信标帧的服务集标识SSID字段和/或厂商自定义字段中包括该加密数据。
可选地,该信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在该加密数据的标识。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据,该方法还包括:
该第二设备基于散列算法对该预设数据进行计算,得到该散列摘要数据。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该方法还包括:
该第二设备基于该第一算法对该启动次数进行计算得到第一序号,并基于该第一序号和该预设数据得到该第一数据。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该方法还包括:
该第二设备基于该第二算法对该随机数进行计算得到第二序号,并基于该第二序号和该预设数据得到该第一数据。
可选地,该第一数据还包括启动次数和随机数,该启动次数具有对应的第一算法,该随机数具有对应的第二算法,该方法还包括:
该第二设备基于该第一算法对该启动次数进行计算得到第一序号;
该第二设备基于该第二算法对该随机数进行计算得到第二序号;
该第二设备基于该第一序号、该第二序号和该预设数据得到该第一数据。
可选地,该第一秘钥对应的解密秘钥为第二秘钥;其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该待验证信息中还包括该第二设备的证书。
可选地,该方法还包括:
在验证结果为成功的情况下,该第二设备接收来自该第一设备的配网信息。
本实施例的第二设备执行方法500的具体示例可以参见上述方法200、300、400的中关于第二设备的相关描述,为了简洁,在此不再赘述。
在一种应用示例中,本申请实施例的技术方案可以在Wi-Fi AP的Beacon中携带用于验证设备身份的加密数据,从而在softAP配网方式中,在设置家庭Wi-Fi网络的SSID和密码之前完成对设备身份的校验。参见图6,在本示例中,第一设备中可以安装用于进行网络配置的应用程序,可以简称应用(B厂商APP),第二设备可以简称设备(A厂商设备)。第一设备的云端可以为应用厂商的云服务(B厂商云,图6中未示出,可以在B厂商APP与A厂商云之间,起到代理作用)。第二设备的云端可以为设备厂商的云服务(A厂商云)。该方案具体可以包括:
1、设备厂商为每个设备(可以采用设备ID来标识)分配一对唯一的非对称密钥(私钥K1和公钥K2)。其中,私钥K1可以预置到对应的设备中,公钥K2和对应的设备ID可以保存在厂商的云服务中。此外,也可以为设备分配多对非对称秘钥,这样,私钥K1的集合可以预置到对应的设备中,公钥K2的集合和对应的设备ID可以保存在厂商的云服务中。
2、Wi-Fi设备例如智能冰箱等家用电器使用预置的私钥K1对特定数据D1。例如设备厂商规定的预定义数据进行加密得到S1。其中,所有设备的D1可以都一样,或者,每个设备的D1也可以都不同。每个设备都不同的情况下,厂商的云服务可以保存每个设备ID对应的D1。
3、Wi-Fi设备开启softAP,将设备ID设置到信标帧(Beacon Frame)的基本服务集标识(BSSID)字段。可选地,可以将功能标识F1设置到信标帧(Beacon Frame)的服务集标识(SSID)字段和/或厂商自定义(Vendor Specific)字段,F1用于指示Wi-Fi接入设备此信标帧数据是否包含S1。将S1设置到信标帧(Beacon Frame)的服务集标识(SSID)字段和/或厂商自定义(Vendor Specific)字段数据中进行广播。
4、可选地,对于D1仅使用固定的预定义数据(即不包含下述步骤5的N1和/或步骤6的N2)的情况,可以将设备ID和S1生成二维码并打印到设备包装上或者说明书上,手机可以通过扫描该二维码获取设备ID和S1,这样Wi-Fi设备可以不用开启softAP。
5、可选地,Wi-Fi设备可以记录自身启动softAP的次数,设备每次启动softAP时,在Beacon帧中还携带该启动次数N1。使用厂商预定义初始数据(例如固定数据)和预定义初始序号(例如123)做为第 1次softAP配网的原数据D1。后续可以使用厂商预定义初始数据(例如固定数据)和按预定义算法增大后的序号例如225(123+10*10+2)),修改初始数据,作为第2次softAP配网的原数据D1。厂商云服务也记录每次验证时的序号(根据手机发送的N1按预定义算法计算得到),对小于已记录的序号的验证请求返回失败,这样可以防止重放攻击。可选地,也可以用较大的初始序号和减小序号的预定义算法,厂商云服务对大于已记录的序号的验证请求返回失败。
6、可选地,设备厂商为每个设备分配多对公私钥,设备每次启动softAP时,在Beacon中还可以携带一个随机数N2。使用厂商预定义初始数据(例如固定数据)和N2一起作为原数据D1。具体可以根据该随机数使用厂商预定义算法(例如按私钥总个数求模取余运算得到私钥的序号)选择自身多个私钥中的一个加密D1得到S1,这样也可以防止重放攻击。
7、Wi-Fi接入设备(例如手机)的应用程序接收并解析前述Wi-Fi设备的信标帧,获取其中的设备ID。根据前述F1确定信标帧包含了前述S1并获取前述S1。可选地,还可以获取信标帧中的N1和/或N2。
8、Wi-Fi接入设备(例如手机)的应用程序登录应用的云服务(应用厂商与设备厂商为同一厂商)获取访问令牌,或者通过云服务之间的验证(应用厂商与设备厂商非同一厂商,例如使用OAuth验证)获取厂商云的访问令牌。可选地,该步骤也可以在接入设备从信标帧中获取到S1之前执行。
9、Wi-Fi接入设备(例如手机)的应用程序将访问令牌,设备ID和S1(和N1和/或N2)发送到设备厂商的云服务。云服务根据设备ID和前述N1和/或N2对应的密钥选择策略从保存的公钥列表中查询到对应的公钥K2,并进行验证。使用K2对签名S1进行解密得到D2,若D2与已知数据D1一样则验证通过,否则验证失败。
10、可选地,应用厂商与设备厂商非同一厂商的情形下,Wi-Fi接入设备(例如手机)的应用程序也可以不直接访问设备厂商的云服务,而是将设备ID和S1(和N1和/或N2)发送给应用厂商的云服务,由应用厂商的云服务代理访问设备厂商的云服务。
11、Wi-Fi接入设备(例如手机)的应用程序收到验证结果后,若验证成功则连接前述Wi-Fi设备的softAP网络,给该Wi-Fi设备设置家庭Wi-Fi网络的SSID和密码。否则流程结束。
示例性地:若使用服务集标识(SSID)字段传输S1,由于SSID字段值最大长度为32字节,要求加密后产生的S1长度与功能标识F1的长度(例如F1占用至少1字节)不超过32字节。可选地,如果还同时传输N1和N2,则S1、F1N1和N2的总长度不超过32字节。也就是说,D1不超过31字节且使用密钥长度不大于31字节的非对称算法。厂商自定义(Vendor Specific)字段无此限制。
可选地,也可以按一般的数字签名实现,加密时使用K1对D1的散列摘要数据H1进行加密得到S1,验证签名时云服务需要对S1解密得到H2,并且需要对D1进行散列摘要计算得到H3,然后云服务比对H2与H3,若一致则验证通过,否则验证失败。
可选地,应用厂商与设备厂商非同一厂商的情形下,为了避免跨厂商云服务之间的交互(导致厂商云服务需要实现特定接口),可以采用证书链验证方法。具体地,应用厂商与设备厂商持有同样的上级CA的证书CertR,还持有由该上级CA签发的各自的证书CertA和CertB。其中,CertR包含公钥Kr和更上级CA的签名Srr,Kr对应的私钥Kpr由该上级CA自身持有。CertA包含公钥Ka和用Kpr加密的签名Sa,Ka对应的私钥Kpa由应用厂商自身持有。CertB包含公钥Kb和用Kpr加密的签名Sb,Kb对应的私钥Kpb由设备厂商自身持有。设备持有前述上级CA所签发的CertC,CertC包含公钥Kc和 用Kpr加密的签名Sc,Kc对应的私钥Kpc由设备自身持有。设备在前述Beacon中和/或前述二维码中携带如下信息:原数据D1(如前述),自身的私钥Kpc所加密的签名数据S1和CertC。应用厂商通过前述流程收到该信息后进行如下验证:使用公钥Kr验证CertC,确定CertC中包含的公钥Kc是合法的再使用CertC中包含的公钥Kc验证S1。此方式所需携带的数据较长,一般使用厂商自定义(Vendor Specific)字段或者二维码。
可选地,可以使用对称加密算法(例如AES,DES等)和对称密钥(即前述流程中K1与K2一样)代替前述非对称加密算法和非对称密钥。例如,设备对D1进行使用密钥K1对称加密计算得到S1,云服务验证时使用K2(等于K1)对S1进行解密得到数据D2,若D2与D1一样则验证通过,否则验证失败。对称加密方案比非对称加密方案更易实施,而非对称加密方案安全性更高。
本申请实施例的,技术方案在设置家庭Wi-Fi网络的SSID和密码之前就完成对设备身份的校验,可以提升softAP配网的安全性。
图7是根据本申请一实施例的第一设备20的示意性框图。该第一设备20可以包括:
获取单元21,用于获取待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
发送单元22,用于将该待验证信息发送至云端以对该加密数据进行解密和验证。
可选地,该获取单元21用于执行以下步骤的至少之一:
接收广播消息,该广播消息中包括该待验证信息;
扫描图形编码得到该待验证信息。
可选地,该广播消息包括信标帧,该信标帧的基本服务集标识BSSID字段中包括该第二设备的设备标识,该信标帧的服务集标识SSID字段和/或厂商自定义字段中包括该加密数据。
可选地,该信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在该加密数据的标识。
可选地,该加密数据是该第二设备基于第一秘钥对第一数据计算得到的。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该第一算法用于对该启动次数进行计算得到第一序号。
可选地,该待验证信息中还包括该启动次数。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该第二算法用于对该随机数进行计算得到第二序号。
可选地,该待验证信息中还包括该随机数。
可选地,该第一秘钥对应的解密秘钥为第二秘钥;其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该待验证信息中还包括该第二设备的证书,该证书中包括该第一秘钥对应的第二秘钥。
可选地,该发送单元22还用于向云端发送访问令牌,该访问令牌用于访问该第二设备的云端。
可选地,该获取单元21还用于接收验证结果;
该发送单元22还用于在该验证结果为成功的情况下,向该第二设备发送配网信息。
本申请实施例的第一设备20能够实现前述的方法实施例中的第一设备的对应功能。该第一设备20 中的各个模块(子模块、单元或组件等)对应的流程、功能、实现方式以及有益效果,可参见上述方法实施例中的对应描述,在此不再赘述。需要说明,关于申请实施例的第一设备20中的各个模块(子模块、单元或组件等)所描述的功能,可以由不同的模块(子模块、单元或组件等)实现,也可以由同一个模块(子模块、单元或组件等)实现。
图8是根据本申请一实施例的第一云端30的示意性框图。该第一云端30可以包括:
接收单元31,用于接收来自第一设备的待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
处理单元32,用于对该加密数据进行解密和验证。
可选地,该加密数据是该第二设备基于第一秘钥对第一数据计算得到的。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该第一算法用于对该启动次数进行计算得到第一序号。
可选地,该待验证信息中还包括该启动次数。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该第二算法用于对该随机数进行计算得到第二序号。
可选地,该待验证信息中还包括该随机数。
可选地,该第一秘钥对应的解密秘钥为第二秘钥;其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该处理单元32还用于将该待验证信息发送至该第二设备的云端以对该加密数据进行解密和验证。
可选地,该接收单元31还用于接收来自该第二设备的云端的验证结果;
该处理单元32还用于向该第一设备发送该验证结果。
可选地,该待验证信息中还包括该第二设备的证书,该证书中包括该第一秘钥对应的第二秘钥。
可选地,该处理单元32还用于对该证书进行验证;基于该证书中的该第二秘钥对该加密数据进行解密得到第二数据,并基于该第二数据对第一数据进行验证;在对该证书的验证成功并且对该第一数据的验证成功的情况下,判定本次接入验证成功;向该第一设备发送该验证结果。
可选地,该接收单元31还用于接收来自该第一设备的访问令牌,该访问令牌用于访问该第二设备的云端;
该处理单元32还用于将该访问令牌发送至该第二设备的云端进行验证。
本申请实施例的第一云端30能够实现前述的方法实施例中的第一设备的云端的对应功能。该第一云端30中的各个模块(子模块、单元或组件等)对应的流程、功能、实现方式以及有益效果,可参见上述方法实施例中的对应描述,在此不再赘述。需要说明,关于申请实施例的第一云端30中的各个模块(子模块、单元或组件等)所描述的功能,可以由不同的模块(子模块、单元或组件等)实现,也可以由同一个模块(子模块、单元或组件等)实现。
图9是根据本申请一实施例的第二云端40的示意性框图。该第二云端40可以包括:
接收单元41,用于接收待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;
处理单元42,用于基于该设备标识对该加密数据进行解密和验证。
可选地,该接收单元41还用于接收来自第一设备或该第一设备的云端的该待验证信息。
可选地,该处理单元42还用于根据该设备标识获取第二秘钥;基于该第二秘钥对该加密数据进行解密得到第二数据;基于该第二数据对第一数据进行验证。
可选地,该第二秘钥对应的加密秘钥为第一秘钥;其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该处理单元42还用于获取该设备标识对应的该第二秘钥。
可选地,该待验证信息中还包括随机数,该处理单元还用于获取该设备标识对应的秘钥集合;基于该待验证信息中的随机数计算秘钥标识,并获取该秘钥标识对应的该第二秘钥。
可选地,该加密数据是该第二设备基于第一秘钥对第一数据计算得到的。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据。
可选地,该处理单元42还用于获取该设备标识对应的第一数据;比较该第二数据与该第一数据是否一致;在该第二数据与该第一数据一致的情况下,判定对该加密数据的验证成功。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该第一算法用于对该启动次数进行计算得到第一序号。
可选地,该处理单元42还用于获取该设备标识对应的设定数据;基于该第一算法对该待验证信息中包括的启动次数进行计算得到验证标识,基于该验证标识和该设定数据计算得到第一数据;比较该第二数据与该第一数据是否一致;在该第二数据与该第一数据一致的情况下,判定对该加密数据的验证成功。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该第二算法用于对该随机数进行计算得到第二序号。
可选地,该处理单元42还用于获取该设备标识对应的设定数据;基于该第二算法对该待验证信息中包括的随机数进行计算得到秘钥标识,基于该秘钥标识和该设定数据计算得到第一数据;比较该第二数据与该第一数据是否一致;在该第二数据与该第一数据一致的情况下,判定对该加密数据的验证成功。
可选地,该接收单元41还用于接收来自第一设备或该第一设备的云端的访问令牌,该访问令牌用于访问该第二设备的云端;
该处理单元42还用于对该访问令牌进行验证;在对该访问令牌的验证成功的情况下,再执行对该加密数据进行验证的步骤。
可选地,该待验证信息中还包括证书,该证书中包括该第一秘钥对应的第二秘钥,该处理单元42还用于对该证书进行验证;基于该证书中的该第二秘钥对该加密数据进行解密得到第二数据,并基于该第二数据对第一数据进行验证;在对该证书的验证成功并且对该加密数据的验证成功的情况下,判定本次接入验证成功。
本申请实施例的第二云端40能够实现前述的方法实施例中的第二设备的云端的对应功能。该第二云端40中的各个模块(子模块、单元或组件等)对应的流程、功能、实现方式以及有益效果,可参见上述方法实施例中的对应描述,在此不再赘述。需要说明,关于申请实施例的第二云端40中的各个模块(子模块、单元或组件等)所描述的功能,可以由不同的模块(子模块、单元或组件等)实现,也可 以由同一个模块(子模块、单元或组件等)实现。
图10是根据本申请一实施例的第二设备50的示意性框图。该第二设备50可以包括:
加密单元51,用于基于第一秘钥对第一数据进行加密得到加密数据;
发送单元52,用于向第一设备发送待验证信息,以通过该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证,该待验证信息中包括第二设备的设备标识和该加密数据。
可选地,该发送单元52还用于向该第一设备发送广播消息,该广播消息中包括该待验证信息。
可选地,该广播消息包括信标帧,该信标帧的基本服务集标识BSSID字段中包括该第二设备的设备标识,该信标帧的服务集标识SSID字段和/或厂商自定义字段中包括该加密数据。
可选地,该信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在该加密数据的标识。
可选地,该第一数据包括预设数据。
可选地,该第一数据包括预设数据的散列摘要数据,该加密单元51还用于基于散列算法对该预设数据进行计算,得到该散列摘要数据。
可选地,该第一数据还包括启动次数,该启动次数具有对应的第一算法,该加密单元51还用于基于该第一算法对该启动次数进行计算得到第一序号,并基于该第一序号和该预设数据得到该第一数据。
可选地,该第一数据还包括随机数,该随机数具有对应的第二算法,该加密单元51还用于基于该第二算法对该随机数进行计算得到第二序号,并基于该第二序号和该预设数据得到该第一数据。
可选地,该第一数据还包括启动次数和随机数,该启动次数具有对应的第一算法,该随机数具有对应的第二算法,该加密单元51还用于基于该第一算法对该启动次数进行计算得到第一序号;基于该第二算法对该随机数进行计算得到第二序号;基于该第一序号、该第二序号和该预设数据得到该第一数据。
可选地,该第一秘钥对应的解密秘钥为第二秘钥;
其中,该第一秘钥为私钥,该第一秘钥对应的公钥为该第二秘钥;或者,该第一秘钥与该第二秘钥相同。
可选地,该待验证信息中还包括该第二设备的证书。
可选地,该第二设备还包括:
接收单元,用于在验证结果为成功的情况下,接收来自该第一设备的配网信息。
本申请实施例的第二设备50能够实现前述的方法实施例中的第二设备的对应功能。该第二设备50中的各个模块(子模块、单元或组件等)对应的流程、功能、实现方式以及有益效果,可参见上述方法实施例中的对应描述,在此不再赘述。需要说明,关于申请实施例的第二设备50中的各个模块(子模块、单元或组件等)所描述的功能,可以由不同的模块(子模块、单元或组件等)实现,也可以由同一个模块(子模块、单元或组件等)实现。
图11是根据本申请实施例的通信设备600示意性结构图。该通信设备600包括处理器610,处理器610可以从存储器中调用并运行计算机程序,以使通信设备600实现本申请实施例中的方法。
可选地,通信设备600还可以包括存储器620。其中,处理器610可以从存储器620中调用并运行计算机程序,以使通信设备600实现本申请实施例中的方法。
其中,存储器620可以是独立于处理器610的一个单独的器件,也可以集成在处理器610中。
可选地,通信设备600还可以包括收发器630,处理器610可以控制该收发器630与其他设备进行 通信,具体地,可以向其他设备发送信息或数据,或接收其他设备发送的信息或数据。
其中,收发器630可以包括发射机和接收机。收发器630还可以进一步包括天线,天线的数量可以为一个或多个。
可选地,该通信设备600可为本申请实施例的第一设备、第二设备、第一设备的云端或第二设备的云端,并且该通信设备600可以实现本申请实施例的各个方法中由终端设备实现的相应流程,为了简洁,在此不再赘述。
图12是根据本申请实施例的芯片700的示意性结构图。该芯片700包括处理器710,处理器710可以从存储器中调用并运行计算机程序,以实现本申请实施例中的方法。
可选地,芯片700还可以包括存储器720。其中,处理器710可以从存储器720中调用并运行计算机程序,以实现本申请实施例中由第一设备、第二设备、第一设备的云端或第二设备的云端执行的方法。
其中,存储器720可以是独立于处理器710的一个单独的器件,也可以集成在处理器710中。
可选地,该芯片700还可以包括输入接口730。其中,处理器710可以控制该输入接口730与其他设备或芯片进行通信,具体地,可以获取其他设备或芯片发送的信息或数据。
可选地,该芯片700还可以包括输出接口740。其中,处理器710可以控制该输出接口740与其他设备或芯片进行通信,具体地,可以向其他设备或芯片输出信息或数据。
可选地,该芯片可应用于本申请实施例中的第一设备、第二设备、第一设备的云端或第二设备的云端,并且该芯片可以实现本申请实施例的各个方法中由第一设备、第二设备、第一设备的云端或第二设备的云端实现的相应流程,为了简洁,在此不再赘述。
应用于第一设备、第二设备、第一设备的云端或第二设备的云端的芯片可以是相同的芯片或不同的芯片。
应理解,本申请实施例提到的芯片还可以称为系统级芯片,系统芯片,芯片系统或片上系统芯片等。
上述提及的处理器可以是通用处理器、数字信号处理器(digital signal processor,DSP)、现成可编程门阵列(field programmable gate array,FPGA)、专用集成电路(application specific integrated circuit,ASIC)或者其他可编程逻辑器件、晶体管逻辑器件、分立硬件组件等。其中,上述提到的通用处理器可以是微处理器或者也可以是任何常规的处理器等。
上述提及的存储器可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory,RAM)。
应理解,上述存储器为示例性但不是限制性说明,例如,本申请实施例中的存储器还可以是静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic RAM,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器(synch link DRAM,SLDRAM)以及直接内存总线随机存取存储器(Direct Rambus RAM,DR RAM)等等。也就是说,本申请实施例中的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
图13是根据本申请实施例的通信系统800的示意性框图。该通信系统800包括第一设备810、第二设备820和云端。
第一设备810,用于获取待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;将该待验证信息发送至云端以对该加密数据进行解密和验证。
第二设备820,用于基于第一秘钥对第一数据进行加密得到加密数据;
发送单元,用于向第一设备发送待验证信息,以通过该第一设备将该待验证信息发送至云端以对该加密数据进行解密和验证,该待验证信息中包括第二设备的设备标识和该加密数据。
云端,用于接收待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;对该加密数据进行解密和验证。
可选地,该云端可以包括第一云端830和/或第二云端840。
第一云端830,用于接收来自第一设备的待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;对该加密数据进行解密和验证;
第二云端840,用于接收待验证信息,该待验证信息中包括第二设备的设备标识和加密数据;基于该设备标识对该加密数据进行解密和验证。
其中,该第一设备810可以用于实现上述方法中由第一设备实现的相应的功能;该第二设备820可以用于实现上述方法中由第二设备实现的相应的功能;该第一云端830可以用于实现上述方法中由第一设备的云端实现的相应的功能;该第二云端840可以用于实现上述方法中由第二设备的云端实现的相应的功能。为了简洁,在此不再赘述。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时,全部或部分地产生按照本申请实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘(Solid State Disk,SSD))等。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
以上所述仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以该权利要求的保护范围为准。
Claims (124)
- 一种设备验证方法,包括:第一设备获取待验证信息,所述待验证信息中包括第二设备的设备标识和加密数据;所述第一设备将所述待验证信息发送至云端以对所述加密数据进行解密和验证。
- 根据权利要求1所述的方法,其中,第一设备获取待验证信息,包括以下至少之一:所述第一设备接收广播消息,所述广播消息中包括所述待验证信息;所述第一设备扫描图形编码得到所述待验证信息。
- 根据权利要求2所述的方法,其中,所述广播消息包括信标帧,所述信标帧的基本服务集标识BSSID字段中包括所述第二设备的设备标识,所述信标帧的服务集标识SSID字段和/或厂商自定义字段中包括所述加密数据。
- 根据权利要求3所述的方法,其中,所述信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在所述加密数据的标识。
- 根据权利要求1至4中任一项所述的方法,其中,所述加密数据是所述第二设备基于第一秘钥对第一数据计算得到的。
- 根据权利要求5所述的方法,其中,所述第一数据包括预设数据。
- 根据权利要求5或6所述的方法,其中,所述第一数据包括预设数据的散列摘要数据。
- 根据权利要求5至7中任一项所述的方法,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述第一算法用于对所述启动次数进行计算得到第一序号。
- 根据权利要求8所述的方法,其中,所述待验证信息中还包括所述启动次数。
- 根据权利要求5至9中任一项所述的方法,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述第二算法用于对所述随机数进行计算得到第二序号。
- 根据权利要求10所述的方法,其中,所述待验证信息中还包括所述随机数。
- 根据权利要求5至11中任一项所述的方法,其中,所述第一秘钥对应的解密秘钥为第二秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求5至12中任一项所述的方法,其中,所述待验证信息中还包括所述第二设备的证书,所述证书中包括所述第一秘钥对应的第二秘钥。
- 根据权利要求1至13中任一项所述的方法,其中,所述方法还包括:所述第一设备向云端发送访问令牌,所述访问令牌用于访问所述第二设备的云端。
- 根据权利要求1至14中任一项所述的方法,其中,所述方法还包括:所述第一设备接收验证结果;在所述验证结果为成功的情况下,所述第一设备向所述第二设备发送配网信息。
- 一种设备验证方法,包括:第一设备的云端接收来自第一设备的待验证信息,所述待验证信息中包括第二设备的设备标识和加密数据;所述第一设备的云端对所述加密数据进行解密和验证。
- 根据权利要求16所述的方法,其中,所述加密数据是所述第二设备基于第一秘钥对第一数据计 算得到的。
- 根据权利要求17所述的方法,其中,所述第一数据包括预设数据。
- 根据权利要求17或18所述的方法,其中,所述第一数据包括预设数据的散列摘要数据。
- 根据权利要求17至19中任一项所述的方法,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述第一算法用于对所述启动次数进行计算得到第一序号。
- 根据权利要求20所述的方法,其中,所述待验证信息中还包括所述启动次数。
- 根据权利要求17至21中任一项所述的方法,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述第二算法用于对所述随机数进行计算得到第二序号。
- 根据权利要求22所述的方法,其中,所述待验证信息中还包括所述随机数。
- 根据权利要求17至23中任一项所述的方法,其中,所述第一秘钥对应的解密秘钥为第二秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求16至24中任一项所述的方法,其中,所述第一设备的云端对所述加密数据进行解密和验证,包括:所述第一设备的云端将所述待验证信息发送至所述第二设备的云端以对所述加密数据进行解密和验证。
- 根据权利要求25所述的方法,其中,所述方法还包括:所述第一设备的云端接收来自所述第二设备的云端的验证结果;所述第一设备的云端向所述第一设备发送所述验证结果。
- 根据权利要求17至24中任一项所述的方法,其中,所述待验证信息中还包括所述第二设备的证书,所述证书中包括所述第一秘钥对应的第二秘钥。
- 根据权利要求27所述的方法,其中,所述第一设备的云端对所述加密数据进行解密和验证,包括:所述第一设备的云端对所述证书进行验证;所述第一设备的云端基于所述证书中的所述第二秘钥对所述加密数据进行解密得到第二数据,并基于所述第二数据对第一数据进行验证;在对所述证书的验证成功并且对所述第一数据的验证成功的情况下,判定本次接入验证成功;所述第一设备的云端向所述第一设备发送验证结果。
- 根据权利要求16至28中任一项所述的方法,其中,所述方法还包括:所述第一设备的云端接收来自所述第一设备的访问令牌,所述访问令牌用于访问所述第二设备的云端;所述第一设备的云端将所述访问令牌发送至所述第二设备的云端进行验证。
- 一种设备验证方法,包括:第二设备的云端接收待验证信息,所述待验证信息中包括第二设备的设备标识和加密数据;所述第二设备的云端基于所述设备标识对所述加密数据进行解密和验证。
- 根据权利要求30所述的方法,其中,第二设备的云端接收待验证信息,包括:所述第二设备的云端接收来自第一设备或所述第一设备的云端的所述待验证信息。
- 根据权利要求30或31所述的方法,其中,所述第二设备的云端基于所述设备标识对所述加密数据进行解密和验证,包括:所述第二设备的云端根据所述设备标识获取第二秘钥;所述第二设备的云端基于所述第二秘钥对所述加密数据进行解密得到第二数据;所述第二设备的云端基于所述第二数据对第一数据进行验证。
- 根据权利要求32所述的方法,其中,所述第二秘钥对应的加密秘钥为第一秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求32或33所述的方法,其中,所述第二设备的云端根据所述设备标识获取第二秘钥,包括:所述第二设备的云端获取所述设备标识对应的所述第二秘钥。
- 根据权利要求32或33所述的方法,其中,所述待验证信息中还包括随机数,所述第二设备的云端根据所述设备标识获取第二秘钥,包括:所述第二设备的云端获取所述设备标识对应的秘钥集合;所述第二设备的云端基于所述待验证信息中的随机数计算秘钥标识,并获取所述秘钥标识对应的所述第二秘钥。
- 根据权利要求32至35中任一项所述的方法,其中,所述加密数据是所述第二设备基于第一秘钥对第一数据计算得到的。
- 根据权利要求36所述的方法,其中,所述第一数据包括预设数据。
- 根据权利要求36或37所述的方法,其中,所述第一数据包括预设数据的散列摘要数据。
- 根据权利要求36至38中任一项所述的方法,其中,所述第二设备的云端基于所述第二数据对第一数据进行验证,包括:所述第二设备的云端获取所述设备标识对应的第一数据;所述第二设备的云端比较所述第二数据与所述第一数据是否一致;在所述第二数据与所述第一数据一致的情况下,所述第二设备的云端判定对所述加密数据的验证成功。
- 根据权利要求36至38中任一项所述的方法,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述第一算法用于对所述启动次数进行计算得到第一序号。
- 根据权利要求40所述的方法,其中,所述第二设备的云端基于所述第二数据对第一数据进行验证,包括:所述第二设备的云端获取所述设备标识对应的设定数据;所述第二设备的云端基于所述第一算法对所述待验证信息中包括的启动次数进行计算得到验证标识,基于所述验证标识和所述设定数据计算得到第一数据;所述第二设备的云端比较所述第二数据与所述第一数据是否一致;在所述第二数据与所述第一数据一致的情况下,所述第二设备的云端判定对所述加密数据的验证成功。
- 根据权利要求36至38、40中任一项所述的方法,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述第二算法用于对所述随机数进行计算得到第二序号。
- 根据权利要求42所述的方法,其中,所述第二设备的云端基于所述第二数据对第一数据进行验证,包括:所述第二设备的云端获取所述设备标识对应的设定数据;所述第二设备的云端基于所述第二算法对所述待验证信息中包括的随机数进行计算得到秘钥标识,基于所述秘钥标识和所述设定数据计算得到第一数据;所述第二设备的云端比较所述第二数据与所述第一数据是否一致;在所述第二数据与所述第一数据一致的情况下,所述第二设备的云端判定对所述加密数据的验证成功。
- 根据权利要求29至43中任一项所述的方法,其中,所述方法还包括:所述第二设备的云端接收来自第一设备或所述第一设备的云端的访问令牌,所述访问令牌用于访问所述第二设备的云端;所述第二设备的云端对所述访问令牌进行验证;在对所述访问令牌的验证成功的情况下,所述第二设备的云端再执行对所述加密数据进行验证的步骤。
- 根据权利要求29至44中任一项所述的方法,其中,所述待验证信息中还包括证书,所述证书中包括所述第一秘钥对应的第二秘钥,所述方法还包括:所述第二设备的云端对所述证书进行验证;所述第二设备的云端基于所述证书中的所述第二秘钥对所述加密数据进行解密得到第二数据,并基于所述第二数据对第一数据进行验证;在对所述证书的验证成功并且对所述加密数据的验证成功的情况下,所述第二设备的云端判定本次接入验证成功。
- 一种设备验证方法,包括:第二设备基于第一秘钥对第一数据进行加密得到加密数据;所述第二设备向第一设备发送待验证信息,以通过所述第一设备将所述待验证信息发送至云端以对所述加密数据进行解密和验证,所述待验证信息中包括第二设备的设备标识和所述加密数据。
- 根据权利要求46所述的方法,其中,所述第二设备向第一设备发送待验证信息,包括:所述第二设备向所述第一设备发送广播消息,所述广播消息中包括所述待验证信息。
- 根据权利要求47所述的方法,其中,所述广播消息包括信标帧,所述信标帧的基本服务集标识BSSID字段中包括所述第二设备的设备标识,所述信标帧的服务集标识SSID字段和/或厂商自定义字段中包括所述加密数据。
- 根据权利要求48所述的方法,其中,所述信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在所述加密数据的标识。
- 根据权利要求46至49中任一项所述的方法,其中,所述第一数据包括预设数据。
- 根据权利要求50所述的方法,其中,所述第一数据包括预设数据的散列摘要数据,所述方法还包括:所述第二设备基于散列算法对所述预设数据进行计算,得到所述散列摘要数据。
- 根据权利要求50或51所述的方法,其中,所述第一数据还包括启动次数,所述启动次数具有 对应的第一算法,所述方法还包括:所述第二设备基于所述第一算法对所述启动次数进行计算得到第一序号,并基于所述第一序号和所述预设数据得到所述第一数据。
- 根据权利要求50或51所述的方法,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述方法还包括:所述第二设备基于所述第二算法对所述随机数进行计算得到第二序号,并基于所述第二序号和所述预设数据得到所述第一数据。
- 根据权利要求50或51所述的方法,其中,所述第一数据还包括启动次数和随机数,所述启动次数具有对应的第一算法,所述随机数具有对应的第二算法,所述方法还包括:所述第二设备基于所述第一算法对所述启动次数进行计算得到第一序号;所述第二设备基于所述第二算法对所述随机数进行计算得到第二序号;所述第二设备基于所述第一序号、所述第二序号和所述预设数据得到所述第一数据。
- 根据权利要求46至54中任一项所述的方法,其中,所述第一秘钥对应的解密秘钥为第二秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求46至55中任一项所述的方法,其中,所述待验证信息中还包括所述第二设备的证书。
- 根据权利要求46至56中任一项所述的方法,其中,所述方法还包括:在验证结果为成功的情况下,所述第二设备接收来自所述第一设备的配网信息。
- 一种第一设备,包括:获取单元,用于获取待验证信息,所述待验证信息中包括第二设备的设备标识和加密数据;发送单元,用于将所述待验证信息发送至云端以对所述加密数据进行解密和验证。
- 根据权利要求58所述的第一设备,其中,所述获取单元用于执行以下步骤的至少之一:接收广播消息,所述广播消息中包括所述待验证信息;扫描图形编码得到所述待验证信息。
- 根据权利要求59所述的第一设备,其中,所述广播消息包括信标帧,所述信标帧的基本服务集标识BSSID字段中包括所述第二设备的设备标识,所述信标帧的服务集标识SSID字段和/或厂商自定义字段中包括所述加密数据。
- 根据权利要求60所述的第一设备,其中,所述信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在所述加密数据的标识。
- 根据权利要求58至61中任一项所述的第一设备,其中,所述加密数据是所述第二设备基于第一秘钥对第一数据计算得到的。
- 根据权利要求62所述的第一设备,其中,所述第一数据包括预设数据。
- 根据权利要求62或63所述的第一设备,其中,所述第一数据包括预设数据的散列摘要数据。
- 根据权利要求61至64中任一项所述的第一设备,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述第一算法用于对所述启动次数进行计算得到第一序号。
- 根据权利要求65所述的第一设备,其中,所述待验证信息中还包括所述启动次数。
- 根据权利要求62至66中任一项所述的第一设备,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述第二算法用于对所述随机数进行计算得到第二序号。
- 根据权利要求67所述的第一设备,其中,所述待验证信息中还包括所述随机数。
- 根据权利要求62至68中任一项所述的第一设备,其中,所述第一秘钥对应的解密秘钥为第二秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求62至69中任一项所述的第一设备,其中,所述待验证信息中还包括所述第二设备的证书,所述证书中包括所述第一秘钥对应的第二秘钥。
- 根据权利要求58至70中任一项所述的第一设备,其中,所述发送单元还用于向云端发送访问令牌,所述访问令牌用于访问所述第二设备的云端。
- 根据权利要求58至71中任一项所述的第一设备,其中,所述获取单元还用于接收验证结果;所述发送单元还用于在所述验证结果为成功的情况下,向所述第二设备发送配网信息。
- 一种第一云端,包括:接收单元,用于接收来自第一设备的待验证信息,所述待验证信息中包括第二设备的设备标识和加密数据;处理单元,用于对所述加密数据进行解密和验证。
- 根据权利要求73所述的第一云端,其中,所述加密数据是所述第二设备基于第一秘钥对第一数据计算得到的。
- 根据权利要求74所述的第一云端,其中,所述第一数据包括预设数据。
- 根据权利要求74或75所述的第一云端,其中,所述第一数据包括预设数据的散列摘要数据。
- 根据权利要求74至76中任一项所述的第一云端,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述第一算法用于对所述启动次数进行计算得到第一序号。
- 根据权利要求77所述的第一云端,其中,所述待验证信息中还包括所述启动次数。
- 根据权利要求74至78中任一项所述的第一云端,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述第二算法用于对所述随机数进行计算得到第二序号。
- 根据权利要求79所述的第一云端,其中,所述待验证信息中还包括所述随机数。
- 根据权利要求74至80中任一项所述的第一云端,其中,所述第一秘钥对应的解密秘钥为第二秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求73至81中任一项所述的第一云端,其中,所述处理单元还用于将所述待验证信息发送至所述第二设备的云端以对所述加密数据进行解密和验证。
- 根据权利要求82所述的第一云端,其中,所述接收单元还用于接收来自所述第二设备的云端的验证结果;所述处理单元还用于向所述第一设备发送所述验证结果。
- 根据权利要求74至81中任一项所述的第一云端,其中,所述待验证信息中还包括所述第二设备的证书,所述证书中包括所述第一秘钥对应的第二秘钥。
- 根据权利要求84所述的第一云端,其中,所述处理单元还用于对所述证书进行验证;基于所述证书中的所述第二秘钥对所述加密数据进行解密得到第二数据,并基于所述第二数据对第一数据进行验证;在对所述证书的验证成功并且对所述第一数据的验证成功的情况下,判定本次接入验证成功;向所述第一设备发送验证结果。
- 根据权利要求73至85中任一项所述的第一云端,其中,所述接收单元还用于接收来自所述第一设备的访问令牌,所述访问令牌用于访问所述第二设备的云端;所述处理单元还用于将所述访问令牌发送至所述第二设备的云端进行验证。
- 一种第二云端,包括:接收单元,用于接收待验证信息,所述待验证信息中包括第二设备的设备标识和加密数据;处理单元,用于基于所述设备标识对所述加密数据进行解密和验证。
- 根据权利要求87所述的第二云端,其中,所述接收单元还用于接收来自第一设备或所述第一设备的云端的所述待验证信息。
- 根据权利要求87或88所述的第二云端,其中,所述处理单元还用于根据所述设备标识获取第二秘钥;基于所述第二秘钥对所述加密数据进行解密得到第二数据;基于所述第二数据对第一数据进行验证。
- 根据权利要求89所述的第二云端,其中,所述第二秘钥对应的加密秘钥为第一秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求89或90所述的第二云端,其中,所述处理单元还用于获取所述设备标识对应的所述第二秘钥。
- 根据权利要求90或91所述的第二云端,其中,所述待验证信息中还包括随机数,所述处理单元还用于获取所述设备标识对应的秘钥集合;基于所述待验证信息中的随机数计算秘钥标识,并获取所述秘钥标识对应的所述第二秘钥。
- 根据权利要求89至92中任一项所述的第二云端,其中,所述加密数据是所述第二设备基于第一秘钥对第一数据计算得到的。
- 根据权利要求93所述的第二云端,其中,所述第一数据包括预设数据。
- 根据权利要求93或94所述的第二云端,其中,所述第一数据包括预设数据的散列摘要数据。
- 根据权利要求93至95中任一项所述的第二云端,其中,所述处理单元还用于获取所述设备标识对应的第一数据;比较所述第二数据与所述第一数据是否一致;在所述第二数据与所述第一数据一致的情况下,判定对所述加密数据的验证成功。
- 根据权利要求93至96中任一项所述的第二云端,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述第一算法用于对所述启动次数进行计算得到第一序号。
- 根据权利要求97所述的第二云端,其中,所述处理单元还用于获取所述设备标识对应的设定数据;基于所述第一算法对所述待验证信息中包括的启动次数进行计算得到验证标识,基于所述验证标识和所述设定数据计算得到第一数据;比较所述第二数据与所述第一数据是否一致;在所述第二数据与所述第一数据一致的情况下,判定对所述加密数据的验证成功。
- 根据权利要求93至95、97中任一项所述的第二云端,其中,所述第一数据还包括随机数,所 述随机数具有对应的第二算法,所述第二算法用于对所述随机数进行计算得到第二序号。
- 根据权利要求99所述的第二云端,其中,所述处理单元还用于获取所述设备标识对应的设定数据;基于所述第二算法对所述待验证信息中包括的随机数进行计算得到秘钥标识,基于所述秘钥标识和所述设定数据计算得到第一数据;比较所述第二数据与所述第一数据是否一致;在所述第二数据与所述第一数据一致的情况下,判定对所述加密数据的验证成功。
- 根据权利要求87至100中任一项所述的第二云端,其中,所述接收单元还用于接收来自第一设备或所述第一设备的云端的访问令牌,所述访问令牌用于访问所述第二设备的云端;所述处理单元还用于对所述访问令牌进行验证;在对所述访问令牌的验证成功的情况下,再执行对所述加密数据进行验证的步骤。
- 根据权利要求87至101中任一项所述的第二云端,其中,所述待验证信息中还包括证书,所述证书中包括所述第一秘钥对应的第二秘钥,所述处理单元还用于对所述证书进行验证;基于所述证书中的所述第二秘钥对所述加密数据进行解密得到第二数据,并基于所述第二数据对第一数据进行验证;在对所述证书的验证成功并且对所述加密数据的验证成功的情况下,判定本次接入验证成功。
- 一种第二设备,包括:加密单元,用于基于第一秘钥对第一数据进行加密得到加密数据;发送单元,用于向第一设备发送待验证信息,以通过所述第一设备将所述待验证信息发送至云端以对所述加密数据进行解密和验证,所述待验证信息中包括第二设备的设备标识和所述加密数据。
- 根据权利要求103所述的第二设备,其中,所述发送单元还用于向所述第一设备发送广播消息,所述广播消息中包括所述待验证信息。
- 根据权利要求104所述的第二设备,其中,所述广播消息包括信标帧,所述信标帧的基本服务集标识BSSID字段中包括所述第二设备的设备标识,所述信标帧的服务集标识SSID字段和/或厂商自定义字段中包括所述加密数据。
- 根据权利要求105所述的第二设备,其中,所述信标帧的SSID字段和/或厂商自定义字段中还包括用于指示是否存在所述加密数据的标识。
- 根据权利要求103至106中任一项所述的第二设备,其中,所述第一数据包括预设数据。
- 根据权利要求107所述的第二设备,其中,所述第一数据包括预设数据的散列摘要数据,所述加密单元还用于基于散列算法对所述预设数据进行计算,得到所述散列摘要数据。
- 根据权利要求107或108所述的第二设备,其中,所述第一数据还包括启动次数,所述启动次数具有对应的第一算法,所述加密单元还用于基于所述第一算法对所述启动次数进行计算得到第一序号,并基于所述第一序号和所述预设数据得到所述第一数据。
- 根据权利要求107或108所述的第二设备,其中,所述第一数据还包括随机数,所述随机数具有对应的第二算法,所述加密单元还用于基于所述第二算法对所述随机数进行计算得到第二序号,并基于所述第二序号和所述预设数据得到所述第一数据。
- 根据权利要求107或108所述的第二设备,其中,所述第一数据还包括启动次数和随机数,所述启动次数具有对应的第一算法,所述随机数具有对应的第二算法,所述加密单元还用于基于所述第一算法对所述启动次数进行计算得到第一序号;基于所述第二算法对所述随机数进行计算得到第二序号;基于所述第一序号、所述第二序号和所述预设数据得到所述第一数据。
- 根据权利要求103至111中任一项所述的第二设备,其中,所述第一秘钥对应的解密秘钥为第二秘钥;其中,所述第一秘钥为私钥,所述第一秘钥对应的公钥为所述第二秘钥;或者,所述第一秘钥与所述第二秘钥相同。
- 根据权利要求103至112中任一项所述的第二设备,其中,所述待验证信息中还包括所述第二设备的证书。
- 根据权利要求103至113中任一项所述的第二设备,其中,所述第二设备还包括:接收单元,用于在验证结果为成功的情况下,接收来自所述第一设备的配网信息。
- 一种通信设备,包括:处理器和存储器,该存储器用于存储计算机程序,所述处理器用于调用并运行所述存储器中存储的计算机程序,以使所述通信设备执行如权利要求1至15、46至57中任一项所述的方法。
- 一种通信设备,包括:处理器和存储器,该存储器用于存储计算机程序,所述处理器用于调用并运行所述存储器中存储的计算机程序,以使所述通信设备执行如权利要求16至45中任一项所述的方法。
- 一种芯片,包括:处理器,用于从存储器中调用并运行计算机程序,使得安装有所述芯片的设备执行如权利要求1至15、46至57中任一项所述的方法。
- 一种芯片,包括:处理器,用于从存储器中调用并运行计算机程序,使得安装有所述芯片的设备执行如权利要求16至45中任一项所述的方法。
- 一种计算机可读存储介质,用于存储计算机程序,当所述计算机程序被设备运行时使得所述设备执行如权利要求1至15、46至57中任一项所述的方法。
- 一种计算机可读存储介质,用于存储计算机程序,当所述计算机程序被设备运行时使得所述设备执行如权利要求16至45中任一项所述的方法。
- 一种计算机程序产品,包括计算机程序指令,该计算机程序指令使得计算机执行如权利要求1至15、46至57中任一项所述的方法。
- 一种计算机程序产品,包括计算机程序指令,该计算机程序指令使得计算机执行如权利要求16至45中任一项所述的方法。
- 一种计算机程序,所述计算机程序使得计算机执行如权利要求1至15、46至57中任一项所述的方法。
- 一种计算机程序,所述计算机程序使得计算机执行如权利要求16至45中任一项所述的方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2020/112286 WO2022041151A1 (zh) | 2020-08-28 | 2020-08-28 | 设备验证方法、设备和云端 |
CN202080102528.3A CN115868142A (zh) | 2020-08-28 | 2020-08-28 | 设备验证方法、设备和云端 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2020/112286 WO2022041151A1 (zh) | 2020-08-28 | 2020-08-28 | 设备验证方法、设备和云端 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022041151A1 true WO2022041151A1 (zh) | 2022-03-03 |
Family
ID=80352471
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2020/112286 WO2022041151A1 (zh) | 2020-08-28 | 2020-08-28 | 设备验证方法、设备和云端 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN115868142A (zh) |
WO (1) | WO2022041151A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114786177A (zh) * | 2022-04-07 | 2022-07-22 | 武汉联影医疗科技有限公司 | 边缘节点接入处理方法、移动终端和边缘节点 |
WO2024044978A1 (zh) * | 2022-08-30 | 2024-03-07 | 京东方科技集团股份有限公司 | 防伪验证方法、硬件装置、系统、电子设备及存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104537735A (zh) * | 2014-12-11 | 2015-04-22 | 应骏 | 电子锁及其解锁和设置方法 |
CN106921963A (zh) * | 2017-01-22 | 2017-07-04 | 海尔优家智能科技(北京)有限公司 | 一种智能设备接入无线局域网的方法及装置 |
CN109255653A (zh) * | 2018-08-27 | 2019-01-22 | 阿里巴巴集团控股有限公司 | 一种动销方法、装置及电子设备 |
CN111080856A (zh) * | 2019-12-27 | 2020-04-28 | 珠海市竞争电子科技有限公司 | 蓝牙门禁开锁方法 |
US10756964B2 (en) * | 2015-05-29 | 2020-08-25 | Espressif Systems (Shanghai) Co., Ltd. | Internet of things configuration method and system for secure low-power-consumption proxy device |
-
2020
- 2020-08-28 WO PCT/CN2020/112286 patent/WO2022041151A1/zh active Application Filing
- 2020-08-28 CN CN202080102528.3A patent/CN115868142A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104537735A (zh) * | 2014-12-11 | 2015-04-22 | 应骏 | 电子锁及其解锁和设置方法 |
US10756964B2 (en) * | 2015-05-29 | 2020-08-25 | Espressif Systems (Shanghai) Co., Ltd. | Internet of things configuration method and system for secure low-power-consumption proxy device |
CN106921963A (zh) * | 2017-01-22 | 2017-07-04 | 海尔优家智能科技(北京)有限公司 | 一种智能设备接入无线局域网的方法及装置 |
CN109255653A (zh) * | 2018-08-27 | 2019-01-22 | 阿里巴巴集团控股有限公司 | 一种动销方法、装置及电子设备 |
CN111080856A (zh) * | 2019-12-27 | 2020-04-28 | 珠海市竞争电子科技有限公司 | 蓝牙门禁开锁方法 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114786177A (zh) * | 2022-04-07 | 2022-07-22 | 武汉联影医疗科技有限公司 | 边缘节点接入处理方法、移动终端和边缘节点 |
CN114786177B (zh) * | 2022-04-07 | 2023-05-30 | 武汉联影医疗科技有限公司 | 边缘节点接入处理方法、移动终端和边缘节点 |
WO2024044978A1 (zh) * | 2022-08-30 | 2024-03-07 | 京东方科技集团股份有限公司 | 防伪验证方法、硬件装置、系统、电子设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN115868142A (zh) | 2023-03-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108512846B (zh) | 一种终端与服务器之间的双向认证方法和装置 | |
CN107800539B (zh) | 认证方法、认证装置和认证系统 | |
US9497171B2 (en) | Method, device, and system for securely sharing media content from a source device | |
WO2017028593A1 (zh) | 网络接入设备接入无线网络接入点的方法、网络接入设备、应用程序服务器和非易失性计算机可读存储介质 | |
US11134069B2 (en) | Method for authorizing access and apparatus using the method | |
JP6471112B2 (ja) | 通信システム、端末装置、通信方法、及びプログラム | |
CN105471974A (zh) | 实现远程控制的智能设备、终端设备及方法 | |
KR20190099066A (ko) | 디지털 인증서 관리 방법 및 장치 | |
CN110545252B (zh) | 一种认证和信息保护的方法、终端、控制功能实体及应用服务器 | |
JP2020526146A (ja) | 第1のアプリケーションと第2のアプリケーションとの間の対称型相互認証方法 | |
WO2022100356A1 (zh) | 身份认证系统、方法、装置、设备及计算机可读存储介质 | |
WO2022111187A1 (zh) | 终端认证方法、装置、计算机设备及存储介质 | |
CN108809907B (zh) | 一种证书请求消息发送方法、接收方法和装置 | |
CN111726801B (zh) | 一种网络安全控制方法 | |
WO2022041151A1 (zh) | 设备验证方法、设备和云端 | |
WO2017020530A1 (zh) | 一种增强的wlan证书鉴别方法、装置及系统 | |
CN104243452A (zh) | 一种云计算访问控制方法及系统 | |
CN112118568B (zh) | 一种设备身份鉴权的方法及设备 | |
CN115022850A (zh) | 一种d2d通信的认证方法、装置、系统、电子设备及介质 | |
WO2020009129A1 (ja) | 認証情報の設定を仲介するための装置及び方法 | |
CN113141333B (zh) | 入网设备的通信方法、设备、服务器、系统及存储介质 | |
US11240661B2 (en) | Secure simultaneous authentication of equals anti-clogging mechanism | |
WO2023240587A1 (zh) | 一种设备权限配置方法及装置、终端设备 | |
WO2022094936A1 (zh) | 接入方法、设备和云平台设备 | |
JP7312279B2 (ja) | モバイルネットワークアクセスシステム、方法、記憶媒体及び電子機器 |
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: 20950821 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: 20950821 Country of ref document: EP Kind code of ref document: A1 |