A method and system for encrypting data transmission of monitoring equipment in smart cities

Abstract

This invention relates to the field of smart city communication security technology, and discloses a method and system for encrypting data transmission of monitoring equipment in smart cities. The method includes: obtaining an initial set of device classifications; performing secure grouping based on the initial set to obtain a secure group list; collecting communication requirements based on the list and performing priority scheduling to generate a group transmission scheduling scheme; generating an encryption key set based on the scheme; performing dynamic authorization and permission adjustment based on the key set to obtain an authorization result list; performing consistency verification and synchronization update based on the authorization results and the key set to obtain a final state table; performing symmetric encryption based on this state table to generate encrypted data packets; performing path monitoring and dynamic optimization based on the encrypted data packets to obtain an optimized transmission path; and performing integrity verification and data retransmission based on the path to obtain the final transmission result. This method can solve the problem of keys and permissions not being able to be updated synchronously under dynamic device changes.

Description

Technical Field

[0001] This invention relates to the field of smart city communication security technology, and in particular to a method and system for encrypting data transmission of monitoring equipment in smart cities. Background Technology

[0002] In the context of smart cities, the deployment of distributed devices is rapidly developing, leading to a surge in data communication demands. Especially in high-frequency data interaction scenarios involving numerous edge terminals such as monitoring equipment and sensor nodes, ensuring the security and integrity of data during transmission has become a crucial issue in the field of network information security. Traditional centralized communication models struggle to adapt to the complex environment of highly heterogeneous devices and frequent state changes. Systems often experience slow response times and information leaks when facing dynamic node changes, real-time performance assurance, and data encryption / decryption management. Therefore, constructing a secure communication method with real-time monitoring capabilities, dynamic key management mechanisms, and encryption path adaptation strategies has become a research focus in the field of smart city data networks.

[0003] In existing technologies, data encryption configuration in smart city monitoring networks is managed using static grouping and preset rule matching. Specifically, devices are initially grouped according to their type or function, and each group is assigned a fixed encryption key and communication permissions. Then, communication behavior is verified and authorized through rule matching. Key generation and permission configuration rely on periodic updates or manual adjustments, making it difficult to respond to dynamic changes in real time. In scenarios where devices are frequently added to or removed from the network, or whose status changes, this mechanism lacks flexibility and cannot adjust groups or quickly update keys based on real-time conditions. This easily leads to outdated encryption configurations and inconsistent communication permissions, resulting in communication interruptions, data transmission failures, and other problems, thus limiting the system's security and continuity assurance capabilities in large-scale, highly dynamic environments.

[0004] In summary, existing technologies suffer from the problem that keys and permissions cannot be updated synchronously under dynamic device changes. Summary of the Invention

[0005] This invention provides a method and system for encrypting data transmission from monitoring equipment in a smart city, to solve the problem of keys and permissions not being able to be updated synchronously under dynamic equipment changes. Firstly, to solve the above-mentioned technical problem, this invention provides a method for encrypting data transmission from monitoring equipment in a smart city, comprising:

[0006] Obtain the initial set of equipment categories;

[0007] Based on the initial set of device classifications, security groups are performed to obtain a security group list;

[0008] Based on the security packet list, communication requirements are collected and priority scheduling is performed to obtain a packet transmission scheduling scheme;

[0009] Based on the packet transmission scheduling scheme, an encryption key is generated to obtain an encryption key set;

[0010] Based on the set of encryption keys, dynamic authorization and permission adjustment are performed to obtain a list of authorization results;

[0011] Based on the authorization result list and the encryption key set, a consistency check and synchronization update are performed to obtain the final status table;

[0012] Based on the final state table, encryption processing is performed to obtain the encrypted data packet;

[0013] Based on the encrypted data packet, path monitoring and dynamic optimization are performed to obtain the optimized transmission path;

[0014] Based on the optimized transmission path, integrity verification and retransmission are performed to obtain the final transmission result.

[0015] Preferably, based on the initial set of device classifications, security grouping is performed to obtain a security group list, including:

[0016] Based on the initial set of device classifications, identity feature verification is performed to obtain a set of trusted devices;

[0017] Based on the set of trusted devices, state monitoring and feature extraction are performed to obtain a set of communication state feature vectors;

[0018] Based on the set of communication state feature vectors, group admission and permission configuration are performed to obtain a list of secure groups.

[0019] Preferably, based on the secure packet list, communication demand collection and priority scheduling are performed to obtain a packet transmission scheduling scheme, including:

[0020] Based on the security group list, communication load is collected to obtain a communication demand data table;

[0021] Based on the communication requirements data table, traffic analysis and performance evaluation are performed to obtain a packet communication performance report;

[0022] Based on the packet communication performance report, priority determination and scheduling configuration are performed to obtain a packet transmission scheduling scheme.

[0023] Preferably, according to the packet transmission scheduling scheme, an encryption key is generated to obtain an encryption key set, including:

[0024] Get the key update template;

[0025] Based on the hash algorithm, a hash key is generated for the packet transmission scheduling scheme to obtain an initial encryption key set;

[0026] Based on the initial encryption key set, device change records are generated to obtain a device change dataset;

[0027] Based on the device change dataset and the key update template, the key is updated and synchronized to obtain an encryption key set.

[0028] Preferably, dynamic authorization and permission adjustment are performed based on the encryption key set to obtain an authorization result list, including:

[0029] Obtain the communication request data and key update timestamps of each group device in the encryption key set;

[0030] Based on a hash algorithm, request features are extracted from the communication request data to obtain a request feature set;

[0031] Based on the request feature set, permission determination and instruction generation are performed to obtain the permission control set;

[0032] Based on the access control set and the key update timestamp, dynamic authorization and structure generation are performed to obtain an authorization result list.

[0033] Preferably, based on the authorization result list and the encryption key set, state extraction and consistency update are performed to obtain the final state table, including:

[0034] Based on the hash algorithm, state features are extracted from the authorization result list and the encryption key set to obtain a state feature set;

[0035] Based on the set of state features, a matching verification and instruction generation are performed to obtain an update instruction set;

[0036] Based on the set of update instructions, synchronous adjustments and state generation are performed to obtain the final state table.

[0037] Preferably, the encryption process is performed based on the final state table to obtain the encrypted data packet, including:

[0038] Based on the final state table, state extraction and symmetric encryption are performed to obtain a set of encrypted data packets;

[0039] Based on the set of encrypted data packets, an integrity check is performed to obtain valid encrypted data packets;

[0040] Based on the valid encrypted data packet, path planning and data transmission are performed to obtain the encrypted data packet.

[0041] Preferably, based on the encrypted data packet, path monitoring and dynamic optimization are performed to obtain an optimized transmission path, including:

[0042] Obtain the alternative path library;

[0043] Based on the encrypted data packet, path monitoring and performance data collection are performed to obtain a path status report;

[0044] Based on the path status report, a performance comparison and switching instruction generation are performed to obtain a set of path switching instructions.

[0045] Based on the path switching instruction set and the backup path library, dynamic optimization is performed to obtain the optimized transmission path.

[0046] Preferably, based on the optimized transmission path, integrity verification and retransmission are performed to obtain the final transmission result, including:

[0047] Based on the optimized transmission path, the reception status is collected to obtain the first reception report;

[0048] Based on the first received report, an integrity check is performed to obtain a set of data packet identifiers;

[0049] Based on the set of data packet identifiers, data packets are retransmitted and acknowledged to obtain the final transmission result.

[0050] Secondly, the present invention provides a data transmission encryption system for monitoring equipment based on smart cities, comprising:

[0051] The data acquisition module is used to obtain the initial set of device categories;

[0052] The security grouping module is used to perform security grouping based on the initial set of device classifications to obtain a security group list;

[0053] The transmission scheduling module is used to collect communication requirements and prioritize them according to the security packet list to obtain a packet transmission scheduling scheme.

[0054] The encryption key module is used to generate encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set;

[0055] The authorization result module is used to dynamically authorize and adjust permissions based on the encryption key set, and obtain a list of authorization results;

[0056] The final state module is used to perform consistency verification and synchronization update based on the authorization result list and the encryption key set to obtain the final state table;

[0057] The encryption module is used to perform encryption processing according to the final status table to obtain the encrypted data packet;

[0058] The optimization module is used to perform path monitoring and dynamic optimization based on the encrypted data packet to obtain the optimized transmission path;

[0059] The transmission result module is used to perform integrity verification and retransmission based on the optimized transmission path to obtain the final transmission result.

[0060] Thirdly, the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the data transmission encryption method for monitoring devices based on smart cities as described in any one of the above.

[0061] Fourthly, the present invention also provides a computer-readable storage medium comprising a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the data transmission encryption method for monitoring equipment based on smart cities as described above.

[0062] Compared with the prior art, the present invention has the following beneficial effects:

[0063] (1) By performing identity feature verification and status monitoring operations on the initial set of device classification, the present invention can effectively screen out trusted devices and extract their communication status features, thereby realizing group admission based on actual operating status, improving the pertinence and accuracy of security group configuration, and avoiding the risk of misconfiguration caused by static grouping.

[0064] (2) This invention extracts the transmission parameters of each group and generates a unique initial encryption key based on a hash algorithm. Combined with the device change record and the preset update template, it determines whether a key replacement operation is triggered, thereby realizing the dynamic update and synchronous management of the key set. It can effectively cope with the scenario of frequent changes in group devices and avoid communication interruption caused by key failure or asynchronous permissions.

[0065] (3) This invention extracts the group identifier and communication protocol content from the scheduling scheme, generates an encryption key by executing a hash algorithm, and updates the key according to the timestamp and type difference when the device is added or removed, so as to ensure that the key generation process is synchronized with the device status in real time and enhance the continuity and effectiveness of the encryption configuration.

[0066] (4) By monitoring the delay and bandwidth data of the current transmission path, the present invention generates a path switching instruction if the delay exceeds a preset threshold, and selects a path from the preset backup path library to perform the replacement. This ensures that encrypted data still has good transmission stability and timeliness under complex network conditions, and reduces the probability of data blocking and congestion. Attached Figure Description

[0067] Figure 1 This is a schematic diagram of the data transmission encryption method for monitoring equipment based on smart cities provided in the first embodiment of the present invention;

[0068] Figure 2 This is a schematic diagram of the data transmission encryption system for monitoring equipment based on smart cities provided in the second embodiment of the present invention. Detailed Implementation

[0069] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0070] Reference Figure 1 The first embodiment of the present invention provides a data transmission encryption method for monitoring equipment based on smart cities, including the following steps:

[0071] S11, Obtain the initial set of device categories;

[0072] S12, Based on the initial set of device classifications, perform security grouping to obtain a security group list;

[0073] S13, Based on the security group list, perform communication demand collection and priority scheduling to obtain a group transmission scheduling scheme;

[0074] S14, according to the packet transmission scheduling scheme, generate encryption keys to obtain an encryption key set;

[0075] S15, Based on the encryption key set, perform dynamic authorization and permission adjustment to obtain an authorization result list;

[0076] S16, Based on the authorization result list and the encryption key set, perform consistency verification and synchronization update to obtain the final status table;

[0077] S17, perform encryption processing according to the final state table to obtain the encrypted data packet;

[0078] S18, Based on the encrypted data packet, perform path monitoring and dynamic optimization to obtain the optimized transmission path;

[0079] S19. Based on the optimized transmission path, perform integrity verification and retransmission to obtain the final transmission result.

[0080] In step S11, an initial set of device categories is obtained.

[0081] It is worth noting that the specific process of obtaining the initial set of device classifications in step S11 includes the collection of device identification information, communication status judgment, establishment of basic data structures, and classification operations based on feature information. The goal of this step is to form a set of devices divided according to functional attributes, which serves as the basic input for subsequent encryption and scheduling operations, ensuring that the encryption strategy matches the communication structure.

[0082] First, a scanning tool deployed in a distributed network environment performs a comprehensive one-time scan of all node devices in the local area network, extracting the MAC address and IP address of each device. This operation uses the ARP scanning principle, sending address requests sequentially to all addresses within the network segment, and recording the device's unique hardware address and current network address in the returned packets. For example, using the Nmap tool to scan the subnet 192.168.10.0 / 24, the MAC address of device A is identified as 00-1C-B3-09-85-15, corresponding to the IP address 192.168.10.15, forming a unique device identifier pair.

[0083] Secondly, based on the acquired IP address list, a status probe command is sent to each device using the SNMP communication protocol to read the sysUpTime field. The SNMP communication request has a fixed timeout, such as 5 seconds. If the device returns a valid response within the time limit, it is considered online; otherwise, it is marked as offline. For example, device A responds in 1.2 seconds, returns normally, and its status is online; device B does not respond, and its status is offline. This process avoids human judgment errors by setting consistency standards, ensuring the uniformity and accuracy of device communication status information.

[0084] Next, the acquired MAC addresses, IP addresses, and communication status are grouped into structured data fields and written into the database in a unified table format. Taking MySQL as an example, the fields include mac_address, ip_address, and status. The database records are as follows: "00-1C-B3-09-85-15", "192.168.10.15", "online", ensuring that the information of each device is traceable, searchable, and updatable.

[0085] To meet the differentiated scheduling requirements of subsequent tasks, devices need to be initially classified based on their type and communication response characteristics. The K-means algorithm is used for automatic device classification during the clustering process. Specifically, each device is first represented as a two-dimensional feature vector, with dimensions representing the device type code and the communication response latency, respectively. The K-means algorithm iteratively calculates the Euclidean distance between the device and the cluster center, grouping similar devices into the same cluster and continuously updating the cluster centers until the intra-cluster error converges. To control the convergence condition of the algorithm and ensure clustering accuracy, the system sets the intra-cluster error threshold to 0.05 seconds², meaning the average squared difference in response latency from each device to the cluster center does not exceed 0.05 seconds². This threshold is set based on statistical results of the response fluctuation range of high-performance devices (such as servers) in actual sampling, effectively preventing mixed classification of device performance and thus improving the accuracy and stability of subsequent scheduling and encrypted grouping.

[0086] Finally, the clustering results are output as an initial set of device categories, which contains unique identification information for each device, including fields such as MAC address, IP address, device type, and response time.

[0087] In step S12, based on the initial set of device classifications, security groups are performed to obtain a security group list, including:

[0088] Based on the initial set of device classifications, identity feature verification is performed to obtain a set of trusted devices;

[0089] Based on the set of trusted devices, state monitoring and feature extraction are performed to obtain a set of communication state feature vectors;

[0090] Based on the set of communication state feature vectors, group admission and permission configuration are performed to obtain a list of secure groups.

[0091] It's worth noting that the system compares the MAC address of each device with a locally registered whitelist to determine if it's an authorized access device. If the device's MAC address isn't in the whitelist, it's directly removed. Next, the system reads each device's IP address and matches it with the assigned IP range in the registry to confirm its network affiliation. If the IP address is in an illegal range, such as a public IP or an unknown address, it's marked as an untrusted device. Furthermore, the system also verifies the device's registration time and device ID. For example, if a device's registration time exceeds a set limit (e.g., 365 days) and its information hasn't been updated, it's considered an invalid device and not included in the trusted set. After completing these comparisons, the system includes all verified devices in the trusted device set. This set includes fields such as device ID, MAC address, IP address, and identity verification status; each record corresponds to a device with a valid authentication identity.

[0092] A status monitoring process is initiated for each device by periodically sending SNMP GET requests to read communication status fields such as device response time, packet processing rate, and CPU utilization. For example, device A has a response time of 0.15 seconds, a packet processing rate of 300 packets per second, and a CPU utilization of 25%. This raw monitoring data is then used as input parameters in the feature extraction operation.

[0093] During feature extraction, parameters such as response time, data rate, and CPU utilization are first normalized and converted to a percentage scale. For example, a response time of 0.15 seconds is normalized to 30 points, a data packet rate to 60 points, and CPU utilization to 50 points. These three features are then combined into a three-dimensional feature vector representing the device's communication status. Finally, the vector set of all trusted devices is stored uniformly, called the communication status feature vector set. Each record in this set uniquely corresponds to a device and contains three field values ​​used for subsequent group admission determination and permission configuration operations.

[0094] The communication state feature vector set is composed of numerical values ​​in three dimensions for each trusted device: communication response time, data packet processing rate, and CPU utilization. For example, a device's vector might be <30, 60, 50>, representing the normalized response latency, data packet processing rate, and resource utilization, respectively. Based on this set, a group admission process is first performed, comparing each device's vector value with a preset admission range to determine if it meets the basic requirements for secure communication. For example, devices with a response time below 50, a data packet processing rate above 40, and a CPU utilization not exceeding 70% can enter the high-priority group. If a device's vector is <45, 65, 60>, meeting the requirements, it is marked as admitted.

[0095] Next, the permission configuration operation is performed, assigning different levels of communication permissions based on the group to which the device belongs. High-priority group devices can obtain larger bandwidth and lower latency channels for core data interaction; low-priority group devices are restricted to communication during non-critical periods to avoid resource conflicts. The permission configuration table records the MAC address, group number, and corresponding permission level of each device. For example: MAC address 00:1A:2B:3C:4D:5E, group number 1, permission level is high.

[0096] Finally, the system generates a security group list, which includes the grouping results and permission identifiers of each device. This list is structured into a form and saved to provide a basis for subsequent scheduling and key management.

[0097] In step S13, communication requirements are collected and priority scheduling is performed based on the secure packet list to obtain a packet transmission scheduling scheme, including:

[0098] Based on the security group list, communication load is collected to obtain a communication demand data table;

[0099] Based on the communication requirements data table, traffic analysis and performance evaluation are performed to obtain a packet communication performance report;

[0100] Based on the packet communication performance report, priority determination and scheduling configuration are performed to obtain a packet transmission scheduling scheme.

[0101] It is worth noting that, based on the established security group list, the communication load of devices within each group is collected in real time or periodically, and a communication demand data table is output in a standardized structure. First, the device identification information for each group is extracted from the security group list, including the device's MAC address and IP address. This list clearly defines the group affiliation and communication permission scope of each device, thus serving as the starting point for monitoring device communication status.

[0102] During the data collection process, the system uses network traffic monitoring tools (such as NetFlow or sFlow) to listen to the network interfaces of devices within the group, recording multiple parameters such as the total number of data packets per unit time, average data packet length, bandwidth utilization, and number of connection sessions. The collection period can be set to 5 minutes to balance real-time performance and resource overhead. If a device's network interface generates a total of 5000 data packets within the period, with a total data volume of 300MB, the system records its average transmission rate as 10Mbps and bandwidth utilization as 20%.

[0103] After data collection, the system organizes the data into a communication demand data table for each group. This table includes fields such as group ID, device IP address, bandwidth utilization, packet frequency, peak traffic, and number of active connections. The values ​​for each field are derived from the statistical processing of the aforementioned monitoring data. For example, a record might show: group ID SG01, device IP 192.168.1.100, average bandwidth utilization of 18%, average number of packets sent per second of 1200, and number of connections of 8.

[0104] Based on the communication demand data table collected in the previous stage, the system performs traffic analysis and performance evaluation on the communication status of each security group, thereby quantifying the network load level and communication stability of each group and ultimately generating a structured group communication performance report. The communication demand data table contains multiple fields, including group identifier, device IP address, average bandwidth utilization, packet sending frequency, peak traffic, packet loss rate, number of connection interruptions, and average latency. This data is compiled and summarized by network detection tools after monitoring device ports within a set period.

[0105] During traffic analysis, the system first iterates through all traffic records of devices within each group, calculating the group's average bandwidth utilization and peak bandwidth. Taking group SG01 as an example, its three subordinate devices have bandwidth utilization rates of 20%, 30%, and 25%, respectively, and one device has a peak bandwidth of 50Mbps. The system uses a weighted average method to derive the group's average bandwidth. In the weighted calculation of utilization, the weights are determined based on the proportion of each device in the total communication volume. If the data transmission volumes of the three devices are 200MB, 400MB, and 300MB, respectively, the corresponding weights are 2:4:3. According to the weighted average formula, the group's average bandwidth utilization is (20×2+30×4+25×3) / (2+4+3)=26.67%. The peak bandwidth is directly taken as the maximum value of each device during the observation period. Next, the system evaluates the packet sending frequency and packet loss rate, counting the total number of successfully sent packets and the number of failed responses per unit time, and calculating the packet loss ratio. If the packet loss rate exceeds 5% or connection interruptions occur frequently, the communication is considered unstable.

[0106] For connection interruptions, the system counts the number of interruptions and combines this with the average latency to determine network fluctuations. All data is normalized and scored using a percentage system. The performance evaluation section converts the results of each indicator into scoring dimensions; for example, bandwidth utilization above 80% scores 90, latency below 50 milliseconds scores 95, and packet loss rate below 2% scores 92. The system calculates the final performance score within each group based on the weight of each indicator and assigns a rating. For example, a score above 90 is excellent, 70 to 90 is good, and below 70 is questionable. The final generated packet communication performance report records the performance score, bottleneck description, abnormal indicators, and warning signs for each group in tabular form. For example, the SG01 report lists: average bandwidth utilization of 26.67%, packet loss rate of 1.2%, total score of 91, rating of excellent, no adjustment required at present.

[0107] Based on key indicators such as the security packet score, bandwidth utilization, packet loss rate, and connection stability in the packet communication performance report, the system performs priority determination and scheduling configuration operations. First, the system sorts packets from highest to lowest score; for example, packets with scores above 90 are considered high priority, those between 70 and 90 are medium priority, and those below 70 are low priority. Then, the system prioritizes various tasks based on their importance to the business; for example, video surveillance packets are set to high priority, environmental awareness packets to medium priority, and periodic data collection packets to low priority.

[0108] During the scheduling configuration process, the system allocates available bandwidth and scheduling cycles based on priority levels. For example, if the total available network bandwidth is 100Mbps, high-priority groups will receive over 40% of the resources, medium-priority groups 30%, and the remainder allocated to low-priority groups. Furthermore, the system sets different refresh cycles for the scheduling intervals; for example, high-priority groups are scheduled every 5 seconds, medium-priority groups every 15 seconds, and low-priority groups every 30 seconds. If a group experiences a sudden surge in traffic and current bandwidth is insufficient, the system will determine if its priority is higher than other groups in the same area. If so, the scheduling table will be dynamically adjusted to increase its bandwidth allocation.

[0109] Finally, the system generates a packet transmission scheduling scheme, recording the scheduling time interval, allocated bandwidth limit, preset channel priority, and bandwidth reservation for each packet. This scheduling scheme will serve as the foundational data for subsequent encryption key generation and bandwidth control strategies, ensuring the transmission quality and timeliness of high-priority tasks.

[0110] In step S14, according to the packet transmission scheduling scheme, an encryption key is generated to obtain an encryption key set, including:

[0111] Get the key update template;

[0112] Based on the hash algorithm, a hash key is generated for the packet transmission scheduling scheme to obtain an initial encryption key set;

[0113] Based on the initial encryption key set, device change records are generated to obtain a device change dataset;

[0114] Based on the device change dataset and the key update template, the key is updated and synchronized to obtain an encryption key set.

[0115] It's worth noting that the system accesses a locally configured key policy template library and calls the key update template corresponding to the current network security level. This template is preset by the system administrator and is in JSON or XML format. Its content includes fields such as key validity period, device change trigger threshold, and maximum number of recalculation attempts. For example, for a Level 1 security group, the system loads a template named "key_policy_level1.json" with fields setting "key validity period" to 48 hours and "device change threshold" to 2 devices, indicating that key recalculation should be performed when more than two devices in a group have changed within 48 hours.

[0116] After receiving the packet transmission scheduling scheme, the system processes the identification information of each secure packet and the scheduling parameters as input to form a unique encryption key. The operation process includes the following three steps:

[0117] First, the system extracts the unique identifier (e.g., group number SG01) and the current combination of scheduling parameters (e.g., bandwidth allocation ratio of 70% and priority level of 1) for each group from the scheduling scheme. This information is concatenated into a string, such as "SG01-70-1", and used as input data.

[0118] Second, the concatenated string is input into a hash function for digest calculation. The hash algorithm used is SHA256, which calculates a fixed-length hash value from an input of arbitrary length. In the specific calculation process, SHA256 converts the string into binary and performs multiple rounds of logical AND bitwise operations, finally outputting a 256-bit hash value, such as "3a7c9f...ec12";

[0119] Third, the system extracts the first 128 bits of the hash value as the initial encryption key for that packet. The generated initial key is then bound to the current packet ID, forming a pair of "packet ID – initial key" entries. All the key entries for all packets are aggregated to form the initial encryption key set, which is written to the encryption configuration file for subsequent encrypted communication calls.

[0120] Taking the SG01 block as an example, its initial key is the first 128 bits of "3a7c9f...", which will be used as the core of symmetric encryption in the actual data transmission process.

[0121] Based on the initial encryption key set generated in the previous stage, the system performs real-time comparison of the device composition within each security group to identify any changes such as the addition or offline of devices, thereby recording and forming a device change dataset. The specific operation process is as follows:

[0122] First, the system reads the "Block Identifier - Initial Key" entry recorded in the encryption configuration file and establishes a mapping relationship between the current block and the encryption key. Each block identifier corresponds to the set of devices bound during the initial encryption, and this information is indirectly reconstructed by the system through historical communication scheduling records.

[0123] Next, the system calls the network status monitoring interface to poll and collect the device status under each group, obtaining the latest device online status and identifier set. Taking group SG01 as an example, if the original configuration contains devices A, B, and C, and the current polling result is A, B, and D, then it is determined that device C is offline and device D is newly added.

[0124] The system extracts these changes into change record entries using difference calculation, including fields such as group ID, change type (new or offline), device MAC address, IP address, and change timestamp. For example, the record for device D is: SG01, New, 00:1A:2B:3C:4D:5F, 192.168.1.105, 2025-06-03 14:32:00. The system aggregates all change entries into a device change dataset, which is used for subsequent matching with the key update template to determine whether to trigger the key update process.

[0125] Based on the device change dataset generated in the previous stage and the loaded key update template, the system matches each change event one by one to determine whether the key update conditions are met, and accordingly completes the key content replacement and version synchronization to obtain the updated encryption key set. The specific operations are as follows:

[0126] First, the system iterates through each change record in the device change dataset, extracting the group identifier, change type, and device identifier information. For example, if a record is "SG02, New, 00:1A:2B:3C:4D:6E", it means that a new device has been added to the SG02 group. Based on this, the system searches for the corresponding update rule for SG02 in the key update template, for example, specifying that "if the number of devices in any group changes by more than one, the key must be updated."

[0127] Once a match is successful, the system immediately calls the key update interface to recalculate the new encryption key for the block. The update method involves concatenating the original initial key with the current timestamp to form a new input, which is then processed by the SHA256 function to obtain a new hash digest. For example, concatenating the original key "3a7c9f..." with the time "2025-06-03 16:00:00" to form "3a7c9f...-20250603160000", inputting this into the hash function, and truncating the first 128 bits of the output value as the new key.

[0128] The system then replaces the original key entries with the new key and marks the version number as upgraded, such as "v2". Finally, all updated or unchanged block keys are written into the encryption configuration file to form a new set of encryption keys.

[0129] In step S15, dynamic authorization and permission adjustment are performed based on the encryption key set to obtain an authorization result list, including:

[0130] Obtain the communication request data and key update timestamps of each group device in the encryption key set;

[0131] Based on a hash algorithm, request features are extracted from the communication request data to obtain a request feature set;

[0132] Based on the request feature set, permission determination and instruction generation are performed to obtain the permission control set;

[0133] Based on the access control set and the key update timestamp, dynamic authorization and structure generation are performed to obtain an authorization result list.

[0134] It's worth noting that the system, based on the generated encryption key set, sequentially reads the device identifiers contained in each group and performs communication request data collection and key update timestamp extraction operations for each device. The communication request data refers to the number of valid communication connections initiated by the device per unit time, the total number of requests, and the cumulative data transmission volume. This data is obtained by reading NetFlow or sFlow data from firewall or router logs and aggregating statistics based on the request source IPs. The key update timestamp refers to the last time an encryption key was generated for the group to which the device belongs. This time information is stored in the encryption key generation log and is automatically recorded each time a key is updated. Taking the terminal device in group SG03 as an example, the system reads its MAC address and finds that the device initiated 180 connection requests in the past 5 minutes, with a cumulative traffic of 350MB, while its last key update time was 14:30 on October 1, 2024.

[0135] The system performs hash feature extraction on the collected communication request data to generate a stable and comparable set of request features. The operation process is as follows: First, the system selects three key parameters from the communication request data as input, including request initiation frequency, average data volume per request, and request-response ratio. These three parameters constitute an initial feature string. For example, if a device initiates 120 requests within 5 minutes, with an average transmission volume of 2.5MB per request and a response ratio of 95%, this feature string is assembled into the string "120-2.5-95" and used as the hash input.

[0136] Subsequently, the system calls the SHA256 hash algorithm to perform a digest operation on the input string. SHA256 maps strings of arbitrary length to 256-bit binary hash codes using a fixed encryption function. This process involves bit shifting, logical AND operations, and modulo addition to ensure that the output value uniquely maps to the input. The first 64 bits of the resulting hash code are truncated as the request feature fingerprint. For example, if the hash result is "ab3f...c7e1", the truncated result is "ab3f...d9b2", which is the request feature of this device. The feature fingerprints of all devices are compiled into a request feature set and bound to the device identifier, then stored in the database.

[0137] The system matches the communication request record from which each feature value in the request feature set originates, and identifies the corresponding device identifier and group accordingly. Subsequently, the system performs permission determination operations based on the device's request frequency and data volume metrics. The specific operation process is as follows: First, the system presets a permission threshold table, for example, dividing request frequency levels into five levels and data volume levels into four levels, and stipulating that when a device's request frequency and data volume levels are both higher than level three, it is considered to be in a high-load state.

[0138] For devices that meet high load conditions, the system generates access control instructions such as "restrict communication" or "reduce transmission frequency"; for devices in low load conditions, it generates instructions such as "maintain communication" or "normal transmission". All instructions are organized using the device identifier as the index and associated with the current group identifier, and are uniformly constructed into a structure of "device ID - access control status - control instructions", which together form a complete access control set.

[0139] Based on the access control set obtained in the previous stage and the key update timestamp corresponding to each device, the system performs dynamic authorization and result structure generation operations. The operation process first uses the device identifier as an index to traverse each record in the access control set, while simultaneously reading the device's last update time information in the key set. The system compares the current system time with the key update timestamp; if the time interval exceeds a preset threshold (e.g., 60 minutes), it determines that the key may have expired or there is a risk of inconsistent access control status.

[0140] For devices that meet the update requirements, the system marks their access control records as "requires authorization adjustment" and regenerates authorization entries in the format "Device ID – Permission Status – Key Update Time – Authorization Status". The authorization status field indicates whether the authorization is automatically synchronized, whether it overwrites the original permissions, etc. For devices that do not require adjustment, their original records are retained and marked as "Maintain".

[0141] After all records are aggregated, a structured list of authorization results is generated. This list can be directly imported into the permission distribution program and used in the next step of communication configuration.

[0142] In step S16, based on the authorization result list and the encryption key set, state extraction and consistency update are performed to obtain the final state table, including:

[0143] Based on the hash algorithm, state features are extracted from the authorization result list and the encryption key set to obtain a state feature set;

[0144] Based on the set of state features, a matching verification and instruction generation are performed to obtain an update instruction set;

[0145] Based on the set of update instructions, synchronous adjustments and state generation are performed to obtain the final state table.

[0146] It's worth noting that the system takes the authorization result list and encryption key set as input, performs hash calculations on each record, and extracts its status feature information. The operation first performs field concatenation on each authorization entry, concatenating fields such as device identifier, current permission level, authorization timestamp, and corresponding encryption key value into a single string in a preset order, for example, "SG01-AUTH1-20250601-KeY88F3". Then, the system calls the SHA256 hash algorithm to perform a digest operation on this concatenated string, converting it into a 256-bit hash value. This hash value can be considered a unique feature representing the current status of the authorization record, simultaneously reflecting the joint characteristics of permission status and encryption configuration.

[0147] In actual processing, all hash results are uniformly stored in a list structure, which is the state feature set. Each item in the state feature set is accompanied by the index number of its original record, used for subsequent comparison and updates. Taking the SG01 device as an example, its authorization status is "enabled", the latest key value is "KeY88F3", and the generated state feature value is such as "c9f0...3a71". During the consistency verification phase, it will be compared with the previously stored historical state feature values ​​to determine whether its status has changed.

[0148] Based on the set of status features extracted in the previous stage, the system compares each feature item with the feature values ​​stored in its historical records to determine whether the authorization status or key configuration of the device has changed. Specifically, the system reads the historical hash values ​​from the current status table in the database and compares them one by one with the corresponding items in the latest status feature set. If the hash values ​​are different, it indicates that the current device status has been updated. The comparison operation uses a string equality comparison method to ensure the uniqueness and accuracy of the comparison results.

[0149] Once a status difference is detected, the system generates a corresponding update instruction based on the type of difference. If the difference stems from a change in permission level, a permission adjustment instruction is generated, such as "Device SG01's permission is changed from AUTH1 to AUTH2"; if the difference stems from an encryption key update, a key synchronization instruction is generated, such as "Device SG01 enables new key 3a7c9f". All generated instructions are written into the update instruction set, and each instruction structure includes fields such as device identifier, instruction type, original status value, and target status value.

[0150] For example, for device SG01, if its status characteristic value changes from "9f3a...1e7c" to "c4b2...9a11", and the comparison result is inconsistent, the system generates an update instruction: "SG01, update key, synchronize to c4b2...".

[0151] Based on the set of update instructions generated in the previous stage, the system executes the corresponding operations one by one to achieve real-time updates of the status of each device, and writes the update results into the final status table. The specific process includes two stages: synchronization adjustment and status generation.

[0152] First, the system reads each update command and determines its type. If it's a permission adjustment command, the system calls the relevant authorization management program through the device control interface to replace the old value of the target device's permission field with the new value. If it's a key synchronization command, the system replaces the original key in the device configuration with a newly generated encryption key through the encryption service interface. After each command is executed, the system records its execution time, execution result, and corresponding device number, forming an intermediate log record.

[0153] Then, in the state generation phase, the system constructs a new state table structure based on the final results of all update operations. This state table contains information such as device identifier, current permission level, encryption key number, and synchronization status field. Taking device SG01 as an example, if its original permission was AUTH1 and key number was K1, and it is updated to AUTH2 and K3, then the corresponding row in the final state table for this device will be updated to SG01, AUTH2, K3, and synchronized. The final state table is stored in the database in a structured format for subsequent communication encryption, permission verification, and network scheduling operations.

[0154] In step S17, encryption is performed according to the final state table to obtain the encrypted data packet, including:

[0155] Based on the final state table, state extraction and symmetric encryption are performed to obtain a set of encrypted data packets;

[0156] Based on the set of encrypted data packets, an integrity check is performed to obtain valid encrypted data packets;

[0157] Based on the valid encrypted data packet, path planning and data transmission are performed to obtain the encrypted data packet.

[0158] It is worth noting that the system performs state extraction and symmetric encryption operations based on the device identifier, current status value, and authorization key number recorded in the final status table, generating a set of encrypted data packets. The specific operation process is as follows:

[0159] First, the system reads the status field of each device from the final status table, which includes the device ID, key number, authorization level, and data preparation flag. The system then combines these status values ​​as parameters to call the key management subsystem to load the encryption key corresponding to the key number. Each status record is bound to only one key, ensuring consistency in subsequent encryption operations.

[0160] Subsequently, the system organizes the raw business data to be sent by the device along with its status parameters into a standard data structure, and inputs it into a symmetric encryption function for encryption. The encryption process uses the AES algorithm, employing a key retrieved from key management to encrypt the raw data in 128-bit blocks in rounds. During each round of encryption, the system performs byte substitution, row shifting, column mixing, and round key addition operations, ultimately outputting a ciphertext block. Each encryption operation corresponds to a unique device and key combination, avoiding interference caused by cross-device or repeated encryption.

[0161] For example, in the status record of device ID D01, the key number is K3. After the system extracts the data block to be transmitted from D01, it performs AES encryption using key K3 to generate the ciphertext "9f3d2a...". This ciphertext data is packaged into encrypted data packets, and a block identifier and destination address are added, ultimately forming a set of encrypted data packets.

[0162] The system performs integrity checks on each encrypted data packet generated in the previous stage to identify potential data corruption during encryption or caching. The specific process includes three steps: recalculating the checksum, comparing the results, and filtering the data.

[0163] First, the system extracts the encrypted main content from each data packet and reads the original checksum field attached to the data packet. This field is a four-byte checksum calculated using the CRC32 algorithm when the data packet was generated, used to identify the state characteristics of the data content at the time of generation.

[0164] Next, the system re-executes the CRC32 operation on the current content of the data packet. The core process of CRC32 includes initializing a 32-bit register, performing an XOR operation on each byte of the data byte sequence, and using a preset polynomial for right shifting and table lookup correction. Taking the data content "0x3A 0x7F 0x12" as an example, the system takes 0x3A as the starting byte, performs an XOR operation with the initial register value, looks up the value in the table, and then performs another XOR operation with 0x7F. This process is repeated until the last byte 0x12, finally yielding a 32-bit checksum such as "F28D7C1A".

[0165] The system then compares the newly generated checksum with the original CRC field in the data packet bit by bit. If they match perfectly, it means that the data packet has not undergone any content changes during storage and encryption, and the system marks it as a "valid encrypted data packet." If there is any bit difference in the comparison result, it is considered that the structure or content of the data packet is corrupted, and the system removes it and records the abnormal entry. The system aggregates all data packets that pass the checksum to form a "set of valid encrypted data packets."

[0166] The system first extracts the target device number from the data packet, and then retrieves the connection relationship corresponding to the target device from the network topology information table. This connection relationship predefines the communication links between each device, including parameters such as the device pairs connected to each path, link identifier, physical bandwidth, current queue length, and connection latency.

[0167] The path planning operation follows the "shortest reachable path first" principle. The system generates a topology map internally, taking the current sending node as the starting point and the target device as the ending point. By traversing all possible paths in the topology and prioritizing them according to path bandwidth, congestion level, and transmission distance, the system selects the reachable path with the best overall performance as the forwarding route.

[0168] The ranking criteria can be set by weighting. For example, if the bandwidth weight is set to 0.4, the delay weight to 0.3, and the congestion weight to 0.3, the system will normalize the three criteria and perform a weighted summation calculation to obtain the cost value of each path. The path with the lowest cost value will be selected as the transmission path.

[0169] Once a path is selected, the system delivers data packets to the next-hop device according to the order of the path nodes. This process is accomplished through network interface calls; for example, a TCP socket communication interface can send data packets via the source device port to the device port corresponding to the next-hop address identifier. The sending and receiving times are recorded for each forward, facilitating subsequent latency backtracking and performance analysis.

[0170] Finally, the encrypted data packet is transmitted from the source device to the target device via a selected path through multiple hops. After this process is completed, the system marks the data packet as "sent" and generates an encrypted transmission record, which includes the source device, target device, path number, timestamp, and transmission success identifier, facilitating subsequent tracking and anomaly analysis.

[0171] In step S18, based on the encrypted data packet, path monitoring and dynamic optimization are performed to obtain the optimized transmission path, including:

[0172] Obtain the alternative path library;

[0173] Based on the encrypted data packet, path monitoring and performance data collection are performed to obtain a path status report;

[0174] Based on the path status report, a performance comparison and switching instruction generation are performed to obtain a set of path switching instructions.

[0175] Based on the path switching instruction set and the backup path library, dynamic optimization is performed to obtain the optimized transmission path.

[0176] It's worth noting that the backup path library refers to a set of feasible transmission paths from the source node to the target node pre-built during the system deployment phase. This provides a basis for rapid switching in case of performance degradation or interruption risks during actual data transmission. The construction process of this path library is as follows: First, the system obtains the connection relationships of each node based on the network topology, traverses all connected paths from each source node to the target node, and records key parameters such as the relay node sequence, hop count, link bandwidth, historical average latency, and packet loss rate. Second, the system filters the path parameters, excluding unstable paths. For example, the system sets a minimum bandwidth threshold of 20Mbps, which stems from the minimum transmission requirements of high-definition video streams or high-frequency command interactions in actual business. If the historical average bandwidth of a path is lower than this threshold, it is considered unable to support stable communication and is excluded from the backup path library. Simultaneously, paths with a historical average latency exceeding 150 milliseconds are also removed because they are prone to causing interaction stuttering or control command delays. Finally, the remaining paths are written to the database, forming a static backup path library. For example, if S1 is the source node and T1 is the target device, the system may record path one as S1-N2-N3-T1 and path two as S1-N4-N6-T1. Each path contains fields such as bandwidth, latency, and packet loss rate, providing a data basis for runtime path selection and dynamic switching.

[0177] After receiving the encrypted data packet, the system automatically extracts the target device address information and preset path number, and performs real-time monitoring on each network relay node it passes through. Specifically, the system deploys a data monitoring program on each relay node. This program records a timestamp when a data packet passes through a node and measures the actual transmission delay, bandwidth utilization, and packet loss count with the next node. The delay is calculated by subtracting the time the previous node sent the data packet from the time the node received it. Bandwidth utilization is obtained by detecting the ratio of the current node's sending queue to its bandwidth limit. For example, if the current rate is 20Mbps and the maximum bandwidth is 100Mbps, the bandwidth utilization is 20%. The packet loss rate is calculated as the ratio of the number of unacknowledged data packets to the total number of packets sent per unit time.

[0178] After data packets complete their path transmission, the system aggregates the latency, bandwidth utilization, and packet loss rate data recorded by each relay node to generate a path status report. This report, indexed by path number, includes performance metrics for each hop node, anomaly event markers, and historical comparison data, used for subsequent path switching and optimization operations. For example, the report for path number R3 records: the latency from nodes N2 to N5 is 50 milliseconds, the bandwidth utilization is 85%, and two packet losses occurred within the last two minutes. Based on this, the system can determine that the current performance of this path exhibits abnormal fluctuations, marking it as "suboptimal," thus preparing for subsequent switching.

[0179] After receiving the path status report, the system analyzes the performance metrics of each relay node in the report item by item and compares them with preset performance thresholds. The path status report contains several key fields, such as the average transmission delay per hop, bandwidth utilization, packet loss rate per unit time, and whether there are short-term interruption records. The system compares these fields item by item with the corresponding thresholds. Taking bandwidth utilization as an example, the system sets the threshold to 80%. If the utilization of any node in a path exceeds this threshold, the path is judged to have a congestion risk; the latency threshold is set to 50 milliseconds, and if it exceeds this value, it is considered to have a risk of slow transmission; a packet loss rate exceeding 5% is considered an unstable path.

[0180] If any of the above indicators exceeds the threshold, the system will mark the path as "suboptimal" or "abnormal" and generate a path switching instruction accordingly. This instruction explicitly specifies the group number to be switched, the original path identifier, and the preset backup path number. For example, if an encrypted data packet with the number SG03 is currently using path R3, and the status report shows a latency of 70 milliseconds for node N2, the system will generate a switching instruction based on the judgment result: "SG03 switches from R3 to R7". All generated path switching instructions will form a path switching instruction set, serving as input for subsequent dynamic optimization steps. This ensures that data transmission can quickly switch to a better path when performance is abnormal, improving the overall communication stability and real-time response capability of the system.

[0181] Upon receiving the path switching instruction set and the backup path library, the system will immediately perform dynamic optimization operations. The path switching instruction set contains the group number of each path to be replaced, the currently used path number, and the target replacement path number; the backup path library records multiple reachable paths from each source node to the target node in the current network and their corresponding path attribute data, including indicators such as bandwidth utilization, hop count, and historical stability level.

[0182] The optimization process consists of two steps. The first step is path matching: the system iterates through the path switching instruction set, sequentially reading each instruction that needs optimization, and extracting the group number and the target replacement path number. It then searches the backup path library for all candidate paths corresponding to the target path number, filtering out the candidate path set that meets the minimum hop count or the lowest bandwidth utilization. For example, if the path switching instruction is "SG04 switch to R6", the system will search the library for all reachable paths from the source to the target corresponding to R6. If path R6 has three candidate routes R6-1, R6-2, and R6-3, the system will calculate their historical average latency and bandwidth usage, selecting the one with the highest score as the final transmission path.

[0183] The second step is path replacement: The system writes the selected new path into the transmission control table, marks the original path as invalid, and updates the target route field of the corresponding encrypted data packet in the scheduling queue. For example, if the original path R3 is replaced with R6-2, then R6-2 will be used as the optimized transmission path for SG04 packets in subsequent communication tasks.

[0184] In step S19, integrity verification and retransmission are performed according to the optimized transmission path to obtain the final transmission result, including:

[0185] Based on the optimized transmission path, the reception status is collected to obtain the first reception report;

[0186] Based on the first received report, an integrity check is performed to obtain a set of data packet identifiers;

[0187] Based on the set of data packet identifiers, data packets are retransmitted and acknowledged to obtain the final transmission result.

[0188] It is worth noting that the system uses the optimized transmission path as a basis to collect the reception status of the transmission terminal device in real time to generate the first reception report. The optimized transmission path is the result of the dynamic path adjustment in the previous stage, and is a set of paths in the current network with low transmission latency, stable bandwidth, and controllable hop count. The system performs data monitoring operations on the target device node according to this path, and captures the data arrival status of the device interface within a specified time window through the reception status collector.

[0189] During the data collection process, the system records the receiving timestamp and original assigned sequence number for each transmitted data packet, and associates and binds them with the preset path target to form a structured receiving record entry. For example, when the encrypted data packet with the number D102 is sent to device T5 through path R1, the system detects on T5 that its receiving time is June 1, 2025, 10:20:05, and its sequence number is 102, and then generates the record entry "Sequence number 102, timestamp 10:20:05, target T5".

[0190] All received records are written to the receiving database in real time. The system periodically aggregates and cleans the collected results using the devices as indexes, and finally outputs a complete first receiving report. This report includes fields such as the number of data packets received by each device, a list of sequence numbers, corresponding timestamps, and receiving delays. These are used for subsequent integrity verification analysis and retransmission determination to ensure that each data transmission has clear receiving feedback and time reference.

[0191] Based on the first reception report, the system verifies the integrity of each received data packet, identifying any risks of content corruption, structural abnormalities, or loss and retransmission during transmission. The first reception report records fields such as the sequence number, reception timestamp, and target device identifier of each data packet, providing a basic index for subsequent verification.

[0192] The system performs CRC32 verification on each received data packet using a data verification tool. This algorithm performs bit-level processing on the data packet content using generator polynomial division. Specifically, the system first XORs the entire binary content of the data packet with a fixed 32-bit generator polynomial (e.g., 0x04C11DB7) for initialization. Then, it sequentially performs shift and conditional XOR operations on each bit of the data stream. In each operation, if the current highest bit is 1, the current register content is XORed with the generator polynomial; if it is 0, a left shift operation is performed, ultimately obtaining a 32-bit cyclic redundancy check value.

[0193] This checksum is the hash digest of the data content. The system then compares it with the original CRC value pre-generated and encapsulated in the end of the message before transmission. If they match, the system determines that the data packet has not been altered during transmission; if the checksums differ, it is assumed that the data content has encountered errors or been tampered with during transmission, and the data packet is marked as abnormal. The system extracts and summarizes the numbers and sequence numbers of all data packets that fail the checksum, forming a "data packet identifier set".

[0194] Based on the data packet identifier set generated in the previous stage, the system identifies data packet items that failed the integrity check and performs retransmission and acknowledgment operations on the data packets corresponding to these identifiers to ultimately complete the closed-loop process of data transmission. The data packet identifier set contains information such as sequence number, destination device address, and original transmission time, which allows the system to quickly locate the source data packet copy that needs to be retransmitted in the original data buffer.

[0195] In practice, the system first accesses the cache through an index, dequeues the data packets that need to be retransmitted, repackages the packet header, adds a new timestamp and sequence marker, and then sends it to the target device node using the previously selected optimized transmission path. After the data is retransmitted, the system simultaneously opens an acknowledgment listening channel to parse the response from the target device and listen for its returned receive acknowledgment response.

[0196] For example, when data packet number D102 is identified as an anomaly due to verification failure, the system retrieves the original content of D102 from the cache, reencrypts it, and sends it to device T5. Subsequently, it receives an "ACK-102" response in the receive window, confirming that the data packet has been received and accepted by the target device. This type of confirmation operation can be configured with a maximum number of attempts and a timeout mechanism. The maximum number of retransmissions is set to 3, and the timeout is 3 seconds. Exceeding the number of attempts or not receiving confirmation will trigger an anomaly report.

[0197] The system ultimately marks success and failure results based on the retransmission status of each identifier, and generates a structured "Final Transmission Result" record table containing fields such as packet number, destination node, acknowledgment status, retransmission count, and final status. This provides a traceable basis for the stability assessment of the entire data link and subsequent network maintenance. This step ensures that all critical data has a closed-loop acknowledgment system, significantly improving the system's data reliability and transmission integrity.

[0198] Reference Figure 2 The second embodiment of the present invention provides a data transmission encryption system for monitoring equipment based on smart cities, comprising:

[0199] The data acquisition module is used to obtain the initial set of device categories;

[0200] The security grouping module is used to perform security grouping based on the initial set of device classifications to obtain a security group list;

[0201] The transmission scheduling module is used to collect communication requirements and prioritize them according to the security packet list to obtain a packet transmission scheduling scheme.

[0202] The encryption key module is used to generate encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set;

[0203] The authorization result module is used to dynamically authorize and adjust permissions based on the encryption key set, and obtain a list of authorization results;

[0204] The final state module is used to perform consistency verification and synchronization update based on the authorization result list and the encryption key set to obtain the final state table;

[0205] The encryption module is used to perform encryption processing according to the final status table to obtain the encrypted data packet;

[0206] The optimization module is used to perform path monitoring and dynamic optimization based on the encrypted data packet to obtain the optimized transmission path;

[0207] The transmission result module is used to perform integrity verification and retransmission based on the optimized transmission path to obtain the final transmission result.

[0208] It should be noted that the data transmission encryption device for monitoring equipment based on smart cities provided in this embodiment of the invention is used to execute all the process steps of the data transmission encryption method for monitoring equipment based on smart cities in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0209] This invention also provides an electronic device. The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, such as a data transmission encryption program for smart city-based monitoring devices. When the processor executes the computer program, it implements the steps in the various embodiments of the smart city-based monitoring device data transmission encryption method described above, for example... Figure 1 The step S11 shown. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the above-described device embodiments, such as the result transmission module.

[0210] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0211] The electronic device may be a desktop computer, laptop, handheld computer, or smart tablet, etc. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above components are merely examples of electronic devices and do not constitute a limitation on the electronic device. It may include more or fewer components than described above, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0212] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device, connecting all parts of the electronic device via various interfaces and lines.

[0213] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0214] Wherein, if the modules / units integrated in the electronic device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0215] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0216] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A data transmission encryption method for monitoring equipment in a smart city, characterized in that, include: Obtain the initial set of equipment categories; Based on the initial set of device classifications, security groups are performed to obtain a security group list; Based on the security packet list, communication requirements are collected and priority scheduling is performed to obtain a packet transmission scheduling scheme; Based on the packet transmission scheduling scheme, an encryption key is generated to obtain an encryption key set; Based on the set of encryption keys, dynamic authorization and permission adjustment are performed to obtain a list of authorization results; Based on the authorization result list and the encryption key set, a consistency check and synchronization update are performed to obtain the final status table; Based on the final state table, encryption processing is performed to obtain the encrypted data packet; Based on the encrypted data packet, path monitoring and dynamic optimization are performed to obtain the optimized transmission path; Based on the optimized transmission path, integrity verification and retransmission are performed to obtain the final transmission result.

2. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The step of performing security grouping based on the initial set of device classifications to obtain a security group list includes: Based on the initial set of device classifications, identity feature verification is performed to obtain a set of trusted devices; Based on the set of trusted devices, state monitoring and feature extraction are performed to obtain a set of communication state feature vectors; Based on the set of communication state feature vectors, group admission and permission configuration are performed to obtain a list of secure groups.

3. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The step of collecting communication requirements and prioritizing scheduling based on the security packet list to obtain a packet transmission scheduling scheme includes: Based on the security group list, communication load is collected to obtain a communication demand data table; Based on the communication requirements data table, traffic analysis and performance evaluation are performed to obtain a packet communication performance report; Based on the packet communication performance report, priority determination and scheduling configuration are performed to obtain a packet transmission scheduling scheme.

4. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The step of generating encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set includes: Get the key update template; Based on the hash algorithm, a hash key is generated for the packet transmission scheduling scheme to obtain an initial encryption key set; Based on the initial encryption key set, device change records are generated to obtain a device change dataset; Based on the device change dataset and the key update template, the key is updated and synchronized to obtain an encryption key set.

5. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The step of dynamically authorizing and adjusting permissions based on the encryption key set to obtain an authorization result list includes: Obtain the communication request data and key update timestamps of each group device in the encryption key set; Based on a hash algorithm, request features are extracted from the communication request data to obtain a request feature set; Based on the request feature set, permission determination and instruction generation are performed to obtain the permission control set; Based on the access control set and the key update timestamp, dynamic authorization and structure generation are performed to obtain an authorization result list.

6. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The process of performing consistency verification and synchronization updates based on the authorization result list and the encryption key set to obtain the final state table includes: Based on the hash algorithm, state features are extracted from the authorization result list and the encryption key set to obtain a state feature set; Based on the set of state features, a matching verification and instruction generation are performed to obtain an update instruction set; Based on the set of update instructions, synchronous adjustments and state generation are performed to obtain the final state table.

7. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The step of performing encryption processing based on the final state table to obtain the encrypted data packet includes: Based on the final state table, state extraction and symmetric encryption are performed to obtain a set of encrypted data packets; Based on the set of encrypted data packets, an integrity check is performed to obtain valid encrypted data packets; Based on the valid encrypted data packet, path planning and data transmission are performed to obtain the encrypted data packet.

8. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The step of performing path monitoring and dynamic optimization based on the encrypted data packet to obtain the optimized transmission path includes: Obtain the alternative path library; Based on the encrypted data packet, path monitoring and performance data collection are performed to obtain a path status report; Based on the path status report, a performance comparison and switching instruction generation are performed to obtain a set of path switching instructions. Based on the path switching instruction set and the backup path library, dynamic optimization is performed to obtain the optimized transmission path.

9. The data transmission encryption method for monitoring equipment based on smart cities according to claim 1, characterized in that, The process of performing integrity verification and retransmission based on the optimized transmission path to obtain the final transmission result includes: Based on the optimized transmission path, the reception status is collected to obtain the first reception report; Based on the first received report, an integrity check is performed to obtain a set of data packet identifiers; Based on the set of data packet identifiers, data packets are retransmitted and acknowledged to obtain the final transmission result.

10. A data transmission encryption system for monitoring equipment based on smart cities, characterized in that, include: The data acquisition module is used to obtain the initial set of device categories; The security grouping module is used to perform security grouping based on the initial set of device classifications to obtain a security group list; The transmission scheduling module is used to collect communication requirements and prioritize them according to the security packet list to obtain a packet transmission scheduling scheme. The encryption key module is used to generate encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set; The authorization result module is used to dynamically authorize and adjust permissions based on the encryption key set, and obtain a list of authorization results; The final state module is used to perform consistency verification and synchronization update based on the authorization result list and the encryption key set to obtain the final state table; The encryption module is used to perform encryption processing according to the final status table to obtain the encrypted data packet; The optimization module is used to perform path monitoring and dynamic optimization based on the encrypted data packet to obtain the optimized transmission path; The transmission result module is used to perform integrity verification and retransmission based on the optimized transmission path to obtain the final transmission result.

Images