Internet of Things access control method, system and device, and storage medium

Abstract

The invention provides an Internet of Things access control method, system and device, and a storage medium. The method comprises the steps of obtaining identity attribute information of a terminal device; performing access verification on the identity attribute information based on an access control strategy, and generating a time capability tree of the terminal equipment; generating a corresponding digital signature token according to identity attribute information of terminal equipment, and positioning an authority node corresponding to each resource request in the time capability tree through the digital signature token; performing time boundary matching according to time constraints of different control levels to obtain a permission boundary of a permission node corresponding to each resource request, and generating an access record of each resource request; and dynamically updating the permission boundaries of the different permission nodes according to the common access characteristics of all the access records, and further adjusting the access permission of the terminal equipment according to an updating result. By adopting the scheme of the invention, the time sequence characteristics accessed by the terminal equipment and the authority management can be dynamically coupled.

Description

Technical Field

[0001] This application relates to the field of access control, and more specifically, to an Internet of Things (IoT) access control method, system, device, and storage medium. Background Technology

[0002] Access control refers to the process of verifying the identity, matching permissions, and monitoring the behavior of entities attempting to access specific resources through pre-defined access policies, permission rules, and technical means (such as identity authentication, permission allocation, access auditing, and role management). This prevents unauthorized entities from illegally obtaining, modifying, or deleting resources or performing unauthorized operations, ultimately ensuring that resources are used legally and securely within the pre-defined authorized scope. Its core objective is to address issues of permission abuse, unauthorized operations, and illegal intrusion in resource access.

[0003] IoT access control refers to a technical mechanism that uses IoT-specific technologies to verify the identity, match permissions, and monitor the behavior of various entities in the IoT ecosystem (such as IoT terminal devices, administrators, third-party management systems, and related applications) attempting to access core IoT objects (such as sensor data collection, device control command permissions, IoT gateway services, and terminal device operation interfaces). This prevents unauthorized entities from illegally accessing devices, issuing control commands beyond their authority, stealing sensor data, or tampering with access permissions. Traditional IoT access control methods often rely on static capability tokens or role-based permission models, which are insufficient to effectively address the real-time changes in terminal device access behavior. For example, traditional permission management may not trigger automatic permission contraction for high-frequency access by a terminal device for 10 consecutive minutes, or may fail to revoke access tokens in a timely manner during the unauthorized period of 2-4 AM. It fails to consider the dynamic impact of access time-series data on permission boundaries, causing permission adjustments to lag behind changes in device behavior. This results in the retention of illegal access risks or the restriction of legitimate temporary access requests. Therefore, how to dynamically couple the temporal characteristics of terminal device access with permission management to avoid the lag in permission adjustments during access has become a challenge for the industry. Summary of the Invention

[0004] This application provides an Internet of Things (IoT) access control method, system, device, and storage medium that can dynamically couple the timing characteristics of terminal device access with permission management.

[0005] In a first aspect, this application provides an Internet of Things (IoT) access control method, comprising the following steps: When the IoT gateway receives a network access request initiated by a terminal device, it obtains the identity attribute information of the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. Based on the access control policy, the identity attribute information is access verified, and then the time capability tree of the terminal device is generated based on the verification result and the time constraints of different control levels. When a terminal device issues a resource request, a corresponding digital signature token is generated based on the identity attribute information of the terminal device. The digital signature token is used to locate the permission node corresponding to each resource request in the time capability tree. Based on the time constraints of different control levels, the time boundary matching of the permission nodes corresponding to each resource request is performed to obtain the permission boundary of the permission node corresponding to each resource request, and the access record of each resource request is generated based on the permission boundary. Based on the common access characteristics of all access records, the permission boundaries of different permission nodes are dynamically updated, and then the access permissions of terminal devices are adjusted according to the update results.

[0006] In some embodiments, performing access verification on the identity attribute information based on the access control policy specifically includes: Obtain the basic access control rules and control hierarchy permission matrix from the access control policy; The identity attribute information is validated by the basic access rules to obtain the structured validation information of the identity attribute information. Based on the structured verification information, the operation permissions requested by the terminal device in the identity attribute information are extracted; The operation permissions are matched with the control hierarchy permission matrix to obtain the permission matching result of the terminal device; The structured verification information and the permission matching result are merged into the verification result of the identity attribute information.

[0007] In some embodiments, generating a time capability tree for the terminal device based on the verification results and time constraints at different control levels specifically includes: Extract the list of valid permissions for each control level from the verification results; Obtain the time constraints corresponding to different preset control levels in the access control policy; Bind the list of valid permissions for each control level to the corresponding time constraints as node attributes in a tree structure; The time capability tree of the terminal device is generated based on the preset hierarchical nesting relationship and the node attributes in the tree structure.

[0008] In some embodiments, generating a corresponding digital signature token based on the identity attribute information of the terminal device specifically includes: The token base information of the resource request is extracted from the identity attribute information of the terminal device; The token's basic information is generated based on the private key of the IoT gateway, and then digitally signed. Based on the signature result, a corresponding digitally signed token is generated.

[0009] In some embodiments, locating the permission node corresponding to each resource request in the time capability tree using the digital signature token specifically includes: Extract the data to be verified and the digital signature result from the digital signature token; The digital signature result is verified using the public key of the IoT gateway; Based on the verification results, the data to be verified is parsed to obtain the resource identifier information when the terminal device issues a resource request; Based on the resource identification information, the permission node corresponding to each resource request is located from the time capability tree.

[0010] In some embodiments, the time boundary matching of the permission nodes corresponding to each resource request is performed based on the time constraints of different control levels to obtain the permission boundary of the permission node corresponding to each resource request. Specifically, this includes: Determine the time constraints corresponding to the control level to which the permission node belongs for each resource request; Obtain the actual time information of each resource request initiated by the terminal device; The actual time information is matched with the time constraints corresponding to each resource request, and then the permission boundaries of the permission nodes corresponding to each resource request are generated based on the matching results.

[0011] In some embodiments, dynamically updating the permission boundaries of different permission nodes based on common access characteristics of all access records specifically includes: Identify the common access characteristics of all access records; Determine the dynamic redundancy information between the common access features and the permission boundaries of different permission nodes; The permission boundaries of different permission nodes are updated based on the dynamic redundancy information.

[0012] Secondly, this application provides an Internet of Things (IoT) access control system, comprising: The acquisition module is used to acquire the identity attribute information of the terminal device when the IoT gateway receives the network access request initiated by the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. The processing module is used to perform access verification on the identity attribute information based on the access control policy, and then generate a time capability tree of the terminal device based on the verification result and the time constraints of different control levels. The processing module is also used to generate a corresponding digital signature token based on the identity attribute information of the terminal device when the terminal device issues a resource request, and to locate the permission node corresponding to each resource request in the time capability tree through the digital signature token. The processing module is also used to perform time boundary matching on the permission nodes corresponding to each resource request according to the time constraints of different control levels, to obtain the permission boundary of the permission node corresponding to each resource request, and to generate access records for each resource request based on the permission boundary. The execution module is used to dynamically update the permission boundaries of different permission nodes based on the common access characteristics of all access records, and then adjust the access permissions of the terminal device based on the update results.

[0013] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described Internet of Things access control method.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described Internet of Things access control method.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The IoT access control method, system, device, and storage medium provided in this application obtain the identity attribute information of the terminal device when the IoT gateway receives a network access request initiated by the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. Access verification is performed on the identity attribute information based on the access control policy, and a time capability tree of the terminal device is generated based on the verification result and the time constraints of different control levels. When the terminal device issues a resource request, a corresponding digital signature token is generated based on the terminal device's identity attribute information. The digital signature token is used to locate the permission node corresponding to each resource request in the time capability tree. Time boundary matching is performed on the permission nodes corresponding to each resource request based on the time constraints of different control levels to obtain the permission boundary of the permission node corresponding to each resource request, and an access record for each resource request is generated based on the permission boundary. The permission boundaries of different permission nodes are dynamically updated based on the common access characteristics of all access records, and the access permissions of the terminal device are adjusted based on the update result.

[0016] Therefore, in this solution, firstly, the terminal device's identity attributes are verified based on access control policies, and a time capability tree for the terminal device is generated by combining time constraints at different control levels. This time capability tree accurately associates the terminal device's identity with dynamic time constraints. It binds time rules at different control levels (such as device type level and resource importance level) to corresponding permission nodes, thus avoiding the problem of separation between time-series features and permissions in traditional static permission models. Compared to the traditional method of allocating permissions solely based on preset roles, this process embeds time constraints into the hierarchical structure of the capability tree, providing a structured carrier for the subsequent dynamic coupling of time-series features and permissions, significantly improving the accuracy of adapting permissions to time-series changes. Then, in After generating access records for each resource request, the common access features of all access records are extracted to dynamically update the permission boundaries of different permission nodes. This permission boundary update process can transform temporal features into permission adjustment criteria in real time, automatically expanding the common risk features of the time boundaries of corresponding permission nodes and shrinking the permission boundaries during unauthorized periods, ensuring that permission adjustments always follow changes in temporal features. This process, through data analysis of common access features, shifts permission management from manually preset rules to time-series data-driven approaches, avoiding the problem of permissions lagging behind temporal changes in traditional methods, and further reducing the adaptation deviation between temporal features and permission management. In summary, this solution can dynamically couple the temporal features of terminal device access with permission management. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating an Internet of Things (IoT) access control method according to some embodiments of this application; Figure 2 This is a flowchart illustrating the process of determining the boundaries of permissions according to some embodiments of this application; Figure 3 This is a schematic diagram illustrating the process of implementing constraint matching according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of an Internet of Things access control system according to some embodiments of this application; Figure 5 This is an internal structural diagram of a computer device implementing an Internet of Things access control method according to some embodiments of this application. Detailed Implementation

[0018] To better understand the technical solutions in this embodiment, the technical solutions in this embodiment will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0019] refer to Figure 1The figure is a flowchart illustrating an Internet of Things (IoT) access control method according to some embodiments of this application. The IoT access control method 100 mainly includes the following steps: In step 101, when the IoT gateway receives a network access request initiated by the terminal device, it obtains the identity attribute information of the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes.

[0020] In practical implementation, the identity recognition module built into the IoT gateway can trigger the identity attribute information collection process during the handshake phase of the terminal device's network access request: For devices that support hardware identification (such as industrial sensors and smart controllers), the core identity information is obtained by reading their built-in unique hardware identifier; for devices that require authentication and activation (such as smart home terminals), the manufacturer information, device model, security level, and other attributes contained in the certificate are extracted by verifying the digital certificate or device token pre-installed at the factory; at the same time, the communication protocol parsing module of the IoT gateway obtains auxiliary attributes such as the device's network identifier (such as port number) and protocol version from the protocol header of the network access request message, such as the hardware serial number provided when a smart door lock enters the network, the communication protocol version parsed by the home gateway, and the digital certificate information submitted when an industrial robot enters the network, which together serve as the identity attribute information of the terminal device.

[0021] It should be noted that the identity attribute information refers to the inherent attributes or pre-set identifiers of the terminal device that can be objectively verified during the network access process; the network access request refers to the identity authentication request initiated by the terminal device when it first accesses the IoT system or reconnects; the access control policy refers to the set of device access control rules pre-set by the system administrator or policy management platform according to the security requirements and business rules of the IoT system before the deployment or operation of the IoT gateway; the control level refers to the hierarchical structure of the access control policy divided according to the granularity of permission management, commonly including device level (access control for the entire device), resource level (control of specific resources that the device can access, such as sensor data and actuator instructions), and operation level (control of specific operations that the device can perform on resources, such as reading data and issuing instructions); the permission node refers to the specific permission unit under each control level, such as the "allow network access" and "deny network access" nodes at the device level, the "access sensor A data" and "access controller B instruction" nodes at the resource level, and the "read sensor A data" and "modify sensor A sampling frequency" nodes at the operation level. Each permission node is associated with corresponding access conditions and control rules, constituting the basic unit of the access control policy.

[0022] In step 102, the identity attribute information is access verified based on the access control policy, and then the time capability tree of the terminal device is generated based on the verification result and the time constraints of different control levels.

[0023] In some embodiments, the access verification of the identity attribute information based on the access control policy can be achieved by the following steps: Obtain the basic access control rules and control hierarchy permission matrix from the access control policy; The identity attribute information is validated by the basic access rules to obtain the structured validation information of the identity attribute information. Based on the structured verification information, the operation permissions requested by the terminal device in the identity attribute information are extracted; The operation permissions are matched with the control hierarchy permission matrix to obtain the permission matching result of the terminal device; The structured verification information and the permission matching result are merged into the verification result of the identity attribute information.

[0024] It should be noted that the basic access rules mentioned in this application refer to the minimal security verification rules executed by the IoT gateway when a terminal device joins the network, which are used to ensure that the terminal device has legitimate identity credentials and access qualifications; the control level permission matrix refers to a multi-level permission allocation structure predefined according to the access control policy, which is used to represent the correspondence between various operation permissions and resource nodes under different control levels; the basic access rules and the control level permission matrix can be extracted through the access control policy configuration module of the IoT gateway, which can call the corresponding data structure from the system's preset access policy library, device registration database or external security policy management system; in other embodiments, the basic access rules can also be dynamically obtained through external identity authentication services (such as Public Key Infrastructure (PKI) certificate management system, Open Authorization (OAuth) certification center), and the control level permission matrix can also be generated in real time in combination with a policy inference engine or an attribute-based access control model, thereby improving the flexibility and dynamic adaptation capability of policy acquisition, which is not limited in this application.

[0025] In specific implementation, the structured verification information of the identity attribute information obtained by verifying the identity attribute information through the basic access rules can be implemented in the following way: First, collect the identity attribute information submitted by the terminal device when initiating the access request. The identity attribute information includes at least the device unique identifier, access address, organization number, and security credential data. Then, during the verification, the device unique identifier can be compared with a list of legal identifiers using a hash index. The hash function mapping reduces the retrieval time, and the legality status of the identifier is marked according to the matching result. The verification of the access address can be carried out by combining regular expression parsing and a network whitelist. The regular expression parsing is used to check the syntax compliance of the address, while the whitelist comparison is used to determine whether the address is within the authorized scope. The verification of the organization number can be carried out by comparing the path mapping of the organization number in the hierarchical tree structure. The system matches the data against preset rule paths one by one. If a matching path exists, it is marked as valid; otherwise, it is marked as unknown. For the verification of security credential data, the credential content is decrypted by calling a digital signature algorithm, and the signature consistency is verified using a pre-stored public key, thereby obtaining the validity determination result of the credential. Finally, the above verification results are uniformly structured, specifically by generating verification entries according to a preset data structure template. Each entry includes a field name, field value, verification result, and rule source information, and all entries are summarized to generate structured verification information for the terminal device. As a preferred embodiment, a rule mapping table can be introduced in the above structured processing to convert the judgment conditions of each basic access rule into standardized logical labels, such as valid certificate, legal address, illegal organization, etc., so that they can be directly called in subsequent permission extraction and control level matching steps. This is not limited here.

[0026] It should be noted that the structured verification information mentioned in this application refers to a standardized data set generated after verifying the identity attribute information submitted by the terminal device based on the basic access rules. Each data entry includes a field name, field value, verification result, and rule source information, which is used to fully characterize the legality and validity status of the terminal device's identity attributes.

[0027] In specific implementation, the extraction of operation permissions requested by the terminal device from the identity attribute information based on the structured verification information can be achieved in the following way: First, the operation request field submitted by the terminal device is parsed from the structured verification information. The operation request field may include resource access type, operation instruction code, service interface identifier, and associated context parameters. Then, for the resource access type in the operation request field, it can be retrieved through a permission mapping dictionary. The permission mapping dictionary predefines the correspondence between resource access types and corresponding permission categories, such as read, write, execute, configuration, etc., and outputs the corresponding primary permission identifier. For parsing the operation instruction code, a mapping table between operation instructions and functional modules can be established, and the instruction code can be converted into specific functional permission items one by one. For example, code 001 corresponds to data collection permission, code 002 corresponds to remote control permission, and code 0... 03 corresponds to the configuration modification permission, thereby obtaining the permission request at the operation instruction level; the processing of service interface identifiers can be carried out by matching each item based on the interface access list. If the identifier exists in the list, its corresponding interface access permission is extracted; otherwise, it is marked as an unknown request; when parsing the context parameters, the operation scope limited by the parameters can be determined by the rule engine, such as time period restrictions, resource scope restrictions, or user role restrictions, thereby attaching corresponding constraints to the extracted permissions; finally, the above-mentioned various permission identifiers and constraints are uniformly summarized, and operation permission entries for the terminal device are generated according to the preset permission data structure. Each entry contains fields such as permission category, function item, interface scope, and constraints, constituting the extracted operation permissions; in other embodiments, operation permission extraction can also be achieved by rule-based reasoning or semantic matching, which is not limited in this application.

[0028] It should be noted that the operation permissions mentioned in this application refer to a set of permissions generated based on the identity attribute information and structured verification information submitted by the terminal device, by parsing the operation request field, mapping permission categories, function items and service interface identifiers, and combining contextual constraints. The operation permissions are used to characterize the specific operation types, functional scope and interface access capabilities that the terminal device can execute, and include corresponding operation restrictions, such as time period restrictions, resource scope restrictions or role restrictions, to support fine-grained control and permission management of the terminal device's resource access and function calls in the Internet of Things system.

[0029] In specific implementation, matching the operation permissions with the control hierarchy permission matrix to obtain the permission matching result of the terminal device can be achieved in the following way: First, obtain the operation permissions extracted by the terminal device and the predefined control hierarchy permission matrix in the access control policy. The permission matrix represents the correspondence between resource nodes and allowed operations under each control hierarchy in a two-dimensional structure. Then, for each operation permission of the terminal device, compare it layer by layer in the control hierarchy permission matrix according to the operation category, functional module, interface scope and constraints. Determine whether the operation permission is in the corresponding control hierarchy by index lookup and Boolean matching. The operation permission is allowed to be executed at the specified level. Next, for the successfully matched operation permission, its corresponding control level and the position of the permission node in the matrix are marked, and the permission inheritance or constraint information is recorded. For the unmatched operation permission, it can be marked as unauthorized or pending approval, and an exception prompt or log record can be generated. Finally, all matching results are summarized into the permission matching result of the terminal device. Each entry includes the operation permission identifier, matching status, control level, permission node and additional constraints. In other embodiments, automated permission matching can also be performed by a batch matching algorithm based on matrix multiplication or a strategy reasoning engine. This application does not limit this.

[0030] It should be noted that the permission matching result mentioned in this application refers to the set of matching information generated by comparing the operation permissions extracted by the terminal device with the predefined control hierarchy permission matrix in the access control policy.

[0031] In specific implementation, the fusion of the structured verification information and the permission matching result into the verification result of the identity attribute information can be achieved in the following way: First, the verification status of each field in the structured verification information is associated with the corresponding operation permission in the permission matching result through a mapping table. The mapping table records the operation permission and priority information corresponding to each field. Specifically, the field name in the structured verification information is used as the index of the mapping table to find the permission node and control level corresponding to the field. Then, the validity and operability of the field under the overall access control are calculated through logical operations, preferably using logical AND operation: if the field verification status is legal and the permission matching result is allowed, the calculation result is marked as operable; otherwise, it is marked as inoperable. The operability score can be quantified as 0 or 1, or it can be weighted and calculated. For example, important fields are multiplied by a weight coefficient and then multiplied by the binary status of the permission matching to obtain a weighted operability score. This reflects the overall effectiveness of the fields in the overall access control. Then, all the merged verification units are integrated into the identity attribute information verification result of the terminal device according to the preset data structure template. The data structure template can be defined as a multi-dimensional table or a nested object array. Each verification unit contains the following fields: field name, field value, verification status, corresponding permission node, control level, time constraint, operability score, and rule source. During integration, each merged verification unit is written into the template one by one, sorted according to the field name or permission node order to form a complete table or array, and the control level and time constraint information are attached to the corresponding unit as metadata to ensure that each record fully describes the field status, permissions, and execution constraints. In other embodiments, a nested tree structure can also be used to store the verification units, so that the hierarchical relationship of fields, permission nodes, and control levels is clear, supporting multi-level permission queries and dynamic updates. This application does not limit this.

[0032] It should be noted that the identity attribute information verification result mentioned in this application refers to the comprehensive evaluation information set generated by fusing the structured verification information of the terminal device with the permission matching result.

[0033] In some embodiments, generating the time capability tree of the terminal device based on the verification results and time constraints of different control levels can be achieved using the following steps: Extract the list of valid permissions for each control level from the verification results; Obtain the time constraints corresponding to different preset control levels in the access control policy; Bind the list of valid permissions for each control level to the corresponding time constraints as node attributes in a tree structure; The time capability tree of the terminal device is generated based on the preset hierarchical nesting relationship and the node attributes in the tree structure.

[0034] In specific implementation, the extraction of the list of valid permissions for each control level from the verification results can be achieved in the following way: First, traverse all field verification units in the verification results of the identity attribute information. For each field unit, read its corresponding control level information, permission node, and operability score. Then, filter out field units whose operability scores reach the threshold according to the preset validity judgment rules. For example, when the operability score is 1 or exceeds the set weight threshold, the permission corresponding to the field is considered to be a valid permission. Next, summarize all valid permission fields under the same control level to generate a list of valid permissions for that level. Each list record includes the permission node identifier, field name, field value, verification status, and rule source information. In other implementations, dynamic extraction and filtering can also be performed through database queries or a strategy engine, which is not limited here.

[0035] It should be noted that the effective permission list mentioned in this application refers to the set of permissions extracted from the identity attribute information verification results of the terminal device and determined to be operable under a specific control level; the effective permission list is used to characterize the specific operation permissions that the terminal device can execute under the control level, including information such as permission node identifier, field name, field value, verification status and rule source.

[0036] It should be noted that the time constraints corresponding to different control levels mentioned in this application refer to the time windows and effective periods under each control level that terminal devices can perform corresponding permission operations in the IoT access control policy. These time constraints may include, but are not limited to, the start and end time of daily access, the number of days of access per week, the duration limit of access, and temporary authorization time periods. The time constraints can be extracted from the system's preset policy library or external security policy management system through the access control policy configuration module of the IoT gateway. For example, the corresponding time constraint parameters can be read according to the control level index and cached in the local policy mapping table. In other embodiments, the time constraints corresponding to the control level can also be generated in real time through the access control policy inference engine or the attribute-based access control model. For example, the access time window can be dynamically calculated by combining the organization, role attributes, and environmental conditions of the terminal device. The acquisition frequency of the time constraints can be set according to the policy update cycle and the access frequency of the terminal device. For example, the policy library update information can be read every 1 to 5 minutes to ensure the timeliness and dynamic adaptability of the time constraints. This application does not limit this.

[0037] In specific implementation, binding the effective permission list of each control level with the corresponding time constraints as node attributes in a tree structure can be achieved in the following way: First, for each control level, read its corresponding effective permission list and preset time constraint parameters; then, use each effective permission record as a basic attribute of the tree node, including permission node identifier, field name, field value, verification status, and rule source information, and use the time constraint information of the control level as the node's time attribute, such as access start and end time, validity period, and access duration; next, create a parent node for all permission nodes under the same control level, establish a hierarchical relationship between the above permission nodes and the parent node, so that each permission node can inherit the time constraint attribute of the control level, thereby realizing the binding of the effective permission list of each control level with the corresponding time constraints as node attributes in a tree structure; in other embodiments, a policy mapping table or hash index can also be used to dynamically bind effective permissions and time constraints to node objects so as to enable fast access and combination when generating the time capability tree, which is not limited in this application.

[0038] It should be noted that the time-constrained permission nodes mentioned in this application refer to nodes in the time capability tree that not only contain the effective permission information of the terminal device under a specific control level, such as permission node identifier, field name, field value, verification status and rule source, but also are associated with the time constraint information of that control level, including access start and end time, validity period and access duration, etc. The time-constrained permission nodes are used to characterize the scope of permissions and timeliness of the operations that the terminal device can perform under a specific control level, ensuring that permissions and time constraints can be considered simultaneously when generating the time capability tree and executing access control policies.

[0039] In specific implementation, generating the terminal device's time capability tree based on a preset hierarchical nesting relationship and node attributes in a tree structure can be achieved in the following way: First, read the node attribute information of each control level, including the list of valid permissions with bound time constraints and parent-child hierarchical relationship information; then, according to the preset hierarchical nesting rules, recursively traverse downwards from the top-level parent node, establishing hierarchical connections between each child node and its parent node according to its control level, forming a tree branch structure; next, for each node, merge or inherit its time attributes with the time constraints of its parent node, for example, by taking the intersection to determine the access start and end time and the valid period, ensuring that the child node's time attributes are merged or inherited. Node permission operations will not exceed the time limit of the parent node; at the same time, the node's permission information, verification status, rule source information, and time constraints are encapsulated together as attributes of the node object so that they can be directly called in access control decisions; then, all nodes are integrated according to their hierarchical relationship to form a complete terminal device time capability tree. The root node of this tree corresponds to the highest control level, and the leaf nodes correspond to specific operation permissions. Each node contains permission and time attributes. In other implementations, the node hierarchy or time constraints can also be dynamically adjusted in conjunction with the policy engine so that the time capability tree can adapt to the dynamic needs of terminal device role changes, temporary authorizations, or policy updates. This application does not limit this.

[0040] It should be noted that the time capability tree described in this application refers to a tree structure constructed based on a preset nested control hierarchy and combined with the time constraints and permission information bound to each node. It is used to characterize the operation permissions of the terminal device under different control levels and their executable time range. Each node of the time capability tree includes a permission node identifier, a list of valid permissions, a verification status, rule source information, and a time constraint attribute. The nodes form a branch structure through a parent-child hierarchical relationship. The time constraint of the parent node can be inherited by the child node or used to limit the operation time of the child node, thereby ensuring that the terminal device meets both permission requirements and time limits when performing various operations.

[0041] In step 103, when the terminal device issues a resource request, a corresponding digital signature token is generated based on the identity attribute information of the terminal device, and the permission node corresponding to each resource request in the time capability tree is located through the digital signature token.

[0042] In some embodiments, generating a corresponding digital signature token based on the identity attribute information of the terminal device can be achieved through the following steps: The token base information of the resource request is extracted from the identity attribute information of the terminal device; The token's basic information is generated based on the private key of the IoT gateway, and then digitally signed. The corresponding digitally signed token is then generated based on the signature result.

[0043] In specific implementation, the token base information for the resource request can be extracted from the identity attribute information of the terminal device in the following way: First, extract fields related to each resource request from the identity attribute information of the terminal device, such as device identifier to identify the requesting device, resource type to distinguish the requested service or data, and request timestamp to mark the access time; then, organize the obtained fields into a standardized data structure according to a preset key-value pair format. The preset key-value pair format means that each field name is used as the key and the corresponding field value is used as the value, and encapsulated with a unified symbol, such as using a JSON object, so that each key-value pair clearly corresponds to the identity attribute field as the token base information for the resource request; in other embodiments, identity attribute fields can also be automatically mapped to token base information through a policy mapping table or template engine, so as to be quickly called when generating digital signature tokens. This application does not limit this.

[0044] It should be noted that the token basic information mentioned in this application refers to the key information related to each resource request extracted and standardized from the identity attribute information of the terminal device, which is used as the basic data for generating access control tokens.

[0045] In specific implementation, the token basic information generated based on the IoT gateway's private key is digitally signed, and then a corresponding digital signature token is generated based on the signature result. This can be achieved in the following way: First, the token basic information is serialized into a string with a unified encoding format, such as UTF-8 encoding, to ensure the consistency and parsability of the information in subsequent processing. Then, a fixed-length hash value is calculated based on the serialized string. A well-known hash algorithm such as SHA-256 can be used to process the string byte by byte to obtain a 256-bit binary digest. This digest is used to ensure data integrity and tamper-proof performance. Next, the hash value is asymmetrically encrypted using the IoT gateway's private key. The encryption process includes inputting the hash digest into a private key encryption function to generate a digital signature result. This signature can be verified using the corresponding public key to confirm the token's authenticity. Then, the token basic information and the digital signature result are Base64 encoded respectively to ensure that the encoded result can be securely transmitted and maintain parsability. Finally, the encoded token basic information and the digital signature result are combined according to a preset format to form a complete digital signature token, for example, "Token Basic Information (Base64)". The corresponding digital signature token is obtained by concatenating the following: "(Base64 encoded)". The digital signature result is obtained by "(Base64 encoded)".

[0046] It should be noted that the digital signature token mentioned in this application refers to a verifiable access credential generated by digitally signing the token basic information of the terminal device through the private key of the Internet of Things gateway; the digital signature token includes the serialized token basic information and the corresponding digital signature result.

[0047] In some embodiments, locating the permission node corresponding to each resource request in the time capability tree using the digital signature token can be achieved through the following steps: Extract the data to be verified and the digital signature result from the digital signature token; The digital signature result is verified using the public key of the IoT gateway; Based on the verification results, the data to be verified is parsed to obtain the resource identifier information when the terminal device issues a resource request; Based on the resource identification information, the permission node corresponding to each resource request is located from the time capability tree.

[0048] In specific implementation, the extraction of the data to be verified and the digital signature result from the digital signature token can be achieved in the following way: First, the complete digital signature token sent by the terminal device is received and split according to a preset delimiter. In this application, a comma is used as the delimiter to split the token into two parts: the first part is the data to be verified (i.e., the token's basic information), and the second part is the digital signature result. Then, the split data to be verified and the digital signature result are Base64 decoded respectively. The data to be verified is decoded into the original token's basic information, and the digital signature result is decoded into an encrypted hash value. Next, the format of the decoded data to be verified is validated to ensure that it conforms to the preset data structure standard, such as a JSON object containing fields such as device identifier, resource type, and request operation.

[0049] It should be noted that the data to be verified and the digital signature result mentioned in this application refer to two types of information obtained by splitting and decoding the digital signature token. The data to be verified corresponds to the basic information of the serialized token, which is used to represent the identity attributes and request operation fields of the terminal device, including device identifier, resource type, request timestamp, etc. The digital signature result corresponds to the binary digest generated by encrypting the data to be verified using the IoT gateway private key after hashing, which is used to verify the integrity, authenticity and tamper resistance of the token. The data to be verified and the digital signature result can be decoded and parsed through a unified encoding (such as Base64) to support security verification and permission verification in the access control process.

[0050] In practice, verifying the digital signature result using the public key of the IoT gateway can be achieved in the following way: First, obtain the public key of the IoT gateway paired with the generated digital signature token. This key can be read from a local key storage module or a security management system and parsed according to a preset format to ensure it can be used for decryption. Then, input the decoded digital signature result into an asymmetric decryption algorithm, such as RSA. A 2048-bit public key decryption function decrypts the encrypted hash value to obtain the original hash digest. Next, the same hash calculation is performed on the token's basic information extracted from the data to be verified, using the SHA-256 algorithm to process it byte-by-byte to obtain a locally calculated hash digest. Then, the decrypted hash digest is compared bit-by-bit with the locally calculated hash digest. If they match completely, the digital signature verification is successful, confirming that the token has not been tampered with and its source is reliable. If they do not match, the signature verification fails, the resource request is rejected, and an exception log can be generated to record the verification failure information. In other implementations, timestamps, serial numbers, or policy version numbers can be combined to further verify the verification result to enhance security and anti-tampering capabilities; this application does not limit this.

[0051] It should be noted that the digital signature verification result mentioned in this application refers to the verification conclusion obtained by decrypting the digital signature result in the digital signature token using the public key of the Internet of Things gateway and comparing it with the hash digest calculated locally. It is used to characterize the integrity, authenticity and tamper resistance of the token.

[0052] In specific implementation, the resource identification information obtained by parsing the data to be verified based on the verification result can be achieved in the following way: First, under the premise that the digital signature verification is passed, the data to be verified is parsed according to a preset data structure standard, such as extracting each field in the JSON object as an independent variable; then, the core fields related to the resource request are obtained from the parsed data, including but not limited to the device identifier used to identify the requesting device, the resource type used to distinguish the requested service or data, and the request operation used to indicate the specific operation to be performed; next, the parsed fields can be converted into a unified resource identification information format according to the field naming mapping table or template rules, such as forming a structured object containing a triple of "device identifier, resource type, request operation"; finally, the structured object is used as the resource identification information corresponding to the terminal device in this resource request; in other embodiments, the fields can also be automatically parsed and standardized by combining a strategy engine or dynamic mapping table, which is not limited in this application.

[0053] It should be noted that the resource identification information mentioned in this application refers to the structured information parsed from the data to be verified, which is used to identify the resource requested by the terminal device, provided that the digital signature verification is successful, so as to clarify the device identity, resource type and specific operation involved in this access request.

[0054] In specific implementation, locating the permission node corresponding to each resource request from the time capability tree based on the resource identification information can be achieved in the following way: First, obtain the time capability tree corresponding to the terminal device. This tree can be read from the gateway's local storage or policy database, ensuring that its structure conforms to a preset hierarchical nesting relationship, such as device-level, resource-level, and operation-level nodes nested sequentially. Then, extract the device identifier, resource type, and request operation field from the resource identification information. Use the device identifier as an index to confirm the existence of the device-level node and verify that the node's status meets the network access and permission verification conditions. Next, starting from the device-level node, use a depth-first search or breadth-first search... The search algorithm traverses its child nodes, matching the resource type field sequentially to locate the corresponding resource-level node. Then, it continues traversing child nodes under the resource-level node, finding the operation-level node based on the request operation field; this is the permission node corresponding to the current resource request. During the location process, the node's time constraint attribute can be used to verify whether the current access time is within the allowed operation time window. If the time constraint is exceeded, the node is marked as inoperable. Finally, the located operation-level node and its status information are returned as the permission node for this resource request. In other implementations, a node index table or hash mapping can be used to accelerate node location and improve access efficiency; this application does not limit this approach.

[0055] It should be noted that the permission node mentioned in this application refers to the operation-level node corresponding to each resource request in the time capability tree of the terminal device, which is used to characterize the device's executable permission for a certain resource under a specific time window.

[0056] In step 104, time boundary matching is performed on the permission nodes corresponding to each resource request according to the time constraints of different control levels to obtain the permission boundary of the permission node corresponding to each resource request, and an access record for each resource request is generated based on the permission boundary.

[0057] In some embodiments, reference Figure 2 As shown in the figure, this is a flowchart illustrating the process of determining permission boundaries in some embodiments of this application. The permission boundaries of each resource request are obtained by matching the permission nodes corresponding to each resource request with time boundaries based on the time constraints of different control levels, using the following steps: First, in step 1041, the time constraint corresponding to the control level to which the permission node of each resource request belongs is determined; Then, in step 1042, the actual time information of each resource request initiated by the terminal device is obtained; Finally, in step 1043, the actual time information is matched with the time constraints corresponding to each resource request, and then the permission boundaries of the permission nodes corresponding to each resource request are generated based on the matching results.

[0058] In specific implementation, determining the time constraint corresponding to the control level of the permission node for each resource request can be achieved in the following way: First, obtain the permission node corresponding to each resource request. The permission node can be obtained through the time capability tree positioning method. The node type includes device level, resource level, and operation level. Then, read the control level identifier (e.g., operation level, resource level, or device level) from the attribute information of the permission node, and use it as an index to extract the corresponding time constraint parameters from the time constraint attributes associated with the node, including access start and end time, daily allowed access time period, weekly access days, and access duration, thereby obtaining the time constraint corresponding to the control level of the permission node for each resource request. As a preferred embodiment, the time constraints of different levels can be prioritized and their inheritance relationship calculated according to the preset control level mapping rules. For example, operation level constraints take precedence over resource level constraints to ensure that the extracted time constraints accurately reflect the permission restrictions of the terminal device under the current control level. In other embodiments, the control level time constraints of the permission node can also be dynamically obtained through a policy mapping table, database query, or attribute-based access control model to adapt to policy updates or temporary authorization changes. This application does not limit this.

[0059] It should be noted that the time constraint corresponding to the control level to which the permission node belongs in this application refers to the set of parameters used to limit the time range of the operation that the permission node can perform under the control level associated with the permission node that the terminal device requests to operate; the time constraint includes access start and end time, daily allowed access period, weekly access days and access duration, etc., to characterize the time limit of the terminal device to operate on resources under a specific control level.

[0060] It should be noted that the actual time information mentioned in this application refers to the specific time point when the terminal device initiates each resource request, including timestamp, date, and hour and minute information. This actual time information can be obtained through the system clock module of the IoT gateway, for example, by recording the reception time of the terminal request through a local clock synchronized by a network time protocol or a hardware real-time clock. The acquisition of the actual time information can be carried out immediately when the terminal device initiates a request, or it can be read uniformly after the request reception time is recorded in the gateway message queue. The acquisition frequency can be set according to the access frequency of the terminal device and the policy update cycle. For example, the system clock can be read immediately to obtain the timestamp each time a request is received, or the time cache can be refreshed every 1 millisecond to 1 second to ensure accurate recording of the request time. In other embodiments, the local time information reported by the terminal device itself can also be verified or fused with the gateway clock to enhance time accuracy and security. This application does not limit this.

[0061] For specific implementation, refer to Figure 3 As shown in the figure, this is a schematic diagram of the constraint matching process in some embodiments of this application. The actual time information is matched with the time constraint corresponding to each resource request, and then the permission boundary of the permission node corresponding to each resource request is generated based on the matching result. This can be achieved in the following way: First, the actual time information is converted into a format consistent with the time constraint, for example, the timestamp is converted to year-month-day hour:minute:second or hour:minute only, so as to be compared with the access start and end time and daily or weekly access periods; then, the time constraints of the permission nodes are matched and determined sequentially, including checking whether the actual time falls within the daily allowed time. The system considers factors such as the start and end time of access, whether it falls within a permitted weekday or date, whether it exceeds the duration limit for a single access, and whether it meets the time window for temporary authorization. Next, it generates permission boundaries based on the matching results. When the actual time fully meets all constraints, the permission boundary is set to allow access, and a successful match is recorded. If the actual time exceeds any constraint, the permission boundary is set to deny access, and the reason for denial is noted, such as the request time exceeding the permitted access window. In other implementations, priority rules, inheritance relationships, or dynamic policy adjustments can also be combined to comprehensively calculate the permission boundaries; this application does not limit this approach.

[0062] It should be noted that the permission boundary mentioned in this application refers to the status identifier and related constraint information generated after matching the control level time constraint corresponding to the permission node requested by the terminal device with the actual access time information, which is used to limit whether the permission node is allowed to perform the operation; the permission boundary may include an access allowed or denied identifier, a denial reason, a successful match information and other constraints, to characterize the legality and executability of the terminal device's resource operation under a specific time window and control level.

[0063] In specific implementation, generating access records for each resource request based on the permission boundaries can be achieved in the following way: First, the terminal device identifier, permission node identifier, request time, and matched permission boundaries corresponding to each resource request are used as the basic information of the access record; then, the time constraint information of the control level to which the permission node belongs, the actual request time, the matching result, and the rejection reason (if any) are added as additional attributes to the access record; next, the above information is organized into access records for each resource request according to a preset data structure standard. The preset data structure standard refers to organizing according to unified field naming, type, and hierarchical rules. For example, object notation (JavaScript Object Notation, JSON) can be used. Each access record contains a device identifier field, a permission node field, a request time field, a time constraint field, a matching result field, and a permission boundary field. In other embodiments, other methods can also be used, which are not limited here.

[0064] It should be noted that the access record mentioned in this application refers to a data entry generated for each resource request of the terminal device to record access behavior and permission matching. The access record includes information such as terminal device identifier, permission node identifier, request time, permission boundary, control level time constraint, matching result and rejection reason, so as to comprehensively characterize the resource access behavior of the terminal device under a specific time and control level.

[0065] In step 105, the permission boundaries of different permission nodes are dynamically updated based on the common access characteristics of all access records, and then the access permissions of the terminal device are adjusted according to the update results.

[0066] In some embodiments, dynamically updating the permission boundaries of different permission nodes based on the common access characteristics of all access records can be achieved using the following steps: Identify the common access characteristics of all access records; Determine the dynamic redundancy information between the common access features and the permission boundaries of different permission nodes; The permission boundaries of different permission nodes are updated based on the dynamic redundancy information.

[0067] In specific implementation, determining the common access characteristics of all access records can be achieved in the following way: First, statistical analysis is performed on all access records to extract multiple common access characteristics, which include at least time distribution characteristics, access frequency characteristics, and matching failure characteristics. The time distribution characteristics can be obtained by aggregating the request time field into time periods and statistically analyzing the proportion of requests within different time periods to identify the main concentrated periods of requests. The access frequency characteristics can be obtained by using a sliding time window counting method to calculate the average number of accesses and the peak number of accesses per unit time, thereby determining the normal access level of the terminal device. The matching failure characteristics can be obtained by aggregating and statistically analyzing the reasons for matching failure entries in the access records to identify common conditions leading to access restrictions, such as exceeding time constraints or exceeding access frequency limits. Finally, the above statistical results are used as the common access characteristics of all access records. In other embodiments, cluster analysis, pattern mining, or time series modeling algorithms can also be used to extract patterns of access behavior; this application does not limit this approach.

[0068] It should be noted that the common access features mentioned in this application refer to key feature parameters that can reflect the overall pattern of access behavior, extracted by statistical analysis or pattern mining of all access records of terminal devices. The common access features include time distribution features, access frequency features, and matching failure features, which are used to characterize the access concentration of terminal devices in different time periods, the access frequency per unit time, and the typical reasons for restricted access, thereby providing a basis for dynamic updating of permission boundaries, identification of abnormal behavior, and optimization of policies.

[0069] In specific implementation, determining the dynamic redundancy information between the common access features and the permission boundaries of different permission nodes can be achieved in the following way: First, obtain the common access features of all access records and the currently configured permission boundaries of different permission nodes. The permission boundaries include time constraint ranges, access frequency upper limits, and additional constraints. Then, perform interval comparison based on the time distribution features and the time constraint range. If the actual access concentration time period reflected by the time distribution features strictly falls within the time constraint range of the permission node, the difference between the two is extracted as the redundant time range. Then, perform numerical comparison based on the access frequency features and the access frequency upper limit. If the actual peak access count is less than the access frequency upper limit, the difference between the two is used as the redundant time range. The value range is used as the redundancy frequency margin. Next, the matching failure features are compared with the constraints of the permission boundary. If a certain constraint is not triggered in the access record or does not lead to a failure result for a long time, the constraint is marked as a redundant constraint. Finally, the redundant time range, redundant frequency margin, and redundant constraint are combined to generate the dynamic redundancy information. As a preferred embodiment, the accuracy of redundancy identification can be enhanced by setting a threshold. For example, when the duration of the redundant time range exceeds 15 minutes or the redundant frequency margin exceeds 20% of the configuration limit, it is determined to be valid redundant information. In other embodiments, clustering statistics or pattern mining methods can also be combined to automatically identify the redundant part. This application does not limit this.

[0070] It should be noted that the dynamic redundancy information mentioned in this application refers to a set of permission redundancy parameters that are not fully utilized or have not been triggered for a long time, identified by comparing the common access characteristics of all access records with the permission boundaries currently configured for different permission nodes.

[0071] In specific implementation, updating the permission boundaries of different permission nodes based on the dynamic redundancy information can be achieved in the following way: First, obtain the redundancy time range, redundancy frequency margin, and redundancy constraint conditions identified in the dynamic redundancy information, and match them with the original permission boundary parameters of different permission nodes; then, for the redundancy time range, shrink and update the time constraint range of the permission nodes according to the concentrated access period, that is, remove the part that exceeds the actual concentrated interval to form an optimized time constraint range; then, for the redundancy frequency margin, lower the upper limit of the access frequency of the permission nodes according to the actual peak access number plus a preset margin factor. The update process involves several steps: First, the frequency limit is updated to better align with the normal access levels of terminal devices. Second, for redundant constraints, additional constraints in the permission nodes that have not been triggered or have not resulted in failure are deleted or set to a non-mandatory state to reduce unnecessary restrictions. Third, the updated permission boundary parameters are written into the attribute configuration of the corresponding permission node and synchronously updated in the time capability tree structure to replace the original permission boundaries, thereby updating the permission boundaries of different permission nodes. As a preferred embodiment, a smooth adjustment strategy can be introduced during the update, such as setting a transition interval between the original boundary and the updated boundary to avoid sudden changes in boundary conditions. The sudden fluctuations in terminal access permissions caused by the change are not limited here. As a preferred embodiment, adjusting the terminal device's access permissions based on the update results can be achieved in the following way: First, obtain the updated permission boundaries, which include the updated time constraint range, access frequency limit, and additional constraints. Then, compare the terminal device's permission configuration table on the gateway side with the updated permission boundaries, and replace and update any entries that differ. Specifically, for permission nodes whose redundant time ranges have been removed, their corresponding time constraint intervals are synchronously reduced. For permission nodes whose redundant frequency margins have been corrected, their access frequency limit is synchronously reduced to a safe margin range for the actual peak access count. For permission nodes whose redundant constraints have been deleted, their corresponding additional constraints are marked as invalid and removed from the permission configuration table. Next, write the updated permission configuration table into the terminal device's access control cache and generate a corresponding digital signature capability token to ensure that the update results are consistent between the terminal side and the gateway side. Finally, during the terminal device's access control process, the gateway performs permission verification based on the digital signature capability token, ensuring that the terminal device can only perform access operations within the range defined by the latest permission boundaries, thereby realizing the adjustment of the terminal device's access permissions.

[0072] Furthermore, in another aspect of this application, in some embodiments, this application provides an Internet of Things (IoT) access control system, with reference to... Figure 4The figure is a schematic diagram of the structure of an Internet of Things (IoT) access control system according to some embodiments of this application. The IoT access control system 200 includes: an acquisition module 201, a processing module 202, and an execution module 203, which are described below: The acquisition module 201 in this application is mainly used to acquire the identity attribute information of the terminal device when the IoT gateway receives the network access request initiated by the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. Processing module 202, in this application, is mainly used to perform access verification on the identity attribute information based on the access control policy, and then generate the time capability tree of the terminal device based on the verification result and the time constraints of different control levels. In addition, the processing module 202 in this application is also used to generate a corresponding digital signature token based on the identity attribute information of the terminal device when the terminal device issues a resource request, and to locate the permission node corresponding to each resource request in the time capability tree through the digital signature token; In addition, the processing module 202 in this application is also used to perform time boundary matching on the permission nodes corresponding to each resource request according to the time constraints of different control levels, to obtain the permission boundary of the permission node corresponding to each resource request, and to generate the access record of each resource request based on the permission boundary. The execution module 203 in this application is mainly used to dynamically update the permission boundaries of different permission nodes based on the common access characteristics of all access records, and then adjust the access permissions of the terminal device based on the update results.

[0073] In addition, this application also provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described Internet of Things access control method.

[0074] In some embodiments, reference Figure 5 This figure is an internal structural diagram of a computer device implementing an Internet of Things (IoT) access control method according to some embodiments of this application. The IoT access control method in the above embodiments can be implemented through... Figure 5 The computer device shown is used to implement this, and the computer device 300 includes at least one processor 301, a communication bus 302, a memory 303, and at least one communication interface 304.

[0075] The processor 301 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more devices for controlling the execution of the Internet of Things access control method in this application.

[0076] The communication bus 302 is used to transmit information between the aforementioned components.

[0077] Memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CDROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 303 may exist independently and be connected to processor 301 via communication bus 302. Memory 303 may also be integrated with processor 301.

[0078] The memory 303 stores program code for executing the scheme of this application, and its execution is controlled by the processor 301. The processor 301 executes the program code stored in the memory 303. The program code may include one or more software modules. In the above embodiments, the IoT access control method can be implemented by the processor 301 and one or more software modules in the program code in the memory 303.

[0079] Communication interface 304 uses any transceiver-like device to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0080] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core processor or a multi-core processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0081] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device may be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0082] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described Internet of Things access control method.

[0083] In summary, the IoT access control method, system, device, and storage medium disclosed in this application obtain the identity attribute information of the terminal device when the IoT gateway receives a network access request initiated by the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. Access verification is performed on the identity attribute information based on the access control policy, and a time capability tree for the terminal device is generated based on the verification result and the time constraints of different control levels. When the terminal device issues a resource request, a corresponding digital signature token is generated based on the terminal device's identity attribute information. The digital signature token is used to locate the permission node corresponding to each resource request in the time capability tree. Time boundary matching is performed on the permission nodes corresponding to each resource request based on the time constraints of different control levels to obtain the permission boundary of the permission node corresponding to each resource request, and an access record for each resource request is generated based on the permission boundary. The permission boundaries of different permission nodes are dynamically updated based on the common access characteristics of all access records, and the access permissions of the terminal device are adjusted based on the update result. This allows for dynamic coupling of the temporal characteristics of terminal device access with permission management.

[0084] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0085] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An Internet of Things (IoT) access control method, characterized in that, Includes the following steps: When the IoT gateway receives a network access request initiated by a terminal device, it obtains the identity attribute information of the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. Based on the access control policy, the identity attribute information is access verified, and then the time capability tree of the terminal device is generated based on the verification result and the time constraints of different control levels. When a terminal device issues a resource request, a corresponding digital signature token is generated based on the identity attribute information of the terminal device. The digital signature token is used to locate the permission node corresponding to each resource request in the time capability tree. Based on the time constraints of different control levels, the time boundary matching of the permission nodes corresponding to each resource request is performed to obtain the permission boundary of the permission node corresponding to each resource request, and the access record of each resource request is generated based on the permission boundary. Based on the common access characteristics of all access records, the permission boundaries of different permission nodes are dynamically updated, and then the access permissions of terminal devices are adjusted according to the update results.

2. The method as described in claim 1, characterized in that, The access control policy-based access verification of the identity attribute information specifically includes: Obtain the basic access control rules and control hierarchy permission matrix from the access control policy; The identity attribute information is validated by the basic access rules to obtain the structured validation information of the identity attribute information. Based on the structured verification information, the operation permissions requested by the terminal device in the identity attribute information are extracted; The operation permissions are matched with the control hierarchy permission matrix to obtain the permission matching result of the terminal device; The structured verification information and the permission matching result are merged into the verification result of the identity attribute information.

3. The method as described in claim 1, characterized in that, The generation of the terminal device's time capability tree based on the verification results and time constraints at different control levels specifically includes: Extract the list of valid permissions for each control level from the verification results; Obtain the time constraints corresponding to different preset control levels in the access control policy; Bind the list of valid permissions for each control level to the corresponding time constraints as node attributes in a tree structure; The time capability tree of the terminal device is generated based on the preset hierarchical nesting relationship and the node attributes in the tree structure.

4. The method as described in claim 1, characterized in that, Generating a corresponding digital signature token based on the identity attribute information of the terminal device specifically includes: The token base information of the resource request is extracted from the identity attribute information of the terminal device; The token's basic information is generated based on the private key of the IoT gateway, and then digitally signed. Based on the signature result, a corresponding digitally signed token is generated.

5. The method as described in claim 1, characterized in that, Locating the permission node corresponding to each resource request in the time capability tree using the digital signature token specifically includes: Extract the data to be verified and the digital signature result from the digital signature token; The digital signature result is verified using the public key of the IoT gateway; Based on the verification results, the data to be verified is parsed to obtain the resource identifier information when the terminal device issues a resource request; Based on the resource identification information, the permission node corresponding to each resource request is located from the time capability tree.

6. The method as described in claim 1, characterized in that, Based on the time constraints of different control levels, the time boundaries of the permission nodes corresponding to each resource request are matched to obtain the specific permission boundaries of the permission nodes corresponding to each resource request, including: Determine the time constraints corresponding to the control level to which the permission node belongs for each resource request; Obtain the actual time information of each resource request initiated by the terminal device; The actual time information is matched with the time constraints corresponding to each resource request, and then the permission boundaries of the permission nodes corresponding to each resource request are generated based on the matching results.

7. The method as described in claim 1, characterized in that, Dynamically updating the permission boundaries of different permission nodes based on the common access characteristics of all access records specifically includes: Identify the common access characteristics of all access records; Determine the dynamic redundancy information between the common access features and the permission boundaries of different permission nodes; The permission boundaries of different permission nodes are updated based on the dynamic redundancy information.

8. An Internet of Things (IoT) access control system, characterized in that, include: The acquisition module is used to acquire the identity attribute information of the terminal device when the IoT gateway receives the network access request initiated by the terminal device. The IoT gateway is pre-configured with an access control policy, which includes multiple control levels and corresponding permission nodes. The processing module is used to perform access verification on the identity attribute information based on the access control policy, and then generate a time capability tree of the terminal device based on the verification result and the time constraints of different control levels. The processing module is also used to generate a corresponding digital signature token based on the identity attribute information of the terminal device when the terminal device issues a resource request, and to locate the permission node corresponding to each resource request in the time capability tree through the digital signature token. The processing module is also used to perform time boundary matching on the permission nodes corresponding to each resource request according to the time constraints of different control levels, to obtain the permission boundary of the permission node corresponding to each resource request, and to generate access records for each resource request based on the permission boundary. The execution module is used to dynamically update the permission boundaries of different permission nodes based on the common access characteristics of all access records, and then adjust the access permissions of the terminal device based on the update results.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the Internet of Things access control method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the Internet of Things access control method as described in any one of claims 1 to 7.

Images