Intelligent Internet of Things access management method based on dynamic encryption

Abstract

The invention discloses an intelligent Internet of Things access management method based on dynamic encryption, particularly relates to the field of Internet of Things access control, and is used for solving the problem that when existing Internet of Things equipment is accessed, validity is not dynamically judged based on interaction behaviors, and session keys are not updated in real time. The method comprises the following steps: firstly, constructing a communication chain group based on a communication topology of registered equipment, and establishing an upstream and downstream interaction role identification table; distributing a temporary key when an access request is initiated, and extracting a communication record of a current communication period to form a data collaboration window; extracting an input response from the window, outputting a numerical value, executing feedback and an echoing state to generate a collaborative residual parameter, and matching the collaborative residual parameter with a collaborative behavior model of the communication chain group; if matching succeeds, extracting communication abstract features and a time window identifier to generate a key disturbance factor, and generating a current session key; and if matching fails, communication is rejected and key synchronization is blocked, so that dynamic encryption access control based on interaction feature driving is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things access control, and more specifically, to a smart Internet of Things access management method based on dynamic encryption. Background Art

[0002] In existing smart IoT systems, numerous devices are deployed in a distributed architecture, physically independent yet logically collaboratively completing sensing, control, and feedback tasks, forming a stable data exchange link. For example, in typical applications such as smart manufacturing, traffic management, and distributed energy consumption sensing, numerous devices in these systems do not operate in isolation, but rather exhibit upstream and downstream dependencies within the task flow. For example, data from temperature and humidity sensors directly influences the action logic of a wind turbine controller, and the controller's post-execution status requires feedback and confirmation from an execution status detection device. However, current IoT access management strategies generally focus on single-device identity authentication, ignoring the data consistency required between device access and upstream and downstream devices in the collaborative link. This results in an attacker impersonating a device in a link and completing the initial cryptographic handshake. By replicating the communication structure, they can maintain "legitimate access" for a limited period of time, implicitly tampering with the collaborative link. This impersonation behavior does not immediately trigger traditional anomaly detection based on key integrity or token validity, making it highly susceptible to long-term latency in systems with infrequent symmetric key updates. Especially in smart IoT systems deployed using national encryption algorithms, although the encryption protocol level has high security, it lacks a dynamic access verification mechanism based on the collaborative behavior of multiple devices, and cannot prevent counterfeit devices from bypassing the link logical relationship and directly accessing the system.

[0003] Therefore, constructing a method that combines the residual characteristics of upstream and downstream interactions of devices, dynamically adjusts the key strategy, and performs access management based on collaborative communication chain groups has become an important issue that needs to be urgently addressed in the current smart Internet of Things security access system. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a smart Internet of Things access management method based on dynamic encryption to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] A method for managing access to a smart Internet of Things based on dynamic encryption, comprising the following steps:

[0007] S1. Build a communication chain group based on the communication topology of the registered devices in the IoT platform and establish an upstream and downstream interaction role identification table for each device;

[0008] S2, distributing a temporary key and extracting the communication record of the access device and the upstream and downstream devices when the access device initiates an access request, forming a data collaboration window of interaction in the current communication period;

[0009] S3, extracting the input response, output value, execution feedback and echo state between the access device and the upstream and downstream devices, and generating a collaboration residual parameter;

[0010] S4, matching the collaboration residual parameter with the collaboration behavior model constructed in the communication chain group;

[0011] S5, when the matching is successful, extracting the current communication summary feature and time window identifier, generating a key perturbation factor, and jointly constructing a current session key with a preset root key;

[0012] S6, when the matching fails, rejecting the access device to maintain the communication channel, and blocking the key synchronization process of the access device in the communication chain group.

[0013] In a preferred embodiment, in S1, the communication chain group is constructed based on the communication topology of the registered devices in the Internet of Things platform, and the upstream and downstream interaction roles of each device specifically include:

[0014] Call the historical scheduling record and communication log of each device in the Internet of Things platform;

[0015] Identify the data input source, control relay node and result return node based on the communication direction between each device, and map the flow direction, and construct a data dependency topology graph;

[0016] Define a closed-loop process in the data dependency topology graph as a communication period, which is a communication period marker with an incremental primary key;

[0017] Group the device pairs with continuous linkage interaction relationship in the topology graph, form a communication chain group containing explicit uplink and downlink, and generate an upstream and downstream interaction role identification table according to the relative position of each device in the communication chain group.

[0018] In a preferred embodiment, in S2, when the access device initiates an access request, a temporary key is distributed and the communication record of the access device and the upstream and downstream devices is extracted, forming a data collaboration window of interaction in the current communication period, which specifically includes:

[0019] After receiving the access authentication request initiated by the access device, locate the communication chain group to which the access device belongs in the upstream and downstream interaction role identification table, distribute temporary keys to the access device and the upstream and downstream devices, and record the communication record of the access device upstream and downstream role device in the time window of the current communication period;

[0020] The upstream and downstream communication records are time axis mapped and aligned according to the temporary key effective time length, and a data cooperation window containing the interaction behaviors of the access device and its upstream and downstream associated devices is established.

[0021] In a preferred embodiment, the S3 extracts the input response, output value, execution feedback and echo state between the access device and the upstream and downstream devices, and generates the cooperation residual parameter, which specifically includes:

[0022] Taking the data cooperation window as input, the cooperation feature analysis calculation is performed to extract the input response delay, output value offset amplitude and offset direction parameter between the access device and its upstream device;

[0023] The execution feedback delay and control echo state error between the access device and the downstream device are synchronously extracted;

[0024] The above parameters are summarized as a cooperative residual parameter vector with a unified structure, and standardized mapping is performed on the data cooperation window according to the preset normalization rule to generate a residual parameter set of the current behavior consistency of the access device.

[0025] In a preferred embodiment, the S4 matches the cooperation residual parameter with the cooperation behavior model constructed in the communication chain group, which specifically includes:

[0026] The communication records of the communication chain group in the historical communication period are collected to construct the corresponding cooperation behavior model;

[0027] The cooperation residual parameter vector generated in the latest communication period after the device is accessed is input into the constructed cooperation behavior model, and the similarity scores between it and all standardized behavior templates are calculated in sequence, the closest behavior template is selected, and the matching score value of the current behavior is output.

[0028] In a preferred embodiment, the construction process of the cooperation behavior model includes:

[0029] The communication records between the devices in the communication chain group in the historical communication period of the Internet of Things platform are collected, and the historical cooperation residual parameters of each device are extracted;

[0030] The historical cooperation residual parameters are divided according to the task round and the time window to obtain the multi-dimensional response feature sequence of the stable interaction of each pair of adjacent upstream and downstream nodes in the communication chain group in multiple task cycles;

[0031] The multi-dimensional response feature sequence of each adjacent upstream and downstream node is repeatedly generated in multiple communication cycles, and the feature clustering is performed to generate the corresponding standardized behavior template;

[0032] The standardized behavior templates of all adjacent node pairs in the communication chain group are integrated in the link order, and an interaction condition index table is constructed based on the device role association relationship to form a communication chain group collaborative behavior model with upstream and downstream role mapping rules.

[0033] In a preferred embodiment, in S5, when the match is successful, extracting the current communication summary feature and the time window identifier, generating a key perturbation factor, and combining it with the preset root key to construct the current session key specifically includes:

[0034] When the matching score is within the set security threshold, the device identity code, data packet content summary and communication cycle mark contained in the communication data of the access device are extracted;

[0035] The above three items are combined to form the disturbance source input set;

[0036] Perform a hash operation on the disturbance source input set to obtain a fixed-length disturbance digest value. Perform a bitwise XOR operation on the disturbance digest value and the symmetric root key assigned by the platform to the access device to obtain the encryption disturbance factor.

[0037] The encryption perturbation factor is input into the symmetric key expansion algorithm to generate the session key of the current communication period to replace the temporary key, and the session key is written into the communication encryption context of the current device.

[0038] In a preferred embodiment, in S6, when the matching fails, the key synchronization process of refusing the access device to maintain the communication channel and blocking its access to the communication chain group specifically includes:

[0039] When the behavior matching score of the access device is lower than the set security threshold range in a preset number of consecutive communication cycles, the access communication channel blocking operation is triggered;

[0040] Terminate the key distribution operation and clear the temporary key held by the current access device, and at the same time issue a communication chain group isolation instruction to other devices in the communication chain group;

[0041] The access device is marked as an abnormal access source and removed from the communication chain group. The device identity code is recorded to prevent it from participating in subsequent key updates and access permission inheritance.

[0042] The technical effects and advantages of the present invention's intelligent Internet of Things access management method based on dynamic encryption are as follows:

[0043] The smart Internet of Things access management method based on dynamic encryption provided by the present invention realizes the structured organization of access management by utilizing the communication topology to construct a communication chain group and establish an upstream and downstream interaction role identification table, making the relationship between devices clear and traceable; introducing a temporary key in the access request stage and synchronously collecting the communication records of the access device and upstream and downstream devices to form a data collaboration window within the same communication cycle, ensuring the synchronization and comparability of data collection; by extracting the input response, output value, execution feedback and echo state to calculate the collaborative residual parameters, and matching them with the pre-built collaborative behavior model, it realizes the joint judgment of access legitimacy and behavior consistency, and effectively improves the recognition accuracy of disguised access and abnormal behavior; when the match is successful, the key perturbation factor is generated according to the communication summary feature and the time window identifier and the session key is derived, so that the key update and behavior verification are deeply bound, and the dynamic security of the encryption channel is enhanced; when the match fails, the access channel is blocked and the key synchronization isolation is performed to prevent abnormal nodes from maintaining connections for a long time, thereby realizing the closed-loop collaboration of access authentication, behavior monitoring and key management, and significantly improving the overall security and operational stability of the smart Internet of Things system. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a schematic diagram of a smart Internet of Things access management method based on dynamic encryption according to the present invention. DETAILED DESCRIPTION

[0045] The following will provide a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0046] Example 1

[0047] Figure 1 The present invention provides a smart Internet of Things access management method based on dynamic encryption, which includes the following steps:

[0048] S1. Build a communication chain group based on the communication topology of the registered devices in the IoT platform and establish an upstream and downstream interaction role identification table for each device;

[0049] S2. When the access device initiates an access request, a temporary key is distributed and the communication records between the access device and upstream and downstream devices are extracted to form a data collaboration window for interaction within the current communication cycle.

[0050] S3. Extract input responses, output values, execution feedback, and echo status between the access device and upstream and downstream devices to generate collaborative residual parameters;

[0051] S4, matching the collaborative residual parameters with the collaborative behavior model constructed in the communication chain group;

[0052] S5. When the match is successful, extract the current communication summary features and time window identifier, generate a key perturbation factor, and combine it with the preset root key to construct the current session key;

[0053] S6. When the matching fails, the access device is denied access to maintain the communication channel and is blocked from accessing the key synchronization process of the communication chain group.

[0054] In S1, a communication chain group is constructed based on the communication topology of the registered devices in the Internet of Things platform, and the upstream and downstream interaction roles of each device are marked.

[0055] The historical scheduling records and communication logs of each device in the IoT platform are called. In this embodiment, the historical scheduling records include the start time, stop time, task execution order, and trigger relationships between tasks during the device's previous task execution. These records are sourced from the field control unit, edge node recorder, or independent task execution recording module. The communication log includes communication information between each device and other devices at different time points, including data transmission time, data reception time, communication content category (such as measurement value, control instruction, status feedback, etc.), communication duration, and communication direction. First, the historical scheduling records of all devices are sorted by timeline to form a task timeline table. The communication logs are grouped by sender and receiver, so that the communication behavior between each device and its interactive object can be individually traced. Next, the directionality of each record in the communication log is analyzed, that is, the sender and receiver roles of the data are clarified. If the data source sends raw measurement data or status parameters, and the receiver makes a control decision or forwarding behavior within a certain time range after receiving the data, the data source is marked as the data input source. If a device, after receiving data, processes the data and sends control instructions or further processed data to another device, it is labeled a control relay node. If a device, after receiving control instructions or processing data, performs a physical action and, upon completion, sends the result or status feedback back to the previous node in the link, it is labeled a result return node. To ensure the accuracy of these labelings, statistics are collected from multiple rounds of historical communication data to ensure that device roles are not determined by a single, random communication behavior but rather reflect long-term, stable interaction patterns. After role identification, a ternary mapping is established for each identified pair of data input source, control relay node, and result return node. This mapping not only includes the device identifier but also additional attributes such as communication direction, typical communication latency, and common data types. A data dependency topology graph is then constructed based on all these ternary mappings. Each node in the graph represents a device, and directed edges between nodes indicate the communication direction. The attributes on these edges include latency and data type descriptions. This approach yields a unified topology that reflects both physical deployment and logical interaction, providing a precise data dependency basis for delineating subsequent communication cycles.

[0056] Identifying and delineating communication cycles in the topology graph involves defining the entire process from data input initiated by a data input source, processed by a control relay node, to physical execution and result return by a downstream node as a communication cycle. To accurately define the start and end points of a communication cycle, the data dependency topology graph is first searched for all closed-loop paths that originate from the data input source and return to the starting path. These closed-loop paths must pass through at least one control relay node and one result return node. Data transmission directions must remain consistent and no devices must be involved in the path. For each closed-loop path, the communication logs are extracted from the most recent device interaction records along the path and arranged in chronological order. A single data input event, such as a temperature sensor reporting a new measurement value, is identified and the timestamp of this event is used as the start point of the communication cycle. The topology path is then traced back to the data transmission to the control relay node, where the node generates and issues a control instruction. The timestamp of the execution node (result return node) completing the action and reporting status feedback is then traced back to the end point of the communication cycle. This extraction process is repeated over multiple historical cycles to obtain a large amount of cycle start and end time data. For ease of management, each communication cycle is assigned a unique auto-incrementing primary key as a communication cycle marker. This primary key is not only used to distinguish different cycles, but also serves as an index for subsequent data storage, query, and comparison. While generating the communication cycle marker, the participation order, communication delay, data type, and typical response behavior of each node in the cycle are recorded. This communication cycle demarcation method based on the topological closed-loop process ensures that the cycle definition is highly consistent with the actual business process, and does not generate false cycle markers due to isolated communication events of a single device. In addition, this method can also distinguish different business closed loops when multiple links are concurrent, because each closed-loop path has a unique device sequence and start and end time, so that the complete interaction process of a specific business flow can be accurately located in subsequent data analysis and security management;

[0057] After the communication period is determined, the device pairs with a sustained linkage interaction relationship in the topology graph are grouped to form a communication chain group, and the relative position of each device in the communication chain group is generated to form an upstream and downstream interaction role identification table. First, the interaction frequency, interaction direction and interaction stability of all device pairs are extracted from the topology graph with the labeled communication period. The interaction frequency can be obtained by counting the number of common participation times of two devices in all communication periods; the interaction direction is directly given by the directionality of the topology edge; and the interaction stability is measured by calculating the proportion of two devices maintaining the relative order in the communication period. If a device pair interacts in the same direction in most communication periods, and the interaction frequency exceeds a certain proportion (for example, 80%) of all periods, the device pair is determined to have a sustained linkage interaction relationship. After the determination is completed, these device pairs are gradually merged into larger device sets according to the interaction relationship. The devices in this set either directly communicate with each other or indirectly communicate through other devices in the chain group, and they all participate in the same type of business closed loop process. In the grouping process, the topology structure is not destroyed, that is, the communication direction between the devices in the chain group is consistent, and isolated nodes or disconnected subgraphs are not allowed. After the grouping is completed, each device in the chain group is assigned a relative position number in the chain group, which is used to generate an upstream and downstream interaction role identification table in combination with the communication direction. In the identification table, the upstream role refers to the source device of the data flow, and the downstream role refers to the device that receives and processes the upstream data. The devices in the middle position are marked as relay roles according to their data processing functions. If a device plays different roles in different business flows, the multi-role mapping relationship is recorded in the identification table, and the current role is determined according to the communication period mark when used. Each record in the identification table contains not only the device number and role type, but also the identification and communication characteristic information of the upstream and downstream devices directly connected thereto, such as average delay, data type and typical response behavior.

[0058] In S2, when the access device initiates an access request, a temporary key is distributed and the communication record of the access device and the upstream and downstream devices is extracted to form a data collaboration window that interacts in the current communication period.

[0059] After receiving the access authentication request initiated by the access device, the communication chain group to which the access device belongs is first located through the upstream and downstream interaction role identification table established in advance. The first step in this process is to read the device's unique identity contained in the access authentication request. This identity can be the hardware serial number preset when the device leaves the factory, the firmware identity code burned in, or a long string code generated when the platform is registered. This identity is accurately matched with the record in the upstream and downstream interaction role identification table to find the communication chain group number to which it belongs. If the match here cannot rely on the device number query match, the device's physical deployment location, service label, function type and other additional information can be cross-verified to ensure accurate identification. After the chain group is located, the temporary key distribution link is entered. In this embodiment, the temporary key adopts a session-level one-time generation strategy. The trusted key management unit generates a key string of a specified length according to a high-entropy random source. The length can be set to 128 bits or 256 bits to meet different encryption strength requirements. After key generation, the access device is designated as the core node according to the current chain group topology. The same temporary key is distributed to its directly connected upstream and downstream devices simultaneously, ensuring that they can exchange data using the same encryption parameters within the current session. During this distribution process, the temporary key is transmitted over an existing secure channel, encrypted using the root key established during device registration to prevent interception or tampering during transmission. Once key distribution is complete, the communication record collection task is immediately initiated, recording communication events between the access device and upstream devices, and between the access device and downstream devices, within the current communication cycle time window. Collected communication records include at least timestamps, communication direction, type of transmitted data (e.g., status data, control commands, sensor values), data length, and transmission latency. These records are written to a buffer in real time, in the order in which the events occurred. Because upstream and downstream devices may interact with the access device at different frequencies and timings, separate record queues are established for each type of interaction during the collection process to ensure that granular event information is not lost during aggregation.

[0060] After obtaining the original communication records between the access device and upstream and downstream devices during the current communication cycle, these records are time-aligned based on the validity period of the temporary key, thereby establishing a data collaboration window. First, the validity period of the temporary key is determined. In this embodiment, it is set as a fixed proportion of the communication cycle length. For example, if the communication cycle is 120 seconds, the validity period of the temporary key can be set between 60 and 90 seconds. The specific value is selected based on the security policy. After determining the validity period, the timestamp of each event in the original communication record is converted into an offset relative to the time when the temporary key was issued, accurately calculated in milliseconds. Next, two parallel tracks are drawn on the timeline, corresponding to the interaction events between the access device and the upstream device, and between the access device and the downstream device, respectively. All events are marked on their respective tracks and distinguished by their directionality, for example, using different symbols to represent "send" and "receive." Then, the time interval on the timeline that completely overlaps with the validity period of the temporary key is intercepted. Events within this interval are included in the data collaboration window. To ensure comparability between upstream and downstream events, the events need to be time-aligned. Specifically, the process uses the access device's event timestamp as a benchmark. The event sequences of upstream and downstream devices are searched for the event closest to that timestamp. If the time difference is within a preset tolerance (e.g., ±5 milliseconds), they are paired into a coordinated event set. If no matching event is found, an empty placeholder is used in the coordination window to indicate its absence, allowing for identification of delays or losses during subsequent analysis. After event alignment, each paired event, along with its time difference, data type difference, and data value difference, is stored as a record in the coordination window data structure. The coordination window not only reflects the interaction density and temporal consistency between the access device and upstream and downstream devices within the same key validity period but also provides a set of differential parameters necessary for quantitative analysis. This approach compresses previously dispersed, asynchronous communication behaviors into a common reference frame, facilitating the subsequent extraction of behavioral residuals and matching of coordinated behavior models. This step results in a structured, time-aligned data coordination window with clear upstream and downstream relationships, providing direct input for security analysis and dynamic key construction.

[0061] In S3, the input response, output value, execution feedback and echo status between the access device and the upstream and downstream devices are extracted to generate collaborative residual parameters.

[0062] After obtaining the data collaboration window, collaboration characteristics are analyzed and calculated for the communication data between the access device and its upstream device. Specifically, based on the time-aligned event records in the collaboration window, the timestamp of the access device's request or data packet sent to the upstream device and the timestamp of the upstream device's response to the request are read one by one. The input-response delay is directly calculated based on the time difference between the two. This delay is recorded in milliseconds, and the independent values ​​of each pair of events are retained in subsequent statistics to ensure that the latency distribution characteristics are fully preserved. To extract the output value offset, the output value received by the access device from the upstream device is compared item by item with the standard output value for this type of interaction in the reference behavior template. The absolute value of the numerical difference is calculated and recorded as the offset parameter. To obtain the offset direction parameter, the sign of the numerical difference is determined. If the value received by the access device is higher than the standard value, it is recorded as a positive offset; otherwise, it is recorded as a negative offset. These three parameters—input-response delay, output value offset, and offset direction parameter—collectively constitute a description of the interaction differences between the access device and the upstream device. Simultaneously, the interaction data between the access device and its downstream device is synchronously analyzed. The feedback time of the downstream device after receiving the execution instruction sent by the access device is extracted, and the time difference is made with the instruction sending time to obtain the execution feedback delay value, which is measured in milliseconds and retains all the original data of multiple interactions. Next, the control echo state error is analyzed, that is, the difference between the state flag returned by the downstream device after completing the task and the expected state. For example, when the target state is "completed and normal", if the downstream device returns "completed but warning" or "not completed", the difference is converted into a quantitative value record according to the predefined error coding. These quantitative error values ​​can intuitively reflect the performance fluctuations or potential faults that may exist in the downstream link of the execution link. After completing the parsing of the two types of upstream and downstream interaction data, all parameters are summarized into a unified data structure to ensure that the parameter order, format, and data type are consistent, thereby forming a unified structure collaborative residual parameter vector.

[0063] After the collaborative residual parameter vector is formed, it is normalized across the data collaborative window according to a pre-set normalization rule. This eliminates dimensional differences between different devices and data types, making the residual parameter sets directly comparable. The first step in the normalization process is to set reasonable reference ranges and scaling rules for each parameter type. For example, for input response delay, the maximum and minimum values ​​of this type of interaction within the historical normal operation cycle are selected as the interval endpoints, and all delay values ​​are linearly mapped to a value between 0 and 1. For output numerical offset amplitude, the absolute offset value is divided by the maximum amplitude of this data type in the historical sample to obtain a dimensionless value between 0 and 1. For the offset direction parameter, the direction information can be directly retained in binary form (1 indicates a positive offset, 0 indicates a negative offset). The normalization method for execution feedback delay is the same as for input response delay. For control reverberation state error, different levels of state error are mapped to corresponding numerical ranges according to a pre-set error level table, for example, 0 indicates no error, 0.5 indicates a moderate error, and 1 indicates a severe error. After normalizing all parameters, they are combined in a fixed order into a standardized residual vector, which is then populated into the corresponding collaborative window entry. The collaborative window contains multiple groups of events, resulting in a time-ordered set of residual parameters, each containing vectors of the same length and parameter order. This structured, standardized residual set not only preserves all temporal variance information but also provides a direct input interface for subsequent matching with the collaborative behavior model. Throughout this process, normalization rules are pre-determined based on long-term operational data statistics and are fixed during implementation to ensure data comparability across different communication cycles.

[0064] In S4, the collaborative residual parameter is matched with the collaborative behavior model constructed in the communication chain group.

[0065] Communication chain group records from historical communication cycles are retrieved from the IoT platform. These records are sourced from each registered device's command transmission records, response data records, execution feedback logs, and control echo results during each communication cycle. The historical upstream and downstream residual coordination parameters of each device are extracted. After obtaining these historical upstream and downstream residual coordination parameters for each device, these data are precisely divided into task rounds and time windows. Task rounds are defined based on the business logic within the communication chain group. For example, a complete production task, an environmental monitoring process, or a remote control execution is defined as a task round. A time window refers to the data interaction intervals at different stages within a task round, such as the startup phase, execution phase, and result confirmation phase. During data collation, all interaction records within the same task are grouped together based on the task round tag. Then, interaction records within the same task group are further divided into multiple stage subgroups based on the time window tag. Within each stage subgroup, the corresponding residual parameter values ​​are arranged in chronological order, resulting in a multidimensional vector sequence reflecting the interaction characteristics of that stage. The dimension of this multidimensional vector sequence is fixed, and it includes all parameters such as input response delay, output offset amplitude, offset direction, feedback delay, state error, etc., and the values ​​of each dimension are standardized to ensure comparability across devices and tasks. For each pair of adjacent upstream and downstream nodes in the communication chain group, the above process is repeated, and eventually a set of stable interactive multidimensional response feature sequences are accumulated over multiple task cycles. These sequences can reflect the behavior patterns of devices under normal collaboration. For example, a stable sensor-controller pair may have input response delay and output offset amplitude that maintain a similar numerical fluctuation range over multiple task cycles. This type of regularity data is the core basis for subsequent cluster analysis and standardized template generation. The stable interaction is an interactive relationship in which adjacent upstream and downstream devices in the communication chain group present a repeatable, regular and non-sudden change trend over multiple communication cycles.

[0066] After obtaining the multidimensional response feature sequences for each pair of adjacent upstream and downstream nodes, recurring patterns across multiple communication cycles are identified and solidified into standardized behavioral templates. Specifically, cluster analysis is performed on the feature sequences of each pair of nodes, grouping sequences with similar Euclidean distance or cosine similarity into the same cluster. For each cluster, the mean and fluctuation range of all sequences in each dimension are calculated to form the cluster's center vector, which serves as the parameter value for the standardized behavioral template. Each template contains not only the feature mean but also information such as the time window position, task phase identifier, and device role, enabling precise mapping to specific locations in the communication chain during subsequent matching. After template generation, the standardized templates for all adjacent node pairs within the communication chain are integrated according to the link order to form a standardized interaction path description covering the entire chain. Based on this, an interaction condition index table is constructed based on the upstream and downstream role relationships of the devices. This index table records the preconditions and postconditions corresponding to each template. For example, a template is activated only when the upstream node is in a normal state and the feedback delay is below a set threshold. Ultimately, the template set and index table together constitute the communication chain group collaborative behavior model, which can not only match and score the behavior of access devices, but also determine the location and nature of behavioral anomalies based on upstream and downstream relationships and task stages, thereby providing reliable criteria for dynamic encryption strategies.

[0067] After the collaborative behavior model is constructed, when a device is connected and completes a full communication cycle, a collaborative residual parameter vector for that device is generated for that cycle. This vector is composed of a predetermined sequence of parameters, including the input response delay, output numerical offset amplitude, and offset direction between the device and its upstream device, as well as the execution feedback delay and control reverberation state error between the device and its downstream device. Its structure is identical to the parameter structure extracted during the historical data phase, ensuring direct comparison with the standardized behavior templates in the collaborative behavior model. Before entering the matching calculation, the collaborative residual parameter vector undergoes data preprocessing. This involves rescaling all parameters according to the normalization rules used during the model training phase. This ensures that each dimension of data has equal weight contribution in the similarity calculation, while avoiding computational bias caused by differences in numerical scale. During the calculation process, the current residual parameter vector is subjected to a difference operation or angle calculation for each corresponding dimension with the target template, and the results are aggregated into a single similarity score using preset weighting coefficients. The weighting coefficient is set based on the feature importance analysis results during the model training phase. For example, in industrial process control scenarios, the output value offset amplitude has a greater impact on judging the device status. Therefore, in the similarity calculation, the weight of this dimension will be set to 1.5 times that of other dimensions, while the weight of the input response delay may be maintained at the standard value.

[0068] After calculating the similarity scores for all candidate templates, the results are sorted from high to low, and the highest-scoring template is selected as the reference template that most closely matches the current device's behavior pattern. To ensure matching stability, the difference between the highest and second-highest scores is calculated. If the difference falls below the minimum discrimination threshold, the current behavior pattern is considered an ambiguous match, and the device's monitoring frequency is increased in subsequent security policies.

[0069] In said S5, when the match is successful, the current communication summary feature and the time window identifier are extracted to generate a key perturbation factor, and the key perturbation factor is combined with the preset root key to construct the current session key.

[0070] Once the access device's behavior matching score is confirmed to be within the pre-set security threshold, the session key generation preparation phase begins. Three key elements are precisely located and extracted from the complete communication data generated by the access device during the current communication cycle. The first is the device identity code, which is assigned during device registration and remains unique. It identifies the device entity and serves as the basis for key construction. The second is the data packet content summary, which is derived from all valid data packets in the current communication cycle through a unified content compression and digest calculation method. This summary covers core data such as input commands, return results, and status information exchanged between the device and upstream and downstream nodes during the cycle, ensuring the uniqueness and integrity of its information fingerprint. The third is the communication cycle marker, a sequential, auto-incrementing number used to distinguish different communication cycles and prevent cross-cycle key misuse. These three types of data are concatenated in a strict, predetermined order, preserving the byte order of the original data, to form a perturbation source input set specific to the current communication cycle. This input set serves as the unique and complete raw perturbation base in subsequent processing, driving the entire dynamic session key generation process.

[0071] After the perturbation source input set is formed, the intensive digest processing phase begins. Using a highly deterministic, collision-resistant hash algorithm recognized by national cryptographic standards, a byte-by-byte operation is performed on the concatenated perturbation source input set. During this operation, each byte of the input set undergoes multiple rounds of iterative computation, ensuring that any change in the input data will result in a significant change in the output digest, thereby achieving extremely high sensitivity. The resulting fixed-length perturbation digest value is highly random and irreversible, and the input set contents cannot be reversed. This perturbation digest value is then bitwise XORed with the symmetric root key provisioned for the access device. This process is performed bit by bit at the binary level, ensuring that the highly random characteristics of the perturbation digest value are directly mapped and incorporated into every bit of the root key. The resulting cryptographic perturbation factor, after the XOR operation, no longer directly contains sensitive information such as the original device identity code, packet digest, or communication cycle marker. It also exhibits cycle-uniqueness and anti-replay capabilities, providing a highly secure random input seed for the subsequent session key expansion phase.

[0072] After obtaining the encryption perturbation factor, session key construction begins. A symmetric key expansion algorithm, compliant with national security standards, is invoked, using the encryption perturbation factor as the initial input. Multiple rounds of key bit mixing, cyclic shifting, and nonlinear permutation are performed to expand the input factor to a complete session key, in length and structure, that meets the encryption requirements for the current communication cycle. This key expansion process ensures that the output session key has a statistical distribution close to that of an ideal random sequence, and that every bit of the key maps to all input bits of the perturbation factor, thereby preventing the risk of partial leakage leading to global key derivation. After the generated session key passes integrity testing, it immediately replaces the temporary key in the access device's current communication context, ensuring that subsequent communications are encrypted and decrypted using the newly generated, highly secure session key. Simultaneously, the cycle marker and key validity period in the communication context are updated to prevent the key from being used across cycles or after its expiration. This process enables the access device to switch its encryption parameters from temporary to highly dynamic within the current communication cycle, significantly enhancing data confidentiality and tamper resistance during communication.

[0073] In S6, when the matching fails, the access device is denied to maintain the communication channel and is blocked from accessing the key synchronization process of the communication chain group.

[0074] When the behavior state of the access device is periodically evaluated, a matching score value output by the cooperative behavior model is obtained at the end of each communication cycle. When the matching score value of the access device is lower than the preset security threshold range in a plurality of consecutive communication cycles (specifically set according to the validity period length of the temporary key, and the default setting is 1), it is determined that the behavior characteristics of the device in the consecutive cycles show significant abnormal consistency. The abnormality may be caused by device tampering, external intrusion, hardware sensor unit misalignment, or control and use by an unauthorized subject. In order to avoid the device continuing to interact with the communication chain group, and to prevent the abnormal behavior from spreading to other normal device nodes through the data link, the access communication channel blocking operation is triggered. The blocking process first locates the physical and logical links of the current device on the communication path between the device and the upstream, relay, and downstream nodes, ensuring that the blocking action covers all reachable paths; then directly cuts off the data packet transmission channel at the data transmission layer of the communication link, so that the device cannot continue to establish or maintain a connection with other nodes in the chain group at the physical signal or link layer; finally, while the channel is blocked, the accessibility table of the communication chain group is updated, and the link of the device is marked as "blocked", so that it is completely excluded in subsequent link planning and routing calculation. Through this processing, it is ensured that the abnormal device cannot send or receive data within the chain group through any known normal communication channel after the blocking is triggered, and the propagation path of the potential risk is fundamentally cut off.

[0075] After the communication channel is blocked, all key distribution operations related to the access device are terminated synchronously to ensure that it cannot use the previously allocated key material for encrypted communication. This process accurately retrieves the temporary key identifier corresponding to the current access device in the key management record, and then directly executes the key destruction operation, so that it is completely cleared in any memory, cache or hardware security storage unit. The destruction operation requires covering all possible key copies, including temporary buffer data during the distribution process, to ensure that there is no possibility of residual key being used by the device or attacker. At the same time, the chain group isolation instruction is issued to the remaining device nodes in the communication chain group. The isolation instruction contains the identity code of the isolated device and the effective time marker of the isolation execution, and each node will immediately update the local chain group interaction whitelist after receiving the instruction, remove the isolated device from the node list allowed to communicate, and refuse any data packet request sent by it in the subsequent communication cycle. Such isolation processing not only takes effect on a single node, but also forms a linkage in the entire communication chain group, ensuring that all nodes maintain a consistent isolation posture to the abnormal device within the same time window, thereby avoiding link vulnerabilities caused by local node delay response. Through the synchronous execution of key distribution termination and isolation instruction issuance, the abnormal device is realized in the key, channel, and node interaction layer.

[0076] After channel blocking and isolation, the access device must be permanently marked as abnormal and its permissions blocked to prevent it from re-entering the communication group through registration or inheritance in subsequent cycles. This process begins by writing the device's unique identity code into the abnormal device record table. This record table is used in multiple core processes, including key generation, access authentication, and communication group maintenance, automatically identifying and denying access requests from the device at all future security checkpoints. Subsequently, during the communication group's structural maintenance phase, the device node is completely removed from the group topology to which it belongs, and the upstream and downstream link mappings are revised. This ensures that links that originally relied on the node re-establish direct or indirect alternative connections to maintain the interoperability of other devices in the group. Finally, during key update management, the device is blocked from participating in any key update process, ensuring that even if other devices change their session keys in subsequent cycles, the abnormal device cannot obtain new cryptographic material. Furthermore, the inheritance of its access permissions is blocked, prohibiting it from re-entering the group by cloning its identity code, forging hardware identifiers, or impersonating a role. This processing step combines blocking, isolation, and long-term privilege deprivation, strengthening the entire communication chain in both structure and security, thereby ensuring that abnormal devices completely lose the possibility of any form of access and interaction with the chain.

[0077] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters and thresholds in the formulas are set by technicians in this field according to actual conditions.

[0078] The above-described embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, the above-described embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present application are wholly or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center through a wired (for example, infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. containing one or more available medium collections. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state disk.

[0079] Those skilled in the art can realize that the modules and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0080] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and module can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0081] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the above-described device embodiments are only schematic, for example, the division of the modules is only a logical function division, and actual implementation can have another division manner, for example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

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

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

[0084] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0085] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0086] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A smart Internet of Things access management method based on dynamic encryption, characterized in that: The steps include: S1. Build a communication chain group based on the communication topology of the registered devices in the IoT platform and establish an upstream and downstream interaction role identification table for each device; S2. When the access device initiates an access request, a temporary key is distributed and the communication records between the access device and upstream and downstream devices are extracted to form a data collaboration window for interaction within the current communication cycle. S3. Extract input responses, output values, execution feedback, and echo status between the access device and upstream and downstream devices to generate collaborative residual parameters; S4, matching the collaborative residual parameters with the collaborative behavior model constructed in the communication chain group; S5. When the match is successful, extract the current communication summary features and time window identifier, generate a key perturbation factor, and combine it with the preset root key to construct the current session key; S6. When the matching fails, the access device is denied access to maintain the communication channel and is blocked from accessing the key synchronization process of the communication chain group.

2. The method for managing access to the intelligent Internet of Things based on dynamic encryption according to claim 1, characterized in that: In S1, a communication chain group is constructed based on the communication topology of the registered devices in the IoT platform, and the upstream and downstream interaction roles of each device are marked, specifically including: Call the historical scheduling records and communication logs of each device in the IoT platform; Based on the communication direction between devices, the data input source, control relay node and result return node are identified, and the flow direction of the three is mapped to build a data dependency topology diagram; A communication cycle is defined as the closed-loop process in the data dependency topology graph, which consists of a data input, an instruction executed by a control relay node, and a result returned by a downstream node. The communication cycle is marked with an auto-incrementing primary key. The device pairs with continuous linkage interaction relationships in the topology diagram are grouped to form a communication chain group with clear uplinks and downlinks, and an upstream and downstream interaction role identification table is generated for each device according to its relative position in the communication chain group.

3. The method for access management of intelligent Internet of Things based on dynamic encryption according to claim 1, characterized in that: In S2, when the access device initiates an access request, distributing a temporary key and extracting communication records between the access device and upstream and downstream devices to form a data collaboration window for interaction within the current communication cycle specifically includes: After receiving the access authentication request initiated by the access device, locate the communication chain group to which the access device belongs in the upstream and downstream interaction role identification table, distribute temporary keys to the access device and upstream and downstream devices, and record the communication records of the upstream and downstream role devices of the access device within the time window of the current communication cycle; The upstream and downstream communication records are aligned on the time axis according to the validity period of the temporary key, and a data collaboration window containing the interaction behavior of the access device and its upstream and downstream associated devices is established.

4. The method for managing access to the intelligent Internet of Things based on dynamic encryption according to claim 1, characterized in that: In S3, extracting the input response, output value, execution feedback, and echo status between the access device and the upstream and downstream devices to generate the collaborative residual parameter specifically includes: Using the data collaboration window as input, the collaborative feature analysis calculation is performed to extract the input response delay, output value offset amplitude, and offset direction parameters between the access device and its upstream device. Synchronously extract execution feedback delays and control echo state errors between access devices and downstream devices; The above parameters are aggregated into a unified structure of collaborative residual parameter vectors, and standardized mapping is performed on the data collaborative window according to the preset normalization rules to generate a residual parameter set consistent with the current behavior of the access device.

5. The method for access management of intelligent Internet of Things based on dynamic encryption according to claim 1, characterized in that: In S4, matching the collaborative residual parameter with the collaborative behavior model constructed in the communication chain group specifically includes: Collect communication records of communication chain groups in historical communication cycles and build corresponding collaborative behavior models; The collaborative residual parameter vector generated in the latest communication cycle after the device is connected is input into the constructed collaborative behavior model, and the similarity scores between it and all standardized behavior templates are calculated in turn. The closest behavior template is screened out, and the matching score value of the current behavior is output.

6. The method for managing access to the intelligent Internet of Things based on dynamic encryption according to claim 5, characterized in that: The construction process of the collaborative behavior model includes: Collect communication records between devices in the communication chain group during the historical communication cycle of the IoT platform, and extract the historical collaborative residual parameters of the upstream and downstream of each device; The historical collaborative residual parameters are divided according to task rounds and time windows to obtain the multi-dimensional response feature sequence of each pair of adjacent upstream and downstream nodes in the communication chain group that interacts stably in multiple task rounds. Perform feature clustering on the parts of the multi-dimensional response feature sequences of adjacent upstream and downstream nodes that appear repeatedly in multiple communication cycles to generate corresponding standardized behavior templates; The standardized behavior templates of all adjacent node pairs in the communication chain group are integrated in the link order, and an interaction condition index table is constructed based on the device role association relationship to form a communication chain group collaborative behavior model with upstream and downstream role mapping rules.

7. The method for managing access to the intelligent Internet of Things based on dynamic encryption according to claim 1, characterized in that: In S5, when the match is successful, extracting the current communication summary feature and the time window identifier, generating a key perturbation factor, and combining it with the preset root key to construct the current session key specifically includes: When the matching score is within the set security threshold, the device identity code, data packet content summary and communication cycle mark contained in the communication data of the access device are extracted; The above three items are combined to form the disturbance source input set; Perform a hash operation on the disturbance source input set to obtain a fixed-length disturbance digest value. Perform a bitwise XOR operation on the disturbance digest value and the symmetric root key assigned by the platform to the access device to obtain the encryption disturbance factor. The encryption perturbation factor is input into the symmetric key expansion algorithm to generate the session key of the current communication period to replace the temporary key, and the session key is written into the communication encryption context of the current device.

8. The method for managing access to smart Internet of Things based on dynamic encryption according to claim 1, characterized in that: In S6, when the matching fails, the key synchronization process of denying the access device to maintain the communication channel and blocking its access to the communication chain group specifically includes: When the behavior matching score of the access device is lower than the set security threshold range in a preset number of consecutive communication cycles, the access communication channel blocking operation is triggered; Terminate the key distribution operation and clear the temporary key held by the current access device, and at the same time issue a communication chain group isolation instruction to other devices in the communication chain group; The access device is marked as an abnormal access source and removed from the communication chain group. The device identity code is recorded to prevent it from participating in subsequent key updates and access permission inheritance.

Images