Security management method, system and device of Internet of Things device and storage medium

Abstract

The invention relates to the technical field of Internet of Things, and particularly provides a security management method, system and device of Internet of Things equipment and a storage medium, and the method comprises the steps: receiving the authentication information of the Internet of Things equipment; according to the authentication information, determining whether the Internet of Things equipment is trusted equipment or not to an authentication platform; the Internet of Things device is confirmed to be a trusted device, the trusted device is granted a permission identifier with timeliness, and the permission identifier is used for confirming that service data uploaded by the trusted device is trusted; acquiring operation data of the trusted equipment, confirming an operation state of the trusted equipment according to the operation data, and if the operation state is abnormal, cancelling the permission identifier; the authentication information comprises an authentication certificate signed and issued to the Internet of Things equipment by an authentication platform. According to the invention, lightweight safety management of Internet of Things equipment and dynamic isolation of abnormal equipment are realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of Internet of Things, and specifically relates to a security management method, system, device and storage medium for Internet of Things devices. Background Art

[0002] IoT device security authentication and permission management are core areas for ensuring data credibility. The core challenge lies in coping with dynamic operating environments and complex attack scenarios. With the exponential growth of IoT devices, traditional security architectures based on fixed trust relationships are facing new threats such as hardware tampering, permission abuse, and zero-day attacks. There is an urgent need to build a full-lifecycle trusted verification system that covers the hardware layer to the application layer.

[0003] The current mainstream technical approach is: a static authentication mechanism based on PKI (such as the IEEE 802.1AR standard), which implements identity binding through device digital certificates; a permission revocation mechanism with manual intervention, and relies on periodic policy updates to achieve exception isolation.

[0004] Bidirectional authentication mechanisms based on the PKI system suffer from issues such as high certificate management costs and redundant key lengths, making them difficult to adapt to resource-constrained industrial devices. Furthermore, mechanisms requiring manual intervention to revoke permissions are time-consuming and fail to isolate exceptions in a timely manner, leading to security vulnerabilities. Summary of the Invention

[0005] In view of the above-mentioned deficiencies in the prior art, the present invention provides a security management method, system, device and storage medium for Internet of Things devices to solve the above-mentioned technical problems.

[0006] In a first aspect, the present invention provides a security management method for an Internet of Things device, which is used on a business platform and includes: Receive authentication information from IoT devices; Confirming with the authentication platform whether the IoT device is a trusted device based on the authentication information; Confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, which is used to confirm that the business data uploaded by the trusted device is credible; Acquire operation data of the trusted device, confirm the operation status of the trusted device based on the operation data, and revoke the permission identifier if the operation status is abnormal; The authentication information includes an authentication certificate issued by an authentication platform to the IoT device.

[0007] In an optional embodiment, the method further comprises: The IoT device encrypts its own device information and uploads it to the authentication platform through a trusted gateway. The device information includes the device's unique identification code, hardware information, and software component information. The IoT device saves the authentication certificate issued by the authentication platform based on the device information to the trusted control module.

[0008] In an optional embodiment, the method further comprises: The authentication platform decrypts the received encrypted file and obtains the device information of the IoT device; The authentication platform audits the device information according to pre-stored audit rules, and generates an authentication certificate if the device information passes the audit; The authentication platform calculates a hash value of a data pair consisting of the device unique identification code and the authentication certificate, and stores the hash value locally; The authentication platform sends the authentication certificate to the IoT device.

[0009] In an optional embodiment, the authentication information includes: The hash value of the data pair consisting of the unique device identification code and authentication certificate of the IoT device.

[0010] In an optional embodiment, confirming with an authentication platform whether the IoT device is a trusted device based on the authentication information includes: The hash value is sent to the authentication platform, and the authentication platform queries whether there is an identical hash value locally. If the identical hash value exists, a prompt message indicating successful authentication is returned; otherwise, a prompt message indicating failed authentication is returned; Receive the prompt information returned by the authentication platform. If the prompt information indicates that the authentication is successful, the IoT device is determined to be credible. If the prompt information indicates that the authentication fails, the IoT device is determined to be untrustworthy.

[0011] In an optional embodiment, confirming that the IoT device is a trusted device and granting the trusted device a time-sensitive permission identifier includes: Assign permissions based on the device type of the trusted device; Generate a pair of public and private keys using a trusted chip, and save the private key to the trusted chip; Send the public key to the trusted device and create a mapping table between the public key and the trusted device ID; Generate a permission code based on the assigned permission, and combine the permission code with a set of random numbers to form a permission identifier; Binding the permission identifier to the IP address of the trusted device and storing the result in an identifier storage list; Using a monitoring thread to monitor the storage time of the permission identifier in the identifier storage list, and deleting the permission identifier and the IP address of the trusted device if the storage time reaches a set time threshold; The authority identifier is encrypted using a private key, and the encrypted authority identifier is sent to the trusted device, so that the trusted device decrypts and stores the authority identifier and carries the authority identifier encrypted using the public key each time a request is sent.

[0012] In an optional embodiment, obtaining operation data of the trusted device, confirming the operation status of the trusted device based on the operation data, and revoking the permission identifier if the operation status is abnormal, includes: Regularly obtain operating data of trusted devices, including hardware temperature and resource utilization of trusted devices; generating a temperature curve and a resource occupancy curve based on the regularly acquired operating data; Monitor the frequency of requests sent by the trusted device and whether the requests are successfully responded to, and count the number of requests that fail to respond; Comparing the temperature curve with a preset temperature baseline to obtain a high-temperature curve segment exceeding the temperature baseline, and determining that the trusted device is abnormal if a time period corresponding to the high-temperature curve segment exceeds a set high-temperature time threshold; Comparing the resource utilization rate curve with a preset resource utilization rate baseline to obtain an abnormal curve segment exceeding the resource utilization rate baseline, and determining that an abnormality exists in the trusted device if a time period corresponding to the abnormal curve segment exceeds a set time threshold; Counting fluctuation values of the frequency of sending requests, and determining that an abnormality exists in the trusted device if the fluctuation value exceeds a set fluctuation threshold; If the number of failed response requests reaches a set failure threshold, it is determined that the trusted device has an abnormality.

[0013] In a second aspect, the present invention provides a security management system for IoT devices, which is used in a business platform and includes: A receiving module, used to receive authentication information of an IoT device; An authentication module, configured to confirm with an authentication platform whether the IoT device is a trusted device based on the authentication information; An authorization module is used to confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, where the permission identifier is used to confirm that the business data uploaded by the trusted device is credible; A monitoring module, configured to obtain operating data of the trusted device, confirm the operating status of the trusted device based on the operating data, and revoke the permission identifier if the operating status is abnormal; The authentication information includes an authentication certificate issued by an authentication platform to the IoT device.

[0014] According to a third aspect, a device is provided, comprising: Memory, used to store security management programs for IoT devices; A processor is used to implement the steps of the security management method for the Internet of Things device provided in the first aspect when executing the security management program of the Internet of Things device.

[0015] In a fourth aspect, a computer-readable storage medium is provided, on which a security management program for an Internet of Things device is stored. When the security management program for the Internet of Things device is executed by a processor, the steps of the security management method for the Internet of Things device provided in the first aspect are implemented.

[0016] The beneficial effects of the present invention are that the security management method, system, device and storage medium for IoT devices provided by the present invention realize lightweight device authentication by setting up an authentication platform with a trusted gateway and adopting authentication logic based on device information. At the same time, by issuing a time-sensitive permission identifier to the authenticated device, the device is managed based on the permission identifier, thereby avoiding frequent interactions with the authentication platform. At the same time, the time-sensitive setting avoids security vulnerabilities caused by the theft of the permission identifier. On this basis, the status of the authenticated device is monitored, and the permission identifier is dynamically revoked according to the status monitoring results, thereby realizing timely isolation of abnormal devices. The present invention realizes lightweight security management of IoT devices and dynamic isolation of abnormal devices.

[0017] In addition, the present invention has a reliable design principle, a simple structure and a very broad application prospect. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present invention 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, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 is a schematic flow chart of a method according to an embodiment of the present invention.

[0020] Figure 2 It is a schematic diagram of the basic architecture of a method according to an embodiment of the present invention.

[0021] Figure 3 The figure is a schematic flow chart of a method for issuing a certificate according to an embodiment of the present invention.

[0022] Figure 4 The figure is a schematic flow chart of a method for producing a certificate according to an embodiment of the present invention.

[0023] Figure 5 2 is a schematic diagram of an application of a method according to an embodiment of the present invention.

[0024] Figure 6 It is an application flow chart of a method according to an embodiment of the present invention.

[0025] Figure 7 FIG. 4 is a schematic block diagram of a system according to an embodiment of the present invention.

[0026] Figure 8 A schematic structural diagram of a device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. 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 making creative efforts should fall within the scope of protection of the present invention.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0029] The security management method for an Internet of Things device provided by an embodiment of the present invention is executed by a computer device. Accordingly, the security management system for the Internet of Things device runs in the computer device.

[0030] Figure 1 is a schematic flow chart of a method according to an embodiment of the present invention. Figure 1 The execution entity can be a security management system for an IoT device. Depending on different needs, the order of the steps in the flowchart can be changed, and some steps can be omitted.

[0031] like Figure 1 As shown, the method is applied to the business platform, and the method includes: S1. Receive authentication information from IoT devices; S2. Confirm to the authentication platform whether the IoT device is a trusted device based on the authentication information; S3. Confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, which is used to confirm that the business data uploaded by the trusted device is credible; S4 obtains the operating data of the trusted device, confirms the operating status of the trusted device based on the operating data, and revokes the permission identification if the operating status is abnormal; The authentication information includes an authentication certificate issued by an authentication platform to the IoT device.

[0032] Please refer to Figure 2 The method is implemented by the device data service platform. The device data service platform is used to obtain and process the service data of IoT devices. The service platform obtains authentication information from the secure and trusted device management center (referred to as the authentication platform) and performs authentication and security management on IoT devices.

[0033] The Secure and Trusted Device Management Center is responsible for the full lifecycle management of trusted device security and for exchanging device security status information with the data service platform. It features built-in front-end, back-end, certificate, and authentication modules. The front-end module provides a visual interface, supports online entry of device information, and displays basic device security information in real time. The back-end module provides access control, full lifecycle management, and access control based on different users, devices, and data platforms. The certificate module manages lightweight digital certificates for devices, and the authentication module handles device authentication and certificate issuance.

[0034] The trusted device side includes a trusted gateway and trusted direct-connect devices. Its built-in TPM / TPCM module is responsible for storing certificates, extracting identification codes, and performing real-time security measurements to ensure device security and reliability. The trusted gateway connects terminal devices to the management center, enabling device identity authentication, encrypted data transmission, and security measurements. Trusted direct-connect devices directly perform identity authentication and interact with the device data service platform.

[0035] Please refer to Figure 3 ,The process of IoT device authentication from the authentication platform includes: The IoT device encrypts its own device information and uploads it to the authentication platform through a trusted gateway. The device information includes the device's unique identification code, hardware information, and software component information; the IoT device saves the authentication certificate issued by the authentication platform based on the device information to the trusted control module.

[0036] The authentication platform decrypts the received encrypted file to obtain the device information of the IoT device; the authentication platform audits the device information according to pre-stored audit rules, and generates an authentication certificate if the device information passes the audit; the authentication platform calculates the hash value of the data pair consisting of the device's unique identification code and the authentication certificate, and stores the hash value locally; the authentication platform sends the authentication certificate to the IoT device.

[0037] Please refer to Figure 4 , the certificate generation methods include: The digital certificate is generated by the Secure and Trusted Device Management Center without going through a CA organization. It generates a lightweight digital certificate (including public key, private key, and encryption key) based on the device's unique identification code, device information, encryption algorithm, and signature algorithm.

[0038] Compared with the traditional centralized CA certificate management system, the improvements of lightweight certificate management are: built based on the unique identification code of the device to eliminate the risk of CA single point failure; support encryption and signature algorithm expansion, support dynamic switching between national encryption SM2 / SM4 and international RSA / AES / DES algorithms to meet different levels of security requirements; the generated certificates include not only public keys and private keys, but also encryption keys, providing more comprehensive key management functions; after the user logs in to the management center, he can independently select the algorithm and generate the corresponding certificate, which improves operational autonomy; the management center integrates lightweight certificate generation, issuance, storage, and deletion, which improves certificate management efficiency.

[0039] The process of the management center confirming that the device is trustworthy: First, the device sends a connection request with the device ID to the secure and trusted device management center. The management center parses the request and returns a heartbeat response, while updating the connection status of the device in the management center. After the device is successfully connected, the management center "issues" it and sends a lightweight certificate to the device. The device stores the certificate in the TPM / TPCM module and feeds back the issuance result to the management center. After receiving the response, the management center updates the certificate status of the corresponding device. For devices with issued certificates, the device actively initiates an authentication request to the management center. The request body carries information such as the device ID, public key, private key, and encryption key. The management center parses the authentication request, queries the database for device certificate information based on the device ID, decodes the public key in the request body based on the encryption algorithm, signature algorithm, etc., and performs signature verification. It compares the request body with other information about the device in the database to obtain the authentication result; it returns the authentication response carrying the authentication result to the device end, and updates the authentication status of the device in the management center.

[0040] The authentication status is divided into unauthenticated, successful, and failed. The default status is unauthenticated. If the authentication fails, the device is required to request or re-issue a certificate. If the authentication succeeds, it means the device is secure and trustworthy.

[0041] In an embodiment of the present invention, based on step S1, a possible embodiment will be given below to illustrate its specific implementation scheme in a non-limiting manner.

[0042] Receive authentication information of the IoT device, where the authentication information includes a hash value of a data pair consisting of a unique device identification code of the IoT device and an authentication certificate.

[0043] In a specific example, the device ID uses the UUID format, the authentication certificate uses a simplified X.509 certificate structure, and the hash value is generated through the following steps: Concatenate the Device ID and Certificate contents in order (separated by newline characters); Use SHA-256 algorithm for hash calculation; The results are presented in the format of "algorithm name:hexadecimal value".

[0044] The following is an example of IoT device authentication information: Device ID: a1b2c3d4-e5f6-7890-1234-56789abcdef0.

[0045] Certificate: { "version": "X.509v3", "serial_number": "00:11:22:33:44:55:66:77", "issuer": "IoT CA", "subject": "Device:a1b2c3d4-e5f6-7890-1234-56789abcdef0", "validity": { "not_before": "2025-03-19T00:00:00Z", "not_after": "2026-03-18T23:59:59Z"}, "public_key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...", "signature": "H4sIAAAAAAAEA...", "exs": [tension]}.

[0046] Data pair hash value (Hash): sha256:0b1a2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a.

[0047] In an embodiment of the present invention, based on step S2, a possible embodiment will be given below to illustrate its specific implementation scheme in a non-limiting manner.

[0048] S201. The hash value is sent to the authentication platform. The authentication platform queries whether there is an identical hash value locally. If there is an identical hash value, a prompt message indicating successful authentication is returned. Otherwise, a prompt message indicating failed authentication is returned.

[0049] To ensure the security and reliability of data transmission, communication protocols based on TLS (Transport Layer Security), such as HTTPS, are often used. TLS encrypts transmitted data, preventing it from being eavesdropped or tampered with during transmission.

[0050] For resource-constrained IoT devices, you can also consider using CoAP (Constrained Application Protocol), which is a lightweight protocol designed specifically for IoT devices and performs well in low-power, low-bandwidth network environments.

[0051] The hash value sent is usually transmitted in the form of a string, and for ease of parsing and processing, it is encapsulated in a specific data format, such as JSON or XML.

[0052] For example, when using JSON format, the data is as follows: { "hash": "sha256:0b1a2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a", "device_id": "a1b2c3d4-e5f6-7890-1234-56789abcdef0"}.

[0053] The authentication platform compares the received hash value with the locally stored hash value. To improve query efficiency, database indexing techniques are often used. For example, in a relational database, an index can be created for the hash value field, allowing matching records to be quickly located during queries.

[0054] For large-scale authentication data, distributed storage and query technologies can also be used, such as distributed hash tables (DHT) or distributed databases, to improve the scalability and performance of the system.

[0055] S202. Receive the prompt information returned by the authentication platform. If the prompt information indicates that the authentication is successful, the IoT device is determined to be credible. If the prompt information indicates that the authentication fails, the IoT device is determined to be untrustworthy.

[0056] The prompt information returned by the authentication platform will also use a unified data format, such as JSON or XML.

[0057] For example, when using JSON format, the response for successful authentication is: { "status": "success", "message": "Device authentication successful"}; Response to authentication failure: { "status": "failure", "message": "No matching hash value found"}.

[0058] After receiving the response from the authentication platform, the IoT device will parse the response data and determine the authentication result based on the value of the status field.

[0059] If the status is success, the IoT device is considered trustworthy and can be allowed to interact with other systems; if the status is failure, the IoT device is considered untrustworthy and corresponding measures need to be taken, such as rejecting its connection request and recording abnormal logs.

[0060] In an embodiment of the present invention, based on step S3, a possible embodiment will be given below to illustrate its specific implementation scheme in a non-limiting manner.

[0061] S301. Allocate permissions based on the device type of the trusted device.

[0062] During the initial stages of system design, it's important to carefully define the set of permissions each IoT device might possess, based on its distinct functions, usage scenarios, and potential security risks. This can involve a professional technical team, security experts, and business personnel to ensure comprehensive and appropriate permission definitions. Furthermore, detailed documentation should be developed for each permission, clarifying its purpose and scope of application.

[0063] Comprehensively and meticulously categorize IoT devices. Besides considering common functional factors, consider multiple factors, including the device's usage environment (e.g., industrial sites, home environments, outdoor locations), security level requirements (e.g., highly sensitive devices, standard devices), and communication methods (e.g., Wi-Fi, Bluetooth, ZigBee). Establish a hierarchical device classification database. In addition to recording device types and corresponding permission scopes, the database can also include information such as the device's manufacturer, model, and supported protocols.

[0064] A hybrid strategy combining static and dynamic allocation is employed. Static allocation is fundamental, pre-setting basic permissions based on device type. These permissions are essential for the device's proper operation. Dynamic allocation allows for flexible adjustments based on factors such as device usage, user roles and operational history, and the system's security posture. A permission allocation rules engine can be established to automatically adjust permissions based on pre-set rules and real-time data.

[0065] For example, for a smart thermostat, the permission set can be defined as: temperature adjustment (allowing users to set the target temperature), mode switching (such as switching between cooling, heating, and energy-saving modes), and data viewing (viewing historical temperature data). Smart meters are classified as industrial-grade metering equipment, used in power systems, with high security requirements, and using power line carrier communication. The corresponding permission range includes data reading (reading data such as power, voltage, and current) and parameter setting (setting the meter's metering parameters). All smart cameras have video stream viewing permissions by default (statically assigned). When an emergency security incident occurs, the system automatically assigns video storage and playback permissions (dynamically assigned) to the smart cameras used by security personnel.

[0066] S302. Generate a pair of public and private keys using a trusted chip, and save the private key to the trusted chip.

[0067] When selecting a trusted chip, a comprehensive evaluation is essential. Besides considering factors like security, reliability, performance, compatibility, and cost, the chip manufacturer's reputation, technical support capabilities, and compliance with relevant security standards and regulations should also be considered. You can test and compare various chips on the market to select the one that best suits your system needs.

[0068] Prioritize asymmetric encryption algorithms that comply with international standards and industry specifications, such as RSA or ECC. For resource-constrained IoT devices, the ECC algorithm is a superior choice. When generating keys, use a high-quality entropy source, such as a hardware random number generator, to ensure randomness and unpredictability. Furthermore, the key generation process should be rigorously monitored and recorded for audit and traceability.

[0069] Trusted chips should provide a dedicated, protected storage area for private keys. A multi-layered encryption mechanism should be used to protect private keys. In addition to the hardware encryption engine, software encryption algorithms can also be used. Strict access control policies should be implemented to ensure that only authorized users or programs with multi-factor authentication (such as passwords, fingerprint recognition, and digital certificates) can access private keys.

[0070] For example, a smart home system selected a trusted chip based on a TEE. This chip offers high security, low power consumption, and excellent compatibility. Certified to international security standards, it meets the system's requirements for secure key storage. When generating a key pair for a smart sensor device, an ECC algorithm with a 256-bit key length is used. A hardware random number generator provides entropy to ensure sufficient randomness. The generated private key is stored in a secure area of the trusted chip and encrypted using the AES-256 algorithm. The private key can only be retrieved from the chip after dual authentication via fingerprint recognition and password entry.

[0071] S303. Send the public key to the trusted device and create a mapping table between the public key and the trusted device ID.

[0072] During public key transmission, data is encrypted and authenticated using secure communication protocols (such as TLS 1.3). Prior to transmission, devices undergo rigorous authentication using multi-factor authentication methods, such as the device's hardware serial number and pre-shared key. Furthermore, digital certificates are used to verify the identities of both communicating parties, ensuring the integrity and authenticity of public key transmission.

[0073] Establish a clearly structured and easily manageable mapping table between public keys and trusted device IDs. This mapping table can be stored in a relational database (such as MySQL, PostgreSQL) or a distributed database (such as Cassandra, MongoDB). When establishing the mapping table, perform strict format validation and integrity checks on the data to ensure accuracy and consistency.

[0074] Establish an automated mapping table update and maintenance mechanism. The system automatically updates the mapping table when new devices are added, existing devices are removed, or public keys are updated. Set up regular data backup and recovery strategies to ensure rapid recovery in the event of data loss or corruption. Additionally, implement strict access control on the mapping table to prevent unauthorized modification.

[0075] For example, when sending a public key to a smart door lock, TLS 1.3 is used for encrypted transmission. Before transmission, the device is authenticated using its hardware serial number and pre-shared key, and digital certificates are used to verify the identities of both communicating parties. A table named device_public_key_mapping is created in the MySQL database, containing fields such as device_id, public_key, and timestamp. When inserting new records, the format and integrity of device_id and public_key are verified. When a smart camera's public key needs to be updated, the system automatically updates the corresponding record in the mapping table. The mapping table is backed up every night and stored in an off-site data center. Only system administrators and authorized security personnel can access and modify the mapping table.

[0076] S304. Generate a permission code according to the assigned permission, and combine the permission code and a set of random numbers to form a permission identifier.

[0077] Establish a set of permission coding rules. Use a hierarchical coding approach to encode permission categories, functions, and specific operations. Also, assign a unique identifier to each permission code to facilitate subsequent management and query.

[0078] Generate random numbers using a secure random number generator, such as the / dev / random or / dev / urandom devices provided by the operating system, or a hardware random number generator. The length and format of the random number should be appropriately configured based on the system's security requirements to ensure sufficient randomness and unpredictability.

[0079] When combining the permission code and the random number, you can use a cryptographic hash algorithm (such as SHA-256) to process the combined string and generate a fixed-length hash value as the permission identifier. This can improve the security and uniqueness of the permission identifier.

[0080] For example, for smart lighting devices, the permission encoding rules are as follows: the first level of encoding represents the device type (IL for smart lighting), the second level of encoding represents the function (S for switch control, B for brightness adjustment), and the third level of encoding represents the specific operation (ON for turn on, OFF for turn off). For example, the code for the switch on permission is IL_S_ON.

[0081] Use the / dev / urandom device to generate a 16-bit random number, such as 23a4b5c6d7e8f901.

[0082] After combining the permission code IL_S_ON and the random number 23a4b5c6d7e8f901 and hashing them using the SHA-256 algorithm, the generated permission identifier is 5f8d6a7b9c0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a.

[0083] S305: Bind the authority identifier to the IP address of the trusted device and store them in an identifier storage list.

[0084] Obtain the IP address of a trusted device through various network protocols (such as DHCP, ARP, and ICMP). After obtaining the IP address, verify its legitimacy and authenticity, checking whether it complies with IP address specifications and matches the device's MAC address. For devices with dynamic IP addresses, establish a real-time monitoring mechanism to promptly update IP address information.

[0085] Bind the permission identifier to the IP address of the trusted device to establish a one-to-one mapping relationship. When establishing the binding relationship, record the binding timestamp and validity period for subsequent management and verification. At the same time, the binding relationship is encrypted and stored to prevent data leakage.

[0086] Choose an appropriate storage method to manage the identity storage list, such as Redis caching or a distributed file system. The storage list should have efficient query and update capabilities, supporting fast permission verification and binding relationship updates. Regularly clean up the storage list and delete expired binding relationships.

[0087] For example, a smart speaker obtains the IP address 192.168.1.100 through DHCP. Use ARP to verify that the IP address matches the device's MAC address to ensure its authenticity. Bind the permission identifier 5f8d6a7b9c0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a to the IP address 192.168.1.100, recording the binding time as 2025-03-19 10:00:00, with a validity period of 24 hours. Use Redis cache to store the identifier list, setting the key to permission_identifier:192.168.1.100 and the value to the permission identifier and related information. Clear the Redis cache every morning to delete expired bindings.

[0088] S306. Use a monitoring thread to monitor the storage time of the permission identifier in the identifier storage list. If the storage time reaches a set time threshold, delete the permission identifier and the IP address of the trusted device.

[0089] Design an efficient and stable monitoring thread. This monitoring thread can use multithreading or asynchronous programming to improve monitoring efficiency. Regularly (e.g., every minute) check the storage time of each permission token in the token storage list to ensure timely detection of expired permission tokens.

[0090] Set appropriate time thresholds based on the system's security policies, business requirements, and device types. For high-security permissions, the time threshold can be shorter (e.g., 1 hour); for low-security permissions, the time threshold can be longer (e.g., 24 hours). Administrators can also dynamically adjust the time threshold based on actual circumstances.

[0091] When the storage time of a permission identifier reaches the set time threshold, the monitoring thread promptly deletes the IP binding between the permission identifier and the trusted device. Simultaneously, a notification is sent to relevant system components (such as the authentication platform and device management system) to update the system's permission status. Detailed logging is maintained throughout the expiration process for audit and traceability.

[0092] For example, use Python's threading module to create a monitoring thread that checks the list of stored identifiers in the Redis cache every minute. For smart door lock unlocking permissions, the time threshold is set to 30 minutes; for smart camera video stream viewing permissions, the time threshold is set to 2 hours. When a smart door lock unlocking permission expires, the monitoring thread deletes the corresponding binding in the Redis cache and sends a notification to the authentication platform and device management system. At the same time, the expiration processing record is written to the log file, recording information such as the expiration time, permission identifier, and device IP address.

[0093] S307. Encrypt the permission identifier using the private key and send the encrypted permission identifier to the trusted device, so that the trusted device decrypts and stores the permission identifier and carries the permission identifier encrypted using the public key each time it sends a request.

[0094] Use hybrid encryption: First, encrypt the permission identifier with a symmetric encryption algorithm (such as AES) to improve encryption efficiency. Then, encrypt the symmetric encryption key with the private key to ensure key security. Choose encryption algorithms that comply with international standards and industry specifications, such as AES-256 and RSA-2048.

[0095] The permission token is encrypted using the AES-256 algorithm to generate an encrypted permission token and a symmetric encryption key. The symmetric encryption key is then encrypted using the private key. The encrypted permission token and the encrypted symmetric encryption key are then sent to the trusted device.

[0096] After receiving the encrypted permission identifier and the encrypted symmetric encryption key, the trusted device uses the public key to decrypt the symmetric encryption key. It then uses the decrypted symmetric encryption key to decrypt the permission identifier. The decrypted permission identifier is stored in a secure storage area on the device, such as a Trusted Execution Environment (TEE).

[0097] Each time a request is sent, the trusted device encrypts the permission identifier using the public key and sends the encrypted permission identifier to the business platform as part of the request. After receiving the request, the business platform decrypts the encrypted permission identifier using the private key and verifies its legitimacy and validity. Only requests that pass verification can be processed.

[0098] For example, the permission identifier 5f8d6a7b9c0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a is encrypted using the AES-256 algorithm and the symmetric encryption key is encrypted using the RSA-2048 algorithm. On the service platform, a 256-bit AES key is generated and used to encrypt the permission identifier, obtaining the encrypted permission identifier, encrypted_permission_identifier. The AES key is then encrypted using the private key, obtaining the encrypted AES key, encrypted_aes_key. The encrypted_permission_identifier and encrypted_aes_key are sent together to the smart camera device. After receiving the encrypted_permission_identifier and encrypted_aes_key, the smart camera device decrypts the encrypted_aes_key using the public key to obtain the AES key. The encrypted_permission_identifier is then decrypted using the AES key to obtain the original permission identifier. The decrypted permission identifier is stored in the device's TEE. When the smart camera sends a video stream request, it encrypts the permission identifier using the public key and adds it to the request. After receiving the request, the business platform decrypts the encrypted permission identifier using the private key to verify its legitimacy and validity. If verification passes, the video stream is allowed; otherwise, the request is rejected.

[0099] In an embodiment of the present invention, based on step S4, a possible embodiment will be given below to illustrate its specific implementation scheme in a non-limiting manner.

[0100] S401. Regularly obtain operating data of the trusted device, where the operating data includes the hardware temperature and resource occupancy rate of the trusted device.

[0101] For example, an industrial robot in a smart factory collects data every 10 seconds. The device's internal temperature sensor reads a temperature value of 45,000 (in millidegrees Celsius, which converts to 45°C) from the " / sys / class / hwmon / hwmon0 / temp1_input" file. Using the " / proc / stat" file, calculations show that over the past 10 seconds, the CPU's user-mode run time increased by 100 seconds, the kernel-mode run time increased by 50 seconds, and the total run time increased by 200 seconds. The CPU utilization is calculated as (100 + 50) / 200 * 100% = 75%. The " / proc / meminfo" file shows that the total memory is 1024MB and the used memory is 600MB, resulting in a memory utilization of 600 / 1024 * 100% ≈ 58.6%. Regarding disk I / O, the " / sys / block / sda / stat" file shows that the number of read operations increased by 50 and the number of write operations increased by 30 during the 10 seconds. This data is stored in InfluxDB in the following format: {"device_id": "industrial_robot_01", "timestamp": "2025 - 03 - 19T10:00:10Z", "temperature": 45, "cpu_usage": 75, "memory_usage": 58.6, "disk_read_ops": 50, "disk_write_ops": 30}.

[0102] S402. Generate a temperature curve and a resource occupancy rate curve according to the regularly acquired operation data.

[0103] Curve type selection: Temperature Curve: Use a line graph to display temperature changes over time, visually demonstrating temperature fluctuation trends. To facilitate identification of anomalies, the graph marks the preset temperature baseline and possible temperature threshold ranges. Different ranges can be distinguished by different colors or line types. Resource utilization curve: For resource utilization, stacked area charts are more appropriate because they involve multiple resources such as CPU, memory, and disk. Stacked area charts clearly display the contribution of each resource to the overall utilization and its trend over time, making it easier to compare the usage relationships between different resources. Visualization tool application: Real-time monitoring scenarios: Grafana is chosen as a visualization tool, offering powerful real-time data visualization capabilities and seamless integration with various data sources, such as InfluxDB. In Grafana, by configuring the InfluxDB data source and setting the appropriate query statements, you can obtain real-time device operating data and generate temperature and resource utilization curves. Users can customize the chart style, axis range, time span, and more. They can also set alert rules to trigger notifications when the curve data meets specific conditions. Offline analysis scenarios: For in-depth data analysis or report generation, Python libraries like Matplotlib or Seaborn can be used. Matplotlib is a widely used Python plotting library with comprehensive and flexible features, allowing precise control of chart elements through code. Seaborn, a higher-level encapsulation of Matplotlib, provides a more aesthetically pleasing and concise plotting style, making it ideal for data analysis visualization. These libraries can be used to read device operating data files stored locally or in a database, perform data processing and plotting, and generate high-quality temperature and resource utilization curve images or charts for subsequent analysis and reporting. Data aggregation processing: The amount of originally collected data may be very large. In order to facilitate the viewing of long-term trends and reduce data storage pressure, the data needs to be aggregated. Downsampling by time period: For example, using the Pandas library's resample method, data collected every 10 seconds can be downsampled by hour or day. If downsampling by hour, for temperature data, the average of all temperature data within each hour can be calculated as the representative temperature value for that hour; for resource utilization data, the weighted average of resource utilization for each hourly period can be calculated. Calculate a moving average: To smooth the curve and reduce the interference caused by data fluctuations, calculate a moving average. For example, using a 5-point moving average, for a temperature value at a certain moment, calculate the average of the two data points before and after it, plus the five data points itself, as the smoothed temperature value at that moment. This creates a smoother temperature curve and more clearly displays the temperature trend.

[0104] For example, for the aforementioned industrial robot equipment, use Grafana integrated with InfluxDB for real-time monitoring. Create a dashboard in Grafana and add a temperature curve panel. Select InfluxDB as the data source and use the query "SELECT mean (temperature) FROM device_metrics WHERE device_id = 'industrial_robot_01' GROUP BY time (1m)." This will query the average temperature of the device every minute and plot a curve. Also, set the temperature baseline to 40°C, represented by a horizontal dashed line in the curve panel. For the resource utilization curve, create a stacked area chart panel with the query "SELECT mean (cpu_usage), mean(memory_usage), mean (disk_io_usage) FROM device_metrics WHERE device_id = 'industrial_robot_01' GROUP BY time (5m)." This will query the average CPU, memory, and disk I / O utilization every 5 minutes and plot a stacked area chart. During offline analysis, Python's Matplotlib library is used to read the CSV data file exported by InfluxDB.

[0105] S403: Monitor the frequency of requests sent by the trusted device and whether the requests are responded to successfully, and count the number of requests that fail to respond.

[0106] Frequency statistics: A sliding window algorithm is used to count the frequency of device requests, typically measured in requests per second (QPS). The size of the sliding window can be customized, for example, a 1-minute window. Within the window, the timestamp of each request is recorded. By counting the number of requests within the window, the QPS for that period is calculated. Different types of requests should be distinguished. For example, in HTTP requests, the frequency of requests using different methods, such as GET, POST, and PUT, should be differentiated to enable more detailed analysis of device behavior. Response monitoring method: When the device sends a request, record the key information of each request, including the request timestamp, the target address of the request, the parameters of the request, the response code, and the response delay time. For HTTP requests, a response code such as 200 indicates a successful request, and a series of codes such as 400 and 500 indicate different types of failures. Use monitoring tools such as Prometheus to collect and store this information by defining relevant indicators. Prometheus can configure crawling tasks to regularly obtain request and response statistics from devices or related service interfaces. For example, the "http_requests_total" indicator is used to count the total number of requests, and the "http_response_time_seconds" indicator is used to count the response delay time. Failure criteria: Timeout settings: Set a reasonable request timeout based on business needs and network environment. For example, for most business requests with high real-time requirements, set the timeout to 500 milliseconds. If no response is received within this time, the request is considered failed. Retry mechanism: To avoid misjudgments due to temporary network fluctuations, a retry mechanism is established. When a request fails, the device automatically retries a certain number of times, such as three consecutive retries. If all three retries fail, the request is recorded as a failed request and the number of failed requests is added to the statistics. The time and result of each retry are also recorded to facilitate subsequent analysis of the cause of the failure.

[0107] Assume that the industrial robot device interacts with the factory's production management system through an HTTP interface. Use Prometheus to monitor its requests. Add the following crawling task to the Prometheus configuration file: scrape_configs: - job_name: 'industrial_robot_requests' static_configs: - targets: ['industrial_robot_server:9100'] metrics_path: ' / metrics' params: module: ['http'] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: blackbox_exporter:9115.

[0108] On the device side, when an HTTP POST request is sent, the request timestamp is recorded as "2025-03-19T10:10:00Z", the request destination address is "http: / / production_management_system / api / robot_tasks", and the request parameters are {"task_id": "12345", "robot_id": "industrial_robot_01"}. If no response is received within 500 milliseconds, the device automatically performs the first retry, recording the retry time as "2025-03-19T10:10:00.5Z", and then resends the request. If three consecutive retries fail, the request is recorded as a failed request, and the "http_requests_total" and "http_requests_failed_total" metrics in Prometheus are incremented by 1.

[0109] S404. Compare the temperature curve with a preset temperature baseline to obtain a high-temperature curve segment that exceeds the temperature baseline. If the time period corresponding to the high-temperature curve segment exceeds a set high-temperature time threshold, it is determined that the trusted device is abnormal.

[0110] Baseline establishment method: Based on historical data statistics: Collect device temperature data over a period of time (e.g., 7 days) and calculate the average of this data as the base temperature value. Then, calculate the standard deviation (σ) of this data to determine the temperature fluctuation range. Typically, the normal temperature fluctuation range is ±3σ of the average value; temperatures outside this range are considered abnormal. For example, if the average temperature of a device over the past 7 days is 35°C and the standard deviation is 2°C, the normal temperature range is approximately 35 - 3 * 2 = 29°C to 35 + 3 * 2 = 41°C.

[0111] Dynamic baseline adjustment: Considering the potential for cyclical fluctuations in device operation, for example, some devices experience high temperatures during peak daytime hours due to high loads, and low temperatures at night due to low loads. A seasonal decomposition model (such as STL - Seasonal Trend decomposition using Loess) is used to decompose historical temperature data, separating trend, seasonal, and residual terms. The temperature baseline is dynamically adjusted based on different time periods (such as hourly or daily) by combining trend and seasonal terms. For example, if STL model analysis reveals that a device's temperature is approximately 5°C higher between 10:00 AM and 4:00 PM daily due to frequent business activity, compared to other time periods, the temperature baseline is raised by 5°C during this time period. High-temperature detection logic: The system traverses the temperature curve data. When the detected temperature value continuously exceeds the preset temperature baseline (for example, exceeding the baseline by 10%), the start time of the high-temperature curve segment is recorded. When the temperature value falls below the baseline, the end time of the high-temperature curve segment is recorded. The duration of the high-temperature curve segment is calculated. If the duration exceeds the set high-temperature time threshold (for example, 30 minutes), the device is considered abnormal. During the detection process, a data filtering algorithm can be used to eliminate short-term temperature fluctuations that may be caused by noise or transient interference to avoid false positives. False alarm suppression measures: Analyze historical data and business scenarios of device operation to identify situations that may cause a brief temperature increase but are not device abnormalities, such as the warm-up process during device startup and the normal temperature rise when the device performs specific high-load tasks. When determining high-temperature anomalies, these known normal high-temperature scenarios are excluded. For example, through historical data analysis, it is found that within the first 10 minutes after each device startup, the temperature will rise rapidly from room temperature to around 45°C and then gradually stabilize at 40°C. In this case, no high-temperature anomaly detection will be performed within these 10 minutes after the device is started.

[0112] For the aforementioned industrial robot, historical data statistics show an average temperature of 40°C with a standard deviation of 3°C. A temperature baseline of 40°C was set, and the normal temperature range was 31°C to 49°C. Analysis using an STL model revealed that the robot's temperature was 3°C higher during peak production hours (9:00 AM to 5:00 PM) than during other periods. Therefore, the temperature baseline was adjusted to 43°C during this period. During monitoring, the temperature consistently exceeded 43°C + 10% (i.e., 47.3°C) starting at 10:00 AM. The high-temperature curve segment began at 2025-03-19T10:00:00Z and fell below 47.3°C at 10:40 AM. The high-temperature curve segment lasted 40 minutes, exceeding the set high-temperature duration threshold of 30 minutes. The system determined that the industrial robot had a temperature anomaly. Further checking the device operation log revealed that the time period was not a normal high-temperature scenario such as device startup or execution of specific high-load tasks, confirming that the abnormal situation was true.

[0113] S405. Compare the resource occupancy rate curve with a preset resource occupancy rate baseline to obtain an abnormal curve segment that exceeds the resource occupancy rate baseline. If the time period corresponding to the abnormal curve segment exceeds a set time threshold, it is determined that the trusted device has an abnormality.

[0114] Set a resource utilization baseline based on the average resource utilization over a period of time. Starting from the starting point of the resource utilization curve, compare each point against the preset baseline range. When the resource utilization value exceeds the upper limit of the baseline range, mark the start time of the abnormal curve segment. Focus not only on anomalies of individual data points, but also conduct short-term trend analysis. For example, calculate a moving average (such as the average of the past five data points). If the moving average exceeds the baseline range for multiple consecutive points, it can further confirm the presence of an anomaly and prevent misjudgments caused by momentary noise interference. When the resource utilization value falls below the lower limit of the baseline range, mark the end time of the abnormal curve segment.

[0115] Set time thresholds based on the importance of the device and the business's tolerance for device failures. For critical industrial control equipment, where abnormal resource usage could lead to serious production incidents, a shorter time threshold, such as 5 minutes, can be used. For non-critical smart home devices, a longer time threshold, such as 30 minutes, can be used. Furthermore, time thresholds can be optimized based on the device's historical operating data and failure statistics. For example, if you find that certain devices are prone to performance issues if abnormal resource usage persists for around 10 minutes, you can set the time threshold to 10 minutes.

[0116] S406. Count the fluctuation value of the frequency of sending the request, and if the fluctuation value exceeds a set fluctuation threshold, determine that the trusted device has an abnormality.

[0117] Determine the time window for calculating request frequency fluctuations. The size of the time window should be selected based on the device's service characteristics and the nature of request frequency fluctuations. For devices with frequently fluctuating request frequencies, such as front-end servers on e-commerce platforms, the time window can be shorter, such as one minute. For devices with relatively stable request frequencies, such as smart meters, the time window can be longer, such as one hour. Furthermore, the time window can adopt a sliding window approach, continuously updating the data within the window over time to ensure that the calculation results better reflect real-time changes in request frequency. For example, for a one-minute sliding window, every second the oldest one-second of data in the window is removed and the latest one-second of data is added to recalculate the request frequency within the window. Calculate the difference between the request frequency within the current time window and the historical average request frequency (baseline frequency). This difference can be an absolute value (|current frequency - baseline frequency|) or a relative value ((current frequency - baseline frequency) / baseline frequency × 100%). Relative values more intuitively reflect the degree of change in request frequency relative to the baseline. To smooth out fluctuations and avoid abnormal fluctuations caused by sudden changes in request frequency, we can use an exponentially weighted moving average (EWMA) to process fluctuations. For example, using EWMA to calculate a smoothed fluctuation value for multiple consecutive time windows can more accurately reflect the long-term fluctuation trend of request frequency.

[0118] When the calculated request frequency fluctuation value (absolute or relative) exceeds the set fluctuation threshold, the device is considered abnormal. Detailed information, including the time of the abnormality, current request frequency, baseline frequency, and fluctuation value, is recorded to facilitate subsequent analysis of the abnormality's cause. For example, if the calculated relative fluctuation value of a device's request frequency at a certain moment is 20%, and the set fluctuation threshold is 15%, the device is considered abnormal at that moment.

[0119] S407. If the number of failed response requests reaches a set failure threshold, it is determined that the trusted device has an abnormality.

[0120] Please refer to Figure 5 In an actual application scenario, it includes: device data service platform, secure and trusted device management center, trusted terminal devices 1-n (trusted gateway / trusted direct connection device), device 1-device n. The specific implementation steps are as follows: First, before the terminal device leaves the factory, the user logs in to the Security and Trusted Device Management Center to create and issue a digital certificate. The device stores the digital certificate in the built-in TPM / TPCM module.

[0121] Then, when the terminal device is running, it initiates an authentication request to the secure and trusted device management center, encrypts and transmits the authentication request message, and the secure and trusted device management center obtains and decrypts the authentication request message, verifies the device key stored in the database and the device key in the request message. If the verification is successful, the device authentication status changes from unauthenticated to secure and trusted. If the verification fails, the device authentication status changes from unauthenticated to authentication failure, and the authentication result is fed back to the device.

[0122] Then, when the terminal device is running, it initiates an access request to the device data service platform. After receiving the request, the device data service platform processes the request, returns a response, and updates the online status. Then, after the device is connected, it sends an identity authentication request to the device data service platform. The platform parses the request and obtains the device identification code.

[0123] Then, the platform accesses the device management center to obtain the device authentication status. The management center queries the device authentication status based on the identification code and feeds back the authentication result to the platform. The platform updates the device authentication status and establishes the corresponding authentication file.

[0124] Finally, if the device is secure and trustworthy, it can communicate with the digital intelligence platform through encrypted data. Otherwise, the device is marked as untrustworthy, isolated and displayed, and required to undergo identity security authentication with the secure and trustworthy device management center.

[0125] Device security and trust management methods such as Figure 6 shown.

[0126] The process of the management center confirming that the device is trustworthy: First, the device sends a connection request with the device ID to the secure and trusted device management center. The management center parses the request and returns a heartbeat response, while updating the connection status of the device in the management center. After the device is successfully connected, the management center "issues" it and sends a lightweight certificate to the device. The device stores the certificate in the TPM / TPCM module and feeds back the issuance result to the management center. After receiving the response, the management center updates the certificate status of the corresponding device. For devices with issued certificates, the device actively initiates an authentication request to the management center. The request body carries information such as the device ID, public key, private key, and encryption key. The management center parses the authentication request, queries the database for device certificate information based on the device ID, decodes the public key in the request body based on the encryption algorithm, signature algorithm, etc., and performs signature verification. It compares the request body with other information about the device in the database to obtain the authentication result; it returns the authentication response carrying the authentication result to the device end, and updates the authentication status of the device in the management center.

[0127] The authentication status is divided into unauthenticated, successful, and failed. The default status is unauthenticated. If the authentication fails, the device is required to request or re-issue a certificate. If the authentication succeeds, it means the device is secure and trustworthy.

[0128] In some embodiments, the security management system of the Internet of Things device may include multiple functional modules composed of computer program segments. The computer program of each program segment in the security management system of the Internet of Things device may be stored in the memory of the computer device and executed by at least one processor to perform (see Figure 1 Description) Functions for security management of IoT devices.

[0129] In this embodiment, the security management system of the Internet of Things device can be divided into multiple functional modules according to the functions it performs, such as Figure 7 As shown. The module referred to in the present invention refers to a series of computer program segments that can be executed by at least one processor and can perform fixed functions, which are stored in a memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0130] A receiving module, used to receive authentication information of an IoT device; An authentication module, configured to confirm with an authentication platform whether the IoT device is a trusted device based on the authentication information; An authorization module is used to confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, where the permission identifier is used to confirm that the business data uploaded by the trusted device is credible; A monitoring module, configured to obtain operating data of the trusted device, confirm the operating status of the trusted device based on the operating data, and revoke the permission identifier if the operating status is abnormal; The authentication information includes an authentication certificate issued by an authentication platform to the IoT device.

[0131] Figure 8The security management method for the Internet of Things device provided in the embodiment of the present application can be applied to the device. Those skilled in the art will understand that the device structure involved in the embodiment of the present invention does not constitute a limitation on the device, and the device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. In the embodiment of the present invention, the device includes but is not limited to a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described and / or required herein.

[0132] The device 800 may include a processor 810, a memory 820, and a communication unit 830. These components communicate via one or more buses. Those skilled in the art will appreciate that the server structure shown in the figure does not limit the present invention. The server structure may be a bus structure or a star structure, and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0133] The memory 820 can be used to store execution instructions of the processor 810. The memory 820 can be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 820 are executed by the processor 810, the device 800 can perform some or all of the steps in the above-described method embodiments.

[0134] The processor 810 is the control center of the storage device, which uses various interfaces and lines to connect various parts of the entire electronic device. It executes various functions of the electronic device and / or processes data by running or executing software programs and / or modules stored in the memory 820, and calling data stored in the memory. The processor can be composed of an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same or different functions. For example, the processor 810 can only include a central processing unit (CPU). In an embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0135] The communication unit 830 is configured to establish a communication channel so that the storage device can communicate with other devices, receive user data sent by other devices, or send user data to other devices.

[0136] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program that, when executed, may include some or all of the steps of each embodiment provided by the present invention. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0137] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software and a necessary general-purpose hardware platform. Based on this understanding, the technical solutions in the embodiments of the present invention, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, among other media capable of storing program code, and includes instructions for causing a computer device (which can be a personal computer, a server, or a second device, a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention.

[0138] In this specification, the same or similar parts between the various embodiments can be referred to each other. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.

[0139] In the several embodiments provided by the present invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of systems or modules, and can be electrical, mechanical or other forms.

[0140] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of the present embodiment according to actual needs.

[0141] In addition, each functional module in each embodiment of the present invention may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0142] Although the present invention has been described in detail with reference to the accompanying drawings and in conjunction with preferred embodiments, the present invention is not limited thereto. Without departing from the spirit and essence of the present invention, persons of ordinary skill in the art may make various equivalent modifications or substitutions to the embodiments of the present invention, and such modifications or substitutions shall be within the scope of the present invention. Any changes or substitutions that can be easily conceived by persons skilled in the art within the technical scope disclosed in the present invention shall be within the scope of protection of the present invention.

Claims

1. A security management method for an Internet of Things device, characterized in that: For business platforms, including: Receive authentication information from IoT devices; Confirming with the authentication platform whether the IoT device is a trusted device based on the authentication information; Confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, which is used to confirm that the business data uploaded by the trusted device is credible; Acquire operation data of the trusted device, confirm the operation status of the trusted device based on the operation data, and revoke the permission identifier if the operation status is abnormal; The authentication information includes an authentication certificate issued by an authentication platform to the IoT device.

2. The method according to claim 1, characterized in that The method further comprises: The IoT device encrypts its own device information and uploads it to the authentication platform through a trusted gateway. The device information includes the device's unique identification code, hardware information, and software component information. The IoT device saves the authentication certificate issued by the authentication platform based on the device information to the trusted control module.

3. The method according to claim 2, characterized in that The method further comprises: The authentication platform decrypts the received encrypted file and obtains the device information of the IoT device; The authentication platform audits the device information according to pre-stored audit rules, and generates an authentication certificate if the device information passes the audit; The authentication platform calculates a hash value of a data pair consisting of the device unique identification code and the authentication certificate, and stores the hash value locally; The authentication platform sends the authentication certificate to the IoT device.

4. The method according to claim 3, characterized in that The authentication information includes: The hash value of the data pair consisting of the unique device identification code and authentication certificate of the IoT device.

5. The method according to claim 4, characterized in that Confirming with the authentication platform whether the IoT device is a trusted device based on the authentication information includes: The hash value is sent to the authentication platform, and the authentication platform queries whether there is an identical hash value locally. If the identical hash value exists, a prompt message indicating successful authentication is returned; otherwise, a prompt message indicating failed authentication is returned; Receive the prompt information returned by the authentication platform. If the prompt information indicates that the authentication is successful, the IoT device is determined to be credible. If the prompt information indicates that the authentication fails, the IoT device is determined to be untrustworthy.

6. The method according to claim 1, characterized in that Confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, including: Assign permissions based on the device type of the trusted device; Generate a pair of public and private keys using a trusted chip, and save the private key to the trusted chip; Send the public key to the trusted device and create a mapping table between the public key and the trusted device ID; Generate a permission code based on the assigned permission, and combine the permission code with a set of random numbers to form a permission identifier; Binding the permission identifier to the IP address of the trusted device and storing the result in an identifier storage list; Using a monitoring thread to monitor the storage time of the permission identifier in the identifier storage list, and deleting the permission identifier and the IP address of the trusted device if the storage time reaches a set time threshold; The authority identifier is encrypted using a private key, and the encrypted authority identifier is sent to the trusted device, so that the trusted device decrypts and stores the authority identifier and carries the authority identifier encrypted using the public key each time a request is sent.

7. The method according to claim 1, characterized in that Acquiring operation data of the trusted device, confirming the operation status of the trusted device based on the operation data, and revoking the permission identifier if the operation status is abnormal, including: Regularly obtain operating data of trusted devices, including hardware temperature and resource utilization of trusted devices; generating a temperature curve and a resource occupancy curve based on the regularly acquired operating data; Monitor the frequency of requests sent by the trusted device and whether the requests are successfully responded to, and count the number of requests that fail to respond; Comparing the temperature curve with a preset temperature baseline to obtain a high-temperature curve segment exceeding the temperature baseline, and determining that the trusted device is abnormal if a time period corresponding to the high-temperature curve segment exceeds a set high-temperature time threshold; Comparing the resource utilization rate curve with a preset resource utilization rate baseline to obtain an abnormal curve segment exceeding the resource utilization rate baseline, and determining that an abnormality exists in the trusted device if a time period corresponding to the abnormal curve segment exceeds a set time threshold; Counting fluctuation values of the frequency of sending requests, and determining that an abnormality exists in the trusted device if the fluctuation value exceeds a set fluctuation threshold; If the number of failed response requests reaches a set failure threshold, it is determined that the trusted device has an abnormality.

8. A security management system for Internet of Things devices, characterized in that: Business platforms include: A receiving module, used to receive authentication information of an IoT device; An authentication module, configured to confirm with an authentication platform whether the IoT device is a trusted device based on the authentication information; An authorization module is used to confirm that the IoT device is a trusted device and grant the trusted device a time-sensitive permission identifier, where the permission identifier is used to confirm that the business data uploaded by the trusted device is credible; A monitoring module, configured to obtain operating data of the trusted device, confirm the operating status of the trusted device based on the operating data, and revoke the permission identifier if the operating status is abnormal; The authentication information includes an authentication certificate issued by an authentication platform to the IoT device.

9. A device, characterized in that include: Memory, used to store security management programs for IoT devices; A processor, configured to implement the steps of the security management method for an Internet of Things device as described in any one of claims 1 to 7 when executing the security management program of the Internet of Things device.

10. A computer-readable storage medium storing a computer program, characterized in that: The readable storage medium stores a security management program for an Internet of Things device, and when the security management program for the Internet of Things device is executed by a processor, the steps of the security management method for an Internet of Things device according to any one of claims 1 to 7 are implemented.

Images