Privacy preserving cross-datacenter identity anonymous authentication system

Abstract

The application relates to the technical field of privacy protection, in particular to a cross-data-center identity anonymous authentication system based on privacy protection, which comprises an identity registration module, an access request module and an anonymous authentication module. The identity registration module is used for generating an anonymous DID (Decentralized Identifier) and assigning an initial trusted value. The access request module is used for calculating an access commitment value when a cross-data-center access request is initiated by a current node. The anonymous authentication module comprises the following steps: performing double verification; after the verification is passed, determining an effective trusted value of the current node, calculating a risk value of the current access operation, and matching and executing a differentiated authentication and storage strategy for access control according to the risk value; and the authorization and update module is used for judging the authorization of the current access operation according to the effective trusted value, judging the compliance of the current access operation, and executing an update strategy of reward and punishment settlement of the trusted value. The application greatly improves the overall security defense capability in the cross-data-center multi-node collaborative environment.

Description

Technical Field

[0001] This application relates to the field of privacy protection technology, specifically to a privacy-protected cross-data center anonymous identity authentication system. Background Technology

[0002] With the large-scale development of the digital industry, multi-regional, distributed data centers have become the mainstream deployment form for government and enterprise, Internet platforms and various business systems. Under this architecture, the demand for business collaboration, data interaction and user identity interoperability across data centers continues to surge.

[0003] Existing cross-datacenter identity authentication solutions mainly consist of centralized IAM solutions and traditional anonymous authentication solutions. IAM solutions, where a central server handles identity storage, authentication, and authorization, suffer from a core problem: identity data is stored in plaintext, posing a high risk of leakage. Cross-domain authentication requires third-party endorsement, creating a single point of failure. Static permissions are unsuitable for dynamic access scenarios such as temporary maintenance and cross-domain data synchronization. Furthermore, user access behavior can be linked to the real identity throughout the process, resulting in insufficient privacy protection. Traditional anonymous authentication solutions achieve identity concealment through technologies like blind signatures and zero-knowledge proofs, but their core problem is the inability to achieve fine-grained permission control, making them unsuitable for access permissions of different security levels. Additionally, unauthorized behavior is difficult to trace after anonymization, failing to meet compliance auditing requirements. This results in an inability to balance absolute identity privacy protection with dynamic, fine-grained permission control in existing identity authentication solutions. This is particularly problematic in complex scenarios involving multi-node collaboration across data centers and business workflow transitions, easily leading to serious security risks such as unauthorized access, trust abuse, and data leakage. Summary of the Invention

[0004] To address the aforementioned technical challenges, a privacy-preserving cross-datacenter anonymous authentication system is provided.

[0005] The solution to the technical problem in this application is to provide a privacy-preserving cross-datacenter anonymous authentication system, the system comprising: The identity registration module is used to receive the public key, qualification certificate hash and node type label submitted by the node, generate anonymous DID identifier and assign an initial trusted value, and bind them together to generate an identity mapping table for on-chain storage. The access request module is used to calculate the access commitment value and submit it to the smart contract to trigger the authentication process when the current node initiates a cross-data center access request, based on the specific operation type label of this access, the security level of the accessed data and the access request timestamp. The anonymous authentication module is used to perform anonymous authentication, specifically: (1) The smart contract generates a random challenge value based on the access commitment value and returns it to the node. The node uses its own private key to sign the random challenge value to obtain the signature information. The smart contract performs double verification based on the signature information, the specific operation type label of this access, the access data security level, and the access request timestamp. (2) After verification, based on the fact that this access operation belongs to the cross-domain relay scenario, determine the effective trust value of the current node, and calculate the risk value of this access operation in combination with the access data security level. Based on this, match and execute differentiated authentication and evidence storage strategies to control access. The authorization and update module is used to determine the authorization of this access operation based on the valid trust value. After the node obtains authorization and completes the access operation, it generates an operation result hash and submits it to the smart contract. The smart contract judges the compliance of this access operation based on this hash, executes the reward and punishment settlement update strategy on the trust value, and synchronizes it to the identity mapping table to overwrite the original record.

[0006] Preferably, the allocation of the initial trust value includes: based on the node type label, pre-setting a qualification score for the node, and multiplying it by the preset benchmark trust value as the initial trust value of the node.

[0007] Preferred access commitment value The calculation formula is In the formula, A label for the specific operation type performed on the node; For the access request timestamp, To access data security levels, A random number generated locally on the node; This represents a hash function.

[0008] Preferably, the process of obtaining the random challenge value is as follows: the smart contract performs a bitwise XOR operation between the access commitment value and the current block hash to generate the random challenge value.

[0009] Preferably, the dual verification process is as follows: The public key bound to the anonymous DID is invoked, and this public key is used to verify whether the signature information corresponds to the issued random challenge value, thus confirming that the current node holds a legitimate private key and completing the signature validity verification; the smart contract returns the specific operation type tag. Access Data Security Level Access request timestamp and random numbers The hash algorithm is used to recalculate the value and verify whether the result is consistent with the received access commitment value. This confirms that the current node's operational intent has not been tampered with, thus completing the commitment consistency verification.

[0010] Preferably, determining the valid trust value of the current node includes: after the dual verification is passed, the smart contract determines whether the current node's access operation belongs to a cross-domain relay scenario assigned by other nodes by parsing the task tracking serial number carried in the access request. If the current access operation does not involve a cross-domain relay scenario, the trust value of the node itself is directly defined as the valid trust value of the current access operation. Otherwise, the smart contract traces back to the previous hop node that assigned the task based on the task tracking serial number as the predecessor node, retrieves the trust value of the predecessor node, performs a positive mapping on it, and uses it as a trust transmission factor. The trust value of the current node is then weighted and converted using the trust transmission factor as the weight, and used as the valid trust value.

[0011] Preferably, the step of calculating the risk value of this access operation and matching and executing differentiated authentication and evidence storage policies accordingly for access control includes: By performing a weight iteration strategy on all access operations within the historical period, the currently effective security level weight and trust weight are extracted. The effective trust value of the current node is negatively mapped. Based on the security level weight and trust weight, the result of the negative mapping is weighted and summed with the security level of the normalized access data of the node, which is used as the risk value of this access operation. The smart contract categorizes this access operation into different risk levels based on the risk value and executes differentiated authentication and evidence storage strategies accordingly, specifically: If the risk value is less than the preset first threshold, it is determined to be a low-risk operation. At this time, the operation log will be uploaded to the blockchain in batches at a preset long period for evidence storage. If the risk value is greater than or equal to the preset first threshold and less than the preset second threshold, it is determined to be a medium-risk operation. At this time, the operation log is written to the local buffer, the smart contract performs integrity verification on the cached operation log, and uploads the operation log to the blockchain in batches at a preset short period for evidence storage. If the risk value is greater than or equal to the preset second threshold, it is judged as a high-risk operation. In this case, in addition to performing dual verification, an enhanced authentication process is performed. After the verification is passed, the operation log is triggered to be uploaded to the blockchain for evidence storage in real time.

[0012] Preferably, the weight iteration strategy is as follows: Within a preset statistical period, extract all unblocked illegal operations from all access operations within that period, along with the actual authentication time for each access operation, and calculate the error loss. The calculation formula is as follows: In the formula, This indicates the number of all access operations within the statistical period. Indicates the first The actual authentication time for each access operation. This indicates the preset tolerance time threshold. For the first The indicator for the next access operation, where if the first... This access operation is considered an unblocked violation; the indicator is set to 1, otherwise it is set to 0. This represents the function that takes the maximum value. Two weight parameters are preset, denoted as the initial security level weight and the initial trust weight, respectively, and the sum of the two weight parameters is 1. If the error loss is less than or equal to the preset value, the security level weight and the trust weight remain unchanged; otherwise, the weight callback mechanism is triggered, and the security level weight is reduced by the preset step size, while the trust weight is increased by the same preset step size, so as to ensure that the sum of the two is constant at 1.

[0013] Preferably, the authorization determination for this access operation based on the valid trust value includes: if the valid trust value of the current node is less than the preset minimum trust threshold, then the access operation is rejected and the unauthorized attempt is recorded; otherwise, the access operation is allowed, and a trust value pre-freezing operation is immediately performed, deducting the trust consumption amount of this operation from the valid trust value of the current node in advance as a temporary trust value; wherein, the trust consumption amount is the preset minimum trust threshold corresponding to this operation.

[0014] Preferably, the step of determining the compliance of this access operation and updating the reward and penalty settlement strategy for the trust value includes: The smart contract determines the compliance of this access operation based on preset judgment conditions. If all judgment conditions are met, the access operation is compliant, and the first update strategy is executed to update the temporary trust value of the current node. Otherwise, if the access operation is non-compliant, the second update strategy is executed to update the temporary trust value of the current node. The updated temporary trust value is used as the new trust value of the node and synchronized to the on-chain identity mapping table to overwrite the original record. The preset judgment conditions are: the received operation result hash is consistent with the hash calculated by the access gateway independently of the network layer operation result through bypass interception; and the submission of the operation result hash does not time out. The first update strategy is: the updated temporary trusted value. The calculation formula is: In the formula, This is the temporary trusted value before the update. To preset the reward coefficient, For reliable consumption amount, The preset maximum confidence value, This represents a function that takes the minimum value. The second update strategy is: the updated temporary trust value. The calculation formula is: In the formula, To preset the penalty coefficient, The preset minimum confidence value, This represents the function that takes the maximum value.

[0015] This application has at least the following beneficial effects: This application utilizes anonymous DID identifiers and qualification certificate hashes to replace plaintext identities, preventing privacy leaks at the source. It assigns initial trust values ​​based on node type and stores them on the blockchain, establishing an immutable initial trust benchmark. Nodes calculate access commitment values ​​locally; the access request timestamps and local random numbers involved in the calculation ensure the timeliness and unpredictability of the commitment value, effectively preventing replay attacks and duplicate commitments under the same operation. Furthermore, the access commitment value integrates the specific operation intent, data security level, and timestamp, forcing nodes to commit before revealing their commitments in subsequent authentication processes. This locks the node's intent before the operation occurs, and once the commitment is submitted, the operation intent cannot be tampered with, cryptographically guaranteeing the authenticity of the operation intent and effectively preventing access requests from being tampered with by a man-in-the-middle or launching replay attacks. By issuing random challenges and verifying private key signatures, the legitimacy of the node's identity and operation intent are simultaneously verified without exposing the true identity. Figure 1 To ensure consistency and achieve high-strength anonymous verification, the system calculates effective trust values ​​for cross-domain relay scenarios, forcing the credit of preceding nodes to be passed down. This ensures that the operational quality of preceding nodes directly constrains the permission boundaries of subsequent stages, forming a chain-like constraint mechanism of "trust propagation along the link and risk attenuation along the link." This prevents unauthorized relays and integrates trust values ​​with data security levels to quantify risks, implementing differentiated management and balancing the security defense of high-risk operations with the efficiency of low-risk operations. Authorization for this access operation is determined based on the effective trust value, directly linking the node's dynamic credit to specific access thresholds. This achieves strict, fine-grained pre-access control, avoiding the unauthorized access risks of traditional static authorization models. Furthermore, after obtaining authorization and completing the access operation, the node generates an operation result hash and submits it to the smart contract. The smart contract then uses this hash to determine the current access status. The compliance of access operations is ensured by conducting objective and consistent audits of the actual business execution results after the fact. This enforces that the actual behavior of nodes must be completely consistent with their prior commitments, effectively preventing security vulnerabilities caused by fraudulent authorization and subsequent execution of other illegal operations. Furthermore, a reward and punishment settlement update strategy is implemented for the trust value, and it is synchronized to the identity mapping table to overwrite the original records. This allows the node's operation behavior to directly drive the rise and fall of its own credit, constructing a dynamic zero-trust closed-loop mechanism where violations result in demotion and blocking, while compliance results in credit enhancement and incentives. This ensures that the trust status of all nodes in the network is always accurately matched with the actual security environment. It can effectively break the control deadlock of traditional static authentication in cross-domain scenarios and completely solve the fundamental problem of difficulty in restraining and tracing violations under anonymous authentication mechanisms, thereby significantly improving the overall security defense capabilities in a multi-node collaborative environment across data centers. Attached Figure Description

[0016] The privacy-preserving cross-data center anonymous authentication system of this application will be further described in detail below with reference to the accompanying drawings.

[0017] Figure 1 A block diagram of a privacy-preserving cross-data center anonymous authentication system provided in one embodiment of this application; Figure 2 This is a block diagram illustrating the implementation of an anonymous authentication module according to one embodiment of this application. Detailed Implementation

[0018] The following detailed description, in conjunction with the accompanying drawings and embodiments, provides a further explanation of the privacy-preserving cross-data center anonymous authentication system proposed in this application.

[0019] Please see Figure 1 The diagram illustrates a privacy-preserving cross-data center anonymous authentication system according to an embodiment of this application. The system includes: an identity registration module, an access request module, an anonymous authentication module, and an authorization and update module.

[0020] The identity registration module is used to receive the public key, qualification certificate hash and node type label submitted by the node, generate anonymous DID identifier and assign an initial trusted value, and bind them together to generate an identity mapping table for on-chain storage. The access request module is used to calculate the access commitment value and submit it to the smart contract to trigger the authentication process when the current node initiates a cross-data center access request, based on the specific operation type label of this access, the security level of the accessed data and the access request timestamp. The anonymous authentication module is used to perform anonymous authentication. The authorization and update module is used to determine the authorization of this access operation based on the valid trust value. After the node obtains authorization and completes the access operation, it generates an operation result hash and submits it to the smart contract. The smart contract judges the compliance of this access operation based on this hash, executes the reward and punishment settlement update strategy on the trust value, and synchronizes it to the identity mapping table to overwrite the original record.

[0021] The cross-datacenter anonymous authentication system is jointly maintained by a datacenter consortium composed of multiple datacenters. The authentication servers and attribute authorities of each datacenter in the consortium form a consortium blockchain, providing blockchain proxy services to other users within the system. Each datacenter has multiple authentication servers and attribute authorities joining the consortium blockchain to avoid losses due to the downtime of a single server. This system does not rely on any third-party authoritative institution, achieving true decentralization while improving cross-datacenter authentication efficiency.

[0022] In this embodiment, the actual operating entity (user) or business system first completes internal identity registration and obtains physical qualification certificates in its local data center. The network device entities that represent the entity to perform cross-domain access are collectively referred to as nodes. The network device entities refer to specific physical servers, virtual machines or business system instances that participate in data synchronization, operation and maintenance or business access in the cross-data center network. Each node accesses the consortium blockchain through a deployed proxy gateway or light client.

[0023] The identity registration module is as follows: During the node registration phase, the node generates a public-private key pair for the SM2 algorithm locally, extracts the local qualification certificate to generate a qualification certificate hash, and submits the node type label, qualification certificate hash, and public key to the registration smart contract of the consortium blockchain without submitting any plaintext identity information; the node type label includes operation and maintenance nodes, data synchronization nodes, regulatory nodes, and third-party service providers. The registered smart contract calls the qualification Merkle root pre-stored by the regulatory node to verify the validity of the qualification proof hash. After the verification is successful, a globally unique anonymous DID identifier is generated for the node as an on-chain identity credential. The anonymous DID identifier is then bound to the public key and qualification proof hash to generate an identity mapping table for on-chain storage, thereby realizing node identity privacy protection and subsequent regulatory traceability. When the registration smart contract receives the qualification certificate hash submitted by the node, it calls the complete qualification Merkle tree pre-stored by the regulatory node to search for the existence of the qualification certificate hash in all leaf nodes of the Merkle tree. The search operation is specifically as follows: performing hash index matching on the set of Merkle tree leaf nodes; if there is a leaf node that is completely consistent with the qualification certificate hash, the verification is successful, indicating that the qualification document corresponding to the qualification certificate has been pre-registered with the regulatory node and has not been revoked; if it does not exist, the verification fails, and the registration smart contract rejects the registration request. It should be noted that the SM2 algorithm is a well-known technology and will not be described in detail here.

[0024] At the same time, an initial trust value is assigned to the node. Specifically, based on the node type label, a qualification score is preset for the node, and the product of the score and the preset baseline trust value is used as the initial trust value of the node.

[0025] Specifically, since the node type labels include operation and maintenance nodes, data synchronization nodes, regulatory nodes, and third-party service providers, the qualification score for operation and maintenance nodes is set to 0.9, the qualification score for data synchronization nodes is set to 0.8, the qualification score for regulatory nodes is set to 1, and the qualification score for third-party service providers is set to 0.7; the preset benchmark confidence value is set to 1000. As other implementation methods, implementers can set it according to the actual situation.

[0026] The access request module specifically comprises: During the cross-datacenter access phase, when a node initiates a cross-datacenter access request, this request will inevitably pass through the datacenter's access gateway at the physical layer. The access gateway extracts the specific operation type label, access data security level, and access request timestamp by parsing the header of the access request, but does not parse the plaintext data content in the message body. The node calculates the access commitment value based on the specific operation type label, access data security level, and access request timestamp. Its calculation formula is In the formula, A label for the specific operation type performed on the node; For the access request timestamp, To access data security levels, A random number generated locally on the node; Represents a hash function; The hash function used is the SM3 hash function, with a 256-bit random number, to prevent replay attacks and duplicate commitments under the same operation. Secondly, the access commitment value is a fixed-length 256-bit SM3 hash value. The SM3 hash function is a well-known technology and will not be described in detail here.

[0027] It should be noted that the specific operation type label refers to the specific business operation category executed when a node initiates cross-datacenter access. The specific operation type label includes 0, 1, 2, 3, and 4, where 0 represents a read operation, 1 represents a write operation, 2 represents an operation and maintenance operation, 3 represents a data synchronization operation, and 4 represents a regulatory inspection operation, which are used to declare the purpose of this operation to the smart contract. There are 5 levels of data security, where 1 represents public data, 2 represents internal data, 3 represents sensitive data, 4 represents core data, and 5 represents regulatory data.

[0028] Subsequently, the access gateway uses a pre-negotiated shared key to encrypt and encapsulate the aforementioned behavioral interaction data, generate standardized ciphertext messages, and upload them to the blockchain. At the same time, the node submits its anonymous DID identifier and access commitment value to the smart contract to trigger the authentication process. Cross-data center access involves data interaction among multiple entities, across multiple scenarios, and at multiple stages. Without an identity authentication mechanism that balances privacy and access rights, issues such as identity leaks, unauthorized access, and untraceable violations can easily arise, leading to security risks such as data breaches and business interruptions. Consortium blockchains, with their decentralized, immutable, and automatically executed smart contracts, can build a trusted anonymous identity system across multiple nodes in multiple data centers without third-party endorsement, achieving a balance between identity anonymity, dynamic access control, and auditable behavior.

[0029] By not storing plaintext identity information of nodes, a dynamic trusted value is assigned to each anonymous DID identifier as the basis for access control. Before each access operation, the legitimacy of the node's identity and the authenticity of the operation intent are verified through a random challenge mechanism. At the same time, access control is achieved through the dynamic addition, reduction and transmission of trusted values.

[0030] An anonymous authentication module is used to perform anonymous authentication. The implementation block diagram of the anonymous authentication module provided in this application is as follows: Figure 2 As shown, it specifically includes: Step 1: The smart contract generates a random challenge value based on the access commitment value and returns it to the node. The node uses its own private key to sign the random challenge value to obtain the signature information. The smart contract performs double verification based on the signature information, the specific operation type label of this access, the access data security level, and the access request timestamp. Step 2: After successful verification, based on the fact that this access operation belongs to a cross-domain relay scenario, determine the effective trust value of the current node, and calculate the risk value of this access operation in combination with the security level of the access data. Based on this, match and execute differentiated authentication and evidence storage policies for access control.

[0031] In step 1, the specific process is as follows: Furthermore, when a node wishes to initiate a cross-datacenter access operation, it must undergo a mandatory authentication process without submitting plaintext identity information. Specifically: Step 101: After triggering the authentication process, the smart contract performs a bitwise XOR operation between the access commitment value and the current block hash to generate a random challenge value, and returns it to the node; the current node signs the random challenge value using its own private key to obtain the signature information; and then sends the signature information and the random number... Specific operation type tags Access Data Security Level and access request timestamp Send it back to the smart contract together; The random challenge value is composed of the first 128 bits of the current block hash and the commitment value. The first 128 bits are generated by XOR operation. The XOR operation and the private key signing process are well-known technologies and will not be described in detail here. The current block hash refers to the hash digest value of the latest block generated on the consortium blockchain and confirmed by consensus at the moment when the node initiates the authentication request.

[0032] Furthermore, the smart contract performs dual verification: first, it verifies the validity of the signature information using the public key bound to the node; second, it returns the... , , , Substitute the values ​​into the hash function and recalculate, checking if the result matches the temporarily stored access commitment value. If either fails, the access request is rejected and a violation is recorded; if both succeed, the identity is considered legitimate and the intent genuine.

[0033] Step 102: After receiving the returned data, the smart contract performs dual verification, specifically: it calls the public key bound to the anonymous DID identifier and uses this public key to verify whether the signature information corresponds to the issued random challenge value, thereby confirming that the current node holds a legitimate private key and completing the signature validity verification; the smart contract then sends the returned specific operation type label... Access Data Security Level Access request timestamp and random numbers Substitute the result into the hash algorithm for recalculation, and verify whether the result is consistent with the received access commitment value to confirm that the current node's operation intention has not been tampered with, thus completing the commitment consistency verification. Specifically, the corresponding SM2 public key is retrieved from the on-chain identity mapping table based on the anonymous DID identifier; private key signing and public key verification are well-known technologies and will not be described in detail here.

[0034] It should be noted that if both the signature validity verification and the commitment consistency verification pass, the node's identity is deemed legitimate and its operational intent is genuine; if either fails, the access request is directly rejected and a violation is recorded.

[0035] The above process transforms each cross-datacenter access operation into an independent and unpredictable authentication process, forcing nodes to prove that they hold a legitimate private key before the operation is executed and to bind it to the pre-submitted operation commitment. This can prevent the risk of static tokens being stolen and session hijacking, while keeping the node's true identity hidden throughout the process, thus meeting privacy protection requirements.

[0036] Secondly, for situations where multiple data center nodes may collaborate to complete a comprehensive instruction in actual business operations, such as cross-domain data synchronization chains, specifically, when an access operation is a pre-processing part of a comprehensive instruction and requires subsequent relay processing by nodes in other data centers, the smart contract will initiate a cross-domain relay transmission procedure. Therefore, it is crucial to determine whether the access operation involves a multi-node relay access scenario across data centers. For example, a node in data center A synchronizes core data to data center B, and data center B then synchronizes it to data center C. If multi-node relay access is involved, the trustworthiness of the preceding node directly affects the access risk of subsequent nodes. Therefore, the smart contract performs a trustworthiness transmission calculation on subsequent nodes based on the trustworthiness value of the preceding node, forming a trust mechanism of mutual constraints in the chain. When a node needs to execute a relay access operation assigned by the preceding node, step 2 is implemented. The specific execution process is as follows: Step 201: After the dual verification is passed, the smart contract determines whether the current node's access operation belongs to a cross-domain relay scenario assigned by other nodes by parsing the task tracking serial number carried in the access request. If the current access operation does not involve a cross-domain relay scenario, the trust value of the node itself is directly defined as the valid trust value of the current access operation. Otherwise, the smart contract traces back to the previous hop node that assigned the task based on the task tracking serial number as the predecessor node, retrieves the trust value of the predecessor node, performs a positive mapping on it, and uses it as a trust transmission factor. The trust value of the current node is then weighted and converted using the trust transmission factor as the weight, and used as the valid trust value. Specifically, the positive mapping process is as follows: the ratio of the credibility value of the preceding node to the preset maximum credibility value is used as the credibility transmission factor, where the preset maximum credibility value is set to 2000. In other implementation methods, the implementer can set this value according to the actual situation. Secondly, the weighted conversion process is as follows: In the formula, This represents the valid trust value of the current node. This represents the trust value of the current node. This represents the preset system reference confidence value, which is fixed at 500. This is a reliable transmission factor.

[0037] It should be noted that the trust transmission factor quantifies the reliability of the operation completed by the preceding node. The higher the value, the more standardized and trustworthy the behavior of the preceding node. If the trust value of the preceding node is low due to illegal operation, the trust transmission factor will approach 0. The effective trust value of the current node will be reduced to close to the system reference trust value. Even if the trust value of the current node itself is high, it cannot use the trust value to perform high-privilege operations, forcing subsequent nodes to supervise the operation of the preceding node and preventing relay-style illegal access.

[0038] Furthermore, different access scenarios have different risk levels. In order to better adapt to access scenarios with different risk levels and optimize authentication efficiency, access operations are classified by calculating risk values, thereby optimizing the access process.

[0039] Step 202: By performing a weight iteration strategy on all access operations in the historical period, the currently effective security level weight and trust weight are extracted, and the effective trust value of the current node is negatively mapped. Based on the security level weight and trust weight, the result of the negative mapping is weighted and summed with the security level of the normalized access data of the node, which is used as the risk value of this access operation. The negative mapping process is as follows: calculate the ratio of the effective trust value of the current node to the preset maximum trust value, and take the difference between the value 1 and the ratio as the result of the negative mapping; the method for obtaining the normalized access data security level is as follows: since there are 5 access data security levels, the ratio of the access data security level of the current node to the maximum access data security level is taken as the normalized access data security level.

[0040] Step 203: The smart contract classifies this access operation into different risk levels based on the risk value and executes differentiated authentication and evidence storage strategies accordingly, specifically: If the risk value is less than the preset first threshold, it is determined to be a low-risk operation. At this time, the operation log will be uploaded to the blockchain in batches at a preset long period for evidence storage. If the risk value is greater than or equal to the preset first threshold and less than the preset second threshold, it is determined to be a medium-risk operation. At this time, the operation log is written to the local buffer, the smart contract performs integrity verification on the cached operation log, and uploads the operation log to the blockchain in batches at a preset short period for evidence storage. If the risk value is greater than or equal to the preset second threshold, it is judged as a high-risk operation. In this case, in addition to performing double verification, an enhanced authentication process is performed, that is, the smart contract randomly selects multiple regulatory nodes to perform secondary signature verification, and after the verification is passed, the operation log is triggered to be uploaded to the chain for evidence storage in real time. It should be noted that if any tampering is detected during the integrity verification process, the access operation will be immediately upgraded to a high-risk operation, triggering the real-time evidence storage and enhanced verification process. Secondly, the first preset threshold is set to 0.3, the second preset threshold is set to 0.7, the preset long period is 1 hour, and the preset short period is 10 minutes. As other implementation methods, implementers can set them according to the actual situation. Secondly, two regulatory nodes are randomly selected based on a pseudo-random algorithm for secondary signature verification. The current node does not need to provide identity information to the regulatory node, but only needs to submit signature information, operation type label, and access commitment value. After receiving the above data, the regulatory node first calls the locally deployed threat intelligence database to perform risk feature comparison. If no abnormal risk features are matched, the regulatory node generates a signature using its own private key and returns it. Only after the smart contract verifies the validity of the signature is the operation permission granted.

[0041] It should be noted that the higher the risk value, the higher the potential threat to system security this access operation poses. This reflects that the operation not only touches highly sensitive core data resources, but also that the node initiating the operation has extremely low credibility and a very high probability of unauthorized access and data tampering. Therefore, it is necessary to strictly block and control the operation through a high-risk classification strategy and multiple approval processes.

[0042] The weight iteration strategy is as follows: Within a preset statistical period, extract all unblocked illegal operations from all access operations within that period, along with the actual authentication time for each access operation, and calculate the error loss. The calculation formula is as follows: In the formula, This indicates the number of all access operations within the statistical period. Indicates the first The actual authentication time for each access operation. This indicates the preset tolerance time threshold. For the first The indicator for the next access operation, where if the first... This access operation is considered an unblocked violation; the indicator is set to 1, otherwise it is set to 0. This represents the function that takes the maximum value. Two weight parameters are preset, denoted as the initial security level weight and the initial trust weight, respectively. The sum of the two weight parameters is 1. If the error loss is less than or equal to the preset value, the security level weight and the trust weight remain unchanged. Otherwise, the weight callback mechanism is triggered, and the security level weight is reduced by the preset step size, while the trust weight is increased by the same preset step size to ensure that the sum of the two is constant at 1. In this embodiment, the preset statistical period is 7 days. The system counts all access operations within a period every 7 days to calculate error loss. The preset tolerance time threshold is set to 0.05. As another implementation method, the implementer can set it according to the actual situation. The initial security level weight and the initial trust weight are both 0.5, the preset value is set to 0.3, and the preset step size is set to 0.05. As another implementation method, the implementer can set it according to the actual situation. Therefore, when the error loss is greater than the preset value, the security level weight is reduced by 0.05 and the trust weight is increased by 0.05. It should be noted that after each execution of the weight callback mechanism, extreme value boundary checks are performed on the two weights: if the security level weight is less than 0 after decay, it is truncated and assigned a value of 0, and the trust weight is assigned a value of 1; if the trust weight is greater than 1 after increase, it is truncated and assigned a value of 1, and the security level weight is assigned a value of 0, so that the value range of the security level weight and the trust weight is protected within the interval [0, 1].

[0043] It should be noted that, This indicates a deviation in authentication time. When the actual authentication time of a node exceeds the preset tolerance threshold, this item takes a positive value, indicating that the authentication strength allocated under the current risk classification strategy is too high. This causes access requests from normal nodes to wait too long before being authorized, resulting in system efficiency deviating from expectations. It reflects that the risk level classification is too conservative, and a large number of low-to-medium risk operations are over-authenticated. When the access operation is an unblocked violation, this also applies. A value of 1 indicates that the weighting configuration in the current risk value calculation caused high-risk operations that should have been identified to be incorrectly classified as low-risk or medium-risk, thus allowing them to proceed with lower authentication strength, resulting in missed detections; if A value that is frequently 1 indicates that the weight configuration is too lenient; the greater the error loss, the greater the deviation between the current security level weight and trust weight configuration and the actual operating environment. The system is out of balance between over-authentication (i.e., low-risk operations are over-authenticated, resulting in excessive time consumption) and under-authentication (i.e., high-risk operations are underestimated, resulting in missed detection). It cannot achieve the optimal balance between security and efficiency, and the accuracy of risk assessment can no longer meet the actual needs of the current cross-data center access scenario.

[0044] Secondly, when the error loss is less than or equal to 0.3, it indicates that the sum of the average authentication time deviation per operation and the occurrence rate of unblocked violations within the statistical period is within an acceptable range, and the current weight configuration can cover most operational scenarios. The security level weight and trust weight do not need adjustment. Conversely, it indicates that the current weight configuration has significantly deviated from the actual operating environment. By triggering a weight callback mechanism: the security level weight is reduced by 0.05 according to a preset step size, while the trust weight is increased by 0.05, causing the risk value calculation to shift towards "more reliance on trust value judgment and less reliance on security level sensitivity." The design basis of this callback mechanism is: when a missed judgment occurs ( This usually means that the node's trust value is already low, but the system has reduced its vigilance towards its behavior due to the excessively high security level weight. Therefore, it is necessary to increase the trust weight to strengthen the ability to identify risks in node behavior.

[0045] It should be noted that when the error loss continues to rise over two consecutive statistical periods, or when violations of high-risk operations result in missed detections, an early warning will be triggered, notifying operations and maintenance personnel to investigate the authentication link and node trust value status, and promptly repair potential risks.

[0046] Furthermore, the authorization and update module's specific process is as follows: If the current node's valid trust value is less than the preset minimum trust threshold, the access operation will be rejected and the unauthorized access attempt will be recorded. Otherwise, the access operation will be allowed, and a trust value pre-freeze operation will be performed immediately. The trust consumption amount for this operation will be deducted from the current node's valid trust value in advance as a temporary trust value. The trust consumption amount is the preset minimum trust threshold corresponding to this operation. It should be noted that the trusted consumption amount required for this operation is immediately frozen to prevent nodes from taking advantage of the time difference to access the system concurrently without authorization.

[0047] Secondly, the preset minimum trust threshold is pre-set based on the specific operation type and the data security level accessed. The setting principle is: the higher the data security level requested by the node and the greater the specific operation privileges executed, the higher the corresponding minimum trust threshold value; the calculation formula is: ; Pre-defined basic thresholds for labels of different specific operation types. To access data security levels, This is the security level step size, with a value of 125. When the specific operation type label is 0, it indicates a read operation. The value is 100; when the specific operation type label is 1, indicating a write operation, then... The value is 300; when the specific operation type label is 2, it indicates an operation and maintenance operation. The value is 500; when the specific operation type label is 3, it indicates a data synchronization operation. The value is 400; when the specific operation type label is 4, it indicates a regulatory inspection operation, which falls under privileged auditing and directly sets the minimum credibility threshold. for As another implementation method, the implementer can set it according to the actual situation.

[0048] After obtaining authorization from the smart contract and completing the cross-datacenter access operation, the current node generates an operation result hash and submits it to the smart contract. The smart contract performs a compliance judgment on this access operation based on preset judgment conditions. If all judgment conditions are met, the access operation is a compliant operation, and the first update strategy is executed to update the temporary trust value of the current node. Otherwise, if the access operation is non-compliant, the second update strategy is executed to update the temporary trust value of the current node. The updated temporary trust value is used as the new trust value of the node and synchronized to the on-chain identity mapping table to overwrite the original record. The preset judgment conditions are as follows: (1) The hash of the received operation result is consistent with the hash of the network layer operation result calculated independently by the access gateway through bypass interception; (2) The submission of the hash of the completed operation did not time out; Specifically, the node takes the target file data stream or the execution status message generated upon completion of the operation as input, calculates the digest ciphertext using the SM3 hash function locally, uses it as the hash of the operation result, and actively submits it to the smart contract within a preset time window. In this embodiment, the time window is set to 300 seconds from the time of operation authorization.

[0049] The first update strategy is: the updated temporary trusted value. The calculation formula is: In the formula, This is the temporary trusted value before the update. To preset the reward coefficient, For reliable consumption amount, The preset maximum confidence value; The second update strategy is: the updated temporary trust value. The calculation formula is: In the formula, This is the temporary trusted value before the update. To preset the penalty coefficient, For reliable consumption amount, This is the preset minimum confidence value; The preset reward coefficient is set to 1.1, the preset penalty coefficient is set to 1.5, the preset maximum confidence value is set to 2000, and the preset minimum confidence value is set to 0. As other implementation methods, implementers can set these values ​​according to their actual circumstances.

[0050] It should be noted that if it falls under compliant procedures, then it will be done through... This allows nodes to not only fully recover the pre-frozen trusted consumption amount but also receive additional trusted value increment rewards, thereby incentivizing compliant access behavior; conversely, if violations occur, [the system will]... This causes the system to not only confiscate the pre-frozen trusted consumption amount, but also impose an additional trusted value deduction penalty, thereby greatly increasing the cost of node violations.

Claims

1. A privacy-preserving cross-datacenter anonymous authentication system, characterized in that, The system includes: The identity registration module is used to receive the public key, qualification certificate hash and node type label submitted by the node, generate anonymous DID identifier and assign an initial trusted value, and bind them together to generate an identity mapping table for on-chain storage. The access request module is used to calculate the access commitment value and submit it to the smart contract to trigger the authentication process when the current node initiates a cross-data center access request, based on the specific operation type label of this access, the security level of the accessed data and the access request timestamp. The anonymous authentication module is used to perform anonymous authentication, specifically: (1) The smart contract generates a random challenge value based on the access commitment value and returns it to the node. The node uses its own private key to sign the random challenge value to obtain the signature information. The smart contract performs double verification based on the signature information, the specific operation type label of this access, the access data security level, and the access request timestamp. (2) After verification, based on the fact that this access operation belongs to the cross-domain relay scenario, determine the effective trust value of the current node, and calculate the risk value of this access operation in combination with the access data security level. Based on this, match and execute differentiated authentication and evidence storage strategies to control access. The authorization and update module is used to determine the authorization of this access operation based on the valid trust value. After the node obtains authorization and completes the access operation, it generates an operation result hash and submits it to the smart contract. The smart contract judges the compliance of this access operation based on this hash, executes the reward and punishment settlement update strategy on the trust value, and synchronizes it to the identity mapping table to overwrite the original record.

2. The privacy-preserving cross-data center anonymous authentication system as described in claim 1, characterized in that, The allocation of the initial trust value includes: based on the node type label, a pre-set qualification score is given to the node, and the product of the score and the pre-set benchmark trust value is used as the initial trust value of the node.

3. The privacy-preserving cross-data center anonymous authentication system as described in claim 1, characterized in that, Access commitment value The calculation formula is: In the formula, A label for the specific operation type performed on the node; For the access request timestamp, To access data security levels, A random number generated locally on the node; This represents a hash function.

4. The privacy-preserving cross-data center anonymous authentication system as described in claim 1, characterized in that, The process of obtaining the random challenge value is as follows: the smart contract performs a bitwise XOR operation between the access commitment value and the current block hash to generate the random challenge value.

5. The privacy-preserving cross-data center anonymous authentication system as described in claim 3, characterized in that, The dual verification process is as follows: The public key bound to the anonymous DID is invoked, and this public key is used to verify whether the signature information corresponds to the issued random challenge value, thus confirming that the current node holds a legitimate private key and completing the signature validity verification; the smart contract will then return the specific operation type tag. Access Data Security Level Access request timestamp and random numbers The hash algorithm is used to recalculate the value and verify whether the result is consistent with the received access commitment value. This confirms that the current node's operational intent has not been tampered with, thus completing the commitment consistency verification.

6. The privacy-preserving cross-data center anonymous authentication system as described in claim 1, characterized in that, The determination of the current node's valid trust value includes: after the dual verification is passed, the smart contract parses the task tracking serial number carried in the access request to determine whether the current node's access operation belongs to a cross-domain relay scenario assigned by other nodes. If the current access operation does not involve a cross-domain relay scenario, the node's own trust value is directly defined as the valid trust value of the current access operation. Otherwise, the smart contract traces back to the previous hop node that assigned the task based on the task tracking serial number as the predecessor node, retrieves the trust value of the predecessor node, performs a positive mapping on it, and uses it as a trust transmission factor. The trust value of the current node is then weighted and converted using the trust transmission factor as the weight, and used as the valid trust value.

7. The privacy-preserving cross-data center anonymous authentication system as described in claim 1, characterized in that, The calculation of the risk value of this access operation, and the matching and execution of differentiated authentication and evidence storage policies accordingly for access control, includes: By performing a weight iteration strategy on all access operations within the historical period, the currently effective security level weight and trust weight are extracted. The effective trust value of the current node is negatively mapped. Based on the security level weight and trust weight, the result of the negative mapping is weighted and summed with the security level of the normalized access data of the node, which is used as the risk value of this access operation. The smart contract categorizes this access operation into different risk levels based on the risk value and executes differentiated authentication and evidence storage strategies accordingly, specifically: If the risk value is less than the preset first threshold, it is determined to be a low-risk operation. At this time, the operation log will be uploaded to the blockchain in batches at a preset long period for evidence storage. If the risk value is greater than or equal to the preset first threshold and less than the preset second threshold, it is determined to be a medium-risk operation. At this time, the operation log is written to the local buffer, the smart contract performs integrity verification on the cached operation log, and uploads the operation log to the blockchain in batches at a preset short period for evidence storage. If the risk value is greater than or equal to the preset second threshold, it is judged as a high-risk operation. In this case, in addition to performing dual verification, an enhanced authentication process is performed. After the verification is passed, the operation log is triggered to be uploaded to the blockchain for evidence storage in real time.

8. The privacy-preserving cross-data center anonymous authentication system as described in claim 7, characterized in that, The weight iteration strategy is as follows: Within a preset statistical period, extract all unblocked violations from all access operations within that period, along with the actual authentication time for each access operation, and calculate the error loss. The calculation formula is as follows: In the formula, This indicates the number of all access operations within the statistical period. Indicates the first The actual authentication time for each access operation. This indicates the preset tolerance time threshold. For the first The indicator for the next access operation, where if the first... This access operation is considered an unblocked violation; the indicator is set to 1, otherwise it is set to 0. This represents the function that takes the maximum value. Two weight parameters are preset, denoted as the initial security level weight and the initial trust weight, respectively, and the sum of the two weight parameters is 1. If the error loss is less than or equal to the preset value, the security level weight and the trust weight remain unchanged; otherwise, the weight callback mechanism is triggered, and the security level weight is reduced by the preset step size, while the trust weight is increased by the same preset step size, so as to ensure that the sum of the two is constant at 1.

9. The privacy-preserving cross-data center anonymous authentication system as described in claim 1, characterized in that, The authorization determination for this access operation based on the valid trust value includes: if the valid trust value of the current node is less than the preset minimum trust threshold, the access operation is rejected and the unauthorized attempt is recorded; otherwise, the access operation is allowed, and a trust value pre-freezing operation is immediately performed, deducting the trust consumption amount of this operation from the valid trust value of the current node in advance as a temporary trust value; wherein, the trust consumption amount is the preset minimum trust threshold corresponding to this operation.

10. The privacy-preserving cross-data center anonymous authentication system as described in claim 9, characterized in that, The process of determining the compliance of this access operation and updating the reward / penalty settlement strategy for the trust value includes: The smart contract determines the compliance of this access operation based on preset judgment conditions. If all judgment conditions are met, the access operation is compliant, and the first update strategy is executed to update the temporary trust value of the current node. Otherwise, if the access operation is non-compliant, the second update strategy is executed to update the temporary trust value of the current node. The updated temporary trust value is used as the new trust value of the node and synchronized to the on-chain identity mapping table to overwrite the original record. The preset judgment conditions are: the received operation result hash is consistent with the hash calculated by the access gateway independently of the network layer operation result through bypass interception; and the submission of the operation result hash does not time out. The first update strategy is: the updated temporary trusted value. The calculation formula is: In the formula, This is the temporary trusted value before the update. To preset the reward coefficient, For reliable consumption amount, The preset maximum confidence value, This represents a function that takes the minimum value. The second update strategy is: the updated temporary trust value. The calculation formula is: In the formula, To preset the penalty coefficient, The preset minimum confidence value, This represents the function that takes the maximum value.

Images