Device control method, verification information generation method, device, apparatus, and medium

Abstract

The application discloses a device control method, a verification information generation method, a device and a medium, and belongs to the technical field of device control. The method comprises the following steps: in response to a received unlocking request for a smart door lock, obtaining first verification information for temporary password verification and second verification information for public password verification stored in the smart door lock according to the unlocking request, wherein the unlocking request contains a data packet of a user identifier and a first temporary password; verifying the first temporary password according to the user identifier and the first verification information; when the temporary password verification is successful, verifying a public password according to the second verification information; and when the public password verification is successful, controlling the smart door lock to start unlocking. Through the embodiments of the application, dynamic temporary password verification and static public password verification are realized, so that the extreme usability of the door lock in extreme scenarios such as no network and weak network is ensured, and the door lock can independently complete high-security-level unlocking authentication in an offline state.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically relating to a device control method and a verification information generation method, apparatus, electronic device and storage medium. Background Technology

[0002] Existing smart lock systems primarily employ two technical approaches: one is fully online authentication, where unlocking commands must be verified by a cloud server before being issued. This method is completely unavailable during network outages or server failures, resulting in a poor user experience. The other is fully offline authentication, where the lock independently completes all verifications. While this ensures availability, it presents security risks such as delayed security policy updates, difficulty in revoking permissions, and uncontrollable global state. For example, when it is necessary to urgently revoke a user's permissions or update the security policy of the entire system, a fully offline lock cannot respond in time, leading to security vulnerabilities in the system. Summary of the Invention

[0003] The purpose of this application is to provide a device control method and a verification information generation method, which can solve the current problems in smart lock verification.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a device control method, the method comprising: In response to a received unlocking request for a smart door lock, the system obtains first verification information for temporary password verification and second verification information for public password verification stored in the smart door lock according to the unlocking request. The unlocking request includes a data packet containing a user identifier and a first temporary password. The first temporary password is verified based on the user identifier and the first verification information; When the temporary password is successfully verified, the public password is verified based on the second verification information; When the public password is successfully verified, the smart door lock is controlled to start unlocking.

[0005] Optionally, verifying the first temporary password based on the user identifier and the first verification information includes: The preset calculation key and dynamic password generation algorithm corresponding to the user identifier are determined in the first verification information; A second temporary password is generated based on the preset calculation key and the dynamic password; Determine whether the first temporary password and the second temporary password match to perform temporary password verification.

[0006] Optionally, the second verification information is a public password carrying a password state, and verifying the public password based on the second verification information includes: The password status is obtained from the flag bit of the second verification information; The public password is verified based on the password status.

[0007] Optionally, it also includes: When the smart lock is connected to the application used to control the smart lock, in response to the received synchronization request, the application sends a preset calculation key and a user identifier, which are data generated by the cloud to which the application is connected and sent to the application. The preset calculation key and the user identifier are bound together to obtain the first verification information.

[0008] Optionally, it also includes: Obtain the version number and / or security event log of the public password; The version number and / or the security event log are uploaded to the cloud through a pre-built transmission channel between the smart lock and the cloud, so that the cloud can generate a new public password when it determines that the smart lock is in a lagging state or has abnormal behavior. The new public password is received through a pre-built transmission channel between the smart lock and the cloud.

[0009] Secondly, embodiments of this application provide a method for generating verification information for a smart door lock, the method comprising: In response to a preset trigger event, a pre-calculated key and a public password corresponding to the user identifier of the smart lock are generated; The preset calculation key and the user identifier are sent to the smart lock through an application used to control the smart lock, so as to generate first verification information in the smart lock for temporary password verification.

[0010] The public key is sent to the smart lock via a pre-built transmission channel between the smart lock and the cloud, so as to generate second verification information in the smart lock for public password verification.

[0011] Optionally, the step of generating a preset calculated key and a public password corresponding to the user identifier of the smart lock in response to a preset trigger event includes: In response to a first triggering event for triggering the generation of a computing key, a user identifier corresponding to the first triggering event is obtained, and a preset computing key corresponding to the user identifier is generated; In response to a second triggering event used to trigger the generation of a public key, a random number is obtained and a public key is generated based on the random number.

[0012] Optionally, generating the preset calculation key corresponding to the user identifier includes: Determine the key generation method corresponding to the user identifier; Generate the first computing key according to the key generation method described above; The first auxiliary parameter is determined according to the key generation method; The first calculation key and the auxiliary parameters are encapsulated to obtain a preset calculation key.

[0013] Optionally, obtaining a random number and generating a public password based on the random number includes: Call the random number generator to generate random numbers; Determine the second auxiliary parameter corresponding to the random number; The random number and the second auxiliary parameter are encapsulated to obtain the public password.

[0014] Thirdly, embodiments of this application provide a device control apparatus, which includes: The verification information acquisition module is used to respond to a received unlocking request for the smart door lock, and acquire, according to the unlocking request, first verification information for temporary password verification and second verification information for public password verification stored in the smart door lock, wherein the unlocking request includes a data packet containing a user identifier and a first temporary password; A temporary password verification module is used to verify the first temporary password based on the user identifier and the first verification information; A public password verification module is used to verify the public password based on the second verification information when the temporary password is successfully verified. The door lock control module is used to control the smart door lock to start unlocking when the public password is successfully verified.

[0015] Fourthly, embodiments of this application provide a device for generating verification information for a smart door lock, the device comprising: The initial information generation module is used to generate a pre-calculated key and a public password corresponding to the user identifier of the smart lock in response to a preset trigger event. The first verification information generation module is used to send the preset calculation key and the user identifier to the smart lock through an application for controlling the smart lock, so as to generate first verification information in the smart lock for temporary password verification.

[0016] The second verification information generation module is used to send the public key to the smart lock through a transmission channel pre-built between the smart lock and the cloud, so as to generate second verification information in the smart lock for public password verification.

[0017] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0018] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0019] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0020] In this embodiment, the smart lock stores first verification information and second verification information. When the smart lock is offline, it can perform dynamic temporary password verification and static public password verification, thereby ensuring the ultimate availability of the lock in extreme scenarios such as no network or weak network, and enabling the lock to independently complete high-security unlocking authentication in offline state.

[0021] In this embodiment, the computing key and public password are generated and distributed to the smart lock in the cloud, maintaining a security level consistent with the global policy. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a device control method according to an embodiment of this application; Figure 2 This is a flowchart illustrating another device control method in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a device control device according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a device control device according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] The control of the smart door lock provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0026] like Figure 1 The diagram illustrates a flowchart of a device control method according to an embodiment of this application, which may specifically include the following steps: Step S101: In response to the received unlocking request for the smart lock, obtain the first verification information for temporary password verification and the second verification information for public password verification stored in the smart lock according to the unlocking request. The unlocking request includes a data packet of user identifier and first temporary password. Smart locks can be controlled both online and offline. This application primarily focuses on smart lock control in completely offline or poor network conditions. The smart lock may contain first verification information and second verification information. The first verification information is used for dynamic temporary password verification, and the second verification information is used for static public password verification.

[0027] Users can initiate an unlocking request for the smart lock, which includes a data packet that identifies the user and matches the first temporary password.

[0028] Upon receiving an unlocking request, the smart lock triggers a security verification process, which includes temporary password verification and public password verification. To achieve two-stage verification, the smart lock can retrieve the first and second verification information corresponding to the unlocking request locally after receiving the unlocking request.

[0029] Step S102: Verify the first temporary password based on the user identifier and the first verification information; In smart locks, the first temporary password can be dynamically verified based on the user identifier and the first verification information.

[0030] Step S103: When the temporary password is successfully verified, the public password is verified according to the second verification information; If the temporary password verification is successful, the public password verification can proceed, which involves verifying the public password based on the second verification information. If the temporary password verification fails, a verification failure message will be generated.

[0031] Step S104: When the public password is successfully verified, control the smart door lock to start unlocking.

[0032] If the public password verification is successful, the smart door lock can be controlled to start unlocking. If the public password verification fails, a verification failure prompt message will be generated.

[0033] In this embodiment, the temporary password verification and public password verification of the smart lock are performed using AND logic. When both verifications pass, the smart lock is unlocked.

[0034] In one embodiment of this application, verifying the first temporary password based on the user identifier and the first verification information includes: determining a preset calculation key and a dynamic password generation algorithm corresponding to the user identifier in the first verification information; generating a second temporary password based on the preset calculation key and the dynamic password; and determining whether the first temporary password and the second temporary password match to perform temporary password verification.

[0035] In this embodiment, the first verification information may include a preset computation key and a dynamic password generation algorithm corresponding to the user identifier. After determining the user identifier, the preset computation key and dynamic password generation algorithm can be determined based on the user identifier. These two algorithms then jointly generate a second temporary password. The first temporary password and the second temporary password are then matched to verify the temporary password. If the first and second temporary passwords match, the temporary password verification is successful. If they do not match, the temporary password verification fails.

[0036] In one embodiment of this application, the second verification information is a public password carrying a password status. Verifying the public password based on the second verification information includes: obtaining the password status from the flag bit of the second verification information; and verifying the public password based on the password status.

[0037] The second verification information is a public password carrying a password status, which indicates the effective status of the public password. When the password status of the public password is effective, the public password verification passes; otherwise, if there is no password status or the password status is ineffective, the public password verification fails.

[0038] In one embodiment of this application, the smart lock is pre-configured with its unique asymmetric key pair, device certificate and server public key when it leaves the factory. When the smart lock is connected to the network for the first time, it completes two-way identity authentication with the cloud server through a two-way TLS (Transport Layer Security) / DTLS (Datagram Transport Layer Security) handshake, and establishes an end-to-end encrypted secure channel.

[0039] Based on the establishment of a secure channel between the cloud and the smart lock, the cloud server and the smart lock can perform key distribution and synchronization to achieve initial collaboration: the cloud server can generate a public password representing the system policy and a user computing key representing user permissions; then, it is distributed through a channel separation mode, such as directly sending the highly secure public password to the smart lock via the NB-IoT (Narrowband Internet of Things) network and storing it in the smart lock, while the user computing key is distributed to the user's mobile APP (application) via a secure link, and then synchronized to the lock via the Bluetooth "convenient channel". This establishes the basic mode of core policy being sent through a secure dedicated line and user credentials being synchronized through the convenient channel.

[0040] Furthermore, when a user initiates a request, the smart lock can enter a completely offline verification mode, independently performing the first verification information verification (i.e., finding the corresponding pre-set calculated key based on the user identifier, generating a second temporary password by running the TOTP / HOTP algorithm locally on the smart lock, and then comparing the second temporary password with the first temporary password provided in the user request) and the second verification information verification (checking the local "security context" status flag to confirm that it follows the latest security policy, where the security context consists of the public password and the password status of the public password), and finally independently deciding whether to unlock based on the result of the logical "AND". The entire process requires no network interaction.

[0041] The specific offline verification process is as follows: When a user initiates an unlocking request via a mobile app, the app sends an unlocking request data packet to the lock via Bluetooth. This data packet contains more than just a temporary password; it's a structured message. It includes not only a temporary password dynamically generated by the user terminal based on a pre-set calculated key and the current time (or counter), but also at least a user identifier and an optional data signature. The user identifier uniquely identifies the authorized user initiating the request, which is crucial for lock systems supporting multi-user management, allowing the smart lock to index the pre-set calculated key associated with that user in its local database. The data signature ensures the request data is not tampered with during Bluetooth transmission.

[0042] Upon receiving a request, the smart lock immediately initiates a rigorous and orderly two-factor authentication sequence.

[0043] The first layer of verification involves checking the dynamic temporary password. The door lock first parses the user identifier from the data packet and then searches for the corresponding pre-calculated key in its secure storage area. If the search fails, the verification process terminates immediately, and the unlocking request is rejected. If the calculation key is successfully obtained, the door lock calls a dynamic password generation algorithm identical to that of the user terminal to independently calculate a reference temporary password locally. This algorithm is typically a time-based or event-based one-time password algorithm. In the time-based scheme, the door lock relies on its internally maintained reliable clock source for calculation and sets a reasonable time tolerance window to handle minor clock drift. The reliable clock source is ensured by the door lock calibrating its local clock using the high-precision timestamp in the server message each time it communicates with the server in NB-IoT (such as when distributing a public password), thus keeping time drift within the tolerance window. In the event-based scheme, the door lock uses a local counter value synchronized with the user terminal. Subsequently, the door lock precisely compares the locally calculated reference temporary password with the temporary password parsed from the Bluetooth data packet. The consistency between the two constitutes the verification condition for the first factor, which proves that the requester holds the correct computation key synchronized with the door lock.

[0044] After the dynamic temporary password verification is successful, the verification process enters the second, more crucial stage: verification of the static public password. The purpose of this step is to confirm that the unlocking request is within the currently valid security period set by the server via the NB-IoT channel. The public password acts as a server-controlled, infrequently updated "security context." Public password verification is not initiated by the mobile app, but rather determined by the lock's own state. After receiving a new public password from the server via NB-IoT, the lock internally sets a flag to "new public password enabled." This flag, along with the public password itself, constitutes the "security context." When the lock processes any unlocking request, it checks the validity of this security context. For example, the public password status check is considered successful only if the temporary password verification in an unlocking request is successful and the lock is currently in the "new public password enabled" state. If the server issues a new public password but the lock fails to receive it for some reason, it will remain in the old security context, allowing the server to determine that the lock's state is abnormal.

[0045] Only when both verification steps—the comparison of the dynamic temporary password and the status check of the static public password—are successfully completed will the lock's main control chip determine the unlocking request as legitimate and trigger the drive circuit to execute the mechanical unlocking action. Conversely, if either step fails, the lock will not only refuse to unlock but also record a security event log locally containing a timestamp, user identifier, and failure type. These logs will be automatically reported the next time the lock establishes an NB-IoT connection with the server, providing valuable security audit clues for the system backend. Furthermore, multiple consecutive verification failures may trigger the lock's temporary locking mechanism to prevent brute-force attacks.

[0046] In one embodiment of this application, the method further includes: when the smart lock is connected to an application for controlling the smart lock, in response to a received synchronization request, receiving a preset calculation key and a user identifier sent by the application, wherein the preset calculation key and the user identifier are data generated by the cloud to which the application is connected and sent to the application; binding the preset calculation key and the user identifier to obtain first verification information.

[0047] In practical applications, smart locks can connect to an application, which in turn connects to the cloud. This allows for data synchronization between the smart lock, the cloud, and the application. Specifically, the cloud generates a pre-set computation key and a public password. The pre-set computation key is then sent from the application or via a direct pre-set channel to the smart lock, thus establishing the first and second verification messages at the smart lock.

[0048] In practical applications, the process of generating a pre-configured computing key in the cloud is as follows: The generation of user computation keys can be triggered in the following scenarios: initial user registration and authorization for unlocking, administrators granting temporary unlocking permissions to new visitors or temporary tenants, or the need to change the key for a user due to security reasons such as the loss of the original mobile phone. The cloud server first verifies the target user's identity information and logically binds the newly generated computation key to the user's unique user identifier. Regarding the specific key generation method, the cloud server can choose one of two approaches based on the security policy: one is to directly call a cryptographically secure random number generator to generate a completely random number of sufficient length to resist brute-force attacks as the computation key; the other is for the server to hold a global master key and use a key derivation function combined with the user identifier and a random salt value to derive the user computation key. This method facilitates batch management by the server and eliminates the need to store the plaintext of each user's computation key. Depending on the selected dynamic cryptography algorithm type, the server also needs to determine or generate auxiliary parameters, including an algorithm type identifier specifying whether TOTP or HOTP is used, the time step for TOTP, the initial counter value for HOTP, and the password length, and encapsulate these parameters together with the computation key. Finally, the server uses its own private key to digitally sign the encapsulated data structure, then stores the calculated key in the database, associates it with the user identifier, target door lock device ID, key validity period, and key status (valid, expired, revoked), and completes the entire generation process.

[0049] The specific steps for generating a user computation key through key derivation are as follows: When generating a user computation key using a key derivation function, the server first needs to obtain three core input parameters: First, a global master key stored in the hardware security module, which is a high-strength root key, typically 256 bits or longer, and is never leaked; second, a unique identifier bound to the target user, such as a user account ID or mobile phone number, serving as a distinguishing factor in the derivation process; and third, a completely new, unpredictable random salt value generated for the new user, typically 128 bits long, used to resist pre-computation attacks such as rainbow tables. The server then passes these three parameters into a standardized key derivation function, with common algorithms including HKDF, PBKDF2, or Argon2. Taking HKDF as an example, this function goes through two stages: first, using the master key and salt value to extract a fixed-length pseudo-random key; then, using this pseudo-random key combined with the user identifier to expand the required length (typically 128 or 256 bits) of the user computation key. The entire derivation process is deterministic, meaning that the same input parameters will always produce the same output result. After the function execution is complete, the server needs to perform a security check on the derived result, including confirming that it is not all zeros and does not belong to a known weak key set. If the check fails, the salt value needs to be regenerated and the process repeated. After the derivation is complete, the server does not need to store the user's computation key itself, because the key can be re-derived using the master key and user identifier when needed. However, the server must store the random salt value used during derivation and associate it with the user identifier, while also recording metadata such as the key's validity period and derivation algorithm identifier. When the user's computation key needs to be distributed to a mobile app, the server typically directly distributes the derived key in plaintext, protected by HTTPS and subsequent Bluetooth encryption channels, thus achieving convenient distribution while ensuring security.

[0050] In one embodiment of this application, the process of determining or generating auxiliary parameters based on the dynamic cryptography algorithm type is as follows: Depending on the selected dynamic cryptography algorithm, the server needs to determine or generate a series of auxiliary parameters to ensure that the door lock can perform offline verification according to the algorithm configuration completely consistent with the user terminal. First, the server determines whether the algorithm type is TOTP or HOTP, which depends on the door lock's clock reliability, user usage frequency, and security policy requirements, and writes the corresponding algorithm type identifier into the generated data structure.

[0051] If the TOTP algorithm is selected, the server needs to determine the time step, which is commonly 30 seconds, 60 seconds or 90 seconds. This value is determined by the security level and the degree of door lock clock drift. At the same time, a time tolerance window also needs to be determined, such as allowing passwords within one step before and after the current time to be considered valid, in order to deal with minor clock asynchrony issues. The size of this window is set according to the frequency at which the door lock calibrates its clock via NB-IoT.

[0052] If the HOTP algorithm is chosen, the server needs to determine the initial counter value, which is usually set to 0, a specified value, or a random value, as the starting point for the user's password generation logic. At the same time, it also needs to determine the counter synchronization window, for example, allowing the door lock to look forward 100 times during verification, in order to solve the problem of the counter losing synchronization due to multiple accidental touches by the user. In addition, the server also needs to clarify the counter update strategy, agreeing on how the counters of both parties will increment or be calibrated and aligned after successful verification.

[0053] Regardless of the algorithm used, the cloud server needs to determine several common parameters, including the output length of the dynamic password, typically 6 or 8 bits, determined by both security level and user experience; and the underlying HMAC hash algorithm, such as SHA-1, SHA-256, or SHA-512, selected based on the overall system security requirements. Once all these auxiliary parameters are determined, they are encapsulated and signed along with the user's calculated key, and synchronized to the door lock via the mobile app's Bluetooth channel. This allows the door lock to configure its own verification engine accordingly, ensuring complete consistency between its algorithm execution details and those of the server and user terminal.

[0054] In practical applications, the process of generating a public password in the cloud is as follows: The generation of a public password begins with the server determining trigger conditions. These conditions include the expiration of a preset time period, the revocation of user privileges, the detection of a potential security threat, or a manual update initiated by an administrator. Once triggered, the server invokes its hardware security module or cryptographically secure random number generator to generate a high-strength random number, typically 128 or 256 bits long, as the raw material for the new public password. The server then formats and encapsulates this random number, attaching a series of key metadata, including a strictly monotonically increasing version number to identify the order of old and new, an effective timestamp indicating the expected effective time, an expiration timestamp indicating the expiration time, and a digital signature generated using the server's private key for all the above fields to ensure its authenticity and integrity. After encapsulation, the server stores the newly generated public password in a database and associates it with the target lock device ID or device group ID, while recording the distribution status (e.g., pending distribution, distributed, confirmed), providing data for subsequent auditing and retry mechanisms.

[0055] In one embodiment of this application, the method further includes: obtaining the version number and / or security event log of the public password; uploading the version number and / or the security event log to the cloud through a pre-built transmission channel between the smart lock and the cloud, so that the cloud generates a new public password when it determines that the smart lock is in a lagging state or has abnormal behavior; and receiving the new public password through the pre-built transmission channel between the smart lock and the cloud.

[0056] In this embodiment, to achieve global security, the system is supplemented with powerful online management functions for monitoring and repair: the server performs status auditing and lag detection through the version number and logs reported by the door lock via NB-IoT connection; once a policy lag or security threat is detected, it proactively issues a new public password through the NB-IoT channel to force an update, or automatically repairs lagging door locks, or even remotely freezes high-risk door locks, thus forming a complete closed-loop security lifecycle from policy creation, secure issuance, offline use, status auditing to triggering updates and revoking permissions, ensuring that the entire system achieves eventual consistency. The specific process is as follows: The door lock utilizes every connection opportunity established via the NB-IoT "management line" (whether for periodic heartbeats, security event log reporting, or receiving commands) to upload its internally held public password version number and key operation logs to the cloud server. By comparing the reported version number with the latest global policy version, the server can accurately identify door locks in a "lagging state," i.e., those devices that have not been updated in time due to long-term offline operation and have thus deviated from the global security baseline. At the same time, by deeply analyzing the operation logs reported by the door locks, the server can identify potential security threats such as brute-force attacks or abnormal usage patterns. Once lag or threat is detected, the system immediately initiates a proactive policy implementation and repair mechanism: the server can generate a new generation of public passwords according to a preset policy cycle or in response to specific threat events, and forcibly distribute it to the door locks through a secure NB-IoT channel. After the door locks enable the new password, all old passwords and associated user permissions that may have been leaked are immediately invalidated at the offline level, achieving instantaneous revoke of permissions. For devices marked as "lagging," the server will initiate an automatic repair program, continuously resending update commands until they successfully synchronize with the latest policy, ensuring eventual consistency across the system. In high-risk scenarios, the server also has remote intervention capabilities, allowing it to issue a "freeze" command to a specific lock, temporarily rejecting all unlocking requests until the administrator confirms the risk has been eliminated. This constitutes a complete closed-loop security lifecycle, ensuring that public passwords and user permissions remain under the server's control. Even if the lock operates offline most of the time, it can be effectively anchored within the global security framework through periodic online interactions.

[0057] The process of the server issuing the public password through the NB-IoT network is as follows: The server decides to update the public password of a certain door lock according to the security policy (such as every 30 days, after detecting potential risks, or initiated manually by the administrator).

[0058] First, the server generates a new, high-strength random number as the public password. Then, the server constructs a structured update instruction message. This message contains at least the following fields: instruction type identifier, version number, a strictly incrementing sequence number, a high-precision timestamp, and most importantly, the plaintext of the new public password.

[0059] Next, the server encrypts the instruction using the symmetric key shared with the lock and generates a digital signature. Specifically, the server uses a dedicated symmetric key derived from the TLS session master key to encrypt the instruction message using the AES-256-GCM algorithm. GCM mode provides both encryption and authentication, generating an authentication tag to ensure the data has not been tampered with while encrypted. Furthermore, to further strengthen authentication and non-repudiation, the server also digitally signs the entire unencrypted instruction message: it calculates the hash value of the message using the SHA-256 algorithm and signs the hash value with the server's private key to generate a digital signature.

[0060] After encryption and signing are completed, the server sends the complete data packet—including encrypted instructions, authentication tags, and digital signatures—to the target door lock through the established NB-IoT TLS secure channel. This transmission process completely bypasses the user's smartphone, ensuring that the public password is never exposed to potentially malware-infected mobile devices or insecure Bluetooth channels.

[0061] Upon receiving an update data packet, the door lock performs a series of rigorous verification steps. First, it verifies the digital signature using a pre-configured server public key. This step aims to confirm that the instruction indeed originates from a trusted server and that the instruction content has not been tampered with during transmission. If signature verification fails, the door lock immediately discards the data packet, records a security event log locally, and simultaneously sends an alarm message to the server via the NB-IoT module. If signature verification succeeds, the door lock uses a derived symmetric key shared with the server to decrypt the encrypted instruction portion, while simultaneously verifying the GCM authentication tag to ensure successful decryption and data integrity.

[0062] After decrypting the original command message, the door lock undergoes a crucial replay attack prevention check. The door lock persistently stores the sequence number received during the last successful update in non-volatile memory. It compares the sequence number in the new command with the locally stored sequence number; only if the new sequence number is significantly greater than the old one is the command considered fresh. Simultaneously, the door lock verifies the timestamp in the command, ensuring that its deviation from the door lock's local time is within a preset, reasonable time window. These two checks effectively defend against replay attacks where attackers intercept and repeatedly send old update commands.

[0063] Only after passing all the above verifications—signature valid, decryption successful, serial number fresh, and timestamp valid—will the lock perform the final operation: securely overwriting the old public password stored in its hardware security module with the new public password. Upon successful update, the lock sends an encrypted and signed confirmation response to the server. Upon receiving the confirmation, the server updates the lock's status in its database, marking the successful completion of the security update process. If the server fails to receive confirmation within the timeout period, it will resend the message a limited number of times according to the retry policy. If this ultimately fails, an operational alarm will be triggered, allowing administrators to intervene manually and ensuring eventual consistency of the system state.

[0064] In this embodiment, the smart lock stores first verification information and second verification information. When the smart lock is offline, it can perform dynamic temporary password verification and static public password verification, thereby ensuring the ultimate availability of the lock in extreme scenarios such as no network or weak network, and enabling the lock to independently complete high-security unlocking authentication in offline state.

[0065] like Figure 2 The diagram illustrates the flowchart of a verification information generation method according to an embodiment of this application, which may specifically include the following steps: Step S201: In response to a preset trigger event, generate a preset calculated key and a public password corresponding to the user identifier of the smart lock; In practical applications, the cloud server can be pre-configured with trigger events, which are used to generate the computational key and public password associated with the smart lock in the cloud. These trigger events can be set according to the specific scenario.

[0066] When a smart lock detects a trigger event in the current scene, the cloud server can generate a pre-configured key and a public password corresponding to the user's identifier. The pre-configured key is used to generate the first local verification information in the smart lock, enabling dynamic temporary password verification, while the public password is used to generate the second local verification information in the smart lock, enabling static public password verification. This allows for efficient and secure offline verification in the smart lock.

[0067] Step S202: The preset calculation key and the user identifier are sent to the smart lock through the application used to control the smart lock, so as to generate first verification information for temporary password verification in the smart lock.

[0068] Step S203: The public key is sent to the smart lock through the transmission channel pre-built between the smart lock and the cloud, so as to generate second verification information in the smart lock for public password verification.

[0069] In one embodiment of this application, the step of generating a preset calculated key and a public password corresponding to a user identifier of a smart lock in response to a preset triggering event includes: in response to a first triggering event for triggering the generation of the calculated key, obtaining a user identifier corresponding to the first triggering event and generating a preset calculated key corresponding to the user identifier; and in response to a second triggering event for triggering the generation of the public key, obtaining a random number and generating a public password based on the random number.

[0070] The first triggering event may include, but is not limited to, any one or more of the following: When a user registers for the first time and authorizes unlocking, when an administrator grants temporary unlocking permissions to a new visitor or temporary tenant, or when a user needs to change their key due to security reasons such as the loss of their original mobile phone.

[0071] The second triggering event may include, but is not limited to, any one or more of the following: The update may be triggered when the preset time period expires, user permissions are revoked, a potential security threat is detected, or an update is manually initiated by the administrator.

[0072] In one embodiment of this application, generating the preset computation key corresponding to the user identifier includes: determining the key generation method corresponding to the user identifier; generating a first computation key according to the key generation method; determining a first auxiliary parameter according to the key generation method; and encapsulating the first computation key and the auxiliary parameter to obtain the preset computation key.

[0073] The first auxiliary parameter may include, but is not limited to, the algorithm type identifier, the time step for the algorithm, the initial counter value for the algorithm, and the password length.

[0074] The key generation method can be either a completely random key generation method or a key generation method derived from the master key.

[0075] The generation of user computation keys is triggered in the following scenarios: initial user registration and authorization for unlocking, administrator granting temporary unlocking permissions to new visitors or temporary tenants, or the need to change the key for a user due to security reasons such as a lost mobile phone. The server first verifies the target user's identity information and logically binds the newly generated key to the user's unique identifier. Regarding the specific key generation method, the server can choose one of two approaches based on the security policy: one is to directly call a cryptographically secure random number generator to generate a completely random number of sufficient length to resist brute-force attacks as the computation key; the other is for the server to hold a global master key and use a key derivation function combined with the user identifier and a random salt value to derive the user computation key. This method facilitates batch management by the server and eliminates the need to store the plaintext of each user's computation key. Depending on the selected dynamic cryptography algorithm type, the server also needs to determine or generate auxiliary parameters, including an algorithm type identifier specifying whether TOTP or HOTP is used, the time step for TOTP, the initial counter value for HOTP, and the password length, and encapsulate these parameters along with the computation key. Finally, the server uses its own private key to digitally sign the encapsulated data structure, then stores the calculated key in the database, associates it with the user identifier, target door lock device ID, key validity period, and key status (valid, expired, revoked), and completes the entire generation process.

[0076] In one embodiment of this application, obtaining a random number and generating a public password based on the random number includes: calling a random number generator to generate a random number; determining a second auxiliary parameter corresponding to the random number; and encapsulating the random number and the second auxiliary parameter to obtain the public password.

[0077] The second auxiliary parameter may include: a monotonically increasing version number to identify the order of old and new versions, an effective timestamp indicating the expected effective time, an expiration timestamp indicating the deprecation time, and a digital signature generated using the server's private key for all the above fields. Setting the second auxiliary parameter ensures its authenticity and integrity.

[0078] The generation of a public password begins with the server determining trigger conditions. These conditions include the expiration of a preset time period, the revocation of user privileges, the detection of a potential security threat, or a manual update initiated by an administrator. Once triggered, the server invokes its hardware security module or cryptographically secure random number generator to generate a high-strength random number, typically 128 or 256 bits long, as the raw material for the new public password. The server then formats and encapsulates this random number, attaching a series of key metadata, including a strictly monotonically increasing version number to identify the order of old and new, an effective timestamp indicating the expected effective time, an expiration timestamp indicating the expiration time, and a digital signature generated using the server's private key for all the above fields to ensure its authenticity and integrity. After encapsulation, the server stores the newly generated public password in a database and associates it with the target lock device ID or device group ID, while recording the distribution status (e.g., pending distribution, distributed, confirmed), providing data for subsequent auditing and retry mechanisms.

[0079] In this embodiment of the application, by generating and distributing computing keys and public passwords to the smart lock in the cloud, a security level consistent with the global policy can be maintained.

[0080] It should be noted that the device control method provided in this application embodiment can be executed by a device control device, or a control module within the device control device for executing the method of loading a smart lock. This application embodiment uses the method of a device control device executing the method of loading a smart lock as an example to illustrate the smart lock control method provided in this application embodiment.

[0081] like Figure 3 The diagram shows a structural schematic of a device control apparatus according to an embodiment of this application, which may specifically include the following structure: The verification information acquisition module 301 is used to respond to a received unlocking request for the smart door lock and acquire, according to the unlocking request, first verification information for temporary password verification and second verification information for public password verification stored in the smart door lock. The unlocking request includes a data packet containing a user identifier and a first temporary password. The temporary password verification module 302 is used to verify the first temporary password based on the user identifier and the first verification information; The public password verification module 303 is used to verify the public password based on the second verification information when the temporary password verification is successful; The door lock control module 304 is used to control the smart door lock to start unlocking when the public password is successfully verified.

[0082] In one embodiment of this application, the temporary password verification module 302 may include: The password generation submodule is used to determine the preset calculation key and dynamic password generation algorithm corresponding to the user identifier in the first verification information; The second temporary password generation submodule is used to generate a second temporary password based on the preset calculation key and the dynamic password; The matching submodule is used to determine whether the first temporary password and the second temporary password match, so as to perform temporary password verification.

[0083] In one embodiment of this application, the second verification information is a public password carrying the password status, and the public password verification module 303 may include: A password status acquisition submodule is used to acquire the password status from the flag bit of the second verification information; The public password verification submodule is used to verify the public password based on the password status.

[0084] In one embodiment of this application, the apparatus further includes: The synchronization request response module is used to, in the state where the smart lock is connected to the application used to control the smart lock, respond to the received synchronization request and receive a preset calculation key and user identifier sent by the application. The preset calculation key and user identifier are data generated by the cloud to which the application is connected and sent to the application. The first verification information generation module is used to bind the preset calculation key and the user identifier to obtain the first verification information.

[0085] In one embodiment of this application, the apparatus may further include: The data acquisition module acquires the version number of the public password and / or security event logs; The data upload module is used to upload the version number and / or the security event log to the cloud through a pre-built transmission channel between the smart lock and the cloud, so that the cloud can generate a new public password when it determines that the smart lock is in a lagging state or has abnormal behavior; The data receiving module is used to receive new public passwords through a pre-built transmission channel between the smart lock and the cloud.

[0086] In this embodiment, the smart lock stores first verification information and second verification information. When the smart lock is offline, it can perform dynamic temporary password verification and static public password verification, thereby ensuring the ultimate availability of the lock in extreme scenarios such as no network or weak network, and enabling the lock to independently complete high-security unlocking authentication in offline state.

[0087] like Figure 4 The diagram shows a structural schematic of a device control apparatus according to an embodiment of this application, which may specifically include the following structure: The initial information generation module 401 is used to generate a preset calculated key and a public password corresponding to the user identifier of the smart lock in response to a preset trigger event. The first verification information generation module 402 is used to send the preset calculation key and the user identifier to the smart lock through an application for controlling the smart lock, so as to generate first verification information for temporary password verification in the smart lock.

[0088] The second verification information generation module 403 is used to send the public key to the smart lock through the transmission channel pre-built between the smart lock and the cloud, so as to generate second verification information in the smart lock for public password verification.

[0089] In one embodiment of this application, the initial information generation module 401 includes: The computation key generation submodule is used to respond to a first triggering event for triggering the generation of a computation key, obtain the user identifier corresponding to the first triggering event, and generate a preset computation key corresponding to the user identifier. The public key generation submodule is used to obtain a random number and generate a public key based on the random number in response to a second triggering event for triggering the generation of a public key.

[0090] In one embodiment of this application, the computation key generation submodule may include: A key generation method determination unit is used to determine the key generation method corresponding to the user identifier; The first computing key generation unit is used to generate a first computing key according to the key generation method. The first auxiliary parameter determination unit is used to determine the first auxiliary parameter according to the key generation method; A preset calculation key determination unit is used to encapsulate the first calculation key and the auxiliary parameters to obtain a preset calculation key.

[0091] In one embodiment of this application, the public key generation submodule may include: The random number generation unit is used to call the random number generator to generate random numbers; The second auxiliary parameter determination unit is used to determine the second auxiliary parameter corresponding to the random number; A public password generation unit is used to encapsulate the random number and the second auxiliary parameter to obtain a public password.

[0092] In this embodiment, the computing key and public password are generated and distributed to the smart lock in the cloud, maintaining a security level consistent with the global policy.

[0093] The device control device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0094] The device control device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0095] The device control apparatus provided in this application embodiment can achieve... Figures 1 to 2 The various processes implemented by the device control device in the method embodiment will not be described again here to avoid repetition.

[0096] Optionally, this application embodiment also provides an electronic device, including a processor 1010, a memory 1009, and a program or instructions stored in the memory 1009 and executable on the processor 1010. When the program or instructions are executed by the processor 1010, they implement the various processes of the above-described device control method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0097] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0098] Figure 5 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application. The electronic device 1000 includes, but is not limited to, the following components: radio frequency unit 1001, network module 1002, audio output unit 1003, input unit 1004, sensor 1005, display unit 1006, user input unit 1007, interface unit 1008, memory 1009, and processor 1010.

[0099] The memory 1009 includes applications and an operating system; the user input unit 1007 may include a touch panel 10071 and other input devices 10072; the input unit 1004 may include an image processor 10041 and a microphone 10042; and the display unit 1006 may include a display panel 10061.

[0100] Those skilled in the art will understand that the electronic device 1000 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 1010 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here. This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described device control method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0101] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0102] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described device control method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0103] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0104] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, 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 is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0106] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A device control method, characterized in that, Applied to smart door locks, the method includes: In response to a received unlocking request for a smart door lock, the system obtains first verification information for temporary password verification and second verification information for public password verification stored in the smart door lock according to the unlocking request. The unlocking request includes a data packet containing a user identifier and a first temporary password. The first temporary password is verified based on the user identifier and the first verification information; When the temporary password is successfully verified, the public password is verified based on the second verification information; When the public password is successfully verified, the smart door lock is controlled to start unlocking; The first verification information is generated by receiving a cloud response to a preset trigger event, generating a preset calculated key and a public password corresponding to the user identifier of the smart lock, and generating the smart lock based on the preset calculated key and the public password. The second verification information is generated by receiving the public password through a pre-built transmission channel between the smart lock and the cloud, and based on the public password; The cloud is configured to, in response to a first triggering event for triggering the generation of a computing key, obtain a user identifier corresponding to the first triggering event and generate a preset computing key corresponding to the user identifier; and in response to a second triggering event for triggering the generation of a public key, obtain a random number and generate a public password based on the random number.

2. The method according to claim 1, characterized in that, The step of verifying the first temporary password based on the user identifier and the first verification information includes: The preset calculation key and dynamic password generation algorithm corresponding to the user identifier are determined in the first verification information; A second temporary password is generated based on the preset calculation key and the dynamic password generation algorithm; Determine whether the first temporary password and the second temporary password match to perform temporary password verification.

3. The method according to claim 1, characterized in that, The second verification information is a public password carrying the password status. Verifying the public password based on the second verification information includes: The password status is obtained from the flag bit of the second verification information; The public password is verified based on the password status.

4. The method according to claim 1, 2, or 3, characterized in that, Also includes: When the smart lock is connected to the application used to control the smart lock, in response to the received synchronization request, the application sends a preset calculation key and a user identifier, which are data generated by the cloud to which the application is connected and sent to the application. The preset calculation key and the user identifier are bound together to obtain the first verification information.

5. The method according to claim 1, 2, or 3, characterized in that, Also includes: Obtain the version number and / or security event log of the public password; The version number and / or the security event log are uploaded to the cloud through a pre-built transmission channel between the smart lock and the cloud, so that the cloud can generate a new public password when it determines that the smart lock is in a lagging state or has abnormal behavior. The new public password is received through a pre-built transmission channel between the smart lock and the cloud.

6. A method for generating verification information, characterized in that, Applied to the cloud, the method includes: In response to a preset trigger event, a pre-calculated key and a public password corresponding to the user identifier of the smart lock are generated; The preset calculation key and the user identifier are sent to the smart lock through an application for controlling the smart lock, so as to generate first verification information for temporary password verification in the smart lock; The public password is sent to the smart lock through a pre-built transmission channel between the smart lock and the cloud, so as to generate second verification information in the smart lock for verifying the public password; The step of generating a preset calculated key and a public password corresponding to the user identifier of the smart lock in response to a preset trigger event includes: In response to a first triggering event for triggering the generation of a computing key, a user identifier corresponding to the first triggering event is obtained, and a preset computing key corresponding to the user identifier is generated; In response to a second triggering event used to trigger the generation of a public key, a random number is obtained and a public key is generated based on the random number.

7. The method according to claim 6, characterized in that, The generation of the preset calculation key corresponding to the user identifier includes: Determine the key generation method corresponding to the user identifier; Generate the first computing key according to the key generation method described above; The first auxiliary parameter is determined according to the key generation method; The first calculation key and the auxiliary parameters are encapsulated to obtain a preset calculation key.

8. The method according to claim 6, characterized in that, The step of obtaining a random number and generating a public password based on the random number includes: Call the random number generator to generate random numbers; Determine the second auxiliary parameter corresponding to the random number; The random number and the second auxiliary parameter are encapsulated to obtain the public password.

9. A device control apparatus, characterized in that, The device, used in smart door locks, includes: The verification information acquisition module is used to respond to a received unlocking request for the smart door lock, and acquire, according to the unlocking request, first verification information for temporary password verification and second verification information for public password verification stored in the smart door lock, wherein the unlocking request includes a data packet containing a user identifier and a first temporary password; A temporary password verification module is used to verify the first temporary password based on the user identifier and the first verification information; A public password verification module is used to verify the public password based on the second verification information when the temporary password is successfully verified. The door lock control module is used to control the smart door lock to start unlocking when the public password is successfully verified. The first verification information is generated by receiving a cloud response to a preset trigger event, generating a preset calculated key and a public password corresponding to the user identifier of the smart lock, and generating the smart lock based on the preset calculated key and the public password. The second verification information is generated by receiving the public password through a pre-built transmission channel between the smart lock and the cloud, and based on the public password; The cloud is configured to, in response to a first triggering event for triggering the generation of a computing key, obtain a user identifier corresponding to the first triggering event and generate a preset computing key corresponding to the user identifier; and in response to a second triggering event for triggering the generation of a public key, obtain a random number and generate a public password based on the random number.

10. A device for generating equipment verification information, characterized in that, The device, applied in the cloud, includes: The initial information generation module is used to generate a pre-calculated key and a public password corresponding to the user identifier of the smart lock in response to a preset trigger event. The first verification information generation module is used to send the preset calculation key and the user identifier to the smart lock through an application for controlling the smart lock, so as to generate first verification information in the smart lock for temporary password verification. The second verification information generation module is used to send the public password to the smart lock through a pre-built transmission channel between the smart lock and the cloud, so as to generate second verification information in the smart lock for verifying the public password. The initial information generation module may include: The computation key generation submodule is used to respond to a first triggering event for triggering the generation of a computation key, obtain the user identifier corresponding to the first triggering event, and generate a preset computation key corresponding to the user identifier. The public key generation submodule is used to obtain a random number and generate a public key based on the random number in response to a second triggering event for triggering the generation of a public key.

11. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the device control method as claimed in any one of claims 1 to 5 or the steps of the verification information generation method as claimed in any one of claims 6 to 8.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device control method as described in any one of claims 1 to 5 or the steps of the verification information generation method as described in any one of claims 6 to 8.

Images