Information Security Transmission Methods and Systems for Multi-Terminal Online Paperless Meetings

Abstract

This invention discloses a method and system for secure information transmission in multi-terminal online paperless meetings, relating to the field of data transmission technology. The method includes: S1, the server divides the meeting document into encrypted fragments according to agenda items and pre-distributes them to each tablet terminal. The encrypted fragments are protected based on a chaotic system and threshold cryptography; S2, each tablet terminal constructs a rendering decision graph based on the rendering instruction stream and extracts a rendering fingerprint. The nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of the rendering instructions; S3, each tablet terminal calculates the similarity of its own rendering fingerprint with that of other tablet terminals and executes a consensus protocol based on the rendering fingerprint similarity; S4, a health index is generated based on the execution result, and the health index feeds back the evolution parameters of the modulated chaotic system; S5, during the execution of an agenda item, each tablet terminal collects encrypted fragments that meet a threshold number to reconstruct the key and decrypt the local document. When the agenda item ends, the reconstructed key and fragments are deleted.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and more specifically, to a method and system for secure information transmission in multi-terminal online paperless meetings. Background Technology

[0002] With the deepening of digital transformation, online paperless meeting systems have become an indispensable collaborative infrastructure in high-frequency scenarios such as financial transactions and corporate strategic communication. These systems significantly improve cross-regional communication efficiency and reduce the management costs and environmental pressures associated with paper document circulation by integrating digital distribution of meeting materials, real-time audio and video interaction, and collaborative operation. However, with the widespread circulation of meeting data in the network environment, its integrity and availability face increasingly severe challenges. How to build a data transmission protection system suitable for high-security scenarios while ensuring user experience has become a core issue that urgently needs to be addressed in the development of current online meeting systems.

[0003] While existing online conferencing solutions have implemented basic security measures such as encrypted transmission and identity authentication, significant technical shortcomings remain. Most systems employ static keys or fixed-period key management mechanisms, making it difficult to dynamically adjust encryption strategies based on factors such as the sensitivity of the meeting and changes in the participating terminal environments. Once keys are leaked or terminals are attacked, large-scale decryption of meeting data can occur.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method and system for secure information transmission in multi-terminal online paperless meetings to solve the above-mentioned technical problems.

[0006] This application provides a method for secure information transmission in multi-terminal online paperless meetings, comprising: S1, the server segments the meeting document into encrypted fragments according to agenda items and pre-distributes them to each tablet terminal, wherein the encrypted fragments are protected based on a chaotic system and threshold cryptography; S2, each tablet terminal constructs a rendering decision graph based on the rendering instruction stream and extracts a rendering fingerprint, wherein the nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of the rendering instructions; S3, each tablet terminal calculates the similarity of its own rendering fingerprint with that of other tablet terminals, and executes a consensus protocol based on the similarity of the rendering fingerprint; S4, a health index is generated based on the execution result, wherein the health index feeds back the evolution parameters of the chaotic system; S5, during the execution of an agenda item, each tablet terminal collects encrypted fragments that meet a threshold number to reassemble the key and decrypt the local document, and deletes the reassembled key and fragments when the agenda item ends.

[0007] This application provides an information security transmission system for multi-terminal online paperless meetings, comprising: a pre-distribution unit, used by the server to segment meeting documents into encrypted fragments according to agenda items and pre-distribute them to each tablet terminal, wherein the encrypted fragments are protected based on a chaotic system and threshold cryptography; a construction unit, used by each tablet terminal to construct a rendering decision graph and extract rendering fingerprints based on rendering instruction streams, wherein the nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of rendering instructions; a consensus unit, used by each tablet terminal to calculate the similarity of its own rendering fingerprints with those of other tablet terminals, and execute a consensus protocol based on the similarity of the rendering fingerprints; a generation unit, used to generate a health index based on the execution results, wherein the health index provides feedback to modulate the evolution parameters of the chaotic system; and a processing unit, used by each tablet terminal to collect encrypted fragments that meet a threshold number to reconstruct the key and decrypt the local document during the agenda item process, and to delete the reconstructed key and fragments when the agenda item ends.

[0008] Based on the embodiments provided in this application, by dividing the meeting document into encrypted fragments according to agenda items and pre-distributing them to various tablet terminals, and employing a chaotic system and threshold cryptography for dual protection of the fragments, it is ensured that no single terminal can independently obtain the complete meeting document. Even if the terminal is subjected to a local cracking attack, the attacker can only obtain meaningless encrypted fragments and cannot recover the original content. The introduction of the chaotic system gives the encryption process dynamic evolution capabilities, making the fragment protection strategy no longer dependent on static algorithms, significantly increasing the difficulty of resisting reverse analysis and brute-force attacks, and providing reliable security for the document pre-distribution stage in highly sensitive meeting scenarios. A rendering decision graph is constructed based on the rendering instruction stream, and rendering fingerprints are extracted. By calculating the similarity of rendering fingerprints between terminals and executing a consensus protocol, consistency verification of terminal rendering behavior is achieved. This mechanism does not rely on additional hardware or centralized verification nodes, and can autonomously identify terminals with abnormal rendering behavior in a distributed terminal group, effectively preventing malicious tampering with document display content, forging viewport operations, or injecting false rendering instructions. The rendering decision graph uses nodes and edges to represent document elements and their rendering sequence relationships, which makes the rendering fingerprint highly unique and behaviorally bound, making it difficult to simulate or copy, thus constructing a reliable identity credential for terminal behavior.

[0009] A health index is generated based on the consensus execution results, and this index is used to provide real-time feedback on the evolution parameters of the modulated chaotic system, achieving dynamic linkage between encryption strength and meeting security status. When the consistency of rendering behavior among terminal groups decreases, the health index can adaptively adjust the initial state or iteration number of the chaotic system, thereby enhancing the anti-cracking capability of encrypted fragments; conversely, it maintains low computational overhead in a stable environment. This adaptive modulation mechanism makes the security strategy no longer rigid and fixed, but flexibly evolves with the actual operation of the meeting, balancing high-strength protection and a smooth meeting experience. During the agenda items, this invention collects encrypted fragments that meet a threshold number to reassemble keys to decrypt local documents, and immediately deletes the reassembled keys and fragments at the end of the agenda. This threshold reconstruction and immediate destruction mechanism ensures that the decryption key only exists temporarily within the meeting window, effectively reducing the risk of leakage caused by keys residing on the terminal for a long time; at the same time, the threshold strategy avoids single-point key holders abusing their privileges or becoming the focus of attacks, further strengthening the distributed security attributes of terminal-side key management. The entire key lifecycle is closely bound to the meeting agenda. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of embodiments of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0011] Figure 1 This is a flowchart of an optional multi-terminal online paperless conference information security transmission method according to an embodiment of this application;

[0012] Figure 2 A flowchart illustrating another optional method for secure information transmission in multi-terminal online paperless conferencing according to an embodiment of this application;

[0013] Figure 3 This is a flowchart illustrating another optional method for secure information transmission in multi-terminal online paperless conferencing according to an embodiment of this application;

[0014] Figure 4 This is a structural diagram of an optional multi-terminal online paperless conferencing information security transmission system according to an embodiment of this application;

[0015] Figure 5 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application.

[0016] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] 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 a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0018] This invention combines the unpredictability of chaotic systems, the distributed trust mechanism of threshold cryptography, the trusted verification of rendering behavior consensus, and key lifecycle management to construct a full-link dynamic protection system from document pre-distribution, terminal behavior verification, security situation awareness to real-time key destruction. The method uses meeting agenda items as the basic time unit. Each agenda item independently generates security parameters, independently distributes encrypted fragments, independently executes the consensus protocol, and independently destroys key materials, thereby achieving a tight binding between security policies and the meeting process.

[0019] According to one aspect of the embodiments of this application, such as Figure 1 As shown, this application provides a method for secure information transmission in multi-terminal online paperless conferencing, including:

[0020] S1, the server divides the meeting document into encrypted segments according to the agenda items and pre-distributes them to each tablet terminal. The encrypted segments are protected based on a chaotic system and a threshold cipher.

[0021] In this invention, chaotic systems and gated cryptography are not simply superimposed, but rather deeply integrated through a direct mapping from state vectors to threshold parameters. The server maintains a hyperchaotic system (preferably a hyperchaotic Lorenz system), which continuously generates a four-dimensional state vector during its evolution. At the start of each agenda item, the server samples this four-dimensional state vector, and the instantaneous value of the sample serves as the security seed for the encryption strategy of that agenda item.

[0022] The continuous evolutionary nature of chaotic systems ensures that the encryption parameters of each agenda item are unique and unpredictable, making it impossible for attackers to infer the security configuration of the current agenda from the encryption parameters of historical agendas. At the same time, the extreme sensitivity of chaotic systems to initial conditions ensures that even small perturbations will lead to huge differences in subsequent state vectors, thereby blocking key association across agendas.

[0023] S2, each tablet terminal constructs a rendering decision graph and extracts rendering fingerprints based on the rendering instruction stream. The nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of the rendering instructions.

[0024] The process of constructing the rendering decision graph uses the terminal rendering instruction stream as raw data, transforms the abstract rendering behavior into a structured graph representation, and then generates a rendering fingerprint that is unique to the terminal.

[0025] Specifically, each tablet terminal captures the rendering instruction stream at the operating system or graphics driver level, extracting information such as instruction type, target element identifier, timestamp, and viewport coordinate range. Using visible document elements within the current viewport as nodes, a connection is established between two document elements if they are in the same rendering instruction sequence and their timestamp difference is less than a preset threshold. The weight of the edge is set to the reciprocal of the timestamp difference; the smaller the difference, the higher the weight, indicating a strong correlation between the two document elements in their rendering sequence. This design allows the rendering decision graph to not only reflect the static layout of document elements but also capture the dynamic rendering dependencies triggered by user viewport movement, document scrolling, element highlighting, and other interactive behaviors.

[0026] The extraction of the rendering fingerprint is accomplished using a graph neural network. First, a feature vector is constructed for each node, which integrates multi-dimensional rendering semantics: element type encoding reflects the category attributes of the document structure; rendering latency characterizes system response efficiency; pixel change quantifies the drastic nature of viewport content updates; hierarchy depth reflects the nested position of elements in the document object model tree; and relative chapter position indicates the reading progress of elements within the entire document. These features are concatenated into an input vector of a preset dimension, processed by the hierarchical attention mechanism of the graph neural network, and finally compressed into a 16-dimensional rendering fingerprint vector. This fingerprint encapsulates the rendering behavior characteristics of the terminal at a specific viewport and at a specific time, and cannot be simulated by static data forgery or simple replay attacks.

[0027] S3, each tablet terminal calculates the similarity of its own rendering fingerprint with other tablet terminals, and executes the consensus protocol based on the similarity of the rendering fingerprint.

[0028] After extracting their own rendering fingerprint, each tablet terminal initiates a distributed consensus protocol. Its core objective is to autonomously identify the consistency of rendering behavior among the terminal group without a centralized verification node.

[0029] The first step in the consensus protocol is to calculate the rendering fingerprint similarity and viewport overlap between terminals. The viewport overlap is calculated based on the document chapter structure tree and represents the degree of overlap of the content currently viewed by the two terminals. The rendering fingerprint similarity is obtained by normalizing the Euclidean distance of the 16-dimensional vector through an exponential transformation, and the value ranges between 0 and 1. The closer the value is to 1, the more similar the rendering behavior is.

[0030] The protocol categorizes terminals into different interaction groups based on the two metrics mentioned above and executes differentiated consensus processes.

[0031] S4, generate a health index based on the execution results, and use the health index to modulate the evolution parameters of the chaotic system;

[0032] The health index is used to modulate the evolution parameters of the chaotic system to control the key derivation rate of the next agenda item.

[0033] The health index is a crucial link connecting consensus on terminal behavior with dynamic adjustments to encryption strategies. This index is calculated based on a weighted average of trust scores among terminals within the rapid consensus group; specifically, it is the ratio of the sum of trust scores of all terminals in the rapid consensus group to the sum of trust scores of all online terminals. This ratio directly reflects the proportion of highly trusted terminals among all terminals, providing a quantitative representation of the overall security posture of the meeting.

[0034] The health index modulates the evolution parameters of the hyperchaotic system in real time through a feedback loop. The specific modulation mechanism is as follows: based on a baseline dissipation parameter, a negative feedback gain term controlled by the health index is introduced. When the health index decreases, indicating a decline in the proportion of highly trusted terminals and difficulty in reaching consensus, the dissipation parameter increases accordingly, accelerating the divergence rate of the chaotic system's state vector and automatically shortening the sampling interval of the state vector. A shorter sampling interval means more state vector samples are generated within the same time period, allowing each agenda item to acquire new security parameters, thus increasing the key update frequency. Conversely, when the health index increases and the meeting environment becomes more stable, the dissipation parameter decreases, the sampling interval lengthens, and the key update frequency decreases, balancing security strength and system overhead.

[0035] This design implements an adaptive defense mechanism that drives encryption strength based on the security posture of the meeting. Traditional encryption schemes use static security level presets, which cannot cope with sudden terminal anomalies or attacks during a meeting; this invention links the evolution rate of the chaotic system with the actual health status of the terminal group in real time, achieving a dynamic security effect where the more dangerous the environment, the stronger the encryption.

[0036] In this invention, agenda items are the basic atomic units for security policy execution, and their division is closely tied to the structured organization of meeting documents. Each agenda item corresponds to an independent chapter, topic unit, or time interval in the meeting document, configured by the meeting organizer before the meeting or automatically divided by the server based on the document structure.

[0037] In some embodiments, the switching of agenda items is triggered by any of the following conditions: the meeting host initiates an agenda advancement instruction through the control terminal; the preset duration of the current agenda item expires; the meeting document enters a new chapter area; or all tablet terminals complete the document interaction for the current agenda item and enter a standby state.

[0038] Each time the agenda changes, the server resamples the chaotic system state vector and recalculates the threshold value, total number of fragments, and polynomial coefficients based on the new state vector, generating a completely new set of frozen parameters and encrypted fragments. There is no inheritance or reuse of security parameters between the old and new agenda items. This agenda-based security cycle concept ensures that even if the key material for a certain agenda item is leaked due to a compromised terminal, attackers cannot use that material to decrypt meeting documents for other agenda items, strictly limiting the scope of security risks to a single agenda item.

[0039] S5, during the agenda item, each tablet terminal collects encrypted fragments that meet the threshold number to reassemble the key and decrypt the local document. When the agenda item ends, the reassembled key and fragments are deleted.

[0040] In some embodiments, the present invention employs the Shamir threshold secret sharing scheme as the mathematical basis for key distribution. The core idea of ​​this scheme is: to construct a polynomial of degree t-1 using the key to be protected as a constant term; to take the coordinates of n distinct points on the polynomial as fragments and distribute them to n terminals; any t fragments can uniquely determine the polynomial, thereby reconstructing the constant term, i.e., the original key; any number of fragments less than t will not be able to obtain any information about the key.

[0041] In the application scenario of this invention, meeting the threshold number means that when a tablet terminal needs to decrypt a document, it must collect at least t valid fragments from the locally stored encrypted fragments and recover the agenda key using the Lagrange interpolation algorithm. The terminal itself holds only one fragment; the remaining t-1 fragments must be obtained from other terminals via LAN multicast or with the assistance of a server. This mechanism ensures that unless an attacker simultaneously compromises at least t terminals and obtains their fragments, it is impossible to independently reconstruct the key for any agenda item; the compromise of a single terminal only results in the leakage of a single fragment stored by that terminal, without affecting the overall security of the meeting.

[0042] The threshold value t is not a fixed constant, but is dynamically generated by the state vector of the chaotic system and takes an independent value for each agenda item, typically ranging from 2 to 4. This design provides a flexible adjustment space between security (the larger t is, the more difficult it is to attack) and availability (the smaller t is, the higher the tolerance for terminal offline).

[0043] The standard for secure deletion in this invention is set as follows: after the key material and encrypted fragments are deleted, they cannot be recovered by any software recovery method or hardware analysis technology, thus achieving the "Purge" security level defined by the NIST SP 800-88 standard.

[0044] In practice, the tablet terminal triggers a secure erase routine at the end of the agenda item. This routine performs differentiated erase operations for different storage media: For solid-state drives (SSDs), the terminal calls the ATA Secure Erase command or the NVMeFormat command to trigger the main control chip to erase the storage block level, and at the same time clears all logical block address mappings in the file system mapping table, making the deleted data physically unaddressable; For storage media that do not support secure erase commands, the terminal performs multiple rounds of overwrite operations. The first round writes all-zero binary data, the second round writes all-one binary data, and the last round writes a random pseudo-noise sequence, covering the original sectors occupied by the file and the reserved area of ​​the file system.

[0045] Furthermore, if meeting documents are stored using hardware-bound encryption during distribution, the terminal can also employ an encrypted erasure strategy when performing secure deletion: only the decryption key is destroyed, while the encrypted fragment data is retained. Due to the lack of a decryption key, the encrypted data is computationally undecryptable, achieving a security effect equivalent to physical destruction. This strategy combines high efficiency and high security, and is particularly suitable for flash memory media, preventing excessive writes from affecting storage lifespan.

[0046] After the above secure deletion operation is completed, it generates auditable log records, including information such as operation time, target file identifier, erasure algorithm, and checksum, for subsequent compliance review.

[0047] In summary, this invention constructs a complete, self-consistent, and highly secure multi-terminal paperless meeting information security transmission system, encompassing chaos-driven dynamic threshold key distribution, rendering behavior-driven distributed consensus, health feedback-driven adaptive encryption, and agenda-bound key lifecycle management. The various technical elements support and collaborate with each other, achieving full lifecycle protection for meeting documents while maintaining a smooth end-user experience and flexible meeting organization, significantly distinguishing it from existing technical solutions.

[0048] After S5, at the start of the next agenda item, the encrypted fragments are reacquired based on the newly determined freeze parameters of that agenda item.

[0049] Furthermore, the chaotic system is a hyperchaotic Lorenz system; in S1, protection is based on the chaotic system and threshold cryptography, including:

[0050] S11, The server samples the four-dimensional state vector of the hyperchaotic Lorenz system at the start of the agenda item;

[0051] Specifically, the first and second state components are extracted and used as constant term coefficients and linear term coefficients of the threshold cipher polynomial after modulo prime operation. The third state component is extracted and the threshold value is determined after taking the absolute value, taking the integer part, and modulo 3 plus 2. The fourth state component is extracted and combined with the preset maximum number of flat plates to determine the total number of slices. The threshold value, the total number of slices, the constant term coefficients and linear term coefficients of the threshold cipher polynomial are used as freezing parameters.

[0052] The four-dimensional state vector includes a first state component. Second state components Third state component and the fourth state component Determine the freezing parameters using the following formula:

[0053]

[0054]

[0055]

[0056]

[0057] in, Denotes the coefficients of the constant term in the threshold cipher polynomial. Denotes the coefficient of the first-order term in the threshold cipher polynomial. This represents the threshold value, i.e., the minimum number of fragments required to reassemble the key, and n represents the total number of fragments, i.e., the total number of fragments pre-calculated for this agenda item. This indicates that a preset prime number is used to limit the range of coefficient values ​​in modulo operations. This indicates the preset maximum number of tablets, which is the maximum number of terminals supported by the conference. These represent the absolute values ​​of the first state component, the second state component, the third state component, and the fourth state component, respectively. The floor function represents rounding down, and mod represents modulo operation.

[0058] The hyperchaotic Lorenz system used in this invention is an extension of the classical Lorenz system, with its state space consisting of four dimensions. The dynamic behavior of this system is defined by the following set of differential equations: the rate of change of the first state component is proportional to the difference between the second and third state components; the rate of change of the second state component is related to the product of the first and third state components plus the linear combination of the first and second state components; the rate of change of the third state component is equal to the product of the first and second state components minus the product of the third state component and a preset system parameter; the rate of change of the fourth state component is equal to the product of the second and third state components plus the product of the fourth state component and another preset system parameter. When the system parameters take typical values ​​(such as 10, 28, 8 / 3, and -1), the system exhibits hyperchaotic characteristics, i.e., it has at least two positive Lyapunov exponents, and the state trajectory in the phase space is non-periodic, non-convergent, and highly sensitive to initial conditions. This characteristic provides an ideal entropy source for generating unpredictable and irreversible safety parameters.

[0059] The prime number p is the modulus of the modulo prime operation, and its selection must satisfy two conditions simultaneously: First, p must be greater than the state component after absolute value amplification by 10. 6 The maximum value that can be obtained after multiplication is selected to ensure that the modular arithmetic operation does not result in truncation ambiguity; secondly, p should be a prime number to form a finite field GF(p), ensuring that the arithmetic operations of the threshold polynomial coefficients are closed and have no zero factors. Preferably, p = 1000003, which is slightly greater than 10. 6 This meets the above requirements. Experiments have verified that when the input value is between 0 and 4 × 10⁻⁶... 7 When the distribution is uniform within the interval, the result of the modulo 1000003 operation is also approximately uniformly distributed within the interval from 0 to 1000002, thus ensuring that the constant term coefficients and linear term coefficients of the threshold cipher polynomial have good randomness and will not cause output bias due to improper selection of the modulus.

[0060] Preset maximum number of tablets This indicates the maximum number of concurrent tablet terminals that the conference system can support within a single agenda item. This parameter is statically configured by the system administrator during the conference deployment phase based on server performance, network bandwidth, and expected conference scale. For example, in a typical deployment for provincial government meetings, the number of participating terminals usually does not exceed 100. It can be set to 120 to reserve a 20% redundancy; in deployments targeting corporate board meetings, the number of participating terminals typically does not exceed 20. It can be set to 24. This is only used to calculate the total number of sessions, n. Its specific value is decoupled from the actual number of attendees at the meeting, and it is not mandatory for every meeting to reach this upper limit. Total number of sessions n = or The fourth state component w is determined by modulo 2 operation. This design ensures that the server always pre-generates slightly more fragments than the maximum number of terminals to meet the instant distribution needs when temporary new terminals join the meeting.

[0061] S12, the server generates an independent random salt value for each tablet terminal, determines the sharding point based on the hash operation of the agenda key, random salt value and tablet terminal hardware fingerprint, substitutes the sharding point into the threshold cryptographic polynomial to calculate the sharding value, and combines the sharding point and sharding value into encrypted shards and pre-distributes them.

[0062] S13, the server broadcasts the freeze parameters to each tablet terminal. The freeze parameters remain unchanged during this agenda item. When the agenda item is switched, the server samples the new state vector and calculates the new threshold value and the new total number of fragments. The absolute value of the difference between the new threshold value and the original threshold value is calculated to obtain the threshold change, and the absolute value of the difference between the new total number of fragments and the original total number of fragments is calculated to obtain the fragment number change. It determines whether the threshold change is less than or equal to the first preset change threshold and whether the fragment number change is less than or equal to the second preset change threshold. If the determination result is yes, the new freeze parameters are broadcast and a new random salt value is generated. The new encrypted fragments are calculated based on the new freeze parameters and distributed. If the determination result is no, the original freeze parameters are maintained, a high-risk state identifier is generated and written into the metadata of this agenda item, and the distribution of encrypted fragments for the next agenda item to the tablet terminals involved in this agenda item is suspended until the administrator manually confirms or the threat is eliminated.

[0063] The frozen parameter set includes constant term coefficients. coefficient of the first term The threshold value t and the total number of fragments n together define the key distribution strategy for this agenda item.

[0064] constant term coefficient In the (t-1)th degree threshold polynomial, Let be the constant term of the polynomial, and its value is the symmetric encryption key for that term. The value of the polynomial reconstructed by Lagrange interpolation on all tablet terminals during key reconstruction at the zero point is . .therefore, The security of directly protecting the decryption access of meeting documents relies entirely on the unpredictability of chaotic sampling and the unidirectionality of modular prime number operations.

[0065] coefficient of the first term : It is the coefficient of the linear term in the (t-1)th degree polynomial. When t=2, the polynomial is a linear function. and Together, determine the slope of the linear function; when t > 2, It still exists as the coefficient of the higher-order term in the polynomial. The randomization ensures that the distribution of each fragment value generated by different agenda items is different in the finite field. Even if an attacker obtains fragments of multiple historical agenda items, they cannot deduce the fragment of the current agenda item through a linear relationship.

[0066] Threshold value t: t represents the minimum number of cryptographic fragments required to reconstruct the key. The value of t, ranging from 2 to 4, directly determines the balance between security and availability. The smaller t is, the lower the probability that a terminal will be unable to reconstruct the key due to offline status or malfunction, but the lower the threshold for the number of terminals an attacker needs to compromise; the larger t is, the attack difficulty increases exponentially, but the requirements for terminal online rate become more stringent. Real-time sampling of the z-component in the chaotic system allows t to change independently at each agenda item, enabling dynamic adjustment of the security policy.

[0067] Total number of fragments n: n represents the total number of encrypted fragments pre-computed and distributed by the server for this agenda item, and its value is fixed. or n must be greater than or equal to t to ensure that at least t distinct fragments are always available for reassembly at the threshold value t. The redundant fragments of n compared to t are used to accommodate the retransmission needs when new terminals join or individual terminal fragments are lost, improving the fault tolerance and scalability of the system.

[0068] It should be explained that at the beginning of each agenda item, the server reads the current four-dimensional state vector from the continuously evolving hyperchaotic Lorenz system. This read operation is triggered by a system-level timer to ensure precise synchronization between the sampling time and the agenda item boundaries. Each state component is a double-precision floating-point number, typically ranging from -40 to 40. To convert these floating-point numbers into integer-field cryptographic parameters, the following sequence of operations is performed:

[0069] Taking the absolute value: Eliminates the influence of the sign, making the mapping result only related to the magnitude of the value, and avoiding unnecessary changes introduced by the sign bit.

[0070] Multiply by 10 6 Coefficient: Magnifies floating-point numbers to the order of millions, thus minimizing the minute differences in chaotic trajectories (such as 10^10). -6 The magnitude is amplified to a distinguishable integer difference, ensuring that the slight state deviation at different sampling times can be reflected in the final threshold parameter.

[0071] Round down: Truncates the amplified floating-point number into an integer to accommodate the integer operation requirements of subsequent modulo operations and threshold value calculations.

[0072] Modulo 3 plus 2 (applicable only to the z component): The z value after rounding down is modulo 3, and the result is constrained to three remainders: 0, 1, and 2; then 2 is added to make the threshold value t lie in three discrete values: 2, 3, and 4. This design discretizes the continuous chaotic state into a threshold level containing only three gradients, which preserves the dynamics of chaotic sampling and avoids system instability caused by frequent jumps in t due to small state fluctuations.

[0073] The above operations together constitute a deterministic and repeatable mapping from continuous chaotic states to discrete cryptographic parameters, which is the core of the dynamic generation mechanism of frozen parameters.

[0074] Preferably, both the first and second preset change thresholds are set to 1. This value is set based on the following technical considerations: allowing the threshold value t and the total number of slices n to undergo smooth changes of ±1 between adjacent agenda items, to accommodate the natural drift of chaotic trajectories in phase space or the need for fine-tuning the meeting size. When the change is ≤1, the system determines that the evolution of security parameters is gradual and predictable, and directly adopts the new parameters to advance the meeting. If the change is ≥2, it means that the chaotic system state has undergone a jump—possibly caused by system time reset, server cold start, malicious tampering of chaotic system parameters, or external injection of disturbances—in this case, forcibly adopting new parameters may cause a large number of terminals to be unable to reassemble keys due to their inability to adapt to parameter mutations in a short time, or attackers may use the jump window to launch parameter rollback attacks. Therefore, setting the threshold to 1 achieves the best balance between security and continuity.

[0075] The high-risk status identifier is an immutable, structured audit record used to mark abnormal events triggered by a sudden change in threshold value or total number of shards exceeding a threshold. Its data structure includes the following fields: Event UUID: A 128-bit globally unique identifier, generated by the server according to RFC 4122. Timestamp: The UTC time at the time the event occurred, accurate to milliseconds. Anomaly Type: An enumerated value, taking either "threshold jump" or "shard count jump". Original parameter value, new parameter value, and change amount. Agenda Identifier: The ID of the agenda item that triggered the anomaly. Server Identifier: The ID of the server node that generated the record. This identifier is first written to the server's local security audit log file, which uses a write-only append mode and is stored in a tamper-proof hardware security module or a remote log server. Simultaneously, the identifier is pushed in real-time to the meeting management console via WebSocket, displayed in red highlighting at the top of the interface.

[0076] The administrator confirmation process is as follows: Administrators with high-risk operation privileges log in to the console using a USB hardware token or an SM2-based digital certificate. The system will then require the user to enter a dynamic verification code. After reviewing the identifier details, the administrator must choose one of the following three actions:

[0077] Ignore and force the process: Determine this jump as a normal system fluctuation and immediately continue the meeting using the new freeze parameters. This operation requires two administrators to log in and confirm, forming dual authorization.

[0078] Maintain original parameters and extend agenda: Keep the frozen parameters of the current agenda item unchanged, automatically extend the duration of the current agenda item by a preset value (e.g., 15 minutes), and do not advance to the next agenda item for the time being. Try switching again after the chaotic system state stabilizes.

[0079] Terminate the meeting and isolate the terminals: Immediately terminate all meeting sessions on all tablet terminals, trigger a full trust score reassessment, and mark all terminals in the current agenda item as pending observation. This operation requires recording the administrator's digital signature and the reason for the operation.

[0080] The time of each confirmed operation, the administrator's identity, the selected operation, and the signature value are all archived as extended fields of the high-risk status identifier, forming a complete audit loop.

[0081] Furthermore, the method also includes new security protocols added to the tablet terminal, namely:

[0082] S21, the newly added tablet terminal provides the server with hardware fingerprints and digital certificates issued by a certificate authority;

[0083] Hardware fingerprints serve as a unique physical identifier for tablet terminals. Their generation process is executed by the Trusted Execution Environment (TEE) or Secure Enclave (SE), ensuring that fingerprint acquisition is not interfered with by ordinary operating system processes. The specific steps are as follows:

[0084] The process involves collecting hardware attributes, specifically reading the unique identifiers built into the central processing unit (such as the JEP106 manufacturer code and chip serial number in ARM architecture chips), the serial number of the motherboard or backplane management controller, the MAC address of the network interface controller (Ethernet or Wi-Fi chip), and the public key hash (SHA-256) of the Trusted Platform Module (TPM) endorsement key. Attribute serialization involves concatenating these four attribute values ​​into a continuous byte string in a fixed order: "CPU ID + Motherboard Serial Number + MAC Address + TPM Public Key Hash".

[0085] The hash operation involves performing a SHA-256 hash calculation on the concatenated byte string, outputting a 256-bit digest value. Formatted storage means that this digest value is stored as a hexadecimal string in the terminal's secure storage area and reported to the server via an encrypted channel during initial registration, where it is added to the hardware fingerprint whitelist database.

[0086] This fingerprint has the characteristics of terminal uniqueness, non-cloning, and resistance to physical tampering. All subsequent fragment point generation and access verification rely on this fingerprint.

[0087] In some embodiments, the present invention constructs a three-tier certificate authority system, which, from top to bottom, consists of:

[0088] Root Certificate Authority (Root CA): Deployed offline, its private key is stored in a dedicated hardware security module (HSM) and is used only to issue secondary policy certificate authority certificates and its own root certificate. Root certificates have a validity period of 20 years and are pre-installed in the server and endpoint trust anchor library.

[0089] Policy Certificate Authorities (CAs): Deployed in a secure data center, their private keys are protected by an HSM (Hardware Management System). They are responsible for issuing Level 3 Registered Certificate Authorities certificates and publishing certificate revocation lists. Policy CA certificates are valid for 5 years.

[0090] Registration Certificate Authority (CA): Provides online certificate issuance services to end users. Private keys can be stored on a server HSM or a cryptographic card certified to FIPS 140-2 Level 3. Registration CA certificates are valid for 2 years, while end-user certificates are valid for the same period as the conferencing system (e.g., 90 days).

[0091] The terminal digital certificate conforms to the X.509 v3 standard, and the key fields are defined as follows:

[0092] Version: v3 (value is 2). Serial Number: A 20-byte positive integer assigned by the registered CA, guaranteed to be unique within the same CA. Signature Algorithm: Such as sha256WithRSAEncryption or ecdsa-with-SHA256. Issuer: The distinguishable name (DN) of the registered CA. Validity Period: notBefore and notAfter, using UTC time, in the format YYYYMMDDHHMMSSZ. Subject: The terminal hardware fingerprint represented as a hexadecimal string. Subject Public Key Information: A 2048-bit RSA public key or a NIST P-256 elliptic curve public key. Extensions: Includes key usage (digital signature, key encryption), extended key uses (client authentication), basic constraints (end entity), and CRL distribution point.

[0093] When the server verifies the certificate chain, it verifies it level by level from bottom to top: it uses the issuer's public key to decrypt the signature of the lower-level certificate and compares it with the digest value of the lower-level certificate; until it traces back to the pre-set root certificate public key, and each level of certificate is within its validity period and has not been revoked, the certificate chain is deemed trustworthy.

[0094] S22, the server extracts the public key and validity period from the digital certificate, verifies that the current time is within the validity period, uses the public key of the certificate authority to verify the signature validity of the digital certificate, and queries the pre-stored certificate revocation list to confirm that the hardware fingerprint does not exist in the list;

[0095] All certificate validity period fields are represented in Coordinated Universal Time (UTC), with a fixed time zone offset of "Z" (zero time zone). The server's local clock is synchronized with the national standard time source via the NTP protocol, with a maximum error of no more than 1 second. The expiration determination logic is as follows: When a terminal initiates an access request, the server extracts the current system time (converted to UTC) and compares it with the notBefore and notAfter (effective date and expiration date) in the certificate as integers (the format has been pre-converted to a Unix timestamp). If the current time < notBefore, it is determined as "not yet effective"; if the current time > notAfter, it is determined as "expired". If either is true, the terminal access is rejected, and an alarm is sent to the administrator console. To prevent misjudgment due to millisecond-level time deviations, a 30-second soft boundary buffer is allowed at the validity period boundary, meaning that the current time is still considered valid within 30 seconds after notAfter, but a time offset alarm must be recorded.

[0096] Signature verification performs corresponding cryptographic operations based on the signature algorithm field in the certificate. Taking the RSA algorithm as an example: the server uses the issuer's public key to perform RSA decryption on the certificate signature value to obtain the original hash value; simultaneously, the server recalculates the digest of the part to be signed in the certificate using the same hash algorithm as the signature algorithm (such as SHA-256); the decrypted hash value is compared with the recalculated digest value, and if they match, the signature is valid. For ECDSA signatures, the verification process involves elliptic curve multiplication, using the public key to verify whether the signature pair satisfies the elliptic curve equation. All cryptographic operations are implemented through hardware acceleration instructions or cryptographic libraries (such as OpenSSL, BoringSSL) to ensure constant time and resistance to side-channel attacks.

[0097] Policy-based Certificate Authorities (CAs) publish Certificate Revocation Lists (CRLs) in CRL v2 format. The update mechanism uses an incremental release model: each CRL is published as a complete one, but newly added revocation items can be identified by comparing serial numbers. CRLs are published every 24 hours; in the event of an emergency revocation, the policy-based CA administrator can manually trigger immediate publication.

[0098] In one embodiment, the process of the server querying the CRL is as follows:

[0099] First, the server checks if the current policy CA's CRL object exists in the memory cache. If it exists and its "Next Update Time" field is more than 80% of the current time since the last update (default is 80% of the difference between the current and next update times), an asynchronous update is triggered. If there is no cache or the cache has expired, the server downloads the latest CRL from the distribution point specified by the policy CA via HTTP or LDAP protocol. The download uses a TLS 1.3 encrypted channel and verifies the validity of the CRL signature.

[0100] Extract the "List of Revoked Certificate Serial Numbers" from the CRL and perform a binary search with the terminal certificate serial numbers. If a match is found, deny access to the terminal and record the corresponding risk level based on the revocation reason code (e.g., key leakage, certificate expiration). Cache the verified CRL objects in memory, and convert the serial number list into a hash table structure to accelerate subsequent queries.

[0101] S23, the server generates a new random salt value for the newly added tablet terminal and calculates a new sharding point and sharding value based on the freeze parameters of the current agenda item;

[0102] S24, the server transmits the encrypted fragment to the newly joined tablet terminal through the established TLS 1.3 secure channel and marks the fragment as issued.

[0103] All encrypted fragmented data transmissions between the server and the tablet terminal are based on the TLS 1.3 protocol. The handshake process is as follows:

[0104] ClientHello: The terminal sends a ClientHello message, which includes the version number of TLS 1.3 or higher that is supported, a random number, a list of supported cipher suites (which must include TLS_AES_256_GCM_SHA384 and ECDHE parameters based on X25519 or P-256), and extended fields (such as supported_versions and key_share).

[0105] ServerHello: The server selects TLS 1.3 and the cipher suite TLS_AES_256_GCM_SHA384, and replies to ServerHello with the server's random number and the corresponding ECDHE public key.

[0106] Key Negotiation: Both parties exchange keys via ECDHE, negotiating a shared secret using X25519 or P-256 elliptic curves. Combining random numbers from both parties and handshake hashes, the master key, session key, and initialization vector are derived using HKDF.

[0107] Certificates and Verification: The server sends its digital certificate chain, and the terminal may optionally send its client certificate (this invention mandates that the terminal provide a certificate). Both parties verify the validity of the other party's certificate.

[0108] Finished: Both parties send a Finished message containing the MAC value of the handshake message digest, confirming that the handshake process has not been tampered with.

[0109] Subsequently, all application data is transmitted encrypted in AEAD mode (AES-256-GCM), with each record accompanied by a message authentication code to ensure confidentiality and integrity. The core advantage of TLS 1.3 lies in its forward confidentiality: the session key generated by ECDHE is independent of the server's long-term private key. Even if the server's private key is leaked in the future, attackers will not be able to decrypt any recorded encrypted traffic, thus ensuring the absolute security of the historical fragment distribution process.

[0110] Furthermore, in S2, a rendering decision graph is constructed based on the rendering instruction stream, and rendering fingerprints are extracted, including:

[0111] S31, each tablet terminal captures the rendering instruction stream at the operating system layer and extracts the instruction type, target element identifier, timestamp and viewport coordinate range;

[0112] This invention captures rendering instruction streams at the tablet operating system level. It supports the following three implementation schemes, and the optimal scheme should be deployed based on system permissions and API openness:

[0113] PLT hooks: These hijack the graphics library function table in user space. Taking the Android system as an example, by modifying the process's GOT (Global Offset Table), the entry addresses of drawing functions (such as glDrawElements and glClear) in the OpenGL ES driver library (libGLESv2.so) are redirected to a custom interceptor function. The interceptor function records the instruction parameters and then jumps back to the original function.

[0114] System call interception: By injecting probes into key ioctl entry points at the graphics card driver layer (such as the drm driver) through the Linux kernel's ftrace or eBPF mechanisms, the rendering command buffer sent from user space to the kernel can be captured. This method requires system-level privileges and is suitable for enterprise-customized terminals.

[0115] Kernel Module: For deeply customized tablet hardware, a kernel module can be developed to register a graphics subsystem hook, directly intercept the rendering command submission queue, and achieve zero-bypass command capture.

[0116] Regardless of the method used, the capture engine must record the following metadata for each rendering instruction with microsecond precision: instruction opcode (corresponding to the specific drawing operation), target element identifier (such as view control ID or Web DOM element hash), timestamp, and viewport coordinate range (the boundary of the rendering target rectangle).

[0117] The captured rendering instruction stream uses a uniform structured log format, and each entry contains the following fields:

[0118] Instruction ID: Incrementing sequence number. Timestamp: 64-bit nanosecond-level time value. Process ID / Thread ID: Identifier of the process and thread initiating the rendering. API Type: Enumerated value, such as "OpenGL_ES", "Vulkan", "Skia", "WebView". Instruction Type: Fine-grained enumeration, for example: DRAW_ELEMENT: Draw a single graphics element; DRAW_ARRAY: Batch draw an array of vertices; CLEAR_COLOR: Clear the color buffer; TEX_IMAGE: Upload texture data; SET_VIEWPORT: Set the viewport transformation; SWAP_BUFFERS: Swap the front and back buffers (end of frame). Element Identifier: If the instruction involves a specific document element, record its DOMID or control handle. Coordinate Range: Left, top, right, and bottom boundaries of the rendering target in the screen pixel coordinate system. Parameter Summary: Hash values ​​of key parameters (such as texture pointers, shader program handles), used for subsequent fingerprint comparison.

[0119] This data format maps one-to-one with the instruction sets of common graphics APIs, ensuring that the captured information is sufficient to reconstruct the rendering process of the current viewport.

[0120] S32, taking the document elements in the current viewport as nodes, for two document elements in the same rendering instruction sequence whose timestamp difference is less than a preset timing threshold, establish an edge between the two document elements, and construct a rendering decision graph with the reciprocal of the timestamp difference as the edge weight.

[0121] A preset timing threshold is used to determine whether two rendering events belong to the same batch of related operations, and its value is fixed at 16.67 milliseconds. This value is selected based on the fact that the screen refresh rate of mainstream tablet devices is 60Hz, meaning the interval between two adjacent frames is approximately 16.67ms. Rendering instructions occurring within the same frame usually serve the same visual presentation task and have strong temporal correlation; rendering instructions across frames belong to different display cycles, and their correlation is significantly weakened. Therefore, two document elements with a timestamp difference of less than 16.67ms are considered to be in the same rendering batch, and an edge relationship is established; if the difference is greater than or equal to this threshold, they are determined to be unrelated rendering events, and no connection is established. This threshold ensures that the rendering decision graph can effectively capture rendering dependencies within a single frame, while avoiding the introduction of noisy edges due to cross-frame instructions.

[0122] S33, extract node feature vectors and concatenate them into a feature vector with a preset input dimension. The node feature vector includes: element type encoding that maps element type to binary encoding vector and sets the dimension corresponding to element type to 1 and the other dimensions to 0; rendering delay, which is the difference between the rendering instruction execution time and the receiving time; pixel change, which is the ratio of the difference between the pixel values ​​of the current frame and the previous frame; the level depth of the element in the document object model tree; and the relative chapter position, which is the ratio of the chapter number of the element to the total number of chapters in the document.

[0123] The dimension of the binary encoded vector is equal to the total number of all predefined document element types in the system. The element type enumeration set consists of visualization components supported by the conference document rendering engine, including but not limited to: text blocks, images, tables, charts, shapes, annotation boxes, highlighted areas, video placeholders, hyperlink anchors, page number markers, etc. This enumeration set is statically compiled into the rendering engine, and its dimension is typically between 12 and 16. The binary encoded vector for each element type is in one-hot code form: the dimension equals the total number of types, the dimension corresponding to the element type is set to 1, and the other dimensions are set to 0. For example, if the total number of types is 12 and the current element is "table", then the encoded vector is [0,0,1,0,0,0,0,0,0,0,0,0] (assuming that table is type 3). This encoding method unambiguously expresses the category attribute of the element, and the vector spaces are orthogonal to each other, which facilitates subsequent graph neural network feature fusion.

[0124] S34, the feature vector of the preset input dimension is processed by the hierarchical attention aggregation of the graph neural network, and compressed to 16-dimensional output through the encoding layer of the graph neural network to obtain a 16-dimensional rendering fingerprint vector. The hierarchical attention includes intra-element attention of the same type, inter-element attention of cross-type, and exponentially decaying temporal attention.

[0125] The preset input dimension is the total length of the feature vectors received by the entry layer of the graph neural network, determined by the dimension of the feature vector of each node. A node feature vector is composed of six parts: Element type encoding: the dimension equals the total number of element types (denoted as T, usually T = 12). Rendering latency: a scalar (1-dimensional), normalized to [0,1]. Pixel variation: a scalar (1-dimensional), normalized. Layer depth: a scalar (1-dimensional), normalized. Relative chapter position: a scalar (1-dimensional), normalized. Element geometry (optional extended features): normalized width and height values ​​(2-dimensional). Therefore, the node feature vector dimension = T + 1 + 1 + 1 + 1 + 2 (if including geometry). Taking T = 12 and including geometry as an example, the preset input dimension is 12 + 5 = 17 (if including 2-dimensional geometry, it is 12 + 6 = 18). This dimension value is fixed during model training; all node input vectors need to be padded or clipped to this unified dimension.

[0126] The graph neural network used in this invention employs a two-layer graph attention network architecture, which is specifically optimized for real-time inference on mobile devices.

[0127] Input layer: Receives node feature vectors of a preset input dimension.

[0128] The first layer is the graph attention layer: it has 4 attention heads, each of which independently calculates the attention coefficients between nodes and normalizes the edge weights using softmax; the output feature dimension is compressed to 64. The activation function used is ELU.

[0129] The second layer is the graph attention layer: the number of attention heads is reduced to 2, and the output feature dimension is further compressed to 32. The activation function used is ELU.

[0130] Encoding layer: The fully connected layer aggregates 32-dimensional node-level features and maps them to global graph-level features, with an output dimension of 16 and no activation function (linear layer).

[0131] Output layer: The 16-dimensional vector is the rendering fingerprint, which is normalized by L2 norm to ensure that each component is in the [0,1] interval.

[0132] The network employs a pre-training + edge inference approach: Pre-training is performed on the server side using a large-scale general document rendering dataset to learn general characteristics of rendering behavior; after training, the model parameters (weights, biases) are quantized to 8-bit integers and converted to TensorFlow Lite format for deployment on tablet terminals. During edge inference, the rendering decision graph is directly input into the lightweight model after construction, utilizing the ARM NEON instruction set for parallel matrix operations.

[0133] By aggregating information from the entire image through an attention mechanism, high-dimensional sparse node features are compressed into a low-dimensional dense vector space, preserving the most discriminative rendering behavior features. This dimensionality is a trade-off between security strength and computational cost; dimensions below 16 are prone to fingerprint collisions between different rendering behaviors, while dimensions above 16 result in inference latency exceeding the 3-millisecond budget.

[0134] The original 16-dimensional vector output by the graph neural network is normalized using the L2 norm, which means that each component is divided by the Euclidean norm of the vector, so that the magnitude of the output vector is 1 and the value of each component falls between [0,1]. This normalization step has the following technical significance: it eliminates the vector scale offset caused by the difference in rendering command scale between different agenda items or different terminals, ensuring that the subsequent Euclidean distance calculation only reflects the difference in direction rather than the difference in absolute magnitude; at the same time, the normalized vector can be directly used for cosine similarity or distance threshold comparison without additional scaling.

[0135] Furthermore, in S3, each tablet terminal calculates its own rendering fingerprint similarity to other tablet terminals, and executes a consensus protocol based on the rendering fingerprint similarity, including:

[0136] S41, each tablet terminal calculates its own viewport overlap and rendering fingerprint similarity with other tablet terminals; the viewport overlap is the ratio of the number of intersections to the number of unions of visible elements calculated based on the document chapter structure tree, and the rendering fingerprint similarity is obtained by exponential transformation of the Euclidean distance of the 16-dimensional rendering fingerprint vector.

[0137] S42, determine whether the viewport overlap is greater than the first preset overlap threshold and whether the rendered fingerprint similarity is greater than the first preset similarity threshold. If so, it is assigned to the fast consensus group and the simplified consensus process is executed.

[0138] S43, determine whether the viewport overlap is greater than or equal to the second preset overlap threshold and less than or equal to the first preset overlap threshold, and determine whether the rendering fingerprint similarity is greater than or equal to the second preset similarity threshold and less than or equal to the first preset similarity threshold. If so, it is included in the enhanced verification group and the enhanced verification process is executed.

[0139] S44, determine whether the viewport overlap is less than the second preset overlap threshold and whether the semantic distance is less than the preset semantic threshold. If so, mark it as an observation state. The tablet terminal in the observation state does not participate in the consensus protocol of the current agenda item, and its trust score remains unchanged. When the next agenda item starts, steps S41 to S43 are re-executed.

[0140] S45, determine whether the viewport overlap is less than the second preset overlap threshold and whether the semantic distance is greater than or equal to the preset semantic threshold. If so, it is assigned to the isolation group and a security response is triggered.

[0141] After each tablet terminal extracts its own 16-dimensional rendering fingerprint vector, it initiates a distributed consensus protocol. The protocol first calculates the viewport overlap and rendering fingerprint similarity between each pair of terminals.

[0142] Viewport overlap is calculated based on the document chapter structure tree: Visible document elements within both current viewports are constructed into sets, and the overlap is the ratio of the number of elements in the intersection of the two sets to the number of elements in the union. Visible elements are determined by the criterion that their bounding boxes intersect with the screen viewport rectangle and that they are not completely obscured or transparent.

[0143] Render fingerprint similarity is calculated by taking the Euclidean distance from the 16-dimensional rendered fingerprint vectors and then mapping it to the 0-1 range using an exponential function. A value closer to 1 indicates more similar rendering behavior. Based on the combination of these two metrics, the protocol categorizes terminal pairs into the following groups and executes the corresponding procedures:

[0144] Rapid consensus group: When the viewport overlap is higher than the first preset overlap threshold (70%) and the rendering fingerprint similarity is higher than the first preset similarity threshold (0.85), it indicates that both parties are not only viewing the same area, but their rendering behavior is also highly consistent. The terminals within the group execute a simplified consensus process: skipping the pre-preparation phase of the classic Byzantine protocol, a temporary coordinator broadcasts the fingerprint digest, and each terminal compares it locally; consensus is reached when more than 2 / 3 of the terminals confirm. This process has minimal communication overhead and is suitable for highly trusted terminal groups.

[0145] Enhanced Verification Group: When the viewport overlap is between the second preset overlap threshold (30%) and the first preset overlap threshold, and the rendering fingerprint similarity is between the second preset similarity threshold (0.50) and the first preset similarity threshold, the viewports of both parties are similar, but there are interpretable differences in their rendering behavior. The terminal within the group executes an enhanced verification process: one party initiates a challenge, requesting the other party to provide a Merkle path proof for the rendering instructions of a specified document element; the other party constructs a binary Merkle tree based on the instructions in the current frame and returns a path hash sequence; the verifier confirms the authenticity of the instructions by calculating the root hash and path level by level. This process can achieve strong and reliable verification without transmitting all instructions.

[0146] Observational state: When the viewport overlap is lower than the second preset overlap threshold (30%), but the semantic distance is less than the preset semantic threshold (0.20), the two parties, although having different viewports, are in adjacent chapters and there is a reasonable possibility of collaboration. Such terminals do not participate in the consensus of the current agenda item, and their trust score remains unchanged until the next agenda item is re-executed for group evaluation.

[0147] Isolation Group: When the viewport overlap is below the second preset overlap threshold (30%) and the semantic distance is greater than or equal to the preset semantic threshold (0.20), the viewport span between the two parties exceeds two chapters, indicating no reasonable collaborative semantics. Such terminals are classified into the isolation group and a security response is triggered. The semantic distance is calculated based on the ratio of the difference between the current chapter number and the total number of chapters in the document. The chapter number is determined by the depth-first traversal sequence number of the chapter structure tree.

[0148] Furthermore, in S45, the process of categorizing into an isolation group and triggering a security response includes:

[0149] S51, Update the trust score of the tablet terminal in the isolation group;

[0150] Calculate using the following formula:

[0151]

[0152] in, This represents the updated trust score of the j-th tablet terminal. This represents the original trust score before the j-th tablet terminal updates, i.e., the trust score at the end of the previous agenda item; This indicates that the preset memory decay coefficient is used to control the retention ratio of historical trust, and its value ranges from greater than 0 to less than 1. This represents the preset isolation penalty value, used to quantify the amount of trust score deduction due to the isolation state. Its value is a constant greater than 0 and less than 1. The maximum value operation is used to truncate the lower limit of the trust score to 0. The minimum value operation is used to truncate the upper limit of the trust score to 1;

[0153] S52, determine whether the updated trust score is less than the first preset trust threshold. If so, calculate the sum of the current threshold value and the preset threshold increment value as the new threshold value for the next agenda item. The preset threshold increment value is 1, and mark the segment of the tablet terminal as a state that requires additional verification.

[0154] S53, determine whether the updated trust score is less than the second preset trust threshold. If so, refuse to send the encrypted fragment of the next agenda item to the tablet terminal and remove it from the meeting.

[0155] Tablet devices placed in the isolation group will trigger a trust score update mechanism. The system uses a dual-factor approach of memory decay and isolation penalty to adjust the trust score: the original trust score is multiplied by a preset memory decay coefficient (within 0 and 1) to reflect the smooth forgetting of historical behavior, and then a preset isolation penalty value is subtracted, truncating the result to between 0 and 1. This update rule ensures that the trust score of frequently abnormal devices continues to decline, while devices with single abnormalities can gradually recover through subsequent good performance.

[0156] When a terminal's updated trust score falls below a first preset trust threshold, the system determines that the terminal poses a moderate risk. To mitigate this potential threat, the threshold value for the next agenda item will be increased by a preset threshold increment (fixed at 1) based on the current value. Simultaneously, the encrypted fragments held by this terminal are marked as requiring additional verification. Other terminals must perform additional signature verification on these fragments when reconstructing the key, thereby increasing the cost for an attacker to utilize these fragments for reconstructing.

[0157] When a terminal's updated trust score falls below the second preset trust threshold, the system determines that the terminal has lost basic trustworthiness. The server immediately refuses to issue any encrypted fragments for the next agenda item to the terminal and removes it from the current meeting session. If a removed terminal needs to rejoin, it must re-execute the certificate and hardware fingerprint dual access process of claim 3, and its trust score is reset to the initial value (1.0) and enters an observation period.

[0158] Furthermore, in S4, a health index is generated based on the execution results and fed back the evolution parameters of the modulated chaotic system, including:

[0159] S61, calculate the health index based on the weighted trust score of each tablet terminal in the fast consensus group. The health index is the ratio of the sum of trust scores of the fast consensus group to the sum of trust scores of all online terminals.

[0160] S62 modulates the dissipative parameters of a hyperchaotic Lorenz system using a health index;

[0161]

[0162] in, Indicates the dissipation parameter. Indicates the reference dissipation parameter. This indicates the preset feedback gain coefficient. Indicates a health index;

[0163] Among them, the preset feedback gain coefficient It is a dimensionless constant, with a value greater than 0 and less than 1, used to control the health index. For dissipation parameters The adjustment range. Health Index Defined as the ratio of the sum of trust scores of the fast consensus group to the sum of trust scores of all online terminals, its value ranges from 0 to 1 and is a dimensionless quantity. S63, when the health index decreases, the dissipation parameter increases, the state vector divergence rate of the hyperchaotic Lorenz system accelerates, the state vector sampling interval shortens, and the key update frequency increases accordingly; when the health index increases, the dissipation parameter decreases, the state vector divergence rate slows down, the sampling interval lengthens, and the key update frequency decreases accordingly.

[0164] The Health Index is a real-time quantitative indicator of the overall security status of the meeting. It is calculated as: the sum of the current trust scores of all terminals within the rapid consensus group, divided by the sum of the current trust scores of all online terminals. This ratio directly reflects the proportion of highly trusted terminals in the total number of meeting terminals, and its value ranges between 0 and 1.

[0165] The health index dynamically modulates the dissipation parameters of the hyperchaotic Lorenz system through a negative feedback loop. Specifically, the dissipation parameter equals the baseline dissipation parameter multiplied by one minus the product of the feedback gain coefficient and the health index. When the health index decreases, indicating a decline in the proportion of highly trusted terminals and increased consensus difficulties, the dissipation parameter increases accordingly. This increase accelerates the divergence rate of the state vector in the hyperchaotic Lorenz system, causing the state trajectories to separate more quickly in phase space. The system synchronously shortens the sampling interval of the state vector, meaning more independent state samples can be obtained per unit time, thus generating more frequently updated key material at each agenda item switch. Conversely, when the health index increases, the dissipation parameter decreases, the sampling interval lengthens, and the key update frequency gradually decreases.

[0166] This feedback mechanism achieves, for the first time, real-time linkage between encryption strength and the actual security status of the meeting: when the environment becomes dangerous, the encryption strategy is automatically strengthened; when the environment becomes stable, the encryption overhead adaptively decreases. The entire process requires no manual intervention and is driven entirely by the system's inherent security metrics.

[0167] In one specific implementation, such as Figure 2 As shown, this invention provides a method for secure information transmission in multi-terminal online paperless meetings, the core process of which is as follows:

[0168] Step A: Meeting begins

[0169] After the meeting started, the system initialized the hyperchaotic Lorenz system to prepare for generating security parameters for the first agenda item.

[0170] Step B: Generating threshold parameters for the chaotic system

[0171] The server samples the current state vector of the hyperchaotic Lorenz system and generates a frozen parameter set for the agenda item using a pre-defined mapping rule. This set includes: the constant and linear coefficients of the threshold polynomial, the minimum number of fragments required for key reconstruction (the threshold value), and the total number of fragments pre-computed for the agenda item. This mapping rule utilizes operations such as absolute value amplification of state components, modulo prime, and modulo 3 plus 2 to transform the minute differences in the chaotic trajectory into discrete cryptographic parameters.

[0172] Step C: Pre-distribute encrypted fragments

[0173] Based on the frozen parameters, the server generates a random salt value for each tablet terminal that has passed dual authentication of hardware fingerprint and digital certificate. It calculates the fragmentation point by combining the terminal hardware fingerprint, substitutes it into a polynomial to generate the fragmentation value, and pre-distributes the encrypted fragments to each terminal through the TLS 1.3 secure channel.

[0174] Step D: Rendering the decision graph and fingerprint

[0175] During the execution of each agenda item, each tablet terminal captures the real-time rendering instruction stream at the operating system layer, extracting the instruction type, target element identifier, timestamp, and viewport coordinates. Using visible document elements within the current viewport as nodes and the reciprocal of the timestamp difference within the same rendering batch as edge weights, a rendering decision graph is constructed; subsequently, a 16-dimensional rendering fingerprint vector is extracted using a lightweight graph neural network.

[0176] Step E, Consensus Grouping

[0177] Each terminal broadcasts its own rendered fingerprint and viewport information, calculates the viewport overlap and rendered fingerprint similarity between pairs of terminals, and categorizes terminal pairs into different groups based on preset thresholds:

[0178] High viewport / fingerprint ratio (viewport overlap ≥ 70% and fingerprint similarity ≥ 0.85): classified into the fast consensus group;

[0179] In the viewport / fingerprint (viewport overlap 30%~70% and fingerprint similarity 0.50~0.85): classified into the enhanced verification group;

[0180] Low viewport / fingerprint ratio (other cases, and viewport overlap < 30%, semantic distance ≥ 0.20): classified into the isolation group.

[0181] The state to be observed (viewport overlap < 30% but semantic distance < 0.20) is not shown separately in this figure, but serves as a preliminary screening branch for the isolation group.

[0182] Step F, Rapid Consensus Group

[0183] The rapid consensus process involves simplified consensus procedures executed by terminals within the group, skipping the pre-preparation phase. A temporary coordinator broadcasts the fingerprint digest, and consensus is reached once more than two-thirds of the group confirm it.

[0184] Step G, Enhanced Verification Group

[0185] Enhanced verification group terminal execution Merkel path challenge-response verification: One party initiates a random number challenge, and the other party provides the Merkel root hash and path proof of the rendering instruction of the specified document element. The verifier confirms the authenticity of the instruction by recalculating the path.

[0186] Step H, Isolation Group

[0187] The isolated group terminal triggers a dynamic trust score update mechanism. The system adjusts its trust score based on the memory decay coefficient and the isolation penalty value. If the trust score is lower than the first preset threshold, the threshold value of the next agenda item is increased by 1, and its fragment is marked as requiring additional verification. If the trust score is lower than the second preset threshold, the next agenda item fragment is rejected and removed from the meeting.

[0188] Step 1: Calculate the health index

[0189] The server generates a health index H based on the ratio of the sum of the current trust scores of all terminals within the rapid consensus group to the sum of the trust scores of all online terminals. This index reflects the overall security status of the meeting in real time.

[0190] Step J: Modulate chaotic evolution parameters

[0191] The server uses the health index H to perform negative feedback modulation on the dissipation parameter k of the hyperchaotic Lorenz system: When H decreases and k increases, the divergence rate of the chaotic system accelerates, the state vector sampling interval shortens, and the key update frequency increases; conversely, the encryption overhead decreases.

[0192] Step K: Decryption of the reconstructed key

[0193] During the agenda items, each tablet terminal collects encrypted fragments up to the threshold number t via LAN multicast or server assistance, reconstructs the threshold polynomial over a finite field using Lagrange interpolation, extracts the constant term as the agenda key, and decrypts the locally stored encrypted meeting documents.

[0194] Step L: Secure deletion at the end of the agenda

[0195] At the end of the agenda item, each tablet terminal performs a secure deletion operation compliant with NIST SP 800-88 on the temporarily stored agenda key, reconstructed intermediate data and encrypted fragments: supporting ATA Secure Erase, NVMe Format or multiple overwrite (all 0s, all 1s, random pseudo-noise sequence), ensuring that no sensitive material can be recovered by software recovery or hardware analysis.

[0196] Step M, Next Agenda? If the meeting contains multiple agenda items, the system determines whether to switch to the next agenda. Yes: Return to step B, the server resamples the chaotic system state, generates new threshold parameters and encrypted fragments, and begins a new agenda cycle. No: The meeting ends, all temporary key materials have been destroyed, and the terminal exits the meeting state.

[0197] Furthermore, following S5, the method also includes:

[0198] S81, each tablet terminal monitors the number of online tablet terminals, calculates the difference between the number and the current threshold value, and determines whether the difference is less than 0. If so, the downgrade mode is triggered.

[0199] S82, in downgrade mode, the tablet terminal suspends receiving new encrypted fragments and only accesses the decrypted document content in the local cache; the server suspends issuing encrypted fragments of the next agenda item to the tablet terminal and generates a downgrade notification message to push to the tablet terminal.

[0200] S83, determine whether the tablet terminal has reconnected. If yes, execute the consensus protocol of S3 and determine whether to restore the online status according to the consensus group to which it was assigned. Otherwise, execute S84.

[0201] S84, determine whether the absolute value of the difference between the new threshold value after the threshold value is reduced by the preset threshold and the original threshold value is less than or equal to the first preset change threshold. If yes, reduce the threshold value by the preset threshold and recalculate the encrypted fragment. Otherwise, execute S85.

[0202] S85 retrieves the pre-stored backup key in the server hardware security module, verifies the administrator's authorization information, and then enables the backup key. The threshold value of the backup key is a preset minimum threshold value.

[0203] The system continuously monitors the real-time number of online tablet terminals during each agenda item. When the number of online terminals falls below the threshold value t set for the current agenda item, the system determines that the minimum key reassembly requirement cannot be met and immediately triggers the degradation mode.

[0204] In degraded mode, all tablet terminals suspend requesting new encrypted fragments from the server and are only allowed to access the decrypted content of the current agenda item document in the local cache. The server simultaneously suspends the distribution of encrypted fragments for the next agenda item to any terminal and pushes a degraded notification message to all online terminals and the conference console, indicating "Insufficient online terminals; the conference will enter restricted browsing mode."

[0205] For offline terminals, the system initiates a reconnection detection process. If the offline terminal re-establishes a secure connection and completes the access authentication of claim 3 within the preset reconnection window, the consensus protocol of claim 5 is immediately executed, and it is assigned to the corresponding group based on its viewport overlap and rendered fingerprint similarity with existing terminals; if it is successfully assigned to the fast consensus group or enhanced verification group, its online status is restored and it continues to participate in key reassembly.

[0206] If an offline terminal fails to recover within the reconnection window, the system assesses the feasibility of lowering the threshold value: it calculates the current threshold value minus a preset threshold reduction (fixed at 1) to obtain a new threshold value, and determines whether the absolute value of the change between the new threshold value and the original threshold value is less than or equal to a first preset change threshold (i.e., 1). If the condition is met, the system lowers the threshold value by 1 and recalculates the encrypted fragments of all terminals based on the current freeze parameters to reduce the requirement for the number of terminals and maintain the continuation of the conference.

[0207] If the threshold value is already at the minimum (i.e., t=2) or lowering the threshold value would cause the change to exceed the first preset change threshold, the system automatically activates the backup key pre-stored in the hardware security module. The backup key is generated offline by the system administrator and written into the hardware security module during the meeting deployment phase, and its threshold value is fixed at the preset minimum threshold value (i.e., 2). The system releases the backup key and switches to the minimum threshold mode only after the administrator completes online authorization verification via a USB hardware token or digital certificate, ensuring that the meeting can continue to operate under the minimum conditions for two-terminal collaboration even in extreme circumstances.

[0208] Every decision node in the entire degradation mode, including degradation triggering, threshold lowering, and backup key activation, generates a structured audit event, which fully records the timestamp, terminal status, decision basis, and operation administrator identity, for use in post-event security audits and compliance reviews.

[0209] In one specific implementation, such as Figure 3 As shown, the adaptive response mechanism of this invention for abnormal scenarios is as follows:

[0210] Step A: Meeting Setup

[0211] The meeting proceeded normally, and the system continuously monitored the number of online terminals, terminal trust scores, and parameter changes during agenda switching.

[0212] Step B: Number of online terminals < current threshold?

[0213] The server continuously counts the number of online tablet terminals in the current agenda item and compares it with the threshold value t set for that agenda item. If the number of online terminals is greater than or equal to t, the meeting continues normally; if the number of online terminals is less than t, a downgrade mode is triggered.

[0214] Step C, Downgrade Mode

[0215] The system immediately enters a degraded state: all tablet terminals suspend requesting new encrypted fragments from the server and are only allowed to access the content of the current agenda item document that has been decrypted in the local cache, in order to ensure the availability of the loaded information.

[0216] Step D: The server suspends the distribution of the next agenda shard and pushes a downgrade notification.

[0217] The server suspends the distribution of encrypted fragments of the next agenda item to any terminal and pushes a degradation notification message to the conference console via WebSocket. The console displays "Insufficient online terminals, the conference has entered restricted browsing state".

[0218] Step E: Reconnecting the offline terminal?

[0219] The system waits for the offline terminal to reconnect within a preset reconnection window (e.g., 30 seconds). If the terminal reconnects, proceed to step F; if it does not reconnect within the timeout period, proceed to step J.

[0220] Step F: Re-execute the consensus protocol

[0221] After the reconnected terminal rejoins the meeting, it immediately interacts with the existing online terminals, recalculates the viewport overlap and rendering fingerprint similarity, and executes the consensus grouping process of claim 5.

[0222] Step G: Assign to the fast / enhanced group?

[0223] Based on the consensus grouping results: if the terminal is assigned to the fast consensus group or the enhanced verification group, its behavior is deemed trustworthy, and step H is executed; if it is assigned to the observation state or the isolation group, step I is executed.

[0224] Step H, Restore Online

[0225] Once the terminal returns to online status, it can receive subsequent encrypted fragments and participate in key reassembly normally, and its trust score is gradually restored according to the consensus result.

[0226] Step 1: Maintain isolation / under observation

[0227] The terminal maintains its current group status, and its trust score is updated according to the isolation group rules. It will not participate in key reassessment for the time being, and will wait for the next agenda item to be re-evaluated.

[0228] Step J: After the threshold is lowered by 1, is the change ≤ 1?

[0229] For terminals that have not reconnected, the system assesses the feasibility of lowering the threshold value: calculates the current threshold value minus 1 to obtain the new threshold value, and calculates the absolute value of the difference between the new threshold value and the original threshold value. If the absolute value is ≤ the first preset change threshold (i.e., 1), then step K is executed; otherwise, step L is executed.

[0230] Step K: Decrease the threshold value by 1 and recalculate the fragments.

[0231] The threshold value of the current agenda item is reduced by 1, and the encrypted fragments are recalculated for all online terminals based on the current freeze parameters, thereby reducing the number of terminals required to reassemble the key and allowing the meeting to continue.

[0232] Step L: Enable the HSM backup key, with a threshold value set to 2.

[0233] If lowering the threshold causes the change to exceed the limit or the threshold value is already at the minimum (2), the system automatically calls the backup key pre-stored in the hardware security module. This backup key is generated offline during the conference deployment phase, and its threshold value is fixed at the preset minimum threshold value 2.

[0234] Step M, Administrator Authorization

[0235] Enabling the backup key requires administrator authorization: After logging into the console via USB hardware token or digital certificate and confirming the dynamic verification code, the system releases the backup key and switches to the minimum threshold mode.

[0236] Step N, when the threshold / shard count jumps to >1 during agenda switching?

[0237] When switching each agenda item, the server compares the difference between the new threshold value t_new and the original threshold value t_old, as well as the difference between the new total number of shards n_new and the original total number of shards n_old. If any difference is greater than the first preset change threshold (1), it is determined that the parameter jump is abnormal, and step O is executed; otherwise, step T is executed.

[0238] Step 0: Generate a high-risk status identifier and push it to the console.

[0239] The system immediately generates a high-risk status identifier, which includes: event UUID, UTC timestamp, anomaly type (threshold jump / shard count jump), original parameter value, new parameter value, agenda identifier, and server node ID. This identifier is written to the server security audit log and pushed to the management console in real time, where it is highlighted in red.

[0240] Step P: Administrator confirms operation

[0241] The console forces administrators to confirm high-risk status identifiers, providing three optional responses:

[0242] Forced Implementation: If the jump is determined to be a normal fluctuation in the system, the meeting will continue using the new freeze parameters, requiring double review and authorization;

[0243] Extend Agenda: Maintain the original frozen parameters, and the current agenda item will automatically extend the preset duration (e.g., 15 minutes) without switching.

[0244] Terminating the meeting: Immediately terminate all terminal sessions, trigger a full trust reassessment, and add the affected terminals to the watch list.

[0245] Step Q: Use new parameters

[0246] After the administrator selects "force forward", the server broadcasts the new freeze parameters, and each terminal receives the encrypted fragments according to the new parameters and continues the meeting.

[0247] Step R: Maintain original parameters

[0248] After the administrator selects "Extend Agenda", the server retains the original frozen parameters, the timer for the current agenda item is reset, and the meeting continues according to the original security policy.

[0249] Step S: Full Trust Reassessment

[0250] After the administrator selects "Terminate Meeting", the server immediately disconnects all terminal connections, recalculates the trust score of each terminal based on historical behavior data, and archives the session logs along with the administrator's signature.

[0251] Step T: Normal Agenda Switch

[0252] If the parameter change is ≤1, the system determines it to be a smooth evolution, and normally switches to the next agenda item to re-execute. Figure 2 The process is shown below.

[0253] According to another aspect of the embodiments of this application, a secure information transmission system for multi-terminal online paperless meetings is also provided. For example... Figure 4 As shown, the system includes:

[0254] The pre-distribution unit 41 is used by the server to divide the meeting document into encrypted fragments according to the agenda items and pre-distribute them to each tablet terminal. The encrypted fragments are protected based on a chaotic system and a threshold cipher.

[0255] Construction unit 42 is used by each tablet terminal to construct a rendering decision graph based on the rendering instruction stream and extract rendering fingerprints. The nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of the rendering instructions.

[0256] Consensus unit 43 is used for each tablet terminal to calculate the similarity of its own rendering fingerprint with other tablet terminals and to execute the consensus protocol based on the similarity of the rendering fingerprint.

[0257] Generation unit 44 is used to generate a health index based on the execution result, and the health index is used to feed back and modulate the evolution parameters of the chaotic system.

[0258] Processing unit 45 is used to collect encrypted fragments that meet a threshold number of encryption fragments to reassemble the key and decrypt the local document during the agenda item process of each tablet terminal, and delete the reassembled key and fragments when the agenda item ends.

[0259] It should be noted that the embodiments implemented on the information security transmission system side of multi-terminal online paperless conferencing in this application can be referenced with the embodiments implemented on the information security transmission method side of multi-terminal online paperless conferencing, and will not be described in detail here.

[0260] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described method for secure information transmission in multi-terminal online paperless conferencing is also provided. This electronic device may be... Figure 5 The terminal device or server shown. This embodiment uses this electronic device as an example of a server. Figure 5 As shown, the electronic device includes a memory 402, a processor 404, and a transmission device 406. The memory 402 stores a computer program, and the processor 404 is configured to execute the steps of any of the above method embodiments through the computer program.

[0261] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0262] Optionally, the transmission device 406 is used to receive or send data via a network. Specific examples of the network described above may include wired and wireless networks. In one example, the transmission device 406 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 406 is a Radio Frequency (RF) module used to communicate with the Internet wirelessly. Furthermore, the electronic device also includes a display 408 and a connection bus 410, which connects the various module components within the electronic device.

[0263] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for secure information transmission in multi-terminal online paperless conferencing, characterized in that, include: S1, the server divides the meeting document into encrypted segments according to the agenda items and pre-distributes them to each tablet terminal. The encrypted segments are protected based on a chaotic system and a threshold cipher. S2, each tablet terminal constructs a rendering decision graph based on the rendering instruction stream and extracts the rendering fingerprint. The nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of the rendering instructions. S3, each tablet terminal calculates the similarity of its own rendering fingerprint with that of other tablet terminals, and executes the consensus protocol based on the rendering fingerprint similarity; S4, Generate a health index based on the execution result, and the health index is used to modulate the evolution parameters of the chaotic system. S5, during the agenda item, each tablet terminal collects encrypted fragments that meet the threshold number to reassemble the key and decrypt the local document. When the agenda item ends, the reassembled key and fragments are deleted.

2. The information security transmission method for multi-terminal online paperless conferencing according to claim 1, characterized in that, The chaotic system is a hyperchaotic Lorenz system; In S1, the protection based on chaotic systems and threshold cryptography includes: S11, the server samples the four-dimensional state vector of the hyperchaotic Lorenz system at the start of the agenda item; S12, the server generates an independent random salt value for each tablet terminal, determines the sharding point based on the hash operation of the agenda key, the random salt value and the hardware fingerprint of the tablet terminal, substitutes the sharding point into the threshold cryptographic polynomial to calculate the sharding value, and combines the sharding point and the sharding value into an encrypted shard and pre-distributes it. S13, the server broadcasts the freeze parameters to each tablet terminal, and the freeze parameters remain unchanged during this agenda item.

3. The information security transmission method for multi-terminal online paperless conferencing according to claim 2, characterized in that, The four-dimensional state vector includes a first state component, a second state component, a third state component, and a fourth state component. Specifically, the first state component and the second state component are extracted and subjected to modular prime number operations, and then used as the constant term coefficient and the linear term coefficient of the threshold cryptographic polynomial, respectively. The threshold value is determined by extracting the third state component, taking its absolute value, rounding it down, and performing modulo 3 plus 2 operations. The total number of slices is determined by extracting the fourth state component and combining it with the preset maximum number of flat plates. The threshold value, the total number of segments, and the constant term coefficient and linear term coefficient of the threshold cryptographic polynomial are used as the freezing parameters.

4. The information security transmission method for multi-terminal online paperless conferencing according to claim 1, characterized in that, The method further includes: S21, the newly added tablet terminal provides the server with a hardware fingerprint and a digital certificate issued by a certificate authority; S22, the server extracts the public key and validity period from the digital certificate, verifies that the current time is within the validity period, uses the public key of the certificate authority to verify the signature validity of the digital certificate, and queries the pre-stored certificate revocation list to confirm that the hardware fingerprint does not exist in the certificate revocation list; S23, the server generates a new random salt value for the newly added tablet terminal, and calculates a new sharding point and a new sharding value based on the freeze parameters of the current agenda item.

5. The information security transmission method for multi-terminal online paperless conferencing according to claim 1, characterized in that, In S2, the step of constructing a rendering decision graph and extracting rendering fingerprints based on the rendering instruction stream includes: S31, each tablet terminal captures the rendering instruction stream at the operating system layer and extracts the instruction type, target element identifier, timestamp and viewport coordinate range; S32, taking the document elements in the current viewport as nodes, for two document elements in the same rendering instruction sequence whose timestamp difference is less than a preset timing threshold, establish an edge between the two document elements, and construct the rendering decision graph with the reciprocal of the timestamp difference as the edge weight. S33, extract the node feature vectors and concatenate them into a feature vector of the preset input dimension; S34, the feature vector of the preset input dimension is processed by the hierarchical attention aggregation of the graph neural network, and compressed to 16-dimensional output through the encoding layer of the graph neural network to obtain a 16-dimensional rendering fingerprint vector. The hierarchical attention includes intra-element attention of the same type, inter-element attention of cross-type, and exponentially decaying temporal attention.

6. The information security transmission method for multi-terminal online paperless conferencing according to claim 5, characterized in that, The node feature vector includes: The following are considered as a function of the following: mapping element type to binary encoded vector with the dimension corresponding to the element type set to 1 and the other dimensions set to 0; rendering latency (the difference between the execution time and the reception time of the rendering instruction); pixel change (the ratio of the difference in pixel values ​​between the current frame and the previous frame); the hierarchical depth of the element in the document object model tree; and the relative chapter position (the ratio of the chapter number of the element to the total number of chapters in the document).

7. The information security transmission method for multi-terminal online paperless conferencing according to claim 5, characterized in that, In S3, each tablet terminal calculates its own rendering fingerprint similarity to that of other tablet terminals, and executes a consensus protocol based on the rendering fingerprint similarity, including: S41, Each tablet terminal calculates its own viewport overlap and rendered fingerprint similarity with other tablet terminals. S42, determine whether the viewport overlap is greater than a first preset overlap threshold and whether the rendering fingerprint similarity is greater than a first preset similarity threshold. If so, it is assigned to the fast consensus group and the simplified consensus process is executed. S43, determine whether the viewport overlap is greater than or equal to the second preset overlap threshold and less than or equal to the first preset overlap threshold, and determine whether the rendering fingerprint similarity is greater than or equal to the second preset similarity threshold and less than or equal to the first preset similarity threshold. If so, it is included in the enhanced verification group and the enhanced verification process is executed.

8. The information security transmission method for multi-terminal online paperless conferencing according to claim 7, characterized in that, The method further includes: S44, determine whether the viewport overlap is less than the second preset overlap threshold and whether the semantic distance is less than the preset semantic threshold. If so, mark it as an observation state. The tablet terminal in the observation state does not participate in the consensus protocol of the current agenda item, and its trust score remains unchanged. S41 to S43 are re-executed when the next agenda item begins. S45, determine whether the viewport overlap is less than the second preset overlap threshold and whether the semantic distance is greater than or equal to the preset semantic threshold. If so, classify it into the isolation group and trigger a security response.

9. The information security transmission method for multi-terminal online paperless conferencing according to claim 7, characterized in that, In S4, a health index is generated based on the execution results, and the evolution parameters of the chaotic system are fed back to modulate them, including: S61, calculate the health index based on the trust score of each tablet terminal in the fast consensus group, whereby the health index is the ratio of the sum of trust scores of the fast consensus group to the sum of trust scores of all online terminals. S62, modulate the dissipation parameters of the chaotic system with the health index.

10. A secure information transmission system for multi-terminal online paperless conferencing, the system implementing the secure information transmission method for multi-terminal online paperless conferencing as described in claim 1, characterized in that, include: The pre-distribution unit is used by the server to divide the meeting document into encrypted fragments according to the agenda items and pre-distribute them to each tablet terminal. The encrypted fragments are protected based on a chaotic system and a threshold cipher. The construction unit is used by each tablet terminal to construct a rendering decision graph based on the rendering instruction stream and extract rendering fingerprints. The nodes of the rendering decision graph represent document elements within the viewport, and the edge weights represent the temporal correlation strength of the rendering instructions. The consensus unit is used by each tablet terminal to calculate the similarity of its own rendering fingerprint with that of other tablet terminals, and to execute the consensus protocol based on the similarity of the rendering fingerprint. A generation unit is used to generate a health index based on the execution results, and the health index is used to modulate the evolution parameters of the chaotic system. The processing unit is used by each tablet terminal to collect encrypted fragments that meet a threshold number of times during the agenda item process to reassemble the key and decrypt the local document, and delete the reassembled key and fragments when the agenda item ends.

Images