An intelligent access control management system for IoT terminal devices

Abstract

The application relates to the technical field of Internet of Things access control, in particular to an intelligent access control management system for an IoT terminal device, which comprises the following modules: an identity authentication module for constructing a hardware trusted identity and completing bidirectional authentication, a trust evaluation module for collecting running environment behavior indexes and calculating dynamic trust values, an access control module for determining a threshold value and generating a strategy, a communication monitoring module for establishing an encrypted link and checking integrity to identify abnormalities, and a disposal tracing module for determining an event level and outputting disposal instructions.In the application, the access permission is adjusted according to the change of trust by continuously binding the device identity and the running risk, the long-term fixed permission after one-time authentication is avoided, the communication abnormality identification and integrity protection capability are improved, the permission recovery isolation disposal and tracing closed loop are formed when the risk is increased, the continuous access risk of a compromised terminal is reduced, and the real-time accuracy and disposal consistency of IoT terminal access management are improved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) access control technology, and more particularly to an intelligent access control management system for IoT terminal devices. Background Technology

[0002] The field of IoT access control technology involves authenticating, determining permissions, and restricting access for IoT terminals, network nodes, and their data packets connected to a communication network. Specifically, intelligent access control management for IoT terminal devices refers to a communication system comprised of IoT terminal devices, access gateways, authentication servers, and a permission database. The terminal device encapsulates its device identifier, identity credentials, and access request into a network packet and sends it to the access gateway. The authentication server reads the device identity records and access rules from the permission database, verifies the request packet, and then returns control information to the access gateway indicating whether access is permitted or denied.

[0003] Existing IoT terminal access control typically relies on static identity credentials and fixed permission rules. The correlation between device hardware characteristics and operating status is insufficient. After authentication, it is difficult to continuously perceive environmental risks and behavioral deviations. Trust judgment tends to remain at the one-time access level. Communication links focus on connectivity but lack linkage monitoring of frequency objects and traffic changes. When anomalies occur, permission adjustment and isolation handling rely on manual experience. Event level classification and traceability are scattered, which leads to compromised devices potentially maintaining access capabilities for a long time. Security response is lagging and management costs are high. Summary of the Invention

[0004] The purpose of this invention is to provide an intelligent access control management system for IoT terminal devices, enabling IoT terminal devices to form a continuous and interconnected security management mechanism during access, trust assessment, access control, communication monitoring, and anomaly handling. Through the collaborative processing of hardware trusted identifiers, temporary authentication keys, dynamic trust values, trust thresholds, access control policies, abnormal communication alarms, and security event levels, dynamic management of the identity trustworthiness, behavior trustworthiness, and communication trustworthiness of IoT terminal devices can be achieved.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: an intelligent access control management system for IoT terminal devices includes: The identity authentication module is used to collect the chip serial number, MAC address and hardware model of IoT terminal devices to construct a trusted hardware identifier, complete two-way authentication based on the trusted hardware identifier and temporary authentication key, and output the identity authentication result. The trust assessment module, connected to the identity authentication module, is used to record the operating status indicators, environmental security indicators, and behavioral characteristic indicators of the IoT terminal device when the identity authentication result is passed, and to determine the AHP indicator weights and calculate the dynamic trust value by combining the logistic regression model. The access control module, connected to the trust evaluation module, is used to dynamically determine the trust threshold based on the dynamic trust value, compare the dynamic trust value and the trust threshold to output the trust status, and generate an access control policy based on the hardware trust identifier and the trust status, combined with the access scenario. The communication monitoring module is connected to the access control module and is used to establish a lightweight encrypted communication link according to the access control policy, perform hash integrity verification on the transmitted data, and issue an abnormal communication alarm when the communication frequency, communication object or data transmission volume meets the abnormal communication conditions. The handling and tracing module is connected to the communication monitoring module and is used to determine the security event level based on the abnormal communication alarm, the trusted status, and the access control policy, and output permission revoke instructions or isolation and handling instructions.

[0006] Specifically, the identity authentication module includes an identifier acquisition submodule, a key negotiation submodule, and an authentication output submodule; The identification acquisition submodule is used to collect chip serial number, MAC address and hardware model, associate and record the acquisition timestamp and acquisition interface number, and generate a hardware trusted identifier. The key negotiation submodule is used to obtain a temporary authentication key, bind and verify the hardware trusted identifier with the temporary authentication key, and generate a two-way authentication status based on the binding and verification result. The authentication output submodule is used to output the authentication result as passed when the two-way authentication status meets the authentication pass conditions, and otherwise output as failed.

[0007] Specifically, the binding verification process is as follows: Obtain the identifier digest value of the trusted hardware identifier and the key validity period of the temporary authentication key, compare whether the identifier digest value is consistent with the preset identifier digest value, and determine whether the current authentication time is within the key validity period; When the comparison results are consistent and the time judgment result is true, an authentication pass status is generated. An authentication rejection status is generated when the comparison results are inconsistent or the time judgment result is invalid.

[0008] Specifically, the trust assessment module includes an indicator recording submodule, a weight determination submodule, and a trust calculation submodule; The indicator recording submodule is used to record the operation status indicators, environmental safety indicators and behavioral characteristic indicators according to a preset sampling period when the identity authentication result is passed, and to mark the missing sample values ​​as invalid, thereby generating a trust evaluation indicator set. The weight determination submodule is used to call the hierarchical analysis weight table according to the category to which each indicator in the trust evaluation index set belongs to determine the category weight and AHP indicator weight. The trust calculation submodule is used to input the category weights, the AHP index weights, and the trust evaluation index set into the logistic regression model and output a dynamic trust value.

[0009] Specifically, the process of determining the weights of the AHP indicators includes: Obtain the hierarchical analysis weight table, and read the category weights corresponding to the operation status index, environmental safety index and behavioral characteristic index respectively from it; When any category weight is missing, the missing category weight is replaced with the historical average weight of the same category, and the consistency of the replaced category weight is checked to generate the AHP index weight.

[0010] Specifically, the calculation process for the dynamic trust value is as follows: The operation status index score, environmental safety index score, and behavioral characteristic index score of the IoT terminal device are obtained. The operation status index score, environmental safety index score, and behavioral characteristic index score are weighted by the AHP index weight to obtain the category intermediate trust score. The intermediate trust score of the category is input into the logistic regression model to obtain the authentication credibility probability output by the logistic regression model. The authentication credibility probability is compared with multiple trust value intervals in the preset trust interval table to determine the target trust value interval hit by the authentication credibility probability. The interval baseline trust value corresponding to the target trust value interval is read from the preset trust interval table, and the interval baseline trust value is linearly calibrated according to the positional relationship of the authentication credibility probability within the target trust value interval to generate the dynamic trust value.

[0011] Specifically, the access control module includes a threshold determination submodule, a state comparison submodule, and a policy generation submodule; The threshold determination submodule is used to obtain the dynamic trust value, device type and access scenario, read the basic threshold corresponding to the device type and access scenario from the threshold configuration table, and adjust the basic threshold according to the trust interval where the dynamic trust value is located to generate a trust threshold. The state comparison submodule is used to compare the dynamic trust value and the trust threshold and output the trust status. The policy generation submodule is used to obtain hardware trusted identifier, trusted status, access scenario and policy mapping table, read device permission range from the policy mapping table according to the hardware trusted identifier, read permission constraint rules from the policy mapping table according to the trusted status, read scenario access rules from the policy mapping table according to the access scenario, and perform intersection matching of the device permission range, the permission constraint rules and the scenario access rules to generate the access control policy.

[0012] Specifically, the process of generating the trust threshold is as follows: Obtain the scenario risk level, device sensitivity level, and historical reliable distribution range from the threshold configuration table. Use the scenario risk level and the device sensitivity level together as the threshold adjustment condition, and use the historical reliable distribution range as the threshold calibration boundary. When the access scenario hits a high-risk access scenario and the dynamic trust value is in the critical trust range, the base threshold is increased and the increased threshold is limited to not exceeding the threshold calibration boundary, and the trust threshold is output.

[0013] Specifically, the communication monitoring module includes a link establishment submodule, a complete verification submodule, and an alarm output submodule; The link establishment submodule is used to obtain the communication permission range and encryption algorithm identifier in the access control policy, obtain the allowed communication objects, allowed port range and allowed session duration in the communication permission range, match the allowed communication objects with the current communication objects, and match the allowed port range with the current communication ports; When both matching results are consistent, the corresponding encryption parameters are loaded according to the encryption algorithm identifier, and the link failure time is written according to the allowed session duration to establish the lightweight encrypted communication link. The complete verification submodule is used to obtain the sequence number, data payload, and link session identifier of the data packets transmitted on the lightweight encrypted communication link, perform joint digest calculation on the sequence number, data payload, and link session identifier, and generate the current hash verification value. The current hash check value is compared with the preset hash check value carried in the packet. When the comparison results match, the complete status is output; when the comparison results do not match, the tampered status is output. The alarm output submodule is used to obtain the number of communication requests, the communication object identifier, and the cumulative data transmission volume within the unit monitoring window, compare the number of communication requests with a frequency threshold, match the communication object identifier with an object whitelist, and compare the cumulative data transmission volume with a traffic threshold. When any one of the following three conditions is met: the number of communication requests exceeds the frequency threshold, the communication object identifier does not match the object whitelist, or the cumulative data transmission volume exceeds the traffic threshold, an abnormal communication state is determined, an abnormal communication alarm is output, and the alarm category and link session identifier are recorded.

[0014] Specifically, the handling and tracing module includes an alarm parsing submodule, a level determination submodule, and an instruction output submodule; The alarm parsing submodule is used to obtain the alarm category and link session identifier in the abnormal communication alarm, and associate the abnormal communication alarm with the trusted state and access control policy to generate an event association record; The level determination submodule is used to obtain the alarm category in the event association record, match the alarm category with the preset level interval table to determine the candidate event level, and verify the candidate event level according to the access control policy. When the access control policy indicates that the current access behavior exceeds the allowed permission range, the verified candidate event level is adjusted to a higher event level and restricted to not exceeding the preset highest level, and the security event level is generated. The instruction output submodule is used to output an access control revoke instruction when the security event level meets the access control reduction condition, and to output an isolation and disposal instruction when the security event level meets the communication blocking condition.

[0015] Compared with the prior art, the advantages and positive effects of the present invention are as follows: An authentication entry point is established through a hardware trusted identifier, which solidifies the chip serial number, MAC address, and hardware model as the device identity root. A two-way verification is formed using a temporary authentication key, providing a basis for binding and updating access decisions. After successful authentication, the operating environment and behavioral indicators are aggregated, and a dynamic trust value is formed through hierarchical weights and regression calculations. This shifts the permission decision-making process from static rules to risk-driven judgment. The trust value and dynamic threshold jointly constrain access scenarios, maintaining necessary permissions for normal access and tightening authorization when risks increase. Encrypted communication integrity verification and abnormal frequency object traffic identification are interconnected. Communication anomalies trigger alarms, and event levels guide permission revocation and isolation tracing, reducing the probability of compromised device access and improving response consistency. Attached Figure Description

[0016] Figure 1 This is a flowchart of the intelligent access control management process for IoT terminal devices according to the present invention; Figure 2 This is a schematic diagram of a campus edge gateway access scenario according to the present invention; Figure 3 This is a schematic diagram illustrating the dynamic trust value generation and strategy mapping effect of the present invention; Figure 4This is a schematic diagram illustrating the monitoring effect of the lightweight encrypted communication link of the present invention; Figure 5 This is a schematic diagram illustrating the traceability effect of abnormal communication alarm handling in this invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0018] Example Please see Figures 1 to 5 This embodiment provides an intelligent access control management system for IoT terminal devices. In practical applications, such as during the network operation process where a temperature and humidity sensor, access controller, energy consumption acquisition gateway, and equipment maintenance terminal are continuously connected to the edge gateway in a park, the edge gateway receives the terminal's network access authentication request, and the security control node maintains the device identification library, key status library, trust evaluation library, policy mapping library, and event traceability library. The core includes an identity authentication module, a trust evaluation module, an access control module, a communication monitoring module, and a handling traceability module.

[0019] The identity authentication module connects to the device access interface of the park's edge gateway. This interface receives network access requests, link reconnection requests, and session renewal requests from IoT terminal devices. The hardware trusted identifier in the identity authentication module is a device identity data object formed by the chip serial number, MAC address, and hardware model. The chip serial number comes from the terminal chip's secure storage area, the MAC address from the communication interface controller, and the hardware model from the device firmware manifest. These fields are written to the identifier cache via the acquisition interface to form the identity record for the same terminal. The temporary authentication key is a short-term key field assigned by the security control node to the current authentication session. The key state database records the key source, validity status, bound object, and expiration identifier. The identity authentication module only uses this key for judging the status of this two-way authentication. The identity authentication result refers to the pass or fail status written to the authentication result cache by the authentication output submodule. The result carries the hardware trusted identifier, authentication session identifier, and authentication failure reason field and is sent to the trust assessment module as the entry point for subsequent processing. The identifier acquisition submodule connects to the terminal security interface, network interface, and firmware reading interface. After the terminal initiates a network access authentication request, the identifier acquisition submodule reads the chip serial number from the terminal security interface, the MAC address from the network interface, and the hardware model from the firmware reading interface, and writes the acquisition timestamp and acquisition interface number into the same identifier record. The identifier acquisition submodule compares session identifiers for duplicate network access requests. If the identifier field carried by the duplicate request matches the cached record, the cached record is inherited; if the fields do not match, an identifier conflict state is generated and sent to the authentication output submodule. The identification acquisition submodule sets an invalid identification status for missing fields. If the chip serial number cannot be read, a security interface read error is recorded; if the MAC address cannot be read, a network interface read error is recorded; if the hardware model cannot be read, a firmware manifest read error is recorded. The invalid identification status and the collected fields are still written to the authentication log. The authentication output submodule receives this status and outputs a failed status. The trust evaluation module does not receive the trust evaluation indicator set for this terminal. The key negotiation submodule connects to the key state database and the identifier cache. After obtaining the temporary authentication key, it binds and verifies the hardware trusted identifier with the temporary authentication key. The identifier digest value in the binding verification refers to the digest field generated by sequentially organizing the chip serial number, MAC address, hardware model, collection timestamp, and collection interface number in the hardware trusted identifier. This field is used to represent the terminal hardware identity within the authentication session. The preset identifier digest value comes from the baseline record of registered devices in the device identifier database. The device identifier database is written by the device network access registration process and refreshed when the device hardware is replaced, the interface is changed, or the operation and maintenance authorization is updated. The key negotiation submodule reads the key validity period field of the temporary authentication key. The key validity period field is derived from the key state database and bound to the authentication session identifier. The binding verification is performed in the order of identifier digest comparison and key state judgment. When the identifier digest value matches the baseline record in the device identifier database and the current authentication time is in the key valid state, the key negotiation submodule generates an authentication passed state. When the identifier digest does not match, the key has expired, the key is not bound to the current hardware trusted identifier, or the key state database returns an error, the key negotiation submodule generates an authentication rejected state.

[0020] The authentication output submodule receives the two-way authentication status output by the key negotiation submodule and converts this status into an authentication result. When the two-way authentication status meets the authentication pass conditions, the authentication output submodule outputs a pass status and sends the hardware trusted identifier, authentication session identifier, and pass status to the trust evaluation module. When the two-way authentication status is an authentication rejection status, identifier conflict status, or invalid identifier status, the authentication output submodule outputs a failure status and writes the rejection reason to the authentication log and event traceability database. The authentication output submodule sets a pending write status for log write failures. The pending write status is entered into the local security cache. After the cache is restored, the log is rewritten according to the authentication session identifier. The failure status does not trigger access control policy generation.

[0021] Trust Assessment Module: This module connects to the identity authentication module and initiates a trust assessment of the current IoT terminal device only when the identity authentication result is successful. Operational Status Indicators refer to a set of fields related to the terminal device's operational health in the current session. These fields are derived from device heartbeat, firmware status, interface status, and resource status. Environmental Security Indicators refer to a set of fields formed by the terminal's access location, network segment security status, edge gateway protection status, and security domain attributes. These fields are derived from access switching nodes, security domain configurations, and edge gateway security logs. Behavioral Feature Indicators refer to a set of fields formed by the terminal's communication behavior, access behavior, and historical policy hit rates. These fields are derived from access control logs, communication monitoring logs, and historical event tracing records. Dynamic Trust Value is a dimensionless trust status field output by the trust calculation submodule based on the above indicators and weight fields. The access control module uses this field to determine the trusted status. The metrics recording submodule, upon successful authentication, reads runtime status metrics, environmental security metrics, and behavioral characteristic metrics from the edge gateway's runtime cache, network security status database, and access log cache according to a preset sampling period. The preset sampling period is a collection rhythm field maintained by the security control node in the policy configuration database. The metrics recording submodule associates each sampling field with the authentication session identifier, hardware trust identifier, and sampling source interface to generate a trust evaluation metric set. The trust evaluation index set refers to a structured evaluation data object formed around the same hardware trust identifier. It contains the index name, index category, index source, sampling status, valid status, previous valid status, and reason for any anomalies. When a sampled value is missing, the field format is inconsistent with the index definition, the source interface returns an error, or duplicates and content conflicts occur within the same sampling period, the index recording submodule marks the corresponding field as invalid. Invalid fields are not included in the trust calculation for the current period. The trust calculation submodule reads the previous valid status or an available field of the same category to form a supplementary record. If there is no previous valid status during the startup phase, the initial baseline status in the policy configuration library is used as the supplementary record, and a startup supplementary identifier is written into the trust evaluation index set. The weight determination submodule reads the category to which each indicator belongs from the trust evaluation indicator set and calls the hierarchical analysis weight table. The hierarchical analysis weight table refers to the weight rule data object maintained by the security control node in the trust evaluation database. It includes category weight fields for operational status categories, environmental security categories, and behavioral characteristic categories, as well as indicator weight fields within each category. Category weights represent the relative influence boundaries of different indicator categories in the trust evaluation, while indicator weights represent the relative influence boundaries of different fields within the same category when entering the evaluation. The weight fields are dimensionless configuration fields, derived from device registration rules, historical security event playback, and policy configurations after operation and maintenance review. The weight determination submodule reads the category weights according to the indicator category, and then reads the AHP indicator weights corresponding to the indicator names under the same category. In this system, AHP indicator weights are weight configurations for individual indicator fields in the hierarchical analysis weight table, and are bound to the indicator's valid status before participating in trust calculation. When any category weight is missing, the weight determination submodule reads the historical average weight of the same category from the trust evaluation library. The historical average weight comes from historical weight versions that have passed operation and maintenance review, and is written to the replacement weight field after reading. The replaced category weights undergo consistency verification. The consistency verification reads the weight version, category boundary, and indicator affiliation relationship to confirm that the replaced weights are consistent with the current device type, access scenario, and indicator category configuration. If the verification passes, an AHP indicator weight set is generated. If the verification fails, a weight abnormality status is sent to the trust calculation submodule, and the access control module is triggered to adopt a conservative trusted state. The Trust Calculation Submodule receives the trust evaluation index set, category weights, and AHP index weight set, and categorizes and organizes the operational status index scores, environmental security index scores, and behavioral characteristic index scores. Operational status index scores are derived from the rule-based results of device heartbeat continuity, firmware status, and interface status; environmental security index scores are derived from the rule-based results of access network segment, protection status, and security domain attributes; and behavioral characteristic index scores are derived from behavioral records associated with the current hardware trust identifier in access control logs and communication monitoring logs. Each type of score undergoes effective status filtering, source interface verification, and normalization processing before entering trust calculation. The normalization criteria are maintained by the trust evaluation library and used to convert different source fields into the same trust level criterion. The trust calculation submodule weights each category score with its corresponding weight field to obtain the intermediate trust score for each category. The intermediate trust score refers to the intermediate state field of valid indicators within the same category after being processed by weighting rules. This field is stored in the trust evaluation cache and includes a category identifier, a supplementary identifier, and an invalid field summary. The logistic regression model in this system is a classification model oriented towards outputting the authentication trust probability. The model inputs are the intermediate trust score, supplementary identifier, invalid field summary, and device type field; the model output is the authentication trust probability. Model training data comes from historical authentication logs, access control logs, communication monitoring logs, and handling traceability records. The annotation rules use historical security event levels, permission revocation records, isolation handling records, and operation and maintenance review results as the boundaries between trustworthy and untrustworthy categories. During training, historical samples are first cleaned according to device type, access scenario, and indicator category. Model parameters are adjusted based on the deviation between the predicted category and the labeled category. Training stops based on the stability of the category determination in the verification records and the consistency of the operation and maintenance review. During the inference phase, the trust calculation submodule reads the authentication trust probability output by the model and compares it with a preset trust interval table. The preset trust interval table refers to a trust state mapping data object maintained in the trust evaluation library, containing different trust value intervals, interval baseline trust values, interval boundary sources, and invocation scenarios. After the authentication trust probability hits the target trust value interval, the trust calculation submodule reads the corresponding interval baseline trust value and performs linear calibration on the interval baseline trust value based on the state of the authentication trust probability within the target trust value interval—whether it's near the boundary or near the center—to generate a dynamic trust value. This dynamic trust value, along with the hardware trust identifier, authentication session identifier, indicator validity status, and model version identifier, is sent to the access control module.

[0022] Access Control Module: Connected to the Trust Assessment Module, it receives dynamic trust values ​​and reads device type, access scenario, and hardware trust identifier to generate a trust status and access control policy. Device type is derived from registered fields in the device identifier library, and access scenario is derived from the resource access type, communication direction, data access object, and current security domain of the edge gateway in the terminal request. Trust status refers to the status identifier generated by the status comparison submodule based on the comparison result of the dynamic trust value and the trust threshold. The status identifier is then entered into the policy generation submodule and the handling traceability module. Access control policy refers to the permission control data object formed based on the current hardware trust identifier and access scenario, including allowed resource scope, communication permission scope, port scope, session constraints, encryption algorithm identifier, audit rules, and permission contraction identifier. The threshold determination submodule reads dynamic trust values, device types, and access scenarios, and retrieves the base threshold from the threshold configuration table. The threshold configuration table is a trust boundary configuration data object maintained in the access policy library, recording device type, access scenario, base threshold, scenario risk level, device sensitivity level, and historical trusted distribution range. The base threshold is derived from device registration rules, security domain access rules, and historical trusted distribution, and is written to the access policy library after policy review. The historical trusted distribution range is derived from the summary of trust records for similar devices in similar access scenarios, serving as the threshold calibration boundary. The threshold determination submodule uses both scenario risk level and device sensitivity level as conditions for threshold increase, and historical trusted distribution intervals as threshold calibration boundaries. When an access scenario hits a high-risk access scenario and the dynamic trust value is within the critical trust interval, the threshold determination submodule increases the base threshold and limits the adjusted result within the threshold calibration boundary to generate a trust threshold. High-risk access scenarios are jointly determined by resource sensitivity level, cross-security domain access attributes, and remote control attributes in the access policy library, and the critical trust interval is provided by a preset trust interval table. When the threshold configuration table fails to read, the threshold determination submodule outputs an abnormal threshold status, the status comparison submodule processes it as a conservative trusted status, and writes the abnormal threshold status to the policy log. State Comparison Submodule: This submodule receives dynamic trust values ​​and trust thresholds, and outputs trusted states according to fixed state comparison rules in the access policy library. When the dynamic trust value reaches the current trust threshold, a trusted identifier is written to the trusted state; when the dynamic trust value does not reach the current trust threshold, an untrusted identifier is written to the trusted state; when the dynamic trust value carries a state of abnormal model output, abnormal weights, excessive indicator supplementation, or abnormal threshold, a restricted trusted identifier is written to the trusted state. The trusted state, along with the hardware trusted identifier and the access scenario, enters the policy generation submodule. The handling and tracing module synchronously reads the trusted state for determining the security event level. The policy generation submodule reads the hardware trust identifier, trust status, access scenario, and policy mapping table. The policy mapping table refers to the permission mapping data object maintained in the access policy library, containing device permission scope, permission constraint rules, and scenario access rules. The device permission scope is read from the device registration record based on the hardware trust identifier, indicating the resource categories and communication boundaries that the current terminal is registered to be allowed to access; the permission constraint rules are read based on the trust status, indicating the permission contraction methods corresponding to trusted, restricted trusted, and untrusted states; the scenario access rules are read based on the access scenario, indicating the access boundaries corresponding to the current business resources, security domains, and communication directions. The policy generation submodule performs intersection matching on device permission scope, permission constraint rules, and scenario access rules. Intersection matching uses resource scope, communication object, port scope, session constraints, and audit rules as field-level matching objects. Fields allowed by all types of rules are written into the access control policy; fields restricted by any rule are marked as restricted fields; and fields denied by any rule are marked as denied fields. When the trusted state is marked as untrusted, the policy generation submodule outputs a "communication prohibited" and "permission revocation pending" flag; when the trusted state is marked as "restricted trusted," the policy generation submodule outputs an access control policy with session constraints and enhanced audit flags. After the access control policy is written to the policy cache, it is sent to the communication monitoring module, and the policy version identifier is synchronously written to the event traceability database.

[0023] Communication Monitoring Module: Connected to the access control module, this module receives access control policies, establishes a lightweight encrypted communication link, and monitors its behavior. A lightweight encrypted communication link refers to a controlled session established between the edge gateway and the IoT terminal device according to the communication permission scope, allowed port range, allowed session duration, and encryption algorithm identifier in the access control policy. The link record includes the link session identifier, current communication object, current communication port, link failure time, and encryption parameter identifier. Hash Integrity Verification: This is a verification mechanism where the integrity verification submodule performs a joint digest of the data packet sequence number, data payload, and link session identifier, and then compares it with a preset hash verification value carried in the packet. The verification result is entered as a link status field into the alarm output submodule. The link establishment submodule reads the communication permission scope and encryption algorithm identifier from the access control policy, and extracts the allowed communication objects, allowed port ranges, and allowed session durations from the communication permission scope. The allowed communication objects are derived from the intersection matching results of the policy generation submodule, the allowed port ranges are derived from the intersection of the scenario access rules and the device permission scope, and the allowed session durations are derived from the session constraint field in the access policy library. The link establishment submodule matches the allowed communication objects with the current communication objects and the allowed port ranges with the current communication ports. When both the communication object and port matches, the link establishment submodule loads the corresponding encryption parameters from the encryption parameter library based on the encryption algorithm identifier and writes the link expiration time according to the allowed session duration, thus forming a lightweight encrypted communication link. When the current communication object does not match an allowed communication object, the current communication port is not within the allowed port range, the encryption parameter library returns an error, or the link failure time writing fails, the link establishment submodule will not establish a communication link and will send a link establishment error status to the alarm output submodule.

[0024] The complete verification submodule, after the lightweight encrypted communication link is established, receives the sequence number, data payload, and link session identifier of the data packets transmitted on the link. The sequence number comes from the terminal communication message header, the data payload comes from the message service data area, and the link session identifier comes from the session record written by the link establishment submodule. The complete verification submodule sorts the above fields sequentially and generates the current hash checksum. The current hash checksum is compared with the preset hash checksum carried in the packet. The preset hash checksum is generated by the sending side according to the same field order and carried in the packet. The receiving side only uses this field to determine whether the transmitted content is consistent. When the current hash check value matches the preset hash check value, the complete verification submodule outputs the complete status and writes the data packet sequence number, link session identifier, and complete status to the communication log; when the comparison results are inconsistent, the complete verification submodule outputs the tampered status and sends the tampered status, data packet sequence number, link session identifier, and current communication object to the alarm output submodule.

[0025] The alarm output submodule reads the communication request frequency field, communication object identifier, and cumulative data transmission volume field from the unit monitoring window. The unit monitoring window contains monitoring boundary fields configured in the communication policy library for the current device type and access scenario. The communication request frequency field originates from the edge gateway's cumulative records of request events under the same link session identifier. The communication object identifier is derived from the current communication packet header, and the cumulative data transmission volume field is derived from continuous records of data payloads in the link session records. The frequency threshold, object whitelist, and traffic threshold are all derived from the communication policy library. The frequency threshold corresponds to the request frequency boundary, the object whitelist corresponds to the set of allowed communication objects, and the traffic threshold corresponds to the data transmission boundary. The alarm output submodule generates abnormal communication states in the order of request frequency verification, communication object verification, and transmission volume verification. When the communication request frequency field reaches the abnormal frequency category, the communication object identifier fails to match the object whitelist, or the cumulative data transmission volume field reaches the abnormal traffic category, the alarm output submodule determines the abnormal communication state and outputs an abnormal communication alarm. An abnormal communication alarm refers to a security alarm data object sent to the handling and tracing module, containing the alarm category, link session identifier, hardware trust identifier, current communication object, access control policy version identifier, trust status reference field, and log index. When multiple abnormal conditions are met simultaneously, the alarm category is written according to the preset alarm priority in the communication policy library. In case of priority conflicts, the alarm category affecting the permission boundary is used as the primary category, and the remaining categories are written to the supplementary category field.

[0026] The handling and tracing module connects to the communication monitoring module. Upon receiving abnormal communication alarms, it correlates the trusted status and access control policy to determine the security event level and output handling instructions. The security event level refers to the level field in the event tracing database that describes the intensity of handling the current abnormal communication alarm. The level is derived from the matching results of alarm category, trusted status, access control policy, and permission out-of-bounds status. The permission revoke instruction is a permission contraction control data object sent to the access control module, used to revoke allowed resources and communication permissions in the current access control policy. The isolation handling instruction is a link blocking control data object sent to the edge gateway and communication monitoring module, used to block the current link session and write the hardware trusted identifier to the isolation list. The alarm parsing submodule reads the alarm category and link session identifier from abnormal communication alarms. Based on the link session identifier, it reads the current communication object, current communication port, data integrity status, and link establishment status from the communication log. Based on the access control policy version identifier, it reads the access control policy from the policy cache. Based on the trusted status reference field, it reads the trusted status from the access control module. These fields are written to the event association record. The event association record refers to the evidence-based data object formed around the same abnormal communication alarm in the event tracing database, including alarm category, link session identifier, hardware trusted identifier, trusted status, access control policy version, log index, permission boundary matching result, and handling status. The alarm parsing submodule sets a traceable completion status for missing logs, invalid policy caches, or failed trusted state references. Tracing the completion status does not change the handling path for abnormal communication alarms. The level determination submodule reads the alarm category and the existing access control policy version to perform level matching under the completion status.

[0027] The level determination submodule reads the alarm categories from the event association records and matches them with the level interval table to determine the candidate event levels. The level interval table is a mapping data object maintained in the event tracing database, mapping alarm categories to event levels. This mapping originates from the communication policy database, access policy database, and historical handling review records. After the candidate event levels are written to the event association records, the level determination submodule reads the allowed resource scope, communication permission scope, port scope, and session constraints from the access control policy and verifies the current access behavior field against these permission boundaries. When the current access behavior exceeds the allowed permissions, the level determination submodule adjusts the candidate event level to a higher level, using the preset highest level as the adjustment boundary, and generates a security event level. When the current access behavior does not exceed the allowed permissions, the candidate event level remains a security event level. When the trusted status is marked as untrusted, the security event level enters the communication blocking condition verification; when the trusted status is marked as restricted trusted and the permission boundary corresponding to the alarm category is abnormal, the security event level enters the permission contraction condition verification. When the level range table cannot match the alarm category, the level determination submodule reads the default security event level from the event tracing database and writes a level pending review flag. The instruction output submodule receives the security event level, trust status, and access control policy, and reads the handling rule table. The handling rule table is a mapping data object maintained in the event tracing database that maps event levels to handling actions, including permission reduction conditions, communication blocking conditions, instruction recipients, and confirmation receipt rules. When the security event level meets the permission reduction conditions, the instruction output submodule outputs a permission revoke instruction. This instruction carries a hardware trust identifier, access control policy version identifier, the permission to be revoked field, and an event-related record index. Upon receiving this instruction, the access control module updates the policy cache and revokes the corresponding access permissions. When a security incident meets the communication blocking criteria, the instruction output submodule outputs an isolation and handling instruction. This instruction carries a hardware trusted identifier, a link session identifier, an isolation list identifier, and an event association record index. Upon receiving this instruction, the communication monitoring module terminates the lightweight encrypted communication link, and the edge gateway rejects any new link requests initiated by the same hardware trusted identifier. The instruction output submodule waits for a confirmation receipt from the instruction recipient, which is then written to the event association record. If no confirmation receipt is received, the instruction output submodule writes the instruction to a pending confirmation status and resubmits the instruction to the corresponding recipient according to the handling rule table. After handling, the event association record retains the authentication log index, trust evaluation cache index, policy log index, and communication log index, forming a traceable link from identity authentication, trust evaluation, policy generation, communication monitoring to handling output.

[0028] During system operation, the hardware trusted identifier and authentication result output by the identity authentication module serve as input to the trust assessment module. The dynamic trust value output by the trust assessment module serves as input to the access control module. The access control policy output by the access control module serves as the basis for link establishment and anomaly judgment by the communication monitoring module. The abnormal communication alarm output by the communication monitoring module serves as the basis for level determination by the handling and tracing module. The permission revoke command or isolation handling command output by the handling and tracing module is written back to the access control module and the communication monitoring module. Each module establishes field-level associations through the hardware trusted identifier, authentication session identifier, link session identifier, and event association record index. Authentication failure, invalid indicators, weight anomalies, threshold anomalies, link anomalies, verification anomalies, and command pending confirmation status are all written to the corresponding logs and entered into the event tracing database. The security control node controls the log reading scope according to access permissions, and the operation and maintenance terminal traces the authentication field, trust field, policy field, link field, and handling field through the event association record index.

[0029] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. An intelligent access control management system for IoT terminal devices, characterized in that, include: The identity authentication module is used to collect the chip serial number, MAC address and hardware model of IoT terminal devices to construct a trusted hardware identifier, complete two-way authentication based on the trusted hardware identifier and temporary authentication key, and output the identity authentication result. The trust assessment module, connected to the identity authentication module, is used to record the operating status indicators, environmental security indicators, and behavioral characteristic indicators of the IoT terminal device when the identity authentication result is passed, and to determine the AHP indicator weights and calculate the dynamic trust value by combining the logistic regression model. The access control module, connected to the trust evaluation module, is used to dynamically determine the trust threshold based on the dynamic trust value, compare the dynamic trust value and the trust threshold to output the trust status, and generate an access control policy based on the hardware trust identifier and the trust status, combined with the access scenario. The communication monitoring module is connected to the access control module and is used to establish a lightweight encrypted communication link according to the access control policy, perform hash integrity verification on the transmitted data, and issue an abnormal communication alarm when the communication frequency, communication object or data transmission volume meets the abnormal communication conditions. The handling and tracing module is connected to the communication monitoring module and is used to determine the security event level based on the abnormal communication alarm, the trusted status, and the access control policy, and output permission revoke instructions or isolation and handling instructions.

2. The intelligent access control management system for IoT terminal devices according to claim 1, characterized in that, The identity authentication module includes an identifier acquisition submodule, a key negotiation submodule, and an authentication output submodule; The identification acquisition submodule is used to collect chip serial number, MAC address and hardware model, associate and record the acquisition timestamp and acquisition interface number, and generate a hardware trusted identifier. The key negotiation submodule is used to obtain a temporary authentication key, bind and verify the hardware trusted identifier with the temporary authentication key, and generate a two-way authentication status based on the binding and verification result. The authentication output submodule is used to output the authentication result as passed when the two-way authentication status meets the authentication pass conditions, and otherwise output as failed.

3. The intelligent access control management system for IoT terminal devices according to claim 2, characterized in that, The binding verification process is as follows: Obtain the identifier digest value of the trusted hardware identifier and the key validity period of the temporary authentication key, compare whether the identifier digest value is consistent with the preset identifier digest value, and determine whether the current authentication time is within the key validity period; When the comparison results are consistent and the time judgment result is true, an authentication pass status is generated. An authentication rejection status is generated when the comparison results are inconsistent or the time judgment result is invalid.

4. The intelligent access control management system for IoT terminal devices according to claim 1, characterized in that, The trust assessment module includes an indicator recording submodule, a weight determination submodule, and a trust calculation submodule; The indicator recording submodule is used to record the operation status indicators, environmental safety indicators and behavioral characteristic indicators according to a preset sampling period when the identity authentication result is passed, and to mark the missing sample values ​​as invalid, thereby generating a trust evaluation indicator set. The weight determination submodule is used to call the hierarchical analysis weight table according to the category to which each indicator in the trust evaluation index set belongs to determine the category weight and AHP indicator weight. The trust calculation submodule is used to input the category weights, the AHP index weights, and the trust evaluation index set into the logistic regression model and output a dynamic trust value.

5. The intelligent access control management system for IoT terminal devices according to claim 4, characterized in that, The process of determining the weights of the AHP indicators specifically includes: Obtain the hierarchical analysis weight table, and read the category weights corresponding to the operation status index, environmental safety index and behavioral characteristic index respectively from it; When any category weight is missing, the missing category weight is replaced with the historical average weight of the same category, and the consistency of the replaced category weight is checked to generate the AHP index weight.

6. The intelligent access control management system for IoT terminal devices according to claim 5, characterized in that, The calculation process for the dynamic trust value is as follows: The operation status index score, environmental safety index score, and behavioral characteristic index score of the IoT terminal device are obtained. The operation status index score, environmental safety index score, and behavioral characteristic index score are weighted by the AHP index weight to obtain the category intermediate trust score. The intermediate trust score of the category is input into the logistic regression model to obtain the authentication credibility probability output by the logistic regression model. The authentication credibility probability is compared with multiple trust value intervals in the preset trust interval table to determine the target trust value interval hit by the authentication credibility probability. The interval baseline trust value corresponding to the target trust value interval is read from the preset trust interval table, and the interval baseline trust value is linearly calibrated according to the positional relationship of the authentication credibility probability within the target trust value interval to generate the dynamic trust value.

7. The intelligent access control management system for IoT terminal devices according to claim 1, characterized in that, The access control module includes a threshold determination submodule, a state comparison submodule, and a policy generation submodule; The threshold determination submodule is used to obtain the dynamic trust value, device type and access scenario, read the basic threshold corresponding to the device type and access scenario from the threshold configuration table, and adjust the basic threshold according to the trust interval where the dynamic trust value is located to generate a trust threshold. The state comparison submodule is used to compare the dynamic trust value and the trust threshold and output the trust status. The policy generation submodule is used to obtain hardware trusted identifier, trusted status, access scenario and policy mapping table, read device permission range from the policy mapping table according to the hardware trusted identifier, read permission constraint rules from the policy mapping table according to the trusted status, read scenario access rules from the policy mapping table according to the access scenario, and perform intersection matching of the device permission range, the permission constraint rules and the scenario access rules to generate the access control policy.

8. The intelligent access control management system for IoT terminal devices according to claim 7, characterized in that, The process of generating the trust threshold is as follows: Obtain the scenario risk level, device sensitivity level, and historical reliable distribution range from the threshold configuration table. Use the scenario risk level and the device sensitivity level together as the threshold adjustment condition, and use the historical reliable distribution range as the threshold calibration boundary. When the access scenario hits a high-risk access scenario and the dynamic trust value is in the critical trust interval, the base threshold is increased and the increased threshold is limited to not exceeding the threshold calibration boundary, and the trust threshold is output.

9. The intelligent access control management system for IoT terminal devices according to claim 1, characterized in that, The communication monitoring module includes a link establishment submodule, a complete verification submodule, and an alarm output submodule; The link establishment submodule is used to obtain the communication permission range and encryption algorithm identifier in the access control policy, obtain the allowed communication objects, allowed port range and allowed session duration in the communication permission range, match the allowed communication objects with the current communication objects, and match the allowed port range with the current communication ports; When both matching results are consistent, the corresponding encryption parameters are loaded according to the encryption algorithm identifier, and the link failure time is written according to the allowed session duration to establish the lightweight encrypted communication link. The complete verification submodule is used to obtain the sequence number, data payload, and link session identifier of the data packets transmitted on the lightweight encrypted communication link, perform joint digest calculation on the sequence number, data payload, and link session identifier, and generate the current hash verification value. The current hash check value is compared with the preset hash check value carried in the packet. When the comparison results match, the complete status is output; when the comparison results do not match, the tampered status is output. The alarm output submodule is used to obtain the number of communication requests, the communication object identifier, and the cumulative data transmission volume within the unit monitoring window, compare the number of communication requests with a frequency threshold, match the communication object identifier with an object whitelist, and compare the cumulative data transmission volume with a traffic threshold. When any one of the following three conditions is met: the number of communication requests exceeds the frequency threshold, the communication object identifier does not match the object whitelist, or the cumulative data transmission volume exceeds the traffic threshold, an abnormal communication state is determined, an abnormal communication alarm is output, and the alarm category and link session identifier are recorded.

10. The intelligent access control management system for IoT terminal devices according to claim 1, characterized in that, The handling and tracing module includes an alarm parsing submodule, a level determination submodule, and an instruction output submodule; The alarm parsing submodule is used to obtain the alarm category and link session identifier in the abnormal communication alarm, and associate the abnormal communication alarm with the trusted state and access control policy to generate an event association record; The level determination submodule is used to obtain the alarm category in the event association record, match the alarm category with the preset level interval table to determine the candidate event level, and verify the candidate event level according to the access control policy. When the access control policy indicates that the current access behavior exceeds the allowed permission range, the verified candidate event level is adjusted to a higher event level and restricted to not exceeding the preset highest level, and the security event level is generated. The instruction output submodule is used to output an instruction to revoke permissions when the security event level meets the permission reduction condition. When the security event level meets the communication blocking conditions, an isolation and disposal command is output.

Images