Multi-algorithm dynamic encryption paperless conference file protection method

Abstract

The invention relates to the field of data encryption, and provides a multi-algorithm dynamic encryption paperless conference file protection method, which comprises the following steps: acquiring environmental parameters of terminal equipment in real time, the environmental parameters comprising network delay, CPU load and battery power; respectively processing the network delay, the CPU load and the battery power to obtain a network delay weight coefficient, a CPU load weight coefficient and a battery power weight coefficient; performing dynamic weight fusion on the network delay weight coefficient, the CPU load weight coefficient and the battery electric quantity weight coefficient to obtain a decision value D; determining a corresponding encryption algorithm according to the decision value D; and based on the corresponding encryption algorithm, carrying out encryption processing on the paperless conference file. According to the environment perception parameters, collected in real time, of the terminal equipment, different encryption algorithms are dynamically selected to encrypt the conference file, and compared with a traditional method using a single fixed encryption algorithm, the method is safer.

Description

Technical Field

[0001] The present invention relates to the field of data encryption, and more particularly to a paperless conference file protection method with multi-algorithm dynamic encryption. Background Art

[0002] With the rapid development of digital office, paperless conferencing systems have become the mainstream method of meeting management in modern enterprises. According to statistics, the penetration rate of paperless conferencing systems reached 78% in 2023, but the number of conference data leaks increased by 210% year-on-year during the same period, highlighting the urgent need to protect conference documents.

[0003] The traditional encryption method is to use a single algorithm to encrypt meeting files and adopt static key management. Among them, the use of a single algorithm cannot resist targeted attacks; and the use of static key management lacks a dynamic key generation mechanism based on meeting characteristics; and the environmental adaptability is poor. Summary of the Invention

[0004] The present invention aims to solve the technical problems existing in the prior art and provides a paperless conference file protection method with multi-algorithm dynamic encryption to improve the security of data encryption.

[0005] The present invention provides a paperless conference document protection method with multi-algorithm dynamic encryption, comprising:

[0006] Acquire environmental parameters of the terminal device in real time, including network latency, CPU load, and battery power;

[0007] Processing the network delay, the CPU load, and the battery power respectively to obtain a network delay weight coefficient, a CPU load weight coefficient, and a battery power weight coefficient;

[0008] Dynamically weighting the network delay weight coefficient, the CPU load weight coefficient, and the battery power weight coefficient to obtain a decision value D;

[0009] Determine the corresponding encryption algorithm according to the decision value D;

[0010] The paperless conference documents are encrypted based on the corresponding encryption algorithm.

[0011] The present invention provides a paperless conference document protection method with multi-algorithm dynamic encryption, which obtains the environmental parameters of the terminal device in real time, wherein the environmental parameters include network delay, CPU load and battery power; the network delay, CPU load and battery power are processed respectively to obtain a network delay weight coefficient, a CPU load weight coefficient and a battery power weight coefficient; the network delay weight coefficient, the CPU load weight coefficient and the battery power weight coefficient are dynamically weighted to obtain a decision value D; according to the decision value D, a corresponding encryption algorithm is determined; and based on the corresponding encryption algorithm, the paperless conference document is encrypted. The present invention dynamically selects different encryption algorithms to encrypt conference documents based on the environmental perception parameters of the terminal device collected in real time, which is more secure than the traditional use of a single fixed encryption algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A flowchart of a paperless conference document protection method using multi-algorithm dynamic encryption provided by one embodiment of the present invention;

[0013] Figure 2 An overall flow chart of a paperless conference document protection method with multi-algorithm dynamic encryption provided by one embodiment of the present invention;

[0014] Figure 3 A schematic diagram of obtaining network delay according to an embodiment of the present invention. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be arbitrarily combined with each other to form a feasible technical solution. This combination is not restricted by the sequence of steps and / or structural composition mode, but must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0016] Figure 1 Provides a paperless conference document protection method with multi-algorithm dynamic encryption, see Figure 1 and Figure 2 , the method comprising:

[0017] Step 1: Acquire the environmental parameters of the terminal device in real time, including network delay, CPU load and battery power.

[0018] It is understandable that when a conversation is conducted between a terminal device and a server, three sets of parameters of the terminal device, namely, network delay, CPU load, and battery power, are collected in real time.

[0019] Network latency, τ, is the round-trip time (RTT) between the sending and receiving of a data packet, reflecting the real-time state of network congestion. Terminal devices send probe packets (ICMP / UDP) with nanosecond timestamps, recording the packet sending time (T1) and the packet receiving time (T2). The raw round-trip latency (RTT) is calculated as T2 - T1. After median filtering and sigmoid normalization, the network latency weight α∈[0,1] is output.

[0020] The network delay τ is collected through hardware-level timestamps, see Figure 3 The process of collecting network delay τ using hardware-level timestamps includes:

[0021] (1) Sending a probe packet:

[0022] The encryption terminal device sends an ICMP / UDP probe packet with a hardware timestamp T1 (recorded to nanoseconds by the IEEE1588 protocol of the network card) to the conference server through the network card NIC. Two types of probe packets are supported:

[0023] ICMP Ping: general scenarios, strong compatibility;

[0024] UDP probe packet: In high-security scenarios, the encrypted payload can be customized to prevent ICMP from being intercepted by firewalls.

[0025] (2) Receive response packet:

[0026] The response packet is the key data packet returned by the server to the terminal device. It is the server's encrypted response to the terminal detection packet. The basic structure is shown in Table 1 below:

[0027] Table 1

[0028]

[0029] When receiving the response packet, the terminal device verifies the response packet according to the following rules:

[0030] Use CRC to check data packet integrity;

[0031] Use magic number check to filter out illegal traffic (such as network noise);

[0032] Use ECDSA-P256 over SHA-256 digital signature algorithm to reject forged or tampered responses;

[0033] Perform time verification to prevent time reversal attacks: ensure T1 < T1' < T2' < T2;

[0034] Check the sequence number to ensure that the data packet is within the sliding window and is not repeated.

[0035] The steps for obtaining the network delay τ include:

[0036] (1) Calculate the initial RTT:

[0037] Clock offset calibrated according to NTP / PTP protocol to eliminate server processing delay:

[0038] ;

[0039] in:

[0040] T1: the time when the terminal originally sends the detection packet;

[0041] T2: the time when the terminal receives the response packet;

[0042] T1': the time when the server receives the detection packet;

[0043] T2': the time when the server sends the response packet;

[0044] T2'-T1': Server processing time (normally should be <0.5ms).

[0045] (2) Perform median filtering on the initial RTT:

[0046] The network delay data is processed by median filtering to reduce noise and outliers in the data and improve the accuracy and stability of delay estimation.

[0047] Select an appropriate median filter window size based on the data characteristics and filtering requirements. The window size is typically expressed as the number of data points included. For example, a window size of 5 means that each processing step considers the current data point and the two adjacent data points before and after it. Generally speaking, a larger window size results in a more pronounced filtering effect, but may also reduce the real-time nature of the data and cause loss of detailed information. A smaller window size may result in less noise suppression but better preserves the short-term characteristics of the data.

[0048] Median filter anti-jitter:

[0049] ;

[0050] N represents window selection, which supports two types:

[0051] General scenario: N=3 (real-time priority);

[0052] High-security scenario: N=5 (prioritizes noise immunity).

[0053] The CPU load (ρ) collection process includes:

[0054] When collecting CPU load data, it is necessary to support both general scenarios and high-security scenarios.

[0055] In common scenarios, the CPU load collection process includes:

[0056] (1) Data source:

[0057] In common scenarios, global CPU utilization statistics are mainly provided by the operating system.

[0058] The Linux system parses the / proc / stat file, and the Windows system calls the GetSystemTimes() API.

[0059] (2) Calculation formula:

[0060] ;

[0061] in:

[0062] ΔIdle: the idle time difference between two adjacent samplings;

[0063] Δtotal: Total time increment.

[0064] In high-security scenarios, the CPU load collection process includes:

[0065] (1) Data source:

[0066] In high-security scenarios on the x86 architecture, CPU load data must be obtained by directly reading the hardware performance monitoring registers. The following registers are read using the assembly instruction RDMSR (Read Model-Specific Register):

[0067] IA32_APERF (register address 0xE8): records the number of clock cycles actually run by the CPU (excluding shutdown, frequency reduction and other states);

[0068] IA32_MPERF (register address 0xE7): records the maximum theoretical number of clock cycles of the CPU at the nominal frequency.

[0069] (2) Calculation formula:

[0070] ;

[0071] in:

[0072] represents the temperature compensation term;

[0073] =0.05% / ℃ (temperature compensation coefficient);

[0074] : Current CPU temperature, collected from a digital temperature sensor (such as DTS);

[0075] =65℃ (nominal temperature threshold);

[0076] ;

[0077] in:

[0078] : The actual number of effective clock cycles (excluding the shutdown / reduction state), from the IA32_APERFMSR register;

[0079] : The baseline APERF value when the system is no-load, the average value measured after 5 minutes of no-load after startup;

[0080] : Maximum theoretical number of clock cycles (at nominal frequency), from the IA32_MPERF MSR register;

[0081] :Baseline MPERF value when the system is unloaded, and Synchronous acquisition.

[0082] The process of collecting battery power (E) is as follows:

[0083] In general scenarios:

[0084] (1) Read directly through the operating system API:

[0085] Android system: Get it by calling BatteryManager.EXTRA_LEVEL;

[0086] Linux system: Read the power percentage directly through / sys / class / power_supply / BAT* / capacity.

[0087] (2) Moving average filtering:

[0088] Filtering is required to eliminate power jumps (such as instantaneous plugging and unplugging of a charger). In general scenarios, the moving average filtering method is selected. The calculation formula is as follows:

[0089] ;

[0090] in:

[0091] The power value after filtering at the current moment;

[0092] The original power value currently collected;

[0093] It is the power value after filtering at the previous moment;

[0094] The weight coefficient of historical electricity value is 0.9, and stability is prioritized.

[0095] In high-security scenarios:

[0096] (1) Power Management IC (PMIC) direct reading:

[0097] Read a battery fuel gauge (such as the MAX17048) via the I²C bus.

[0098] (2) Weighted recursive filtering:

[0099] In high-security scenarios, the weighted recursive filtering method is selected. The calculation formula is as follows:

[0100] ;

[0101] in, is the weight of the historical electricity data at time ti, n is the amount of historical electricity data, satisfying ;

[0102] Typical weight distribution of different historical battery power data (taking 5-point filtering as an example) is shown in Table 2:

[0103] Table 2

[0104] Time offset Weight wi effect Et 0.4 Current value dominant Et−1 0.3 Recent data Et−2 0.15 Suppress high-frequency noise Et−3 0.1 Keep trend memory Et−4 0.05 Preventing overfitting

[0105] Step 2: Process the network delay, the CPU load, and the battery power respectively to obtain a network delay weight coefficient, a CPU load weight coefficient, and a battery power weight coefficient.

[0106] It is understandable that the above step 1 obtains the network delay, CPU load and battery power of the terminal device collected in real time, and normalizes them respectively to obtain the corresponding weight coefficients.

[0107] The core purpose of normalizing network delay (τ) is to convert the original delay data into a standardized decision weight. The delay τ is mapped to the [0, 1] interval through the Sigmoid function to generate the standardized weight α:

[0108] ;

[0109] in:

[0110] =0.1: Adjust the slope (default value), used to control the sensitivity of the function. The larger the value, the more sensitive it is to delay changes.

[0111] =100ms: baseline delay threshold.

[0112] The normalization of CPU load is divided into normalization of CPU load in general scenarios and high-security scenarios, and the standard decision weight β is:

[0113] (1) In general scenarios, linear segmentation is used to achieve normalization, and the formula is as follows:

[0114] ;

[0115] Here, 30% is the load safety lower limit; a value below this is considered idle. 80% is the overload protection threshold, the critical load point for most CPU schedulers; exceeding this value triggers a downgrade strategy. 50 is the normalized denominator, controlling the linear mapping of the 30% → 80% interval to [0, 1]. This formula enforces the constraint β∈[0, 1] to prevent extreme values ​​from influencing decision making.

[0116] (2) In high-security scenarios, the Sigmoid function is used for normalization, and the formula is as follows:

[0117] ;

[0118] in:

[0119] : Actual load after temperature compensation;

[0120] k: Curve steepness control, generally set to 0.15, which can be dynamically adjusted according to the real-time threat to the system;

[0121] : Load decision center point (load value corresponding to β=0.5).

[0122] Among them, through normalization processing, the system converts the battery power E into the standard decision weight γ:

[0123] (1) In general scenarios, direct linear mapping is used to achieve normalization, and the calculation formula is as follows:

[0124] .

[0125] (2) The normalized calculation formula in a high-security scenario is:

[0126] ;

[0127] in:

[0128] 0.3: minimum weight guarantee (maintaining basic security even if the battery runs out);

[0129] 0.2: adjust the steepness of the curve;

[0130] 20: Battery warning threshold (%).

[0131] Step 3: Dynamically weight the network delay weight coefficient, the CPU load weight coefficient, and the battery power weight coefficient to obtain a decision value D.

[0132] It can be understood that dynamic algorithm selection is a quantitative assessment of real-time environmental parameters (network delay weight coefficient α, CPU load weight coefficient β, battery power weight coefficient γ). By establishing a decision model, weight fusion and threshold judgment, the encryption algorithm that best suits the current device status is automatically selected. Its core goal is to achieve a dynamic balance between security and performance.

[0133] The normalized network delay weight coefficient α, CPU load weight coefficient β, and battery power weight coefficient γ are fused according to fixed weights to obtain the decision value D: ;

[0134] Weight distribution is based on: network latency and CPU load dominate performance (40% each), and battery power affects device battery life (20%).

[0135] Step 4: Determine the corresponding encryption algorithm based on the decision value D.

[0136] It is understandable that see Figure 2 , according to the decision value D, assign the corresponding encryption algorithm:

[0137] ;

[0138] in:

[0139] AES-256-GCM (D < 0.4): Suitable for low latency (τ < 80ms), low load (ρ < 50%), and high power (E > 60%) scenarios;

[0140] SM4-CTR (0.4 ≤ D < 0.7): Suitable for medium resource conditions;

[0141] ChaCha20-Poly1305 (D ≥ 0.7): for high latency (τ > 150ms) or low battery (E < 20%).

[0142] Step 5: Encrypt the paperless conference documents based on the corresponding encryption algorithm.

[0143] It is understandable that after the encryption algorithm is determined according to the decision value D, the paperless conference documents are encrypted based on the encryption algorithm.

[0144] Specifically, dynamic key generation generates high-entropy seeds by combining a quantum random number generator, and integrates device fingerprints, real-time environmental parameters (such as network latency, CPU load) and session identifiers, using a hierarchical key derivation function (HKDF) to generate unique and temporary encryption keys, ensuring that independent keys are used for each session and even different stages of the same session; through timed forced updates and updates triggered by abnormal events (such as network mutations or attack detection), dynamic keys effectively prevent the risk of key reuse and resist brute force cracking and quantum computing attacks. At the same time, the forward security design ensures the confidentiality of historical sessions. Even a single key leak will not endanger the overall system security, thereby providing a real-time, adaptive and crack-resistant key management mechanism for paperless meetings.

[0145] The master key and session key form a hierarchical key system, where the master key Kmaster serves as the root key. The short-term session key Ksession is generated through the key derivation function (HKDF) combined with dynamic parameters. The logical relationship is as follows:

[0146] (1) Master key generation:

[0147] ;

[0148] in:

[0149] Seed: 256-bit true random number generated by quantum entropy source;

[0150] SaltM=Timestamp: nanosecond timestamp to prevent pre-calculation attacks;

[0151] InfoM="MasterKey": fixed identifier, isolating keys for different purposes;

[0152] L=384: The output length is compatible with AES-256 (256 bits) and SM4 (128 bits).

[0153] (2) Session key generation:

[0154] ;

[0155] in:

[0156] SaltS=MeetingID|RoundID: MeetingID represents the unique hash identifier of the conference (128 bits), and RoundID represents the time- or event-driven round counter (32 bits);

[0157] InfoS=AlgoType: Algorithm identifier (such as "AES-GCM"), ensuring that the key is bound to the algorithm;

[0158] L: Dynamically adapts to algorithm requirements (AES-256 → 256 bits, SM4 → 128 bits).

[0159] At this time, the master key is only used to derive the session key and does not directly participate in encryption; the session key is valid for a short period of time (5 minutes by default), and forward security ensures that even if Kmaster is leaked, K cannot be reversed. session or historical keys.

[0160] After generating session keys for various encryption algorithms, call the general encryption interface to encrypt the conference file according to the selected encryption algorithm. Specifically:

[0161] (1) AES-256-GCM (high performance mode):

[0162] If the AES-256-GCM encryption algorithm is used, the encryption execution calculation formula is:

[0163] ;

[0164] in:

[0165] P is the plain text, the original data that needs to be encrypted.

[0166] K session The session key is a 256-bit symmetric key used for AES-GCM encryption and is used only temporarily in the current session to enhance security.

[0167] IV: Initialization vector, used to ensure that the same plaintext generates different ciphertexts in different encryption processes. Here, IV is passed Generate, K prev Refers to the leading key, which is a long-term key or the key of the previous session, and is used to generate a unique IV in combination with t; t represents the timestamp, which is a dynamic value that ensures the uniqueness of the IV for each encryption.

[0168] (2) SM4-CTR (balanced mode):

[0169] If the national secret SM4 encryption algorithm is used, the encryption execution calculation formula is:

[0170] ;

[0171] in:

[0172] P is the plain text, the original data that needs to be encrypted.

[0173] K session The session key is a symmetric key used for SM4-CTR encryption. It is 128 bits and is used temporarily only in the current session to enhance security.

[0174] Nonce is a random number / initial value used to generate the initial value of the keystream in CTR mode. Here, the nonce consists of two parts: Chaos(t) and SessionID. Chaos(t) generates highly random and unpredictable values ​​based on the function of a chaotic system, leveraging the sensitivity and pseudo-random nature of chaotic systems to enhance the nonce's resistance to analysis. t represents a dynamic parameter (such as a timestamp, counter, or other real-time variable) to ensure that the input is unique for each encryption. SessionID is a unique identifier for the current session, ensuring that the nonce remains unique even if the same t value is used across different sessions. Combine dynamic random values ​​with session identifiers to ensure both uniqueness and anti-collision.

[0175] (3) ChaCha20-Poly1305 (low power mode):

[0176] Encryption execution calculation formula in low power mode:

[0177] ;

[0178] in:

[0179] ChaCha20(P, K session ) Encrypt the plaintext using the ChaCha20 stream cipher to ensure confidentiality. session Symmetric key used for ChaCha20 encryption, key length is usually 256 bits.

[0180] Poly1305-MAC(P, K auth ) An authentication tag generated by a Poly1305 message authentication code (MAC) to verify data integrity and authenticity. auth The independent key used for Poly1305-MAC has a fixed key length of 256 bits and is the same as K sessionSeparation ensures the independence of encryption and authentication keys, in line with the security principle of "key isolation".

[0181] After encrypting the conference file using a corresponding encryption algorithm, watermark information is embedded in the encrypted conference file. Embedding dynamic watermarks (such as the conference ID, user information, and timestamps) in conference documents allows the source of the leak to be tracked if the content is illegally disseminated. Dynamic watermarks change over time or context (e.g., each frame is different), making them difficult for attackers to remove or forge in bulk. Even if the content is screenshotted or recorded, the watermark retains critical tracking information. Dynamic watermarks are typically embedded using lightweight algorithms, which do not affect the real-time transmission of content.

[0182] The dynamic watermark embedding method of the present invention superimposes the watermark information onto the original content through exclusive OR (XOR) and shift operations. The calculation formula is:

[0183] ;

[0184] ;

[0185] in:

[0186] C: Original content, the carrier that needs to be embedded with the watermark.

[0187] MeetingID: Unique meeting identifier, which can be a number or a string. It is used to identify the current meeting or session, ensuring that the watermark is associated with a specific meeting for easy traceability.

[0188] CRC64 (MeetingID): Performs a CRC64 checksum calculation on the MeetingID to generate a 64-bit fixed-length hash value. CRC64 is a fast but non-cryptographically secure checksum algorithm suitable for real-time processing. The generated value serves as the "base" of the watermark to ensure that the watermarks of different MeetingIDs are significantly different.

[0189] t: dynamic time parameter, which is a timestamp. It ensures that the watermark changes over time and prevents fixed patterns from being cracked.

[0190] t mod 64: t is modulo 64, and the result range is between 0 and 63. Control the number of shift bits and recycle each bit of the 64-bit CRC value to ensure that the position of the watermark in the content changes dynamically.

[0191] Finally, for abnormal situations, such as three consecutive decryption failures or CPU temperature > 85°C, it is necessary to set a fuse mechanism and initiate emergency response measures. The specific steps are as follows:

[0192] 1) Immediately destroy the current session key:

[0193] memset(K session ,0,sizeof(K session ));

[0194] Among them, sizeof(K session ) represents the size of the session key, which is used to store the session key (K session ) is reset to zero in order to securely erase sensitive data and prevent keys from remaining in memory and being stolen by malicious programs or attackers.

[0195] 2) Generate an emergency key:

[0196] ;

[0197] in:

[0198] Kemergency: Derived emergency key, the final generated key, used in emergency scenarios (such as data recovery or permission overwriting when the master key expires).

[0199] : An HMAC-based key derivation function used to securely generate one or more keys from a master key. Salt="Fuse" specifies a fixed salt value and is marked for emergency use. L outputs the key length, defining the number of bits of the generated emergency key. Kemergency must comply with security standards (e.g., AES-256 requires a 256-bit key).

[0200] 3) Isolate abnormal terminals and enable security audit logs.

[0201] The present invention provides a paperless conference document protection method with multi-algorithm dynamic encryption, comprising: acquiring environmental parameters of a terminal device in real time, the environmental parameters including network delay, CPU load, and battery power; processing the network delay, CPU load, and battery power respectively to obtain a network delay weight coefficient, a CPU load weight coefficient, and a battery power weight coefficient; dynamically weight-fusing the network delay weight coefficient, the CPU load weight coefficient, and the battery power weight coefficient to obtain a decision value D; determining a corresponding encryption algorithm based on the decision value D; and encrypting the paperless conference document based on the corresponding encryption algorithm. The present invention dynamically selects different encryption algorithms to encrypt conference documents based on the environmental perception parameters of the terminal device collected in real time, which is more secure than the traditional method of using a single fixed encryption algorithm.

[0202] It should be noted that, in the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0203] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0204] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0205] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0206] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0207] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0208] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A paperless conference document protection method with multi-algorithm dynamic encryption, characterized in that: include: Acquire environmental parameters of the terminal device in real time, including network latency, CPU load, and battery power; Processing the network delay, the CPU load, and the battery power respectively to obtain a network delay weight coefficient, a CPU load weight coefficient, and a battery power weight coefficient; Dynamically weighting the network delay weight coefficient, the CPU load weight coefficient, and the battery power weight coefficient to obtain a decision value D; Determine the corresponding encryption algorithm according to the decision value D; The paperless conference documents are encrypted based on the corresponding encryption algorithm.

2. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: The real-time acquisition of environmental parameters of the terminal device includes: Obtain the network delay τ between the terminal device sending data and receiving data; The obtaining of the network delay τ between the terminal device sending data and receiving data includes: Get the initial network delay RTT of the terminal device: ； Where T1 represents the time when the terminal device originally sends the detection packet; T2 represents the time when the terminal device receives the response packet; T1' represents the time when the server receives the detection packet; T2' represents the time when the server sends the response packet; T2'-T1' represents the server processing time; The initial network delay RTT is subjected to median filtering based on the median filtering window to obtain the network delay τ of the terminal device: ； Where N represents the number of windows. In general scenarios, N=3; in high-security scenarios, N=5. Process the network delay τ to obtain the network delay weight coefficient ,include: ； Where, represents the adjustment slope, is the baseline latency threshold.

3. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: The real-time acquisition of environmental parameters of the terminal device includes: In common scenarios, obtain global CPU load data through the operating system: ； in, Indicates the idle time difference between two adjacent samplings of CPU load data. Δtotal indicates the total time of collecting CPU load data, which is read through the Linux kernel. and Δtotal; In high-security scenarios, CPU load data is obtained by reading hardware performance monitoring registers, including: ； Where, represents the temperature compensation term, is the current temperature of the CPU collected, is the nominal temperature threshold, is the temperature compensation coefficient; ； Where: The actual number of effective clock cycles comes from the value of the IA32_APERF MSR register; It is the baseline APERF value when the system is unloaded; The maximum theoretical number of clock cycles comes from the value of the IA32_MPERF MSR register; is the baseline MPERF value when the system is unloaded, and Synchronous acquisition; CPU load data Processing is performed to obtain the CPU load weight coefficient β, including: In general scenarios, CPU load data The formula for normalization is: ； In high security scenarios, CPU load data is used The formula for normalization is: ； Where, is the load decision center point, is the steepness of the curve, is the actual load after temperature compensation.

4. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: The real-time acquisition of environmental parameters of the terminal device includes: In general scenarios, the original power value of the terminal device is obtained through the operating system; The power value of the terminal device after filtering is obtained based on the moving average filtering process: ； in: is the filtered power value at the current moment, is the original power value currently collected, is the filtered power value at the previous moment, is the weight coefficient of historical electricity value; In a high-security scenario, the power value is read through the I²C bus and processed using a weighted recursive filtering method to obtain the filtered power value: ； in, is the weight of the historical electricity data at time ti, n is the amount of historical electricity data, satisfying ; Process the battery power value to obtain the battery power weight coefficient ,include: In general scenarios, the battery power weight coefficient The calculation formula is: ； In high-security scenarios, the battery power weight coefficient The calculation formula is: 。 5. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: The dynamically weighted fusion of the network delay weight coefficient, the CPU load weight coefficient, and the battery power weight coefficient to obtain a decision value D includes: ； in, is the network delay weight coefficient, is the CPU load weight coefficient, is the battery power weight coefficient.

6. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: Determining a corresponding encryption algorithm according to the decision value D includes: ； in, Represents an algorithm.

7. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: The encryption processing of the paperless conference document based on the corresponding encryption algorithm includes: Generate a session key corresponding to the encryption algorithm; Based on the corresponding session key, the paperless conference file is encrypted using the corresponding encryption algorithm to obtain an encrypted conference file; Generating a session key corresponding to the encryption algorithm includes: Based on the hierarchical key derivation function HKDF, the master key Kmaster is generated: ； Where Seed represents a 256-bit true random number generated by a quantum entropy source; It is a nanosecond timestamp; = "MasterKey" is the master key identifier; L is the output length of the master key; According to the master key, conference identifier and algorithm identifier, a session key is generated based on the hierarchical key derivation function HKDF: ； Among them, Salt S =MeetingID|RoundID: MeetingID represents the unique hash identifier of the conference, and RoundID represents a time- or event-driven round counter; Info S =AlgoType indicates the algorithm identifier; L is the output length of the session key.

8. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 7 is characterized in that: The paperless conference file is encrypted using a corresponding encryption algorithm based on the corresponding session key to obtain an encrypted conference file, including: If the AES-256-GCM encryption algorithm is used, the encryption execution calculation formula is: ； in: P is the plain text, conference document that needs to be encrypted; K session is the session key; IV is the initialization vector, IV is passed Generate, K prev refers to the leading key, which is a long-term key or the key of the previous session, and is used to generate a unique IV in combination with t; t represents the timestamp; If the national secret SM4 encryption algorithm is used, the encryption execution calculation formula is: ； in: P is the plain text, conference document that needs to be encrypted; K session is the session key; Nonce is a random number / initial value; Nonce is composed of two parts: Chaos(t) and SessionID. Chaos(t) is a function based on the chaotic system, t represents a dynamic parameter, and SessionID represents the unique identifier of the current session. Combine a dynamic random value with a session identifier; Encryption execution calculation formula in low power mode: ； in: ChaCha20(P, K session ) The ciphertext generated by encrypting the plaintext with the ChaCha20 stream cipher, K session Symmetric key for ChaCha20 encryption, Poly1305-MAC (P, K auth ) Authentication tag generated by Poly1305 message authentication code MAC, K auth The independent key used for Poly1305-MAC has a fixed key length of 256 bits. session Separation.

9. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: The method further includes embedding a dynamic watermark in the encrypted conference file after encrypting the paperless conference file based on the corresponding encryption algorithm: The watermark information is added to the encrypted conference file through XOR and bit shift operations. The calculation formula is: ； ； in: C is the encrypted conference document, which needs to be embedded with a watermark. The conference document after embedding the watermark; MeetingID is the unique identifier of the meeting; CRC64(MeetingID) performs a CRC64 checksum calculation on the MeetingID to generate a 64-bit fixed-length hash value. CRC64 is a non-cryptographically secure checksum algorithm. t is the timestamp; t mod 64 takes the modulus of 64 for t, and the result range is between 0 and 63, which controls the number of shift bits.

10. The paperless conference document protection method with multi-algorithm dynamic encryption according to claim 1 is characterized in that: After encrypting the paperless conference document based on the corresponding encryption algorithm, the method further includes setting a fuse mechanism during the decryption process to initiate emergency response measures if the decryption fails continuously or the CPU temperature exceeds a preset temperature threshold: immediately destroying the current session key, including: Among them, memset(K session ,0,sizeof(K session )) is used to store the session key K session The memory area is all set to zero, sizeof(K session ) represents the size of the session key; The generating of the emergency key comprises: ； in: K emergency A derived emergency key used in emergency scenarios; is the key derivation function, The primary key, Salt="Fuse" is a fixed salt value, marked for emergency use; L is the length of the emergency key; Isolate abnormal terminal devices and enable security audit logs.

Images