An integrity auditing method and system in an edge computing environment

Abstract

The present application relates to the field of edge computing data security, in particular to an integrity auditing method and system in an edge computing environment. The main problem to be solved is the high delay and large bandwidth consumption of the existing cloud auditing model in the edge scene. A lightweight auditing challenge is generated by random sampling, data block aggregation operation is performed on the edge node, and merkle hash tree path evidence is extracted to form a double-verified integrity proof. The aggregation evidence and path evidence are verified by using bilinear mapping to achieve efficient and reliable auditing. Dynamic data updating and precise positioning of damaged blocks are supported, which significantly reduces communication overhead and ensures real-time and reliable edge data.

Description

Technical Field

[0001] This invention relates to the field of edge computing data security, specifically to an integrity auditing method and system in an edge computing environment. Background Technology

[0002] In edge computing environments, data is distributed and stored on heterogeneous nodes near the user side, posing a fundamental architectural flaw to traditional cloud auditing models. Existing integrity verification solutions rely on centralized processing mechanisms, requiring edge nodes to transmit massive amounts of raw data to a remote audit center, causing severe transmission bottlenecks in low-bandwidth wide-area network environments. In high-frequency auditing scenarios such as the Industrial Internet of Things (IIoT), continuous data backhaul leads to network channel saturation and a surge in business data transmission latency, failing to meet the millisecond-level response requirements of real-time control applications.

[0003] Existing audit protocols severely underperform in supporting dynamic data updates. Mainstream static verification models assume data immutability; when data is inserted, deleted, or modified at the edge, global parameter reconstruction or full data re-signing is required. In real-time streaming data processing scenarios such as intelligent transportation, this high-overhead update mechanism widens the service interruption window, causing the audit system to lose its adaptability to dynamic edge environments.

[0004] Distributed architectures have significant shortcomings in fault location capabilities. Traditional solutions can only return a binary judgment result on data integrity, failing to accurately pinpoint the location of specific damaged data blocks in a multi-node network. When silent data corruption occurs at the edge gateway, maintenance personnel are forced to troubleshoot node by node, resulting in fault recovery times far exceeding service level agreement requirements. Enhancement solutions such as multi-replica comparison introduce substantial redundant storage overhead, creating a sharp conflict with the resource constraints of edge devices.

[0005] Therefore, we propose an integrity auditing method and system for edge computing environments to address the problems mentioned above. Summary of the Invention

[0006] This invention provides an integrity auditing method and system for edge computing environments, the core of which lies in constructing a lightweight dual-verification architecture. Audit challenge requests with random factors are generated through random sampling. Homomorphic aggregation operations are performed on the target data block at the edge node to generate aggregated components. Simultaneously, authentication paths are extracted based on Merkle hash trees to form path evidence. After merging the two to construct an integrity proof, bilinear mapping is used to verify the consistency between the aggregated evidence and the path evidence, achieving efficient and reliable auditing.

[0007] The objective of this invention can be achieved through the following technical solutions:

[0008] An integrity auditing method and system in an edge computing environment includes the following steps:

[0009] S1: Use a cryptographic hash function to perform block hashing on the original data file to generate the Merkle hash tree structure and file tags of the original data file;

[0010] S2: Select a subset from the block index set of the original data file using random sampling to generate an audit challenge request containing a random factor;

[0011] S3: Perform aggregation operations on the target data block stored on the edge server based on the audit challenge request to generate the aggregated component of the target data block;

[0012] S4: Extract the authentication path information corresponding to the target data block index based on the Merkle hash tree structure to generate a path evidence set;

[0013] S5: Merge the aggregated component with the path evidence set to form an integrity proof;

[0014] S6: Perform dual verification calculation on the integrity proof using the file tag and the random factor in the audit challenge request to determine the integrity status of the original data file;

[0015] S7: Respond to the update request and perform an operation on the target data block of the original data file through signature verification, update the Merkle hash tree structure and generate a new file tag;

[0016] S8: Based on the integrity status of the failed verification, perform anomaly detection and analysis verification on the target data block, and generate an audit report containing the location information of the damaged data block.

[0017] Preferably, when performing block hashing on the original data file using a cryptographic hash function in step S1, it includes:

[0018] After dividing the original data file into blocks, the hash value of each data block is calculated using the SHA-256 algorithm;

[0019] The Merkel hash tree structure is constructed using hash values ​​as leaf nodes.

[0020] Extract the root hash value of the Merkle hash tree structure;

[0021] The file tag is generated by signing the message containing the hash value using the data owner's private key.

[0022] Preferably, when selecting a subset from the block index set of the original data file using random sampling in step S2, it includes:

[0023] A subset is randomly selected from the block index set of the original data file;

[0024] Generate a random factor for each index in the subset;

[0025] Combine the subset index with the corresponding random factor;

[0026] Add a timestamp to generate the audit challenge request.

[0027] Preferably, when performing aggregation operations on the target data block stored on the edge server based on the audit challenge request in step S3, it includes:

[0028] Parse the target data block index in the audit challenge request;

[0029] Retrieve the contents of the target data block from the edge server;

[0030] Extract the random factor from the audit challenge request;

[0031] A homomorphic aggregation operation is performed on the content of the target data block and the random factor to generate the aggregated component.

[0032] Preferably, in step S4, when extracting the authentication path information corresponding to the target data block index based on the Merkle hash tree structure, the following steps are included:

[0033] Locate the leaf node in the Merkle hash tree based on the target data block index in the audit challenge request;

[0034] Extract the path from the leaf node to the root node from the Merkle hash tree structure;

[0035] Collect the hash values ​​of all sibling nodes in the path;

[0036] The hash values ​​of the sibling nodes are sorted hierarchically to generate the path evidence set.

[0037] Preferably, when merging the aggregated component with the path evidence set in step S5, the following steps are included:

[0038] The aggregated component is encoded as a first verification field;

[0039] Encode the hash value sequence in the path evidence set as a second verification field;

[0040] Combine the first verification field with the second verification field;

[0041] Add edge node identifiers to form the integrity proof.

[0042] Preferably, in step S6, when performing dual verification calculations on the integrity proof using the file tag and the random factor in the audit challenge request, the following steps are included:

[0043] Parse the data owner's public key and the root hash value of the signature from the file tag;

[0044] The aggregate component in the integrity proof is verified using the random factor in the audit challenge request;

[0045] The root hash value is reconstructed using the path evidence set and compared with the root hash value of the signature;

[0046] When both verifications pass, the original data file is determined to be complete.

[0047] Preferably, when performing an operation on the target data block of the original data file in response to an update request and through signature verification in step S7, it includes:

[0048] Receive an update request containing the index of the target data block;

[0049] After verifying the signature of the update request, the operation is performed on the target data block;

[0050] Update the node hash values ​​of the affected paths in the Merkel hash tree structure;

[0051] Generate a new root hash value and update the file tag.

[0052] Preferably, when performing anomaly detection and analysis verification on the target data block based on the integrity status of the verification failure in step S8, it includes:

[0053] When the integrity status verification fails, analyze the results of the dual verification calculation;

[0054] If the aggregation verification fails, all target data blocks in the audit challenge request are marked as suspicious.

[0055] If path verification fails, locate the abnormal node in the path evidence set;

[0056] Output an audit report containing the index of the suspicious data block or the location of the abnormal node.

[0057] An integrity auditing system in an edge computing environment includes:

[0058] The data preprocessing module is used to perform block hashing operations on the original data file using a cryptographic hash function, generating the Merkle hash tree structure and file tags of the original data file;

[0059] The audit challenge module is used to perform random sampling to select a subset of the block index set of the original data file and generate an audit challenge request containing a random factor.

[0060] The edge computing module is used to perform aggregation operations on the target data block stored on the edge server based on the audit challenge request, and generate the aggregated component of the target data block; it is also used to extract the authentication path information corresponding to the index of the target data block based on the Merkle hash tree structure, and generate a path evidence set.

[0061] The evidence synthesis module is used to merge the aggregated component with the path evidence set to form an integrity proof;

[0062] The dual verification module is used to perform dual verification calculations on the integrity proof using the file tag and the random factor in the audit challenge request, and to determine the integrity status of the original data file;

[0063] The dynamic update module is used to respond to update requests and perform operations on the target data blocks of the original data file through signature verification, update the Merkle hash tree structure and generate new file tags;

[0064] The error location module is used to perform anomaly detection and analysis verification on the target data block based on the integrity status of the verification failure, and generate an audit report containing the location information of the damaged data block.

[0065] This invention provides a data integrity auditing method in an edge computing environment, characterized by achieving efficient auditing through a lightweight architecture and a dual verification mechanism. First, a cryptographic hash function is used to segment the original data file and construct a Merkle hash tree structure, generating file tags carrying digital signatures. Based on random sampling, a subset of data blocks is dynamically selected, generating an audit challenge request with a random factor, eliminating the need for original data transmission at edge nodes. After the edge server receives the audit challenge request, it performs homomorphic aggregation operations on the target data block to generate aggregate components representing the data content. Simultaneously, it extracts the complete authentication path information of the target block from the Merkle hash tree to form a path evidence set, and merges the two to construct an integrity proof.

[0066] A dual-channel verification system is implemented using bilinear mapping technology: the mathematical consistency of aggregated evidence is verified based on aggregated components, random factors, and the data owner's public key; simultaneously, the root hash value is reconstructed based on the path evidence set and matched with the signature root hash value in the file tag; the data integrity status is jointly determined through the dual verification results. Addressing the dynamic characteristics of edge environments, upon receiving an update request that has passed signature verification, the target data block operation is executed, updating only the node hash values ​​of the affected subtrees in the Merkle hash tree, generating a new root hash value, and refreshing the file tag, thus achieving real-time adaptation of the audit mechanism to data changes.

[0067] Compared with the prior art, the present invention has the following beneficial effects:

[0068] 1. This invention eliminates the need for cross-domain transmission of original data by generating aggregated evidence and path evidence locally at edge nodes. Audit challenge requests carry only lightweight metadata, and integrity proofs condense data content and structure verification information, fundamentally reducing network communication load. Uplink bandwidth resources on edge devices are fully released, ensuring unblocked transmission of high-priority business data such as industrial control commands and real-time video streams.

[0069] 2. This invention's innovative local subtree update strategy breaks the limitations of static verification models. After a data block change, only the hash values ​​of nodes in the affected path within the Merkle hash tree need to be updated, avoiding the overhead of global tree reconstruction. File tags and the tree structure are incrementally and synchronously refreshed, ensuring the audit system remains continuously verification-ready. It supports the continuous auditing needs of high-frequency data update scenarios such as intelligent transportation and real-time monitoring, ensuring the real-time verifiability of data trustworthiness in dynamic edge environments.

[0070] 3. This invention employs a dual-verification channel to separate content integrity errors from storage structure anomalies: Failed aggregated evidence directly indicates data block content tampering, while abnormal path evidence precisely maps to storage media damage or node deception. Upon verification failure, suspicious data block indexes are automatically identified, and combined with secondary targeted auditing, the location of the damaged data is precisely pinpointed. Maintenance personnel can repair faulty data without performing a full node inspection, significantly improving the maintainability and service reliability of the distributed system. Attached Figure Description

[0071] Figure 1 This is a flowchart illustrating an integrity auditing method and system in an edge computing environment according to the present invention. Detailed Implementation

[0072] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0073] Example: Figure 1 This is a flowchart illustrating an integrity auditing method and system in an edge computing environment according to the present invention. The integrity auditing method and system in an edge computing environment includes the following steps:

[0074] A cryptographic hash function is used to perform block hashing on the original data file to generate the Merkle hash tree structure and file tags of the original data file.

[0075] A subset of the block index set of the original data file is selected using random sampling to generate an audit challenge request containing a random factor;

[0076] Based on the audit challenge request, perform aggregation operations on the target data block stored on the edge server to generate the aggregated component of the target data block;

[0077] Based on the Merkle hash tree structure, the authentication path information corresponding to the target data block index is extracted to generate a path evidence set;

[0078] The aggregated component is combined with the path evidence set to form an integrity proof;

[0079] The integrity status of the original data file is determined by performing a dual verification calculation on the integrity proof using the file tag and the random factor in the audit challenge request.

[0080] In response to the update request, the operation is performed on the target data block of the original data file through signature verification, updating the Merkle hash tree structure and generating new file tags;

[0081] Based on the integrity status of the failed verification, anomaly detection and analysis verification are performed on the target data block to generate an audit report containing the location information of the damaged data block.

[0082] In this embodiment, when performing block hashing on the original data file using a cryptographic hash function in S1, the specific steps are as follows:

[0083] During the data chunking process, the system first receives the original data file as input. This file can be binary data of any format, including but not limited to text files, image files, and database files. The system will divide the file into equal parts according to preset chunk size parameters. For any remaining data at the end of the file that is less than the size of a complete chunk, the system will pad it using the PKCS#7 padding standard to ensure that all data chunks have a uniform size. Each data chunk will be assigned a unique index number starting from 0 and incrementing sequentially. These index numbers will be used for subsequent data chunk location and retrieval.

[0084] After data is divided into blocks, the system performs a hash operation on each block individually. Specifically, the system uses the SHA-256 algorithm from the OpenSSL library, which is optimized at the instruction set level for different CPU architectures. The hash calculation process employs multi-threaded parallel processing, with each thread handling a set of consecutive data blocks. The calculated hash values ​​are 32-byte binary data, which are temporarily stored in a memory buffer and arranged according to the index order of the original data blocks, preparing for the subsequent construction of the Merkle hash tree.

[0085] The Merkle hash tree is constructed using a bottom-up recursive algorithm. The system first uses the hash values ​​of all data blocks as leaf nodes, arranging them in index order to form an initial node list. Then, the system enters a tree-building loop: in each iteration, it processes all nodes at the current level, concatenating the hash values ​​of adjacent nodes into a 64-byte buffer. This concatenated buffer is then subjected to another SHA-256 hash operation, yielding the hash value of the parent node at the next higher level.

[0086] The system uses a specially designed memory pool to manage tree node data. This pool employs a hierarchical storage strategy, with nodes at each level stored in contiguous memory regions, while maintaining pointer relationships between parent and child nodes. The tree construction process continues until a unique root node hash value is generated. To improve construction efficiency, the system checks if the CPU supports the SHA-NI instruction set; if so, hardware acceleration is enabled. For particularly large files, the system also supports temporarily storing intermediate node data in an SSD cache to avoid memory overflow issues.

[0087] Once the Merkle hash tree is built, the system extracts the root hash value from the top of the tree structure in memory. This 32-byte binary data is a unique summary of the entire tree, representing the integrity characteristics of the entire file content. The system combines this root hash value with the file's metadata information to form the original message to be signed. The specific combination method uses the TLV format: first, a 1-byte type identifier; then, a 16-byte unique file identifier; then, an 8-byte UNIX timestamp; and finally, the 32-byte root hash value.

[0088] To ensure message integrity and consistency, the system calculates the CRC32 checksum of the message during the assembly process and appends this checksum to the end of the message. The entire message is a fixed 57 bytes long and encoded using network byte order. This standardized format design ensures compatibility between different systems and facilitates subsequent signature verification processing. After the message is assembled, the system stores it in a temporary buffer, awaiting digital signature processing.

[0089] The digital signature generation phase uses ECDSA (Elliptic Curve Digital Signature Algorithm) for the signing operation. The system first loads the data owner's private key from secure storage, typically stored in an HSM or TPM and encrypted in PEM format. When used in memory, the private key is first decrypted and loaded into the OpenSSL EVP_PKEY structure. The signing process uses the secp256k1 elliptic curve parameter, which provides 256 bits of security strength and is computationally efficient.

[0090] The system calls OpenSSL's ECDSA_sign function to sign the previously assembled 57-byte message. The signing process first hashes the message using SHA-256, then uses the private key to calculate the signature on the hash value. The generated signature is DER-encoded binary data, typically between 70 and 72 bytes in length. To enhance security, the system uses a deterministic k-value generation algorithm during signing, avoiding the risk of private key leakage due to random number generator issues. After signing, the system immediately clears the private key data from memory, leaving no trace.

[0091] The final integrity file label consists of three parts: a message header, the original message, and a digital signature. The system packages these components in a specific binary format: first, a 4-byte magic number; then, a 1-byte version number; then, a 1-byte algorithm identifier; then, the 57-byte original message; and finally, variable-length DER-encoded signature data.

[0092] After file tags are generated, the system offers several storage options: they can be appended directly to the end of the original file, stored as a separate .metadata file in the same directory, or uploaded to a dedicated metadata server for centralized management. To facilitate retrieval, the system generates a SHA-256 digest for each file tag as its unique identifier. All generated tags are indexed in a local database, recording their associated file paths, generation times, and expiration dates, facilitating subsequent auditing and verification operations.

[0093] In this embodiment, when selecting a subset from the block index set of the original data file using random sampling in S2, the specific steps are as follows:

[0094] The generation of audit challenge requests begins with a rigorous pseudo-random sampling process. The system constructs a random index selection engine based on the CTR_DRBG algorithm of the NIST SP 800-90A standard, initialized with a 256-bit entropy seed. A stratified random sampling strategy is employed: the block index space of the original data file is divided into several equal-length sub-intervals, and the sampling ratio is dynamically calculated within each interval to generate an unpredictable index sequence. The sampling process monitors the uniformity of the index distribution in real time. When the system detects that the sampling deviation exceeds a preset threshold, it automatically triggers a resampling mechanism to ensure that the probability of each data block being selected is strictly equal, thereby eliminating audit blind spots.

[0095] The generation of random factors adheres to the highest cryptographic security standards. For each selected index, the system obtains entropy sources through multiple secure channels: first, it directly calls the Linux kernel's ` / dev / urandom` interface to extract raw entropy data; when the available bits in the entropy pool fall below the 1024-bit security threshold, it automatically activates the hardware entropy source for replenishment. The raw entropy data undergoes entropy enhancement using a FIPS 140-2 certified HMAC-SHA512 post-processor, and is then input into the HKDF key derivation function for two-stage processing. The first stage uses HMAC-SHA256 to extract a pseudo-random key from the entropy source; the second stage generates a 128-bit cryptographically strong random factor using a customized extension algorithm. Each factor is bound to a specific index and a nanosecond-level timestamp to ensure uniqueness and unforgeability.

[0096] The structured encoding of the requested data employs a military-grade encapsulation scheme. The system encodes the index-random factor pairs in binary format according to a predefined TLV format: each index occupies a 4-byte big-endian integer, and the corresponding random factor is encapsulated as a 16-byte fixed-length field. The encoded data block and audit metadata include a 64-bit UTC timestamp, a 16-byte digital certificate fingerprint of the auditing party, and an 8-byte protocol version number, combined through a nested TLV structure. Critical data fields are encrypted online using the AES-GCM algorithm, with an additional 16-byte message authentication code to prevent tampering during transmission. Finally, the structured data is compressed into a compact binary payload using a CBOR encoder, achieving a compression rate of over 40%, significantly reducing the network transmission burden.

[0097] The request transmission process establishes an end-to-end secure channel. During system initialization of the TLS 1.3 session, forward secrecy cipher suites are enforced, and key exchange based on elliptic curve P-384 is completed within a three-way handshake. Each audit challenge request is processed as an independent transaction, encapsulated at the application layer as a dedicated audit protocol message: the message header contains a 16-byte transaction ID, a 4-byte payload length, and a 2-byte opcode; the message body carries CBOR-encoded request data. A double-buffering mechanism is enabled during transmission: the primary channel transmits the encrypted payload via HTTPS, while the backup channel synchronously transmits the hash digest in real time via the QUIC protocol. Upon receipt, the edge server immediately performs data integrity verification, identifying network tampering by comparing the dual-channel digest values, ensuring the non-repudiation of the audit trigger signal.

[0098] The entire process is monitored in real time. A lightweight intrusion detection module is deployed in the system to continuously audit security events at each stage of random number generation, encoding, and transmission. Critical operations generate digitally signed audit logs, protected by secure enclave storage. When an abnormal pattern is detected, a circuit breaker mechanism is automatically triggered to discard the current request and generate a security alert. At the same time, a backup physical entropy source is activated to reconstruct the security baseline, providing military-grade security for the audit process.

[0099] In this embodiment, when performing aggregation operations on the target data block stored on the edge server based on the audit challenge request in S3, the specific steps are as follows:

[0100] The edge server employs a modular processing architecture to achieve efficient audit challenge response. Upon receiving a TLS 1.3 encrypted audit challenge request, the server first completes protocol decapsulation and message authentication via a dedicated hardware acceleration module. The request parsing engine directly manipulates the binary data in memory using zero-copy technology, extracting the target data block index list and corresponding random factor sequence according to a predefined TLV format, while simultaneously verifying the timestamp validity and the legitimacy of the auditor's identity. The entire parsing process is completed within a trusted execution environment, ensuring that sensitive data remains encrypted at all times. The system generates a structured task descriptor containing elements such as an index array and a random factor matrix, providing standardized input for subsequent processing stages.

[0101] During the data retrieval phase, the server initiates a three-tier storage acceleration pipeline. Hot data is accessed in nanoseconds via Optane persistent memory, coupled with a Bloom filter to quickly locate target blocks; warm data is read in batches using the io_uring asynchronous interface of NVMe SSDs; and cold data is efficiently loaded from mechanical hard drives using a prefetch algorithm. All retrieval operations undergo rigorous consistency checks, including CRC32C checksum and digital signature verification. The system employs an intelligent cache preheating strategy, predicting potentially auditable data blocks based on historical access patterns and loading them into the high-speed cache layer in advance. For distributed storage scenarios, a consistent hashing algorithm ensures that requests are accurately routed to the physical node holding the target data.

[0102] The aggregation computation stage employs deep optimization using the SIMD instruction set. The server sends each target data block and its corresponding random factor to the AVX-512 vector processing unit, where 256-bit wide multiplication operations are performed in parallel on the Galois domain. Intermediate results are accumulated through a three-stage reduction tree: first, intra-vector accumulation is performed at the CPU register level; then, partial sums are exchanged between cores via a ring bus; and finally, the global aggregation component μ is generated between NUMA nodes. The entire computation process utilizes a double-buffered pipeline design, with computation and I / O operations completely overlapping, fully leveraging the superscalar execution capabilities of modern processors. The system monitors computational deviations in real time, automatically triggering a recalculation process when outliers are detected.

[0103] Security enhancements are implemented throughout the entire process. All sensitive intermediate results are protected by a memory encryption engine, and temporary buffers are securely erased before being released. The system incorporates side-channel attack defense mechanisms, including constant-time algorithm execution and randomized memory access patterns. Completed aggregated components are appended with hardware trust chain proofs from edge nodes and returned to the auditor via a secure channel. Each critical step in the process generates timestamped, verifiable logs, providing a complete chain of evidence for post-audit. The server also implements dynamic load balancing and circuit breaking mechanisms to ensure stable service quality even under high-concurrency audit requests.

[0104] In this embodiment, when extracting the authentication path information corresponding to the target data block index based on the Merkle hash tree structure in S4, the specific steps are as follows:

[0105] Upon receiving the verification request at the edge server, the system first activates the Merkle hash tree's fast location module. This module employs an improved B+ tree index structure, establishing a direct mapping between the original data block index and the leaf nodes of the Merkle hash tree. It achieves O(1) complexity node location through a pre-calculated position offset table. When the target data block index is passed in, the index engine immediately calculates the physical address of the corresponding leaf node in persistent storage and loads the entire cache line of the disk sector containing that node to reduce memory access latency. The system maintains detailed metadata about the tree structure, including the memory pointer, hash checksum, and level depth information for each node. This data is organized into a CPU cache-friendly, compact structure to ensure maximum locality during traversal.

[0106] The node traversal process is implemented using a bidirectional iterator design pattern. Starting from the located leaf node, the system climbs upwards along the parent node pointer chain, a process entirely in memory to avoid expensive I / O operations. At each level, the iterator intelligently determines the sibling direction of the current node: by comparing the node pointer address with the child node pointer array stored in the parent node, it accurately identifies the "non-target direction" sibling nodes that need to be recorded. After the hash values ​​of these sibling nodes are extracted, they undergo two levels of verification: first, the node's own CRC32 checksum is verified, and then its hash digest value stored in the parent node is compared. The system uses copy-on-write technology to maintain the tree structure, ensuring that update operations by other threads during traversal do not affect the current audit task's view. Figure 1 To the point of being responsive.

[0107] The structured encapsulation process for path evidence emphasizes a balance between security and efficiency. The collected sibling node hashes are first stored in a temporary buffer protected by a memory encryption engine to prevent sensitive information leakage through the cache side channel. The system organizes these hashes in strict order from leaf to root, appending 3 bytes of metadata to each hash: 1 byte representing the level depth, 1 byte identifying the sibling direction, and 1 byte storing the compressed location marker. This design allows the verifier to accurately reconstruct the original tree path. In the final serialization stage, the system calculates the HMAC-SHA256 message authentication code for the entire evidence set and signs it using the session key derived from the edge node's hardware security module, ensuring the immutability of the evidence.

[0108] Performance optimization measures are implemented throughout the entire evidence generation process. For deep Merkle hash trees, the system activates a parallel prefetch engine to predict upcoming tree nodes and preload them into the L3 cache. The memory manager employs a large page allocation strategy to reduce TLB misses, while the hash value storage layout is optimized for the SIMD instruction set, supporting batch processing of multiple data in a single instruction. The system also maintains a recently used path cache, storing frequently accessed subtree evidence in fast storage, which, in practice, reduces evidence generation latency by more than 30%. All critical operations are analyzed in real time by a performance monitoring unit, dynamically adjusting thread scheduling and memory allocation parameters.

[0109] Security enhancement mechanisms provide defense-in-depth throughout the process. Each node access verifies a memory safety flag to prevent buffer overflow attacks; tree pointers are randomized using ASLR technology, increasing the difficulty for attackers to predict the memory layout; critical data structures use the Intel MPX instruction set for boundary checks. The system also implements a complete audit log, recording the timestamp of each evidence generation operation, the fingerprints of the involved tree nodes, and system state snapshots. These logs are stored tamper-proofly using blockchain technology. Upon detecting abnormal access patterns, the security module automatically triggers rate limiting and threat analysis processes, isolating affected computing units if necessary. The final structured data packet output from the entire evidence generation process contains both the original path hash sequence and the complete integrity proof chain, providing a reliable foundation for subsequent verification stages.

[0110] In this embodiment, when merging the aggregated component with the path evidence set in S5, the specific steps are as follows:

[0111] The system first performs a rigorous ASN.1DER encoding transformation on the aggregated component μ. This process is completed by a dedicated encoding engine that implements the complete DER encoding rule set specified by the X.690 standard. The encoder constructs a SEQUENCE data structure for the μ value, containing three core elements: an algorithm identifier, the actual aggregated value, and an optional parameter extension field. The encoding process is memory-safe; all buffer operations undergo boundary checks, and the Intel MPX instruction set provides hardware-level memory protection. The system calculates a SHA-3 hash digest for the generated DER data as an additional guarantee of data integrity. The first verification field after encoding is temporarily stored in an encrypted memory area, awaiting subsequent combination operations.

[0112] The processing of the path evidence set employs a multi-stage optimization process. First, the system performs a stable sorting on the collected sibling node hash value sequence. The sorting key is composed of both the level depth and the node position, ensuring that the verifier can accurately reconstruct the original tree structure. The sorting algorithm is specifically optimized for modern CPU architectures, using a hybrid strategy of radix sort and insertion sort, exhibiting near-linear time complexity when handling typical scales. The sorted hash value sequence is then fed into a TLV encoding pipeline, which uses SIMD instructions to process multiple hash values ​​in parallel, generating a standard Type-Length-Value triple for each hash value. The Type field encodes the level and direction information, the Length is fixed at 32, and the Value directly stores the binary data of the hash value. The encoder calculates the hash value for the entire second verification field. The structural integrity checksum is embedded at the end of the field.

[0113] Strict security encapsulation is implemented during the field assembly phase. The system first constructs a nested TLV container structure: the outer container header contains the MAC address and high-precision timestamp of the edge node. The first verification field is inserted as the first TLV element in the inner layer, with a type identifier of 0xA1; the second verification field is inserted as the second TLV element, with a type identifier of 0xA2. The assembly process employs a memory-safe concatenation algorithm, and all pointer operations undergo double verification. The system calculates two independent checksums for the complete structure: CRC-32C is used to detect accidental data corruption, and HMAC-SHA256 is used to verify data authenticity. The assembly buffer is protected by a memory encryption engine to prevent sensitive information from being leaked through the cache side channel.

[0114] The final CBOR serialization process balances efficiency and compatibility. The system adopts the strict mode of the RFC8949 standard, using deterministic CBOR encoding rules to ensure that identical data always generates the same binary output. The encoder implements several optimizations: CBOR tags are used for compressed representation of recurring patterns; integers are encoded with minimum length; and floating-point numbers are forcibly converted to their simplest form. The serialization process employs zero-copy technology, directly reading data from the encrypted memory area and generating the output stream, avoiding unnecessary memory copying. The output stream is lightweight compressed using the DEFLATE algorithm, reducing data size by an average of 35% while maintaining low CPU overhead. The generated CBOR document includes a 4-byte magic number header and an 8-byte format version number, facilitating quick identification and processing by the receiver. Temporary data generated during the entire proof generation process is securely erased immediately upon completion, and all critical operation steps are recorded in a tamper-proof audit log.

[0115] In this embodiment, when performing dual verification calculation on the integrity proof using the file tag and the random factor in the audit challenge request in S6, the specific steps are as follows:

[0116] The verification end employs a layered verification architecture. First, it parses key information from the file tag using a secure certificate chain. The system calls OpenSSL's X.509 certificate processing engine to extract the data owner's ECDSA public key from the file tag's signature block. This public key is verified through a PKIX path to ensure its authenticity. Simultaneously, the system decodes the ASN.1 encoded signature field and uses the deterministic verification algorithm of the RFC6979 standard to recover the original root hash value R. This process is completed under the protection of a hardware security module, ensuring all key materials are always encrypted. The system rigorously verifies the certificate's validity period and key usage flags to prevent certificate abuse. To improve processing efficiency, recently used public keys are cached in a secure memory area using an LRU strategy while maintaining cache consistency.

[0117] Multiple mathematical optimizations are implemented during the aggregated evidence verification phase. The system initializes the bilinear pairing computation environment of the PBC library and configures it for optimal ate pairing implementation. When calculating e(μ,g), the system first decodes the aggregated component μ from DER format into elliptic curve group elements. This conversion process employs a constant-time algorithm to prevent timing attacks. For the computation of the product term ΠH(mi)×(ri), the system constructs a multi-stage pipeline: first, it computes the ri powers of each H(mi) in parallel using SIMD instructions, and then it uses Montgomery multiplication to accumulate the results in a finite field. The final bilinear pair comparison uses a difference technique, directly comparing the encoded forms of the two pairing results rather than the decrypted original values ​​to avoid the leakage of sensitive information. The entire computation process is accelerated using GPUs, achieving near-linear speedup for large-scale datasets.

[0118] The path evidence verification process employs rigorous structural reconstruction. The system reconstructs the Merkle hash tree layer by layer, starting from the leaf nodes, based on the received sequence of sibling node hash values. The reconstruction algorithm uses a memory-efficient iterative implementation rather than recursion, and uses pre-allocated buffers to store intermediate nodes. During each level of computation, the consistency between the direction markers of sibling nodes and the level depth is verified to prevent calculation errors caused by maliciously constructed evidence. When reconstructing to the root node, the system compares the calculated R' with the R value parsed from the file tags, using a constant-time memory comparison function to avoid temporal analysis attacks. To improve verification efficiency, the system maintains a cache of recently verified paths and uses a Bloom filter to quickly determine whether the current evidence is likely to hit the cache.

[0119] The results generation and output phases emphasize audit integrity. The verification system constructs a JSON document containing the complete verification trajectory, generated using RFC8259 strict mode, and includes the following core fields: verification timestamp, bilinear pairing calculation result, path reconstruction process record, and final verification status. The system calculates an independent JWS signature for each verification result, protected by a hardware key on the verification end. The output processor implements multiple transport protocol adaptation layers, supporting the return of results via HTTPS RESTful API, MQTT messages, or blockchain transactions. Key steps throughout the verification process are recorded in tamper-proof audit logs, organized using a Merkle tree structure, with the root hash periodically uploaded to the blockchain for evidence storage. The system also implements real-time performance monitoring and dynamically adjusts computing resource allocation to ensure stable verification throughput even under high load.

[0120] In this embodiment, when responding to the update request and performing an operation on the target data block of the original data file in S7 and verifying the signature, the specific steps are as follows:

[0121] The system implements real-time update monitoring through a high-performance WebSocket server. This server is deeply customized based on the libwebsockets framework, supporting tens of thousands of concurrent connections per second. Each connection undergoes bidirectional TLS authentication upon establishment and is bound to a specific NUMA node to ensure memory access locality. The server adopts an event-driven architecture, using epoll for I / O multiplexing, with each worker thread maintaining an independent event loop. When a data update request arrives, the system first retrieves a pre-configured public key certificate chain from the TPM's secure storage area and processes the request signature using a hardware-based ECDSA verification engine. The verification process employs a constant-time algorithm to prevent key information from being inferred through timing analysis. The system rigorously checks the nonce value and validity window in the request to effectively defend against replay attacks. Verified requests are sent to a priority queue and intelligently scheduled based on operation type and resource requirements.

[0122] The update operation execution phase employs a multi-level concurrency control strategy. For insert operations, the storage engine first allocates physical storage space at the target index location. This process is implemented through an improved buddy memory allocation algorithm to ensure minimal memory fragmentation. Before new data is written, it undergoes four verifications: CRC32 checksum, SHA-256 digest verification, data normalization check, and security boundary detection. Deletion operations trigger a lazy garbage collection mechanism. Storage blocks are first marked as "pending reclamation," and background threads periodically merge free blocks and perform safe erasure. Modification operations employ an innovative copy-on-write strategy, creating a data snapshot at the memory page table level and achieving lock-free concurrent access through shadow page table technology. All update operations are recorded in a write-ahead log. Log entries include the operation sequence number, the image before the change, and an integrity checksum, ensuring a consistent state can be rebuilt during crash recovery.

[0123] The Merkle hash tree update process employs fine-grained incremental computation. The system maintains a detailed metadata index of the tree structure, enabling rapid location of leaf nodes affected by changes. Starting from the target leaf node, the reconstruction algorithm propagates the change upwards along the parent pointer chain: first, it calculates the new child node hash value, then concatenates it with the sibling node hash to generate the new parent node hash. This process is pipelined, with computational tasks at adjacent levels distributed across different CPU cores for parallel processing. Intermediate results are temporarily stored in an encrypted memory buffer, and each node's computation is accompanied by an ARM pointer authentication code to prevent memory tampering. When the update propagates to the root node, the system generates a proof of the difference between the old and new root hashes. This proof contains all changed node paths from the leaf to the root, used for subsequent audit trails. The entire update process remains atomic, with sequence number markers ensuring observers always have a consistent view of the tree state.

[0124] File tag generation and service response employ a zero-trust security model. After a new root hash value is generated, the system calls the TPM's internal cryptographic engine to generate a digital signature; the signing process is executed entirely within a secure enclave. The generated tag contains metadata such as version number, timestamp, and operation sequence number, serialized using ASN.1DER encoding. The system simultaneously updates tag copies in three independent storage locations: local NVMe storage, a remote audit log server, and the blockchain network, ensuring storage consistency through a Byzantine fault-tolerant protocol. After the update is complete, the server sends a response message via a WebSocket connection. The message is protected using AEAD encryption mode and includes an operation result digest and the new file tag fingerprint. The system monitors key metrics of the update operation in real time, including latency percentile, memory pressure index, and tree balancing factor. When performance degradation is detected, optimization strategies are automatically triggered, such as hot data reorganization or tree structure adjustment. All management interfaces are accessed through hardware-isolated protection domains, ensuring that even if the system is partially compromised, attackers cannot tamper with update records already written to disk.

[0125] In this embodiment, when performing anomaly detection and analysis verification on the target data block based on the integrity status of the verification failure in S8, the specific steps are as follows:

[0126] When the system detects an integrity verification failure, it immediately activates a multi-level error diagnosis engine. This engine first takes a complete snapshot of the verification failure context, including the original audit challenge parameters, evidence data returned by edge nodes, and intermediate results from local verification calculations. For aggregate verification failures, the system parses the aggregate component μ value in the evidence, deduces the potential deviation value of each challenged data block through finite field inverse operations, and generates a probability distribution map of suspicious data blocks by combining this with a random factor sequence. The system uses a Bayesian inference algorithm to calculate the anomalous confidence level of each data block, marking indices with confidence levels exceeding a threshold as high-risk targets, while retaining low-probability targets as secondary suspicious objects. This data is organized into a weighted list of suspicious blocks, with each entry containing key fields such as index number, random factor, deviation value, and confidence score, stored in an encrypted temporary buffer.

[0127] The handling of path verification failures employs a difference analysis algorithm to deeply locate the fault point. The system initiates a Merkle hash tree validator, comparing the received sibling node hash values ​​with the local reconstruction results layer by layer, starting from the leaf nodes. The comparison process uses binary search optimization, quickly narrowing down the difference range through prefix matching of hash values. When a mismatched node is found, the validator constructs a difference proof package containing the complete node sequence on the faulty path, the expected hash value, and the actual hash value. By analyzing difference patterns, the system can identify various fault types: consecutive node differences may indicate storage media damage, isolated node differences may suggest a man-in-the-middle attack, and systematic offsets may point to clock drift issues. After locating a suspicious node, the system checks the range of data blocks managed by that node and generates a target index list requiring secondary verification.

[0128] The second verification phase employs a full-scale audit strategy. The system initiates a new verification request to the target edge node, this time requiring complete content transmission of all suspicious data blocks rather than aggregated proof. Requests utilize a tiered priority mechanism: high-risk targets trigger real-time verification immediately, while low-risk targets enter a batch verification queue. Received data blocks undergo triple verification: content hash matching, digital signature verification, and structural consistency check. The system cross-references replica data stored on different edge nodes and uses a vector clock algorithm to resolve version conflicts. Finally identified damaged block information is marked with the following statuses: "Confirmed Damage," "Version Conflict," or "Temporarily Unreachable." Network traffic and computation results generated during the verification process are recorded in detail for subsequent root cause analysis.

[0129] The audit log and alarm system achieves enterprise-level observability. All diagnostic information is structured into a unified audit event format, including timestamps accurate to nanoseconds, edge node identifiers (including geographic location and hardware fingerprints), a list of damaged block indexes, fault type classifications, and remediation suggestion codes. Log writing employs an append-only storage engine with an underlying encrypted distributed log structure merging tree, supporting high-throughput writing and fast time-range queries. The system analyzes the log stream in real time, detecting abnormal patterns through a predefined rule engine; for example, repeated corruption of the same data block within a short period may indicate a systemic failure. Critical alarms are sent through dual channels: SNMP trap messages are sent to the network operations center, while encrypted webhook notifications are pushed to the security event management system. Alarm messages contain actionable remediation instructions, such as "Isolate node 12A4" and "Recover block 5-8 version 3," and are accompanied by digital signatures to ensure the authenticity of the instructions.

[0130] Fault repair and system self-healing mechanisms form a closed-loop management system. Based on diagnostic results, the system automatically triggers a predefined repair workflow: for confirmed corrupted data blocks, a healthy copy is pulled from the nearest backup node and overwritten; for data with version conflicts, a distributed consensus protocol is initiated to determine the authoritative version; for temporarily unreachable nodes, they are marked as offline and their data load is reallocated. The entire repair process generates new verification requests to ensure the correctness of the repair operation itself. The system maintains a fine-grained fault history database, uses machine learning algorithms to analyze fault patterns, and dynamically adjusts data redundancy strategies and audit frequency. All operations are recorded in an immutable audit trail chain, with tamper-proof evidence preservation achieved by periodically writing digest hashes to the blockchain. Operations personnel can monitor the repair progress in real time through a visual console, and the system will also automatically generate compliance reports compliant with ISO 27001 standards, detailing the lifecycle processing trajectory of each integrity fault.

[0131] An integrity auditing system in an edge computing environment includes:

[0132] The data preprocessing module is used to perform block hashing operations on the original data file using a cryptographic hash function, generating the Merkle hash tree structure and file tags of the original data file;

[0133] The audit challenge module is used to perform random sampling to select a subset of the block index set of the original data file and generate an audit challenge request containing a random factor.

[0134] The edge computing module is used to perform aggregation operations on the target data block stored on the edge server based on the audit challenge request, and generate the aggregated component of the target data block; it is also used to extract the authentication path information corresponding to the index of the target data block based on the Merkle hash tree structure, and generate a path evidence set.

[0135] The evidence synthesis module is used to merge the aggregated component with the path evidence set to form an integrity proof;

[0136] The dual verification module is used to perform dual verification calculations on the integrity proof using the file tag and the random factor in the audit challenge request, and to determine the integrity status of the original data file;

[0137] The dynamic update module is used to respond to update requests and perform operations on the target data blocks of the original data file through signature verification, update the Merkle hash tree structure and generate new file tags;

[0138] The error location module is used to perform anomaly detection and analysis verification on the target data block based on the integrity status of the verification failure, and generate an audit report containing the location information of the damaged data block.

[0139] The system's data preprocessing module employs a layered processing architecture for efficient data preparation. During module initialization, the configuration management unit loads predefined hash algorithm parameters and tree structure parameters. The raw data file is fed into a block pipeline that uses double buffering to overlap computation and I / O. Each data block is padded and aligned before being fed into a hardware-accelerated hash engine. The generated leaf node hash values ​​are organized into a cache-friendly array structure for use by the Merkle hash tree builder. The tree construction process uses a parallel recursive algorithm, with a worker thread pool handling different subtrees and synchronizing intermediate results through atomic operations. The final generated tree structure is persisted via a memory-mapped file, and metadata is registered with a distributed configuration center. The file tag generator uses the signature key in the HSM to generate a structured tag containing a timestamp, file fingerprint, and digital signature according to the X.509 standard. This tag is distributed to multiple geographically distributed verification nodes for registration.

[0140] The audit challenge module implements a verifiable random sampling mechanism. The module maintains a real-time updated block index bitmap and quickly excludes audited blocks using a Bloom filter. The random number generator employs a hybrid entropy source to ensure unpredictable sampling. Each challenge request is constructed as a multi-layered nested TLV structure: the outer layer contains the audit session ID and timestamp, the middle layer stores the selected block index and corresponding random factor, and the inner layer embeds edge node location information. After the request is generated, the traffic shaper selects the optimal transmission strategy based on network conditions and simultaneously calculates the Merkle digest of the request as a basis for tamper-proofing. The system also implements a replay cache for challenge requests, using an LRU strategy to manage recent request records, effectively defending against replay attacks.

[0141] The edge computing module is deployed on distributed nodes, providing elastic computing capabilities through a microservice architecture. The aggregation unit employs SIMD instruction set optimization, vectorizing the multiplication of data blocks with random factors and achieving parallel accumulation through a reduction tree. The module incorporates an arithmetic verification mechanism, using finite-field redundancy coding to detect computational errors. The path evidence extractor implements an innovative "lazy-loading" tree traversal algorithm, dynamically loading only the necessary tree nodes, significantly reducing I / O overhead. The results of both computation processes are sent to a secure buffer protected by memory encryption and pointer verification techniques. The module also integrates a lightweight proof cache, providing rapid response capabilities for frequently accessed data blocks. All resource usage metrics generated by these operations are reported to the central monitoring system in real time.

[0142] The evidence synthesis and verification module forms the security decision-making center of the system. The evidence synthesizer adopts military-grade data encapsulation standards, encoding aggregated components and path evidence into ASN.1DER and CBOR formats respectively, and then combining them into a complete proof through a nested signature structure. The verification engine implements a multi-level verification pipeline: the first level performs syntax and structure checks, the second level performs cryptographic verification, and the third level performs policy compliance assessment. Key verification operations are completed within the TEE, and the verification result is accompanied by a proof chain signed by the HSM. The system supports pluggable verification policies, allowing dynamic adjustment of verification strictness according to different security levels. All verification decisions are recorded in an immutable audit log, and log entries are distributed and stored using blockchain technology.

[0143] The dynamic update and error handling modules enable the system's self-healing capabilities. The update listener employs an event-driven architecture, managing thousands of concurrent WebSocket connections via epoll to capture data change requests in real time. Each update operation triggers an atomic tree update process: first, changes are executed on the copy-on-write tree replica; then, a difference algorithm is used to calculate the minimum set of affected nodes; and finally, changes are committed in batches. The error diagnostic tool implements multi-dimensional analysis algorithms, combining aggregation deviations, path differences, and historical node performance to pinpoint the root cause of failures. The repair workflow engine supports custom repair strategies, such as automatic data recovery, node isolation, or data migration. The system also maintains a predictive model, analyzing historical failure patterns to predict potential risks and enabling preventative maintenance. All operational operations generate standardized audit trails, supporting a complete chain of responsibility. The entire system uses a service mesh architecture for inter-module communication, with each interface implementing strict mTLS authentication and attribute-based access control to ensure overall system defense depth.

[0144] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0145] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An integrity auditing method in an edge computing environment, characterized in that, The following steps: S1: Use a cryptographic hash function to perform block hashing on the original data file to generate the Merkle hash tree structure and file tags of the original data file; S2: Select a subset from the block index set of the original data file using random sampling to generate an audit challenge request containing a random factor; S3: Perform aggregation operations on the target data block stored on the edge server based on the audit challenge request to generate the aggregated component of the target data block; S4: Extract the authentication path information corresponding to the target data block index based on the Merkle hash tree structure to generate a path evidence set; S5: Merge the aggregated component with the path evidence set to form an integrity proof; S6: Perform dual verification calculation on the integrity proof using the file tag and the random factor in the audit challenge request to determine the integrity status of the original data file; S7: Respond to the update request and perform an operation on the target data block of the original data file through signature verification, update the Merkle hash tree structure and generate a new file tag; S8: Perform anomaly detection and analysis verification on the target data block based on the integrity status of the verification failure, and generate an audit report containing the location information of the damaged data block.

2. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When performing block hashing on the original data file using a cryptographic hash function in S1, it includes: After dividing the original data file into blocks, the hash value of each data block is calculated using the SHA-256 algorithm; The Merkel hash tree structure is constructed using hash values ​​as leaf nodes. Extract the root hash value of the Merkle hash tree structure; The file tag is generated by signing the message containing the hash value using the data owner's private key.

3. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When selecting a subset from the block index set of the original data file using random sampling in step S2, it includes: A subset is randomly selected from the block index set of the original data file; Generate a random factor for each index in the subset; Combine the subset index with the corresponding random factor; Add a timestamp to generate the audit challenge request.

4. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When performing aggregation operations on the target data block stored on the edge server based on the audit challenge request in step S3, it includes: Parse the target data block index in the audit challenge request; Retrieve the contents of the target data block from the edge server; Extract the random factor from the audit challenge request; A homomorphic aggregation operation is performed on the content of the target data block and the random factor to generate the aggregated component.

5. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When extracting the authentication path information corresponding to the target data block index based on the Merkle hash tree structure in step S4, it includes: Locate the leaf node in the Merkle hash tree based on the target data block index in the audit challenge request; Extract the path from the leaf node to the root node from the Merkle hash tree structure; Collect the hash values ​​of all sibling nodes in the path; The hash values ​​of the sibling nodes are sorted hierarchically to generate the path evidence set.

6. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When merging the aggregated component with the path evidence set in S5, it includes: The aggregated component is encoded as a first verification field; Encode the hash value sequence in the path evidence set as a second verification field; Combine the first verification field with the second verification field; Add edge node identifiers to form the integrity proof.

7. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When performing dual verification calculations on the integrity proof using the file tag and the random factor in the audit challenge request in step S6, it includes: Parse the data owner's public key and the root hash value of the signature from the file tag; The aggregate component in the integrity proof is verified using the random factor in the audit challenge request; The root hash value is reconstructed using the path evidence set and compared with the root hash value of the signature; When both verifications pass, the original data file is determined to be complete.

8. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When S7 responds to an update request and performs an operation on the target data block of the original data file through signature verification, it includes: Receive an update request containing the index of the target data block; After verifying the signature of the update request, the operation is performed on the target data block; Update the node hash values ​​of the affected paths in the Merkel hash tree structure; Generate a new root hash value and update the file tag.

9. The integrity auditing method in an edge computing environment according to claim 1, characterized in that, When performing anomaly detection and analysis verification on the target data block based on the integrity status of verification failure in S8, it includes: When the integrity status verification fails, analyze the results of the dual verification calculation; If the aggregation verification fails, all target data blocks in the audit challenge request are marked as suspicious. If path verification fails, locate the abnormal node in the path evidence set; The output includes an audit report containing indexes of suspicious data blocks or locations of abnormal nodes.

10. An integrity auditing system in an edge computing environment, characterized in that, include: The data preprocessing module is used to perform block hashing operations on the original data file using a cryptographic hash function, generating the Merkle hash tree structure and file tags of the original data file; The audit challenge module is used to perform random sampling to select a subset of the block index set of the original data file and generate an audit challenge request containing a random factor. An edge computing module is used to perform aggregation operations on a target data block stored on an edge server based on the audit challenge request, and generate an aggregated component of the target data block; Used to extract authentication path information corresponding to the target data block index based on the Merkle hash tree structure, and generate a path evidence set; The evidence synthesis module is used to merge the aggregated component with the path evidence set to form an integrity proof; The dual verification module is used to perform dual verification calculations on the integrity proof using the file tag and the random factor in the audit challenge request, and to determine the integrity status of the original data file; The dynamic update module is used to respond to update requests and perform operations on the target data blocks of the original data file through signature verification, update the Merkle hash tree structure and generate new file tags; The error location module is used to perform anomaly detection and analysis verification on the target data block based on the integrity status of the verification failure, and generate an audit report containing the location information of the damaged data block.

Images