A network software security management and control method

Abstract

This invention relates to the field of network software security management technology, specifically disclosing a network software security management method. First, a system call interception module is deployed at the kernel layer of each management node. A dedicated authorization license file is stored in the trusted execution environment local to each node. All system requests involving permission calls generated during the startup and operation of the network software are preferentially intercepted by the kernel-level interception module, triggering kernel-mode authorization validity verification logic. The verification process does not involve the user-mode operable space; only after successful verification can the system call execute normally. This invention effectively avoids the risk of user-mode authorization being easily cracked. Authorization updates do not require restarting the corresponding business software, avoiding business interruption. It eliminates the need to deploy a centralized authorization server, thus avoiding single point-of-failure risks. It is adaptable to confidential private network scenarios without public network access, significantly reducing the operation and maintenance costs of large-scale clusters.

Description

Technical Field

[0001] This invention relates to the field of network software security management technology, and in particular to a network software security management method. Background Technology

[0002] The deployment scale of network software in government, enterprise, finance, telecom operators, and internet sectors continues to expand. With the implementation of compliance requirements such as Cybersecurity Classified Protection 2.0 and the Data Security Law, copyright protection, function permission control, and operation behavior evidence preservation of network software have become core rigid requirements of the industry, and the requirements for the security, availability, and adaptability of control solutions are constantly increasing.

[0003] The current mainstream user-space authorization control scheme works by storing license files in the local user-space storage area of ​​the node. During software runtime, the license validity is verified in user space, and only after successful verification can the corresponding function be enabled. This scheme has a low deployment threshold, is compatible with most general-purpose operating systems, and is currently adopted by the vast majority of commercial software vendors. However, this scheme has significant drawbacks: the verification logic is entirely deployed in user space, making the license file extremely vulnerable to reverse engineering and malicious tampering; there is no kernel-level forced interception mechanism, allowing attackers to bypass verification by tampering with programs or hooking system calls; and license updates require restarting the corresponding network software, which can easily cause service interruptions and fails to meet the requirements of high-availability business scenarios.

[0004] Another mainstream centralized online authorization solution works by sending authorization verification requests from all nodes to a centralized authorization server for verification, with licensing rules configured and updated centrally. This solution facilitates unified management of authorization rules across the entire cluster by operations personnel, eliminating the need for node-by-node operations. However, this solution has serious limitations: the centralized server is a single point of failure; if the central service goes down, authorization verification across the entire cluster will fail. Furthermore, it cannot access the central service in scenarios involving confidential private networks without public network connectivity, resulting in poor adaptability. Large-scale cluster deployments place immense pressure on the central verification side, leading to extremely high operational costs. The license synchronization process is also prone to leaking core authorization information, posing security risks.

[0005] With the continuous upgrading of network security requirements, the existing two types of solutions cannot simultaneously meet the combined requirements of high security against cracking, uninterrupted business operations, multi-scenario adaptability, and low operation and maintenance costs. They are no longer suitable for increasingly stringent network security compliance and management standards, and there is an urgent need for new network software management solutions to fill the industry gap. Summary of the Invention

[0006] This invention proposes a network software security management method to solve the problems mentioned in the prior art, such as easy cracking of network software authorization management, lack of kernel layer verification, easy interruption of services due to authorization updates, and high cluster operation and maintenance costs.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a network software security management method, comprising the following steps: The management and control platform generates an encrypted license carrying the scope of authorized functions, validity period, and node hardware feature binding information based on the deployment scenario of the network software to be authorized and the business attributes of the authorized object. The license is then sent to the user-mode management and control unit of the corresponding deployment node through an encrypted transmission channel. The user-mode management unit performs hash integrity verification on the received encryption license. After the verification is successful, the encryption license is stored in the local trusted storage area, and the validity status information of the license is synchronized to all associated collaborative deployment nodes in the cluster through the two-way authentication channel. The kernel-mode verification unit loads the pre-compiled eBPF probe, attaches the probe to the corresponding trace points of the kernel's network system calls and process function triggers, and reads the encryption license information in the local trusted storage area to complete the verification initialization. The kernel-mode verification unit captures all network interaction requests and function call operations initiated by the network software in real time through the eBPF probe, performs legality verification based on the read license information, directly intercepts requests that fail verification, and generates an immutable evidence log that is uploaded to the management platform. When a license expires or its authorization is adjusted, the management platform will issue the updated encryption license to the user-mode management unit, which will then perform a hot update. The update process does not require restarting the network software or the kernel-mode verification unit.

[0008] Furthermore, when the management platform generates an encrypted license, it first collects at least two types of hardware features from the CPU serial number, network card MAC address, and motherboard serial number of the node to be authorized, performs a hash operation, and uses the result as a derivation factor of the encryption key to participate in the license encryption.

[0009] Furthermore, when the user-mode control unit synchronizes license status information, it only synchronizes the valid status identifier of the license and the hash value of the authorized function scope, without synchronizing the complete license plaintext or encryption key information.

[0010] Furthermore, after the eBPF probe is loaded, the kernel-mode verification unit performs a hash check on the probe's integrity. Only after the check passes can it be mounted to the corresponding tracking point. Probes that fail the integrity check are prohibited from being loaded and run.

[0011] Furthermore, when the kernel-mode verification unit performs legality verification, it first verifies whether the process signature of the network software matches the preset whitelist. If the process signature verification fails, all operation requests of that process are directly blocked.

[0012] Furthermore, after the process signature verification passes, the kernel-mode verification unit further verifies whether the function requested by the current user falls within the scope of the license authorization and whether the request time is within the license validity period. Only when both verifications pass can the request be released.

[0013] Furthermore, the evidence log generated by the kernel-mode verification unit is encrypted using the national cryptographic algorithm and then stored. The log content includes the request time, request process identifier, request content, and interception reason. The log can only be read by the management platform holding the corresponding decryption key.

[0014] Furthermore, for offline deployment scenarios involving classified private networks, the management platform supports offline export of encrypted licenses, which can be imported by authorized personnel into the user-space management unit of the corresponding node via offline storage media to complete the license deployment and update.

[0015] Furthermore, when the user-mode control unit detects that the license stored locally has been tampered with, it immediately triggers the local invalidation mechanism, notifying the kernel-mode verification unit to switch to the interception state and intercept all outbound requests from the network software on that node.

[0016] Furthermore, the management platform can generate and distribute encrypted licenses in batches for multiple nodes within the cluster, and supports unified push when adjusting authorization rules in batches, without the need to operate on each node individually.

[0017] Compared with existing technologies, the beneficial effects of this invention are: This invention employs a technique that deploys mandatory verification logic at the kernel-mode system call hook layer and stores the license file in a local trusted execution environment. The verification process is entirely outside the user-mode operable space, making it impossible to bypass the verification through process tampering or system call hooking. When updating the license, only the kernel-mode verification rules need to be synchronized to take effect, without restarting the corresponding network software. This effectively solves the shortcomings of existing user-mode license control schemes that are easily cracked and whose license updates interrupt services.

[0018] This invention employs a distributed node local self-verification and cluster permission rule point-to-point trusted synchronization mechanism. It eliminates the need for a centralized authorization server, avoids the risk of a single point of failure causing the entire cluster verification to fail, and does not rely on the public network to transmit authorization information. It is adaptable to confidential private network scenarios without public network access. When the cluster is expanded, there is no need to adjust the central service configuration, which significantly reduces the operation and maintenance costs of large-scale clusters. It effectively solves the shortcomings of existing centralized online authorization solutions, such as poor adaptability, high operation and maintenance costs, and the risk of single point of failure.

[0019] This invention is compatible with mainstream hardware architectures and general operating systems, and can seamlessly integrate with the existing architecture of commercial network software. It can be quickly deployed without large-scale modifications to the original software code, and can simultaneously achieve end-to-end evidence storage of operational behaviors, meeting the relevant compliance and audit requirements of the Information Security Law 2.0, the Data Security Law, and other related laws. It can cover a variety of application scenarios such as government and enterprise offices, core financial transactions, operator core networks, and Internet services. It is suitable for both small-scale single-node deployment needs and can also support the management and control needs of ultra-large-scale node clusters, and has extremely high industry promotion value. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the overall process of network software security management proposed in this invention. Figure 2 This is a flowchart illustrating the license generation, encryption, and issuance process proposed in this invention. Figure 3 This is a flowchart of the kernel-mode verification unit initialization and probe mounting process proposed in this invention; Figure 4 This is a flowchart of the real-time legality verification and interception process based on eBPF proposed in this invention; Figure 5 This is a flowchart of the cluster state synchronization and lossless hot update process proposed in this invention. Detailed Implementation

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

[0022] Reference Figures 1 to 5 A network software security management method includes the following steps: After receiving an authorization request work order submitted by the administrator, the management platform first actively retrieves three types of basic information through a pre-established encrypted heartbeat link with the node to be authorized. The first type is the deployment scenario attributes of the network software to be authorized, which specifically includes three sub-information: deployment scenario type identifier, industry compliance level identifier, and security domain classification identifier of the node, used to match the authorization management rules of the corresponding scenario.

[0023] The second category is the business attributes of the authorized object, specifically including four sub-information categories: the unique identifier of the organizational structure to which the authorized object belongs, the security level protection filing number of the corresponding business system, the list of open functional permissions, and the permission level of the associated operation role. These are used to determine the scope of authorized functions and the level of control. The third category is node hardware identification information, specifically including four hardware characteristic values: the unique serial number of the node CPU, the motherboard BIOS UUID, the unique hardware identifier of the system disk, and the physical network card MAC address. These are used to bind the license to the hardware of the deployed node.

[0024] The management platform retrieves a pre-configured authorization rule template. This template allows administrators to customize and adjust parameters such as the upper limit of the authorization validity period, the scope of open functions, and hardware binding requirements under different scenarios through a visual interface. After matching the three types of basic information retrieved with the template parameters one by one, the plaintext license is generated.

[0025] The license document contains three parts. The first part is a set of authorized function codes. The management platform pre-assigns a unique 16-digit hexadecimal function code to each independently authorizable function of the network software to be authorized. The corresponding codes are selected according to the business attributes of the authorized object to form this set. The second part is the authorized validity period. The start and end timestamps are set to the second based on the purchase duration of the authorization application and the compliance requirements of the deployment scenario. The third part is a node hardware feature binding list. The collected node hardware identification information is hashed using SM3 to generate a feature whitelist, which supports single-node binding or batch binding of multiple node clusters to adapt to different deployment needs.

[0026] The management platform uses a combination of the national cryptographic algorithms SM2 and SM4 to encrypt the plaintext of the license. First, a 128-bit SM4 session key is generated using the built-in national cryptographic random number generation module. This session key is then used to perform symmetric encryption on the plaintext of the license to obtain the ciphertext body. Next, the management platform's SM2 private key, stored in the hardware encryption machine, is used to perform asymmetric encryption on the SM4 session key. Simultaneously, the SM3 algorithm is used to generate an integrity digest of the plaintext of the license. The digest is then digitally signed using the same SM2 private key. Finally, the encrypted ciphertext body, the encrypted session key, and the digital signature are concatenated to form a complete encrypted license. Throughout the encryption process, the private key remains within the hardware encryption machine, avoiding the risk of key leakage.

[0027] The management platform and the user-mode management unit of the node to be authorized establish an encrypted transmission channel based on the bidirectional TLS 1.3 protocol. Before the channel is established, both parties first verify the legality of the other party's pre-installed national cryptographic SM2 device root certificate. After the verification is passed, they negotiate a dedicated transmission session key. The encrypted license is then encrypted twice with the transmission session key and sent to the corresponding deployment node. After the node-side user-mode management unit receives the license, it first compares the SM3 digest values ​​before and after transmission to confirm the data integrity. After the verification is passed, the encrypted license is stored in the local temporary cache area, waiting to be transferred to the trusted execution environment later. No plaintext license information is exposed during the entire transmission process, effectively avoiding the risk of information leakage in the transmission process. After receiving the encrypted license data packet from the management platform, the user-mode control unit first performs structured splitting of the data packet, extracting the original SM3 hash digest generated by the management platform from the header. Then, it performs a national standard SM3 hash operation on the concatenated content of the three core fields: the encrypted license body, the encrypted session key, and the digital signature. The resulting local hash value is compared bit-by-bit with the extracted original hash value to complete the integrity verification. If the verification fails, the user-mode control unit discards the received data packet, returns an integrity verification failure error code to the management platform, and generates a local anomaly audit log event, triggering the management platform's automatic retransmission mechanism. If the retransmission fails after a maximum of three retries, an alarm is pushed to the administrator.

[0028] After the integrity verification passes, the user-mode management unit calls the standard client API corresponding to the local trusted execution environment (TEE) to initiate a trusted storage write request. The TEE is built on Arm TrustZone or Intel SGX architecture and is completely isolated from the user-mode operating system's memory space. The user-mode management unit passes the entire encrypted license as a write parameter to the API. After the TEE's secure kernel verifies the caller's preset permissions, it writes the encrypted license to a dedicated secure storage partition. This partition only has a dedicated read port open to the kernel-mode authorization verification module. No user-mode process, including the root process with the highest privileges, can perform read, modify, copy, or delete operations on this partition. After the write is completed, the TEE returns a write success receipt with an SM2 signature. Upon receiving the receipt, the user-mode management unit sends a notification to the management platform that the license has been successfully stored.

[0029] Subsequently, the user-mode management unit calls the read-only decryption interface of the trusted execution environment to temporarily decrypt the header metadata fields of the encrypted license and extract two types of core synchronization information. The first type is the authorization validity status identifier, which is a 32-bit fixed-length status field containing three attributes: authorization activation status, validity period validity identifier, and hardware binding verification result. The second type is the SM3 hash digest of the authorized function code set, which is a 256-bit fixed-length digest value obtained by performing an SM3 hash operation on all authorized function codes in the license. The complete plaintext content of the license is not decrypted during the extraction process to avoid leakage of sensitive authorization information.

[0030] The user-mode management unit establishes a two-way authenticated TLS 1.3 encrypted transmission channel with all associated and collaborative deployment nodes based on the root certificates of the national cryptographic devices pre-installed on each node in the cluster. Before the channel is established, both parties verify the legality of each other's device certificates. After the verification is successful, only the extracted authorized valid status identifier and authorized function code hash digest are synchronized to all collaborative nodes, without transmitting the complete encrypted license content.

[0031] After receiving the synchronization information, each coordinating node first compares the received hash digest with the hash value of the corresponding field in the locally stored encrypted license. If the comparison matches, it updates the local authorization status flag and returns a signed confirmation receipt to the node that initiated the synchronization. If the comparison does not match, it automatically sends a request to the management platform to re-retrieve the local license.

[0032] The node that initiates the synchronization process tracks the acknowledgments of each cooperating node in real time. Once the acknowledgment rate of all valid nodes in the cluster reaches the target, the cluster authorization synchronization is marked as complete. If a node fails to synchronize multiple times, a synchronization anomaly alarm is generated and reported to the management platform to ensure that the authorization status of all nodes in the cluster is completely consistent, thus avoiding business chaos caused by inconsistent authorization rules of some nodes.

[0033] The execution results, timestamps, and operation object identifiers of all the above operations will be written to the local anti-tampering audit log and periodically synchronized to the audit center of the management and control platform to meet the data security compliance audit requirements. The kernel-mode verification unit is automatically triggered to start after the operating system kernel initialization is completed and before all user-mode service processes start. It prioritizes the pre-deployment of authorization verification to prevent unauthorized network software from bypassing control by running prematurely. After startup, it first reads the eBPF verification probe file and its corresponding SM2 digital signature file pre-pushed to the kernel read-only partition by the management platform. It then retrieves the management platform's built-in probe signature public key and performs integrity and legality verification on the eBPF verification probe. First, perform an SM3 hash operation on the probe binary file to generate a local digest. Then, use the public key to verify the validity of the digital signature. If the verification fails, the probe loading process is terminated directly. At the same time, a probe tampering alarm is generated and synchronized to the management platform. All system call permissions of the target network software are automatically set to the default blocking state.

[0034] The eBPF verification probe is pre-compiled and adapted by the management platform for different operating system versions and kernel versions. It supports all kernel versions of mainstream server operating systems such as CentOS, Ubuntu, and OpenEuler, eliminating the need for users to compile on-site and significantly reducing deployment and adaptation costs.

[0035] After the integrity verification passes, the kernel-mode verification unit calls the standard mounting interface of the kernel eBPF subsystem to mount the eBPF verification probe to two preset system call tracing points.

[0036] The first category is network system call tracing points, which include at least three types: sys_bind, sys_connect, and sys_sendmsg. Among them, the probe mounted to the sys_bind tracing point can intercept all process calls bound to local ports, and verify the port listening permissions of the network software accordingly. The probe attached to the sys_connect trace point can intercept all processes' requests to initiate TCP / UDP connections, corresponding to verifying the network software's cross-node outbound connection permissions; the probe attached to the sys_sendmsg trace point can intercept all processes' requests to send data packets, corresponding to verifying the network software's data transmission range permissions.

[0037] The second category is process function trigger tracing points, which at least include sys_execve tracing points. After mounting, these can intercept all requests for process startup, child process creation, and dynamic loading of functional modules, and verify the startup permissions of the network software itself and the usage permissions of subdivided functional modules. When the probe is mounted, the interception scope is configured based on the cgroup to which the target network software belongs. It only captures system calls initiated by processes belonging to the target cgroup and will not intercept call requests from other system processes or irrelevant business processes, thus avoiding performance loss or false interception of the overall operating system.

[0038] After the probe is mounted, the kernel-mode verification unit calls the kernel-specific read interface opened by the Trusted Execution Environment to retrieve the encrypted license stored in the Trusted Execution Environment's secure partition. The entire read process does not pass through any user-mode memory space, thus preventing the encrypted license from being intercepted by user-mode processes.

[0039] After retrieval, the kernel-mode verification unit decrypts and parses the license in a kernel-specific encrypted memory page. This type of memory page is configured with security attributes such as not being exportable, not being accessible by user-mode processes, and being automatically cleared when the process context switches, so there is no risk of plaintext license leakage throughout the process.

[0040] The decryption and parsing process corresponds exactly to the encryption process of the management platform: First, the session key field in the encrypted license is decrypted using the built-in management platform SM2 public key to obtain the SM4 symmetric decryption key. The ciphertext body of the license is then decrypted using this key to obtain the plaintext license. Subsequently, the plaintext is subjected to an SM3 hash operation and compared with the integrity digest attached to the license to confirm that the plaintext has not been tampered with. After the comparison is successful, the verification rule initialization is completed.

[0041] The initialization process specifically includes: establishing a mapping relationship between the authorized function encoding in the license plaintext and the corresponding allowed system call behavior; converting the authorized valid time interval into a local timestamp format that the kernel can directly compare; pre-verifying the node hardware feature binding list with the hardware identifier of the current node; and setting the interception rules of all probes to default if the pre-verification fails.

[0042] After initialization, the kernel-mode verification unit generates a rule activation receipt with an SM2 signature, which is synchronized to the local user-mode management unit and the remote management platform, marking the official activation of the node's authorization verification system. The kernel-mode verification unit also enables a probe anti-tampering protection mechanism, monitoring for unloading, modification, and replacement operations on eBPF probes in real time. Once an abnormal operation is detected, interception is triggered directly, and an audit log is generated and reported to the management platform. If necessary, the process triggering the abnormal operation can be terminated directly to prevent the authorization management system from being maliciously bypassed.

[0043] After the eBPF probe of the kernel-mode verification unit is mounted, it first performs pre-filtering on all captured system calls based on the preset target network software-specific cgroup group label and the SM3 hash whitelist of the process executable file. Only network interaction requests and local function call operations belonging to the network software to be managed are captured, while call requests from other system processes and irrelevant business processes are allowed directly, avoiding system performance loss caused by invalid capture.

[0044] For network interaction requests, eBPF probes extract complete verification parameters from three types of trace points: probes mounted on the sys_bind trace point capture the process PID, the port number to be bound, and the address range information of the bound IP, corresponding to verify the port listening permissions of the network software; probes mounted on the sys_connect trace point capture the target IP address, target port, and transport layer protocol type of the connection request, corresponding to verify the cross-node outbound permissions of the network software; probes mounted on the sys_sendmsg trace point capture the packet destination address, the unique identifier of the functional module to which the packet belongs, and the first 64 bits of the packet payload's characteristic hash, corresponding to verify the data transmission range permissions of the network software.

[0045] For local function call operations, the probe mounted on the sys_execve trace point captures the 16-bit hexadecimal unique code of the function module to be loaded, the permission level of the process initiating the call, and the SM3 hash value of the module's executable file, and verifies the usage permissions of the function module of the network software accordingly.

[0046] All captured parameters undergo validity verification directly within the kernel's dedicated encrypted memory page, eliminating the need for processing in user space. Verification latency is controlled within microseconds, ensuring uninterrupted business operations. The verification process strictly matches pre-parsed license rules and executes them sequentially: First, the basic authorization status is verified by comparing the current kernel system time with the license's valid time interval. Simultaneously, the current node's hardware characteristics are compared with the license binding list. If either of these conditions is not met, all captured requests are directly intercepted. The second step verifies the functional permissions corresponding to the request. For local function call requests, the captured function module code is directly hashed against the set of license-authorized function codes. If no matching code is found, the verification fails. For network interaction requests, the function module code to which the request belongs is first matched. After confirming that the function is authorized, the network behavior is then verified to ensure it conforms to the function's preset access whitelist rules. If it does not conform to the rules, the verification fails. The verification rules are stored in a pre-generated hash table in kernel space, with a matching efficiency of O(1), which can support the real-time verification requirements of tens of thousands of concurrent requests.

[0047] For requests that fail verification, the kernel-mode verification unit intercepts them directly at the system call entry point, without passing the request to the subsequent kernel network protocol stack or process scheduling process: network interaction requests directly return a system call error code indicating permission denial, without generating any invalid network packets, thus avoiding the consumption of network bandwidth resources; local function call requests directly terminate the system call process, return an error code indicating that the operation is not allowed, without loading unauthorized modules into memory, and only intercept the single request that violates the rules, without terminating the main process of the network software, thus avoiding affecting the normal use of other authorized functions.

[0048] After the interception operation is triggered, the kernel-mode verification unit automatically generates an immutable evidence log. The log content includes six core fields: the timestamp of the request initiated to the microsecond, the PID of the process that initiated the request, the request type, the complete request parameters, the verification result, and the reason for the interception. The kernel uses the built-in national cryptographic SM3 algorithm to generate an integrity digest of the entire log, and then calls the node SM2 private key stored in the trusted execution environment to digitally sign the digest and write it to the kernel's dedicated circular read-only log buffer. This buffer only supports read-only operations by the user-mode management unit and cannot be modified or deleted by any process.

[0049] Logs are uploaded asynchronously. When the buffer reaches a preset threshold or the system is in a business idle window, they are uploaded to the audit center of the management platform through a bidirectional TLS 1.3 encrypted channel. The log content in the corresponding buffer will be cleared only after the upload is completed. Logs that are not successfully uploaded will be temporarily stored locally, so there will be no loss of audit data, which meets the audit compliance requirements of the Cybersecurity Classified Protection 2.0.

[0050] If the kernel-mode verification unit detects that a single process continuously sends more than a preset threshold of unauthorized requests within one minute, it will automatically trigger a temporary circuit breaker mechanism to block all requests from that process within a preset time window. Simultaneously, it will report an alarm message about brute-force attacks on authorization rules to the management platform, further enhancing the security of authorization management. When a license is updated, the kernel-mode verification unit can directly pull and parse the latest verification rules from the trusted execution environment without uninstalling or restarting the eBPF probe, or restarting the operating system or business processes. This enables hot updates of authorization rules without affecting business continuity. When three scenarios trigger license renewal, the management platform will automatically initiate the license renewal process: The first scenario is license expiration. The platform's authorization lifecycle management module will pre-set a number of days to scan for licenses that are about to expire and automatically generate a new license based on the renewed authorization period and scope to avoid accidental blocking of business after expiration. The second scenario is authorization scope adjustment, which covers operational needs such as customers purchasing additional software function modules, adjusting node deployment scale, modifying network access whitelists, and adjusting function usage permissions. After receiving the adjustment application submitted by the administrator and completing multi-level permission approval, the management platform will automatically generate a new license adapted to the adjusted rules. The third scenario is key rotation, including periodic key rotation that complies with the national cryptographic algorithm application specifications, or emergency key rotation when a risk of key leakage is detected. The management platform will generate a license encrypted with a new session key and synchronously complete the key update of all nodes.

[0051] When the management platform generates a new encrypted license, it binds it to the unique hardware feature identifier of the target node, uses the national standard SM4 symmetric encryption algorithm to encrypt the license body, attaches an SM3 integrity digest signed by the management platform's private key, and distributes it point-to-point to the user-space management unit of the corresponding node through a TLS1.3 encrypted transmission channel that has completed two-way device certificate authentication. In the case of cluster batch updates, a reliable multicast distribution mechanism is adopted to distribute the same version of the encrypted license to all cluster nodes at the same time, improving the efficiency of batch updates and avoiding the time-consuming problem of distributing one by one.

[0052] After receiving the encrypted license for the update, the user-mode management unit first performs a national standard SM3 integrity check, consistent with the initial license reception. If the check passes, it extracts the new license's version number and preset effective timestamp, comparing them with the parameters of the currently effective old license. This confirms that the new license's version number is higher and the effective time is logically consistent, preventing it from being overwritten by a maliciously distributed old version license. Once the verification is confirmed, the user-mode management unit calls the trusted execution environment's write interface to write the new license to a separate partition in the trusted storage area, temporarily not overwriting the old license. Simultaneously, the old license is marked as pending expiration, reserving a quick rollback path in case of update failure.

[0053] When the preset effective time of the new license is reached, or upon receiving an immediate update command from the management platform, the user-mode management unit triggers the hot update process for verification rules. It calls the atomic update interface of the mapping table exposed by the kernel-mode eBPF subsystem. This process does not require unloading the mounted eBPF verification probes or modifying the probes' execution logic; it only performs an atomic update on the verification rule mapping table that the probes depend on. First, the rules such as the authorized validity period, authorized function code set, and network access whitelist after the new license is decrypted and parsed are written in batches into the backup rule mapping table. After the writing is completed, an atomic pointer switching operation is performed to switch the probe's rule reading pointer from the old mapping table to the new mapping table. The entire switching operation is an atomic operation, and there will be no intermediate state where some requests use the old rules and some requests use the new rules. The verification logic of all concurrent requests is completely unified at the moment of switching, and there will be no rule conflict or missed verification.

[0054] After the rule switch is completed, the kernel-mode verification unit automatically performs rule consistency verification, reads all rules in the new mapping table and compares them bit by bit with the decrypted new license parameters. After confirming that the rules are completely consistent, it returns an update success receipt to the user-mode management unit. After receiving the receipt, the user-mode management unit marks the old license as invalid. The trusted execution environment automatically cleans up the storage content of the old license after a preset time.

[0055] If a rule mismatch is found during the verification process, or if an abnormal increase in the interception rate occurs after switching, the kernel-mode verification unit will automatically trigger a rollback operation, switch the rule reading pointer back to the old mapping table, and report an update failure alarm to the management platform. The entire rollback process is also an uninterrupted operation and will not affect the normal operation of the business.

[0056] The entire update process does not require restarting the managed network software. The mounting state of the eBPF probe is completely decoupled from the running state of the network software, and the software process is unaware of it. There is no need to restart the kernel-mode verification service. The rule replacement is completed only through the mapping table update, and the service is running throughout the process. There is no business interruption. The atomic operation of rule switching takes nanoseconds. The verification latency of all business requests does not fluctuate significantly, which fully meets the continuity requirements of high-availability business scenarios such as finance and government.

[0057] In a cluster deployment scenario, after the user-mode management unit completes the local rule update, it will synchronize the valid status identifier and authorized function code hash digest corresponding to the new license to all collaborative deployment nodes through the cluster's two-way authentication channel, triggering a full cluster synchronization update. The management platform can monitor the update progress of all nodes in real time, ensuring that the authorization rules of all nodes in the cluster take effect at the same time, avoiding business access anomalies caused by inconsistencies in cross-node authorization rules. All operations in the entire update process, including the triggering reason, license version, operation time, update result, and operator identifier, will be written into an immutable audit log and uploaded to the management platform's audit center periodically, meeting compliance requirements such as the Information Security Law 2.0 and the Data Security Law.

[0058] In this invention, when the management platform generates an encrypted license, it first receives a set of node hardware features reported by the user-mode management unit of the node to be authorized. The set of hardware features includes at least two of the following: CPU serial number, network card MAC address, and motherboard serial number. After the management platform performs a uniqueness check on the reported hardware features to exclude forged features, it uses the national cryptographic SM3 hash algorithm to perform a calculation on the set of hardware features to obtain a feature hash value. The feature hash value is used as a derivation factor of the encryption key and, together with the globally unique random salt value generated by the management platform, participates in the generation of the encryption key for the license, ensuring that the encryption key of each node is unique and cannot be reused.

[0059] In this invention, when the user-mode management unit synchronizes license status information with associated collaborative nodes within the cluster, it only synchronizes the valid status identifier of the license, the hash digest of the authorized function code set, and the update timestamp. It does not synchronize the complete encrypted license plaintext, decryption key, and license plaintext details. An anti-replay verification mechanism is added during the synchronization process. The receiver performs verification on the timestamp of the synchronized information. Synchronized information with a timestamp deviation exceeding a preset threshold is directly discarded to prevent the core license information from being leaked during the cluster synchronization process.

[0060] In this invention, after the eBPF probe is loaded, the kernel-mode verification unit first calculates the runtime hash value of the loaded probe file, compares the runtime hash value with the standard hash value of the probe pre-issued by the management platform, and performs verification. Only after the verification is passed can the probe be mounted to the corresponding kernel trace point. Probes that fail the verification are directly discarded by the kernel-mode verification unit, and at the same time, an abnormal alarm is triggered and reported to the management platform to prevent the loading and running of probes that have not passed the integrity verification, thus preventing maliciously tampered probes from bypassing the authorization verification logic.

[0061] In this invention, when the kernel-mode verification unit performs legality verification, it first extracts the file hash value of the network software process that initiated the request, performs a signature verification operation with the file hash value and the pre-stored SM2 public key of the software publisher, and matches whether the process signature belongs to the preset legal process whitelist. If the process signature verification fails, all operation requests of the process are directly blocked, and the process is frozen to prevent the illegal process that has been tampered with from running.

[0062] In this invention, after the process signature verification passes, the kernel-mode verification unit first matches whether the function code corresponding to the current request belongs to the set of authorized function codes recorded in the license, then verifies whether the system time corresponding to the current request is within the authorized valid time interval recorded in the license, and finally verifies whether the source IP address and destination IP address corresponding to the request belong to the authorized IP whitelist recorded in the license. Only after all three verifications pass can the corresponding request be allowed. Requests that pass the verification will be marked as legitimate by the kernel, and no secondary verification is required during subsequent kernel network stack processing.

[0063] In this invention, the evidence log generated by the kernel-mode verification unit is stored after symmetric encryption using the national cryptographic SM4 algorithm. The log content includes at least the request trigger time, the unique identifier of the requesting process, the request function code, the request network five-tuple information, the interception reason, and the unique hardware identifier of the node. The log is stored in append mode, and it is forbidden to modify or delete the written log content. Only the corresponding decryption private key held by the control platform can decrypt and read the log content. The decrypted log can be directly used as valid evidence for network security compliance audit.

[0064] In this invention, for offline deployment scenarios involving classified private networks and without public network connections, the management platform supports offline export of encrypted licenses. The exported encrypted licenses are pre-bound to the hardware feature set of the nodes to be deployed and stored in an encrypted compressed package format. Authorized personnel can only import the encrypted licenses into the user-mode management unit of the corresponding node through offline storage media after completing identity verification by holding an identity authentication UKey, thus completing the deployment and update of the licenses. The entire process does not require a connection to the public network, meeting the security requirements of highly classified scenarios.

[0065] In this invention, the user-mode control unit periodically performs SM3 hash verification on the encrypted licenses stored in the local trusted storage area at preset time intervals. The calculated real-time hash value is compared with the standard hash value stored after the first successful verification. If the comparison is inconsistent, it is determined that the license has been tampered with. The user-mode control unit immediately triggers the local license invalidation mechanism and sends an authorization invalidation command to the kernel-mode verification unit. After receiving the command, the kernel-mode verification unit immediately switches to full interception state, intercepting all outbound requests from the network software on the node, and triggers an alarm notification from the control platform.

[0066] In this invention, the management and control platform supports group management of deployed nodes according to three dimensions: cluster group, business type, and department. Encryption licenses can be generated in batches for multiple nodes in the same group. When generating in batches, the authorization validity period, authorization function scope, and IP whitelist rules can be uniformly configured. When distributing in batches, it supports breakpoint resume and automatic retry, eliminating the need for maintenance personnel to perform operations on each node, and significantly reducing the cost of authorization management and maintenance in large-scale cluster deployment scenarios.

[0067] refer to Figure 1 This diagram illustrates the complete security control loop from the management platform to the endpoints. The process begins with the management platform collecting information on the deployment scenario and hardware characteristics, followed by generating and encrypting licenses. On the endpoint side, the user-space management unit is responsible for verifying the integrity of the licenses and ensuring their trusted storage, while also synchronizing the status with other nodes in the cluster. The kernel-space verification unit is responsible for loading eBPF probes and performing deep system call interception. When the software is running, the probes capture all network and function requests for real-time verification; legitimate requests are allowed, while illegitimate requests are intercepted at the protocol stack level and logged. Finally, the system uses a hot update mechanism to ensure that authorization changes are completed without interrupting business operations.

[0068] refer to Figure 2 This diagram details the construction and distribution logic of the license on the management platform. First, the platform receives hardware characteristics such as CPU and network card information reported by nodes, and derives a unique encryption key using a hash algorithm and random salt value, ensuring a strong binding between the license and the physical hardware. Next, the platform generates plaintext containing function codes, time intervals, and hardware bindings according to preset rules, and then generates ciphertext using a hybrid encryption algorithm combining Chinese national cryptographic standards SM2 and SM4. Finally, the encrypted license is distributed to the user-space management unit via a two-way TLS 1.3 secure channel. This process ensures the privacy and immutability of the authorization certificate during transmission.

[0069] refer to Figure 3This diagram illustrates the startup and environment preparation process of the kernel-mode verification unit. Upon receiving control commands, the system first loads the pre-compiled eBPF probe file and immediately performs a runtime hash comparison. Only probes that pass the integrity verification are mounted. The mount points cover core kernel functions such as network binding, connection, transmission, and process execution. Simultaneously, the kernel-mode unit reads and decrypts the license ciphertext from the Trusted Local Execution Environment (TEE). In this way, the verification logic is deeply embedded in the operating system kernel, improving the stealth of monitoring and protecting the core authorization rules from unauthorized reading by user-mode programs using hardware isolation technology.

[0070] refer to Figure 4 This diagram illustrates the multi-level filtering logic during software runtime. When the eBPF probe captures a system request, it first performs process signature verification to ensure the initiator is a legitimate whitelisted program. Subsequently, it performs three levels of business verification: first, it checks if the function code is within the authorized scope; second, it verifies if the current system time is valid; and third, it checks if the source and destination IPs of the accessed request conform to the whitelist. Only if all verifications pass will the request be marked as legitimate and allowed to proceed. Failure of any verification will cause the request to be directly discarded in the kernel protocol stack and trigger the asynchronous encrypted upload of the evidence log, achieving high-performance, low-latency security control.

[0071] refer to Figure 5 This diagram illustrates the dynamic maintenance mechanism in a large-scale cluster environment. The user-space management unit synchronizes only the license digest and status identifier through a two-way authentication channel, coupled with anti-replay timestamp verification, ensuring consistent cluster authorization status while preventing core key leakage. When authorization changes, the management platform issues a new license, and the node triggers an eBPF hot update after completing self-checks. Utilizing the dynamic replacement mechanism, new verification rules take effect directly in the kernel without restarting network software or kernel services, achieving zero interruption at the business level and significantly reducing system maintenance costs.

[0072] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for network software security management, characterized in that, Includes the following steps: The management and control platform generates an encrypted license carrying the scope of authorized functions, validity period, and node hardware feature binding information based on the deployment scenario of the network software to be authorized and the business attributes of the authorized object. The license is then sent to the user-mode management and control unit of the corresponding deployment node through an encrypted transmission channel. The user-mode management unit performs hash integrity verification on the received encryption license. After the verification is successful, the encryption license is stored in the local trusted storage area, and the validity status information of the license is synchronized to all associated collaborative deployment nodes in the cluster through the two-way authentication channel. The kernel-mode verification unit loads the pre-compiled eBPF probe, attaches the probe to the corresponding trace points of the kernel's network system calls and process function triggers, and reads the encryption license information in the local trusted storage area to complete the verification initialization. The kernel-mode verification unit captures all network interaction requests and function call operations initiated by the network software in real time through the eBPF probe, performs legality verification based on the read license information, directly intercepts requests that fail verification, and generates an immutable evidence log that is uploaded to the management platform. When a license expires or its authorization is adjusted, the management platform will issue the updated encryption license to the user-mode management unit, which will then perform a hot update. The update process does not require restarting the network software or the kernel-mode verification unit.

2. The network software security management method according to claim 1, characterized in that, When the management platform generates an encrypted license, it first collects at least two types of hardware features from the CPU serial number, network card MAC address, and motherboard serial number of the node to be authorized and performs a hash operation. The result of the operation is used as a derived factor of the encryption key to participate in the license encryption.

3. The network software security management method according to claim 1, characterized in that, When the user-mode management unit synchronizes license status information, it only synchronizes the valid status identifier of the license and the hash value of the authorized function scope, and does not synchronize the complete license plaintext or encryption key information.

4. The network software security management method according to claim 1, characterized in that, After the eBPF probe is loaded, the kernel-mode verification unit performs a hash check on the probe's integrity. Only probes that pass the integrity check can be mounted to the corresponding tracking point. Probes that fail the integrity check are prohibited from being loaded and run.

5. The network software security management method according to claim 1, characterized in that, When the kernel-mode verification unit performs a validity check, it first checks whether the process signature of the network software matches the preset whitelist. If the process signature verification fails, all operation requests of that process are directly blocked.

6. The network software security management method according to claim 5, characterized in that, After the process signature verification passes, the kernel-mode verification unit further verifies whether the function requested by the current user is within the scope of the license and whether the request time is within the validity period of the license. The request can only be released if both verifications pass.

7. A network software security management method according to claim 1, characterized in that, The evidence log generated by the kernel-mode verification unit is encrypted using the national cryptographic algorithm and then stored. The log content includes the request time, request process identifier, request content, and reason for interception. The log can only be read by the management platform that holds the corresponding decryption key.

8. A network software security management method according to claim 1, characterized in that, For offline deployment scenarios involving classified private networks, the management platform supports offline export of encrypted licenses, which can be imported by authorized personnel into the user-space management unit of the corresponding node via offline storage media to complete the license deployment and update.

9. A network software security management method according to claim 1, characterized in that, When the user-mode control unit detects that the license stored locally has been tampered with, it immediately triggers the local invalidation mechanism, notifying the kernel-mode verification unit to switch to the interception state and intercept all outbound requests from the network software on that node.

10. A network software security management method according to claim 1, characterized in that, The management platform can generate and distribute encrypted licenses in batches for multiple nodes in the cluster. When adjusting authorization rules in batches, it supports unified push without the need to operate on each node individually.

Images