Hardware acceleration encryption method and system based on chip data encryption

Abstract

The invention relates to the field of information security, and discloses a hardware acceleration encryption method and system based on chip data encryption, and the method comprises the steps: collecting system load and data flow, obtaining real-time task distribution, and if the number of tasks exceeds a task number threshold value, activating parallel and outputting task groups; for independent paths compatible with packet matching and hard acceleration, evaluating the safety of each path, if the safety is lower than a path safety threshold value, adjusting encryption parameters, carrying out load balancing distribution, and outputting safety strength configuration; according to the security intensity configuration, issuing a cooperation instruction to the multiple encryption units, ensuring that key tasks and timestamps are synchronously generated into a synchronous encryption sequence, monitoring real-time processing delay, and when the real-time processing delay exceeds a preset processing delay threshold value, redistributing a path and outputting an adjustment plan so as to schedule a low-efficiency area and integrate feedback to stabilize throughput; extracting vulnerabilities, performing encryption reinforcement to construct an overall framework, analyzing historical log verification cooperation efficiency and outputting a final hardware acceleration encryption scheme, and the real-time performance and security during data encryption can be improved.

Description

Technical Field

[0001] This invention relates to the field of information security, and in particular to a hardware-accelerated encryption method and system based on chip data encryption. Background Technology

[0002] With the widespread adoption of digital applications, data encryption has become a core means of data protection. However, under the requirements of large data volumes and real-time performance, how to improve encryption processing efficiency while ensuring sufficient security strength has become a key issue that needs to be addressed in the fields of information security and chip design.

[0003] Existing technologies mainly rely on software encryption algorithms or single hardware acceleration units. At the system end, tasks are distributed and hashed allocation is achieved through distributed message queues, task schedulers, etc. Data transmission usually follows a fixed path. Even if mechanisms such as consistent hashing are used for task mapping, traditional solutions still mainly rely on a single encryption unit or static channel, making it difficult to achieve real-time dynamic adaptation to multiple independent transmission paths and efficient parallel collaboration of multiple encryption units within the chip.

[0004] Traditional solutions are prone to problems such as single acceleration units becoming performance bottlenecks when dealing with high throughput and multi-task parallelism, congestion and delays caused by fixed transmission paths, difficulty in real-time mapping of data fragments and physical channels, and lack of dynamic scheduling and coordination mechanisms, which in turn affect the real-time performance and security of the system. In summary, existing technologies do not offer high real-time performance and security when encrypting data. Summary of the Invention

[0005] This invention provides a hardware-accelerated encryption method and system based on chip data encryption to solve the problems of lack of real-time performance and security in traditional technologies when dealing with high throughput and multi-task parallelism.

[0006] In a first aspect, to address the aforementioned technical problems, the present invention provides a hardware-accelerated encryption method based on chip data encryption, comprising: Collect the current system load and characteristics of incoming data stream, obtain real-time task distribution, and activate multi-task parallel mode when the number of tasks exceeds the preset task number threshold, and output task group set; Based on the task group set, perform transmission path matching on the data segments within the group and determine independent paths compatible with hardware acceleration, and output a path allocation scheme; According to the path allocation scheme, the path parameters are obtained and the security strength assessment of each path data stream is performed. If the security strength is lower than the preset security strength threshold, the encryption parameters are adjusted and the encryption unit load balancing is performed, and the security strength configuration is output. Based on the security strength configuration, collaborative work instructions are extracted and distributed to multiple encryption units. The operation sequence is determined by timestamp synchronization, and a synchronized encryption execution sequence is output. Based on the synchronous encrypted execution sequence, monitor the real-time processing delay and reallocate path resources when the preset processing delay threshold is exceeded, and output a resource adjustment plan; Based on the resource adjustment plan, adjustment parameters are extracted and dynamic scheduling is performed on inefficient areas. Transmission path feedback is integrated to obtain a stable system throughput index. Based on the system throughput metrics, vulnerability scanning data is extracted and potential risk points are encrypted and strengthened to obtain the overall encryption framework. Based on the overall encryption framework, historical processing logs are acquired and analyzed to verify collaborative work efficiency and identify areas for improvement, ultimately outputting the final hardware-accelerated encryption scheme.

[0007] Secondly, the present invention provides a hardware-accelerated encryption system based on chip data encryption, comprising: Task grouping module: used to collect the current system load and characteristics of incoming data streams, obtain real-time task distribution, activate multi-task parallel mode when the number of tasks exceeds the preset task number threshold, and output task group set; Path allocation module: used to match the transmission paths of data segments within the task group according to the task group set, determine independent paths compatible with hardware acceleration, and output a path allocation scheme; Security strength assessment module: used to obtain path parameters according to the path allocation scheme and perform security strength assessment on each path data stream. When the security strength is lower than the preset security strength threshold, the encryption parameters are adjusted and the encryption unit load is balanced. The security strength configuration is then output. Synchronous execution module: used to extract collaborative work instructions and distribute them to multiple encryption units according to the security strength configuration, use timestamp synchronization to determine the operation sequence, and output a synchronous encrypted execution sequence; Resource adjustment module: used to monitor real-time processing delay according to the synchronous encrypted execution sequence, and reallocate path resources when the delay exceeds a preset threshold, and output a resource adjustment plan; Path optimization module: used to extract adjustment parameters according to the resource adjustment plan, perform dynamic scheduling for inefficient areas, integrate transmission path feedback, and obtain stable system throughput indicators; Encryption Enhancement Module: Used to extract vulnerability scanning data based on the system throughput indicators and enhance the encryption of potential risk points to obtain the overall encryption framework; Log analysis module: Based on the overall encryption framework, it acquires and analyzes historical processing logs, verifies collaborative work efficiency, identifies areas for improvement, and outputs the final hardware-accelerated encryption scheme.

[0008] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention dynamically collects system load and data flow characteristics, activates multi-task parallel mode based on task volume threshold, and generates optimized groups by combining consistent hashing algorithm, forming a closed-loop dynamic scheduling mechanism from load perception to task grouping, which significantly improves task allocation efficiency and resource utilization in high-concurrency scenarios. (2) The present invention adopts dynamic allocation and hardware acceleration compatible path matching, combined with security strength assessment and encryption parameter adjustment, and realizes multi-encryption unit collaboration through timestamp synchronization protocol to generate synchronous encryption execution sequence. It can accurately optimize transmission path and encryption load balancing, prioritize low-latency processing of critical tasks, and enhance encryption performance and security flexibility. (3) Based on performance bottleneck detection, monitoring and processing latency, this invention dynamically reallocates path resources and integrates feedback to optimize scheduling. It combines vulnerability scanning and encryption enhancement to build an overall framework. Through historical log verification of collaborative efficiency, it forms a closed-loop optimization of "detection-adjustment-enhancement-verification", effectively shortening response latency, improving system throughput and enhancing anti-disturbance capability in high-concurrency environments. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of a hardware-accelerated encryption method based on chip data encryption provided in the first embodiment of the present invention; Figure 2 This is a schematic diagram of a hardware-accelerated encryption system structure based on chip data encryption provided in the second embodiment of the present invention. Detailed Implementation

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

[0011] Reference Figure 1 The first embodiment of the present invention provides a hardware-accelerated encryption method based on chip data encryption, comprising the following steps: S101: Collect the current system load and characteristics of incoming data stream, obtain real-time task distribution, and activate multi-task parallel mode when the number of tasks exceeds the preset task number threshold, and output task group set; S102, based on the task group set, perform transmission path matching on the data segments within the group and determine an independent path compatible with hardware acceleration, and output a path allocation scheme; S103: According to the path allocation scheme, obtain the path parameters and perform security strength assessment on each path data stream. If the security strength is lower than the preset security strength threshold, adjust the encryption parameters and perform load balancing of the encryption units, and output the security strength configuration. S104, based on the security strength configuration, extract the collaborative work instructions and distribute them to multiple encryption units, use timestamp synchronization to determine the operation sequence, and output the synchronous encryption execution sequence; S105, based on the synchronous encrypted execution sequence, monitor the real-time processing delay and reallocate path resources when the preset processing delay threshold is exceeded, and output a resource adjustment plan; S106, Based on the resource adjustment plan, extract adjustment parameters and perform dynamic scheduling on inefficient areas, integrate transmission path feedback, and obtain a stable system throughput index. S107. Based on the system throughput index, extract vulnerability scanning data and strengthen the encryption of potential risk points to obtain the overall encryption framework. S108. Based on the overall encryption framework, acquire and analyze historical processing logs, verify collaborative work efficiency and determine improvement points, and output the final hardware-accelerated encryption scheme.

[0012] In step S101, the current system load and incoming data stream characteristics are collected, the real-time task distribution is obtained, and a multi-task parallel mode is activated when the number of tasks exceeds a preset task number threshold. The task group set is then output, including: S1011 uses a distributed message queue to collect the system load and incoming data stream characteristics of each node in real time and count the number of real-time tasks. S1012, when the number of real-time tasks exceeds the preset task number threshold, the task scheduler triggers a multi-task parallel mode and maps and allocates tasks to different nodes or parallel queues according to task type and resource requirements, thereby generating a preliminary task group set.

[0013] In one implementation, in high-concurrency scenarios, the local node's metrics are read and messages are pushed to a specified topic partition in Kafka via TLS. Consumer groups consume in parallel and roll the window according to event time (window length 1s, sliding step 0.5s, out-of-order data processing mechanism, watermark is the window length plus the maximum allowed late time 200ms) to accurately deduplicate the unique ID of the request (based on Redis Set to store the ID within the window, and the state is cleaned up after a 200ms delay after the window ends). The count of distinct(request_id) within the window is summarized as the real-time task count. The timestamp is based on the production end's ISO8601 millisecond-level event_time, and the node time deviation is ensured to be ≤50ms through NTP calibration.

[0014] In one implementation, in high-concurrency scenarios, when the number of valid real-time tasks counted by the monitoring module exceeds a preset threshold of 8000 per window (i.e., task rate ≥ 8000 per 1 second) within two consecutive adjacent scrolling windows (each window is 1 second, with a step size of 0.5 seconds), distributed task scheduling is triggered to avoid false triggering caused by single-window fluctuations. The task scheduler receives the trigger event and reads the task type field (such as "query") and resource requirement tags (CPU usage %, I / O intensity, latency sensitivity) from each task message. It queries the cluster capability registry to obtain the performance profile of each node (number of available CPU cores, remaining memory, network bandwidth, and whether high I / O paths are supported). According to predefined mapping rules, combined with a consistent hashing algorithm (number of virtual nodes on the ring = 100, node weight is calculated according to the ratio of available CPU cores to memory), each task ID is hashed to generate a preliminary task group set.

[0015] It should be noted that the formula for calculating node weights is as follows: in, This represents the number of CPU cores currently available on the node. The number of CPU cores on the largest node in the cluster (obtained from the cluster registry). The node's current available memory (GB). This represents the memory capacity (GB) of the largest node in the cluster. =0.6, =0.4 represents the corresponding weighting coefficients (which can be adjusted according to business needs). + =1); the resource indicators of each node can be collected in real time through the cluster monitoring system, and the maximum value can be calculated as the denominator.

[0016] It should be noted that the mapping rules are as follows: high I / O tasks (I / O intensity tag = "high", defined as a single task I / O operation of no less than 10 times or a data transfer volume of no less than 1MB) are preferentially mapped to servers marked as "high I / O nodes" (the node performance profile shows a disk IOPS of no less than 100,000 and a network bandwidth of no less than 20Gbps); latency-sensitive tasks (latency sensitivity tag = "high", defined as the maximum allowed response time not exceeding 50ms) are mapped to nearby low-latency nodes (network latency of nodes in the same data center does not exceed 1ms, and nodes in different data centers are not included in the candidates).

[0017] In step S102, based on the task group set, transmission path matching is performed on the data segments within the group, and independent paths compatible with hardware acceleration are determined. A path allocation scheme is then output, including: S1021, Based on the task group set, query the bandwidth requirements and latency constraints of data segments within each group in the distributed database; S1022, Based on the bandwidth requirements and latency constraints, filter the candidate set of adaptation paths according to the preset hardware acceleration compatibility rules. S1023, Based on the set of candidate adaptation paths, the data fragments are then mapped to node transmission paths with corresponding hardware acceleration capabilities and load balancing. S1024, if the mapping causes the communication overhead between nodes to exceed a preset communication overhead threshold, then the nodes are reassigned to low-overhead paths through a dynamic routing table, thereby outputting a path allocation scheme.

[0018] In one implementation, in high-concurrency scenarios, the system calls the distributed database client in parallel for each group in the initial task group set, obtains the fields of each data fragment in JSON format, and all timestamps are ISO-8601 milliseconds and calibrated with the system master clock via NTP / PTP (maximum tolerance deviation not exceeding 50ms). With a sampling window of 60s and a sampling period of 200ms, the system statistically calculates the bandwidth requirements and response latency constraints.

[0019] It should be noted that the bandwidth requirement formula is as follows: in, Bandwidth requirement (in MB / s) / Requests per second This represents the average size of a single request (in bytes, ranging from 512B to 4KB, with a typical value of 2KB, derived from single request data over the past 3 months).

[0020] It should be noted that the response latency constraints are defined as server-side processing latency (the time interval from receiving a request to returning a response; since high latency for a few requests can significantly impact user experience and business success rate, the 99th percentile is used to reflect the experience of "almost all" users and reveals tail problems better than the mean); order query tasks should not exceed 50ms (based on historical data from the past 3 months, where 99% of order query task request response times were less than 50ms), and inventory update tasks should not exceed 30ms (based on historical data from the past 3 months, where 99% of inventory update task request response times were less than 30ms). Latency data is collected through a node local timer (1ms accuracy) and calibrated using NTP.

[0021] In one implementation, in high-concurrency scenarios, the scheduler receives the normalized bandwidth requirements (unit: MB / s), latency constraints (unit: ms), and I / O types for each data segment from the distributed database. Then, it filters out the initial matching acceleration type according to the preset hardware acceleration compatibility rules and the segment access mode (read / write / mixed).

[0022] It should be noted that the preset hardware acceleration compatibility rules include: for GPU acceleration, the compatibility rule is a bandwidth requirement greater than 1000MB / s (1GB / s) and a latency requirement less than 100ms (99th percentile), suitable for high-volume query tasks; for dedicated NIC acceleration, the compatibility rule is a latency requirement less than 50ms and a single request write size not exceeding 128KB (defined as "small write"), suitable for high-frequency small data tasks such as inventory updates; for FPGA acceleration, the compatibility rule is a bandwidth requirement greater than 5000MB / s and a latency requirement not less than 200ms (defined as "tolerable latency"), suitable for high-throughput non-real-time tasks such as log synchronization.

[0023] In one implementation, in high-concurrency scenarios, after the scheduler receives the set of candidate adaptation paths, it performs min-max normalization on the bandwidth requirement (MB / s) and latency constraint (ms), and concurrently queries the cluster capability registry to filter and retain only candidate nodes that simultaneously meet the following conditions: acceleration type support (GPU / NIC / FPGA), current CPU utilization of the node is less than 75%, available memory is greater than 2GB, and remaining network bandwidth is not less than the segment bandwidth requirement. Subsequently, the expected end-to-end transmission delay is estimated based on the network topology, and a matching score is calculated for each candidate path based on the normalized weighted average of bandwidth requirement and latency constraint. A maximum of N=10 candidate paths are retained for each segment. Then, a consistent hashing algorithm (virtual node number = 100, node weight is calculated according to the ratio of available CPU cores to available memory) is used to map the data segment to the node transmission path, and ensures that the total bandwidth allocated to a single node does not exceed 80% of its advertising bandwidth to reserve head space.

[0024] In one implementation, in high-concurrency scenarios, for the initial path allocation scheme (such as the transmission path from node 1 to node 3), the scheduler first collects inter-node communication overhead data in real time through network monitoring (specifically including cross-node transmission delay, bandwidth cost, and data transmission volume). The preset communication overhead threshold is that the cross-node delay is greater than 200ms. When the current transmission delay from node 1 to node 3 is detected to be 250ms (exceeding the delay threshold), the scheduler calls the dynamic routing table interface to query all candidate low-overhead paths that support the same hardware acceleration type (such as GPU acceleration) and meet the requirements of CPU utilization being less than 75% and available memory being greater than 2GB. The Dijkstra algorithm is used to calculate the comprehensive overhead of the candidate paths and select the three paths with the lowest comprehensive overhead. The data fragment originally mapped to node 3 is remapped to node 4 using a consistent hashing algorithm (virtual node number = 100), and the path status table is updated at the same time, finally generating the path allocation scheme.

[0025] It should be noted that the comprehensive cost is calculated using a standardized weighted sum, and the specific steps are as follows: the normalized delay is... The normalized cost factor is obtained by dividing the path delay (ms) by the delay threshold (200ms) (normalized range [0,1]); The total cost is calculated by dividing the number of path hops by the maximum allowed number of hops. (Range [0,1], smaller values ​​have lower overhead).

[0026] In step S103, according to the path allocation scheme, path parameters are obtained and security strength assessment is performed on each path data stream. If the security strength is lower than a preset security strength threshold, encryption parameters are adjusted and encryption unit load balancing is performed. The security strength configuration is then output, including: S1031, According to the path allocation scheme, extract the bandwidth usage and delay parameters of each path, evaluate the security strength of each path, and filter out the data stream set that is lower than the preset security strength threshold. S1032, adjust the encryption parameters according to the data stream set to form an updated encryption parameter set; the encryption parameters include key length and encryption mode; S1033, the set of encryption parameters is mapped and allocated to the encryption unit and the unit load balancing is adjusted. Finally, the corresponding encryption unit configuration is applied and the path selection is updated through the dynamic routing table, and the security strength configuration set is output.

[0027] In one implementation, in high-concurrency scenarios, the scheduler reads each path sequentially from the path allocation scheme. The system retrieves the corresponding data stream identifiers and accesses the path performance log table via a distributed database client. It then extracts the bandwidth usage (unit: MB / s, e.g., 800MB / s for order query data streams, typical range 100-1500MB / s, dynamically adapted based on network card model), latency data (unit: ms, e.g., 55ms for inventory deduction data streams), and encryption configuration information (including encryption mode and key length in bits). Using preset security strength evaluation rules, the system compares the security strength value of each data stream with a preset security strength threshold (a security strength value of "low" is considered below the threshold). This filters out order query data streams with "AES-CBC" encryption mode and a key length of 64 bits, as well as unencrypted user behavior log data streams, forming a set of data streams below the preset security strength threshold.

[0028] It should be noted that the preset security strength evaluation rules are as follows: AEAD mode can provide both confidentiality and integrity. For example, AES-GCM has a built-in GMAC to prevent tampering, while AES-CBC requires an additional HMAC and is prone to vulnerabilities due to improper implementation such as IV duplication. A quantitative scoring mechanism is adopted, which comprehensively considers encryption mode (AEAD gets 40 points / non-AEAD gets 0-20 points), key length (128 bits gets 20 points / 256 bits gets 30 points), integrity verification (built-in authentication gets 20 points), and security implementation (hardware acceleration gets 10 points). A total score of not less than 80 points is "high", 60 to 79 points is "medium", and less than 60 points is "low". Dynamic weights are used to adapt to high-concurrency scenarios to ensure a balance between security and performance.

[0029] In one implementation, in high-concurrency scenarios, for a set of low-security data streams that have been filtered out, the system adjusts the encryption parameters and forms an updated set of encryption parameters in a single transactional operation according to the following explicit steps: concurrently reading the current encryption attributes and target path delay constraints of each stream; if any fields are missing, a conservative default is used (encryption mode is AES-GCM, key length is 128); subsequently, the system concurrently queries the encryption unit registry to filter candidate units that meet the following requirements: supporting the required encryption mode and key length, current CPU utilization is below 75%, queue length is less than 1000, available memory is greater than 1GB, and advertising throughput is not less than the stream bandwidth requirement; based on preset adjustment rules, an example mapping logic is explicitly given (example rule 1. In high-security scenarios, if the data stream bandwidth is not less than 800MB / s (close to the network card bandwidth limit), then the key length is adjusted). When upgrading from <128bit to ≥256bit, the mode is switched to AES-GCM (hardware acceleration priority) or ChaCha20 (CPU friendly); if latency is sensitive and the target unit's CPU is limited, the low-latency friendly and hardware-accelerated AES-GCM / 128 or ChaCha20 / 256 is selected; if the node does not support the required mode, it is downgraded to the highest strength supported by the node and the reason for downgrading is recorded. Adjustment instructions are generated for each flow and the adjustment tasks are assigned to candidate encryption units using consistent hashing (virtual nodes=100) to minimize remapping overhead. At the same time, the execution overhead and expected new latency are simulated and estimated. If the estimation causes any path latency to exceed the path latency threshold or the node bandwidth utilization is greater than 80%, the suboptimal solution is tried according to priority or a batch migration is triggered (migration batch limit=100) until the constraints are met.

[0030] It should be noted that the formula used to estimate the new delay is as follows: in, The fixed processing latency of the hardware encryption unit (e.g., AES-GCM 256bit≈2ms, ChaCha20≈3ms, based on actual measured values ​​from the chip datasheet). This represents the total amount of data to be processed (in MB). For a single request, this is the amount of data requested; for batch processing, this is the sum of the amounts of data from all requests within the batch. Data processing throughput of the encryption unit (in MB / s).

[0031] In one implementation, in high-concurrency scenarios, the system reads the parameter items to be allocated one by one from the updated set of encryption parameters. First, it concurrently queries the encryption unit registry to filter candidate units that simultaneously support the required encryption mode and key length, have a current queue length less than the maximum queue (default 1000), CPU utilization less than 80%, available memory greater than 1GB, and advertising throughput not less than the task bandwidth requirement. Then, it uses consistent hashing (virtual node number = 100) to map tasks to candidate units to reduce remapping overhead and generate a preliminary mapping table. If the CPU utilization of any unit after mapping differs from the average CPU utilization of the cluster by more than 10% (absolute difference), or the queue length exceeds 1.5 times the average queue length of the cluster, then a weighted round-robin with weighted adjustments triggers batch migration (50 tasks per batch, with a total batch limit of 100), until the load difference of all units is ≤10%. The path selection is updated through a dynamic routing table to generate the final output security strength configuration set.

[0032] It should be noted that the path selection through the routing table is as follows: an incremental update mechanism is used, only the changed path entries (such as changes in the IP of the encryption unit node) are pushed, and the update frequency is consistent with the encryption parameter adjustment cycle (default 10s / time); during the update process, dual write buffering is enabled (data is forwarded simultaneously on the old and new paths for 500ms), and the old path is cut off after the new path is confirmed to be stable to avoid traffic interruption.

[0033] In step S104, based on the security strength configuration, collaborative work instructions are extracted and distributed to multiple encryption units. The operation sequence is determined using timestamp synchronization, and a synchronized encryption execution sequence is output, including: S1041, Based on the security strength configuration, extract the collaborative work instructions and decompose them into a set of tasks containing task descriptions and priorities; S1042, Distribute tasks containing task descriptions and priorities to multiple encryption units and monitor queues and loads in real time to ensure balance. Extract task data from each unit, calibrate and sort by timestamp to determine the order of operations. S1043, based on the determined order of operations, issue execution commands and combine dynamic scheduling to adjust the encryption mode and key length of each unit to obtain a synchronized encryption execution sequence.

[0034] In one implementation, in high-concurrency scenarios, the system reads JSON records from the security strength configuration via the TLS interface (with a 500ms timeout, exponential backoff retries up to 3 times, and an alarm recorded and conservative default handling if a field is missing). It then parses and extracts instruction elements line by line using a parsing algorithm based on a finite state machine and regular expressions. Following explicit semantic mapping rules, the elements are converted into task descriptions and priorities. Simultaneously, the system parses and explicitly writes the task dependency field (dependencies). If a circular dependency is detected (e.g., t1 depends on t2 and t2 depends on t1), it is marked as an anomaly, and the priority is forcibly set to low (priority=3). An alarm log is also recorded. Standardized metadata items are generated for each task. Parsing anomalies or incomplete instructions are handled using a conservative strategy (e.g., setting the priority indicator to 9 and marking it as requiring manual review). Finally, a task set (JSON array) containing task descriptions and priorities is obtained.

[0035] It should be noted that the specific steps of the mapping rule are as follows: priority determination order (from high to low), explicit priority field (≥8→high, 5-7→medium, ≤4→low); keyword ('priority payment'→high, 'inventory'→medium); delay-sensitive label→medium priority; conflict handling, explicit priority field takes precedence over keyword, such as if it contains 'priority payment' and priority=6→it is determined as medium priority based on priority=6; priority level corresponds to value, high (8-10), medium (5-7), low (1-4), default priority=5 (medium priority).

[0036] In one implementation, in high-concurrency scenarios, tasks containing task descriptions and priorities are distributed to multiple cryptographic units, using consistent hashing (number of virtual nodes). =100× The hash key (MD5 hash of taskid, distributed in a scatter pattern) is initially mapped to candidate encryption units, ensuring that high-performance nodes are allocated more virtual nodes (e.g., a node with a weight of 2 corresponds to 200 virtual nodes). After mapping, the allocation is written to the scheduling table via TLS channel with a single delivery timeout of 500ms and an exponential backoff retries of up to 3 times. The real-time queue length, CPU%, memory, and throughput of each unit are concurrently queried at a 200ms sampling interval to determine load balancing. If the CPU utilization of any unit is ≥85% for 3 consecutive sampling periods (200ms sampling interval), rebalancing is triggered. Subsequently, task data records are extracted from each encryption unit and synchronized using a timestamp protocol (NTP / PTP reference clock, measuring and recording the clock offset offset_ms for each unit, with a maximum sample tolerance deviation of 50ms; exceeding this deviation will pause automatic scheduling and issue a manual review alarm). Perform calibration ( Finally press Sort in ascending order to determine the order of operations; if If they are the same, then... Descending order, then press The lexicographical order is used as the final decision, and the final sorting result, clock offset, migration list, and signature are written into the audit log (JSON format) for compliance verification.

[0037] It should be noted that the rebalancing steps are as follows: the migration strategy prioritizes stateful migration (synchronizing the encrypted context through shared memory or distributed cache, with a migration timeout threshold of 1 second; failure results in downgrading to stateless migration and recording an alarm); the target unit selection weighted round-robin weight = (1 - OBJ_CPU_USE% / 100) × Where OBJ_CPU_USE% is the CPU utilization of the target unit. Weighted round-robin polling prioritizes nodes with higher weights for receiving migration tasks; the number of migration tasks per batch = min(100, Overloaded_Tasks × 20%), where Overloaded_Tasks is the number of overloaded tasks in the source unit to avoid network congestion caused by batch migration.

[0038] In one implementation, in high-concurrency scenarios, the scheduler reads already scheduled data in a transactional manner. Ascending order (if the same, sort by priority in descending order, then sort by...) A task list with lexicographically determined operational order is established, and execution commands are issued according to the following explicit steps to obtain a synchronized encrypted execution sequence. This sequence is transmitted via a TLS channel (single execution timeout = 500ms, exponential backoff retries up to 3 times). (Example values: AES-GCM, AES-CBC, ChaCha20), new_key_len_bit (example values: 128, 256), apply_ts (effective time window), nonce / IV policy, config_id, and checksum are written to the target encryption unit and written to the scheduling metadata table in a transaction. Before distribution, the dynamic scheduling module concurrently obtains the target unit's real-time metrics (queue length, CPU%, available memory, unit throughput_MB_s) at a sampling period of 200ms, and verifies resource availability (default maximum queue max=1000; if the queue length is greater than max or the CPU utilization is greater than 85%, or the expected increase in latency causes path_latency to exceed the latency_constraint_ms threshold, then try suboptimal configuration or trigger stateful migration, with a migration batch limit of 100; if the unit does not support the required mode, it is downgraded to the highest strength supported by the unit and the reason for the downgrade is recorded). When generating the final distribution command, latency estimation and security scoring are performed simultaneously, and the unit clock offset is measured and recorded using NTP / PTP before each distribution. (Maximum tolerance deviation = 50ms; if exceeded, automatic delivery will be paused and an alarm will be triggered requiring manual review); The system updates and solidifies the synchronized encrypted execution sequence in real time based on reports from each unit, and reschedules according to the above rules to maintain the stability of the sequence when a delay or abnormal load is detected, thus obtaining a synchronized encrypted execution sequence.

[0039] It should be noted that the formula used for delay estimation is the same as that in step S1032.

[0040] In step S105, based on the synchronous encryption execution sequence, real-time processing latency is monitored, and when it exceeds a preset processing latency threshold, path resources are reallocated, and a resource adjustment plan is output, including: S1051, Based on the synchronized encrypted execution sequence, monitor the real-time processing delay. If the delay exceeds a preset processing delay threshold, scan to obtain the initial identifier set of congested paths and mark the path status data. S1052, Based on the marked path status data, map resource nodes to determine the traffic load of congested points. When the load is unbalanced, adjust the status data to obtain a set of intermediate resource adjustment plans. S1053, adjust the intermediate plan set according to the resources, calibrate the congestion point time sequence record, and dynamically schedule and calculate the traffic balance index deviation value. If it exceeds the preset balance index deviation threshold, optimize the intermediate plan set and determine the integrated resource configuration scheme. S1054, Based on the integrated resource configuration scheme, extract the mitigation parameter list, verify the stability of the execution sequence, and output the optimized resource adjustment plan.

[0041] In one implementation, in high-concurrency scenarios, the system monitors the processing latency of each encryption unit with a sampling period of 200ms based on the synchronized encryption execution sequence. The preset processing latency threshold is set to 50ms (or 30ms for high-priority payment tasks). When the real-time latency of a certain path exceeds the threshold for three consecutive sampling periods (200ms / period, totaling 600ms), the path resource scanning program is activated. It traverses all associated physical links in the network topology, filters links whose latency is greater than the threshold and whose duration is not less than 5s (starting from the first time the threshold is exceeded, and accumulating the duration if the threshold is exceeded for consecutive sampling periods), obtains the initial set of congested path identifiers, and marks the path status data.

[0042] The rules for marking path status data are as follows: First, the deviation ratio and duration of latency from the threshold are determined by statistical analysis of historical data from the past 3 months to mark the congestion level. The 'severe' congestion level is defined as a latency greater than the threshold by 50% and lasting for no less than 10 seconds; the 'moderate' congestion level is defined as a latency greater than the threshold by 20%-50% and lasting for 5-10 seconds. Then, the scope of impact is determined according to industry standards. The 'core link' is a path containing payment-related tasks; the 'ordinary link' is other paths including the recording of related indicators (current bandwidth utilization rate, queue length).

[0043] In one implementation, in high-concurrency scenarios, based on the marked path status data, a consistent hashing algorithm (virtual node count = 100, hash key is path ID) is used to map to the corresponding resource node set. By concurrently querying the real-time traffic load (specific indicators, current processing flow count, CPU utilization %, memory usage GB, data packet throughput PPS) of each node at a sampling period of 200ms, the load deviation value is calculated. If the load deviation value exceeds a preset threshold of 20%, the load is determined to be unbalanced. At this time, an intermediate instruction set for adjusting the status data is generated through a dynamic scheduling algorithm. After integrating the intermediate instruction set with the transmission path metadata, a resource adjustment intermediate plan set is obtained, which includes migration flow ID, source node, target node, estimated migration time in ms, and expected load balancing deviation value (e.g., the adjusted deviation value ≤ 15%).

[0044] It should be noted that the load deviation value is calculated using a weighted average of multiple indicators. in, For the deviation in flow quantity, CPU utilization deviation For PPS throughput deviation, the deviation of each indicator is calculated by dividing the difference between the maximum and minimum values ​​by the average value and then multiplying by 100%. The weights of each indicator are determined by calculating the correlation between each indicator and key SLAs (such as response latency and error rate) based on historical monitoring data and combined with business priorities. The deviation of the current processing flow is set to have the highest weight to ensure the balance of core business flows. When calculating CPU utilization deviation, the CPU utilization of the max load node must be ≤85% (to avoid including overloaded nodes in the avg calculation).

[0045] It should be noted that the migration batch strategy is as follows: the maximum number of migration batches per batch is min(100, Total_Migrated_Streams×30%), ensuring that the migration volume of a single batch does not exceed 5% of the total number of streams in the cluster; the batch interval is 500ms (waiting for the previous batch of tasks to run stably on the target node); if the total number of streams to be migrated is greater than 300, multi-threaded concurrent migration is enabled (number of threads = min(5, total batches)).

[0046] In one implementation, in high-concurrency scenarios, the intermediate plan set is adjusted based on resources including the identifier of the flow to be migrated, the target node, and the estimated migration time in milliseconds (e.g., planning to migrate 200 flows from node A to node B). The time sequence records of each congested point are calibrated using the NTP / PTP timestamp synchronization protocol (maximum tolerable clock offset = 50ms, exceeding which will pause scheduling and trigger an alarm). A dynamic scheduling algorithm (weighted round-robin combined with stateful migration, migration batch limit = 100) is used to calculate the traffic balance index deviation value with a sampling period of 200ms. When the combined deviation value of the primary nodes (A and B) is greater than 30% or the single migration batch is not less than 150 flows, the backup node C is activated (it must meet the following requirements: support AES-GCM / 256bit encryption mode, CPU utilization less than 70%, and remaining bandwidth not less than the bandwidth required by the migration flow). The migration traffic is allocated according to the load ratio of the primary nodes to optimize the intermediate plan set, and finally the integrated resource configuration scheme is determined.

[0047] It should be noted that the formula for determining the comprehensive deviation value of the traffic balance is as shown in step S1502; if the comprehensive deviation value > 15%, then an imbalance is determined; the weight parameters are determined based on the degree of influence of each indicator on traffic balance, among which the number of flows directly reflects the uniformity of task allocation, so it is given the highest weight of 0.4; CPU utilization and PPS throughput are used as auxiliary indicators, and are given weights of 0.3 and 0.3 respectively, to comprehensively evaluate the node load status. The condition for determining imbalance is determined by combining the correlation between the comprehensive deviation value and the actual imbalance performance of the system over the past 3 months.

[0048] In one implementation, in high-concurrency scenarios, a mitigation parameter list is extracted based on the determined integrated resource configuration scheme. The logic judgment module verifies the stability of the execution sequence and outputs an optimized resource adjustment plan according to the following explicit steps: Each mitigation parameter is mapped to the affected area using consistent hashing (virtual node = 100, hash key = path_id or node_id), and the parameter matching degree is calculated (threshold = 80%, if lower, it is marked as needing supplementation); real-time indicators of each node are sampled concurrently, and the clock is calibrated using NTP (maximum tolerable offset = 50ms, exceeding which pauses the process and requires manual review); based on latency and throughput estimation formulas, each mitigation parameter is... The simulation is performed to verify whether the system throughput fluctuation within the simulation window is within the preset stable range (e.g., ±5% or 950-1050 tps) and whether the critical path delay meets the path delay threshold (e.g., no more than 45ms for payment tasks and no more than 50ms for general tasks, determined by industry standards). If a conflict is detected (e.g., bandwidth allocation contradicts node_priority) or the balance deviation after simulation exceeds the preset balance deviation threshold (preset ≤12%), the intermediate plan is iteratively adjusted according to the optimization rules, and the simulation is repeated until the matching degree, throughput stability and delay constraints are met, and finally the optimized resource adjustment plan that has passed the verification is obtained.

[0049] It should be noted that the content of the intermediate plan iteratively adjusted according to the optimization rules is as follows: the bandwidth adjustment optimization rule is based on the current available bandwidth of the backup node C (retaining 20% ​​redundancy), increasing by 5-10 Mbps each time (maximum adjustment to 80% of the node's physical bandwidth limit); the migration batch optimization rule is an initial batch of 100, increasing by 50 with each iteration (maximum 200); the migration priority optimization rule is that payment tasks have high migration priority (prioritized migration), and general tasks have medium priority; the iteration termination condition optimization rule is that the deviation value of two consecutive simulations does not exceed 12%, or the number of iterations is not less than 5. The preset stability range and preset equilibrium deviation are derived from statistical analysis of data from the stable operation of the system over the past 3 months.

[0050] In step S106, according to the resource adjustment plan, adjustment parameters are extracted and dynamic scheduling is performed on inefficient areas. Transmission path feedback is integrated to obtain a stable system throughput indicator, including: S1061, According to the resource adjustment plan, extract the adjustment parameter list, map the inefficient areas to determine the parameter matching degree, and if the matching degree is lower than the preset threshold, generate a set of area identifiers to obtain the marked area status data; S1062, Calculate the load deviation value based on the marked area status data, and obtain the intermediate instruction set for scheduling update; S1063, integrate the transmission path according to the intermediate instruction set to obtain the integrated path feedback record; S1064, Based on the integrated path feedback record, the timing record is calibrated to determine the feedback consistency. If the consistency deviation is higher than the preset consistency deviation threshold, the path record is optimized to determine the initial configuration scheme for path optimization. S1065, Based on the initial configuration scheme of the path optimization, extract the list of balanced indicators, verify the throughput stability, and obtain stable system throughput indicators.

[0051] In one implementation, in a high-concurrency scenario, an adjustment parameter list is extracted according to the resource adjustment plan. A consistent hashing algorithm (virtual node count = 100, hash key = path_id or node_id) is used to map each adjustment parameter to an inefficient region in the system. By calculating the matching degree between the actual parameter value and the region's demand value, if it is detected that the bandwidth parameter of node C only supports 10Mbps (demand is 20Mbps) and the migration batch limit is only 50 (demand is 100), and the matching degree is <80%, then a region identifier set is generated (containing the fields of region ID = Z003, associated node ID = C, inefficiency type "insufficient resources", and matching degree of 0%), and the region is marked to obtain the marked region status data.

[0052] It should be noted that the criteria for determining an inefficient region are that at least two of the following conditions must be met simultaneously: processing flow count less than 300 streams / node, CPU utilization less than 50%, PPS throughput less than 500 packets / second, and bandwidth support value less than 80% of the required value. Each adjustment parameter (including bandwidth and migration batch limit) is mapped to a system region. If a region simultaneously meets the conditions of 'bandwidth support value < 80% of the required value' and 'migration batch limit < 50% of the required value', it is determined to be an inefficient region. The above data are obtained by collecting historical monitoring data of the system under normal and high-concurrency scenarios, calculating the distribution and key quantiles of each indicator, using correlation analysis to screen candidate thresholds, and combining industry benchmarks / experience values ​​with simulation backtesting and operational verification. These values ​​are then determined and periodically reviewed.

[0053] In one implementation, in high-concurrency scenarios, based on the region status data marked with region ID (e.g., Z003) and associated node ID (e.g., node C), a weighted round-robin scheduling strategy is adopted (the weight factor is 100 times the reciprocal of the node CPU utilization) to calculate the load deviation value (the load deviation value is the difference between the maximum number of current processing flows of the load node and the minimum number of current processing flows of the load node, divided by the average number of current processing flows of the load node, and finally multiplied by 100%). Here, the load nodes are the set of nodes associated with region Z003, and the current number of processing flows is obtained in real time through a 200ms sampling period. If the load deviation value exceeds a preset threshold of 20%, the intermediate instruction set for scheduling update is obtained.

[0054] In one implementation, in high-concurrency scenarios, a dynamic routing algorithm is used to integrate transmission paths based on the intermediate instruction set. The transmission paths include the main path (node ​​A → node B, bandwidth 200Mbps), the backup path (node ​​A → node C, bandwidth 150Mbps), and associated path metadata. Real-time metrics of each path are queried concurrently at a sampling period of 200ms, and the clock is calibrated using the NTP protocol (maximum tolerable offset = 50ms, if it exceeds this, integration is paused and an alarm is triggered) to ensure timing consistency. Finally, the integrated path feedback record is obtained.

[0055] In one implementation, in high-concurrency scenarios, based on the integrated path feedback records, the event_ts field in each path feedback record is calibrated using the NTP / PTP timestamp synchronization protocol to obtain... The system calculates the consistency deviation value to determine the consistency of the feedback. If the consistency deviation value is higher than the preset consistency deviation threshold (10ms), the system uses a dynamic routing algorithm (weighted path selection based on bandwidth utilization) to optimize the path records and determine the initial configuration scheme for path optimization.

[0056] It should be noted that the formula for calculating the consistency deviation value is as follows: in, This is a set of timestamps (in seconds, milliseconds, etc.) of feedback records from different paths for the same event or the same sampling period, after NTP / PTP calibration. The maximum value among the timestamps after calibration for all paths; The minimum timestamp among all calibrated paths. The consistency deviation threshold was determined using data from high-concurrency scenarios over the past three months. In these high-concurrency scenarios, timestamp deviations at each node were mostly concentrated in the 8-12ms range; therefore, the threshold was set to 10ms to cover most normal fluctuations. If the deviation exceeds the preset consistency deviation threshold (e.g., 10ms), the feedback is considered to be inconsistent in timing, and the path recording needs to be optimized.

[0057] In one implementation, in high-concurrency scenarios, based on the initial configuration scheme of path optimization (such as increasing throughput to 1000 streams per second and reducing latency to 40 milliseconds), a list of balanced indicators including throughput target value, latency threshold, and bandwidth allocation value is extracted. The logic judgment module monitors and verifies whether the system throughput remains within a stable range of 950 to 1050 streams per second (fluctuation ≤ ±5%) after the bandwidth is increased by 20Mbps, and whether the payment verification response time remains within 45 milliseconds, thereby obtaining stable system throughput indicators.

[0058] In step S107, based on the system throughput metric, vulnerability scanning data is extracted and potential risk points are encrypted and strengthened to obtain the overall encryption framework, including: S1071, based on stable system throughput indicators, extract and mark the set of abnormal events and risk points; S1072, calculate the risk weighting value based on the marked risk point set; if the risk weighting value is higher than the preset risk level threshold, generate an encryption enhancement instruction to obtain the encrypted and enhanced data record. S1073, Based on the encrypted and enhanced data records, extract the affected paths. If the risk of the affected path is higher than a preset risk level threshold, generate an isolation instruction to obtain the isolated path set. S1074, Construct an overall encryption framework based on the isolated path set.

[0059] In one implementation, in high-concurrency scenarios, vulnerability scanning data is extracted from system logs based on stable system throughput metrics. Then, using feature matching rules (Rule 1: requests with a response time exceeding 45ms and error code 503 are considered abnormal events; Rule 2: a single node with more than 50 abnormal requests per minute is considered a risk point) built from historical data over the past three months, it is determined that node E has 120 requests with a response time of 55ms and error code 503 within one minute (abnormal events), and its abnormal request ratio reaches 7% (risk point, preset risk ratio threshold = 5%). This allows for the extraction and marking of sets of abnormal events and risk points.

[0060] In one implementation, in high-concurrency scenarios, for the marked set of risk points, each item is first normalized, and a frequency score is calculated. ,in, For actual frequency, This is the frequency threshold, which can be set to 50 times per minute; the abnormality percentage score. The percentage threshold , The percentage of abnormal events is used; the criticality of a node is directly determined by its node weight, and a risk-weighted value is calculated using weighting coefficients α=0.5, β=0.3, and γ=0.2. ;in, This indicates the importance of the node containing the risk point within the overall system, determined by the importance of the business the node carries (e.g., whether it is a core payment gateway or a data storage node); the value range is typically [0, 1]. Nodes with higher importance have larger weight values ​​(e.g., core node weight = 0.8-1.0, edge node weight = 0.1-0.3). In the example... To obtain the risk-weighted value If the risk level exceeds the preset risk level threshold of 0.7, the system will generate an encryption enhancement command and produce encrypted and enhanced data records after execution.

[0061] It should be noted that the risk threshold is set at 0.7 after analyzing the situation where encryption enhancement was triggered when the risk weighted value of nodes with 7% of abnormal requests reached 0.85 over the past 3 months, and then the abnormal requests dropped to 2%, thus covering the critical value of most risk events. The weighting coefficients are determined based on the comprehensive weighting of the impact of risk factors. Abnormal frequency (α=0.5) is given the highest weight because the frequency of abnormal events in high-concurrency scenarios directly reflects the urgency of the risk, thus prioritizing the response to high-frequency risks. Abnormal proportion (β=0.3) is related to the scope of risk spread, and a balance needs to be struck between frequency and coverage. Its weight is lower than frequency but higher than node criticality. Node criticality (γ=0.2) reflects the system level of the risk impact. Although it is highly important, high-frequency and high-proportion risks need to be controlled first under high concurrency, so its weight is relatively low.

[0062] In one implementation, in high-concurrency scenarios, the system extracts affected paths from distributed link monitoring based on encrypted and enhanced data records (example, P102, node E → node F), and calculates the path risk score according to the risk calculation formula. in, The increase in data transmission latency along this path compared to the baseline latency after performing encryption enhancement operations; The maximum increase in latency that the path can tolerate; This represents the percentage of requests that failed to transmit or encountered verification errors on this path after encryption enhancement was performed. The highest error rate that the path can tolerate; The additional time overhead introduced by the encryption unit for processing a unit of data; The maximum allowable overhead for a single encryption operation set by the system to balance security and performance.

[0063] when When the risk level threshold is exceeded, the system generates a clear isolation instruction, which, after execution, produces a set of isolated paths.

[0064] Preferably, the weights can be configured as follows: =0.5 (Delay increases have the highest weight because they directly affect real-time performance). =0.3 (error rate weighting is secondary). =0.2 (encryption overhead weight); those skilled in the art will understand that these weights can be adjusted according to actual business needs (such as a greater emphasis on security or performance); when When the calculation result exceeds the preset risk level threshold (e.g., 0.8), the system generates an isolation command.

[0065] In one implementation, in high-concurrency scenarios, the system takes the isolated path set as input and uses a data integration protocol to build an overall encryption framework. To avoid misalignment of path optimization configuration due to time deviation and to improve system throughput stability and configuration reliability, NTP / PTP is first used to align with the system master clock and the time deviation of each path event is calibrated to no more than 3ms (if any path deviation is greater than 50ms, integration is paused and an alarm is triggered). Secondly, all traffic is forced to pass through the encryption channel and hardware-accelerated encryption units are allocated according to the path. Consistent hashing is used to allocate affected flows (such as F001–F120) to encryption units. At the same time, performance and security constraints are set to build the overall encryption framework.

[0066] In step S108, based on the overall encryption framework, historical processing logs are acquired and analyzed to verify collaborative work efficiency and identify areas for improvement, ultimately outputting the final hardware-accelerated encryption scheme, including: S1081, Based on the overall encryption framework, first obtain the historical processing logs, and extract the timestamps and task allocation records to generate the first collaborative efficiency dataset; S1082, Based on the collaborative efficiency dataset, compare it with the historical collaborative efficiency. If it is lower than the historical collaborative efficiency, generate an optimization allocation instruction to obtain an efficiency parameter instruction set. S1083 generates an encryption task allocation record based on the efficiency parameter instruction set, forms an encryption task dataset, and checks the integrity of the dataset. If the integrity is verified, the final hardware-accelerated encryption scheme is generated and output.

[0067] In one implementation, in high-concurrency scenarios, the system, based on an established overall encryption framework, first filters logs from a centralized log library according to a sampling window of 60 seconds and a log sampling period of 200ms. and Existence and The task allocation records are used to calculate key collaboration indicators. The indicators are then normalized using z-score and aggregated by node to generate the first collaboration efficiency dataset.

[0068] In one implementation, in high-concurrency scenarios, the system compares the first collaborative efficiency dataset with the pre-stored historical collaborative efficiency baseline. If it is lower than the historical collaborative efficiency, the system calculates the load deviation of each node / group in real time and generates intermediate scheduling update instructions (such as traffic migration, queue length adjustment, or dynamic rewriting of the routing table) accordingly. This is combined with consistent hash mapping to generate optimized allocation instructions and derive the efficiency parameter instruction set.

[0069] It should be noted that the historical collaborative efficiency baseline is usually obtained by performing statistical analysis on the processing logs of past high-concurrency scenarios (such as average / median / percentile latency, task completion rate, and experience thresholds), and stored in an indicator database or configuration library in the form of time series curves or statistical intervals (key fixed thresholds can be saved in parallel) for real-time comparison.

[0070] In one implementation, in high-concurrency scenarios, the system takes an efficiency parameter instruction set as input. The scheduling module maps the instructions to specific hardware-accelerated encryption units based on consistent hashing and dynamic scheduling algorithms, and generates encryption task allocation records. All timestamps are calibrated with NTP and the system master clock, and are summarized according to a sampling window of 60s and a sampling period of 200ms to form an encryption task dataset. Then, an integrity check is performed on the dataset (each record is calculated and compared with the SHA256 hash, the record count is verified to be consistent with the instruction expectation, the timestamp consistency check allows a deviation of ≤2ms, and the migration flow set is verified to be consistent with migrate_flow_ids). If all checks pass, the final hardware-accelerated encryption scheme is automatically generated and output; if the integrity check fails, the reason for the failure is recorded and a retry or isolation instruction is generated according to the preset rollback conditions.

[0071] In summary, this invention discloses a hardware-accelerated encryption method based on chip data encryption. It adjusts parameters and constructs regional states through consistent hash mapping, extracts balanced features based on dynamic scheduling and timing calibration, identifies inefficient bottlenecks and predicts impact paths, and then generates and verifies resource optimization schemes to achieve reentrant load balancing and throughput stability assurance under high concurrency.

[0072] Reference Figure 2 The second embodiment of the present invention provides a hardware-accelerated encryption system based on chip data encryption, comprising: Task grouping module: used to collect the current system load and characteristics of incoming data streams, obtain real-time task distribution, activate multi-task parallel mode when the number of tasks exceeds the preset task number threshold, and output task group set; Path allocation module: used to match the transmission paths of data segments within the task group according to the task group set, determine independent paths compatible with hardware acceleration, and output a path allocation scheme; Security strength assessment module: used to obtain path parameters according to the path allocation scheme and perform security strength assessment on each path data stream. When the security strength is lower than the preset security strength threshold, the encryption parameters are adjusted and the encryption unit load is balanced. The security strength configuration is then output. Synchronous execution module: used to extract collaborative work instructions and distribute them to multiple encryption units according to the security strength configuration, use timestamp synchronization to determine the operation sequence, and output a synchronous encrypted execution sequence; Resource adjustment module: used to monitor real-time processing delay according to the synchronous encrypted execution sequence, and reallocate path resources when the delay exceeds a preset threshold, and output a resource adjustment plan; Path optimization module: used to extract adjustment parameters according to the resource adjustment plan, perform dynamic scheduling for inefficient areas, integrate transmission path feedback, and obtain stable system throughput indicators; Encryption Enhancement Module: Used to extract vulnerability scanning data based on the system throughput indicators and enhance the encryption of potential risk points to obtain the overall encryption framework; Log analysis module: Based on the overall encryption framework, it acquires and analyzes historical processing logs, verifies collaborative work efficiency, identifies areas for improvement, and outputs the final hardware-accelerated encryption scheme.

[0073] It should be noted that the hardware-accelerated encryption system based on chip data encryption provided in this embodiment of the invention is used to execute all the process steps of the hardware-accelerated encryption method based on chip data encryption in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0074] The above specific embodiments have further described in detail 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 do not 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 hardware-accelerated encryption method based on chip data encryption, characterized in that, include: Collect the current system load and characteristics of incoming data stream, obtain real-time task distribution, and activate multi-task parallel mode when the number of tasks exceeds the preset task number threshold, and output task group set; Based on the task group set, perform transmission path matching on the data segments within the group and determine independent paths compatible with hardware acceleration, and output a path allocation scheme; According to the path allocation scheme, the path parameters are obtained and the security strength assessment of each path data stream is performed. If the security strength is lower than the preset security strength threshold, the encryption parameters are adjusted and the encryption unit load balancing is performed, and the security strength configuration is output. Based on the security strength configuration, collaborative work instructions are extracted and distributed to multiple encryption units. The operation sequence is determined by timestamp synchronization, and a synchronized encryption execution sequence is output. Based on the synchronous encrypted execution sequence, monitor the real-time processing delay and reallocate path resources when the preset processing delay threshold is exceeded, and output a resource adjustment plan; Based on the resource adjustment plan, adjustment parameters are extracted and dynamic scheduling is performed on inefficient areas. Transmission path feedback is integrated to obtain a stable system throughput index. Based on the system throughput metrics, vulnerability scanning data is extracted and potential risk points are encrypted and strengthened to obtain the overall encryption framework. Based on the overall encryption framework, historical processing logs are acquired and analyzed to verify collaborative work efficiency and identify areas for improvement, ultimately outputting the final hardware-accelerated encryption scheme.

2. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, Collect current system load and incoming data stream characteristics, obtain real-time task distribution, and activate multi-task parallel mode when the number of tasks exceeds a preset task quantity threshold. Output task group set, including: The system load and incoming data stream characteristics of each node are collected in real time through a distributed message queue, and the number of real-time tasks is counted. When the number of real-time tasks exceeds a preset task number threshold, the task scheduler triggers a multi-task parallel mode and maps and allocates tasks to different nodes or parallel queues according to task type and resource requirements, thereby generating an initial task group set.

3. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, Based on the task group set, transmission path matching is performed on the data segments within the group, and independent paths compatible with hardware acceleration are determined. A path allocation scheme is then output, including: Based on the task group set, query the bandwidth requirements and latency constraints of data segments within each group in the distributed database; Based on the bandwidth requirements and latency constraints, a set of candidate adaptation paths is selected according to preset hardware acceleration compatibility rules. Based on the set of candidate adaptation paths, the data fragments are then mapped to node transmission paths with corresponding hardware acceleration capabilities and load balancing. If the mapping causes the communication overhead between nodes to exceed a preset communication overhead threshold, the nodes are reassigned to low-overhead paths through a dynamic routing table, thereby outputting a path allocation scheme.

4. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, According to the path allocation scheme, path parameters are obtained and security strength assessments are performed on each path data stream. If the data stream falls below a preset security strength threshold, encryption parameters are adjusted and encryption unit load balancing is performed. The security strength configuration is then output, including: Based on the path allocation scheme, the bandwidth usage and latency parameters of each path are extracted, the security strength of each path is evaluated, and a set of data streams below the preset security strength threshold is selected. The encryption parameters are adjusted based on the data stream set to form an updated encryption parameter set; the encryption parameters include key length and encryption mode. The set of encryption parameters is mapped and allocated to encryption units, and the unit load balancing is adjusted. Finally, the corresponding encryption unit configuration is applied and the path selection is updated through the dynamic routing table, and the security strength configuration set is output.

5. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, Based on the security strength configuration, collaborative work instructions are extracted and distributed to multiple encryption units. The operation sequence is determined using timestamp synchronization, and a synchronized encryption execution sequence is output, including: Based on the security strength configuration, extract collaborative work instructions and decompose them into a set of tasks containing task descriptions and priorities; The tasks, which include task descriptions and priorities, are distributed to multiple encryption units and queues and loads are monitored in real time to ensure balance. The task data of each unit is extracted, calibrated, and sorted by timestamp to determine the order of operations. Based on the order of operations, execution commands are issued and the encryption mode and key length of each unit are adjusted by dynamic scheduling to obtain a synchronized encryption execution sequence.

6. The hardware-accelerated encryption method based on chip data encryption according to claim 5, characterized in that, Based on the synchronous encryption execution sequence, monitor real-time processing latency and reallocate path resources when the latency exceeds a preset threshold, outputting a resource adjustment plan, including: Based on the synchronized encrypted execution sequence, monitor the real-time processing delay. If the delay exceeds a preset processing delay threshold, scan to obtain the initial set of congested path identifiers and mark the path status data. Based on the marked path status data, the resource nodes are mapped to determine the traffic load of congested points. When the load is unbalanced, the status data is adjusted to obtain a set of intermediate resource adjustment plans. Based on the resource adjustment intermediate plan set, the congestion point time sequence record is calibrated, and the traffic balance index deviation value is dynamically scheduled and calculated. If it exceeds the preset balance index deviation threshold, the intermediate plan set is optimized, and the integrated resource configuration scheme is determined. Based on the integrated resource allocation scheme, extract the mitigation parameter list, verify the stability of the execution sequence, and output an optimized resource adjustment plan.

7. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, Based on the resource adjustment plan, adjustment parameters are extracted, and dynamic scheduling is performed on inefficient areas. Transmission path feedback is integrated to obtain stable system throughput metrics, including: According to the resource adjustment plan, an adjustment parameter list is extracted, and the parameter matching degree is judged for inefficient regions. If the matching degree is lower than a preset threshold, a set of region identifiers is generated to obtain the marked region status data. Based on the marked area status data, calculate the load deviation value and obtain the intermediate instruction set for scheduling updates; The transmission path is integrated based on the intermediate instruction set to obtain the integrated path feedback record; Based on the integrated path feedback records, the timing records are calibrated to determine the feedback consistency. If the consistency deviation is higher than the preset consistency deviation threshold, the path records are optimized to determine the initial configuration scheme for path optimization. Based on the initial configuration scheme of the path optimization, extract the list of balanced indicators, verify the throughput stability, and obtain stable system throughput indicators.

8. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, Based on the system throughput metrics, vulnerability scanning data is extracted and potential risk points are encrypted and strengthened to obtain the overall encryption framework, including: Based on stable system throughput metrics, extract and label a set of abnormal events and risk points; Based on the marked set of risk points, a risk weighting value is calculated. If the risk weighting value is higher than a preset risk level threshold, an encryption enhancement instruction is generated to obtain the encrypted and enhanced data record. Based on the encrypted and enhanced data records, the affected paths are extracted. If the risk of the affected path is higher than a preset risk level threshold, an isolation instruction is generated to obtain the isolated path set. Based on the isolated set of paths, an overall encryption framework is constructed.

9. The hardware-accelerated encryption method based on chip data encryption according to claim 1, characterized in that, Based on the overall encryption framework, historical processing logs are acquired and analyzed to verify collaborative work efficiency and identify areas for improvement. The final hardware-accelerated encryption scheme is then output, including: Based on the overall encryption framework, historical processing logs are first obtained, and timestamps and task allocation records are extracted to generate the first collaborative efficiency dataset. Based on the collaborative efficiency dataset, compare it with the historical collaborative efficiency. If it is lower than the historical collaborative efficiency, generate an optimization allocation instruction to obtain an efficiency parameter instruction set. Based on the efficiency parameter instruction set, an encryption task allocation record is generated to form an encryption task dataset. The integrity of the dataset is checked, and if it passes, the final hardware-accelerated encryption scheme is generated and output.

10. A hardware-accelerated encryption system based on chip data encryption, characterized in that, include: Task grouping module: used to collect the current system load and incoming data stream characteristics, obtain real-time task distribution, activate multi-task parallel mode when the number of tasks exceeds the preset task number threshold, and output task group set; Path allocation module: used to match the transmission paths of data segments within the task group according to the task group set, determine independent paths compatible with hardware acceleration, and output a path allocation scheme; Security strength assessment module: used to obtain path parameters according to the path allocation scheme and perform security strength assessment on each path data stream. When the security strength is lower than the preset security strength threshold, the encryption parameters are adjusted and the encryption unit load is balanced. The security strength configuration is then output. Synchronous execution module: used to extract collaborative work instructions and distribute them to multiple encryption units according to the security strength configuration, use timestamp synchronization to determine the operation sequence, and output a synchronous encrypted execution sequence; Resource adjustment module: used to monitor real-time processing delay according to the synchronous encrypted execution sequence, and reallocate path resources when the delay exceeds a preset threshold, and output a resource adjustment plan; Path optimization module: used to extract adjustment parameters according to the resource adjustment plan, perform dynamic scheduling for inefficient areas, integrate transmission path feedback, and obtain stable system throughput indicators; Encryption Enhancement Module: Used to extract vulnerability scanning data based on the system throughput indicators and enhance the encryption of potential risk points to obtain the overall encryption framework; Log analysis module: Based on the overall encryption framework, it acquires and analyzes historical processing logs, verifies collaborative work efficiency, identifies areas for improvement, and outputs the final hardware-accelerated encryption scheme.

Images