Reconnection authentication method and device, equipment and storage medium

Abstract

The invention relates to the field of personal family services, and provides a reconnection authentication method and device, equipment and a storage medium. The method comprises the following steps: under the condition that a first network device needs to be switched to a second network device, a reconnection request is sent to the second network device, and the reconnection request carries a hardware-level device identity identifier of the smart home device; receiving a response from the second network device; and if the response indicates that access is allowed, establishing a connection with the second network device based on network configuration information received from the second network device. According to the reconnection authentication method provided by the invention, non-inductive, safe and automatic reconnection of the smart home equipment in a cross-network equipment switching scene is realized through a local white list verification mechanism based on a hardware-level identity label.

Description

Technical Field

[0001] This invention relates to the field of personal and home business technology, and in particular to a reconnection authentication method, apparatus, device, and storage medium. Background Technology

[0002] In smart home scenarios, when users replace home network devices (e.g., replacing a damaged router with a new one) or when there are multiple network devices in the home, the connected smart home devices (such as cameras and smart sockets) often need to reconnect. Existing technologies mainly attempt to automatically reconnect by using historical Wi-Fi configurations stored in the smart home devices, such as Service Set Identifier (SSID) and password, or by relying on proprietary protocols between mesh network devices of the same brand to achieve automatic switching and reconnection of smart home devices between different access points within the signal coverage area.

[0003] However, existing methods struggle to quickly and securely verify the legitimacy of smart home devices attempting to connect when switching between network devices of different brands and models, resulting in smart home devices being unable to automatically complete network switching and reconnection. Summary of the Invention

[0004] This application provides a reconnection authentication method, apparatus, device, and storage medium to solve the technical problem that smart home devices cannot automatically complete network switching and reconnection.

[0005] In a first aspect, embodiments of this application provide a reconnection authentication method, applied to smart home devices, including: When it is necessary to switch from the first network device to the second network device, a reconnection request is sent to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. Receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access; If the response indicates that access is permitted, a connection is established with the second network device based on the network configuration information received from the second network device.

[0006] In some embodiments, the inherent hardware information includes at least one of the following: chip fingerprint, device serial number, and device media access control (MAC) address; wherein the chip fingerprint is generated by a trusted application within the smart home device chip based on a unique chip identifier and a hard random number.

[0007] In some embodiments, before sending a reconnection request to the second network device when a switch from the first network device to the second network device is required, the method further includes: Monitor the current connection status with the first network device; If the connection signal strength is detected to be lower than a preset threshold, or if the signal strength provided by the second network device is detected to be greater than the preset second threshold of the connection signal strength, it is determined that a switch to the second network device is required.

[0008] In some embodiments, the hardware-level device identity is obtained through the following process: When the smart home device first connects to the home network, it sends an activation request to the cloud platform, and the activation request carries the inherent information of the hardware. Receive the hardware-level device identity identifier generated by the cloud platform; wherein the hardware-level device identity identifier is calculated by the cloud platform based at least on the inherent information of the hardware and the digital home identity identifier; The hardware-level device identity is stored in the chip of the smart home device.

[0009] In some embodiments, the method further includes: If the response indicates that access is not allowed, then the system enters the network configuration standby mode.

[0010] Secondly, embodiments of this application provide a reconnection authentication method, using a network device, including: Receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device; The hardware-level device identity is verified based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; If the verification passes, a response allowing access is sent to the smart home device, along with network configuration information, to enable the smart home device to establish a connection.

[0011] In some embodiments, verifying the hardware-level device identity based on a locally stored device access whitelist includes: Determine whether the hardware-level device identity exists in the device identity list of the device access whitelist; If it exists, then the hardware-level device identity identifier is inversely operated to obtain the first digital family identity identifier; Verify whether the first digital family identity identifier is consistent with the digital family identity identifier recorded in the whitelist; If they match, the verification passes.

[0012] In some embodiments, before receiving a reconnection request from a smart home device, the method further includes: Send a registration request to the cloud platform, the registration request carrying the device information of the network device and the home network access information; Receive the digital home identity identifier issued by the cloud platform.

[0013] In some embodiments, the device access whitelist is obtained and stored locally through one of the following methods: The cloud platform actively pushes the message. Alternatively, a whitelist acquisition request can be initiated to the cloud platform, and the device access whitelist returned by the cloud platform can be received.

[0014] In some embodiments, if the verification fails, a response denying access is sent to the smart home device.

[0015] Thirdly, embodiments of this application provide a reconnection authentication method applied to a cloud platform, including: Based on the gateway device information and user network access information of the home network, generate and maintain a digital home identity for the home network; Based on the inherent hardware information reported by the smart home device and the digital home identity identifier, a hardware-level device identity identifier is generated for the smart home device. Based on the digital home identity, a device access whitelist is built and maintained for the corresponding home network. The device access whitelist includes the digital home identity and at least one hardware-level device identity that has been generated. The device is connected to the whitelist and synchronized to network devices within the home network.

[0016] In some embodiments, generating a hardware-level device identity for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity includes: Receive an activation request from the smart home device, the activation request carrying inherent hardware information; Based on the inherent hardware information, the digital home identity identifier, and a random number, the hardware-level device identity identifier is calculated and generated using a preset cryptographic combination algorithm. The generated hardware-level device identity is sent to the smart home device.

[0017] In some embodiments, the step of building and maintaining a device access whitelist for the corresponding home network based on the digital home identity includes: In response to generating a hardware-level device identity for a new smart home device, the new hardware-level device identity is added to the device access whitelist of the corresponding household.

[0018] In some embodiments, synchronizing the device access whitelist to network devices within the home network includes one of the following methods: Actively push updated device access whitelists to registered network devices within the home network; Alternatively, it can receive a whitelist retrieval request initiated by a network device and return the current device access whitelist to it.

[0019] Fourthly, embodiments of this application provide a reconnection authentication device applied to smart home devices, comprising: The request sending module is used to send a reconnection request to the second network device when it is necessary to switch from the first network device to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. A response receiving module is configured to receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access the network. The first processing module is configured to establish a connection with the second network device based on network configuration information received from the second network device if the response indicates that access is permitted.

[0020] Fifthly, embodiments of this application provide a reconnection authentication device, applied to a network device, comprising: The request receiving module is used to receive reconnection requests sent by smart home devices, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device. The identity verification module is used to verify the identity of the hardware-level device based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; The response sending module is used to send an access permission response to the smart home device and provide network configuration information if the verification passes, so that the smart home device can establish a connection.

[0021] Sixthly, this application provides a reconnection authentication device applied to a cloud platform, comprising: The first identification module is used to generate and maintain a digital home identity identifier for the home network based on the gateway device information and user network access information of the home network. The second identification module is used to generate a hardware-level device identification for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity identifier. The list generation module is used to build and maintain a device access whitelist for the corresponding home network based on the digital home identity identifier. The device access whitelist includes the digital home identity identifier and at least one hardware-level device identity identifier that has been generated. The list sending module is used to synchronize the device access whitelist to network devices within the home network.

[0022] In a seventh aspect, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the reconnection authentication method described in the first, second, or third aspect.

[0023] Eighthly, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the reconnection authentication method described in the first, second, or third aspects.

[0024] Ninthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the reconnection authentication method described in the first, second, or third aspects.

[0025] The reconnection authentication method, apparatus, device, and storage medium provided in this application embodiment achieve seamless and secure automatic reconnection of smart home devices in cross-network device switching scenarios through a local whitelist verification mechanism based on hardware-level identity identifiers. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is one of the flowcharts illustrating the reconnection authentication method provided in the embodiments of this application; Figure 2 This is a second flowchart illustrating the reconnection authentication method provided in the embodiments of this application; Figure 3This is the third flowchart illustrating the reconnection authentication method provided in the embodiments of this application; Figure 4 This is an interactive topology diagram of the reconnection authentication system provided in the embodiments of this application; Figure 5 This is an interactive schematic diagram of establishing a local authentication center for a home network provided in an embodiment of this application; Figure 6 This is an interaction diagram of the device hardware-level identity generation mechanism provided in the embodiments of this application; Figure 7 This is a flowchart illustrating the whitelist generation and update mechanism provided in the embodiments of this application; Figure 8 This is one of the structural schematic diagrams of the reconnection authentication device provided in the embodiments of this application; Figure 9 This is a second schematic diagram of the reconnection authentication device provided in the embodiments of this application; Figure 10 This is the third schematic diagram of the reconnection authentication device provided in the embodiments of this application; Figure 11 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0029] In smart home scenarios, when users replace home network devices (e.g., replacing a damaged router with a new one) or when there are multiple network devices in the home, the connected smart home devices (such as cameras and smart sockets) often need to reconnect. Existing technologies mainly attempt to automatically reconnect by using historical Wi-Fi configurations stored in the smart home devices, such as Service Set Identifier (SSID) and password, or by relying on proprietary protocols between mesh network devices of the same brand to achieve automatic switching and reconnection of smart home devices between different access points within the signal coverage area.

[0030] However, existing methods struggle to quickly and securely verify the legitimacy of smart home devices attempting to connect when switching between network devices of different brands and models, resulting in smart home devices being unable to automatically complete network switching and reconnection.

[0031] The solution provided in this application first generates a hardware-level device identity based on multiple factors such as device chip fingerprint, serial number (SN), MAC address, and home network, and then builds a whitelist of home device connections based on this identity. Subsequently, the whitelist is distributed to network devices within the home network.

[0032] When a smart home device initiates a reconnection request, the network device verifies the device's legitimacy through a whitelist. Once verified, the smart home device automatically reconnects and goes online without requiring manual reconfiguration and binding. This process is seamless for the user, improving the user experience while ensuring the security of automatic device reconnection.

[0033] Figure 1 This is one of the flowcharts illustrating the reconnection authentication method provided in the embodiments of this application. For example... Figure 1 As shown, this reconnection authentication method is applied to smart home devices and may include: Step 101: When it is necessary to switch from the first network device to the second network device, a reconnection request is sent to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs.

[0034] It should be noted that the hardware-level device identity is generated by the cloud platform based on the device's hardware characteristics and the identity information of the home network when the device first connects to the home network. It has uniqueness and anti-tampering characteristics.

[0035] For example, the "need to switch" may include the following scenario: the signal of the original router in the home weakens or malfunctions, and the smart home device actively scans and discovers other available network devices (such as a newly replaced router or another router in the home) and decides to initiate a connection to it.

[0036] Step 102: Receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access.

[0037] It should be noted that this response is the result returned by the second network device after receiving the reconnection request, based on its locally stored trusted device list (i.e., whitelist) synchronized by the cloud platform.

[0038] For example, if the smart home device has been previously activated and registered in the home network, its hardware-level device identity is usually included in the whitelist, and the second network device will return a response allowing access after verification.

[0039] Step 103: If the response indicates that access is permitted, then establish a connection with the second network device based on the network configuration information received from the second network device.

[0040] It should be noted that the network configuration information here is a necessary parameter for establishing a wireless connection. After being granted access, smart home devices can use this information to automatically complete network layer association and authentication.

[0041] For example, once the connection is established, the smart home device can resume communication with the Internet and report its online status to its corresponding business server, enabling the user to remotely control the device through a control terminal.

[0042] By combining hardware-level identity verification with local whitelist verification, smart home devices can achieve secure, automatic, and seamless reconnection when switching between network devices.

[0043] It is understood that the reconnection authentication method provided in this application is applicable to scenarios where users replace network devices and reconnect downstream devices in a home environment; or when there are multiple network devices, and downstream devices switch network devices to reconnect. For example, in a router replacement scenario, when the original router fails and is replaced with a new router, or when there are multiple routers in the home and the device actively switches to another router to maintain a good signal, this method allows smart home devices to automatically complete security authentication and reconnection without requiring manual reset and reconfiguration by the user, improving user experience while ensuring the legitimacy of device access. Through the above method, automatic and secure reconnection of smart home devices when switching network devices is achieved, solving problems such as complex manual network configuration operations, poor compatibility with cross-brand devices, and lack of device legitimacy verification in the prior art.

[0044] In some embodiments, the inherent hardware information includes at least one of the following: chip fingerprint, device serial number, and device media access control (MAC) address; wherein the chip fingerprint is generated by a trusted application within the smart home device chip based on a unique chip identifier and a hard random number.

[0045] It should be noted that the hardware-level identity proposed in this embodiment is generated by combining the hardware feature information of the device itself (such as chip fingerprint, serial number and / or MAC address) with the authentication factor of the home network to which it belongs (i.e. digital home identity), thereby realizing deep binding between the device and the home network at the identity level.

[0046] For example, the generation of hardware-level identity can be specifically manifested as follows: when a device first connects to a home network, it reports its chip fingerprint, serial number and MAC address to the cloud platform; after receiving this information, the cloud platform combines it with the digital home identity corresponding to the home and generates a unique hardware-level identity through cryptographic algorithms (such as a combination of hash, scatter or HMAC calculations) and sends it to the device, which then securely writes it into its chip.

[0047] Traditional solutions often use device serial numbers (SN) and MAC addresses as device identifiers, which can lead to security issues such as impersonation, tampering, and non-uniqueness. This solution proposes a hardware-level identifier, especially one that includes home network factors in its generation process, which is tamper-proof, impersonation-proof, and unique.

[0048] In some embodiments, before sending a reconnection request to the second network device when a switch from the first network device to the second network device is required, the method further includes: Monitor the current connection status with the first network device; If the connection signal strength is detected to be lower than a preset threshold, or if the signal strength provided by the second network device is detected to be greater than the preset second threshold of the connection signal strength, it is determined that a switch to the second network device is required.

[0049] It should be noted that the above monitoring and judgment process can be executed periodically or triggered by the local network management module or signal processing unit of the smart home device, aiming to achieve autonomous optimization of connection quality and intelligent decision-making for network switching.

[0050] For example, in a home environment, when a smart home device (such as a smart camera) moves away from its original router as it moves physically, the signal strength it detects may continue to drop below the threshold required to ensure stable communication. At this point, the device will actively scan for other available network devices in the environment. If it finds that another router (such as another node in the same home network) provides a significantly stronger signal than the current connection, the device can autonomously determine that a network switch is required.

[0051] By introducing an intelligent monitoring and switching decision mechanism based on real-time signal quality, this embodiment enables smart home devices to proactively maintain optimal network connectivity in multi-router or Mesh networking environments, effectively avoiding service interruptions or experience degradation caused by signal weakness, thereby achieving smooth and adaptive network roaming and reconnection without user intervention.

[0052] In some embodiments, the hardware-level device identity is obtained through the following process: When the smart home device first connects to the home network, it sends an activation request to the cloud platform, the activation request carrying the hardware's inherent information; it receives the hardware-level device identity identifier generated by the cloud platform; wherein the hardware-level device identity identifier is calculated by the cloud platform based at least on the hardware's inherent information and the digital home identity identifier; and it stores the hardware-level device identity identifier in the smart home device's chip.

[0053] It should be noted that this process is essentially a "registration" and "registration" process for the device within the home network. Through centralized authentication and identifier distribution on the cloud platform, a trusted connection is established between the device, the home network, and the cloud platform. Once the hardware-level device identity identifier is generated and written into the device chip, it becomes the device's permanent digital identity credential within the home network.

[0054] For example, when a user purchases a new smart socket and connects it to the network for the first time, the device reports its chip fingerprint, serial number, MAC address, and other information to the cloud platform through the gateway already connected to the home network. After verifying the validity of the home network, the cloud platform dynamically generates a unique hardware-level device identity using a preset cryptographic algorithm, combined with the family's digital home identity, and returns it to the device through a secure channel. The device writes this identity to its secure storage area, completing the activation process.

[0055] By uniformly generating and distributing hardware-level identity identifiers that are strongly bound to the home network through a cloud platform, centralized and standardized management of device identities is achieved. This not only ensures the global uniqueness and anti-counterfeiting of the identity identifiers, but also lays a reliable identity foundation for subsequent roaming and automatic reconnection of devices among different network devices within the home. At the same time, it avoids the counterfeiting and supply chain security risks associated with pre-setting fixed identifiers on the device side.

[0056] In some embodiments, the method further includes: if the response indicates that access is not allowed, then entering a network configuration standby mode.

[0057] It should be noted that the "network configuration pending mode" refers to a state where smart home devices stop automatically reconnecting and enter a state where they wait for the user to initiate or accept manual network configuration. In this state, the device can clearly prompt the user that network configuration is required through indicator lights, voice prompts, or notifications sent to associated mobile terminals.

[0058] By establishing a clear failure fallback mechanism, this embodiment ensures a smooth automatic reconnection process while providing a clear and reliable handling path for authentication failure scenarios. This not only avoids resource waste and connection deadlock caused by repeated reconnection attempts, but also ensures that users can still restore device functionality through the regular network configuration process when the network environment is abnormal or the device identity is not recognized by actively prompting user intervention. This improves the robustness of the system and the integrity of the user experience.

[0059] The reconnection authentication method provided in this application allows smart home devices to initiate a request using a unique identifier that is dually bound to the hardware and the home when switching networks, and to achieve seamless automatic reconnection based on the authorized response of the network device. This enables secure and seamless connection switching across network devices without the need for manual operation by the user.

[0060] Figure 2 This is the second flowchart illustrating the reconnection authentication method provided in the embodiments of this application. For example... Figure 2 As shown, this reconnection authentication method is applied to network devices and may include: Step 201: Receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device.

[0061] It should be noted that the reconnection request is an access request initiated by the smart home device when it detects that a network connection needs to be switched. The hardware-level device identity identifier carried by the device is used to verify the device identity and permissions on the network device side.

[0062] For example, when a smart home device moves from the living room router to the bedroom and detects a stronger signal from the bedroom router, it will send a reconnection request containing its hardware-level device identity to the bedroom router.

[0063] Step 202: Verify the identity of the hardware-level device based on the locally stored device access whitelist; wherein the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs.

[0064] It should be noted that the device access whitelist records a list of hardware-level identity identifiers of smart home devices that have been authorized to access the home network. Network devices complete the verification through local query and calculation, without needing to access the cloud in real time during the authentication process, thus ensuring low latency and high reliability.

[0065] For example, the verification process may include: firstly, querying the local whitelist to see if the hardware-level device identity exists; if it exists, then further parsing out the digital home identity contained therein through inverse operation, and comparing it with the digital home identity recorded in the whitelist; if the two match, the verification passes.

[0066] Step 203: If the verification passes, send an access permission response to the smart home device and provide network configuration information to enable the smart home device to establish a connection.

[0067] It should be noted that the network configuration information may include parameters such as SSID, password, and encryption method required for wireless access. After receiving the permission response and configuration information, the smart home device can automatically complete the network layer association and authentication process.

[0068] For example, after successful verification, the network device can return an "allow access" command and the access parameters of the current working Wi-Fi to the smart home device. Based on this information, the smart home device automatically connects to the network, registers with its business platform, and resumes a state that can be controlled by the user.

[0069] This embodiment achieves fast and secure authentication for smart home devices when switching access points within a home network through a local whitelist verification mechanism on the network device. This method not only reduces latency and reliance on cloud interaction but also effectively ensures that only legitimate devices belonging to the same household can automatically reconnect through dual binding of hardware-level identity and home network identity, thus enhancing network access security while improving user experience.

[0070] In some embodiments, verifying the hardware-level device identity based on a locally stored device access whitelist includes: Determine whether the hardware-level device identity exists in the device identity list of the device access whitelist; If it exists, then the hardware-level device identity identifier is inversely operated to obtain the first digital family identity identifier; Verify whether the first digital family identity identifier is consistent with the digital family identity identifier recorded in the whitelist; If they match, the verification passes.

[0071] It should be noted that the above verification process implements a multi-layered trusted verification mechanism. The hardware-level device identity itself is synthesized from the device hardware features and the home network identity through a cryptographic algorithm. The inverse operation can restore the home network identity elements involved in the generation. By comparing whether the restored identity is consistent with the home identity registered in the whitelist, it can be logically confirmed whether the device truly belongs to the current home network, thus completing the verification at both the device identity authenticity and home affiliation legitimacy levels.

[0072] The home device connection whitelist verification mechanism provided in this embodiment ensures that only devices from the same household are allowed to automatically reconnect by verifying the consistency of multiple factors, including device identity, digital home identity, and gateway information. Simultaneously, relying on the centralized management of the whitelist through a cloud platform, the whitelist content is promptly updated and synchronized to network devices within the household when a new device connects or an existing device is removed, thus guaranteeing the accuracy and timeliness of the whitelist.

[0073] In some embodiments, before receiving a reconnection request from a smart home device, the method further includes: Send a registration request to the cloud platform, the registration request carrying the device information of the network device and the home network access information; Receive the digital home identity identifier issued by the cloud platform.

[0074] It should be noted that the registration process described in this embodiment is a crucial step for network devices to join and authenticate their home network. The device information may include unique identifiers such as the network device's MAC address and serial number; the home network access information includes broadband account, password, or other authentication credentials provided by the network operator when activating the service. By submitting this information to the cloud platform, the network device can prove its legitimate qualification to access a specific home network and thereby obtain a digital home identity identifier representing the unique identity of that home network.

[0075] By executing the proactive registration and identity acquisition process of network devices with the cloud platform, this embodiment ensures that each network device has obtained authoritative digital identity authentication from its family before providing access services to devices within the home. This lays a reliable verification foundation for the subsequent whitelist verification mechanism based on digital home identity, preventing illegal or unauthorized network devices from impersonating the home network identity at the source, thereby enhancing the security and reliability of the entire automatic reconnection authentication system.

[0076] In some embodiments, the device access whitelist is obtained and stored locally through one of the following methods: The cloud platform actively pushes the message. Alternatively, a whitelist acquisition request can be initiated to the cloud platform, and the device access whitelist returned by the cloud platform can be received.

[0077] It should be noted that the proactive push refers to the cloud platform actively distributing the updated whitelist to all registered network devices in the household when it detects a change in the whitelist. The whitelist retrieval request can be initiated by the network device itself when it initializes, is triggered by a scheduled task, or detects that its local whitelist has expired. These two methods complement each other, ensuring that the whitelist stored locally on the network device remains synchronized with the authoritative version maintained by the cloud platform.

[0078] By supporting both push and pull whitelist synchronization mechanisms, this embodiment enhances the system's adaptability and robustness under different network conditions and application scenarios. The proactive push mode enables real-time synchronization of changes, ensuring the timely implementation of policies; while the pull request mode empowers network devices to proactively update verification criteria under specific circumstances, avoiding authentication service interruptions due to push failures or delays. This dual-mode synchronization mechanism jointly ensures the accuracy, reliability, and timely updating of the home device connection whitelist, providing a solid data foundation for localized and rapid authentication for automatic device reconnection.

[0079] In some embodiments, if the verification fails, a response denying access is sent to the smart home device.

[0080] It should be noted that the access denial response is an explicit instruction returned by the network device to the smart home device after completing local whitelist verification, based on the verification result. This response informs the smart home device that its automatic reconnection request has not been authorized, thereby terminating the current automatic connection process. The response may include information such as the denial reason code, which the smart home device can then process or log accordingly.

[0081] By explicitly sending an access denial response after verification failure, this embodiment ensures the logical completeness and clear interaction of the authentication process. This mechanism allows smart home devices to promptly know the final status of their reconnection requests, avoiding connection timeouts or resource consumption issues caused by prolonged waiting or lack of feedback. Simultaneously, the explicit denial response provides a basis for subsequent troubleshooting or security auditing, helping to maintain order in home network access and ensure the strict enforcement of security policies.

[0082] The reconnection authentication method provided in this application allows network devices to receive and store a whitelist of home devices issued by a cloud platform, and to perform fast and secure multi-factor authentication on the smart home devices that initiate reconnection requests locally. This enables automatic authorization of access for legitimate home devices and explicit rejection of illegitimate devices, ensuring access security and user experience in home network switching scenarios.

[0083] Figure 3 This is the third flowchart illustrating the reconnection authentication method provided in this application's embodiments. For example... Figure 3 As shown, this reconnection authentication method, applied to a cloud platform, may include: Step 301: Generate and maintain a digital home identity for the home network based on the gateway device information and user network access information of the home network.

[0084] It should be noted that the digital home identity is generated based on the authentication information generated when the operator opens a home broadband network account and the device is connected to the network. It is used to logically and authoritatively represent a specific home network entity.

[0085] For example, when a user activates home broadband and installs an optical modem or smart gateway for the first time, the cloud platform can obtain the device's MAC address, serial number, and access credentials such as broadband account and password, generate a unique digital home identity through a specific algorithm, and permanently bind it to the home account.

[0086] Step 302: Generate a hardware-level device identity for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity identifier.

[0087] It should be noted that the process of generating a hardware-level device identity is essentially a process of cryptographically binding the physical hardware characteristics of the device with its home network identity, thereby ensuring that the identity is both unique to the device and verifiable to the home network.

[0088] For example, when a new smart camera is first connected to the network in a home, it will report its chip fingerprint, serial number, MAC address and other information to the cloud platform. The cloud platform will combine this information with the digital home identity that the home has registered, and generate a globally unique hardware-level device identity through cryptographic operations such as hashing, scattering or message authentication codes.

[0089] Step 303: Based on the digital home identity, construct and maintain a device access whitelist for the corresponding home network. The device access whitelist includes the digital home identity and at least one generated hardware-level device identity.

[0090] It should be noted that the device access whitelist is a dynamic authorization list maintained by the cloud platform for each home network. Its core function is to define the set of legitimate devices allowed to automatically access the network within that home. This whitelist is rooted in the digital home identity and forms a tree-like trust structure by associating multiple device hardware-level identities.

[0091] For example, the cloud platform maintains a whitelist for each household, recording the household's digital home identity and the hardware-level device identities of all activated smart home devices (such as TVs, speakers, sensors, etc.). This list is updated whenever a new device is activated or an old device is unbound.

[0092] Step 304: Synchronize the device access whitelist to network devices within the home network.

[0093] It's important to note that whitelist synchronization is a crucial step in ensuring that network devices within the home have the latest access policies. As the policy center, the cloud platform must distribute whitelist updates promptly and reliably to all network devices at the home network boundary (such as the main router and Mesh nodes) to achieve end-to-end consistency of authentication policies.

[0094] For example, when a new smart plug is added to a home and activated, the cloud platform will immediately push the updated whitelist to all registered routers in the home; or the routers will periodically query the cloud platform to retrieve the latest whitelist version, thereby ensuring that any router can verify device access based on the latest authorized list.

[0095] The home device connection whitelist generation and management mechanism provided in this embodiment is implemented by a cloud platform based on the operator's home network. The whitelist consists of three parts: gateway information, digital home identity identifier, and device identifier. In principle, one whitelist corresponds to one household. When the gateway or digital home identity identifier changes, a new whitelist needs to be generated, ensuring its uniqueness and authority. Through this mechanism, it is possible to accurately determine whether network devices and smart home devices belong to the same household, and maintain a unified device access whitelist accordingly, thereby achieving automatic and secure reconnection of devices within the home network with high accuracy. This solution is naturally applicable to all scenarios with home broadband networks. It not only leverages the advantages of operator networks to build a reliable technical barrier, but also expands its application ecosystem and commercial value by opening up this capability interface to cooperate with external manufacturers.

[0096] In some embodiments, generating a hardware-level device identity for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity includes: Receive an activation request from the smart home device, the activation request carrying inherent hardware information; Based on the inherent hardware information, the digital home identity identifier, and a random number, the hardware-level device identity identifier is calculated and generated using a preset cryptographic combination algorithm. The generated hardware-level device identity is sent to the smart home device.

[0097] It should be noted that the introduction of the random number enhances the unpredictability and dynamic security of device identifier generation, and the cryptographic combination algorithm ensures the strong collision resistance and tamper resistance of the identifier, thereby guaranteeing the reliability and security of hardware-level device identity identifiers from the algorithm level.

[0098] By employing a cryptographic student generation mechanism that incorporates random numbers, this embodiment ensures the strong uniqueness and anti-counterfeiting properties of hardware-level device identities, effectively solving the security risks of traditional fixed device identifiers (such as MAC and SN) being easily counterfeited and tampered with, and providing a reliable and unforgeable identity foundation for whitelist authentication of home devices.

[0099] In some embodiments, the step of building and maintaining a device access whitelist for the corresponding home network based on the digital home identity includes: in response to generating a hardware-level device identity for a new smart home device, adding the new hardware-level device identity to the device access whitelist of the corresponding home.

[0100] It should be noted that the whitelist maintenance mechanism described in this embodiment is an event-driven, dynamic update method. The cloud platform triggers an immediate update of the whitelist by monitoring the key event of "new device identity generation," thereby ensuring the real-time nature and accuracy of the set of legitimate devices within the home network. Logically, the whitelist is organized around a digital home identity, forming a device authorization list for each household.

[0101] By automatically adding newly generated device hardware-level identity identifiers to the corresponding household's whitelist, this embodiment achieves closed-loop synchronization of device authorization and identity registration processes. This mechanism ensures that the household network whitelist can reflect the composition of all legitimate devices within the household in real time and accurately, avoiding security risks caused by delayed list updates, such as new devices failing to automatically reconnect or old device authorizations not being revoked in time. This improves the success rate of automatic reconnection while ensuring the timeliness and security of household network access control.

[0102] In some embodiments, synchronizing the device access whitelist to network devices within the home network includes one of the following methods: Actively push updated device access whitelists to registered network devices within the home network; Alternatively, it can receive a whitelist retrieval request initiated by a network device and return the current device access whitelist to it.

[0103] It should be noted that the proactive push method is typically triggered immediately by the cloud platform after changes to the whitelist content, aiming to achieve rapid policy deployment and effectiveness. The request-response method, on the other hand, provides network devices with the autonomous ability to retrieve the latest whitelist on demand, enhancing the system's adaptability in scenarios such as network fluctuations or device initialization. The two methods can be selected or used in combination depending on network conditions, device capabilities, and business strategies.

[0104] By supporting both proactive push and request-based retrieval synchronization mechanisms, this embodiment ensures that whitelist updates are distributed to all network devices within the home in a timely and reliable manner, while also giving network devices the flexibility to proactively obtain the latest policies when necessary. This dual-mode design effectively improves the success rate and real-time performance of whitelist synchronization, ensuring that all access control points within the home network can authenticate devices based on a unified and up-to-date authorization list. This provides a solid and consistent policy execution foundation for the automatic and secure reconnection of smart home devices.

[0105] The automatic reconnection authentication method based on hardware-level device identity and home device whitelist provided in this application builds, maintains and distributes the device access whitelist to network devices such as gateways or routers in the home network through a unified cloud platform. This enables network devices to quickly complete access determination and authorization locally based on the whitelist when smart home devices switch network devices, achieving secure and seamless automatic reconnection of devices within the home.

[0106] This solution features the following characteristics: It enables automatic and secure reconnection of connected smart home devices when network devices are replaced or multiple network devices coexist in a home environment. It is applicable to network devices of different brands and series, without relying on specific cabling or same-brand networking, effectively expanding the scope of automatic reconnection. The authentication process is performed locally on the network device, with authentication latency as low as milliseconds, imperceptible to the user. It also features a failure fallback mechanism, allowing reverting to traditional network configuration procedures after authentication failure, with virtually no impact on user experience. Leveraging a cloud platform for unified authentication and management of home network identities, it constructs a trusted device system for the home unit, improving reconnection efficiency while enhancing the overall security of home network access. This solution is software-implemented, requiring no additional hardware devices, and is low-cost.

[0107] Figure 4 This is an interaction topology diagram of the reconnection authentication system provided in the embodiments of this application. For example... Figure 4 As shown, the reconnection authentication method includes the following process: (1) Whitelist generation and update.

[0108] After a smart home device is first connected to the network, it reports its inherent hardware information (such as serial number, MAC address, and chip fingerprint) to the cloud platform via the gateway. Based on this inherent hardware information and the digital home identity identifier corresponding to the household, the cloud platform generates a hardware-level device identity identifier (i.e., a unique device identifier) ​​for the device. Based on this, the cloud platform builds and maintains a device access whitelist for each household; when a new device connects, this whitelist is updated.

[0109] (2) Whitelist synchronization.

[0110] The cloud platform will promptly synchronize the latest device access whitelist to network devices (such as gateways or routers) within the home network, and the network devices will store it locally.

[0111] (3) Reconnect the device.

[0112] When a smart home device needs to switch to another network connection, it sends a reconnection request to the target network device, carrying its hardware-level device identity identifier. The target network device verifies this identifier against a locally stored whitelist (e.g., checking if it's on the list and verifying its corresponding home affiliation information). If the verification passes, the device is allowed to connect and go online; if the verification fails or the device is not on the whitelist, the device needs to re-initiate the network configuration and binding process.

[0113] Figure 5 This is an interactive schematic diagram illustrating the establishment of a local authentication center for a home network, provided in an embodiment of this application. For example... Figure 5 As shown, the network devices include a gateway (initially, a gateway is used as an example), where the gateway integrates an authentication plugin; the cloud platform includes a provincial home security platform and a home security authentication platform.

[0114] After the gateway completes the installation of the authentication plugin issued by the cloud platform or management terminal, it requests registration and authentication from the home security authentication platform. The home security authentication platform initiates a verification with the provincial home security platform based on the gateway device parameters (MAC, SN) and network access information (intermediate variables generated when the home broadband network enters the network, such as password). The verification mainly checks the consistency between the gateway device and the network access information. If the verification fails, the process ends; if successful, the provincial home security platform returns the user's home broadband account (hereinafter referred to as Huserid) and other relevant user network access information (net1, net2) to the authentication platform. After verification, the authentication platform generates a digital home identity identifier (hereinafter referred to as homeid) and returns it in encrypted form to the gateway authentication plugin. After receiving it, the plugin decrypts it and caches it in the gateway.

[0115] The homeid is calculated as follows: homeid = CL(MAC / SN, password, Huserid, net1, net2, random), where random represents a random number (the same applies below), and CL represents a combination of calculation methods such as scatter, digest, and HMAC (the same applies below). -1 This indicates the inverse operation.

[0116] When the negotiation information cached in the gateway becomes invalid, a renegotiation authentication process is initiated.

[0117] The following details the mechanism for generating and updating the device connection whitelist.

[0118] (1) Device hardware-level identity generation mechanism.

[0119] Figure 6 This is an interaction diagram of the device hardware-level identity generation mechanism provided in the embodiments of this application. For example... Figure 6 As shown, the device connection whitelist generation and update mechanism includes: When a device is powered on and activated, it carries factors such as the device chip fingerprint, MAC address, and SN. The gateway adds its cached home network identifier (homeid) and sends an activation request to the cloud platform. The cloud platform generates a hardware-level identity identifier for the device and returns it to the device through the gateway. The device then writes the identifier into its chip.

[0120] ① When the device is powered on, the trusted application (TA) embedded in the chip generates a chip fingerprint. The chip fingerprint (hereinafter referred to as CFP) is generated by a cryptographic algorithm based on the chip ID (SoCId) and the hard random number Radom. CFP=CL(SoCId,Radom); ② The device middleware or client application (CA) sends an activation request to the gateway carrying factors such as chip fingerprint, SN, and MAC. ③ After receiving the request, the gateway attaches its cached digital home identity (homeid) and forwards the hardware-level identity generation request to the cloud platform; ④ After receiving the request, the cloud platform generates a hardware-level identity identifier: DeviceId = CL(homeid, CFP, SN, mac, random); ⑤ The cloud platform returns the device hardware identification identifier (DeviceId) to the gateway; ⑥ The gateway returns the device hardware identity identifier, DeviceId, to the device; ⑦ The device writes the DeviceId hardware identifier into the chip.

[0121] (2) Whitelist generation and update mechanism.

[0122] Figure 7This is a flowchart illustrating the whitelist generation and update mechanism provided in this application's embodiments. For example... Figure 7 As shown, after a new device is activated and goes online or a device goes offline, the cloud platform generates or updates the device access whitelist {gateway, digital home identity, [deviceId]} based on the gateway information (mac / SN), digital home identity (h), and device information.

[0123] For proprietary network devices, after the whitelist is generated or updated, it is distributed to the network devices (gateways or routers) by the cloud platform and stored locally. When the local whitelist expires, it retrieves it from the cloud platform. Network devices can also periodically request the whitelist from the cloud platform. For third-party network devices, the whitelist can be retrieved from the gateway according to the interface specifications.

[0124] The following details the process of reconnecting and bringing the device back online.

[0125] Network devices, using routers as an example: (1) Device triggers reconnection Assume the device was originally connected to router A: Router replacement scenario: When router A malfunctions (including damage or weak signal), and router B is replaced, the device needs to switch to router B for connection. Router switching scenario: When a device changes its physical location and goes beyond the WiFi coverage area of ​​router A or the signal strength is weak, the device must automatically switch to router B or C to maintain a good network experience.

[0126] (2) Whitelist verification The device's client application (CA) sends a reconnection authentication request to the target router (B or C) carrying its DeviceId. Upon receiving the request, the target router performs local verification: a. Check if the DeviceId exists in the local whitelist of device identifiers. If it exists, proceed with further verification; if it does not exist, verification fails and access is denied.

[0127] b. Parse or verify the corresponding digital home identity identifier (denoted as homeid') from DeviceId, and compare homeid' with the homeid recorded in the whitelist. If they do not match, terminate; if they match, continue.

[0128] c. Parse or verify the corresponding gateway device information (MAC address / SN) from the homeid, and compare the MAC address / SN with the gateway MAC / SN recorded in the whitelist. If they do not match, the process terminates; if they match, the verification passes.

[0129] (3) Equipment reconnection After successful verification, the device is allowed to connect regardless of whether the routers are from the same brand or series. The router provides the device with its current working WiFi configuration information. Once the device obtains this information, it can automatically connect to the network and initiate an online request to its service platform, thereby restoring the functionality of the controlled device.

[0130] This solution generates and manages device identities and home whitelists based on dual binding of hardware and home network through a cloud platform, and synchronizes them to network devices within the home. This enables smart home devices to automatically reconnect seamlessly through fast and secure local verification when replacing or switching network devices. Thus, in cross-brand, no-wired home scenarios, it balances user experience, access security, and system reliability.

[0131] The reconnection authentication device provided in the embodiments of this application is described below. The reconnection authentication device described below can be referred to in correspondence with the reconnection authentication method described above.

[0132] Figure 8 This is one of the structural schematic diagrams of the reconnection authentication device provided in the embodiments of this application. For example... Figure 8 As shown, the reconnection authentication device 400 is applied to smart home devices and includes: The request sending module 410 is used to send a reconnection request to the second network device when it is necessary to switch from the first network device to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. The response receiving module 420 is configured to receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access the network. The first processing module 430 is configured to establish a connection with the second network device based on network configuration information received from the second network device if the response indicates that access is permitted.

[0133] In some embodiments, the inherent hardware information includes at least one of the following: chip fingerprint, device serial number, and device media access control (MAC) address; wherein the chip fingerprint is generated by a trusted application within the smart home device chip based on a unique chip identifier and a hard random number.

[0134] In some embodiments, the apparatus further includes: The device monitoring module is used to monitor the current connection status with the first network device; when the connection signal strength is detected to be lower than a preset threshold, or when the signal strength provided by the second network device is detected to be greater than the connection signal strength preset second threshold, it is determined that it is necessary to switch to the second network device.

[0135] In some embodiments, the apparatus further includes: An identity acquisition module is used to send an activation request to a cloud platform when the smart home device first accesses the home network, the activation request carrying the inherent hardware information; receive the hardware-level device identity identifier generated by the cloud platform; wherein the hardware-level device identity identifier is calculated by the cloud platform based at least on the inherent hardware information and the digital home identity identifier; and store the hardware-level device identity identifier in the chip of the smart home device.

[0136] In some embodiments, the apparatus further includes: The second processing module is used to enter the network configuration standby mode if the response indicates that access is not allowed.

[0137] Figure 9 This is a second schematic diagram of the reconnection authentication device provided in the embodiments of this application. For example... Figure 9 As shown, the reconnection authentication device 500 is applied to network equipment and includes: The request receiving module 510 is used to receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device. The identity verification module 520 is used to verify the identity of the hardware-level device based on the device access whitelist stored locally; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; The first sending module 530 is used to send an access permission response to the smart home device and provide network configuration information if the verification passes, so that the smart home device can establish a connection.

[0138] In some embodiments, the identity verification module 520 includes: The first determination unit is used to determine whether the hardware-level device identity identifier exists in the device identifier list of the device access whitelist; The second judgment unit is used to perform an inverse operation on the hardware-level device identity identifier if it exists, to obtain the first digital family identity identifier. The third judgment unit is used to verify whether the first digital family identity identifier is consistent with the digital family identity identifier recorded in the whitelist; The fourth judgment unit is used to verify if the results match.

[0139] In some embodiments, the apparatus further includes: The registration sending module is used to send a registration request to the cloud platform, the registration request carrying the device information of the network device and the home network access information; and to receive the digital home identity identifier issued by the cloud platform.

[0140] In some embodiments, the device further includes a whitelist acquisition module, configured to acquire and store a device access whitelist locally via one of the following methods: The cloud platform actively pushes the message. Alternatively, a whitelist acquisition request can be initiated to the cloud platform, and the device access whitelist returned by the cloud platform can be received.

[0141] In some embodiments, the apparatus further includes a second sending module for sending an access denial response to the smart home device if the verification fails.

[0142] Figure 10 This is the third structural schematic diagram of the reconnection authentication device provided in the embodiments of this application. For example... Figure 10 As shown, the reconnection authentication device 600 is applied to network equipment and includes: The first identification module 610 is used to generate and maintain a digital home identity identifier for the home network based on the gateway device information and user network access information of the home network. The second identification module 620 is used to generate a hardware-level device identity identifier for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity identifier. The list generation module 630 is used to build and maintain a device access whitelist for the corresponding home network based on the digital home identity identifier. The device access whitelist includes the digital home identity identifier and at least one hardware-level device identity identifier that has been generated. The list sending module 640 is used to synchronize the device access whitelist to network devices within the home network.

[0143] In some embodiments, the second identification module 620 includes: A request receiving unit is configured to receive an activation request from the smart home device, the activation request carrying inherent hardware information. The identifier generation unit is used to calculate and generate the hardware-level device identifier based on the inherent hardware information, the digital home identifier, and a random number using a preset cryptographic combination algorithm. The identifier sending unit is used to send the generated hardware-level device identity identifier to the smart home device.

[0144] In some embodiments, the list generation module 630 includes: In response to generating a hardware-level device identity for a new smart home device, the new hardware-level device identity is added to the device access whitelist of the corresponding household.

[0145] In some embodiments, the list sending module 640 is specifically configured to synchronize the device access whitelist to network devices within the home network through one of the following methods: Actively push updated device access whitelists to registered network devices within the home network; Alternatively, it can receive a whitelist retrieval request initiated by a network device and return the current device access whitelist to it.

[0146] Figure 11 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application. For example... Figure 11 As shown, the electronic device 700 may include: a processor 710, a communication interface 720, a memory 730, and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 communicate with each other via the communication bus 740. The processor 710 may call a computer program in the memory 730 to execute the steps of the reconnection authentication method, such as including: When it is necessary to switch from the first network device to the second network device, a reconnection request is sent to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. Receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access; If the response indicates that access is permitted, then a connection is established with the second network device based on the network configuration information received from the second network device; or, Receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device; The hardware-level device identity is verified based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; If the verification passes, a response allowing access is sent to the smart home device, along with network configuration information, to enable the smart home device to establish a connection; or, Based on the gateway device information and user network access information of the home network, generate and maintain a digital home identity for the home network; Based on the inherent hardware information reported by the smart home device and the digital home identity identifier, a hardware-level device identity identifier is generated for the smart home device. Based on the digital home identity, a device access whitelist is built and maintained for the corresponding home network. The device access whitelist includes the digital home identity and at least one hardware-level device identity that has been generated. The device is connected to the whitelist and synchronized to network devices within the home network.

[0147] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0148] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the reconnection authentication method provided in the above embodiments, such as including: When it is necessary to switch from the first network device to the second network device, a reconnection request is sent to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. Receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access; If the response indicates that access is permitted, then a connection is established with the second network device based on the network configuration information received from the second network device; or, Receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device; The hardware-level device identity is verified based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; If the verification passes, a response allowing access is sent to the smart home device, along with network configuration information, to enable the smart home device to establish a connection; or, Based on the gateway device information and user network access information of the home network, generate and maintain a digital home identity for the home network; Based on the inherent hardware information reported by the smart home device and the digital home identity identifier, a hardware-level device identity identifier is generated for the smart home device. Based on the digital home identity, a device access whitelist is built and maintained for the corresponding home network. The device access whitelist includes the digital home identity and at least one hardware-level device identity that has been generated. The device is connected to the whitelist and synchronized to network devices within the home network.

[0149] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to execute the steps of the reconnection authentication method provided in the above embodiments, such as including: When it is necessary to switch from the first network device to the second network device, a reconnection request is sent to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. Receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access; If the response indicates that access is permitted, then a connection is established with the second network device based on the network configuration information received from the second network device; or, Receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device; The hardware-level device identity is verified based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; If the verification passes, a response allowing access is sent to the smart home device, along with network configuration information, to enable the smart home device to establish a connection; or, Based on the gateway device information and user network access information of the home network, generate and maintain a digital home identity for the home network; Based on the inherent hardware information reported by the smart home device and the digital home identity identifier, a hardware-level device identity identifier is generated for the smart home device. Based on the digital home identity, a device access whitelist is built and maintained for the corresponding home network. The device access whitelist includes the digital home identity and at least one hardware-level device identity that has been generated. The device is connected to the whitelist and synchronized to network devices within the home network.

[0150] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0151] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0152] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the reconnection authentication method described in various embodiments or some parts of embodiments.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A reconnection authentication method, characterized in that, Applied to smart home devices, including: When it is necessary to switch from the first network device to the second network device, a reconnection request is sent to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. Receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access; If the response indicates that access is permitted, a connection is established with the second network device based on the network configuration information received from the second network device.

2. The reconnection authentication method according to claim 1, characterized in that, The inherent hardware information includes at least one of the following: chip fingerprint, device serial number, and device media access control (MAC) address; wherein the chip fingerprint is generated by a trusted application within the smart home device chip, based on the chip's unique identifier and a hard random number.

3. The reconnection authentication method according to claim 1 or 2, characterized in that, Before sending a reconnection request to the second network device when a switch from the first network device to the second network device is required, the method further includes: Monitor the current connection status with the first network device; If the connection signal strength is detected to be lower than a preset threshold, or if the signal strength provided by the second network device is detected to be greater than the preset second threshold of the connection signal strength, it is determined that a switch to the second network device is required.

4. The reconnection authentication method according to claim 1 or 2, characterized in that, The hardware-level device identity is obtained through the following process: When the smart home device first connects to the home network, it sends an activation request to the cloud platform, and the activation request carries the inherent information of the hardware. Receive the hardware-level device identity identifier generated by the cloud platform; wherein the hardware-level device identity identifier is calculated by the cloud platform based at least on the inherent information of the hardware and the digital home identity identifier; The hardware-level device identity is stored in the chip of the smart home device.

5. The reconnection authentication method according to claim 1 or 2, characterized in that, The method further includes: If the response indicates that access is not allowed, then the system enters the network configuration standby mode.

6. A reconnection authentication method, characterized in that, Application network devices, including: Receive a reconnection request sent by a smart home device, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device; The hardware-level device identity is verified based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; If the verification passes, a response allowing access is sent to the smart home device, along with network configuration information, to enable the smart home device to establish a connection.

7. The reconnection authentication method according to claim 6, characterized in that, The step of verifying the identity of the hardware-level device based on the locally stored device access whitelist includes: Determine whether the hardware-level device identity exists in the device identity list of the device access whitelist; If it exists, then the hardware-level device identity identifier is inversely operated to obtain the first digital family identity identifier; Verify whether the first digital family identity identifier is consistent with the digital family identity identifier recorded in the whitelist; If they match, the verification passes.

8. The reconnection authentication method according to claim 6, characterized in that, Before receiving the reconnection request sent by the smart home device, the method further includes: Send a registration request to the cloud platform, the registration request carrying the device information of the network device and the home network access information; Receive the digital home identity identifier issued by the cloud platform.

9. The reconnection authentication method according to claim 6, characterized in that, The device access whitelist is obtained and stored locally through one of the following methods: The cloud platform actively pushes the message. Alternatively, a whitelist acquisition request can be initiated to the cloud platform, and the device access whitelist returned by the cloud platform can be received.

10. The reconnection authentication method according to any one of claims 6 to 9, characterized in that, If the verification fails, a response denying access is sent to the smart home device.

11. A reconnection authentication method, characterized in that, Applied to cloud platforms, including: Based on the gateway device information and user network access information of the home network, generate and maintain a digital home identity for the home network; Based on the inherent hardware information reported by the smart home device and the digital home identity identifier, a hardware-level device identity identifier is generated for the smart home device. Based on the digital home identity, a device access whitelist is built and maintained for the corresponding home network. The device access whitelist includes the digital home identity and at least one hardware-level device identity that has been generated. The device is connected to the whitelist and synchronized to network devices within the home network.

12. The reconnection authentication method according to claim 11, characterized in that, The step of generating a hardware-level device identity for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity includes: Receive an activation request from the smart home device, the activation request carrying inherent hardware information; Based on the inherent hardware information, the digital home identity identifier, and a random number, the hardware-level device identity identifier is calculated and generated using a preset cryptographic combination algorithm. The generated hardware-level device identity is sent to the smart home device.

13. The reconnection authentication method according to claim 11, characterized in that, The step of building and maintaining a device access whitelist for the corresponding home network based on the digital home identity includes: In response to generating a hardware-level device identity for a new smart home device, the new hardware-level device identity is added to the device access whitelist of the corresponding household.

14. The reconnection authentication method according to claim 11, characterized in that, The step of synchronizing the device access whitelist to network devices within the home network includes one of the following methods: Actively push updated device access whitelists to registered network devices within the home network; Alternatively, it can receive a whitelist retrieval request initiated by a network device and return the current device access whitelist to it.

15. A reconnection authentication device, characterized in that, Applied to smart home devices, including: The request sending module is used to send a reconnection request to the second network device when it is necessary to switch from the first network device to the second network device. The reconnection request carries the hardware-level device identity of the smart home device. The hardware-level device identity is generated based on the inherent hardware information of the smart home device and the digital home identity of the home network to which the first network device belongs. A response receiving module is configured to receive a response from the second network device; wherein the response is used to indicate whether the second network device allows the smart home device to access the network. The first processing module is configured to establish a connection with the second network device based on network configuration information received from the second network device if the response indicates that access is permitted.

16. A reconnection authentication device, characterized in that, Applied to network devices, including: The request receiving module is used to receive reconnection requests sent by smart home devices, wherein the reconnection request carries the hardware-level device identity identifier of the smart home device. The identity verification module is used to verify the identity of the hardware-level device based on the locally stored device access whitelist; wherein, the device access whitelist is generated and synchronized by the cloud platform based on the digital home identity of the home network to which the network device belongs; The response sending module is used to send an access permission response to the smart home device and provide network configuration information if the verification passes, so that the smart home device can establish a connection.

17. A reconnection authentication device, characterized in that, Applied to cloud platforms, including: The first identification module is used to generate and maintain a digital home identity identifier for the home network based on the gateway device information and user network access information of the home network. The second identification module is used to generate a hardware-level device identification for the smart home device based on the inherent hardware information reported by the smart home device and the digital home identity identifier. The list generation module is used to build and maintain a device access whitelist for the corresponding home network based on the digital home identity identifier. The device access whitelist includes the digital home identity identifier and at least one hardware-level device identity identifier that has been generated. The list sending module is used to synchronize the device access whitelist to network devices within the home network.

18. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the reconnection authentication method according to any one of claims 1 to 5, or the steps of the reconnection authentication method according to any one of claims 6 to 10, or the steps of the reconnection authentication method according to any one of claims 11 to 14.

19. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the reconnection authentication method as described in any one of claims 1 to 5, or the steps of the reconnection authentication method as described in any one of claims 5 to 10, or the steps of the reconnection authentication method as described in any one of claims 11 to 14.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the reconnection authentication method according to any one of claims 1 to 5, or the steps of the reconnection authentication method according to any one of claims 6 to 10, or the steps of the reconnection authentication method according to any one of claims 11 to 14.

Images