Access control system and method for an internet of things device

Abstract

The application provides an access control system and method of an Internet of Things device, the method comprising: obtaining a behavior deviation amount of the Internet of Things device within a specified time period, generating an attribute encryption credential based on the behavior deviation amount and an initial trust level of the Internet of Things device; in response to the Internet of Things device initiating an access request to a target resource, calling a trusted execution environment to parse the attribute encryption credential and extract a set of permission constraint attributes; taking the set of permission constraint attributes and a security level tag bound to the target resource as input parameters of a key derivation function to generate a one-time session key, wherein an authorization range of the one-time session key is determined by a logical conjunction of the set of permission constraint attributes and the security level tag; and distributing the one-time session key to the Internet of Things device, so that the Internet of Things device establishes an encrypted communication session with the target resource within the authorization range. The scheme of the application can realize adaptive minimum permission encrypted communication session establishment driven by a device behavior deviation amount.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) security technology, and more specifically, to an access control system and method for IoT devices. Background Technology

[0002] With the widespread adoption of various IoT devices in industrial control, vehicle networking, and smart grids, a massive number of terminals frequently initiate resource access requests. The security of the communication process heavily relies on the protection of session keys. If a device is hijacked or exhibits abnormal behavior, attackers can use their legitimate identity and currently held keys to laterally access sensitive resources. However, traditional access control mechanisms are mostly based on static identities and preset policies, lacking the ability to perceive real-time changes in the behavior and state of devices during operation. This results in the inability to dynamically adjust the scope of key authorization in accordance with fluctuations in device trustworthiness, posing a continuous threat to system security.

[0003] Existing methods typically separate device authentication, behavior assessment, and session key derivation into relatively independent steps. A prominent problem is that the session key generated after initial device authentication often has an authorization scope bound to the device's initial identity, making it difficult to reflect the actual degree of behavioral deviation during operation. For example, when a device's firmware is tampered with, its communication mode changes abruptly, or its access behavior exhibits obvious anomalies, it can still request sensitive operations using a session key with a broad authorization scope. The security mechanism does not trigger any adaptive convergence at the key level. In other words, the session key's authorization boundary is static, while the device's actual trusted state is dynamically changing. This disconnect provides opportunities for privilege abuse and the amplification of internal threats. Therefore, how to achieve adaptive least privilege encrypted communication session establishment driven by device behavior deviation has become a challenging problem for the industry. Summary of the Invention

[0004] This application provides an access control system and method for Internet of Things (IoT) devices, which can realize the establishment of adaptive least privilege encrypted communication sessions driven by device behavior deviation.

[0005] In a first aspect, this application provides an access control method for an Internet of Things (IoT) device, comprising the following steps: The behavior deviation of an IoT device within a specified time period is obtained. An attribute encryption credential is generated based on the behavior deviation and the initial trust level of the IoT device. The attribute encryption credential embeds a set of permission constraint attributes to limit the resource access scope currently granted to the IoT device. In response to the IoT device initiating an access request to the target resource, a trusted execution environment is invoked to parse the attribute encryption credential and extract the permission constraint attribute set; The permission constraint attribute set and the security level label bound to the target resource are used together as input parameters of the key derivation function to generate a one-time session key. The authorization scope of the one-time session key is determined by the logical conjunction of the permission constraint attribute set and the security level label, and does not exceed the resource access scope initially granted to the IoT device. The one-time session key is distributed to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope.

[0006] Preferably, before obtaining the behavioral deviation of the IoT device within a specified time period, the method further includes: During the device registration phase, identity certificates are issued to IoT devices and an initial trust level is assigned. Behavioral data of the IoT devices are collected within a security baseline period to construct a behavioral baseline model, which includes device communication patterns, access frequency, and protocol compliance characteristics.

[0007] Preferably, obtaining the behavioral deviation of IoT devices within a specified time period specifically includes: Collect real-time behavioral data of the IoT device within the specified time period; The real-time behavioral data is compared with the pre-built behavioral baseline model to calculate the deviation of communication mode, access frequency, and protocol compliance. Based on preset fuzzy rules, the deviation of the communication mode, the deviation of the access frequency, and the deviation of the protocol compliance are fuzzily fused to obtain the behavioral deviation of the IoT device within a specified time period.

[0008] Preferably, before performing fuzzy fusion on the communication mode deviation, access frequency deviation, and protocol compliance deviation based on preset fuzzy rules, the method further includes: identifying the current operating scenario of the IoT device, wherein the operating scenario is divided according to the historical behavior cycle of the IoT device and the preset working condition label of the device type.

[0009] Preferably, based on preset fuzzy rules, the fuzzy fusion of the communication mode deviation, access frequency deviation, and protocol compliance deviation specifically includes: The parameters of the input membership function are dynamically adjusted based on the identified operating scenario. Among the parameters, a wide-boundary membership function is set for production scenarios with high behavioral volatility, and a narrow-boundary membership function is set for operation and maintenance scenarios with stable behavioral patterns. Using the adjusted input membership function, the communication mode deviation, access frequency deviation, and protocol compliance deviation are fuzzified respectively to obtain the fuzzy subsets and membership degrees corresponding to each deviation. The fuzzy subsets and membership degrees are input into a preset fuzzy rule base for inference; The fuzzy rule base contains differentiated rule weights set for different operating scenarios. In scenarios with high behavioral volatility, the rule weight of the access frequency deviation is increased, and in scenarios with stable behavioral patterns, the rule weight of the protocol compliance deviation is increased. The comprehensive fuzzy set output by fuzzy inference is defuzzified to obtain the behavioral deviation of the IoT device in the current operating scenario.

[0010] Preferably, generating attribute encryption credentials based on the behavioral deviation and the initial trust level of the IoT device specifically includes: The initial trust level and the behavioral deviation are input into a preset trust decay function to calculate the current trust value; Based on the trust interval into which the current trust value falls, the corresponding set of permission constraint attributes is searched from the preset permission mapping table; The attribute encryption algorithm is invoked, using the identity identifier of the IoT device as the public key, and the permission constraint attribute set as the encryption attribute embedding credential to generate the attribute encryption credential and set the validity period.

[0011] Preferably, in response to the IoT device initiating an access request to the target resource, the trusted execution environment is invoked to parse the attribute encryption credential and extract the permission constraint attribute set, specifically including: Receive an access request sent by the IoT device, the access request carrying the attribute encryption credential and the target resource identifier; The attribute encryption credential is passed into a trusted execution environment to verify the credential signature and validity period. After successful verification, the attribute encryption credential is decrypted, the permission constraint attribute set is extracted, and the extracted result is signed and transmitted out of the trusted execution environment.

[0012] Preferably, generating a one-time session key by using the set of permission constraint attributes and the security level label bound to the target resource as input parameters for the key derivation function specifically includes: Query the security level label bound to the target resource, and obtain the set of allowed operation types, the minimum required trust level, and the mutual exclusion and dependency constraints between operations defined by the security level label; Using the operation permissions defined by the permission constraint attribute set as the initial search space, the allowed operation type set as the boundary conditions, and the mutual exclusion constraints and dependency constraints as rigid constraints, a permission minimization objective function is constructed. Solve the objective function of minimizing permissions, remove operation permissions that do not satisfy the rigid constraints from the initial search space, and prune the remaining operation permissions according to the risk cost to obtain the set of operation permissions that satisfy the principle of least permission; The constrained set of operation permissions, the current trust value, the session random number, and the timestamp are concatenated and used as the derivation material for the key derivation function to generate a one-time session key. The constrained set of operation permissions is associated with the one-time session key and output.

[0013] Preferably, distributing the one-time session key to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope, specifically includes: The one-time session key is encrypted using a preset transmission public key to generate key ciphertext; Send the key ciphertext and the constrained set of operation permissions to the IoT device; After the IoT device decrypts and obtains the one-time session key, it performs a key confirmation handshake with the target resource and establishes an encrypted communication session within the scope of the constrained set of operation permissions.

[0014] Secondly, this application provides an access control system for Internet of Things (IoT) devices, the system comprising: The acquisition module is used to acquire the behavioral deviation of the IoT device within a specified time period, and generate an attribute encryption credential based on the behavioral deviation and the initial trust level of the IoT device. The attribute encryption credential embeds a set of permission constraint attributes to limit the resource access scope currently granted to the IoT device. The processing module is used to respond to the IoT device's request to access the target resource by calling a trusted execution environment to parse the attribute encryption credential and extract the permission constraint attribute set. The processing module is further configured to use the permission constraint attribute set and the security level label bound to the target resource as input parameters of the key derivation function to generate a one-time session key. The authorization scope of the one-time session key is determined by the logical conjunction of the permission constraint attribute set and the security level label, and does not exceed the resource access scope initially granted to the IoT device. An execution module is used to distribute the one-time session key to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: This application achieves adaptive least-privilege encrypted communication session establishment driven by device behavior deviation through the synergistic effect of scenario-adaptive fuzzy inference, trust decay credential mapping, and permission minimization optimization. First, a scenario-aware mechanism is introduced in the behavior evaluation phase, dynamically adjusting the membership function boundary width and fuzzy rule weights according to the production or maintenance scenario. This enables deviation calculation to distinguish between normal process fluctuations and actual abnormal deviations, providing accurate and robust quantitative basis for dynamic permission adjustment. Second, a permission minimization objective function is constructed in the key derivation phase. Using inter-operation mutual exclusion and dependency constraints as rigid limitations, constraint checks and risk pruning are performed on the permission set, transforming permission determination into an optimization process subject to multiple constraints. This achieves a mechanism shift from passive matching to active convergence of the authorization scope. Finally, the constrained set of operation permissions is used as a necessary component of the key derivation material, forcibly limiting the authorization scope of the one-time session key to the minimum permission set through cryptographic means. This decentralizes permission control to the cryptographic primitive level, ensuring that attackers cannot breach the authorization boundary even after the session key is leaked. In summary, this application constructs a complete closed loop from behavior perception to cryptographic permission convergence by embedding permission minimization constraints in the key derivation stage, which greatly improves the permission convergence capability of IoT systems when faced with abnormal device behavior. Attached Figure Description

[0016] Figure 1 This is an exemplary flowchart of an access control method for an Internet of Things (IoT) device according to some embodiments of this application; Figure 2 This is a schematic diagram illustrating an application scenario of the access control method for IoT devices according to some embodiments of this application; Figure 3 This is a flowchart illustrating the determination of behavioral deviation according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of an access control system for an Internet of Things (IoT) device according to some embodiments of this application; Figure 5 This is a schematic diagram of the structure of a computer device that implements an access control method for Internet of Things (IoT) devices according to some embodiments of this application. Detailed Implementation

[0017] To better understand the technical solution of this application, the technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] refer to Figure 1 The figure is an exemplary flowchart of an access control method for an IoT device according to some embodiments of this application. The access control method for the IoT device mainly includes the following steps: Step 101: Obtain the behavioral deviation of the IoT device within a specified time period, and generate an attribute encryption credential based on the behavioral deviation and the initial trust level of the IoT device. The attribute encryption credential embeds a set of permission constraint attributes to limit the resource access scope currently granted to the IoT device.

[0019] In some embodiments, reference Figure 2 As shown in the figure, this figure is a schematic diagram of an application scenario of an access control method for an IoT device according to some embodiments of this application. The figure includes four main components: an IoT device, an access control server, a target resource, and a data storage device. The IoT device initiates an access request to the target resource and reports behavioral data to the access control server. It sends the behavioral data and access request to the access control server through a communication network. The execution code of the access control method is run in the access control server. Based on the behavioral deviation, an attribute encryption credential is generated and a one-time session key is issued. The IoT device uses the key to establish an encrypted communication session with the target resource. Finally, the access control server stores the processed credential and access record in the data storage device.

[0020] In some embodiments, before obtaining the behavioral deviation of the IoT device within a specified time period, the method further includes: during the device registration phase, issuing an identity certificate for the IoT device and assigning an initial trust level; collecting behavioral data of the IoT device within a security baseline period, and constructing a behavioral baseline model, wherein the behavioral baseline model includes device communication patterns, access frequencies, and protocol compliance characteristics.

[0021] In specific implementation, during the device registration phase, the registration server generates a unique identity identifier for the IoT device and calls the certificate issuance module to generate an identity certificate embedding this identity identifier and the device's public key. The identity certificate is then written into the device's secure storage. Simultaneously, based on the device type, deployment location, and a pre-defined allocation strategy based on the manufacturer's reputation, an initial trust level is assigned to the device, and this initial trust level is written into the trust management database. Within the security baseline period set after the IoT device is deployed, traffic probes deployed on the network side or proxy modules on the device side collect the device's communication traffic logs, access request timestamps, and protocol interaction messages as behavioral data. Statistical analysis is performed on the collected behavioral data. The distribution of communication destination addresses and ports is extracted as the device's communication mode. The mean and standard deviation of the number of accesses per unit time are calculated as the access frequency. The compliance rate of the transport layer security protocol handshake version and the correctness rate of the message format are extracted as protocol compliance features. The device's communication mode, access frequency, and protocol compliance features are encoded into feature vectors, which are then used as the behavioral baseline model of the IoT device.

[0022] In some embodiments, reference Figure 3As shown in the figure, this is a schematic flowchart illustrating the determination of behavioral deviation according to some embodiments of this application. In this embodiment, obtaining the behavioral deviation of an IoT device within a specified time period can be achieved through the following steps: In step 1011, real-time behavioral data of the IoT device is collected within the specified time period; In step 1012, the real-time behavior data is compared with the pre-built behavior baseline model to calculate the communication mode deviation, access frequency deviation, and protocol compliance deviation. In step 1013, based on preset fuzzy rules, the communication mode deviation, access frequency deviation and protocol compliance deviation are fuzzily fused to obtain the behavioral deviation of the IoT device within a specified time period.

[0023] The communication mode deviation in this application is an indicator used to measure the degree of change in the communication connection objects and connection methods of IoT devices; the access frequency deviation is an indicator used to measure the degree of abnormality in the access request initiation rate of IoT devices; the protocol compliance deviation is an indicator used to measure the degree of degradation of the security compliance level of the communication protocol of IoT devices; and the behavior deviation is an indicator used to comprehensively measure the degree of deviation of the overall behavior of IoT devices from the baseline.

[0024] In specific implementation, the real-time behavior data of the IoT device within the specified time period can be collected in the following way: A traffic probe deployed on the network side acquires the communication traffic data packets of the IoT device within the specified time period using mirroring or splitting methods, and parses out the communication quintuple, communication protocol type, and message payload length information from them; simultaneously, a proxy module deployed on the device side records the timestamp and target resource identifier of each access request initiated by the IoT device within this time period; in addition, the proxy module also extracts the transport layer security handshake version number, certificate chain verification result, and message format verification result from all protocol interaction messages within this time period; the information parsed from the communication traffic data packets is used as a real-time communication traffic log, the recorded access request timestamp and target resource identifier are used as real-time access request records, and the extracted handshake version number, certificate chain verification result, and message format verification result are used as real-time protocol interaction features. These three types of data together constitute the real-time behavior data of the IoT device within the specified time period.

[0025] It should be noted that the specified time period in this application refers to a preset time window used to collect real-time behavioral data of IoT devices to assess the deviation of their current behavior. For example, the specified time period can be set to the time interval of the most recent five minutes before the current moment, or to a fixed-duration observation window that slides forward from the current moment.

[0026] In specific implementation, the real-time behavior data is compared with the pre-built behavior baseline model to calculate the communication mode deviation, access frequency deviation, and protocol compliance deviation. This can be achieved in the following ways: Real-time communication traffic logs are extracted from the real-time behavior data. The distribution of communication destination addresses and ports parsed from the real-time communication traffic logs are compared with the baseline device communication modes in the behavior baseline model, and the relative entropy between the two distributions is calculated as the communication mode deviation. Real-time access request records are extracted from the real-time behavior data. The number of accesses per unit time within the specified time period is counted, and the deviation multiple between the number of accesses per unit time and the mean and standard deviation of the baseline access frequency in the behavior baseline model is calculated as the access frequency deviation. Real-time protocol interaction features are extracted from the real-time behavior data. The transport layer security handshake version compliance rate and message format correctness rate in the real-time protocol interaction features are compared one by one with the baseline protocol compliance features in the behavior baseline model. The decrease in the two indicators is calculated, and the average of the decreases is used to obtain the protocol compliance deviation.

[0027] In some embodiments, before performing fuzzy fusion on the communication mode deviation, access frequency deviation, and protocol compliance deviation based on preset fuzzy rules, the method further includes: identifying the current operating scenario of the IoT device. The operating scenario is divided according to the historical behavior cycle of the IoT device and preset operating condition labels for the device type, and can be implemented in the following way: obtaining the behavior time series of the IoT device within its historical operating cycle; extracting periodic features from the behavior time series; identifying high-frequency active periods and low-frequency quiet periods; marking the high-frequency active periods as production-type periodic windows and the low-frequency quiet periods as maintenance-type periodic windows; querying the IoT device management database... The system identifies the equipment type and searches for the corresponding operating condition label in a preset operating condition label mapping table. The operating condition labels include production operation labels and maintenance and repair labels. The system matches the current time window with the production cycle window and the operation and maintenance cycle window, and combines this with the operating condition label to determine the current operating scenario. When the current time falls within the production cycle window and the operating condition label is the production operation label, the current operating scenario is identified as a production scenario with high behavioral fluctuations. When the current time falls within the operation and maintenance cycle window and the operating condition label is the maintenance and repair label, the current operating scenario is identified as an operation and maintenance scenario with stable behavioral patterns. The identified operating scenario identifier is then output to the fuzzy inference engine.

[0028] Preferably, in some embodiments, the communication mode deviation, access frequency deviation, and protocol compliance deviation are fuzzily fused based on preset fuzzy rules, which can be achieved by the following steps: The parameters of the input membership function are dynamically adjusted based on the identified operating scenario. Among the parameters, a wide-boundary membership function is set for production scenarios with high behavioral volatility, and a narrow-boundary membership function is set for operation and maintenance scenarios with stable behavioral patterns. Using the adjusted input membership function, the communication mode deviation, access frequency deviation, and protocol compliance deviation are fuzzified respectively to obtain the fuzzy subsets and membership degrees corresponding to each deviation. The fuzzy subsets and membership degrees are input into a preset fuzzy rule base for inference; The fuzzy rule base contains differentiated rule weights set for different operating scenarios. In scenarios with high behavioral volatility, the rule weight of the access frequency deviation is increased, and in scenarios with stable behavioral patterns, the rule weight of the protocol compliance deviation is increased. The comprehensive fuzzy set output by fuzzy inference is defuzzified to obtain the behavioral deviation of the IoT device in the current operating scenario.

[0029] It should be noted that the differentiated rule weights in this application refer to the coefficients used to adjust the contribution of each deviation degree to the behavioral deviation amount under different operating scenarios.

[0030] It should also be noted that the fuzzy rules in this application can be preset in the following way: First, define the linguistic value set of the input and output variables of the fuzzy inference engine, and divide the communication mode deviation, access frequency deviation, and protocol compliance deviation into three fuzzy subsets: low deviation, medium deviation, and high deviation. Divide the behavioral deviation into four fuzzy subsets: normal, slightly abnormal, moderately abnormal, and severely abnormal. Then, based on expert knowledge in the field of industrial control and statistical patterns of historical behavioral data of IoT devices, construct a fuzzy inference rule table. Each rule in the fuzzy inference rule table consists of a premise part and a conclusion part. The premise part consists of the communication mode deviation, access frequency deviation, and protocol compliance deviation. The logic and combination of the fuzzy subsets to which each protocol compliance deviation belongs constitute the conclusion part, which is the fuzzy subset to which the behavior deviation belongs. Finally, an initial rule weight is assigned to each rule in the fuzzy inference rule table, and the rule weights are set differently according to the operating scenario. In the production scenario with high behavior volatility, the initial rule weight of the rule with access frequency deviation as a prerequisite is multiplied by a coefficient greater than 1 to obtain the adjusted rule weight. In the operation and maintenance scenario with stable behavior pattern, the initial rule weight of the rule with protocol compliance deviation as a prerequisite is multiplied by a coefficient greater than 1 to obtain the adjusted rule weight. The fuzzy inference rule table with differentiated rule weights is used as the preset fuzzy rule library.

[0031] In practice, the fuzzy inference engine first dynamically adjusts the parameters of the input membership function based on the running scenario identifier. When the running scenario identifier indicates that the current scenario is a production scenario with high behavioral volatility, the width parameter of the input membership function is increased, so that the coverage of the low deviation membership function expands to the high deviation direction, and the coverage of the high deviation membership function expands to the low deviation direction. The adjusted width parameter is used as the parameter of the wide boundary membership function. When the running scenario identifier indicates that the current scenario is an operation and maintenance scenario with stable behavior patterns, the width parameter of the input membership function is decreased, so that the coverage of the low deviation membership function shrinks to the low deviation direction, and the coverage of the high deviation membership function shrinks to the high deviation direction. The adjusted width parameter is used as the parameter of the narrow boundary membership function. Secondly, the fuzzy inference engine uses the adjusted wide-boundary membership function or narrow-boundary membership function to fuzzify the communication mode deviation, access frequency deviation, and protocol compliance deviation, respectively. For each deviation, the function value of its value under the three membership functions of low deviation membership function, medium deviation membership function, and high deviation membership function is calculated. The three function values ​​are used as the membership degree of the deviation to the low deviation fuzzy subset, medium deviation fuzzy subset, and high deviation fuzzy subset, respectively. This yields the first fuzzy subset and first membership degree corresponding to the communication mode deviation, the second fuzzy subset and second membership degree corresponding to the access frequency deviation, and the third fuzzy subset and third membership degree corresponding to the protocol compliance deviation. The above three fuzzy subsets and their corresponding three membership degrees are used as fuzzified outputs. Then, the fuzzy inference engine inputs the first fuzzy subset and first membership degree, the second fuzzy subset and second membership degree, and the third fuzzy subset and third membership degree into a preset fuzzy rule base. The fuzzy rule base stores several fuzzy inference rules, each containing a premise part and a conclusion part. The premise part is composed of logical combinations of fuzzy subsets corresponding to each deviation degree, and the conclusion part is an output fuzzy subset. The fuzzy inference engine calculates the activation strength of the premise part of each fuzzy inference rule, synthesizes the activation strength with the fuzzy set of the conclusion part, and queries the fuzzy rule base for differences set for different operating scenarios during the synthesis process. The rule weights are adjusted as follows: when the operating scenario indicator indicates that the current scenario is a production scenario with high behavioral volatility, the rule weight of the fuzzy inference rule corresponding to the access frequency deviation is increased to a first preset weight value; when the operating scenario indicator indicates that the current scenario is an operation and maintenance scenario with stable behavioral patterns, the rule weight of the fuzzy inference rule corresponding to the protocol compliance deviation is increased to a second preset weight value. The output fuzzy sets of each fuzzy inference rule after the differential rule weight adjustment are merged to obtain a comprehensive fuzzy set. Finally, the fuzzy inference engine defuzzifies the comprehensive fuzzy set, calculates the centroid abscissa value of the comprehensive fuzzy set, and then uses the centroid abscissa value as the behavioral deviation of the IoT device in the current operating scenario.

[0032] It should be noted that the fuzzy fusion in this application solves the technical problem of high false positive rate in heterogeneous scenarios with significant differences in behavior volatility by combining scenario awareness with dynamic adjustment of membership function parameters. In production scenarios with high behavior volatility, setting a wide-boundary membership function reduces the probability of false alarms caused by normal process fluctuations. In operation and maintenance scenarios with stable behavior patterns, setting a narrow-boundary membership function improves the sensitivity to detecting minor anomalies. Simultaneously, by differentially increasing the rule weights corresponding to key deviations in different scenarios, it maintains high sensitivity to abnormal access frequency in production scenarios and high sensitivity to abnormal protocol compliance in operation and maintenance scenarios, achieving adaptive matching between behavior assessment strategies and operational scenarios, and improving the accuracy and robustness of behavior deviation calculation.

[0033] In some embodiments, generating attribute encryption credentials based on the behavioral deviation and the initial trust level of the IoT device can be achieved through the following steps: The initial trust level and the behavioral deviation are input into a preset trust decay function to calculate the current trust value; Based on the trust interval into which the current trust value falls, the corresponding set of permission constraint attributes is searched from the preset permission mapping table; The attribute encryption algorithm is invoked, using the identity identifier of the IoT device as the public key, and the permission constraint attribute set as the encryption attribute embedding credential to generate the attribute encryption credential and set the validity period.

[0034] The current trust value in this application is a quantitative indicator reflecting the real-time trustworthiness of an IoT device after behavioral deviation correction; the permission constraint attribute set is a set of attributes used to limit the scope of resource access operations granted to the IoT device under the current trust value; the attribute encryption credential is an encrypted token used to prove the current permission constraint attributes of the IoT device to the access control node and is tamper-proof.

[0035] In specific implementation, the initial trust level and behavioral deviation of the IoT device are input into a preset trust decay function. The trust decay function uses the initial trust level as a baseline value and the behavioral deviation as a decay factor, subtracting the baseline value in an exponential decay manner to calculate the current trust value. Based on the preset trust interval into which the current trust value falls, the corresponding operation permission combination is searched from a preset permission mapping table. The permission mapping table stores the correspondence between trust intervals and operation permission combinations. The found operation permission combination is used as a permission constraint attribute set. An attribute encryption algorithm is called, using the IoT device's identity identifier as the encryption public key and the permission constraint attribute set as the plaintext attribute to be encrypted. The attribute encryption operation is performed to generate an attribute encryption certificate, and the current timestamp and preset validity period are written into the attribute encryption certificate. The attribute encryption certificate carrying the validity period is output.

[0036] Step 102: In response to the IoT device initiating an access request to the target resource, a trusted execution environment is invoked to parse the attribute encryption credential and extract the permission constraint attribute set.

[0037] In some embodiments, in response to the IoT device initiating an access request to the target resource, a trusted execution environment is invoked to parse the attribute encryption credential and extract the permission constraint attribute set. This can be achieved through the following steps: Receive an access request sent by the IoT device, the access request carrying the attribute encryption credential and the target resource identifier; The attribute encryption credential is passed into a trusted execution environment to verify the credential signature and validity period. After successful verification, the attribute encryption credential is decrypted, the permission constraint attribute set is extracted, and the extracted result is signed and transmitted out of the trusted execution environment.

[0038] The access request in this application is a request message used to trigger access permission verification of the target resource; the trusted execution environment refers to a computing environment used to perform credential parsing operations in an isolated and tamper-proof hardware security zone; the extraction result refers to signature data used to prove that the permission constraint attribute set has completed integrity verification within the trusted execution environment.

[0039] In specific implementation, the access gateway receives access requests sent by IoT devices, parses the attribute encryption credential from the message body of the access request, and parses the target resource identifier from the request line of the access request. The access request carrying the attribute encryption credential and the target resource identifier is then treated as a pending request. The access gateway transmits the attribute encryption credential to a trusted execution environment (TEA). Within the isolated region, the TEA extracts the credential issuance certificate. The credential generation module uses its private key to encrypt the credential digest to generate a digital signature. The credential issuer's public key is used to decrypt the digital signature to obtain a first digest. Simultaneously, the credential content is recalculated to obtain a second digest. The first digest is then compared with the second digest. The consistency of the digest is used to complete the integrity verification. The timestamp and validity period are extracted from the attribute encryption credential. The timestamp is compared with the current trusted time to determine whether the credential is within the validity period. The attribute encryption credential that passes the signature verification and has not exceeded the validity period is taken as the verified credential. The trusted execution environment performs a decryption operation on the verified credential, recovers the plaintext data of the permission constraint attribute set from the credential ciphertext, and digitally signs the recovered permission constraint attribute set using the signature private key uniquely bound to the trusted execution environment stored inside the trusted execution environment. The signed permission constraint attribute set is taken as the extraction result sent out of the trusted execution environment.

[0040] Step 103: The permission constraint attribute set and the security level label bound to the target resource are used as input parameters of the key derivation function to generate a one-time session key. The authorization scope of the one-time session key is determined by the logical conjunction of the permission constraint attribute set and the security level label, and does not exceed the resource access scope initially granted to the IoT device.

[0041] In some embodiments, the generation of a one-time session key by using the permission constraint attribute set and the security level label bound to the target resource as input parameters of the key derivation function can be achieved through the following steps: Query the security level label bound to the target resource, and obtain the set of allowed operation types, the minimum required trust level, and the mutual exclusion and dependency constraints between operations defined by the security level label; Using the operation permissions defined by the permission constraint attribute set as the initial search space, the allowed operation type set as the boundary conditions, and the mutual exclusion constraints and dependency constraints as rigid constraints, a permission minimization objective function is constructed. Solve the objective function of minimizing permissions, remove operation permissions that do not satisfy the rigid constraints from the initial search space, and prune the remaining operation permissions according to the risk cost to obtain the set of operation permissions that satisfy the principle of least permission; The constrained set of operation permissions, the current trust value, the session random number, and the timestamp are concatenated and used as the derivation material for the key derivation function to generate a one-time session key. The constrained set of operation permissions is associated with the one-time session key and output.

[0042] It should be noted that the security level label in this application is a set of metadata used to define the security access conditions and constraint rules of the target resource; the permission minimization objective function is a mathematical optimization model used to solve the minimum permission operation set under multiple constraint conditions; the constrained operation permission set is the minimum permission set used to limit the range of operations that the IoT device can perform on the target resource in the current session; and the derived material is a concatenated data block used as the input parameter of the key derivation function.

[0043] In specific implementation, firstly, query the security level label bound to the target resource, and obtain the set of allowed operation types, the minimum required trust level, and the mutual exclusion and dependency constraints between operations defined by the security level label. This can be achieved in the following way: query the security level label bound to the target resource, read the set of allowed operation types, the minimum required trust level, the list of mutual exclusion constraints between operations, and the list of dependency constraints from the security level label, and then output the above four items as the security level label. Secondly, using the operation permissions defined in the permission constraint attribute set as the initial search space, the allowed operation type set as the boundary conditions, and the mutual exclusion constraints and dependency constraints as rigid constraints, the permission minimization objective function can be constructed in the following way: using the operation permission enumeration items defined in the permission constraint attribute set as the initial search space, using the operation type enumeration items in the allowed operation type set as the boundary conditions of the search space, and using the rules that mutual exclusion operation pairs in the mutual exclusion constraint list cannot be granted simultaneously and the granting conditions that the prerequisite operations in the dependency constraint list must satisfy as rigid constraints, a permission minimization objective function is constructed with minimizing the number of granted operations as the first optimization objective and minimizing the operation risk cost value as the second optimization objective, where the priority of the first optimization objective is higher than that of the second optimization objective; Then, the permission minimization objective function is solved, and operation permissions that do not satisfy the rigid constraints are removed from the initial search space. The remaining operation permissions are then pruned according to risk cost. The set of operation permissions that satisfy the least privilege principle constraint can be obtained in the following way: The permission minimization objective function is solved. First, satisfying the first optimization objective is taken as the priority condition. The operation combination with the minimum number of granted operations is searched in the search space. When there are multiple operation combinations with the same number of granted operations, satisfying the second optimization objective is taken as the second-best condition. The operation combination with the minimum total operation risk cost is selected. In this process, each operation permission in the initial search space is traversed, and it is checked whether the operation permission satisfies the exclusion conditions of all mutually exclusive operation pairs in the mutual exclusion constraint list and the dependency constraint list. The search space is then processed by satisfying all prerequisite conditions. Operation permissions that do not meet the rigid constraints are removed from the search space. The risk value of each remaining operation permission is calculated. The risk value is determined based on the sensitivity of the operation type and the difference between the current trust value and the required minimum trust level. Operation permissions whose risk value exceeds a preset risk threshold are pruned and removed. The remaining operation permissions after removal and pruning are used as the set of operation permissions that meet the least privilege principle constraint. The risk threshold is usually set as a linear function of the difference between the current trust value and the required minimum trust level. When the difference is large, the risk threshold increases accordingly, and when the difference is small, the risk threshold decreases accordingly. This allows for the retention of more operation permissions when there is a high trust surplus and the execution of stricter permission pruning when there is a low trust surplus.

[0044] Finally, the constrained operation permission set, the current trust value, the session random number, and the timestamp are concatenated as the derivation material for the key derivation function to generate a one-time session key. The constrained operation permission set and the one-time session key are associated and output, which can be achieved as follows: the operation permission encoding field obtained by encoding the constrained operation permission set, the current trust value, the session random number generated by the random number generator, and the current timestamp are concatenated in a preset order. The concatenated data block is used as the derivation material, and the key derivation function is called to perform one-way hash iteration calculation on the derivation material with the master key as the derivation key to generate the one-time session key. Then, the constrained operation permission set and the one-time session key are packaged into a key-value pair structure, and the key-value pair structure is passed to the key distribution module as the associated output.

[0045] It should be noted that existing methods typically use attribute matching results directly as the authorization scope when generating session keys, without minimizing the permission set during key derivation. This results in session keys carrying more operation permissions than necessary, expanding the potential scope of leakage. This application constructs a permission minimization objective function, transforming the determination of operation permissions into an optimization problem rigidly constrained by mutual exclusion and dependency constraints. Before key derivation, the permissions are constrained and risk-pruned, and the pruned set of operation permissions is used as part of the key derivation material. This forces the authorization scope of a one-time session key to be cryptographically limited to a set that strictly satisfies the principle of least privilege, achieving embedding and convergence of permission control at the key derivation level, and significantly reducing the security impact of session key misuse.

[0046] Step 104: Distribute the one-time session key to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope.

[0047] In some embodiments, distributing the one-time session key to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope, can be achieved through the following steps: The one-time session key is encrypted using a preset transmission public key to generate key ciphertext; Send the key ciphertext and the constrained set of operation permissions to the IoT device; After the IoT device decrypts and obtains the one-time session key, it performs a key confirmation handshake with the target resource and establishes an encrypted communication session within the scope of the constrained set of operation permissions.

[0048] In specific implementation, the transmission public key of the IoT device is extracted from the identity certificate issued during the device registration phase. The one-time session key is then asymmetrically encrypted using the transmission public key, and the encrypted ciphertext data is used as the key ciphertext. The key ciphertext and the constrained set of operation permissions obtained from the key derivation module are then encapsulated into a distribution message, which is sent to the IoT device through a secure transmission channel. After receiving the distribution message, the IoT device decrypts the key ciphertext using the transmission private key paired with the transmission public key to recover the one-time session key. Then, it performs a key confirmation handshake with the target resource. During the handshake, both parties verify the consistency of their respective one-time session keys. After a successful handshake, the one-time session key is used as the symmetric key for the encrypted session. Subsequent communication data is encrypted and transmitted within the operation range defined by the constrained set of operation permissions. The encrypted transmission data channel serves as the encrypted communication session between the IoT device and the target resource.

[0049] On the other hand, in some embodiments, this application provides an access control system for Internet of Things (IoT) devices, with reference to... Figure 4 The figure is a schematic diagram of the structure of an access control system for an Internet of Things (IoT) device according to some embodiments of this application. The access control system 400 for the IoT device includes: an acquisition module 401, a processing module 402, and an execution module 403, which are described below: The acquisition module 401 in this application is mainly used to acquire the behavioral deviation of the Internet of Things (IoT) device within a specified time period, and generate an attribute encryption credential based on the behavioral deviation and the initial trust level of the IoT device. The attribute encryption credential embeds a set of permission constraint attributes to limit the resource access scope currently granted to the IoT device. Processing module 402, in this application, is used to respond to the IoT device's request to access the target resource by calling a trusted execution environment to parse the attribute encryption credential and extract the permission constraint attribute set; In this application, the processing module 402 is further configured to use the permission constraint attribute set and the security level label bound to the target resource as input parameters of the key derivation function to generate a one-time session key. The authorization scope of the one-time session key is determined by the logical conjunction of the permission constraint attribute set and the security level label, and does not exceed the resource access scope initially granted to the IoT device. The execution module 403 in this application is mainly used to distribute the one-time session key to the Internet of Things (IoT) device, so that the IoT device can establish an encrypted communication session with the target resource within the authorized scope.

[0050] In addition, this application also provides a computer device, which includes a memory and a processor. The memory stores code, and the processor is configured to acquire the code and execute the above-described access control method for IoT devices.

[0051] In some embodiments, reference Figure 5 This figure is a schematic diagram of the structure of a computer device implementing an access control method for an Internet of Things (IoT) device according to some embodiments of this application. The access control method for IoT devices in the above embodiments can be implemented through... Figure 5 The computer device shown is used to implement this, and the computer device 500 includes at least one processor 501, a communication bus 502, a memory 503, and at least one communication interface 504.

[0052] Processor 501 can be a general-purpose central processing unit (CPU) or an application-specific integrated circuit (ASIC).

[0053] The communication bus 502 can be used to transmit information between the aforementioned components.

[0054] Memory 503 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 503 may exist independently and be connected to processor 501 via communication bus 502. Memory 503 may also be integrated with processor 501.

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

[0056] Communication interface 504 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.

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

[0058] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can 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.

[0059] In addition, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described access control method for IoT devices.

[0060] 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.

[0061] 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. A method for access control of an Internet of Things (IoT) device, characterized in that, Includes the following steps: The behavior deviation of an IoT device within a specified time period is obtained. An attribute encryption credential is generated based on the behavior deviation and the initial trust level of the IoT device. The attribute encryption credential embeds a set of permission constraint attributes to limit the resource access scope currently granted to the IoT device. In response to the IoT device initiating an access request to the target resource, a trusted execution environment is invoked to parse the attribute encryption credential and extract the permission constraint attribute set; The permission constraint attribute set and the security level label bound to the target resource are used together as input parameters of the key derivation function to generate a one-time session key. The authorization scope of the one-time session key is determined by the logical conjunction of the permission constraint attribute set and the security level label, and does not exceed the resource access scope initially granted to the IoT device. The one-time session key is distributed to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope.

2. The method as described in claim 1, characterized in that, Before obtaining the behavioral deviation of IoT devices within a specified time period, the following steps are also included: During the device registration phase, identity certificates are issued to IoT devices and an initial trust level is assigned. Behavioral data of the IoT devices are collected within a security baseline period to construct a behavioral baseline model, which includes device communication patterns, access frequency, and protocol compliance characteristics.

3. The method as described in claim 1, characterized in that, Obtaining the behavioral deviation of IoT devices within a specified time period specifically includes: Collect real-time behavioral data of the IoT device within the specified time period; The real-time behavioral data is compared with the pre-built behavioral baseline model to calculate the deviation of communication mode, access frequency, and protocol compliance. Based on preset fuzzy rules, the deviation of the communication mode, the deviation of the access frequency, and the deviation of the protocol compliance are fuzzily fused to obtain the behavioral deviation of the IoT device within a specified time period.

4. The method as described in claim 3, characterized in that, Before performing fuzzy fusion on the communication mode deviation, access frequency deviation, and protocol compliance deviation based on preset fuzzy rules, the method further includes: identifying the current operating scenario of the IoT device, wherein the operating scenario is divided according to the historical behavior cycle of the IoT device and the preset working condition label of the device type.

5. The method as described in claim 4, characterized in that, Based on preset fuzzy rules, the fuzzy fusion of the communication mode deviation, access frequency deviation, and protocol compliance deviation specifically includes: The parameters of the input membership function are dynamically adjusted based on the identified operating scenario. Among the parameters, a wide-boundary membership function is set for production scenarios with high behavioral volatility, and a narrow-boundary membership function is set for operation and maintenance scenarios with stable behavioral patterns. Using the adjusted input membership function, the communication mode deviation, access frequency deviation, and protocol compliance deviation are fuzzified respectively to obtain the fuzzy subsets and membership degrees corresponding to each deviation. The fuzzy subsets and membership degrees are input into a preset fuzzy rule base for inference; The fuzzy rule base contains differentiated rule weights set for different operating scenarios. In scenarios with high behavioral volatility, the rule weight of the access frequency deviation is increased, and in scenarios with stable behavioral patterns, the rule weight of the protocol compliance deviation is increased. The comprehensive fuzzy set output by fuzzy inference is defuzzified to obtain the behavioral deviation of the IoT device in the current operating scenario.

6. The method as described in claim 1, characterized in that, Generating attribute-based encryption credentials based on the behavioral deviation and the initial trust level of the IoT device specifically includes: The initial trust level and the behavioral deviation are input into a preset trust decay function to calculate the current trust value; Based on the trust interval into which the current trust value falls, the corresponding set of permission constraint attributes is searched from the preset permission mapping table; The attribute encryption algorithm is invoked, using the identity identifier of the IoT device as the public key, and the permission constraint attribute set as the encryption attribute embedding credential to generate the attribute encryption credential and set the validity period.

7. The method as described in claim 1, characterized in that, In response to the IoT device initiating an access request to the target resource, a trusted execution environment is invoked to parse the attribute encryption credential and extract the permission constraint attribute set, specifically including: Receive an access request sent by the IoT device, the access request carrying the attribute encryption credential and the target resource identifier; The attribute encryption credential is passed into a trusted execution environment to verify the credential signature and validity period. After successful verification, the attribute encryption credential is decrypted, the permission constraint attribute set is extracted, and the extracted result is signed and transmitted out of the trusted execution environment.

8. The method as described in claim 1, characterized in that, Using the set of permission constraint attributes and the security level label bound to the target resource as input parameters for the key derivation function to generate a one-time session key specifically includes: Query the security level label bound to the target resource, and obtain the set of allowed operation types, the minimum required trust level, and the mutual exclusion and dependency constraints between operations defined by the security level label; Using the operation permissions defined by the permission constraint attribute set as the initial search space, the allowed operation type set as the boundary conditions, and the mutual exclusion constraints and dependency constraints as rigid constraints, a permission minimization objective function is constructed. Solve the objective function of minimizing permissions, remove operation permissions that do not satisfy the rigid constraints from the initial search space, and prune the remaining operation permissions according to the risk cost to obtain the set of operation permissions that satisfy the principle of least permission; The constrained set of operation permissions, the current trust value, the session random number, and the timestamp are concatenated and used as the derivation material for the key derivation function to generate a one-time session key. The constrained set of operation permissions is associated with the one-time session key and output.

9. The method as described in claim 8, characterized in that, Distributing the one-time session key to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope, specifically includes: The one-time session key is encrypted using a preset transmission public key to generate key ciphertext; Send the key ciphertext and the constrained set of operation permissions to the IoT device; After the IoT device decrypts and obtains the one-time session key, it performs a key confirmation handshake with the target resource and establishes an encrypted communication session within the scope of the constrained set of operation permissions.

10. An access control system for an Internet of Things (IoT) device, characterized in that, The system includes: The acquisition module is used to acquire the behavioral deviation of the IoT device within a specified time period, and generate an attribute encryption credential based on the behavioral deviation and the initial trust level of the IoT device. The attribute encryption credential embeds a set of permission constraint attributes to limit the resource access scope currently granted to the IoT device. The processing module is used to respond to the IoT device's request to access the target resource by calling a trusted execution environment to parse the attribute encryption credential and extract the permission constraint attribute set. The processing module is further configured to use the permission constraint attribute set and the security level label bound to the target resource as input parameters of the key derivation function to generate a one-time session key. The authorization scope of the one-time session key is determined by the logical conjunction of the permission constraint attribute set and the security level label, and does not exceed the resource access scope initially granted to the IoT device. An execution module is used to distribute the one-time session key to the IoT device, enabling the IoT device to establish an encrypted communication session with the target resource within the authorized scope.

Images