Data tamper-proofing method and apparatus, electronic device, computer-readable storage medium

Abstract

The disclosure provides a data tamper-proofing method and device, an electronic device and a computer readable storage medium, relates to the technical field of data processing, and in particular to the technical field of data security, data storage and the like. The specific implementation scheme is as follows: initializing a tamper-proofing verification chain shared by a multi-user sharing platform; in response to any user on the multi-user sharing platform submitting target data and data source information thereof, obtaining a characteristic value of the target data; based on the data source information, the characteristic value and position information of the target data registered in the tamper-proofing verification chain this time, generating a row verification code corresponding to the target data, and saving the row verification code in a private storage area of the user; obtaining a current chain end code of the tamper-proofing verification chain, generating a verification chain code corresponding to the target data based on the current chain end code and the row verification code, and adding the verification chain code as an updated chain end code to the end of the tamper-proofing verification chain.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and more particularly to the fields of data security and data storage. Specifically, this disclosure relates to a method and apparatus for bidirectional anchored data anti-tampering based on a multi-user sharing platform, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Against the backdrop of accelerated digital transformation, electronic data has become a core asset for businesses, governments, and institutions.

[0003] In particular, the widespread adoption of SaaS (Software as a Service) platforms has made it the mainstream model for multiple users to share the same platform for data registration and management. Summary of the Invention

[0004] This disclosure provides a method and apparatus, electronic device, and computer-readable storage medium for two-way anchored data anti-tampering based on a multi-user sharing platform.

[0005] According to a first aspect of this disclosure, a two-way anchored data anti-tampering method based on a multi-user sharing platform is provided, comprising: A platform-shared tamper-proof verification chain is initialized for the multi-user sharing platform. The tamper-proof verification chain has a fixed initial code and a dynamically updated chain end code. In response to any user submitting target data and its data source information on the multi-user sharing platform, the feature value of the target data is obtained; Based on the data source information, the feature value, and the location information of the target data registered in the anti-tampering verification chain, a row verification code corresponding to the target data is generated, and the row verification code is stored in the user's private storage area; Obtain the current end-of-chain code of the anti-tampering verification chain; based on the current end-of-chain code and the row verification code, generate the verification chain code corresponding to the target data; and add the verification chain code as the updated end-of-chain code to the end of the anti-tampering verification chain, so that the verification chain code becomes the new end-of-chain code of the anti-tampering verification chain. The verification chain code is associated with and saved with the index information of the target data.

[0006] According to a second aspect of this disclosure, a two-way anchored data anti-tampering device based on a multi-user sharing platform is provided, comprising: An initialization module is used to initialize a platform-shared anti-tamper verification chain for a multi-user sharing platform. The anti-tamper verification chain has a fixed initial code and a dynamically updated chain end code. The feature value calculation module is used to obtain the feature value of the target data in response to any user submitting target data and its data source information on the multi-user sharing platform. The line verification code module is used to generate a line verification code corresponding to the target data based on the data source information, the feature value, and the location information of the target data being registered in the anti-tampering verification chain, and to save the line verification code in the user's private storage area; The verification chain code module is used to obtain the current chain end code of the anti-tampering verification chain, generate the verification chain code corresponding to the target data based on the current chain end code and the row verification code, and add the verification chain code as the updated chain end code to the end of the anti-tampering verification chain, so that the verification chain code becomes the new chain end code of the anti-tampering verification chain. The storage module is used to associate and save the verification chain code with the index information of the target data.

[0007] According to a third aspect of this disclosure, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to at least one of the aforementioned processors; wherein, The memory stores instructions that can be executed by at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the bidirectional anchored data anti-tampering method based on a multi-user shared platform.

[0008] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the above-described bidirectional anchored data anti-tampering method based on a multi-user shared platform.

[0009] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described bidirectional anchored data anti-tampering method based on a multi-user shared platform.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a two-way anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the disclosure; Figure 2 This is a flowchart illustrating some steps of another bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the present disclosure; Figure 3 This is a flowchart illustrating some steps of another bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the present disclosure; Figure 4 This is a flowchart illustrating some steps of another bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the present disclosure; Figure 5 This is a flowchart illustrating some steps of another bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the present disclosure; Figure 6 This is a flowchart illustrating some steps of another bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the present disclosure; Figure 7 This is a flowchart illustrating some steps of another bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this embodiment of the present disclosure; Figure 8 This is a schematic diagram of the structure of a two-way anchored data anti-tampering device based on a multi-user sharing platform provided in this embodiment of the disclosure; Figure 9 This is a block diagram of an electronic device used to implement the bidirectional anchored data anti-tampering method based on a multi-user sharing platform according to the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] In some related technologies, in a SaaS multi-user environment, there may be frequent registration by multiple users. However, SaaS security solutions are mostly static access control or log auditing, which are passive post-event traceability mechanisms. They cannot proactively form a solid protection that links the data to previous and subsequent changes. This means that historical data still faces the risk of being tampered with in subsequent operations and cannot be locked in time, resulting in the continuous existence of data tampering risks in the shared platform.

[0014] Some related technologies can utilize hash verification (such as MD5, SHA-256), digital signatures, and database trigger log auditing to prevent data tampering. However, these technologies rely on a single central server, making them vulnerable to tampering by internal personnel or external intrusions. Furthermore, they cannot achieve dynamic locking across users. Once the platform's data pool is modified, the integrity of previously registered user data is difficult to guarantee.

[0015] In some related technologies, blockchain multi-user solutions can also achieve data tamper-proofing. However, while distributed ledgers and consensus mechanisms (such as Ethereum public chains and Hyperledger Fabric consortium chains) provide global immutability, their computational overhead is extremely high (consensus latency ranges from seconds to minutes) and their storage requirements are enormous (over TB per full node), making them unsuitable for high-concurrency, real-time, and low-cost SaaS scenarios. Furthermore, existing blockchain multi-user solutions mainly rely on permission isolation or sidechains, which cannot achieve the cascading effect of "automatically locking previous data upon subsequent user registration."

[0016] The bidirectional anchored data anti-tampering method, apparatus, electronic device, and computer-readable storage medium based on a multi-user sharing platform provided in this disclosure are intended to solve at least one of the above-mentioned technical problems in the prior art.

[0017] The bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.

[0018] Figure 1 A flowchart illustrating a two-way anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure is shown. Figure 1 As shown in the figure, the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure embodiment may include steps S110, S120, S130, S140, and S150.

[0019] S110. Initialize a platform-shared anti-tamper verification chain for the multi-user sharing platform. The anti-tamper verification chain has a fixed initial code and a dynamically updated chain end code.

[0020] A multi-user sharing platform refers to a software platform that supports multiple users (or tenants) in sharing the same system resources, with data logically isolated between users. Examples include SaaS platforms and multi-department shared systems within an enterprise. On this platform, different users can independently submit their own data, but all users share the same tamper-proof verification chain.

[0021] The platform-shared tamper-proof verification chain can be a data chain stored on the platform and jointly maintained and relied upon by all users. This chain consists of multiple verification chain codes linked together in chronological order; tampering with any chain code will cause subsequent chain code verifications to fail. Unlike existing technologies where each user or each system maintains a separate chain, the verification chain in this invention is shared by all users within the platform, meaning that all users' data registration operations extend to the same data chain.

[0022] The fixed initial code is the value of the first node in the tamper-proof verification chain. It is generated during platform initialization and cannot be changed once determined. The initial code is used to ensure that the starting point of the entire tamper-proof verification chain is trustworthy.

[0023] The dynamically updated end-of-chain code is the value of the last node in the tamper-proof verification chain, and it is updated every time new data is registered. Subsequent user registrations require the current end-of-chain code as one of the inputs for generating a new verification chain code.

[0024] In some possible implementations, when deploying or starting a multi-user shared platform, it is necessary to initialize a tamper-proof verification chain shared by all users. This specifically involves generating a fixed initial code and using this initial code as the starting point of the chain's end code.

[0025] In some specific implementations, the platform administrator or system program first generates a fixed initial code. The initial code can be calculated using a hash algorithm, for example: Initial Code = SHA-256(Platform Key + Initial Timestamp + Platform Initialization Code). The initial code is then stored in the tamper-proof verification chain's storage area, and the current chain end code is set to the initial code.

[0026] The platform key is the unique identifier of the platform instance, the initial timestamp is the Unix timestamp at platform startup, and the platform initialization code is a randomly generated GUID (Globally Unique Identifier). SHA-256 is a cryptographic hash function that can convert data of arbitrary length into a fixed-length hash value of 256 bits (32 bytes).

[0027] The method of generating the initial code ensures that the initial codes are different across different platforms and cannot be forged. The shared verification chain across platforms provides a unified anchor of trust for all users.

[0028] S120. In response to any user submitting target data and its data source information on the multi-user sharing platform, obtain the feature values ​​of the target data.

[0029] The target data can be the data that the user wants to register this time, and it can be structured data (such as a row of records in a database table) or unstructured data (such as PDF documents, images, videos, etc.).

[0030] Data source information is used to uniquely identify the source of target data. For structured data, data source information includes database name, table name, primary key value, etc.; for unstructured data, data source information includes file storage path, file name, IP address of the server, etc.

[0031] A feature value can be a fixed-length digest value obtained by hashing the target data content, used to uniquely identify the data content. Any modification to the data content will cause the feature value to change.

[0032] In some possible implementations, when a user submits target data through a client, such as a web interface or API (Application Programming Interface), the platform receives the data and its accompanying data source information. The platform then uses a feature extraction algorithm to calculate the feature values ​​of the target data.

[0033] For example, user A logs into a multi-user sharing platform, uploads an electronic contract document (target data), and provides the storage path and filename of the document as data source information.

[0034] The platform reads the file content and uses algorithms such as SHA-256 hashing to calculate the file's characteristic value, for example, characteristic value = SHA-256 (file binary stream). The calculation result is a 256-bit hexadecimal string.

[0035] In some possible implementations, if the target data is structured data (such as a customer record in a database), the platform can directly read the field content of the record from the database, concatenate them, and calculate the hash value as the feature value.

[0036] Feature values ​​can uniquely and compactly represent data content. Any minor modification to the data content will cause unpredictable changes in feature values, thus providing a basis for subsequent tampering detection.

[0037] S130. Based on the data source information, feature values, and the location information of the target data in the anti-tampering verification chain, generate the row verification code corresponding to the target data and save the row verification code in the user's private storage area.

[0038] Row-level CAPTCHAs are CAPTCHAs generated for a single data entry. Their input includes data source information, feature values, and location information. Row-level CAPTCHAs are used to detect whether the index information of a single data entry has been tampered with. They are stored in the user's private storage area and are not visible to other users.

[0039] The private storage area is an isolated storage space allocated by the platform to each user, accessible only to that user. In this embodiment, both the CAPTCHA and its key are stored here to protect user privacy.

[0040] In some possible implementations, the data source information, feature value, and position information (e.g., current chain length + 1) from step S120 can be used to generate a hash value as a line verification code. This line verification code is stored only in the user's private storage area and cannot be read by other users.

[0041] For example, assuming the current anti-tampering verification chain already has 3 nodes, user A's registration will add a 4th node, therefore the location information = 4. Calculate the line verification code: RV = SHA-256(data source information + feature value + "4"). Associate RV with the data source information, feature value, etc., and save it to user A's private storage area.

[0042] The CAPTCHA is stored in the user's private area, inaccessible to other users, thus protecting user data privacy. Furthermore, because the generation of the CAPTCHA includes dynamic information such as feature values ​​and timestamps, any tampering with the data source information, data content, or index information will cause the CAPTCHA verification to fail.

[0043] S140. Obtain the current end-of-chain code of the anti-tampering verification chain. Based on the current end-of-chain code and the row verification code, generate the verification chain code corresponding to the target data, and add the verification chain code as the updated end-of-chain code to the end of the anti-tampering verification chain, so that the verification chain code becomes the new end-of-chain code of the anti-tampering verification chain.

[0044] The current chain end code is the value of the last node in the tamper-proof verification chain. After platform initialization, the chain end code is initially equal to the fixed initial code; each time new data is registered, the chain end code is updated to the newly generated verification chain code.

[0045] The verification chaincode is a node value on the tamper-proof verification chain, generated by a hash algorithm from parameters such as the current chain end code and row verification code. The verification chaincode serves both as proof of the data's presence in the chain and as the chain end code for the next data registration.

[0046] In some possible implementations, the current chain terminator (e.g., EC_current) is read from the shared storage area. Then, using this chain terminator and the row verification code generated in step S130, a new verification chain terminator is generated using a hash algorithm. Finally, the new verification chain terminator is added as the new terminator to the end of the tamper-proof verification chain, and the stored chain terminator is updated.

[0047] For example, read the current chain end code EC_current = V3 from the tamper-proof verification chain store (assuming the value of the 3rd node is V3). Calculate the new verification chain code: V4 = SHA-256(EC_current + RV). Add V4 as the 4th node to the tamper-proof verification chain and update the chain end code to V4.

[0048] The new verification chaincode depends on the current chain terminator. Therefore, any tampering with a previous node (i.e., the data registered by all previous users) will cause the current chain terminator to deviate from the expected value, thus compromising the integrity of the entire chain. Subsequent user registrations will then extend the chain based on the updated chain terminator, creating a cascading effect where "subsequent users automatically lock the data of previous users."

[0049] S150. Associate and save the verification chain code with the index information of the target data.

[0050] The index information is a set of metadata associated with the target data, including at least data source information, feature values, verification chaincode, and its position in the chain. The index information can be stored in the platform's centralized index repository and does not include the row verification code (which is stored in the user's private area), for subsequent verification and tracing.

[0051] In some possible implementations, the verification chaincode generated in step S140 can be associated with the target data's data source information, feature values, location information, and other index information to form an index record, which is then saved in the platform's index information repository. The index information repository is a platform-level storage that can be read by all users (but modification permissions are usually restricted through access control).

[0052] Specifically, the indexed record contains the following fields: data_source: Data source information (such as file path) data_hash: Feature value chain_position: Position information (e.g., 4) chain_code: Verify chaincode (V4) timestamp: Registration timestamp history_id: Historical registration position (empty for the first registration) Among them, data_source, data_hash, chain_position, timestamp, and history_id are index information, which can be written to the table or document storage of the index information database.

[0053] The index database stores the verification chain code and location information for each piece of data, enabling subsequent verification to quickly locate the corresponding chain node based on the data source information and recalculate the verification chain code to verify integrity. Furthermore, since the row verification code is not in the index database, even if the index database is obtained by an attacker, the row verification code cannot be forged.

[0054] The two-way anchoring data anti-tampering method based on a multi-user sharing platform provided in this disclosure can simultaneously establish two independent anchoring relationships when each piece of data is registered: Backward anchoring: The verification chain code generated for each data depends on the end code of the current tamper-proof verification chain (i.e., the verification chain code of the previous data), thus forming a chain lock on the preceding data. Any tampering with the preceding data will cause the verification chain code of the current data to fail.

[0055] Forward anchoring: After each data is registered, its verification chaincode becomes the new chain terminator, which is essential for subsequent user data registrations. This "locks" the current data to all subsequent data, meaning that subsequent registration actions automatically strengthen the protection of the current data. Simultaneously, each data is also bound to its own data characteristics, timestamp, and user private key through a line verification code, forming "self-anchoring."

[0056] These three anchoring methods (backward, forward, and self-anchoring) together form a two-way (or even multi-way) tamper-proof network, making it impossible for data to deny its own content or escape chain constraints once it is written to the shared platform. This achieves high-strength data solidification without the need for blockchain consensus.

[0057] In summary, in the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure, all user data registrations extend along the same chain, and subsequent user operations automatically strengthen the immutability of all previous user data. Any tampering with historical data will cause the chain to break. In other words, the bidirectional anchored data anti-tampering method based on a multi-user sharing platform in this disclosure automatically generates a locking effect each time data is registered, requiring no additional operations, and realizing a proactive security mechanism of "registration equals locking, subsequent actions equal reinforcement". Simultaneously, the line verification code is privately stored by the user, protecting the privacy of user data. It contains sensitive information such as data characteristics, timestamps, and keys. Even if the index information database is compromised, attackers cannot forge line verification codes to bypass tampering detection. Furthermore, all operations in the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure involve only local hash calculations, requiring no distributed consensus or blockchain node synchronization, supporting high concurrency and real-time alerts, making it very suitable for cloud service scenarios such as SaaS.

[0058] The following is a detailed description of the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in the embodiments of this disclosure.

[0059] Among some possible implementations, Figure 2 A flowchart illustrating one implementation method for initializing a platform-shared, tamper-proof verification chain for a multi-user shared platform is provided, such as... Figure 2 As shown, steps S210, S220, and S230 may be included.

[0060] S210. Obtain the platform key and platform initialization code. The platform key is used to identify an instance of a multi-user shared platform, and the platform initialization code is a randomly generated value.

[0061] The platform key is a key used to uniquely identify a multi-user shared platform instance. This key can be obtained by the platform owner from the system developer or regulatory agency, or it can be generated by the platform itself during initial deployment based on hardware information, licenses, etc.

[0062] A platform key is typically a fixed-length string or binary data. Its core function is to distinguish between different platforms (e.g., independent instances deployed by different tenants or customers), preventing confusion in cross-platform tamper-proof verification chains. Simultaneously, the platform key also serves as one of the inputs for generating a fixed initialization code, ensuring that the initialization codes are unique across different platforms.

[0063] In some possible implementations, the platform administrator obtains a unique platform key from an authorized agency (such as the system developer or regulatory body) when deploying the system. Alternatively, the platform itself generates an unforgeable key based on hardware characteristics (such as the network interface card MAC address and CPU serial number) and the software license. This key needs to be securely stored, typically in an encrypted configuration file or a Hardware Security Module (HSM).

[0064] The platform initialization code is a random value generated during platform initialization, typically using a globally unique identifier (GUID) or a cryptographically secure random number. This random value increases the unpredictability of the fixed initialization code, preventing attackers from forging it by guessing the platform key or timestamp. The platform initialization code is used only once during initialization and can be publicly stored, but its randomness ensures that the initialization code will be different even if the same platform is initialized multiple times.

[0065] In some possible implementations, a random number generator can be invoked to produce a sufficiently long random value (e.g., 128 bits or 256 bits), or a GUID can be generated by calling a system API. This random value does not need to be kept secret, but it should be ensured to have sufficient entropy so that the probability of repetition is extremely low.

[0066] S220. Use a hash algorithm to calculate the platform key, initial timestamp, and platform initialization code, and use the calculation result as the fixed initial code.

[0067] The initial timestamp is the system time at the moment of platform initialization, typically using a Unix timestamp. The introduction of the timestamp binds the initial code to the platform startup time, further increasing uniqueness and facilitating subsequent time auditing.

[0068] The fixed initialization code is the first node value of the tamper-proof verification chain, calculated using a hash algorithm from the platform key, initial timestamp, and platform initialization code. Once generated, the fixed initialization code cannot be changed and serves as the root of trust for the entire chain. Verification of any subsequent chaincode directly or indirectly depends on this initialization code.

[0069] In some possible implementations, the current UTC (World Time) is obtained and converted to a Unix timestamp (e.g., accurate to seconds or milliseconds). The timestamp can be the time when the platform boots up or the time when the initialization command is executed. The platform key, initial timestamp, and platform initialization code are concatenated into a string in a pre-defined order (with separators optional), and then a secure hash algorithm, such as SHA-256 or SM3, is used to calculate its hash value. This hash value is the fixed initialization code.

[0070] S230. Set the fixed initial code as the starting point of the chain end code.

[0071] The chain-end code is the value of the last node in the tamper-proof verification chain. During the initialization phase, the chain-end code is set to the same as the fixed initial code. As users continuously register data, the chain-end code is dynamically updated to the newly generated verification chain code.

[0072] In some possible implementations, after generating the fixed initial code, the end-point pointer of the tamper-proof verification chain is set to the fixed initial code, meaning the initialized chain end-point code is equal to the fixed initial code. Simultaneously, the fixed initial code is persistently stored as the first node of the chain.

[0073] In some possible implementations, to facilitate subsequent auditing and disaster recovery, the fingerprint, initial timestamp, and platform initialization code of the platform key can be securely stored, but the fixed initialization code itself is public and can be stored in a shared storage area.

[0074] By introducing a platform key, the fixed initial codes generated by different multi-user shared platform instances are all different. This avoids cross-platform data confusion and chaincode conflicts. For example, even if two different SaaS platforms (such as a government platform and a financial platform) use the same hash algorithm, their initial codes will be different due to the different platform keys, thus ensuring the independence of their respective chains.

[0075] The platform initialization code is a randomly generated value, making it impossible for attackers to predict the initial code in advance, even if they obtain the platform key and timestamp, because random values ​​are unpredictable. Furthermore, the introduction of timestamps ensures that re-initializing the same platform at different times will generate different initial codes, preventing historical state rollback attacks.

[0076] The fixed initial code serves as the root of trust for the entire tamper-proof verification chain, and its unforgeability directly affects the security of all subsequent chain codes. By binding multiple factors (key, timestamp, and random code) together through a hash algorithm, the initial code has sufficient entropy to prevent brute-force attacks or collisions.

[0077] The entire initialization process involves only one hash calculation and a small amount of random number generation. It does not require complex key negotiation or external service calls, making it suitable for rapid deployment and elastic scaling in cloud-native environments.

[0078] In summary, the embodiments of this disclosure use the hash result of "platform key + timestamp + random code" as the initial code, providing a secure, unique, and auditable starting point for the entire multi-user shared anti-tampering verification chain. This design not only increases auditability and uniqueness, but also binds the generation of the initial code to the platform identity, making it more suitable for multi-tenant, multi-instance SaaS scenarios. It also enables the bidirectional anchored data anti-tampering method based on a multi-user shared platform in this disclosure to be reliably deployed in a large-scale multi-tenant environment and to meet the strict requirements of different industries for data authenticity assurance.

[0079] Among some possible implementations, Figure 3 This diagram illustrates a flowchart of one implementation method for generating a row verification code for the target data based on data source information, feature values, and the position information of the target data in the anti-tampering verification chain. Figure 3 As shown, step S310 may be included.

[0080] S310. Generate a row verification code based on the data source information, feature value, the location information of the target data in the anti-tampering verification chain, the current timestamp, the row verification code key, and the historical registration location. The historical registration position refers to the location of the index information of the target data that existed before this registration in the index database. If the target data is being registered for the first time, the historical registration position will be empty.

[0081] As mentioned above, data source information is a set of information that uniquely identifies the source of the data. For structured data, this may include the database name, table name, and primary key value; for unstructured data, it may include the file storage path, file name, and server IP address. A feature value is a fixed-length digest obtained by hashing the target data content, such as a 256-bit hash value calculated using the SHA-256 algorithm. The feature value uniquely represents the data content; any modification to the data content will result in a change to the feature value.

[0082] The position information of the target data registered in the anti-tampering verification chain refers to the node sequence number that the current target data's verification chain code will occupy in the platform's shared anti-tampering verification chain. Since the verification chain grows sequentially, newly registered data will be added to the end of the chain, and its position information will be the current chain length plus 1. This position information is used to bind the line verification code to a specific node in the chain.

[0083] The current timestamp is the system time when the registration operation occurred, typically using a Unix timestamp. Timestamps are used to prevent replay attacks and to give CAPTCHAs a time limit.

[0084] The CAPTCHA key is a user-unique private key used to generate the CAPTCHA. This key is randomly generated by the platform during the user's initial registration and stored encrypted in the user's private storage area. Each user's CAPTCHA key is independent, ensuring that the CAPTCHA cannot be forged across users.

[0085] The historical registration location refers to the storage location in the index database of the index information corresponding to the target data during its last registration (such as the primary key ID or document ID of a database table). If the target data is being registered for the first time (i.e., it has never been registered before), the historical registration location will be empty (can be represented by 0 or null). This field is used to trace the modification history of the data and ensure that the data before and after the modification are linked on the blockchain.

[0086] The above steps define the specific parameters and rules for generating the line verification code. The core idea is to perform a hash calculation on the data source information, feature value, location information, timestamp, user private key, and historical registration location to obtain a fixed-length line verification code. This line verification code contains the data content (through the feature value) and source (through the data source information), the registration context (timestamp, location information), user private information (line verification code key), and modification history (historical registration location). Therefore, the line verification code comprehensively reflects the registration status of the data, and any subsequent tampering with the relevant information will cause the line verification code to fail.

[0087] Therefore, a line-based CAPTCHA can serve as a private verification credential for a single data entry, used to detect whether the data's index information (including data source information, feature values, location information, etc.) has been tampered with. The line-based CAPTCHA is stored only in the user's private storage area and is inaccessible to other users.

[0088] In some possible implementations, after receiving the target data submitted by the user and completing the feature value calculation, a line verification code is generated according to the following sub-steps: The system retrieves data source information and feature values ​​from user requests; retrieves the current registration location information (e.g., current chain length + 1) from the current state of the anti-tamper verification chain; retrieves the current system timestamp; reads the user's line verification key from the user's private storage area; and queries the index information database for the latest index record corresponding to the data source information. If it exists, its storage location is taken as the historical registration location; otherwise, the historical registration location is empty.

[0089] Concatenate the above parameters into a string in a pre-defined order. The concatenation order could be: data source information + feature value + location information string + timestamp string + line verification code key + historical registration location string. To increase randomness, a fixed separator (such as "|") can be added between the parameters.

[0090] The concatenated string is hashed using a secure hash algorithm (such as SHA-256 or SM3) to obtain a fixed-length hash value, which is the verification code.

[0091] The generated line verification code is associated with data source information, feature values, location information, etc., and saved to the user's private storage area. Simultaneously, this line verification code is used as one of the inputs for generating the subsequent verification chain code.

[0092] Linear verification codes (LVCs) contain characteristic values ​​of the data. Any tampering with the data content will cause changes in these characteristic values, resulting in a recalculated LVC that differs from the original, thus being detected. LVCs also contain data such as data source information, location information, and timestamps. If an attacker attempts to modify these fields in the index database (e.g., redirecting the data source information to another file), the recalculated LVC will also be different, effectively preventing index information from being tampered with.

[0093] Furthermore, the verification code is generated using a user-unique verification code key, which is stored exclusively in the user's private storage area. Even if the platform's index database is compromised, attackers cannot forge other users' verification codes because of the lack of the private key. This achieves secure isolation of user data.

[0094] By introducing a historical registration location field, the row CAPTCHA links the current registration to the previous registration. When data is modified multiple times, the historical registration location can be used to trace back to previous indexed records, thus forming a complete modification history. This is crucial for auditing and compliance requirements, such as the preservation of electronic evidence.

[0095] The introduction of timestamps makes line verification codes time-sensitive, preventing attackers from passing verification by copying old line verification codes because the timestamps will be inconsistent.

[0096] The generation of the verification code involves only one hash calculation and a small number of string operations. It does not rely on external services or complex cryptographic protocols and is suitable for high-concurrency scenarios (such as SaaS platforms that process thousands of registration requests per second).

[0097] In some possible implementations, the CAPTCHA key is a user-unique private key, encrypted and stored in the user's private storage area; the CAPTCHA keys of different users are independent of each other.

[0098] As mentioned above, the CAPTCHA key is the user's private key used to generate the CAPTCHA. The CAPTCHA key serves as an input parameter for calculating the CAPTCHA, ensuring that the same data source, the same feature value, and the same location information will generate completely different CAPTCHAs for different users, thus preventing cross-user forgery.

[0099] The user-unique private key emphasizes that the verification code key belongs solely to a single user and cannot be obtained by other users (including platform administrators). Each user has their own independent set of verification code keys, which are not shared with other users. This exclusivity is the technical foundation for achieving user data isolation.

[0100] Encrypted storage means that the CAPTCHA key is encrypted during storage, rather than stored in plaintext. Typically, a platform-level global encryption key (e.g., managed by a Key Management System, KMS) is used to encrypt the user's CAPTCHA key before storing it in the database; it is then decrypted when needed. Even if the storage medium is illegally accessed, attackers cannot directly obtain the plaintext CAPTCHA key.

[0101] A private storage area is an isolated storage space allocated by the platform to each user, accessible only to that user. The private storage area can be a logically isolated database table partition, an independent encrypted file, an object storage bucket, or a keystore based on a hardware security module. In this embodiment, the private storage area is used not only to store line verification codes but also to store the line verification code keys.

[0102] The independence of CAPTCHA keys for different users can be understood as the absence of any correlation or derivation relationship between their keys. That is, even if an attacker obtains user A's CAPTCHA key, they cannot deduce or crack user B's CAPTCHA key. This independence is guaranteed through random generation and independent storage.

[0103] This disclosure establishes a secure and isolated user key management system, making each user's CAPTCHA key their private asset, which cannot be obtained by other users or attackers. In some specific implementations, the CAPTCHA key can be generated according to the following steps: When a new user registers for the first time on a multi-user sharing platform (e.g., creating an account or activating a tenant), the platform automatically calls a cryptographically secure random number generator (CSPRNG) to generate a random byte sequence of sufficient length as the user's line verification key.

[0104] The generated verification code key is encrypted using a system-level master key or by calling a key management service. The encryption algorithm can employ certified encryption modes such as AES-256-GCM to ensure the confidentiality and integrity of the key. The encrypted ciphertext can be securely stored in a database; even if the database is compromised, attackers will not be able to decrypt the verification code key.

[0105] The encrypted verification key is associated with the user's identity and saved to the user's private storage area. Access control to the private storage area must be strictly limited: only the user (or the service process performing the operation on behalf of the user) can read it; other users of the platform, and even platform maintenance personnel (unless they possess the master key), cannot read the plaintext.

[0106] When the user subsequently registers data, the encrypted verification key is read from the private storage area, decrypted using the system master key, and temporarily stored in memory for generating the verification code. It should be immediately removed from memory after use to prevent leakage.

[0107] Each user's CAPTCHA key is generated using an independent random number, and is encrypted using the same master key but a different initialization vector to ensure that the ciphertexts are unrelated. The platform never derives another user's key from one user's key.

[0108] Because each user's CAPTCHA key is independent and private, user A cannot forge user B's CAPTCHA, thus preventing tampering detection of user B's data. Even if the platform's index database is compromised, attackers cannot forge any user's CAPTCHA because they lack the corresponding private key. This achieves secure data isolation in a multi-user environment, meeting the multi-tenant security requirements of SaaS platforms.

[0109] Even if platform operations and maintenance personnel have full access to the database, they cannot directly obtain users' CAPTCHA keys because the CAPTCHA keys are stored encrypted and decryption requires a separate master key. This effectively prevents the risk of internal personnel maliciously tampering with data or forging CAPTCHAs.

[0110] When a new user joins the platform, only a new, independent key is generated for them, without affecting the keys and verification chains of existing users. This stateless design allows the platform to scale horizontally and support millions of users.

[0111] In summary, by limiting the user privacy, encrypting and storing the verification code keys, and ensuring their independence, this disclosure provides a solid security foundation for data locking and tamper-proofing in a multi-user shared environment, thus ensuring user data privacy and the overall trustworthiness of the system.

[0112] Figure 4 The diagram illustrates a process for regenerating the row verification code, updating the verification chain code, and retaining historical traceability information when registered target data is modified. Figure 4 As shown, steps S410, S420, S430, and S440 may be included.

[0113] S410. When a modification to the target data is detected, the feature values ​​of the modified target data are reacquired.

[0114] The target data refers to data that has already been registered. When a user modifies the content of this data, the modified data becomes the "modified target data." Modifications can occur on any type of data, such as when a user updates the content of an electronic contract or modifies field values ​​in a database table.

[0115] In some possible implementations, changes to target data can be detected through proactive monitoring or passive notification reception, such as file monitoring, database triggers, or API calls. For unstructured data (such as files), changes can be detected through file system monitoring (such as inotify) or periodic hash value comparisons; for structured data (such as database records), update events can be captured through database triggers or interceptors.

[0116] Re-obtaining the feature value involves re-hashing the modified target data to obtain a new feature value. This new feature value will be used to generate new line verification codes and verification chain codes.

[0117] In some possible implementations, the modified target data content and its corresponding data source information can be read (this data source information is the same as before the modification, because the data source location remains unchanged). The same hash algorithm is then used to calculate the feature value of the modified data content.

[0118] S420. Based on the data source information of the modified target data, the modified feature value, the new location information, the current timestamp, the line verification code key, and the position of the index information of the target data before modification in the index database, regenerate the line verification code corresponding to the modified target data.

[0119] The modified data will be added as a new entry to the tamper-proof verification chain. Since the verification chain only allows appending, the new entry will occupy the next node position in the chain, and this node number will be the "new position information." The old node corresponding to the original data will remain in the chain and will not be overwritten or deleted.

[0120] The location of the target data's index information in the index database before modification can be the storage identifier of the corresponding index record in the index database before this modification (such as the primary key ID of a database table or a unique key in document storage). This value is used as the "historical registration location" parameter when generating the row verification code to associate the modified data with the data before modification.

[0121] In some possible implementations, the modified target data's data source information, new feature values, new location information, current timestamp, user's line verification key, and the aforementioned "position of the index information before modification" are used as the historical registration location, according to... Figure 3 The hash value is recalculated in the manner described to obtain a new line verification code.

[0122] In some specific implementations, the length of the current anti-tampering verification chain (i.e., the number of existing nodes) is queried, and the location information of the new node is equal to the current length plus 1. Based on the data source information, the latest (i.e., the last registered) index record of the data is retrieved from the index information database, and the storage location of the record (e.g., the primary key ID old_index_id) is obtained. If the data has never been modified, this location is the index position at the time of the initial registration.

[0123] The modified target data's line verification code RV_new is calculated using the formula RV_new = Hash(data source information + modified feature value + new location information + current timestamp + user line verification code key + old_index_id).

[0124] S430. Based on the current end-of-chain code of the tamper-proof verification chain and the regenerated row verification code, generate a new verification chain code and update the end-of-chain code.

[0125] The new verification chaincode is a new node value calculated using a hash algorithm based on the current tamper-proof verification chain's end code, the regenerated row verification code, and the verification chain key. This verification chaincode will be added to the end of the chain and become the new chain end code.

[0126] In some possible implementations, the generated verification chain code can be used as the new chain terminator by updating the end-point pointer of the tamper-proof verification chain to the newly generated verification chain code. Subsequent data registrations or modifications will then be based on this new end-point code.

[0127] In some specific implementations, the end-of-chain code EC_current of the current tamper-proof verification chain can be obtained, and a new verification chain code can be generated using the platform-level verification chain key through the following formula: V_new = Hash(EC_current + RV_new + verification chain key) Add V_new to the end of the tamper-proof verification chain and update the chain end code to V_new.

[0128] S440. Save the position of the index information of the target data before modification in the index database as the historical registration position of the index information of the target data after modification.

[0129] In the modified new index information, the "position of the index information before modification" will be filled into the historical registration position field. A new index record will be created, containing data source information, new feature values, new location information, new verification chaincode, new timestamp, historical registration position (i.e., old_index_id), and a newly generated row verification code (the row verification code is saved to the user's private storage area). At the same time, the old index record will be retained unchanged.

[0130] In this way, by using the historical registration position in the new index record, the old index record before the modification can be traced back, thus forming a complete modification history chain.

[0131] In some possible implementations, a pointer to the old index record is created using the historical entry position field in the new index record. This allows subsequent retracing back to the state before the modification.

[0132] By retaining old index records and writing historical registry locations into new index records, every modified version of the data is fully preserved. Even if the data is modified multiple times, the initial version can be traced back through the historical registry location chain. This is crucial for scenarios requiring strict auditing, such as electronic evidence storage, medical records, and financial transactions.

[0133] The modification operation does not overwrite existing chain nodes; instead, it appends new nodes to the end of the chain. Existing chain nodes remain valid, and any tampering with the old version will still be detected by subsequent chaincode. This ensures that the integrity of the entire chain is not compromised by legitimate modifications.

[0134] Each version of the index record contains independent data feature values ​​and row verification codes, allowing for individual integrity verification of any historical version. For example, a user can verify whether a contract version from a year ago has been tampered with, without relying on the current version.

[0135] Because the new verification chaincode relies on the old chain's endcode, modifications automatically strengthen the lock on the older version. If someone attempts to tamper with the old version's data, verification of the new version and all subsequent versions of the chaincode will fail. This design makes modifications not "unlocking" but rather "re-hardening."

[0136] In summary, the above steps provide a complete solution for handling data modification within an anti-tampering verification chain framework. This solution ensures both the flexibility for users to modify data and the integrity of the global chain and the non-repudiation of historical data. It is an important component of the embodiments of this disclosure for achieving dynamic data locking in a multi-user shared environment.

[0137] Figure 5 This diagram illustrates a flowchart of one implementation method for generating a verification chaincode corresponding to the target data based on the current chain end code and row verification code. Figure 5 As shown, step S510 may be included.

[0138] S510. Based on the current chain end code, row verification code, and verification chain key, generate the verification chain code corresponding to the target data. The verification chain key and the line verification code key are independent keys. The verification chain key is managed uniformly by a multi-user shared platform, while the line verification code key is held separately by each user.

[0139] The current chain-end code is the value of the last node in the tamper-proof verification chain. When a user registers data, the current chain-end code is read as one of the inputs for generating a new verification chain code. This value is dynamically updated with each data registration (including initial registration and modifications).

[0140] The verification code is based on Figure 3 The user-owned verification credential generated in the aforementioned steps is obtained through hash calculation using data source information, feature values, location information, timestamps, row verification code keys, and historical registration locations. The row verification code is used both for verifying the integrity of a single data entry and as one of the inputs for generating the verification chain code.

[0141] The verification chain key is a platform-wide shared key used to generate verification chain codes for all users. This key is generated during platform initialization, managed centrally by the platform, and not disclosed to any user. The platform itself (not the user) is responsible for generating, storing, rotating, and destroying the verification chain key. The platform typically stores the verification chain key in a hardware security module, key management service, or encrypted configuration file, accessible only to the platform's core services. Users have no right to obtain or modify the verification chain key.

[0142] The chain verification key and the row verification key are independent of each other and serve different cryptographic purposes: the chain verification key is used to ensure the global consistency of the chain, and the row verification key is used to ensure the privacy of user data.

[0143] There is no mathematical or logical derivation relationship between the verification chain key and the row CAPTCHA key. That is, knowing the row CAPTCHA key does not allow you to deduce the verification chain key, and vice versa. They are generated from different random sources, stored in different locations, and managed by different roles. This independence ensures that even if one type of key is compromised, the security of the other type will not be affected.

[0144] In some possible implementations, the verification chaincode is calculated using the following formula: Verification chaincode = Hash(current chain end code + row verification code + verification chain key).

[0145] This formula incorporates a platform-level key into the hash operation, making the chaincode verification not only dependent on the previous chaincode and the line verification code, but also on a platform-private secret, thus enhancing the unforgeability of the chaincode.

[0146] The core of the above steps lies in introducing a platform-level verification chain key when generating the verification chain key, and explicitly managing this key independently from the user's line verification code key. This design ensures that the security of the verification chain key no longer relies solely on the collision resistance of the hash function, but also adds a layer of platform-private secrecy, effectively preventing external attackers from forging the verification chain key even if they obtain the line verification code.

[0147] In some specific implementations, during the user data registration process (including initial registration and modification processing), the verification chaincode can be generated according to the following steps: The shared storage area reads the current end code EC_current of the tamper-proof verification chain. This value may be a fixed initial code during platform initialization, or it may be a verification chain code generated from the previous data registration. The row verification code RV is already in... Figure 3 This value is generated during the corresponding steps and stored in the user's private storage area. It is then read from memory or private storage. The verification chain key, Key_VC, is read from secure storage.

[0148] A secure hash algorithm is used to perform a hash calculation on the concatenated string. The concatenation order is usually: current chain end code + line verification code + verification chain key, but a separator or fixed format can also be added. The specific calculation formula can be: V_new = Hash(EC_current || RV || Key_VC), where || represents byte string concatenation.

[0149] The calculated V_new is added as the new end code to the end of the tamper-proof verification chain, and the chain end code in memory and persistent storage is updated.

[0150] The verification chain key must never be mixed with the verification code key, nor used for any other purpose (such as encrypting user data). The platform should strictly limit access to the verification chain key, allowing only the verification chain code generation module to call it.

[0151] The generation of the verification chaincode relies not only on the previous value and the row CAPTCHA on the chain, but also on a platform-private verification chain key. Even if an attacker gains complete control of the user's client and can construct any row CAPTCHA, they cannot generate a legitimate verification chaincode because the verification chain key is stored solely on the platform and cannot be accessed. This effectively prevents attacks that allow clients to bypass the server and directly forge chaincode.

[0152] The verification chain key (platform-level) and the line CAPTCHA key (user-level) are independent and serve different security boundaries. The line CAPTCHA key protects the privacy and integrity of user data and prevents cross-user forgery; the verification chain key protects the global consistency of the entire chain and prevents external attackers from forging chain nodes. The independent management of these two types of keys ensures that even if one type of key is compromised (e.g., a user's line CAPTCHA key is stolen due to a client-side vulnerability), attackers cannot compromise the integrity of the verification chain because the verification chain key remains secure. This achieves a defense-in-depth security architecture.

[0153] The verification chain key is automatically generated and rotated by the platform, requiring no knowledge or management of the key by the user. This contrasts with traditional public key infrastructure schemes, which require each user to manage their own public-private key pair, increasing user burden and deployment complexity. This disclosed embodiment is completely transparent to the user; users simply need to use the platform normally to enjoy tamper-proof protection.

[0154] In some possible implementations, the verification chain key can be rotated periodically according to a security policy (e.g., every 90 days). During rotation, all verification chaincodes after a certain checkpoint need to be recalculated, but this can be done offline in batches without affecting online services. This rotation mechanism further enhances long-term security.

[0155] In summary, the above steps, by introducing a platform-level verification chain key and clarifying its independence from the user's verification code key, provide a robust cryptographic foundation for the tamper-proof verification chain in a multi-user shared environment, ensuring that the overall security system can still operate effectively even if some keys are leaked.

[0156] Because a CAPTCHA contains data source information, feature values, location information, timestamps, the CAPTCHA key, and historical registration locations, any tampering with these parameters (including the data content) will result in a recalculated CAPTCHA that is inconsistent with the original one. Therefore, data verification can be performed based on the CAPTCHA.

[0157] Figure 6 A flowchart illustrating one implementation of data verification based on line-based CAPTCHAs is shown, such as... Figure 6 As shown, steps S610, S620, S630, S640, and S650 may be included.

[0158] S610. Obtain the data to be verified and its corresponding data source information, and calculate the feature values ​​of the data to be verified.

[0159] The data to be verified is the data whose integrity the user wishes to verify. This data could be a currently used file, a database record, or a historical version of data. The data to be verified should have the same data source information (e.g., the same file path or database primary key) as the previously registered target data in order to match the index information.

[0160] Data source information uniquely identifies the source of the data to be verified. For files, this can be the storage path and filename; for database records, it can be the database name, table name, or primary key value. During verification, the data source information is used to search for the corresponding record in the index.

[0161] The characteristic value of the data to be verified is recalculated using the same hash algorithm (such as SHA-256). If the data has not been tampered with, this characteristic value should be consistent with the characteristic value saved at the time of registration.

[0162] In some specific implementations, users submit a data file or database record to be verified through a client (web interface, API, command-line tool), providing the data source information (e.g., file path, database table name, and primary key). The system retrieves the data to be verified and its corresponding data source information by receiving information from the user. The content of the data to be verified is hashed using the same hash algorithm used during registration to obtain the current characteristic value H_current.

[0163] S620. Based on the data source information, obtain the index information that is associated with and saved with the data source information. The index information includes at least the location information when the data to be verified was registered.

[0164] The index information is a set of metadata associated with the data source information, including at least the location information of the data to be verified at the time of registration (i.e., the node number of the data's verification chain code in the tamper-proof verification chain). The index information is typically stored in the platform's index library and can be read, but it does not contain the row verification code (the row verification code is stored in the user's private area). As mentioned above, the index information may also include the timestamp used during registration and historical registration locations.

[0165] In some specific implementations, the data source information is used as the key to retrieve the corresponding index record from the index database. The index record should at least contain the position information at the time the data was registered. If no record is found, it means the data has never been registered, and an "unregistered" alert can be triggered directly.

[0166] S630. Obtain the row verification code that is associated with the data source information and stored in the private storage area of ​​the user corresponding to the data to be verified.

[0167] The private storage area is an isolated storage space allocated by the platform to each user, accessible only to that user. The CAPTCHA and its key are stored in this area. During verification, the CAPTCHA and its key, which are associated with the data source information, are retrieved from this area.

[0168] The row verification code is a private verification credential generated during data registration. As mentioned above, its calculation formula is: Row Verification Code = Hash(Data Source Information + Feature Value + Location Information + Timestamp + Row Verification Code Key + Historical Registration Location). During verification, the system recalculates the expected row verification code using the same parameters and compares it with the stored row verification code.

[0169] In some possible implementations, the previously saved row verification code RV_stored can be retrieved from the user's private storage area based on the data source information and the current user's identity. The private storage area is typically queried using the user ID and data source information as a composite primary key. If the corresponding row verification code is not found, it indicates that the user has never registered the data or that the private storage has been compromised, and an alert should be triggered.

[0170] S640. Using data source information, feature values, and location information, recalculate the expected line verification code.

[0171] In some possible implementations, the CAPTCHA is recalculated using the exact same parameters and algorithm as during registration. The following parameters need to be collected: data source information (same as in step S610), current feature value H_current (calculated in step S610), position information (obtained from the index information), the timestamp used during registration (original_timestamp, which is stored in the index information and can therefore be obtained from it), the user's CAPTCHA key (obtained from the private storage area, the same as the CAPTCHA key in step S630), and the historical registration position history_position (obtained from the index information; empty if it is the first registration).

[0172] Therefore, the recalculated formula is: RV_calc = Hash(data source information + H_current + position + original_timestamp + user line verification code key + history_position).

[0173] The recalculated RV_calc is compared with the RV_stored retrieved from private storage. If they are the same, it means that the data content, data source information, location information, and historical registration location have not been tampered with, and the verification passes. If they are different, it means that at least one of them has changed, triggering a tampering alarm.

[0174] S650. If the expected verification code is inconsistent with the obtained verification code, a tampering alarm will be triggered.

[0175] A tampering alert is a warning signal triggered by the system when the expected CAPTCHA does not match the saved CAPTCHA. Alerts can take various forms: logging into audit logs, sending emails or text messages to the user, displaying warnings on the user interface, blocking subsequent operations, or invoking notifications to third-party monitoring systems.

[0176] In some specific implementations, when verification fails, detailed logs can be recorded (including user ID, data source information, verification time, expected and actual values, etc.), and notifications can be sent to users and administrators according to the configuration. Alerts can prevent subsequent operations (such as prohibiting the use of the data) or simply serve as warnings.

[0177] Using the above method, it is not necessary to verify the entire anti-tampering verification chain. Only the row verification code of the data to be verified needs to be recalculated and compared with the saved value to determine whether the data and its associated index information have been tampered with. The time complexity is O(1), which is much faster than the O(n) verification of traversing the entire chain, making it suitable for high-frequency verification scenarios (such as automatic verification before each file is opened).

[0178] The verification process only involves the CAPTCHA and key stored in the user's private storage area and does not require access to other users' data. The platform's index database also does not contain the CAPTCHA; therefore, even if the index database is leaked, attackers cannot obtain the CAPTCHA to forge verifications. Users can also verify data integrity by comparing local data with the CAPTCHA offline.

[0179] The entire verification process uses only local hash calculations and does not rely on external services or network consensus. The response time is typically in the millisecond range, making it suitable for applications with high real-time requirements (such as online transaction verification and real-time data synchronization).

[0180] The input parameters for the row verification code encompass the data content (feature value), data source (data source information), on-chain position (location information), registration time (timestamp), user privacy (row verification code key), and modification history (historical registration position). Therefore, tampering with any of these dimensions will lead to verification failure, achieving multi-dimensional integrity protection. Furthermore, since the verification uses the original timestamp from registration (not the current time), attackers cannot pass verification by replaying old row verification codes, as the feature value, timestamp, etc., of the old row verification code do not match the current data.

[0181] In summary, the steps described above provide an efficient, private, and comprehensive method for verifying single data entries, enabling users or systems to quickly detect data tampering without relying on the entire anti-tampering chain. This method is particularly suitable for users in SaaS platforms to periodically check their own data, and is also suitable as a lightweight solution for real-time integrity checks.

[0182] In some possible implementations, the integrity of data in the tamper-proof verification chain can also be detected by recalculating and comparing the verification chain code.

[0183] Figure 7 The diagram illustrates a flowchart of one implementation method for detecting the integrity of data in a tamper-proof verification chain by recalculating and comparing the verification chaincode. Figure 7 As shown, steps S710, S720, S730, S740, and S750 may be included.

[0184] S710: Obtain the data to be verified and its corresponding data source information, and the line verification code.

[0185] The data to be verified is the data whose integrity the user wishes to verify. This data has previously been registered on the platform as target data and associated with a verification chaincode. Verification of the verification chaincode can be performed independently or in conjunction with a CAPTCHA. Figure 6 The corresponding verification process is combined.

[0186] Data source information uniquely identifies the source of the data to be verified. It is used to retrieve the corresponding index record and verification chaincode in the index information database.

[0187] The verification code is based on Figure 3 The corresponding method generates the user's private verification credentials. The verification code, as one of the input parameters for recalculating the expected verification chaincode, can be obtained from the user's private storage area or from... Figure 6 The corresponding verification step directly obtains RV_calc as the line verification code for recalculating the expected verification chaincode.

[0188] In some possible implementations, the data to be verified can be obtained based on user-provided data source information. Simultaneously, the corresponding row verification code can be obtained (it can be read from the user's private storage area, or from...). Figure 6 (Obtained from the calculation results of the corresponding verification steps).

[0189] S720. Based on the data source information, obtain the index information and the verification chain code associated with the data source information. The index information includes at least the location information when the data to be verified was registered.

[0190] The index information is metadata that is associated with the data source information and includes at least the location information of the data to be verified when it is registered (i.e., the node number of the data in the anti-tampering verification chain).

[0191] The index information does not contain the line verification code (the line verification code is stored in a private area), but since the index information is stored in association with the verification chain code, the verification chain code can be obtained through the index information.

[0192] The verification chain code is a node value on the tamper-proof verification chain. It is generated during data registration using a hash algorithm from the current chain end code, row verification code, and verification chain key. The verification chain code is stored in association with index information and is used to verify the integrity of the chain.

[0193] In some possible implementations, the data source information can be used as the key to retrieve the corresponding index record from the platform's index database. This record must at least contain the position information of the data to be verified when it was registered, as well as the associated stored verification chaincode (stored_VC). If no record is found, it means that the data has never been registered, which can trigger an "unregistered" alarm.

[0194] S730. Based on the location information, obtain the last chain code of the previous chain when the data to be verified was registered from the anti-tampering verification chain.

[0195] The location information refers to the node number (e.g., the 5th node) of the data to be verified within the tamper-proof verification chain. Based on this location information, the node and its preceding node can be located within the chain.

[0196] The previous chain end code is the end code of the tamper-proof verification chain at the time the data to be verified was registered. Since each new node is generated based on the end code at that time, the previous chain end code is the predecessor node value of the verification chain code corresponding to the data to be verified. For the first node in the chain (position 1), its previous chain end code can be defined as a fixed initial code. This value can be obtained from the tamper-proof verification chain based on the position information.

[0197] In some possible implementations, since the tamper-proof verification chain stores all verification chain codes sequentially (e.g., an array or linked list), the node can be directly located based on its position information, and the value of its preceding node can be obtained. For a node at position p, its preceding node is at position p-1. If p=1 (the first node), the preceding chain end code should be a fixed initial code (i.e., the start of the chain). This value is read from the chain storage area and denoted as prev_end_code.

[0198] S740: Based on the previous chain end code, the line verification code, and the preset verification chain key, recalculate the expected verification chain code.

[0199] The preset verification chain key is a platform-wide shared key used to generate all verification chaincodes. This key is generated during platform initialization and stored securely. During verification, the same key is used to recalculate the expected verification chaincode.

[0200] The expected verification chaincode is a recalculated chaincode based on the previous chain terminator, row verification code, and verification chain key, following the same method used to generate verification chaincode. If the data has not been tampered with and the chain is intact, this value should match the verification chaincode stored in the index information.

[0201] In some possible implementations, the expected verification chaincode is calculated using the exact same hash algorithm and parameter concatenation method used to generate the verification chaincode: That is, expected_VC = Hash(prev_end_code || RV || Key_VC); Wherein, RV is the obtained line verification code, and Key_VC is the platform's preset verification chain key.

[0202] The recalculated `expected_VC` is compared with the `stored_VC` obtained from the index information. If they are the same, it means that the node's integrity in the chain has not been compromised, and the verification passes. If they are different, a tampering alarm is triggered.

[0203] S750. If the expected verification chain code is inconsistent with the saved verification chain code, a tampering alarm will be triggered.

[0204] This is a warning signal triggered by the system when the expected verification chaincode is inconsistent with the saved verification chaincode. This indicates that either the content or associated parameters of the data to be verified have been tampered with (causing a change in the line verification code), the previous chain terminator has been tampered with (chain break), or the verification chain keys do not match.

[0205] In some possible implementations, when verification fails—that is, when the expected verification chaincode is inconsistent with the saved verification chaincode—detailed logs can be recorded (including user ID, data source information, location information, expected chaincode value, actual saved chaincode value, etc.), and an alert can be sent to the user and administrator. The alert may indicate "Data integrity verification failed; the data may have been tampered with or the chain may have been broken."

[0206] The above verification steps aim to leverage the chain dependency of the tamper-proof verification chain to verify whether the position of a single piece of data in the chain has been corrupted. Since each verification chaincode depends on the previous chain terminator and the row verification code of the data, recalculating the expected verification chaincode and comparing it with the stored value can detect the following three tampering scenarios: 1. The content of the data to be verified or the associated index information (such as data source information, location information, etc.) has been tampered with, resulting in a change in the verification code; 2. The last chain terminator (i.e., the previous node in the chain) has been tampered with; 3. The verification chain key has been misused or tampered with.

[0207] The above verification process is independent of row CAPTCHA verification, but they are usually used in combination: first verify the row CAPTCHA to confirm whether the content of the data to be verified or the associated index information has been tampered with, then verify the verification chain key to fully confirm the data integrity. If the row CAPTCHA verification passes and the verification chain key has not been tampered with, it means that the previous chain end key has been tampered with, therefore, the previous chain end key can continue to be verified.

[0208] By recalculating the verification chaincode and comparing it with the stored value, it is possible to detect if any node in the tamper-proof verification chain has been tampered with. Once the value of a node on the chain is modified, the verification of all subsequent nodes will fail, thus forming a strong integrity protection system where "a single change affects the whole chain".

[0209] Verifying the chaincode dependencies implicitly "locks" each piece of data to the previous one (because a change to the previous chaincode will cause the verification of the subsequent chaincode to fail). Through the verification steps described above, users can confirm whether their data is still protected by subsequent data. Unlike traditional chain verification, which requires sequential verification starting from the initial code, this embodiment allows independent verification for a single node, requiring only the acquisition of the previous chain's end code and the row verification code of the current data. This significantly reduces the computational complexity of verification from O(n) to O(1), making it particularly suitable for scenarios with a large number of concurrent verification requests in SaaS platforms.

[0210] The combination of detecting tampering with data content and index information and detecting tampering with the chaincode itself provides comprehensive integrity protection: even if an attacker bypasses the row CAPTCHA (for example, by simultaneously tampering with both the data content and the row CAPTCHA in private storage), chaincode verification will still fail because the chaincode relies on the platform's verification chain key, which the attacker cannot forge. Conversely, if an attacker only tampers with the chaincode, row CAPTCHA verification will still pass, but chaincode verification will issue an alert.

[0211] In summary, the above steps provide a lightweight and highly reliable method for verifying the integrity of the verification chain, enabling users or systems to quickly detect anomalies in the tamper-proof verification chain and form a complete security loop with the line verification code verification, greatly enhancing the data credibility of multi-user shared platforms.

[0212] In some possible implementations, the multi-user sharing platform employs a role-based access control mechanism to manage each user's access rights to the verification codes in their private storage area, as well as each user's access rights to read the end-of-chain code of the tamper-proof verification chain.

[0213] RBAC (Role-Based Access Control) is an access control model where permissions are not directly granted to individual users, but rather to "roles," which are then assigned to users. Each role corresponds to a set of predefined operation permissions (e.g., read, write, delete). Through the user-role-permission mapping, the permissions of a large number of users can be flexibly managed, reducing management complexity. In this embodiment, the role-based access control mechanism is used to distinguish different users' different access levels to private storage and shared chains.

[0214] In a multi-user shared platform, two key security objectives are achieved through role-based access control mechanisms: User-private storage area for line CAPTCHA access isolation: This ensures that each user can only access their own line CAPTCHA, and other users cannot read or modify it. This is the foundation for protecting user privacy and preventing cross-user forgery.

[0215] Tamper-proof verification chain end-code shared reading: Ensures that all users can read the current chain end-code (because subsequent registration depends on it), but at the same time prevents ordinary users from directly modifying the chain end-code or other parts of the chain.

[0216] In some specific implementations, multi-user sharing platforms need to establish the following roles and permission policies: Role definition: Regular User Role: A registered regular user who has the authority to register, modify, and verify their own data.

[0217] Auditor role: Can read all nodes and index information in the chain, but cannot modify any data.

[0218] Platform Administrator (Admin): Responsible for user management, role assignment, and system configuration, but cannot directly access plaintext verification codes in users' private storage.

[0219] Permission assignment: For private storage areas: Each user's private storage area should be configured such that only the user's own identity (User role) and the system service role (System) can read and write it. The system service role acts on behalf of the user when a user requests it, and must be authenticated by the user.

[0220] For the end-chain code of the tamper-proof verification chain: The chain terminator is stored in a public key-value store or database. All users are granted read access.

[0221] Ordinary users cannot directly call the API to update the end-of-chain code; they can only trigger the update indirectly through the data registration interface provided by the platform.

[0222] Access control implementation: At the API gateway or business logic layer, perform identity authentication and role checks on each request. For example, when a user requests to read the end-of-chain code, check if they have read permissions; when a user requests to read the line verification code in private storage, check if the user_id in the request matches the logged-in user.

[0223] For private storage, isolation can be achieved using row-level security policies in the database or by using different encrypted partitions.

[0224] A role-based access control mechanism ensures that each user can only access their own private storage area for line verification codes and keys. Other users (including malicious users or platform administrators) cannot read this private data, thus preventing cross-user line verification code forgery and privacy leaks. This meets the core requirement of multi-user shared platforms for multi-tenant data isolation. All users can read the current end-of-chain code, which is the basis for "automatically locking the data of previous users by subsequent users." However, ordinary users cannot modify the end-of-chain code or other nodes in the chain, ensuring that the integrity of the chain is not compromised by unauthorized operations.

[0225] In some possible implementations, the multi-user sharing platform is a SaaS platform. The SaaS platform supports asynchronous callback mechanisms and real-time monitoring, which is used to push notifications to users when data is registered or tampered with.

[0226] A SaaS platform is a delivery model that provides software services to multiple users (tenants) via the internet. Users do not need to deploy hardware or install software themselves; they can use the platform's functions simply through a browser or API. In this embodiment, the SaaS platform carries a shared, tamper-proof verification chain for multiple users, providing data registration, locking, and verification services to different organizations or individuals. Typical SaaS platforms include electronic contract platforms, electronic certificate platforms, and cloud-based document management systems.

[0227] Asynchronous callbacks are a programming design pattern in which, after an operation (such as data registration or tampering alarm) is completed, the system does not immediately return the result to the caller. Instead, it proactively notifies the caller through a pre-registered callback address. Asynchronous callbacks are suitable for time-consuming operations or scenarios requiring real-time notifications, preventing callers from waiting for extended periods and improving system throughput and responsiveness. In this embodiment, the SaaS platform supports user registration of callback addresses. When data registration is successful or a tampering alarm is detected, the platform sends a request or message to this address, allowing the user to perform subsequent processing.

[0228] Real-time monitoring refers to the continuous, near-real-time tracking and display of platform operating status, data registration events, and tamper detection results. It is typically achieved through dashboards, log streams, and message pushes. Real-time monitoring enables administrators or users to understand the data integrity status immediately and respond promptly in the event of tampering.

[0229] In some possible implementations, the user submits the target data, and the SaaS platform performs the above-mentioned initialization, feature extraction, line verification code generation, verification chain code generation and storage operations to complete the data registration. Then, it pushes a registration notification to the user through an asynchronous callback mechanism.

[0230] When the above verification steps are performed and the expected verification code or expected verification chain code is found to be inconsistent with the saved value, a tampering alarm is generated and pushed to the user through an asynchronous callback mechanism.

[0231] The asynchronous callback mechanism allows user systems to continue executing other tasks without waiting for a platform response, enabling the platform to process registration requests in batches and improve throughput. Simultaneously, the callback mechanism loosely couples the platform with external systems, facilitating integration. When data is tampered with, the SaaS platform can notify users or security teams within seconds via callbacks, allowing users to take immediate action (such as deactivating the data or initiating source tracing). This is far more efficient than the reactive approach of traditional log auditing.

[0232] The following is a detailed description of the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure, using a specific embodiment applied to a particular SaaS electronic contract platform scenario.

[0233] A company operates a SaaS electronic contract platform targeting small and medium-sized enterprises (SMEs). This platform employs a two-way anchored data anti-tampering method based on a multi-user shared platform, as described in this disclosure. The platform supports multi-tenancy (multiple enterprise users), with each enterprise user having multiple employee sub-accounts. For simplicity, this specific embodiment uses two enterprise users (Enterprise A and Enterprise B) as an example, with each enterprise considered a "user" (a user can also be a tenant or an individual). The platform is deployed on a cloud server.

[0234] Platform maintenance personnel obtain the platform key from the system developer, generate a 128-bit platform initialization code, and obtain the current UTC timestamp.

[0235] The fixed initialization code IC = SHA-256(platform key + initial timestamp + platform initialization code). At the same time, a 256-bit verification chain key (platform-level shared) Key_VC is generated and stored in AWS KMS encrypted storage.

[0236] Store IC as the first node (position 1) in the database table tamper_chain. Set the chain end code EC = IC and persist it. Initialization complete, platform ready.

[0237] User A (Company A) uploads a contract document and the data source information for that document through a web interface.

[0238] The platform reads the binary stream of the file and calculates the SHA-256 signature: H_A1 = SHA-256(file content).

[0239] Get position information: Current chain length = 1, new position pos = 2.

[0240] Obtain the user's line verification code key: When user A makes their first operation, the platform calls the random number generator to generate a unique line verification code key for user A: Key_RV_A, which is then encrypted using the platform's master key and stored in the private storage table user_private (accessible only to user A).

[0241] Get the current timestamp.

[0242] Historical registration location: First registration, empty (0).

[0243] Calculate the line verification code: RV_A1 = SHA-256(data source information + H_A1 + pos + T1 + Key_RV_A + 0).

[0244] Associate RV_A1 with the data source information and user ID, and store it in user A's private storage area (the database table user_private has a row-level security policy that restricts it to be readable only by user A).

[0245] Get the current chain end code: EC_current = IC. Read the verification chain key: Key_VC (platform level). Calculate the new verification chain code: V2 = SHA-256(EC_current + RV_A1 + Key_VC).

[0246] Add V2 as a new node (position 2) to tamper_chain and update the chain end code EC = V2.

[0247] Insert a record into the index_records table: RBAC: User A can only access their own private storage and index records; other users (such as user B) cannot read user A's private line verification codes.

[0248] Asynchronous callback: User A included a callback URL in their registration request. After registration is complete, the platform automatically sends a POST request: json {"data_source":"Data source information","chain_code":"V2","status":"success"} The file corresponding to the data source information has been successfully registered, and the corresponding verification chaincode is V2.

[0249] Real-time monitoring: The metric data_registration_total increases by 1, displaying the latest registered events.

[0250] User B (Company B) uploads the contract and obtains the corresponding data source information.

[0251] Feature value: H_B1 = SHA-256 (file content).

[0252] Position information: Current chain length = 2, new position pos = 3.

[0253] User B's verification key: A newly generated Key_RV_B, independent of user A's key.

[0254] Line verification code: RV_B1 = SHA-256(data source information + H_B1 + 3 + T2 + Key_RV_B + 0).

[0255] Current chain end code: EC = V2.

[0256] Verify the chaincode: V3 = SHA-256(V2 + RV_B1 + Key_VC).

[0257] Update the chain terminator to V3 and save the index record.

[0258] User B's registration action makes V3 dependent on V2. If someone tampers with User A's contract in the future (causing a change in V2), then User B's verification chaincode V3 will not be able to match. Therefore, User B's operation "locks" User A's data, achieving forward anchoring—subsequent data automatically locks all previous data.

[0259] User A modified the uploaded contract file, generated a new version, and uploaded it again, overwriting the original file. The platform detected that the data source already existed and triggered the modification process.

[0260] New signature: H_A2 = SHA-256 (new file content).

[0261] Querying old index records: We get old index ID = 101 (hypothetically), and historical registration position old_pos = 101.

[0262] New position information: Current chain length = 3, new position pos = 4.

[0263] Current timestamp.

[0264] Use user A's line verification key (unchanged): RV_A2 = SHA-256(data source information + H_A2 + 4 + T3 + Key_RV_A + 101).

[0265] Store RV_A2 in user A's private storage (retain the old RV_A1 for historical verification).

[0266] Current chain end code: EC = V3.

[0267] New verification chaincode: V4 = SHA-256(V3 + RV_A2 + Key_VC).

[0268] Add V4 to the chain (position 4) and update the end code to V4.

[0269] New index record: (data_source, H_A2, 4, V4, T3, history_pos=101).

[0270] The old index record (position 2) remains unchanged.

[0271] The modification operation preserves historical versions, with the new version pointing to the old version through historical registration positions, forming a modification chain. Meanwhile, the new verification chain code V4 depends on V3, and V3 depends on V2 and V1. Therefore, the modification does not break existing anchors; on the contrary, the extension of the chain further strengthens the locking of historical data.

[0272] User A wants to verify the integrity of the current contract documents.

[0273] Recalculate the feature value: H_current = H_A2 (assuming it has not been tampered with).

[0274] Retrieve location information from the index: pos = 4.

[0275] Retrieve the line verification code from user A's private storage: RV_stored = RV_A2.

[0276] Recalculate the expected line verification code: RV_calc = SHA-256(data source information + H_current + 4 + T3 + Key_RV_A + 101).

[0277] Comparison: RV_calc equals RV_stored, verification passed. If the file has been tampered with, H_current will change, the comparison will fail, triggering an alarm.

[0278] User B wants to verify whether their contract is still locked on the blockchain.

[0279] Obtain the data source information and get the position pos = 3. The verification chain code V3 has been saved.

[0280] Retrieve the previous chain end code from the tamper-proof verification chain: the value of position 2 is V2.

[0281] Retrieve the line verification code RV_B1 from user B's private storage.

[0282] Recalculate the expected verification chaincode: V_calc = SHA-256(V2 + RV_B1 + Key_VC).

[0283] Comparison: If V2 in the chain has not been tampered with and the data has not been modified, then V_calc = V3, and the comparison is successful. If an attacker tampers with user A's historical contract, causing V2 to change, then V_calc will not be equal to V3, triggering a tampering alarm, which can be notified to user B via a callback.

[0284] Each new node depends on the previous node (V2 depends on IC, V3 depends on V2, V4 depends on V3), forming a unidirectional chain.

[0285] Because subsequent nodes depend on previous nodes, subsequent data registration automatically locks all historical data. For example, user B's registration locks user A's original contract; user A's modification operation, in turn, locks user B's contract (because V4 depends on V3). This forward dependency is the key difference between this invention and the underlying patent.

[0286] Each piece of data is bound to its own characteristics and user key through a private line verification code, making it impossible to forge the line verification code even if the chaincode is repaired.

[0287] The combination of these three elements ensures that once data is written to the platform, it is anchored in multiple dimensions and in both directions, making it exponentially more difficult to tamper with over time.

[0288] The platform has three roles: USER, AUDITOR, and ADMIN. Regular users can only read and write to their own private storage; auditors can read the entire index and chain, but cannot modify it; administrators are responsible for user management. Row-level security policies ensure that user A cannot read user B's row verification code.

[0289] After User A modifies the contract, the platform sends a "modification successful" notification to the registered Webhook; when a tampering alarm occurs, the platform immediately calls back the preset alarm URL, and Company A's monitoring system can respond automatically.

[0290] The system collects data on chain length, registration rate, and alarm count, displaying it on a real-time dashboard. When three consecutive verification failures are detected, a message is sent to the operations and maintenance personnel.

[0291] This specific embodiment fully demonstrates the actual operation process of the technical solution corresponding to the two-way anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure. Compared with the prior art, it achieves the following in a multi-user sharing environment: Two-way anchoring: forward + backward + self-anchoring, with security far exceeding that of unidirectional chains.

[0292] User data isolation: private storage of CAPTCHAs, with fine-grained RBAC control.

[0293] Efficient verification: Single-node O(1) verification, no need to traverse the entire chain.

[0294] Compliance modifications: Historical versions are retained, and modifications are traceable.

[0295] Therefore, the embodiments disclosed herein solve the problems of easy data tampering and lack of cross-user mutual protection in SaaS multi-user platforms.

[0296] Based on and Figure 1 The method shown follows the same principle. Figure 8 This illustration shows a schematic diagram of a bidirectional anchored data anti-tampering device based on a multi-user sharing platform, as provided in an embodiment of this disclosure. Figure 8 As shown, the bidirectional anchored data anti-tampering device 80 based on a multi-user sharing platform may include: The initialization module 810 is used to initialize a platform-shared anti-tamper verification chain for the multi-user sharing platform. The anti-tamper verification chain has a fixed initial code and a dynamically updated chain end code. The feature value calculation module 820 is used to obtain the feature value of the target data in response to any user submitting target data and its data source information on the multi-user sharing platform. The line verification code module 830 is used to generate a line verification code corresponding to the target data based on the data source information, feature value and the position information of the target data in the anti-tampering verification chain, and save the line verification code in the user's private storage area; The verification chain code module 840 is used to obtain the current chain end code of the anti-tampering verification chain, generate the verification chain code corresponding to the target data based on the current chain end code and the row verification code, and add the verification chain code as the updated chain end code to the end of the anti-tampering verification chain, so that the verification chain code becomes the new chain end code of the anti-tampering verification chain. Storage module 850 is used to associate and save the verification chaincode with the index information of the target data.

[0297] In the bidirectional anchored data anti-tampering device based on a multi-user sharing platform provided in this disclosure embodiment, all user data registrations extend along the same chain, and subsequent user operations automatically strengthen the immutability of all previous user data. Any tampering with historical data will cause the chain to break, meaning that a locking effect is automatically generated each time data is registered, requiring no additional operations, thus realizing a proactive security mechanism of "registration equals locking, subsequent actions equal reinforcement." Simultaneously, the line verification code is privately stored by the user, protecting user data privacy. It contains sensitive information such as data characteristics, timestamps, and keys; even if the index information database is compromised, attackers cannot forge the line verification code to bypass tampering detection. Furthermore, all operations involve only local hash calculations, requiring no distributed consensus or blockchain node synchronization, supporting high concurrency and real-time alerts, making it highly suitable for cloud service scenarios such as SaaS.

[0298] In some possible implementations, the line verification code module is specifically used to: generate a line verification code based on the data source information, feature value, the position information of the target data in the anti-tampering verification chain, the current timestamp, the line verification code key, and the historical registration position; wherein, the historical registration position is the position of the index information of the target data that existed before this registration in the index database, and if the target data is registered for the first time, the historical registration position is empty.

[0299] In some possible implementations, the CAPTCHA key is a user-unique private key, encrypted and stored in the user's private storage area; the CAPTCHA keys of different users are independent of each other.

[0300] In some possible implementations, the bidirectional anchored data anti-tampering device based on a multi-user sharing platform also includes a modification module, used for: when a modification of the target data is detected, re-acquiring the feature value of the modified target data; regenerating the row verification code corresponding to the modified target data based on the data source information of the modified target data, the modified feature value, the new location information, the current timestamp, the row verification code key, and the position of the index information of the target data before modification in the index database; generating a new verification chain code based on the current chain end code of the anti-tampering verification chain and the regenerated row verification code, and updating the chain end code; and saving the position of the index information of the target data before modification in the index database as the historical registration position of the index information of the modified target data.

[0301] In some possible implementations, the verification chaincode module is specifically used to: generate the verification chaincode corresponding to the target data based on the current chain end code, row verification code, and verification chain key; wherein, the verification chain key and the row verification code key are independent keys, the verification chain key is uniformly managed by the multi-user shared platform, and the row verification code key is held separately by each user.

[0302] In some possible implementations, the two-way anchored data anti-tampering device based on a multi-user sharing platform also includes a verification module, used for: obtaining the data to be verified and its corresponding data source information, and calculating the feature value of the data to be verified; obtaining the index information associated with the data source information based on the data source information, the index information including at least: the location information when the data to be verified was registered; obtaining the row verification code associated with the data source information from the private storage area of ​​the user corresponding to the data to be verified; recalculating the expected row verification code using the data source information, feature value, and location information; and triggering a tampering alarm if the expected row verification code is inconsistent with the obtained row verification code.

[0303] In some possible implementations, the two-way anchored data anti-tampering device based on a multi-user sharing platform also includes a verification module, used for: obtaining the data to be verified and its corresponding data source information and row verification code; obtaining, based on the data source information, index information associated with the data source information and verification chain code associated with the index information, wherein the index information includes at least: the location information when the data to be verified was registered; obtaining, based on the location information, the previous chain end code when the data to be verified was registered from the anti-tampering verification chain; recalculating the expected verification chain code based on the previous chain end code, row verification code, and preset verification chain key; and triggering a tampering alarm if the expected verification chain code is inconsistent with the already saved verification chain code.

[0304] In some possible implementations, the initialization module is used to: obtain the platform key and the platform initialization code, whereby the platform key is used to identify an instance of a multi-user shared platform and the platform initialization code is a randomly generated value; calculate the platform key, the initial timestamp, and the platform initialization code using a hash algorithm, and use the calculation result as a fixed initial code; and set the fixed initial code as the starting point of the chain-end code.

[0305] In some possible implementations, the multi-user sharing platform employs a role-based access control mechanism to manage each user's access rights to the verification codes in their private storage area, as well as each user's access rights to read the end-of-chain code of the tamper-proof verification chain.

[0306] In some possible implementations, the multi-user sharing platform is a SaaS platform. The SaaS platform supports asynchronous callback mechanisms and real-time monitoring, which is used to push notifications to users when data is registered or tampered with.

[0307] It is understood that the above-mentioned modules of the two-way anchored data anti-tampering device based on a multi-user sharing platform in this embodiment of the present disclosure have the ability to implement... Figure 1 The embodiments shown illustrate the functions of corresponding steps in the bidirectional anchored data anti-tampering method based on a multi-user sharing platform. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. These modules can be software and / or hardware, and each module can be implemented individually or integrated from multiple modules. For a detailed description of the functions of each module in the bidirectional anchored data anti-tampering device based on a multi-user sharing platform, please refer to [link to relevant documentation]. Figure 1 The corresponding description of the bidirectional anchored data anti-tampering method based on a multi-user sharing platform in the embodiments shown in the illustration will not be repeated here.

[0308] In the technical solution disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of user personal information comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and there is no violation of public order and good morals.

[0309] In the technical solution disclosed herein, the user's authorization or consent is obtained before acquiring or collecting the user's personal information.

[0310] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0311] The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the bidirectional anchored data anti-tampering method based on a multi-user shared platform as provided in the embodiments of this disclosure.

[0312] Compared to existing technologies, this electronic device extends the data registration of all users on the same chain, and subsequent user operations automatically strengthen the immutability of all previous user data. Any tampering with historical data will cause the chain to break. In other words, the bidirectional anchored data anti-tampering method based on a multi-user sharing platform in this disclosure automatically generates a locking effect with each data registration, requiring no additional operations, and realizing a proactive security mechanism of "registration equals locking, subsequent actions equal reinforcement". At the same time, the line verification code is privately stored by the user, protecting the privacy of user data. It itself contains sensitive information such as data characteristics, timestamps, and keys. Even if the index information database is compromised, attackers cannot forge the line verification code to bypass tampering detection. Furthermore, all operations in the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure involve only local hash calculations, requiring no distributed consensus or blockchain node synchronization, and can support high concurrency and real-time alarms, making it very suitable for cloud service scenarios such as SaaS.

[0313] The readable storage medium is a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in the embodiments of this disclosure.

[0314] Compared to existing technologies, this readable storage medium extends the data registration of all users on the same chain, and subsequent user operations automatically strengthen the immutability of all previous user data. Any tampering with historical data will cause the chain to break. In other words, the bidirectional anchored data anti-tampering method based on a multi-user sharing platform in this disclosure automatically generates a locking effect with each data registration, requiring no additional operations, and realizing a proactive security mechanism of "registration equals locking, subsequent operations equal reinforcement". At the same time, the line verification code is privately stored by the user, protecting the privacy of user data. It contains sensitive information such as data characteristics, timestamps, and keys. Even if the index information database is compromised, attackers cannot forge the line verification code to bypass tampering detection. Furthermore, all operations in the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure involve only local hash calculations, requiring no distributed consensus or blockchain node synchronization, and can support high concurrency and real-time alarms, making it very suitable for cloud service scenarios such as SaaS.

[0315] The computer program product includes a computer program that, when executed by a processor, implements the bidirectional anchored data anti-tampering method based on a multi-user shared platform as provided in the embodiments of this disclosure.

[0316] Compared to existing technologies, this computer program product extends the data registration of all users on the same chain, and subsequent user operations automatically strengthen the immutability of all previous user data. Any tampering with historical data will cause the chain to break. In other words, the bidirectional anchored data anti-tampering method based on a multi-user sharing platform in this disclosure automatically generates a locking effect with each data registration, requiring no additional operations, and realizing a proactive security mechanism of "registration equals locking, subsequent actions equal reinforcement". At the same time, the line verification code is privately stored by the user, protecting the privacy of user data. It itself contains sensitive information such as data characteristics, timestamps, and keys. Even if the index information database is compromised, attackers cannot forge line verification codes to bypass tampering detection. Furthermore, all operations in the bidirectional anchored data anti-tampering method based on a multi-user sharing platform provided in this disclosure involve only local hash calculations, requiring no distributed consensus or blockchain node synchronization, and can support high concurrency and real-time alarms, making it very suitable for cloud service scenarios such as SaaS.

[0317] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0318] like Figure 9 As shown, device 900 includes a computing unit 901, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 902 or a computer program loaded from storage unit 908 into random access memory (RAM) 903. RAM 903 may also store various programs and data required for the operation of device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0319] Multiple components in device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0320] The computing unit 901 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above, such as a two-way anchored data anti-tampering method based on a multi-user shared platform. For example, in some embodiments, the two-way anchored data anti-tampering method based on a multi-user shared platform can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by the computing unit 901, one or more steps of the two-way anchored data anti-tampering method based on a multi-user shared platform described above can be performed. Alternatively, in other embodiments, the computing unit 901 may be configured, by any other suitable means (e.g., by means of firmware), to perform a two-way anchored data anti-tampering method based on a multi-user shared platform.

[0321] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0322] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0323] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0324] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0325] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0326] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0327] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0328] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A two-way anchored data anti-tampering method based on a multi-user sharing platform, comprising: A platform-shared tamper-proof verification chain is initialized for the multi-user sharing platform. The tamper-proof verification chain has a fixed initial code and a dynamically updated chain end code. In response to any user submitting target data and its data source information on the multi-user sharing platform, the feature value of the target data is obtained; Based on the data source information, the feature value, and the location information of the target data registered in the anti-tampering verification chain, a row verification code corresponding to the target data is generated, and the row verification code is stored in the user's private storage area; Obtain the current end-of-chain code of the anti-tampering verification chain; based on the current end-of-chain code and the row verification code, generate the verification chain code corresponding to the target data; and add the verification chain code as the updated end-of-chain code to the end of the anti-tampering verification chain, so that the verification chain code becomes the new end-of-chain code of the anti-tampering verification chain. The verification chain code is associated with and saved with the index information of the target data.

2. The method according to claim 1, wherein, The step of generating a row verification code corresponding to the target data based on the data source information, the feature value, and the position information of the target data currently registered in the anti-tampering verification chain includes: The row verification code is generated based on the data source information, the feature value, the location information of the target data currently registered in the anti-tampering verification chain, the current timestamp, the row verification code key, and the historical registration location. The historical registration location refers to the position of the index information of the target data in the index database before this registration. If the target data is being registered for the first time, the historical registration location is empty.

3. The method according to claim 2, wherein, The line verification code key is a private key unique to the user and is encrypted and stored in the user's private storage area; the line verification code keys of different users are independent of each other.

4. The method according to claim 2, further comprising: When the target data is detected to have been modified, the feature values ​​of the modified target data are reacquired. Based on the data source information of the modified target data, the modified feature value, the new location information, the current timestamp, the line verification code key, and the position of the index information of the target data before modification in the index database, the line verification code corresponding to the modified target data is regenerated. Based on the current end-of-chain code of the tamper-proof verification chain and the regenerated row verification code, a new verification chain code is generated, and the end-of-chain code is updated. The position of the index information of the target data before modification in the index database is saved as the historical registration position of the index information of the target data after modification.

5. The method according to claim 2, wherein, The step of generating the verification chain code corresponding to the target data based on the current chain end code and the row verification code includes: Based on the current chain end code, the row verification code, and the verification chain key, generate the verification chain code corresponding to the target data; The verification chain key and the line verification code key are independent keys. The verification chain key is managed uniformly by the multi-user sharing platform, while the line verification code key is held separately by each user.

6. The method according to claim 1, further comprising: Obtain the data to be verified and its corresponding data source information, and calculate the feature value of the data to be verified; Based on the data source information, obtain the index information that is associated with and saved with the data source information, wherein the index information includes at least: the location information when the data to be verified was registered; Retrieve the line verification code associated with the data source information from the private storage area of ​​the user corresponding to the data to be verified; Using the data source information, the feature value, and the location information, recalculate the expected line verification code; If the expected verification code is inconsistent with the obtained verification code, a tampering alarm will be triggered.

7. The method according to claim 1, further comprising: Retrieve the data to be verified, its corresponding data source information, and the line verification code; Based on the data source information, obtain the index information and the verification chain code associated with the data source information. The index information includes at least the location information of the data to be verified when it was registered. Based on the location information, obtain the last chain code of the previous chain when the data to be verified was registered from the anti-tampering verification chain; Based on the previous chain end code, the row verification code, and the preset verification chain key, recalculate the expected verification chain code; If the expected verification chaincode is inconsistent with the saved verification chaincode, a tampering alarm will be triggered.

8. The method according to claim 1, wherein, The process of initializing a platform-shared, tamper-proof verification chain for a multi-user shared platform includes: Obtain the platform key and platform initialization code, wherein the platform key is used to identify an instance of the multi-user shared platform, and the platform initialization code is a randomly generated value; The platform key, initial timestamp, and platform initialization code are calculated using a hash algorithm, and the calculation result is used as the fixed initial code. Set the fixed initial code as the starting point of the chain end code.

9. The method according to claim 1, wherein, The multi-user sharing platform adopts a role-based access control mechanism to manage each user's access rights to the verification code in their private storage area, as well as each user's access rights to read the end-of-chain code of the tamper-proof verification chain.

10. The method according to claim 1, wherein, The multi-user sharing platform is a SaaS platform that supports asynchronous callback mechanisms and real-time monitoring, and is used to push notifications to users when data is registered or tampered with.

11. A two-way anchored data anti-tampering device based on a multi-user sharing platform, comprising: An initialization module is used to initialize a platform-shared anti-tamper verification chain for a multi-user sharing platform. The anti-tamper verification chain has a fixed initial code and a dynamically updated chain end code. The feature value calculation module is used to obtain the feature value of the target data in response to any user submitting target data and its data source information on the multi-user sharing platform. The line verification code module is used to generate a line verification code corresponding to the target data based on the data source information, the feature value, and the location information of the target data being registered in the anti-tampering verification chain, and to save the line verification code in the user's private storage area; The verification chain code module is used to obtain the current chain end code of the anti-tampering verification chain, generate the verification chain code corresponding to the target data based on the current chain end code and the row verification code, and add the verification chain code as the updated chain end code to the end of the anti-tampering verification chain, so that the verification chain code becomes the new chain end code of the anti-tampering verification chain. The storage module is used to associate and save the verification chain code with the index information of the target data.

12. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-10.

13. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-10.

14. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-10.

Images