Security equipment registration method, device, electronic device and storage medium

Abstract

The present invention discloses a security device registration method, apparatus, electronic device, and storage medium. The method includes: receiving device information sent by a target security device, the device information including a device identification; determining a first target data type based on the device identification, the first target data type being one of multiple data types generated by the target security device during operation; generating a first verification requirement based on the first target data type, and sending the first verification requirement to the target security device, the first verification requirement being used to instruct the target security device to send first verification data; receiving the first verification data sent by the target security device, and determining an identity verification result of the target security device based on the first verification data; and generating registration information for the target security device if the identity verification result is passed, and sending the registration information to the target security device. The present invention is advantageous in improving the credibility of identity verification results during security device registration.

Description

Technical Field

[0001] The present invention relates to the field of registration communication technology for security equipment, and in particular to a registration method, device, electronic device and storage medium for security equipment. Background Art

[0002] Currently, security device registration with a server is typically similar to the registration process for general IoT devices, requiring device registration and server access through steps such as time synchronization, identity verification, device registration, and communication establishment. In existing technologies, identity verification is typically performed by comparing information sent by the security device with a list of devices stored locally on the server. Information is encrypted during transmission to protect user data security. However, the encryption methods used by servers carry the risk of being cracked by third parties, resulting in low reliability of identity verification results during security device registration. Summary of the Invention

[0003] In response to the above problems, the embodiments of the present application provide a registration method, apparatus, electronic device and storage medium for a security device. The adoption of the solution of the present application is conducive to improving the credibility of the identity authentication results during the security device registration process.

[0004] In a first aspect, an embodiment of the present application provides a registration method for a security device, which is applied to a root server, and the method includes: receiving device information sent by a target security device, the device information including a device identification of the target security device; determining a first target data type based on the device identification, the first target data type being one of a plurality of data types generated by the target security device during operation; generating a first verification requirement for the target security device based on the first target data type, and sending the first verification requirement to the target security device, the first verification requirement being used to instruct the target security device to send first verification data of the first target data type; receiving first verification data sent by the target security device in accordance with the first verification requirement, and determining an identity authentication result of the target security device based on the first verification data; generating registration information of the target security device in the Internet of Things system if the identity authentication result is verification passed, and sending the registration information to the target security device.

[0005] It can be seen that in the embodiment of the present application, the root server generates a verification requirement based on the device information of the security device, and then the security device sends the first verification data to the root server according to the verification requirement. The root server performs identity authentication based on the verification information of the security device to obtain an authentication result. The authentication result is supported by the first verification data provided by the security device, which improves the credibility of the authentication result, thereby improving the security of the security device in the registration process and ensuring the data security of the security device user.

[0006] In combination with the first aspect, in a possible embodiment, determining a first target data type based on a device identifier includes: determining a device type and a device model of a target security device based on the device identifier; determining the first target data type based on the device type and the device model of the target security device; if determining the device type and the device model of the target security device based on the device identifier fails, determining an inferred device type of the target security device based on the device identifier; determining a second target data type and a third target data type based on the inferred device type; wherein the second target data type is one of a plurality of data types generated by the security device of the inferred device type during operation, and the third target data type is not a data type generated by the security device of the inferred device type during operation; generating a second verification requirement based on the second target data type and the third target data type, and sending the second verification requirement to the target security device, the second verification requirement being used to instruct the target security device to send second verification data of the second target data type and third verification data of the third target data type; if the second verification data and the third verification data sent by the target security device are received simultaneously, determining that the identity authentication result of the target security device is verification failure; if the second verification data and the third verification data sent by the target security device are not received simultaneously, determining the first target data type based on the inferred device type.

[0007] It can be seen that in this embodiment, through the combination of device type inference and reverse data type verification, it is effective to deal with scenarios where the device identification is ambiguous or forged. While reducing the misjudgment rate, it significantly improves the recognition accuracy of counterfeit devices, improves the credibility of identity authentication results, and ensures the data security of security device users.

[0008] In combination with the first aspect, in a possible embodiment, determining the identity authentication result of the target security device based on the first verification data includes: determining the device type and device model of the target security device based on the device identification; determining whether the first verification data is a first target data type; if the first verification data is a first target data type and the device type is a sensing device, determining a reasonable numerical range of the first verification data based on the device model; if the first verification data is within the reasonable numerical range, determining the identity authentication result as passed verification; if the first verification data is a first target data type and the device type is a camera device, determining reasonable image parameters of the first verification data based on the device model; if the first verification data is within the reasonable image parameters, determining the identity authentication result as passed verification.

[0009] In combination with the first aspect, in a possible embodiment, if the device type is a sensor device, the method also includes: if the first verification data is not the first target data type, determining that the identity authentication result is verification failure; if the first verification data does not conform to a reasonable numerical range, obtaining the number of verifications of the target security device, and if the number of verifications is not greater than the preset number, generating a second verification requirement, the second verification requirement is used to instruct the target security device to send the first verification data of the fourth target data type; sending the second verification requirement to the target security device; if the number of verifications is greater than the preset number, determining that the identity authentication result is verification failure.

[0010] It can be seen that in the embodiment of the present application, for security equipment of the sensor device type, through the two mechanisms of data value range verification and dynamic verification strength adjustment, while ensuring the identity authentication efficiency of security equipment of the sensor device type, it effectively resists security threats such as forged data and replay attacks, thereby improving the efficiency of security equipment registration while ensuring information security.

[0011] In combination with the first aspect, in a possible embodiment, if the device type is a camera device, the method also includes: if the data type of the first verification data is not an image data type, determining that the identity authentication result is verification failure; if the first verification data does not meet reasonable image parameters, obtaining the number of verifications of the target security device, and if the number of verifications is not greater than the preset number, generating a third verification requirement, the third verification requirement is used to instruct the target security device to send the first verification data of the image data type including at least one verification feature, the verification feature including a zoom feature or a movement feature; sending the third verification requirement to the target security device; if the number of verifications is greater than the preset number, determining that the identity authentication result is verification failure.

[0012] It can be seen that in the embodiment of the present application, for security equipment of the image device type, through three layers of protection: data type filtering, technical parameter verification, and dynamic behavior verification, while ensuring the rapid response of the camera equipment, it effectively resists security threats such as image forgery, replay attacks, and device hijacking, thereby improving the efficiency of security equipment registration while ensuring information security.

[0013] In combination with the first aspect, in a possible embodiment, before determining the target data type based on the device identifier, the method also includes: generating query information based on the device identifier and sending the query information to the cache device; wherein the cache device is used to cache the registration information of the security device, and the query information is used to request the cache device to send the registration information of the target security device; and determining that the registration information sent by the cache device is not received.

[0014] In combination with the first aspect, in a possible embodiment, after generating registration information of the target security device in the Internet of Things system if the identity authentication result is verification passed, the method also includes: sending the registration information to a cache device so that the cache device stores the registration information of the security device.

[0015] It can be seen that in the embodiment of the present application, the root server caches the registration information of the registered security device in the cache device, and can send the registration information directly to the security device when the registered device submits a registration request again, thereby reducing the amount of data processing of the root server and improving the processing and transmission efficiency of the root server.

[0016] In a second aspect, an embodiment of the present application provides a registration device for a security device, the registration device for a security device being used to execute a registration method for a security device, the registration device for a security device comprising:

[0017] The receiving unit is used to receive device information sent by the target security device, where the device information includes a device identification of the target security device.

[0018] The determination unit is used to determine the target data type according to the device identification, where the target data type is one of the multiple data types generated by the target security device during operation.

[0019] The sending unit is used to generate a first verification requirement of the target security device according to the target data type, and send the first verification requirement to the target security device, where the first verification requirement is used to instruct the target security device to send first verification data of the target data type.

[0020] The receiving unit is configured to receive first verification data sent by the target security device according to the first verification requirement, and determine an identity verification result of the target security device according to the first verification data.

[0021] The sending unit is used to generate registration information of the target security device in the Internet of Things system if the identity authentication result is verification passed, and send the registration information to the target security device.

[0022] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and one or more instructions are suitable for being loaded by the processor and executing part or all of the methods of the first aspect and / or the second aspect.

[0023] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium that stores a computer program for electronic data exchange, wherein the computer program enables a computer to execute part or all of the method of the first aspect and / or the second aspect.

[0024] In a fifth aspect, the present application provides a computer program product, which, when read and executed by a computer, enables the computer to execute part or all of the method of the first aspect and / or the second aspect.

[0025] It can be understood that the beneficial effects of the embodiments of the second to fifth aspects can refer to the beneficial effects of the method of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0027] Figure 1 A schematic diagram of an application scenario of a registration method for security equipment provided in an embodiment of the present application;

[0028] Figure 2 A flowchart of a registration method for a security device provided in an embodiment of the present application;

[0029] Figure 3 A flowchart of another method for registering a security device provided in an embodiment of the present application;

[0030] Figure 4 A schematic diagram of the structure of an Internet of Things system for security equipment provided in an embodiment of the present application;

[0031] Figure 5 A schematic diagram of communication between a target security device and a root server provided in an embodiment of the present application;

[0032] Figure 6 A flowchart of another method for registering a security device provided in an embodiment of the present application;

[0033] Figure 7 A schematic diagram of the structure of a registration device for security equipment provided in an embodiment of the present application;

[0034] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0035] Explanation of the accompanying figures: 100: application scenario; 101: target security device; 102: root server; 103: communication server; 700: registration device for security device; 701: receiving unit; 702: determination unit; sending unit 703; 800: electronic device; 801: memory; 802: processor; 803: communication interface; 804: bus. DETAILED DESCRIPTION

[0036] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0037] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0038] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0039] The embodiments of the present application are described below with reference to the accompanying drawings.

[0040] Example 1: Please see Figure 1 , Figure 1This is a schematic diagram of an application scenario for a security device registration method provided in an embodiment of the present application. The application scenario 100 includes a target security device 101, a root server 102, and a communication server 103. The target security device 101 is specifically a security protection device, such as a fire alarm, temperature alarm, access control device, smart doorbell, smart camera device, etc. The root server 102 is used to communicate with the target security device 101 directly or through the communication server 103, thereby implementing functions such as message sending and receiving, and updating device firmware and application software. The communication server 103 here is a distributed stream processing middleware, which is used to implement asynchronous message transmission between the target security device 101 and the root server 102, as well as data processing and other functions.

[0041] The communication server 103 is specifically a Kafka communication server or an EMQX communication server.

[0042] In an embodiment of the present application, the root server 102 receives device information sent by the target security device 101. The device information includes the device identification of the target security device 101. This device information specifically includes the device identification, MAC media access control address and other information related to the target security device 101. Subsequently, the root server 102 will perform identity authentication of the security device based on the device information of the target security device 101.

[0043] It should be noted that in the prior art, the root server 102 usually performs verification based on the device information of the target security device 101 and the device information list pre-stored in the local or cache device. If the device information list includes the device information of the target security device 101, it is determined that the target security device 101 has passed the identity authentication.

[0044] In an embodiment of the present application, the root server 102 needs to determine the first target data type through the device identification of the target security device 101. The first target data type is one of the multiple data types generated by the target security device 101 during operation. That is to say, the first target data type is one of the multiple data types that the target security device 101 will generate during operation. Further, the root server 102 can determine multiple first target data types based on the multiple data types described above.

[0045] After determining the first target data type, root server 102 generates a first verification requirement for target security device 101 based on the first target data type and sends the first verification requirement to target security device 101. The first verification requirement is used to instruct target security device 101 to send first verification data of the first target data type. For example, the first verification requirement here specifically requires target security device 101 to send all data of the first target data type collected within the next 30 minutes.

[0046] The root server 102 receives the first verification data sent by the target security device 101 according to the first verification requirement, and determines the identity authentication result of the target security device 101 based on the first verification data. The root server 102 specifically determines the identity authentication result of the target security device 101 based on the characteristics (such as data value, distribution pattern, data integrity, etc.) of all data of the first target data type sent by the target security device 101 and collected within the next 30 minutes.

[0047] If the authentication result is successful, the root server 102 generates registration information for the target security device 101 in the IoT system and sends the registration information to the target security device 101. The registration information here specifically includes the account password and server address of the communication server 103. The target security device 101 can connect to the communication server 103 based on the registration information, thereby establishing a stable communication channel between the device and the root server 102, realizing real-time data transmission and interaction.

[0048] It can be seen that in the embodiment of the present application, the root server generates a verification requirement based on the device information of the security device, and then the security device sends the first verification data to the root server according to the verification requirement. The root server performs identity authentication based on the verification information of the security device to obtain an authentication result. The authentication result is supported by the first verification data provided by the security device, which improves the credibility of the authentication result, thereby improving the security of the security device in the registration process and ensuring the data security of the security device user.

[0049] Figure 2 A flowchart of a registration method for a security device provided in an embodiment of the present application is shown as follows: Figure 2 As shown, steps S201-S205 are included.

[0050] S201: The root server receives device information sent by a target security device, where the device information includes a device identifier of the target security device.

[0051] Specifically, the device information here specifically includes the device identification, MAC address and other information of the target security device. The device information is specifically sent when the target security device needs to initiate a registration request to the root server and request access to the Internet of Things system where the root server is located.

[0052] S202: The root server determines a first target data type according to the device identifier, where the first target data type is one of a plurality of data types generated by the target security device during operation.

[0053] Specifically, the root server can determine the first target data type of the target security device based on the device identification of the target security device, where the target data type is one of the multiple data types generated by the target security device during operation. For example, if the target security device is a temperature sensor, its corresponding first target data type may be a temperature data type, rather than an image data type.

[0054] Furthermore, before determining the first target data type based on the device identifier, the root server may also perform additional verification based on the device information of the target security device and the security device information in the local database. If the device information of the target security device is stored in the local database, S202 and subsequent steps are executed. If the device information of the target security device is not stored in the local database, the identity authentication result of the target security device is determined to be verification failure.

[0055] Optionally, determining the first target data type based on the device identification includes: determining the device type and device model of the target security device based on the device identification; determining the first target data type based on the device type and device model of the target security device; if determining the device type and device model of the target security device based on the device identification fails, determining the inferred device type of the target security device based on the device identification; determining the second target data type and the third target data type based on the inferred device type; wherein the second target data type is one of the data types of multiple data generated by the security device of the inferred device type during operation, and the third target data type is not the data type generated by the security device of the inferred device type during operation; generating a second verification requirement based on the second target data type and the third target data type, and sending the second verification requirement to the target security device, the second verification requirement being used to instruct the target security device to send second verification data of the second target data type and third verification data of the third target data type; if the second verification data and the third verification data sent by the target security device are received at the same time, determining that the identity authentication result of the target security device is verification failure; if the second verification data and the third verification data sent by the target security device are not received at the same time, determining the first target data type based on the inferred device type.

[0056] Specifically, in the embodiment of the present application, the first target data type of the first target security device is determined primarily by determining the device type and device model of the target security device based on the device identifier. Specifically, the determination can be based on a preset correspondence between the device identifier, the device type, and the device model. Furthermore, the first target data type is determined based on the correspondence between the device type, the device model, and the data type.

[0057] If the root server cannot match the device identifier to the pre-defined device type library (for example, the device identifier does not include a standard model code or the communication protocol does not match), the device type inference process is initiated, and the device type is determined based on some characteristics in the device identifier (such as the brand identifier, signal frequency band, or port number). For example, if the device identifier includes the "CAM_" prefix but lacks complete model information, the device type is inferred to be a camera.

[0058] Based on the inferred device type, the root server extracts a second target data type and a third target data type from a preset data type mapping table. The second target data type is a data type that the inferred device type must generate during normal operation (e.g., a camera generates image stream data, or a sensor generates numerical data). The third target data type is a data type that the inferred device type cannot physically generate (e.g., requiring a camera to send temperature data, or requiring a temperature sensor to send audio data).

[0059] The root server then generates a second verification request, instructing the target security device to submit both the second target data type and the first verification data of the third target data type. For example, a device presumed to be an infrared sensor would need to submit the current ambient temperature value (the third target type) and a segment of audio waveform data (the fourth target type). The microprocessor sends the second verification request to the target security device via an encrypted communication channel.

[0060] If the target security device returns the second verification data of the second target data type (for example, an infrared sensor returns audio data), the authentication result is directly determined to be failed and the device is marked as a suspected counterfeit device. If no data of the fourth target data type is returned (for example, only a temperature value is returned, or the corresponding data cannot be provided), the root server determines the first target data type (not the second or third target data type) based on the inferred device type for final verification, performing cryptographic verification or value range comparison.

[0061] It can be seen that in this embodiment, through the combination of device type inference and reverse data type verification, it is effective to deal with scenarios where the device identification is ambiguous or forged. While reducing the misjudgment rate, it significantly improves the recognition accuracy of counterfeit devices, improves the credibility of identity authentication results, and ensures the data security of security device users.

[0062] Optionally, the first target data type is determined based on the device type and device model of the target security device, specifically including: determining the device type and device model of the target security device based on the device identifier; if the device type is a sensing device, determining the first target data type based on the device model, wherein a preset device model corresponds to a plurality of data types, the preset device model includes the device model, and the plurality of data types include the first target data type; if the device type is a camera device, determining the image data type as the first target data type.

[0063] Specifically, in the embodiments of the present application, the target security equipment is divided into sensing equipment or imaging equipment, where the sensing equipment specifically refers to security equipment such as smoke alarms, humidity alarms, smart door locks, etc. that cannot generate and send image data; the imaging equipment specifically refers to security equipment such as cameras, video doorbells, etc. that can generate image data during operation.

[0064] First, for security devices that are image devices, in this solution, identity authentication is mainly performed through the image data they generate. This is because the security devices that need to generate image data are specifically security cameras, visual doorbells and other devices, which need to generate relevant image data during their operation. The cost of counterfeiting image data is high and the difficulty of identification is low. The root server can obtain the relevant reasonable image parameters (such as frame rate, resolution and other parameters) of the image data it generates on the premise of knowing its device type and device model, and then authenticate the target security device based on information such as reasonable image parameters to determine the image data type as the first target data type.

[0065] For sensor devices, the root server determines the target security device's device type and model based on the device identifier in the device information. Device types include smoke alarms, humidity alarms, smart door locks, and other types. Device models include "DX-001," "DX-001A," "DX-002," and so on. Each device model corresponds to different models of the same security device. The type of data generated by security devices during operation depends not only on the device type but also on the device model. Newer models of the same security device may generate more or fewer types of data than older models during operation.

[0066] Therefore, after determining that the device type of the target security device is a sensor device, the root server first determines the multiple data types corresponding to the target security device based on the device model of the target security device and the correspondence between the preset device model and multiple data types, and then determines the first target data type from the multiple data types corresponding to the target security device.

[0067] Furthermore, the root server needs to determine one or more first target data types from the multiple data types corresponding to the target security device, and preferentially determine the data type with a high correlation with the device type of the target security device as the first target data type. The correlation refers to the degree of association between the data type and the device type of the corresponding target security device. For example, for the security device of the smoke alarm, the correlation of the smoke concentration data is higher than the correlation of the power data.

[0068] It can be seen that in the embodiment of the present application, the first target data type of the sensing device is screened from a variety of data types corresponding to the target security device, and the first target data type of the imaging device is the image data type; this enables the root server to have data support for the subsequent identity authentication results, thereby improving the credibility of the verification results; for the imaging device, it also reduces the difficulty of authenticating the target security device based on the first verification data, thereby improving the verification efficiency and thereby improving the registration efficiency of the security device.

[0069] S203: The root server generates a first verification requirement for the target security device according to the first target data type, and sends the first verification requirement to the target security device, where the first verification requirement is used to instruct the target security device to send first verification data of the first target data type.

[0070] Specifically, after the root server determines the first target data type of the target security device, it is necessary to generate a first verification requirement for the target security device based on the first target data type. The first verification requirement here is used to instruct the target security device to send the first verification data of the first target data type. Specifically, the target security device may be required to send all data within a period of time, or separate data at a specific time point.

[0071] S204: The root server receives first verification data sent by the target security device according to the first verification requirement, and determines an identity authentication result of the target security device according to the first verification data.

[0072] Optionally, determining the identity authentication result of the target security device based on the first verification data includes: determining the device type and device model of the target security device based on the device identification; determining whether the first verification data is a first target data type; if the first verification data is a first target data type and the device type is a sensing device, determining a reasonable numerical range of the first verification data based on the device model; if the first verification data is within the reasonable numerical range, determining the identity authentication result as passed verification; if the first verification data is a first target data type and the device type is a camera device, determining reasonable image parameters of the first verification data based on the device model; if the first verification data is within the reasonable image parameters, determining the identity authentication result as passed verification.

[0073] Specifically, in this embodiment of the present application, different verification methods are employed based on the device type of the target security device. First, the root server determines whether the first verification data is of the first target data type. If the first verification data is not of the first target data type, it is determined that the target security device cannot provide relevant data corresponding to its device type as identity proof. The root server then directly determines that the target security device's identity verification result is unsuccessful.

[0074] If the first verification data is of the first target data type and the device type is a sensor device, the root server determines a reasonable numerical range for the first verification data based on the device type. If the range is within the reasonable numerical range, the identity verification result is determined to be passed. It should be noted that the reasonable numerical range here is determined based on the device model and device type provided by the target security device. The correspondence between the reasonable numerical range, device type, and device model is also stored locally on the root server. Therefore, if the first verification data is within the reasonable numerical range, the identity of the target security device is determined to be legitimate, and the identity verification result is determined to be passed.

[0075] If the first verification data is of the first target data type and the device type is a camera, reasonable image parameters for the first verification data are determined based on the device model. Similar to sensor devices, for camera devices, relevant data features, namely reasonable image parameters, must be determined based on the device type and model for identity verification. Specifically, the root server will install various plug-ins and software locally to analyze the image data, obtaining features such as the frame rate, resolution, and watermark information of the first verification data. If it is determined that the image parameters meet the reasonable parameters, the target security device is deemed legitimate and the identity verification result is determined to be passed.

[0076] Optionally, if the device type is a sensing device, the method also includes: obtaining environmental information of the target security device, the environmental information including at least one of temperature information, season information, weather information or humidity information, and determining a reasonable numerical range of the first verification data based on the environmental information, device type and device model.

[0077] Specifically, in this embodiment, for sensor devices deployed in a changing environment (such as outdoor security temperature and humidity sensors), the dynamically adjusted threshold can filter out environmental noise interference and accurately identify real abnormal data, thereby improving the accuracy of the root server's authentication results.

[0078] Optionally, if the device type is a sensor device, the method also includes: if the first verification data is not the first target data type, determining that the identity authentication result is verification failure; if the first verification data does not conform to a reasonable numerical range, obtaining the number of verifications of the target security device, and if the number of verifications is not greater than a preset number, generating a second verification requirement, the second verification requirement is used to instruct the target security device to send the first verification data of a fourth target data type; sending the second verification requirement to the target security device; if the number of verifications is greater than the preset number, determining that the identity authentication result is verification failure.

[0079] Specifically, this embodiment improves the accuracy of security device authentication through a layered verification strategy. The root server first quickly screens the basic attributes (data type, value range) of the first verification data. If the basic verification fails, the root server determines the result without performing complex calculations, thereby reducing system resource consumption.

[0080] For scenarios where the values ​​are abnormal but the data types are consistent, the verification strength is dynamically adjusted based on the number of verification attempts: within the allowed number of attempts, the device is required to provide a fourth target data type with a higher security level (such as multi-factor authentication); if the number of attempts is exhausted, the verification process is terminated immediately to prevent brute force cracking.

[0081] Furthermore, the reasonable value range is set based on the physical characteristics of the target security device and the normal environment. For example, the output value of a light sensor is usually below 10 lux at night. If it receives a value above 1000 lux and the device is not in a bright light environment, it is considered an abnormality. The root server dynamically updates the reasonable value range by comparing the device's reported data with the environmental information of the target security device in real time, avoiding misjudgments caused by sudden environmental changes.

[0082] Furthermore, the verification count and reset mechanism is tied to the device's identity. If a target security device fails to trigger verification within a preset time period (e.g., 24 hours), the verification counter automatically resets to zero. If a device is locked due to repeated failures, an administrator must manually unlock it through a secure channel, ensuring system defense flexibility.

[0083] It can be seen that in the embodiment of the present application, for security equipment of the sensor device type, through the two mechanisms of data value range verification and dynamic verification strength adjustment, while ensuring the identity authentication efficiency of security equipment of the sensor device type, it effectively resists security threats such as forged data and replay attacks, thereby improving the efficiency of security equipment registration while ensuring information security.

[0084] Optionally, if the device type is a camera device, the method also includes: if the data type of the first verification data is not an image data type, determining that the identity authentication result is verification failure; if the first verification data does not meet reasonable image parameters, obtaining the number of verifications of the target security device, and if the number of verifications is not greater than the preset number, generating a third verification requirement, the third verification requirement is used to instruct the target security device to send the first verification data of the image data type including at least one verification feature, the verification feature including a zoom feature or a movement feature; sending the third verification requirement to the target security device; if the number of verifications is greater than the preset number, determining that the identity authentication result is verification failure.

[0085] Specifically, this embodiment designs a multi-level verification mechanism based on the characteristics of the camera device. The root server first excludes disguise attacks of non-image data (such as forged text or audio data) through data type screening. For image data, the basic legitimacy is further detected through technical parameter verification. For example, low-resolution images may be forged screenshots, and abnormal frame rates may be video tampering. If the parameter verification fails but the data type is legal, the verification strength is dynamically upgraded based on the number of verifications: the device is required to submit image data containing dynamic behaviors (such as zooming and focusing on a specific QR code or performing preset trajectory movements) within the allowed number of times. Such features require real-time physical operations to generate and are difficult to forge through static image replay attacks.

[0086] Furthermore, the generation and verification of dynamic verification features is integrated with image analysis algorithms. For example, the zoom feature verifies the device's focus accuracy on the target within a specified timeframe, while the movement feature matches the spatiotemporal coordinates of a pre-set trajectory (e.g., a 30cm horizontal translation followed by a 15° vertical rotation). The root server uses a timestamp compensation algorithm to mitigate the effects of image transmission delays, ensuring the temporal consistency of dynamic behavior. If the dynamic features in the image data returned by the device do not match the spatiotemporal logic specified in the command, the data is deemed invalid.

[0087] Furthermore, the verification threshold is linked to the device's risk level. Cameras in high-risk areas are set to a threshold of one verification attempt, while those in standard areas can be set to three. If a device is locked due to repeated failures, it must be manually unlocked by the administrator to prevent remote malicious attacks.

[0088] It can be seen that in the embodiment of the present application, for security equipment of the image device type, through three layers of protection: data type filtering, technical parameter verification, and dynamic behavior verification, while ensuring the rapid response of the camera equipment, it effectively resists security threats such as image forgery, replay attacks, and device hijacking, thereby improving the efficiency of security equipment registration while ensuring information security.

[0089] S205: If the identity authentication result is that the authentication passes the root server, registration information of the target security device in the Internet of Things system is generated, and the registration information is sent to the target security device.

[0090] Specifically, after determining that the identity authentication result is passed, the server generates registration information for the target security device in the Internet of Things system. The registration information here specifically includes information such as account number, password, and server address. After receiving the registration information, the target security device connects to the communication server through the registration information, thereby realizing asynchronous communication with the root server.

[0091] In addition, the target security device also includes the message subject in the received information. The message subject is used to indicate the purpose, function or category of each message, thereby preventing problems such as incomplete information or information being intercepted and tampered with during the communication process between the root server, communication server and the target security device.

[0092] If the authentication result is failed, the root server also needs to implement measures such as blacklisting the device ID, IP address and other device information of the target security device, generating corresponding security logs, and pushing them to the operation and maintenance platform.

[0093] Example 2: In Example 1, a root server registration method for security devices is described. Based on this, under the premise that the root server is also connected to the cache device, this embodiment of the application also provides a more detailed registration method for security devices, see Figure 3 , Figure 3 A flowchart of another registration method for security equipment provided in an embodiment of the present application includes steps S301-S307.

[0094] S301: The root server receives device information sent by a target security device, where the device information includes a device identifier of the target security device.

[0095] S302: The root server generates query information according to the device identifier and sends the query information to the cache device; wherein the cache device is used to cache the registration information of the security device, and the query information is used to request the cache device to send the registration information of the target security device.

[0096] Specifically, after receiving the device information from the target security device and before determining the target data type based on the device identifier, the root server generates query information based on the device identifier and sends the query information to a cache device. A cache device, such as a Remote Dictionary Server (Redis), caches the registration information (including device type, model, communication protocol, account number, and password) of authenticated security devices.

[0097] S303: The root server determines that it has not received the registration information sent by the cache device.

[0098] S304: The root server determines a first target data type according to the device identifier, where the first target data type is one of a plurality of data types generated by the target security device during operation.

[0099] S305: The root server generates a first verification requirement for the target security device according to the first target data type, and sends the first verification requirement to the target security device, where the first verification requirement is used to instruct the target security device to send first verification data of the first target data type.

[0100] S306: The root server receives first verification data sent by the target security device according to the first verification requirement, and determines an identity authentication result of the target security device according to the first verification data.

[0101] S307: If the identity authentication result is that the authentication passes the root server, the registration information of the target security device in the Internet of Things system is generated and the registration information is sent to the target security device.

[0102] For detailed descriptions of steps S301 and S304-S307, please refer to the relevant descriptions of steps S201-S205, which will not be repeated here.

[0103] Optionally, if the identity authentication result is that the authentication is passed, after generating registration information of the target security device in the Internet of Things system, the method further includes: sending the registration information to a cache device so that the cache device stores the registration information of the security device.

[0104] Specifically, see Figure 4 , Figure 4 A structural diagram of an Internet of Things system for a security device provided in an embodiment of the present application, which includes a target security device, a root server, a cache device, and a communication server. It can be seen that the target security device first sends device information to the root server to start the registration process. The root server queries the cache device based on the device information whether there is registration information of the target security device. If the registration information exists in the cache device, the registration information is sent to the target security device, or identity authentication is performed based on the device information (for detailed identity authentication process, please refer to the relevant description of the aforementioned steps S202-S204, which will not be repeated here). After the identity authentication is passed, the registration information is generated and sent to the target security device, and the registration information is cached in the cache device. The target security device then establishes a communication channel with the communication server based on the registration information to complete the registration.

[0105] In the embodiment of the present application, in addition to sending the registration information to the target security device and storing it in the local cache of the root server, the registration information will also be cached in the cache device.

[0106] This is because the target security device may lose its registration information during the process of system upgrade, factory reset, etc., resulting in an inability to communicate normally with the root server. At this time, the device information will be re-sent to the root server for registration. At this time, when the root server receives the device information of the target security device again, it can directly obtain the corresponding registration information from the cache device and send it directly to the security device, thereby reducing the amount of data processing by the root server and improving the processing and transmission efficiency of the root server.

[0107] It can be seen that in the embodiment of the present application, the root server caches the registration information of the registered security device in the cache device, and can send the registration information directly to the security device when the registered device submits a registration request again, thereby reducing the amount of data processing of the root server and improving the processing and transmission efficiency of the root server.

[0108] Optionally, the root server is connected to the first communication server and the second communication server respectively to generate registration information of the target security device in the Internet of Things system, including: generating first registration information of the target security device in the first communication server, and determining the first registration information as the registration information; if a connection failure message sent by the target security device is received, generating second registration information of the target security device in the second communication server, and determining the second registration information as the registration information.

[0109] See Figure 5 , Figure 5 This is a schematic diagram of communication between a target security device and a root server, provided in an embodiment of the present application. It can be seen that the target security device can communicate with the root server through either the first or second communication server. As previously mentioned, the target security device needs to establish a connection with the communication server during the registration process. Therefore, if the target security device fails to establish a connection with the first communication server, it will send a connection failure message to the root server to obtain the second registration information generated by the root server and attempt to establish a connection with the second communication server. Ultimately, the target security device will establish a communication connection with the root server via either the first or second communication server.

[0110] Example 3: Example 1 describes a registration method for an independent security device. Based on this, this embodiment of the present application provides another, more detailed method for registering a security device, assuming the target security device is a security device in a device cluster. The device cluster includes multiple security devices of the same type, such as multiple cameras or temperature sensors, installed in the same area. The multiple security devices in the device cluster can communicate with each other via short-range communication technology (such as Bluetooth), thereby enabling functions such as image collection, temperature acquisition, and fire warning in a centralized area.

[0111] See Figure 6 , Figure 6 A flowchart of another method for registering a security device provided in an embodiment of the present application includes steps S601-S605.

[0112] S601: The root server receives device information sent by a target security device. The device information includes a device identifier and a cluster identifier of the target security device. The cluster identifier is used to identify the device cluster to which the target security device belongs.

[0113] S602: If the target security device is the first registered device in the device cluster corresponding to the cluster identifier, the root server determines a first target data type based on the device identifier. The first target data type is one of the multiple data types generated by the target security device during operation.

[0114] S603: The root server generates a first verification requirement for the target security device according to the first target data type, and sends the first verification requirement to the target security device, where the first verification requirement is used to instruct the target security device to send first verification data of the first target data type.

[0115] S604: The root server receives first verification data sent by the target security device according to the first verification requirement, and determines an identity authentication result of the target security device according to the first verification data.

[0116] S605: If the identity authentication result is that the authentication passes the root server, registration information of the target security device in the Internet of Things system is generated, and the registration information is sent to the target security device.

[0117] Optionally, if the target security device is not the first registered device in the device cluster to which it belongs, and the device type of the target security device is a sensor device, the method further includes: obtaining reference data sent by the first registered device in the device cluster corresponding to the cluster identifier based on the cluster identifier, the reference data including data of the fifth target data type generated by the first registered device within the target time period; sending a fifth verification requirement to the target security device, the fifth verification requirement being used to instruct the target security device to send second verification data corresponding to the fifth data type generated within the target time period to the root server; receiving second verification data sent by the target security device based on the fifth data type; and authenticating the target security device based on the reference data and the second verification data.

[0118] Specifically, in this embodiment, the device type of the target security device is a sensor device, and the root server establishes a trusted benchmark based on the reference data of the first registered device in the cluster. Since the first device has been strictly verified through the process in the aforementioned steps, its identity has a high degree of credibility. Under the premise that there are registered devices, the data of the same time period and the same data type submitted by the target security device to prove that it is in the same physical environment or performing the same task is sufficient to prove the legitimacy of its identity. For example, in a smart building cluster, if the first temperature sensor records an indoor temperature of 15°C in a certain period of time, and the target device reports 30°C in the same period of time, it may be a counterfeit device or a sensor failure.

[0119] If the similarity between the reference data and the second verification data is greater than the preset similarity, the identity authentication result of the target security device is determined to be verification passed.

[0120] It can be seen that in the embodiment of the present application, under the premise that there is a device that has been successfully registered in the device cluster where the target security device is located, the identity of the target security device is performed based on the second verification data and the reference data. Compared with the verification process of the first registered device, the data type of the verification data of the target security device can be directly determined by the data type corresponding to the registered device, reducing the steps of determining the data type and reasonable data range of the target security device, thereby reducing the data processing volume of the root server and improving the verification and registration efficiency of the security device.

[0121] Optionally, if the target security device is not the first registered device in the device cluster to which it belongs, and the device type of the target security device is an image device, the method further includes: obtaining a reference image sent by the first registered device in the device cluster corresponding to the cluster identifier according to the cluster identifier; determining a feature target from the reference image; sending a sixth verification requirement to the target security device, the sixth verification requirement being used to instruct the target security device to send image data to the root server; receiving the image data sent by the target security device according to the sixth verification requirement; if the image data sent by the target security device according to the sixth verification requirement includes a feature target, determining that the identity authentication result of the target security device is verification passed; if the image data sent by the target security device according to the sixth verification requirement does not include a feature target, determining whether the environmental characteristics of the image data sent by the target security device according to the sixth verification requirement are consistent with the environmental characteristics of the reference image; if the environmental characteristics of the image data sent by the target security device according to the sixth verification requirement are consistent with the environmental characteristics of the reference image, determining that the identity authentication result of the target security device is verification passed.

[0122] Specifically, in this embodiment of the present application, the target security device is an imaging device, and the device cluster constructs baseline verification information using the reference image provided by the first registered device. Feature targets specifically refer to specific flat patterns, objects, text, and other features. Feature targets are automatically identified from reference images using a pre-set deep learning model, for example, by using a target detection algorithm to locate landmark objects or areas in the reference image. Environmental feature parameters include light intensity, background geometry, color distribution, and more. These parameters can be converted into multidimensional vectors by a feature encoding module and then similarity calculated.

[0123] After receiving the sixth verification request, the target security device uploads the corresponding image data according to the sixth verification request and transmits or encrypts the image data to the root server. The root server first uses the target matching algorithm to determine whether the characteristic target exists in the image. If so, the verification is directly passed. If not, the root server initiates the environmental feature analysis process to avoid misjudgment due to temporary occlusion of the characteristic target or angle changes.

[0124] It should be noted that during the initialization phase, the first registered device must collect multiple reference images and upload them to the cloud. The system then selects the image with the highest environmental stability as the baseline reference image. The environmental feature similarity comparison uses a cosine similarity algorithm, calculating the angle between the feature vectors of the target image and the reference image to determine environmental consistency. If the similarity falls below a threshold, the target security device is deemed to be located in an unauthorized area or to be at risk of tampering, resulting in a failed verification result.

[0125] As can be seen, in this embodiment of the application, by integrating the dual mechanisms of feature target matching and environmental feature verification, the accuracy of device authentication is guaranteed while improving the system's robustness to dynamic environmental changes, effectively preventing unauthorized devices from accessing the device cluster through counterfeit or replay attacks. Furthermore, compared to the verification process for the first registered device, steps such as determining the target security device model are eliminated, thereby reducing the root server's data processing load and improving the verification and registration efficiency of security devices.

[0126] By implementing the methods in the aforementioned application embodiments, it can be seen that the root server performs authentication based on the security device's verification information to obtain an authentication result, thereby improving the credibility of the authentication result. By combining device type inference with reverse data type verification, the accuracy of identifying counterfeit devices is significantly improved while reducing the false positive rate. Different detection methods are used for different types of security devices, further improving the credibility of the authentication result while ensuring the authentication efficiency of sensor-type security devices. Caching the registration information of registered security devices in a cache device reduces the amount of data processed by the root server and improves the root server's processing and transmission efficiency.

[0127] Based on the description of the above configuration method embodiment, the present application also provides a registration device 700 for security equipment, which can be a registration device running on Figure 1 A computer program (including program code) in the root server 102 shown and configured to execute Figure 2 、 Figure 3 and Figure 6 See the method shown in . Figure 7 , Figure 7 This is a schematic diagram of the structure of a registration device for a security device provided in an embodiment of the present application. The registration device 700 for a security device includes:

[0128] The receiving unit 701 is configured to receive device information sent by a target security device, where the device information includes a device identification of the target security device.

[0129] The determining unit 702 is configured to determine a target data type according to the device identifier. The target data type is one of a plurality of data types generated by the target security device during operation.

[0130] The sending unit 703 is configured to generate a first verification requirement for a target security device according to the target data type, and send the first verification requirement to the target security device, where the first verification requirement is used to instruct the target security device to send first verification data of the target data type.

[0131] The receiving unit 701 is configured to receive first verification data sent by a target security device according to a first verification requirement, and determine an identity authentication result of the target security device according to the first verification data.

[0132] The sending unit 703 is configured to generate registration information of the target security device in the Internet of Things system if the identity authentication result is verification passed, and send the registration information to the target security device.

[0133] In one possible embodiment, in terms of determining the first target data type based on the device identifier, the determining unit 702 is further specifically configured to: determine the device type and device model of the target security device based on the device identifier; determine the first target data type based on the device type and device model of the target security device; if determining the device type and device model of the target security device based on the device identifier fails, determine the inferred device type of the target security device based on the device identifier; determine a second target data type and a third target data type based on the inferred device type; wherein the second target data type is one of a plurality of data types generated by the security device of the inferred device type during operation, and the third target data type is not a data type generated by the security device of the inferred device type during operation; generate a second verification requirement based on the second target data type and the third target data type, and send the second verification requirement to the target security device, the second verification requirement being used to instruct the target security device to send second verification data of the second target data type and third verification data of the third target data type; if both the second verification data and the third verification data sent by the target security device are received simultaneously, determine the identity authentication result of the target security device as verification failure; if both the second verification data and the third verification data sent by the target security device are not received simultaneously, determine the first target data type based on the inferred device type.

[0134] In a possible embodiment, in terms of determining the identity authentication result of the target security device based on the first verification data, the determination unit 702 is further specifically used to: determine the device type and device model of the target security device based on the device identification; determine whether the first verification data is a first target data type; if the first verification data is a first target data type and the device type is a sensing device, determine a reasonable numerical range of the first verification data based on the device model; if the first verification data is within the reasonable numerical range, determine the identity authentication result as passed verification; if the first verification data is a first target data type and the device type is a camera device, determine reasonable image parameters of the first verification data based on the device model; if the first verification data is within the reasonable image parameters, determine the identity authentication result as passed verification.

[0135] In a possible embodiment, if the device type is a sensor device, the determination unit 702 is further specifically used to: if the first verification data is not the first target data type, determine that the identity authentication result is verification failure; if the first verification data does not conform to a reasonable numerical range, obtain the number of verifications of the target security device, and if the number of verifications is not greater than the preset number, generate a second verification requirement, and the second verification requirement is used to instruct the target security device to send the first verification data of the fourth target data type; send the second verification requirement to the target security device; if the number of verifications is greater than the preset number, determine that the identity authentication result is verification failure.

[0136] In a possible embodiment, if the device type is a camera device, the determination unit 702 is further specifically used to: if the data type of the first verification data is not an image data type, determine that the identity authentication result is verification failure; if the first verification data does not meet reasonable image parameters, obtain the number of verifications of the target security device, and if the number of verifications is not greater than the preset number, generate a third verification requirement, and the third verification requirement is used to instruct the target security device to send the first verification data of the image data type including at least one verification feature, the verification feature including a zoom feature or a movement feature; send the third verification requirement to the target security device; if the number of verifications is greater than the preset number, determine that the identity authentication result is verification failure.

[0137] In a possible embodiment, before determining the target data type based on the device identifier, the sending unit 703 is further specifically used to: generate query information based on the device identifier and send the query information to the cache device; wherein the cache device is used to cache the registration information of the security device, and the query information is used to request the cache device to send the registration information of the target security device; determine that the registration information sent by the cache device has not been received.

[0138] In a possible embodiment, if the identity authentication result is that the authentication is passed, after generating the registration information of the target security device in the Internet of Things system, the sending unit 703 is further specifically used to: send the registration information to the cache device so that the cache device stores the registration information of the security device.

[0139] Based on the description of the above method embodiment and device embodiment, please refer to Figure 8 , Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 The electronic device 800 shown (the electronic device 800 may be a computer device, Figure 1 The root server 102 shown includes a memory 801 , a processor 802 , a communication interface 803 , and a bus 804 . The memory 801 , the processor 802 , and the communication interface 803 are connected to each other via the bus 804 .

[0140] The memory 801 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM).

[0141] The memory 801 can store programs. When the program code stored in the memory 801 is executed by the processor 802, the processor 802 and the communication interface 803 are used to perform the various steps of the registration method for the security device of the embodiment of the present application.

[0142] The processor 802 can adopt a general central processing unit (CPU), a microcontroller, an application specific integrated circuit (ASIC), a graphics processing unit (GPU) or one or more integrated circuits to execute relevant programs to implement the functions required to be performed by the units in the electronic device 800 of the embodiment of the present application, or to execute the registration method of the security device of the method embodiment of the present application.

[0143] Processor 802 can also be an integrated circuit chip with signal processing capabilities. During implementation, the various steps of the security device registration method of the present application can be completed by hardware integrated logic circuits or software instructions within processor 802. The aforementioned processor 802 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microcontroller or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly executed by a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules can be located in storage media well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other such storage media. The storage medium is located in the memory 801, and the processor 802 reads the information in the memory 801 and combines its hardware to complete the functions required to be performed by the units included in the electronic device 800 of the embodiment of the present application, or executes the registration method of the security device of the method embodiment of the present application.

[0144] The communication interface 803 uses a transceiver device such as, but not limited to, a transceiver to implement communication between the electronic device 800 and other devices or a communication network. For example, data can be obtained through the communication interface 803.

[0145] The bus 804 may include a path for transmitting information between various components of the electronic device 800 (eg, the memory 801 , the processor 802 , and the communication interface 803 ).

[0146] It should be noted that although Figure 8The electronic device 800 shown only shows a memory 801, a processor 802, and a communication interface 803. However, in the specific implementation process, those skilled in the art should understand that the electronic device 800 also includes other devices necessary for normal operation. At the same time, according to specific needs, those skilled in the art should understand that the electronic device 800 may also include hardware devices that implement other additional functions. In addition, those skilled in the art should understand that the electronic device 800 may also include only the devices necessary to implement the embodiments of the present application, and does not necessarily include Figure 8 All devices shown in .

[0147] An embodiment of the present application further provides a chip, which includes a processor and a data interface. The processor reads instructions stored in a memory through the data interface to implement the security device registration method.

[0148] Optionally, as an implementation method, the chip may further include a memory, in which instructions are stored, and the processor is used to execute the instructions stored in the memory. When the instructions are executed, the processor is used to execute the registration method of the security device.

[0149] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is executed on a computer or a processor, the computer or processor executes one or more steps in any of the above methods.

[0150] The present application also provides a computer program product comprising instructions, which, when executed on a computer or processor, causes the computer or processor to execute one or more steps in any of the above methods.

[0151] Those skilled in the art will appreciate that the functions described in conjunction with the various illustrative logic blocks, modules, and algorithm steps disclosed herein can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions described in the various illustrative logic blocks, modules, and steps can be stored or transmitted as one or more instructions or codes on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to tangible media, such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one place to another (e.g., based on a communication protocol). In this manner, computer-readable media can generally correspond to (1) non-transitory tangible computer-readable storage media, or (2) communication media, such as signals or carrier waves. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in this application. A computer program product may include computer-readable media.

[0152] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Furthermore, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are actually directed to non-transitory tangible storage media. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and Blu-ray disc, where disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0153] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microcontrollers, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the term "processor," as used herein, may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described by the various illustrative logical blocks, modules, and steps described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. Furthermore, the techniques may be fully implemented in one or more circuits or logic elements.

[0154] The techniques of this application can be implemented in a variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or a set of ICs (e.g., a chipset). Various components, modules, or units are described herein to emphasize functional aspects of devices for performing the disclosed techniques, but they do not necessarily require implementation by different hardware units. In fact, as described above, the various units can be combined in coded hardware units in conjunction with appropriate software and / or firmware, or provided by interoperating hardware units (including one or more processors as described above).

[0155] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems, devices and units can refer to the specific descriptions of the corresponding steps in the aforementioned method embodiments and will not be repeated here.

[0156] It should be understood that, in the description of this application, unless otherwise specified, " / " indicates an "or" relationship between the preceding and following objects. For example, A / B can mean A or B, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise specified, "plurality" means two or more. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, "at least one of a, b, or c" can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural. Furthermore, to facilitate the description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish between identical or similar items with substantially the same function and effect. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or order of execution, and do not necessarily imply differences. At the same time, in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0157] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The mutual coupling, direct coupling, or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, and can be electrical, mechanical or other forms.

[0158] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0159] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium accessible by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic medium such as a floppy disk, a hard disk, a magnetic tape, a magnetic disk, or an optical medium such as a digital versatile disc (DVD), or a semiconductor medium such as a solid state disk (SSD).

[0160] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

[0161] The device embodiments described above are merely illustrative, wherein the units and modules described as separate components may or may not be physically separate. Furthermore, some or all of the units and modules may be selected based on actual needs to achieve the objectives of the present embodiment. Those skilled in the art can understand and implement the present invention without inventive effort.

[0162] The above is only a specific implementation method of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A registration method for security equipment, characterized in that: Applied to a root server, the method includes: Receiving device information sent by a target security device, wherein the device information includes a device identifier of the target security device; determining a first target data type according to the device identifier, where the first target data type is one of multiple data types generated by the target security device during operation; generating a first verification requirement for the target security device according to the first target data type, and sending the first verification requirement to the target security device, where the first verification requirement is used to instruct the target security device to send first verification data of the first target data type; receiving first verification data sent by the target security device in accordance with the first verification requirement, and determining an identity authentication result of the target security device based on the first verification data; If the identity authentication result is that the authentication is passed, registration information of the target security device in the Internet of Things system is generated and the registration information is sent to the target security device.

2. The method according to claim 1, characterized in that The determining the first target data type according to the device identification includes: Determine the device type and device model of the target security device according to the device identification; Determining the first target data type according to the device type and device model of the target security device; If determining the device type and device model of the target security device according to the device identification fails, determining the estimated device type of the target security device according to the device identification; determining a second target data type and a third target data type according to the presumed device type; wherein the second target data type is one of a plurality of data types generated by the security device of the presumed device type during operation, and the third target data type is not a data type generated by the security device of the presumed device type during operation; generating a second verification requirement according to the second target data type and the third target data type, and sending the second verification requirement to the target security device, wherein the second verification requirement is used to instruct the target security device to send second verification data of the second target data type and third verification data of the third target data type; If the second verification data and the third verification data sent by the target security device are received at the same time, determining that the identity authentication result of the target security device is verification failure; If the second verification data and the third verification data sent by the target security device are not received at the same time, the first target data type is determined according to the estimated device type.

3. The method according to claim 1, characterized in that Determining the identity authentication result of the target security device according to the first verification data includes: Determine the device type and device model of the target security device according to the device identification; determining whether the first verification data is of the first target data type; If the first verification data is of the first target data type and the device type is a sensor device, determining a reasonable value range of the first verification data according to the device model; If the first verification data is within the reasonable value range, determining that the identity authentication result is verification passed; If the first verification data is of the first target data type and the device type is a camera device, determining reasonable image parameters of the first verification data according to the device model; If the first verification data meets the reasonable image parameters, the identity authentication result is determined to be verification passed.

4. The method according to claim 3, characterized in that If the device type is a sensor device, the method further includes: If the first verification data is not of the first target data type, determining that the identity authentication result is verification failure; If the first verification data does not conform to the reasonable value range, obtaining the number of verifications of the target security device, and if the number of verifications is not greater than a preset number, generating a second verification requirement, wherein the second verification requirement is used to instruct the target security device to send the first verification data of a fourth target data type; Sending the second verification request to the target security device; If the number of verifications is greater than a preset number, the identity authentication result is determined to be verification failure.

5. The method according to claim 3, characterized in that If the device type is a camera device, the method further includes: If the data type of the first verification data is not an image data type, determining that the identity authentication result is verification failure; If the first verification data does not meet the reasonable image parameters, obtaining the number of verifications of the target security device, and if the number of verifications is not greater than a preset number, generating a third verification requirement, wherein the third verification requirement is used to instruct the target security device to send first verification data of an image data type including at least one verification feature, wherein the verification feature includes a zoom feature or a movement feature; Sending the third verification request to the target security device; If the number of verifications is greater than a preset number, the identity authentication result is determined to be verification failure.

6. The method according to any one of claims 1 to 5, characterized in that Before determining the target data type according to the device identification, the method further includes: Generate query information according to the device identifier and send the query information to a cache device; wherein the cache device is used to cache the registration information of the security device, and the query information is used to request the cache device to send the registration information of the target security device; It is determined that the registration information sent by the cache device is not received.

7. The method according to claim 6, characterized in that After generating registration information of the target security device in the Internet of Things system if the identity authentication result is that the authentication is passed, the method further includes: The registration information is sent to the cache device, so that the cache device stores the registration information of the security device.

8. A registration device for security equipment, characterized in that: The registration device of the security device is used to execute the registration method of the security device, and the registration device of the security device includes: A receiving unit, configured to receive device information sent by a target security device, wherein the device information includes a device identifier of the target security device; a determining unit, configured to determine a target data type according to the device identifier, wherein the target data type is one of multiple data types generated by the target security device during operation; a sending unit, configured to generate a first verification requirement for the target security device according to the target data type, and send the first verification requirement to the target security device, wherein the first verification requirement is used to instruct the target security device to send first verification data of the target data type; a receiving unit, configured to receive first verification data sent by the target security device in accordance with the first verification requirement, and determine an identity authentication result of the target security device based on the first verification data; A sending unit is configured to generate registration information of the target security device in the Internet of Things system if the identity authentication result is that the authentication is passed, and send the registration information to the target security device.

9. An electronic device, characterized in that: The method comprises a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for executing the steps in the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program for electronic data exchange, wherein the computer program enables a computer to execute the method according to any one of claims 1 to 7.

Images