A whole-process delivery and return method of electronic documents

Abstract

The application discloses a kind of electronic document full-process delivery and back certificate method.Service end divides original document logic into slice sequence, generates pseudo-random master key and allocates initial decryption key for first slice;Client and service end establish two-way secure data flow channel and extract export key material to establish binding relationship;Service end issues first slice ciphertext and decryption key, and client renders and is monitored by viewport observer to monitor visible state;When visible overlap area meets preset exposure condition, read hardware rendering fingerprint features affected by graphics computing hardware architecture, calculate micro-state proof data and return;After service end verification, it is used as input salt value, and the decryption key of next sequence slice is calculated on site;After full-amount interaction is completed, micro-state proof data sequence is aggregated to build Merkle tree, and root hash value is entered together with sequence into tamper-proof medium to form final back certificate credential.

Description

Technical Field

[0001] This invention relates to the fields of information security and electronic evidence preservation, specifically to a method for the full-process delivery and return of electronic documents. Background Technology

[0002] With the rapid advancement of e-government and digitalization of the judiciary, electronic document delivery has become an important means for various government platforms, judicial organs, and enterprises to send important documents. Compared with traditional paper mail delivery, electronic document delivery breaks the limitations of physical space and has advantages such as fast transmission speed, low circulation cost, and convenient operation, thus improving the overall efficiency of cross-regional business processing and document circulation.

[0003] In existing electronic document delivery applications, systems typically rely on SMS links, emails, or dedicated business clients to push notifications to recipients. After the recipient clicks the link or opens the target file on their terminal device, the system's front-end application captures the corresponding click or page load event and sends a status confirmation receipt to the server. Upon receiving the status confirmation receipt, the server records the document's access time and account information, thereby generating electronic proof data indicating that the document has been read and delivered.

[0004] However, existing electronic document delivery mechanisms primarily rely on surface-level business logic—such as the recipient actively clicking to confirm or the front-end page loading—to generate delivery receipts. This makes it difficult to effectively distinguish between genuine user reading behavior and automated program simulations. In scenarios involving delivery evasion, recipients can use headless browsers, automated data scraping scripts, or virtual environments to simulate page access and clicks, sending false reading response records to the server. This type of status receipt, based solely on the software application layer, is easily forged by automated programs. This makes it impossible for the server to verify whether the electronic document has been effectively exposed and objectively rendered on the physical display screen of the terminal device. Consequently, the generated delivery receipt lacks multi-dimensional physical rendering evidence, posing a risk of being questioned under strict evidence review standards. Summary of the Invention

[0005] The technical problem to be solved by this invention is that the existing electronic document delivery mechanism relies solely on the status receipts of the pure software application layer, which are easily forged by automated programs. As a result, the generated delivery receipts lack the support of physical rendering evidence at the underlying hardware level, and there is a risk that the evidentiary effect will be negated in the judicial evidence presentation stage. This invention provides a method for the full-process delivery and receipt of electronic documents.

[0006] This invention provides a method for the entire process of delivering and receiving proof of electronic documents, comprising the following steps:

[0007] Step S100: The document slicing engine configured in the server reads the original document to be delivered imported by the system, performs logical slicing operation, generates multiple data slice sequences arranged in order, and the key derivation center generates the pseudo-random master key for this delivery task and independently generates the initial decryption key for the first slice.

[0008] Step S200: The client establishes an end-to-end bidirectional secure data flow channel with the session control node configured in the server based on the user's access behavior, extracts symmetric exported key material, and establishes the cryptographic binding relationship between the application layer business and the underlying physical transmission session.

[0009] Step S300: The session control node sends the first slice ciphertext and initial decryption key to the streaming decryption module configured in the client. The client drives the front-end component to perform view rendering, and the viewport observer monitors the visible coordinate status of the slice content on the physical display device in real time.

[0010] Step S400: When the viewport observer determines that the visible overlap area meets the preset exposure conditions, the underlying hardware call interface is woken up, the hardware rendering fingerprint features affected by the graphics computing hardware architecture are read, and the micro-state calculation unit uses the hash features of the current slice, the exported key material, the system clock parameters and the hardware rendering fingerprint features to perform cascade splicing operations, calculate and output the micro-state proof data corresponding to the current slice rendering action.

[0011] Step S500: The client sends the microstate proof data back to the server. The session control node verifies the consistency of the session identification code contained in the microstate proof data and the legal distribution range of the physical feature values. After the verification is successful, the key derivation center uses the microstate proof data as the context information parameter of the derivation function to calculate the decryption key of the next sequence slice on the spot.

[0012] Step S600: After the document global slicing interaction is completed, the return certificate storage library configured in the server aggregates the micro-state proof data sequence collected during the single delivery lifecycle, constructs a Merkle tree in time series arrangement, extracts the root hash value of the Merkle tree, and enters it together with the micro-state proof data sequence into an immutable medium to form the final return certificate.

[0013] Further, in step S100, a logical segmentation operation is performed to generate multiple sequentially arranged data slice sequences. Specifically, this includes: identifying the file format of the original electronic document data; when the original electronic document data is a structured document based on Extensible Markup Language or Hypertext Markup Language, calling the Document Object Model parser to construct a document tree structure, traversing the document tree structure, extracting nodes with independent visual presentation meaning as segmentation boundaries, and extracting the data block corresponding to each node as an independent plaintext slice; when the original electronic document data is an unstructured binary file or a plain text file, using a fixed byte length threshold as a boundary condition, extracting data blocks according to a preset byte size, and for data blocks at the end of the file that are less than the preset byte size, using the Public Key Cryptography Standard VII padding algorithm to pad the data blocks at the end of the file to the preset byte size, forming plaintext slices of uniform length; assigning an incremental sequence index value to each generated plaintext slice, binding the sequence index value with the corresponding plaintext slice data, and combining them to form a plaintext slice sequence with a sequential relationship.

[0014] Further, in steps S300 and S400, determining that the visible overlap area meets the preset exposure conditions specifically includes: the viewport observer acquiring the physical visible screen matrix parameters of the terminal device and the bounding box coordinate matrix parameters of the rendered element corresponding to the first plaintext slice; calculating the visible overlap area ratio of the rendered element within the physical display screen based on the physical visible screen matrix parameters and the bounding box coordinate matrix parameters; comparing the calculated visible overlap area ratio with the spatial exposure threshold; when the visible overlap area ratio reaches or exceeds the spatial exposure threshold, starting the terminal application layer timer to record the dwell time of the rendered element maintaining the spatial exposure condition; when the dwell time is greater than or equal to the cognitive threshold time, determining that the first plaintext slice has undergone effective viewport exposure on the terminal device and meets the preset exposure conditions.

[0015] Further, in step S400, reading the hardware rendering fingerprint features affected by the graphics computing hardware architecture specifically includes: the underlying hardware calling interface creating an off-screen rendering context object independent of the main interface in the memory sandbox of the terminal device, and triggering the i-th element of the space exposure condition. The glyph contour data or image pixel data of a plaintext slice are converted into vertex data streams and texture mapping parameters; the anti-aliasing rendering mode of the off-screen rendering context object is configured to be enabled, and the floating-point operation precision inside the fragment shader is set to the highest hardware precision level supported by the current terminal device; before the graphics processor completes the drawing task of the current frame and before the image data is exchanged to the physical display screen, the underlying hardware call interface sends a hardware-level pixel reading instruction to the off-screen rendering context object to extract two-dimensional pixel array data containing hardware rendering fingerprint characteristics from the specified memory address block of the frame buffer; the red, green, blue, and transparency (RGBA) channel values ​​contained in the extracted two-dimensional pixel array data are sequentially expanded according to a fixed bit depth of 8 bits per channel and a preset pixel bit order, serialized into one-dimensional byte stream data, and the one-dimensional byte stream data is compressed using a preset hash function to output a fixed-length hardware physical entropy parameter, and the hardware physical entropy parameter is used as the hardware rendering fingerprint feature.

[0016] Further, in step S400, the microstate proof data corresponding to the current slice rendering action is calculated and output, specifically including: the microstate calculation unit extracts the ciphertext of the i-th slice, derives the key material and hardware physical entropy parameters, calls a lightweight hash function to perform a one-way hash operation on the ciphertext of the i-th slice, and outputs a fixed-length ciphertext hash feature; calls the system clock application programming interface to obtain the system timestamp corresponding to the time of extracting the hardware physical entropy parameters; performs formatting and alignment operations on the extracted parameters, and performs concatenation and splicing operations on the formatted parameters according to preset permutation and combination rules to construct composite byte stream data; calls a secure one-way hash algorithm to perform compression operations on the composite byte stream data, and outputs the microstate proof data.

[0017] Further, in step S500, verifying the consistency of the session identification code and the legal distribution range of physical feature values ​​contained in the microstate proof data specifically includes: performing physical time offset verification: extracting the server-sent timestamp when the ciphertext of the i-th slice is sent, and calculating the legal return time window boundary corresponding to the current plaintext slice in combination with the round-trip delay parameters provided by the underlying network protocol stack, comparing it with the received system timestamp, and determining that the physical time offset verification is passed when the system timestamp is within the legal return time window boundary; performing hardware tolerance distribution verification: mapping the hardware physical entropy parameters in the microstate proof data packet to numerical feature vectors, calculating the Euclidean distance between the numerical feature vectors and the historical feature vectors contained in the previous set of hardware physical entropy parameters, and using the Euclidean distance as the statistical variance offset, when the statistical variance offset is within the physical hardware natural tolerance distribution range, the physical time offset verification is passed. When the noise fluctuation range is within the specified range, the hardware tolerance distribution verification is deemed successful. Integrity recalculation verification is then performed: the encrypted hash feature stored locally on the server is extracted along with the exported key material bound to the current physical session. The encrypted hash feature, exported key material, system timestamp, and hardware physical entropy parameters are converted to big-endian order and bit-joined to generate a server-side verification composite byte stream. A secure one-way hash algorithm is then called to compress the server-side verification composite byte stream and output the server-side expected microstate hash value. When the server-side expected microstate hash value is completely consistent with the microstate proof data, the microstate proof data packet is determined to be unaltered and originates from the current legitimate physical communication session.

[0018] Further, in step S500, the microstate proof data is used as the input salt value of the derivation function to calculate the decryption key for the next sequence slice on-site. Specifically, this includes: the key derivation center loading the microstate proof data into the input register of the computing memory as dynamic context information, establishing state dependency conditions that restrict the decryption progress of subsequent slices; constructing a non-confidential session salt value to identify the current derivation task, calling the hash-based message authentication code algorithm module, using the non-confidential session salt value as the input salt value parameter, and the pseudo-random master key as the input key material, and performing the underlying extraction stage calculation to obtain the pseudo-random key; performing hash operation using the pseudo-random key, microstate proof data, and a single-byte counter, and performing a fixed-length truncation operation on the output result according to the key length specified by the target decryption algorithm, calculating the next slice decryption key of the target length; and using the random bit stream output by the server's built-in hardware random number generator to perform an erasure operation on the physical memory address storing the pseudo-random key to eliminate the risk of extracting memory-resident data.

[0019] Furthermore, in step S600, before aggregating all microstate proof data sets collected within a single delivery lifecycle, a timing consistency check is performed. Specifically, this includes: initializing an ordered set structure in an independent memory isolation area on the server; encapsulating the microstate proof data and associated system timestamps into data nodes and appending them to the ordered set structure; checking whether the sequence index values ​​attached to the data nodes are continuous and monotonically increasing to obtain a continuous microstate proof data sequence; extracting the system timestamps from two adjacent data nodes; calculating the actual time interval between effective viewport exposures of adjacent plaintext slices on the client terminal device; extracting the total number of characters contained in the i-th plaintext slice and dividing the total number of characters by a preset baseline reading rate constant to obtain the minimum slice reading time corresponding to the i-th plaintext slice; traversing and verifying each set of time intervals in the microstate proof data sequence; if any actual time interval is less than the corresponding minimum slice reading time, triggering an exception handling instruction to clear the microstate proof data sequence; and locking the microstate proof data sequence as a valid original evidence set when all contained actual time intervals are greater than or equal to the corresponding minimum slice reading time.

[0020] Furthermore, the generation process of the pseudo-random master key and derived key materials specifically includes: the key derivation center uses a configured hardware random number generator to collect phase jitter data of the microprocessor's ring oscillator or semiconductor thermal noise data to extract the initial entropy value, and inputs the initial entropy value into a deterministic random bit generator based on hash-based message authentication codes to generate a pseudo-random master key; the client and server initiate an asymmetric key exchange using an elliptic curve-based Diffie-Hellman key exchange protocol, respectively generating elliptic curve temporary private keys and corresponding public keys and performing the exchange; the shared pre-master key is calculated by performing scalar multiplication operations using the temporary private key and the public key; the underlying network protocol stack uses the pre-master key and the random numbers of both communicating parties to generate the master key for the secure transport layer, and calls the key derivation function based on the master key for the secure transport layer to calculate and output the derived key materials.

[0021] Further, in step S600, the root hash value of the Merkle tree is extracted and entered into an immutable medium along with the microstate proof data set to form the final proof credential. Specifically, this includes: performing byte-formatted encapsulation on the root hash value of the Merkle tree, the global file hash value of the original electronic document, the application layer business serial number of the delivery task, and the current server's issuance timestamp; calling the asymmetric encryption private key configured in the server to perform digital signature operation on the encapsulated byte stream data to generate an electronic proof data package with the server's digital signature; calling the smart contract application interface opened by the consortium blockchain network node to encapsulate the electronic proof data package into a standard blockchain transaction message and broadcast it to the consortium blockchain network; the participating nodes of the consortium blockchain network perform legality verification and packaging confirmation operations on the blockchain transaction message through a consensus algorithm, persistently recording the electronic proof data package in the block of the distributed ledger, returning the proof transaction hash value to the server, and combining the proof transaction hash value, the electronic proof data package, and the microstate proof data set into the final proof credential.

[0022] The present invention, by adopting the above technical solution, can bring the following beneficial effects:

[0023] 1. This invention awakens the underlying hardware interface to read the inherent hardware rendering fingerprint features of the graphics processor when the viewport observer determines that the slice content meets the exposure conditions. The hardware rendering fingerprint features are then concatenated with the slice hash features and timestamps to generate micro-state proof data. This invention realizes a technical solution that uses the discrete rendering fingerprint of the underlying hardware as rendering credentials. This effectively increases the technical difficulty of forging reading records using headless browsers or automated scripts, and improves the credibility of the effective exposure and objective rendering of electronic documents on the recipient's real physical terminal device.

[0024] 2. This invention establishes the cryptographic binding relationship between physical communication and application layer services by extracting the derived key material generated by the interaction of the underlying network protocol stack. It also uses the micro-state proof data containing hardware physical characteristics as the context information parameter of the derived function to calculate the decryption key of the next sequence slice on the spot. This achieves forward state dependency control that prevents the server from generating the next segment decryption key before obtaining a valid rendering proof. It avoids offline forgery and replay attacks from the underlying communication protocol level and ensures that the ciphertext generation progress of the document content is strictly controlled by the terminal physical rendering progress.

[0025] 3. This invention performs a time-series comparison by calculating the actual exposure time interval of the slice and the minimum reading time determined based on the total number of characters. It then uses the verified micro-state proof sequence as leaf nodes to construct a Merkle tree, extracts the root hash value, and packages and broadcasts it to a consortium blockchain network for persistent recording. This achieves dual solidification storage of the document interaction process at both the temporal logic and distributed consensus levels, constructs an anti-tampering evidence chain covering the physical rendering state of the document's global slices, and provides a trusted electronic evidence chain with multi-dimensional underlying technical support for delivery services. Attached Figure Description

[0026] Figure 1 This is a diagram illustrating the overall architecture of the electronic document delivery and return system of the present invention.

[0027] Figure 2 This is the overall flowchart of the electronic document delivery and return confirmation method of the present invention;

[0028] Figure 3 This is a schematic diagram of the hardware physical entropy extraction and microstate proof generation logic of the present invention;

[0029] Figure 4 This is a schematic diagram illustrating the construction of the Merkle Tree based on the microstate proof sequence of this invention. Detailed Implementation

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

[0031] Example 1

[0032] See attached document Figure 1-2 This invention provides a method for the entire process of delivering and receiving proof of electronic documents, comprising the following steps:

[0033] Step S100: The document slicing engine 110 configured in the server 100 reads the original document to be delivered imported by the system, performs logical slicing operations, generates multiple sequentially arranged data slice sequences, and the key derivation center 130 generates the pseudo-random master key for this delivery task. And independently generate the initial decryption key for the first slice. ;

[0034] Step S200: Based on user access behavior, client 200 establishes an end-to-end bidirectional secure data stream channel with session control node 120 configured in server 100. The application layers of client 200 and server 100 respectively call the underlying transport protocol open interface to extract symmetric derived key material from the current physical network handshake state. This establishes a cryptographic binding relationship between application layer services and underlying physical transmission sessions;

[0035] Step S300: The session control node 120 configured in the server 100 sends the first slice ciphertext separately to the streaming decryption module 210 configured in the client 200. and the initial decryption key After the client 200 decrypts the data in memory, it drives the front-end component to perform view rendering. The viewport observer 220 then starts to monitor the visible coordinates of the first slice content on the physical display device in real time.

[0036] Step S400: When the viewport observer 220 determines that the visible overlap area calculated from the slice content meets the preset exposure conditions, it wakes up the underlying hardware call interface 230 to intervene in the system operation. The underlying hardware call interface 230 triggers off-screen re-rendering of the currently rendered content. After the re-rendering is completed, it reads the hardware rendering fingerprint features affected by the graphics computing hardware architecture. The micro-state computing unit 240 then obtains the hash feature of the currently processed slice and exports the key material. System clock parameters In addition, hardware rendering fingerprint features are concatenated and spliced ​​to calculate and output the microstate proof data corresponding to the current slice rendering action. ;

[0037] Step S500: Client 200 uses the established bidirectional secure data stream channel to transmit microstate proof data. The data is sent back to server 100, where the session control node 120 configured within server 100 parses the microstate proof data. Verify microstate proof data After verifying the consistency of the session identification code and the legitimate distribution range of the physical feature values, the key derivation center 130 uses the microstate proof data. The context information parameter of the derived function is used to calculate the decryption key for the next sequence slice on-site. The control session control node 120 issues subsequent ciphertext and new decryption keys to achieve forward cascading control for exposing document content and forcibly collecting evidence;

[0038] Step S600: After all the slice interactions covering the entire document are completed, the return certificate storage library 140 configured in the server 100 aggregates all micro-state proof data sets collected during the single delivery lifecycle. The return certificate storage library 140 arranges the micro-state proof data sets in time sequence, treats the micro-state proof data sets as leaf node data, constructs a Merkle tree, extracts the root hash value of the Merkle tree, and enters it along with the micro-state proof data sets into an immutable medium to form the final return certificate.

[0039] Furthermore, the above-mentioned method for the full-process delivery and return of electronic documents is implemented based on an electronic document delivery and return system, which includes: a server 100 and a client 200 that communicates with the server 100.

[0040] The server 100 is configured to handle the original delivery task, manage the status of the underlying communication protocol, and generate cryptographic return certificates. The server 100 specifically includes a document slicing engine 110, a session control node 120, a key derivation center 130, and a return certificate storage library 140.

[0041] The document slicing engine 110 receives the original electronic document data D and converts it into a set of slice data with a sequential relationship according to set boundary conditions. These boundary conditions are specifically implemented as node-level parsing rules of the Document Object Model (DOM) or a fixed byte length threshold to ensure that the document is segmented into fragments suitable for streaming transmission and independent rendering. Specifically, the document slicing engine 110 divides the original electronic document data D into n ordered plaintext slice sequences, represented as follows: Where n is a positive integer greater than 1. This represents the i-th plaintext slice;

[0042] Session control node 120 is responsible for establishing and maintaining a secure transport layer connection with client 200. Session control node 120 extracts the exported key material from the current network connection context by calling the underlying network protocol stack. ;

[0043] Key Derivation Center 130 is used to generate the master key for the server system. Based on cryptographic algorithms, decryption keys are independently assigned and derived for each data slice. The key derivation center 130 is internally configured with a one-way key derivation function. The one-way key derivation function is configured to dynamically combine and generate the key data required for the next decryption based on the status parameters received in the previous interaction, thereby avoiding keeping the full key in memory at once.

[0044] The return certificate storage library 140 is used to receive and verify the status data from the client 200, and serialize the verified status data. The return certificate storage library 140 has embedded hash tree construction logic to construct the discrete status data into a Merkle tree structure, and uses the root node hash value finally extracted as a legally valid solid delivery certificate.

[0045] The client 200 is deployed in the terminal device held by the recipient and performs network ciphertext parsing, low-level hardware feature extraction and implicit status reporting. The client 200 specifically includes a streaming decryption module 210, a viewport observer 220, a low-level hardware call interface 230 and a micro-state calculation unit 240.

[0046] The streaming decryption module 210 is used to receive ciphertext of data slices sent by the server 100 in a bidirectional data stream. With the corresponding decryption key And perform symmetric decryption and restoration operations in an independent memory sandbox of the terminal device;

[0047] The viewport observer 220 is used to monitor the physical coordinate boundary of the visible area on the display screen of the terminal device. The viewport observer 220 calls the native view layer callback interface of the operating system or the browser kernel rendering listener interface to continuously calculate the layout position parameters of the decrypted and restored slice content in the screen global coordinate system, and calculates the overlap area between the layout position parameters and the physical visible screen matrix of the current terminal device to numerically determine whether the slice content has been truly exposed. The underlying hardware call interface 230 connects to and penetrates to the graphics processor hardware driver layer of the terminal device.

[0048] The underlying hardware call interface 230 is configured to intercept hardware data during the polygon rasterization or anti-aliasing calculation stage when the graphics interface rendering pipeline is active. In this embodiment, the underlying hardware call interface 230 specifically calls the rendering context object of WebGL or a similar graphics library, executes pixel reading instructions to obtain the pixel data array of the current frame buffer, reads floating-point precision truncated data or depth buffer feature tolerance generated in the underlying calculation, and uses the floating-point precision truncated data or depth buffer feature tolerance as a hardware physical entropy parameter characterizing the unique characteristics of the current physical device. ;

[0049] The micro-state computation unit 240 is used to aggregate the aforementioned multi-dimensional parameters. The micro-state computation unit 240 extracts the hash features of the current processing slice and derives the key material. System clock parameters and hardware physical entropy parameters Based on a secure hash algorithm, the above fields are combined and concatenated to calculate and output microstate proof data for the current interaction behavior. .

[0050] Example 2

[0051] See attached document Figure 3-4 In step S100, the document slicing engine 110 in the server 100 reads the original electronic document data to be delivered. Original electronic document data Including text, images, and typography metadata, the document slicing engine 110 pairs of raw electronic document data. The specific steps for performing logical boundary determination and data segmentation are as follows:

[0052] Step S111: The document slicing engine 110 identifies the original electronic document data. The file format, when the original electronic document data When processing structured documents based on Extensible Markup Language or Hypertext Markup Language, the document slicing engine 110 calls the Document Object Model parser to construct a document tree structure. The document slicing engine 110 traverses the document tree structure and extracts nodes with independent visual presentation meaning as slicing boundaries. In specific implementation, nodes with independent visual presentation meaning include paragraph label nodes, image label nodes, or table label nodes. The document slicing engine 110 extracts the data block corresponding to each node into an independent plaintext slice according to the depth-first traversal order of the nodes in the document tree structure.

[0053] Step S112: When the original electronic document data When the file is an unstructured binary file or a plain text file, the document slicing engine 110 uses a fixed byte length threshold as a boundary condition. The document slicing engine 110 extracts data blocks according to the preset byte size. For data blocks that are at the end of the file and are less than the preset byte size, the document slicing engine 110 uses the Public Key Cryptography Standard No. 7 (PKCS#7) padding algorithm to pad the data blocks at the end of the file to the preset byte size, forming plaintext slices of uniform length.

[0054] Step S113: The document slicing engine 110 assigns an incrementing sequence index value to each generated plaintext slice. The document slicing engine 110 binds the sequence index value with the corresponding plaintext slice data, combining them to form a plaintext slice sequence with a sequential relationship. Where n is a positive integer greater than 1. This represents the i-th plaintext slice;

[0055] S114: The key derivation center 130 uses the hardware random number generator 131 configured within the server 100 to generate a pseudo-random master key for a single delivery task. Pseudo-random master key As the foundational root key for the subsequent dynamic decryption keys of each slice, it resides in the secure memory area of ​​the server within the lifecycle of a single delivery task.

[0056] Step S115: The key derivation center 130 independently generates the initial decryption key using the hardware random number generator 131. and the initial decryption key Assigned to plaintext slice sequence The first plaintext slice in ;

[0057] Step S116: Server 100 calls the symmetric encryption algorithm using the initial decryption key. For the first plaintext slice Perform encryption operations to generate the first slice of ciphertext. Subsequent plaintext slices will not undergo static pre-encryption and will not be assigned corresponding decryption keys. This establishes the state dependency of slice data during network transmission and rendering. Specifically, the symmetric encryption algorithm uses the Advanced Encryption Standard (AES) algorithm, implemented in Galois / counter mode. In Galois / counter mode, the output slice ciphertext... At the same time, add certification label The specific encryption formula is as follows:

[0058] ,

[0059] in, For the configured initialization vector, This indicates the Galois / counter mode of the Advanced Encryption Standard algorithm. Client 200 verifies the authentication tag during the subsequent decryption phase. Confirm the ciphertext of the slice It was not tampered with during transmission.

[0060] Furthermore, in step S200, the key derivation center 130 and the streaming decryption module 210 within the server 100 collaboratively perform the initialization of underlying cryptographic parameters and streaming encrypted transmission. To address replay attacks in the network transmission environment, the system introduces a physical true random number generator and an elliptic curve asymmetric key exchange algorithm. The specific steps are as follows:

[0061] Step S211: The hardware random number generator 131 in the key derivation center 130 collects physical environment noise to extract the initial entropy value. The specific implementation of the physical environment noise includes phase jitter data of the microprocessor's ring oscillator or semiconductor thermal noise data. The hardware random number generator 131 inputs the initial entropy value into a deterministic random bit generator based on hash-based message authentication codes, and calls the SHA-256 hash function to generate a pseudo-random master key for a single delivery task. By performing hardware physical entropy extraction operations at the physical layer, this embodiment achieves the high entropy requirement for the pseudo-random master key described in the specification, ensuring the pseudo-random master key... The unpredictability of this is to support the subsequent key derivation logic;

[0062] Step S212: Server 100 and client 200 initiate asymmetric key exchange through session control node 120. In this embodiment, the Diffie-Hellman key exchange protocol based on elliptic curves is adopted. Server 100 and client 200 generate elliptic curve temporary private keys and corresponding public keys through their respective computing resources, and exchange public key data through public network channels.

[0063] Step S213: Server 100 performs scalar multiplication with client 200's public key using its temporary private key to calculate a shared pre-master key. Client 200 performs symmetric mathematical operations to obtain the same pre-master key. The underlying network protocol stack uses the pre-master key and random numbers from both communicating parties to generate a master key for the secure transport layer, and extracts the derived key material based on the master key. ;

[0064] Step S214: During the streaming encrypted transmission phase, when server 100 receives and verifies the data from client 200... Individual state proof data Subsequently, the key derivation center 130 performs dynamic key derivation calculation, where i is a positive integer greater than or equal to 2. The key derivation center 130 calls the hash-based message authentication code key derivation function, and the key derivation center 130 stores the pseudo-random master key in the secure memory area of ​​the server 100. As input key material, the first Individual state proof data As a specific salt value parameter (Salt), the application layer context information string is input as an extended information parameter (Info) into the hash-based message authentication code key derivation function;

[0065] Step S215: The specific calculation process of the hash-based message authentication code key derivation function is expressed as follows:

[0066] ki = HKDF_Expand(HKDF_Extract( ,KM),Info,L)

[0067] in, Indicates the derived output used for the first The decryption key for a plaintext slice ; This represents the extraction stage function, configured to extract a pseudo-random key from the input material; This represents a non-confidential random salt value. In this embodiment, Specifically, the configuration involves concatenating the session identifier and timestamp generated when the server (100) and client (200) establish a connection, ensuring that the salt value is bound to the current communication session; utilizing... Instead of a standard random salt value, this ensures that the derivation of the current key is strictly dependent on the physical proof of the preceding rendered state; This indicates the expansion phase function, configured to expand the extracted pseudo-random key to the required length; Info represents the context information string used to identify the current derived task. Indicates the specified byte length of the output decryption key;

[0068] Step S216: Server 100 obtains the derived decryption key. Then, the Advanced Encryption Standard (AES) algorithm is invoked to process the first... plaintext slice Perform encryption operation and output the first... A slice of ciphertext Since the system does not perform a one-time static pre-encryption on all documents in the initial stage, this streaming processing logic that relies on prior physical rendering proof to derive keys and implement encryption establishes and maintains a technical constraint relationship where the progress of ciphertext generation of document content is controlled by the client's 200 physical rendering progress.

[0069] Step S217: Server 100 will generate the first A slice of ciphertext With decryption key The data is transmitted to client 200 via the established two-way secure data stream channel, and client 200 receives the sliced ​​ciphertext. With decryption key Then, symmetric decryption and view rendering are performed in the memory sandbox of the terminal device to complete the closed loop of a single streaming data interaction.

[0070] Furthermore, in step S300, before executing the document delivery task, the client 200 and the server 100 are configured to establish a bidirectional secure data channel with anti-replay characteristics at the network layer. The system binds the network communication state with the upper-layer business logic through the underlying cryptographic protocol. The specific steps are as follows:

[0071] Step S311: After receiving the access instruction, the client 200 initiates a connection request to the session control node 120 configured in the server 100 through the underlying network components. The client 200 and the server 100 start an encrypted handshake process based on the QUIC protocol or the secure transport layer protocol. The client 200 sends a handshake request message containing the supported cipher suite sequence and the client random number to the server 100. The server 100 responds to confirm the selected cipher suite and returns the server random number and digital certificate.

[0072] Step S312: During the encrypted handshake phase, the underlying network protocol stacks of client 200 and server 100 independently calculate and generate the secure transport layer master key for the current physical network session based on the pre-master key negotiated in the previous interaction steps and the random numbers exchanged between the two parties. The secure transport layer master key resides in the network protocol stack memory area of ​​the operating system kernel and is not exposed to the business application layer. The secure transport layer master key establishes a technical association with the physical Internet protocol address, port number, and connection status of the Transmission Control Protocol or User Datagram Protocol for the current communication.

[0073] Step S313: The application layer business modules of client 200 and server 100 initiate requests to extract key materials by calling the secure application programming interface exposed by the operating system to their respective underlying network protocol stacks. In practice, the application layer business modules call the dedicated function for extracting key materials in the secure socket layer cryptographic library (such as the SSL_export_keying_material function in the OpenSSL library), or penetrate to the kernel network stack through the socket acquisition option (getsockopt) instruction of the operating system. After receiving the request, the underlying network protocol stack calls the key export function under the network security standard framework to calculate and output the key materials based on the secure transport layer master key. The specific formula for calculating the key derivation function is expressed as follows:

[0074]

[0075] in, This represents a pseudo-random function negotiated and determined within the framework of the secure transport layer protocol. This represents the secure transport layer master key residing in the underlying network protocol stack; This represents a preset ASCII string identifier used to distinguish different application layer services; The context hash value representing the current physical connection; Indicates the length in bytes of the requested key material; This represents a byte sequence concatenation operation;

[0076] Step S314: The session control node 120 configured within the server 100 obtains the exported key material from the underlying computation output. Then, the exported key material obtained by session control node 120 will be... Configure the physical session identifier for the current document delivery task. The server 100 performs key-value pair binding and storage of the physical session identifier and the application layer business serial number pre-assigned by the system in the system memory database.

[0077] Step S315: The application layer of client 200 synchronously extracts the same exported key material. And extract the exported key material from client 200. Cached in the local memory sandbox of the terminal device, it serves as the data salt for subsequent computation of microstate proofs and for exporting key materials. The calculations rely strictly on the secure transport layer master key and the physical connection context hash value within the underlying protocol stack. By intercepting document push links and using network packet forgery tools to initiate offline access requests, without establishing a complete physical network handshake, it is impossible to derive or obtain legitimate exported key materials. By calling the calculation and verification operations of the underlying exported key material, this embodiment establishes a cryptographic binding relationship between the application layer document delivery service and the physical transmission session of the recipient's terminal device at the underlying technology level.

[0078] Furthermore, in step S300, after establishing the physical session binding relationship between the network layer and the application layer, the system performs streaming delivery of document content data and monitoring of the terminal environment's exposure status. The specific steps are as follows:

[0079] Step S321: The session control node 120 configured within the server 100 utilizes the established bidirectional secure data stream channel to transmit the first slice of ciphertext. With the initial decryption key The first slice of ciphertext is sent to client 200, where the streaming decryption module 210 is configured to receive it. With the initial decryption key The streaming decryption module 210 calls the Advanced Encryption Standard algorithm to perform symmetric decryption operations in the independent memory sandbox of the terminal device to obtain the first plaintext slice. The streaming decryption module 210 will slice the first plaintext text. The layout and drawing are performed using the local rendering engine on the terminal device.

[0080] Step S322: The viewport observer 220 configured within the client 200 continuously monitors the first plaintext slice after layout and drawing. In the visible state displayed on the terminal device screen, specifically, the viewport observer 220 calls the cross-observer application interface provided by the browser kernel or the native view boundary listener interface of the mobile operating system to obtain the physical visible screen matrix parameters of the terminal device and the first plaintext slice. The bounding box coordinate matrix parameters of the corresponding rendered element;

[0081] Step S323: The viewport observer 220 calculates the visible overlap area ratio of the rendered elements within the physical display screen based on the physical visible screen matrix parameters and the bounding box coordinate matrix parameters. The specific formula for calculating the overlap area ratio is as follows:

[0082]

[0083] in, Indicates the ratio of visible overlap area; Represents the physical visible screen matrix; The bounding box coordinate matrix representing the rendered element; A function that calculates the area covered by a matrix; This represents the operation of finding the intersection region of two matrices;

[0084] Step S324: The viewport observer 220 calculates the visible overlap area ratio. Compare with the spatial exposure threshold, when the visible overlap area ratio When the spatial exposure threshold is reached or exceeded, the viewport observer 220 starts the terminal application layer timer to record the dwell time of the rendered element to maintain the spatial exposure condition. In specific implementation, the spatial exposure threshold is configured to a value greater than or equal to 50% to ensure that the main part of the rendered element enters the physical display screen of the terminal device.

[0085] Step S325: The viewport observer 220 compares the dwell time with the cognitive threshold time. In specific implementation, the cognitive threshold time is configured so that the viewport observer 220 calculates the time based on the first plaintext slice. The dynamic time parameter, obtained by dividing the total number of characters by the preset baseline reading speed, determines the first plaintext slice when the dwell time is greater than or equal to the cognitive threshold time. When a valid viewport exposure occurs on the terminal device, the viewport observer 220 generates a trigger command at the moment of determining that a valid viewport exposure has occurred, which wakes up the underlying hardware call interface 230 in the system to intervene in the system and perform subsequent physical feature extraction operations.

[0086] Furthermore, in step S400, after the system determines that a valid viewport exposure has occurred in the plaintext slice, the underlying hardware call interface 230 in the client 200 penetrates the application layer sandbox and directly controls the graphics hardware of the terminal device to execute customized rendering instructions in order to extract hardware physical entropy parameters that characterize the differences in physical device hardware architecture. The specific steps are as follows:

[0087] Step S411: The underlying hardware call interface 230 creates an off-screen rendering context object independent of the main interface in the graphics computing interface layer of the terminal device. In specific implementation, the underlying hardware call interface 230 calls the WebGL application interface or Metal graphics library to allocate independent vertex buffer and frame buffer objects in system memory and establish a direct interaction channel with the underlying graphics driver of the terminal device. Since conventional automated scripts or headless browsers usually lack the right to call the real physical graphics processor, they default to using the software rendering engine for pure mathematical standard rasterization, which cannot produce real hardware pipeline calculation features.

[0088] Step S412: The underlying hardware call interface 230 converts the glyph contour data or image pixel data of the i-th plaintext slice di that triggers the spatial exposure condition into vertex data stream and texture mapping parameters. In specific implementation, the underlying hardware call interface 230 triangulates the glyph contour data into polygon mesh vertices through the font rendering engine, or binds the image pixel data as texture to rectangular geometric primitives. The underlying hardware call interface 230 configures the anti-aliasing rendering mode of the off-screen rendering context object to be enabled, and sets the floating-point operation precision inside the fragment shader to the highest hardware precision level supported by the current terminal device.

[0089] Step S413: The graphics processor of the terminal device receives the vertex data stream and texture mapping parameters, and performs vertex shading, primitive assembly, polygon rasterization and fragment shading operations. Due to the differences in the edge anti-aliasing algorithm implementation in the polygon rasterization stage and the floating-point coordinate precision truncation mechanism in the fragment shading stage of different models and batches of graphics processors, the graphics processor will generate hardware rendering fingerprint features with discrete distribution in the pixel calculation results of the frame buffer.

[0090] Step S414: Before the graphics processor completes the drawing task of the current frame and exchanges the image data to the physical display screen, the underlying hardware call interface 230 sends a hardware-level pixel reading instruction to the off-screen rendering context object. In specific implementation, the underlying hardware call interface 230 executes the WebGL readPixels function or the operating system's underlying memory copy instruction to extract the two-dimensional pixel array data containing the hardware rendering fingerprint characteristics from the specified memory address block of the frame buffer.

[0091] Step S415: The underlying hardware call interface 230 unfolds the red, green, blue, and alpha (RGBA) channel values ​​contained in the extracted two-dimensional pixel array data according to the fixed bit depth of 8 bits per channel and the pixel position from left to right and from top to bottom, and serializes them into one-dimensional byte stream data. The micro-state calculation unit 240 uses a preset hash function to perform compression operation on the one-dimensional byte stream data and outputs a fixed-length hardware physical entropy parameter. The specific formula for calculating the hardware physical entropy parameter is expressed as follows:

[0092]

[0093] in, Indicates that for the first Hardware physical entropy parameters extracted during the rendering process of a plaintext slice; This represents the two-dimensional pixel array data extracted from the frame buffer; This is a serialization function that converts matrix-formatted memory data into a one-dimensional continuous byte stream sequence according to a fixed bit depth and a preset channel order. This refers to a secure one-way hash function used to extract the physical entropy feature distribution, specifically implemented as the SHA-256 algorithm or the national cryptographic SM3 hash algorithm. Based on the above steps, when the client does not enable GPU hardware acceleration or enables software rendering fallback mechanisms (such as SwiftShader or OSMesa), the extracted hardware physical entropy parameters show a significant difference from the actual GPU rendering results. This can be used as one of the auxiliary criteria for identifying automated scripts. The system extracts and calculates the hardware physical entropy parameters. This provides multi-dimensional statistical hardware feature data that increases the cost of forgery for subsequent microstate proof generation;

[0094] Further, in step S400, after obtaining the hardware physical entropy parameters, the microstate calculation unit 240 in the client 200 performs data serialization and hash compression operations to generate microstate proof data for the current interaction behavior. The specific calculation steps are as follows:

[0095] Step S421: The micro-state computing unit 240 extracts the first from the independent memory sandbox of the terminal device. A slice of ciphertext Export key materials cached in local memory And the hardware physical entropy parameters output by the underlying hardware call interface 230 The microstate computation unit 240 calls the lightweight hash function to process the first... A slice of ciphertext Perform a one-way hash operation and output a fixed-length ciphertext hash feature. The microstate computing unit 240 calls the system clock application programming interface to obtain and extract hardware physical entropy parameters. The system timestamp corresponding to the time System timestamp The precision is implemented at the millisecond or microsecond level to record the temporal dimension characteristics of physically rendered actions;

[0096] Step S422: The micro-state computation unit 240 performs a formatting and alignment operation on the extracted parameters. Specifically, the micro-state computation unit 240 uses the ciphertext hash features... Exporting key materials and hardware physical entropy parameters Based on preset fixed-length truncation or byte padding rules, it is unified into a standard big-endian byte array. In specific implementation, the ciphertext hash characteristics... Fixed at 32 bytes, export key material Fixed at 32 bytes, hardware physical entropy parameter Fixed at 64 bytes, the micro-state calculation unit 240 will use the system timestamp The encoding is a fixed-length 8-byte sequence of 64-bit unsigned integers. By limiting the fixed byte length of each feature field, structural ambiguity during subsequent concatenated data parsing is avoided. The micro-state calculation unit 240 uses the system timestamp... Encoded as a 64-bit unsigned integer byte sequence;

[0097] Step S423: The micro-state calculation unit 240 performs concatenation and splicing operations on the formatted parameters of each dimension according to the preset permutation and combination rules to construct composite byte stream data. The specific formula for calculating the composite byte stream is as follows:

[0098]

[0099] in, Indicates that for the first Composite byte stream data constructed from slices; Indicates the first The ciphertext hash characteristics output by performing a hash operation on the ciphertext slices; This represents a formatting function that converts input data into a big-endian byte array. This represents the encoding function that converts a time value into a 64-bit unsigned integer sequence; This represents a byte sequence concatenation operation;

[0100] Step S424: The microstate calculation unit 240 calls the secure one-way hash algorithm to process the composite byte stream data. Perform compression operations to output fixed-length microstate proof data. In practice, the secure one-way hash algorithm is implemented as either the national standard SM3 cryptographic hash algorithm or the SHA-3 secure hash algorithm, with microstate proof data. The specific calculation formula is expressed as follows:

[0101]

[0102] in, This indicates the national standard SM3 cryptographic hash algorithm or the third-generation secure hash algorithm configured in the system.

[0103] Step S425: The microstate calculation unit 240 generates the microstate proof data. The microstate proof data is written to the network transmission buffer of client 200. Client 200 then uses the established bidirectional secure data stream channel to transmit the microstate proof data. The data is sent back to server 100. By executing the above-mentioned serialization and hash calculation steps, the system establishes the technical relationship between the document rendering content, the underlying communication link, the physical exposure time, and the terminal hardware architecture.

[0104] Furthermore, in step S500, after receiving the data returned by the client 200, the session control node 120 within the server 100 performs a multi-dimensional legality verification operation. The session control node 120 identifies abnormal automated access requests by extracting communication link status, physical time offset, and hardware tolerance distribution parameters. The specific verification is as follows:

[0105] Step S511: Session control node 120 receives the microstate proof data packet returned by client 200 through a bidirectional secure data stream channel. The microstate proof data packet contains a system timestamp in plaintext. Hardware physical entropy parameters and microstate proof data Session control node 120 loads the microstate proof data packet into the secure memory isolation area of ​​server 100 for subsequent verification calculation;

[0106] Step S512: Session control node 120 performs physical time offset verification, and session control node 120 extracts and sends the first... A slice of ciphertext The server sends a timestamp at the specified time, and combines this with the network round-trip time (RTT) parameter provided by the underlying network protocol stack to calculate the boundary of the valid return certificate time window corresponding to the current plaintext slice. The specific formula for calculating the boundary of the valid return certificate time window is expressed as follows:

[0107]

[0108]

[0109] in, Indicates the starting boundary of the valid return time window; Indicates the termination boundary of the valid return time window; This represents the server-side sending timestamp when the server distributes the encrypted slice. Indicates the network round-trip time of the current physical network connection; This represents the estimated rendering time based on the number of characters contained in the slice and the terminal's baseline rendering rate. This indicates the preset network jitter and system processing tolerance time. Session control node 120 compares the received system timestamp. When the system timestamp Greater than or equal to the starting boundary And less than or equal to the termination boundary At that time, the physical time offset verification is deemed successful;

[0110] Step S513: Session control node 120 performs hardware tolerance distribution verification, and session control node 120 extracts the hardware physical entropy parameters from the microstate proof data packet. It also extracts the previously stored set of hardware physical entropy parameters from the historical interaction sequence. In specific implementation, the session control node 120 will use the hardware physical entropy parameters... The mapping is converted into a numerical feature vector. The Euclidean distance between the numerical feature vector and the historical feature vector contained in the previous set of physical entropy parameters of the hardware is calculated. The Euclidean distance is used as the statistical variance offset. The session control node 120 compares the statistical variance offset with the natural noise fluctuation range of the physical hardware. When the statistical variance offset is within the natural noise fluctuation range of the physical hardware, the hardware tolerance distribution verification is deemed to have passed.

[0111] Step S514: Session control node 120 performs session consistency and integrity recalculation verification, and session control node 120 extracts the ciphertext hash feature stored locally on server 100. Exported key material bound to the current physical session The session control node 120, following the formatting alignment rules agreed upon in the preceding steps, sets the ciphertext hash feature... Exporting key materials System timestamp With hardware physical entropy parameters Perform big-endian conversion and bit concatenation operations to generate a composite byte stream for server verification;

[0112] Step S515: Session control node 120 calls the secure one-way hash algorithm to compress the server-side verification composite byte stream and outputs the server-side expected micro-state hash value. Session control node 120 performs a byte comparison operation when the server expects the micro-state hash value. Microstate proof data carried in the microstate proof data packet If they are completely identical, the microstate proves that the data packet has not been tampered with and originates from the current legitimate physical communication session;

[0113] Step S516: After the physical time offset verification, hardware tolerance distribution verification, and integrity recalculation verification are all deemed successful, the session control node 120 sends a verification release signaling to the key derivation center 130. After receiving the verification release signaling, the key derivation center 130 extracts the microstate proof data. and microstate proof data The salt value parameter, as the input to the derived function, triggers the dynamic generation process of the decryption key for the next sequence slice.

[0114] Further, in step S500, the key derivation center 130 within the server 100 performs a state-dependent dynamic key derivation operation. The key derivation center 130 uses the physical rendering state features returned by the client 200 as input variables for cryptographic calculations, and synthesizes the data decryption key required subsequently. The specific execution steps are as follows:

[0115] Step S521: The key derivation center 130 receives the verification release signaling and microstate proof data sent by the session control node 120. The key derivation center 130 will provide microstate proof data. The data is loaded into the input register of computation memory as dynamic context information parameters, due to the microstate proof data. Includes the underlying hardware physical characteristics and real-time network link status of the recipient's terminal device, and microstate proof data. Establish state dependency conditions that restrict the progress of subsequent slice decryption;

[0116] Step S522: The key derivation center 130 reads the pseudo-random master key from the secure memory isolation area of ​​the server 100. The key derivation center 130 constructs a non-confidential session salt value (Salt) to identify the current derivation task. In specific implementation, the non-confidential session salt value (Salt) consists of a preset application layer protocol identifier and a target slice sequence index value. The current communication session identifier is constructed by binary concatenation to ensure that the derived output key is strictly bound to the decryption purpose of a specific slice;

[0117] Step S523: The key derivation center 130 calls the hash-based message authentication code algorithm module to perform the underlying extraction stage calculation. The key derivation center 130 uses the non-confidential session salt value Salt as the input salt value parameter for the algorithm extraction call, and the pseudo-random master key. As input key material, a hash operation is performed to obtain a pseudo-random key KPRK with uniform distribution characteristics;

[0118] Step S524: The key derivation center 130 calls the hash-based message authentication code algorithm module to perform the underlying extension stage calculation. The key derivation center 130 uses the pseudo-random key KPRK, the microstate proof data Ai as context information parameters, and a single-byte counter to perform hash operations. According to the key length specified by the target decryption algorithm, the output result is truncated to a fixed length, and the next slice decryption key of the target length is calculated. ;

[0119] Step S525: Key Derivation Center 130 decrypts the next slice key. The data is passed to the memory region configured within server 100 to perform encryption operations, in order to execute plaintext slicing. In the on-site encryption operation, the key derivation center 130 calls the system memory overwrite instruction and uses the random bit stream output by the hardware random number generator 131 built into the server 100 to store the pseudo-random key. The physical memory address is erased to eliminate the risk of extracting memory-resident data.

[0120] Furthermore, in step S600, the evidence storage repository 140 within the server 100 is configured to continuously collect micro-state proof data verified and released by the session control node 120 during the lifecycle of a single document delivery task. The evidence storage repository 140 blocks the behavior of tampering with or forging complete reading records using concurrent requests or timestamps by performing cache management and time sequence consistency verification. The specific execution steps are as follows:

[0121] Step S611: The evidence storage library 140 initializes an ordered set structure in the independent memory isolation area of ​​the server 100. Specifically, the ordered set structure is implemented as a doubly linked list or an ordered array with pre-allocated capacity. During the maintenance of the bidirectional secure data flow channel, whenever the session control node 120 completes the process of storing the first piece of evidence, the evidence storage library 140 initializes an ordered set structure in the independent memory isolation area of ​​the server 100. Individual state proof data For legality verification, retrieve micro-state proof data from the evidence storage repository 140. and associated system timestamps The microstate proof data will be stored in the evidence repository 140. With system timestamp Encapsulate it as a data node and append the data node to the end of the ordered set structure;

[0122] Step S612: Monitor the progress of adding data nodes in the evidence storage repository 140, after collecting data up to the [number missing]th [number missing]. Microstate proof data corresponding to each slice At that time, the evidence storage database traverses the ordered set structure 140 times, checking whether the sequence index values ​​attached to the data nodes are continuous and monotonically increasing. If the sequence index values ​​are continuous, the data nodes in the ordered set structure form a complete microstate proof data sequence. If the certificate storage library 140 determines that the sequence index value is missing or out of order, it will release the corresponding memory and block the current certificate generation process.

[0123] Step S613: After acquiring the continuous microstate proof data sequence, the proof storage library 140 triggers the timing verification logic, and the proof storage library 140 extracts the system timestamps from two adjacent data nodes. and Calculate the actual time interval between effective viewport exposures of adjacent plaintext slices on the client terminal device;

[0124] Step S614: The evidence storage repository 140 will return the calculated actual time interval. A numerical comparison is performed with the minimum slice reading time. In practice, the 140th slice is retrieved from the evidence storage database. The total number of characters contained in each plaintext slice is calculated by dividing the total number of characters by a preset baseline reading rate constant, multiplying by a content type coefficient corresponding to the slice's content type, and finally adding a preset minimum fixed dwell time to obtain the result corresponding to the first plaintext slice. The minimum slice reading time for a plaintext slice is calculated using the following formula:

[0125]

[0126] in, Indicates the first The minimum slice reading time corresponding to a plaintext slice; Indicates the first The total number of valid characters contained in a plaintext slice; This represents the baseline reading rate constant pre-configured on the server side (100). This is a content type coefficient used to differentiate the reading time weights for different types of content, such as plain text, images, or tables. This is a preset minimum fixed dwell time, used to tolerate network jitter and page loading latency as a baseline.

[0127] Step S615: Return to the evidence storage database 140 to traverse and verify each time interval in the microstate proof data sequence. If any actual time interval exists... Less than the corresponding minimum slice reading time The evidence storage library 140 determines that the microstate proof data sequence has failed the timing verification. The evidence storage library 140 triggers an exception handling instruction, clearing the microstate proof data sequence from the memory isolation area. All actual time intervals included All are greater than or equal to the corresponding minimum slice reading time At that time, the evidence storage library 140 locks the microstate proof data sequence into a legitimate set of original evidence.

[0128] Furthermore, in step S600, the evidence storage library 140 within the server 100 is configured to calculate and construct a Merkle tree data structure based on the verified micro-state proof data sequence, and convert the generated root hash value into an electronic evidence record with tamper-resistant properties. The specific execution steps are as follows:

[0129] Step S621: Retrieve the locked microstate proof data sequence from the evidence storage repository 140. The evidence storage library 140 will store each microstate proof data in the microstate proof data sequence. Configured as a bottom-level leaf node, the evidence storage library 140 performs two-bit concatenation on adjacent bottom-level leaf nodes and calls a secure one-way hash algorithm for compression to generate the hash value of the parent node at the next higher level. The specific formula for calculating the parent node hash value is expressed as follows:

[0130]

[0131] in, Indicates the first level of the previous level The hash value of each parent node; and These represent the left and right child node data of the current level, respectively; This indicates the secure one-way hash algorithm configured in the system. This indicates a byte sequence concatenation operation. During the first-level hash operation, the data of the left child node... With the data of the child nodes on the right They are respectively equal to the microstate proof data and When the total number of nodes at the current level is odd, the last node data is copied from the evidence storage library 140 to complete the pairing calculation.

[0132] Step S622: The evidence storage library 140 recursively executes the above node concatenation and hash operation steps. The evidence storage library 140 builds a tree-like data structure layer by layer upwards until a unique node data at the top level is generated. The evidence storage library 140 extracts the unique node data at the top level as the Merkle tree root hash. Merkel root hash Generate a global hash feature value that covers the rendering states of all slices of the original electronic document;

[0133] Step S623: The return receipt storage library 140 constructs an electronic return receipt data packet containing parameters related to the delivery business. In specific implementation, the return receipt storage library 140 uses the Merkle root hash... The global file hash value of the original electronic document, the application layer business serial number of the delivery task, and the current certificate issuance timestamp of the server 100 are byte-formatted and encapsulated. The certificate storage library 140 calls the asymmetric encryption private key configured in the server 100 to perform digital signature operation on the encapsulated byte stream data, generating an electronic certificate data packet with the server's digital signature. In specific implementation, the digital signature operation is implemented by calling the national cryptographic SM2 elliptic curve digital signature algorithm or the RSA digital signature algorithm, and the asymmetric encryption private key is the server's private key parameter generated by the corresponding algorithm.

[0134] Step S624: The certificate storage library 140 writes the electronic certificate data packet into an immutable medium for solidification storage. In specific implementation, the immutable medium is implemented as a consortium blockchain network based on a distributed consensus mechanism. The certificate storage library 140 calls the smart contract application interface opened by the consortium blockchain network node to encapsulate the electronic certificate data packet into a standard blockchain transaction message and broadcast the blockchain transaction message to the consortium blockchain network.

[0135] Step S625: Participating nodes in the consortium blockchain network receive blockchain transaction messages. These nodes perform legality verification and packaging confirmation operations on the blockchain transaction messages using a Byzantine fault-tolerant consensus algorithm. The electronic receipt data packet is persistently recorded in the distributed ledger's block. The receipt transaction hash value is returned to server 100. The receipt storage repository 140 associates and stores the receipt transaction hash value, the electronic receipt data packet, and the original microstate proof data sequence. The data includes the hash value of the stored transaction, the electronic receipt data packet, and the original microstate proof data sequence. As the recipient, the recipient has effectively exposed the multi-dimensional electronic evidence of the document on the terminal device.

Claims

1. A method for the end-to-end delivery and receipt of electronic documents, characterized in that, Includes the following steps: Step S100: The document slicing engine configured in the server reads the original document to be delivered imported by the system, performs logical slicing operation, generates multiple data slice sequences arranged in order, and the key derivation center generates the pseudo-random master key for this delivery task and independently generates the initial decryption key for the first slice. Step S200: The client establishes an end-to-end bidirectional secure data flow channel with the session control node configured in the server based on the user's access behavior. The application layers of the client and the server respectively call the underlying transport protocol open interface to extract symmetric exported key material from the current physical network handshake state and establish the cryptographic binding relationship between the application layer service and the underlying physical transport session. Step S300: The session control node sends the first slice ciphertext and initial decryption key separately to the streaming decryption module configured in the client. After the client decrypts in memory, it drives the front-end component to execute view rendering. The viewport observer is then started to monitor the visible coordinate status of the first slice content on the physical display device in real time. Step S400: When the viewport observer determines that the visible overlap area calculated by the slice content meets the preset exposure conditions, the underlying hardware call interface is woken up to intervene in the system operation. The underlying hardware call interface triggers off-screen re-rendering of the currently rendered content. After the re-rendering is completed, the hardware rendering fingerprint features affected by the graphics computing hardware architecture are read. The micro-state calculation unit then obtains the hash features of the currently processed slice, the exported key material, the system clock parameters, and the hardware rendering fingerprint features to perform cascade splicing operations and calculate and output the micro-state proof data corresponding to the current slice rendering action. Step S500: The client uses the established bidirectional secure data stream channel to send the microstate proof data back to the server. The session control node parses the microstate proof data, verifies the consistency of the session identification code contained in the microstate proof data and the legal distribution range of the hardware rendering fingerprint features. After verification, the key derivation center uses the microstate proof data as the context information parameter of the derivation function to calculate the decryption key of the next sequence slice on the spot, and controls the session control node to issue subsequent ciphertext and new decryption key, realizing forward cascading control of document content exposure and forced collection of proof. Step S600: After all the slice interactions covering the entire document are completed, the evidence storage library configured in the server aggregates all micro-state proof data sets collected during the single delivery lifecycle. The evidence storage library arranges the micro-state proof data sets in time sequence, treats the micro-state proof data sets as leaf node data, constructs a Merkle tree, extracts the root hash value of the Merkle tree, and records it along with the micro-state proof data sets into an immutable medium to form the final evidence.

2. The method for the full-process delivery and return of electronic documents according to claim 1, characterized in that, In step S100, a logical segmentation operation is performed to generate multiple sequentially arranged data slice sequences, specifically including: The file format of the original electronic document data is identified. When the original electronic document data is a structured document based on Extensible Markup Language or Hypertext Markup Language, the document object model parser is called to construct a document tree structure. The document tree structure is traversed, and nodes with independent visual presentation meaning are extracted as splitting boundaries. The data block corresponding to each node is extracted into an independent plaintext slice. When the original electronic document data is an unstructured binary file or a plain text file, a fixed byte length threshold is used as a boundary condition. Data blocks are extracted based on the preset byte size and combined with multi-byte character encoding boundary alignment rules to prevent character breakage caused by segmentation. For data blocks at the end of the file that are less than the preset byte size, the public key cryptography standard padding algorithm No. 7 is used to pad the data blocks at the end of the file to the preset byte size, forming plaintext slices of uniform length. Each generated plaintext slice is assigned an incremental sequence index value, and the sequence index value is bound to the corresponding plaintext slice data to form a plaintext slice sequence with a sequential relationship.

3. The method for the full-process delivery and return of electronic documents according to claim 1, characterized in that, In steps S300 and S400, determining whether the calculated visible overlap area of ​​the slice content meets the preset exposure conditions specifically includes: The viewport observer acquires the physical visible screen matrix parameters of the terminal device and the bounding box coordinate matrix parameters of the rendered element corresponding to the first plaintext slice; Based on the physical visible screen matrix parameters and the bounding box coordinate matrix parameters, the visible overlap area ratio of the rendered element within the physical display screen is calculated. The specific formula for calculating the overlap area ratio is as follows: in, Indicates the ratio of visible overlap area; Represents the physical visible screen matrix; The bounding box coordinate matrix representing the rendered element; A function that calculates the area covered by a matrix; This represents the operation of finding the intersection region of two matrices; The calculated visible overlap area ratio is compared with the spatial exposure threshold. When the visible overlap area ratio reaches or exceeds the spatial exposure threshold, a terminal application layer timer is started to record the dwell time of the rendered element to maintain the spatial exposure condition. When the dwell time is greater than or equal to the cognitive threshold time, it is determined that the first plaintext slice has a valid viewport exposure on the terminal device and meets the preset exposure condition.

4. The method for the full-process delivery and return of electronic documents according to claim 1, characterized in that, In step S400, reading the hardware rendering fingerprint features affected by the graphics computing hardware architecture specifically includes: The underlying hardware call interface creates an off-screen rendering context object, independent of the main interface, in the terminal device's memory sandbox, which will trigger the space exposure condition. The glyph contour data or image pixel data of a plaintext slice are converted into vertex data streams and texture mapping parameters; Configure the anti-aliasing rendering mode of the off-screen rendering context object to be enabled, and set the floating-point precision inside the fragment shader to the highest hardware precision level supported by the current terminal device. Before the graphics processor completes the drawing task of the current frame and exchanges the image data to the physical display screen, the underlying hardware call interface sends a hardware-level pixel reading instruction to the off-screen rendering context object to extract two-dimensional pixel array data containing hardware rendering fingerprint characteristics from the specified memory address block of the frame buffer. The extracted 2D pixel array data contains red, green, blue, and alpha (RGBA) channel values, which are sequentially expanded according to a fixed bit depth of 8 bits per channel and a preset pixel order. The data is then serialized into a 1D byte stream. A preset hash function is used to compress the 1D byte stream data, and a fixed-length hardware physical entropy parameter is output. This hardware physical entropy parameter is then used as the hardware rendering fingerprint feature.

5. The method for the full-process delivery and return of electronic documents according to claim 4, characterized in that, In step S400, the calculation and output of the micro-state proof data corresponding to the current slice rendering action specifically includes: Microstate computation unit extracts the first The ciphertext of the slice, the derived key material, and the hardware physical entropy parameter are used to call a lightweight hash function to hash the first slice. Perform a one-way hash operation on each slice of ciphertext and output a fixed-length ciphertext hash feature; Call the system clock application interface to obtain the system timestamp corresponding to the moment when the hardware physical entropy parameter was extracted; The extracted parameters are formatted and aligned. Following preset permutation and combination rules, a concatenation operation is performed on the formatted parameters to construct a composite byte stream. The specific formula for calculating the composite byte stream is as follows: in, Indicates that for the first Composite byte stream data constructed from slices; Indicates the first The ciphertext hash characteristics output by performing a hash operation on the ciphertext slices; Indicates the export of key materials; Represents the system timestamp; This represents the hardware physical entropy parameter; This represents a formatting function that converts input data into a big-endian byte array. This represents the encoding function that converts a time value into a 64-bit unsigned integer sequence; This represents a byte sequence concatenation operation; The composite byte stream data is compressed using a secure one-way hash algorithm, and the microstate proof data is output.

6. The method for the full-process delivery and return of electronic documents according to claim 5, characterized in that, In step S500, verifying the consistency of the session identification code and the legitimate distribution range of the physical feature values ​​contained in the microstate proof data specifically includes: Perform physical time offset verification: extract the issued first The server sends the timestamp when the slice is encrypted, and calculates the legal return time window boundary corresponding to the current plaintext slice by combining the network round-trip time (RTT) parameter provided by the underlying network protocol stack. The received system timestamp is compared with the system timestamp. When the system timestamp is within the legal return time window boundary, the physical time offset verification is determined to be successful. Perform hardware tolerance distribution verification: Map the hardware physical entropy parameters in the microstate proof data packet to a numerical feature vector, calculate the Euclidean distance between the numerical feature vector and the historical feature vectors contained in the previous set of hardware physical entropy parameters, and use the Euclidean distance as the statistical variance offset. When the statistical variance offset is within the range of natural noise fluctuations in physical hardware, the hardware tolerance distribution verification is deemed to have passed. Perform integrity recalculation verification: Extract the encrypted hash feature stored locally on the server and the exported key material bound to the current physical session. Perform big-endian conversion and bit concatenation operations on the encrypted hash feature, the exported key material, the received system timestamp, and the received hardware physical entropy parameter to generate a server verification composite byte stream. Call the secure one-way hash algorithm to compress the server verification composite byte stream and output the server's expected microstate hash value. When the server's expected microstate hash value is compared with the received microstate proof data, if the comparison is consistent, it is determined that the microstate proof data packet has not been tampered with and originates from the current legitimate physical communication session.

7. The method for the full-process delivery and return of electronic documents according to claim 6, characterized in that, In step S500, the microstate proof data is used as the context information parameter of the derived function to calculate the decryption key of the next sequence slice on the spot. Specifically, the key derivation center loads the microstate proof data into the input register of the computing memory as dynamic context information to establish state dependency conditions that restrict the decryption progress of subsequent slices. Construct a non-confidential session salt value to identify the current derived task, call the hash-based message authentication code algorithm module, use the non-confidential session salt value as the input salt value parameter, use the pseudo-random master key as the input key material, and perform the underlying extraction stage to calculate and obtain the pseudo-random key; Hash operations are performed using the pseudo-random key, the microstate proof data, and a single-byte counter. Based on the key length specified by the target decryption algorithm, a fixed-length truncation operation is performed on the output result to calculate the next slice decryption key of the target length. The random bit stream output by the server's built-in random number generator is used to erase the physical memory address storing the pseudo-random key, eliminating the risk of extracting memory-resident data.

8. The method for the full-process delivery and return of electronic documents according to claim 1, characterized in that, In step S600, before aggregating all microstate proof data sets collected within a single delivery lifecycle, a timing consistency check is performed, specifically including: In an independent memory isolation area on the server, an ordered set structure is initialized. The microstate proof data and the associated system timestamp are encapsulated into data nodes and appended to the ordered set structure. The sequence index value attached to the data node is checked to see if it is continuous and monotonically increasing, and a continuous microstate proof data sequence is obtained. Extract the system timestamps from two adjacent data nodes and calculate the actual time interval between effective viewport exposures of adjacent plaintext slices on the client terminal device. Extract the first The total number of characters contained in the first plaintext slice is calculated, and this total number of characters is divided by a preset baseline reading rate constant to obtain the result corresponding to the first plaintext slice. Minimum slice reading time for a plaintext slice; The process iterates through and verifies each set of time intervals in the microstate proof data sequence. If any actual time interval is less than the corresponding minimum slice reading time, an exception handling instruction is triggered to clear the microstate proof data sequence. When all the actual time intervals are greater than or equal to the corresponding minimum slice reading time, the microstate proof data sequence is locked as a valid set of original evidence.

9. The method for the full-process delivery and return of electronic documents according to claim 1, characterized in that, The process of generating the pseudo-random master key and the derived key material specifically includes: The key derivation center uses a configured random number generator to collect phase jitter data of the microprocessor's ring oscillator or semiconductor thermal noise data to extract an initial entropy value. The initial entropy value is then input into a deterministic random bit generator based on hash-based message authentication codes to generate the pseudo-random master key. The client and the server initiate an asymmetric key exchange using an elliptic curve-based Diffie-Hellman key exchange protocol, generating elliptic curve temporary private keys and corresponding public keys respectively and performing the exchange. A shared pre-master key is calculated by performing a scalar multiplication operation on a temporary private key and a public key. The underlying network protocol stack uses the pre-master key and random numbers from both communicating parties to generate a master key for the secure transport layer. Based on the master key of the secure transport layer, a key derivation function is called to calculate and output the derived key material.

10. The method for the full-process delivery and return of electronic documents according to claim 1, characterized in that, In step S600, the root hash value of the Merkle tree is extracted and entered into an immutable medium along with the microstate proof data set to form the final proof credential, specifically including: The root hash value of the Merkle tree, the global file hash value of the original electronic document, the application layer business serial number of the delivery task, and the current certificate issuance timestamp of the server are encapsulated in byte format. The server calls the asymmetric encryption private key configured in the server to perform a digital signature operation on the encapsulated byte stream data, generating an electronic proof data packet with the server's digital signature; The smart contract application interface opened by the consortium blockchain network node is invoked to encapsulate the electronic receipt data packet into a standard blockchain transaction message and broadcast it to the consortium blockchain network; The participating nodes of the consortium blockchain network perform legality verification and packaging confirmation operations on the blockchain transaction messages through a consensus algorithm, persistently record the electronic proof data packet in the blocks of the distributed ledger, return the proof transaction hash value to the server, and combine the proof transaction hash value, the electronic proof data packet, and the microstate proof data set into the final proof credential.

Images