Bidirectional anonymous identity mutual trust system based on zero-knowledge trusted identity and authority certificate

Abstract

The invention relates to a bidirectional anonymous identity mutual trust system based on a zero-knowledge trusted identity and an authority certificate, and belongs to the technical field of identity authentication. The system comprises a certifier, a cross-network exchange messenger and a verifier, a certifier, namely an enterprise intranet initiating a service request, is a core carrier for sensitive data isolation and certification generation; a verifier, namely an enterprise intranet receiving a service request, is a key link for proving that validity verification is matched with service permission; the cross-network identity messenger is used as a unique data interaction channel of both parties, only undertakes an encryption forwarding function, and does not store and analyze any data; the transmission content is strictly limited as zero-knowledge proof data Proof and a service identifier, and does not contain any characteristic information capable of being associated with the identity. According to the method, the technical defects of the existing scheme are overcome, the method can be applied to a physically isolated heterogeneous intranet scene, and a safe, reliable, efficient, lightweight, compliant and controllable identity mutual trust solution is provided for enterprise cross-domain collaboration.

Description

Technical Field

[0001] This invention belongs to the field of identity authentication technology, specifically relating to a two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials. Background Technology

[0002] In enterprise collaborative office and cross-domain data interaction scenarios, there is often a deployment status of heterogeneous internal network physical isolation. This means that two or more enterprises each build their own business systems, such as email systems and file exchange systems, on their own internal networks, with no direct network connectivity between them. Limited data interaction can only be achieved through pre-defined cross-network data exchange services. In such scenarios, enterprises have extremely high security and confidentiality requirements for organizational information (such as departmental structure and enterprise codes) and sensitive user personal data (such as names, employee IDs, and job titles). The core constraint is that it is not permissible to synchronize one's own identity data to the other's system in plaintext or in a reversibly anonymized form. However, existing cross-domain identity mutual trust technologies all have unavoidable flaws and cannot meet the business interaction requirements under the above constraints. Specific problems are as follows:

[0003] (1) Traditional identity data synchronization scheme

[0004] In existing technologies, some enterprises use plaintext fragment synchronization or anonymized data sharing to achieve identity association. For example, they might extract the latter part of a user's employee ID or hide the first character of their name and synchronize it to the other party's system for identity matching. However, such solutions have inherent flaws: on the one hand, the anonymized data still contains associative identity features (such as employee ID format and name length), and attackers can reconstruct the complete sensitive data through multi-source data collision (such as combining publicly available business information); on the other hand, data synchronization relies on continuous transmission through cross-network exchange services, and once the platform has vulnerabilities, it can easily lead to the leakage of batch identity data, violating the core constraint that identity data synchronization is not allowed.

[0005] (2) Third-party trusted institution certification scheme

[0006] Some solutions introduce trusted third-party institutions such as Certificate Authorities (CAs) or unified identity management platforms, whereby the third party stores and distributes the identity credentials of both companies, such as digital certificates or tokens. However, this solution has extremely low applicability in physically isolated scenarios: First, the third-party institution needs to establish a connection with both parties' internal networks, breaking the deployment boundaries of physical isolation and increasing the system's attack surface; second, the company needs to expose complete identity data to the third party to generate credentials, creating a potential risk that a single point of leakage by the third party could lead to a global risk; third, cross-network interactions require the additional transmission of third-party credentials, increasing data exchange latency and making it difficult to adapt to low-latency business requirements such as email and file transfers.

[0007] (3) Hash mapping comparison scheme

[0008] Some improved solutions propose hash mapping based on shared keys, where both parties generate anonymous user identifiers (such as SHA-256 hash values) based on an agreed-upon algorithm, and identity verification is achieved by comparing these identifiers. However, this solution can only verify the existence of the identifier, not whether the user has the corresponding business permissions, such as whether they are authorized to send cross-domain emails or receive sensitive files. Furthermore, the hash identifier itself does not have the ability to bind permission attributes; if an attacker obtains an identifier, they can forge business requests, and the verifying party cannot distinguish between legitimate users and identifier thieves, leading to the risk of unauthorized access.

[0009] (4) Static account password authentication scheme

[0010] In some scenarios, a user account authentication method using a pre-set shared password is adopted. This involves both parties agreeing on a fixed password, and the user sending a request along with their account and password for verification. However, this solution has two major drawbacks: first, the account must include identity-related information (such as using a company prefix followed by the user's abbreviation), still posing a risk of sensitive data exposure; second, the password is easily leaked and vulnerable to brute-force attacks, and it cannot prove whether the user is a legitimate registered user on the company's internal network, only verifying the password's correctness. This allows unauthorized users to launch attacks after stealing the password, making its security insufficient for enterprise-level requirements.

[0011] In summary, existing technologies cannot achieve mutual trust between heterogeneous isolated intranets under the triple constraints of not disclosing sensitive identity data, not relying on third parties, and supporting permission verification. This leads to frequent business problems such as email delivery failures and inability to match file recipients. There is an urgent need for a new identity mutual trust technology solution that can complete two-way verification of identity legitimacy and permission validity without exposing zero sensitive data. Summary of the Invention

[0012] (a) Technical problems to be solved

[0013] The technical problem to be solved by this invention is how to provide a two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials, so as to solve the problems existing in the identity mutual trust technology between heterogeneous physically isolated intranets.

[0014] (II) Technical Solution

[0015] To address the aforementioned technical problems, this invention proposes a two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials. This system includes a prover, a cross-network exchange messenger, and a verifier.

[0016] The prover, i.e. the enterprise intranet that initiates the business request, is the core carrier for sensitive data isolation and proof generation. It integrates an identity mapping module and a zero-knowledge proof generation module, and completes the conversion of the user's real attributes to anonymous identifiers AID and permission identifiers PID, as well as the generation of zero-knowledge proofs Proof, only locally. All operations involving sensitive data do not leave the intranet boundary, blocking the risk of data leakage from the source.

[0017] The verifier, i.e. the enterprise intranet that receives the business request, is the key link in verifying the validity of the proof and matching the business permissions. It completes the lightweight verification of Proof through the zero-knowledge proof verification module, and at the same time verifies the business permissions of the requester in combination with the local permission rule table. It only executes the business logic after the double verification is passed.

[0018] The cross-network identity messenger, as the sole data exchange channel between the two parties, only undertakes the function of encrypted forwarding, without storing or parsing any data; the transmitted content is strictly limited to zero-knowledge proof data Proof and business identifiers, and does not contain any characteristic information that can be associated with the identity.

[0019] (III) Beneficial Effects

[0020] This invention proposes a two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials. Based on a core architecture of zero-knowledge proof and local identity mapping, this invention comprehensively optimizes existing cross-domain identity mutual trust solutions, achieving breakthrough improvements in sensitive data security, architectural independence, authorization verification integrity, and business adaptability. Specific beneficial effects are as follows:

[0021] (1) Achieve zero cross-network and zero exposure of sensitive identity data, blocking the risk of leakage at the source. This invention completely avoids the leakage risks caused by the synchronization of anonymized data and sharing with third-party data in existing solutions. On the one hand, the prover (such as user A of enterprise) only calls the identity mapping table locally to obtain non-sensitive values ​​such as anonymous identifier (AID) and permission identifier (PID), and does not export sensitive data such as organization name, user name, employee number, etc. outside the intranet throughout the process; on the other hand, the cross-network transmission only contains zero-knowledge proof data and business identifier. The proof data is pure mathematical encrypted information and does not contain any associatable identity features (such as employee number format, department coding rules). Based on the one-way verification characteristic of zero-knowledge proof, the verifier (such as enterprise B) cannot reverse deduce any sensitive information through the proof data. Even if the cross-network exchange service is attacked, the attacker can only obtain meaningless proof data and cannot steal the core identity assets of the enterprise, which fully complies with the compliance requirements of sensitive data not being transferred across networks.

[0022] (2) No need to rely on trusted third-party institutions, reducing architectural complexity and trust chain risks. This invention breaks through the dependence of existing solutions on third-party institutions (such as CAs and unified identity platforms). Both parties only need to negotiate offline before deployment to agree on three core rules: zero-knowledge proof generation rules (such as Groth16 algorithm parameters), identity legitimacy conditions, and permission verification standards. No third party is required in the subsequent authentication process. This design avoids the architectural intrusion of third-party connections breaking physical isolation and eliminates the trust risk of global identity data loss due to single-point leakage of third parties. At the same time, it eliminates the generation, transmission, and signature verification of third-party credentials, reduces cross-network data interaction links, and lowers system deployment and maintenance costs, such as eliminating the need to pay third-party service fees and maintain third-party interfaces.

[0023] (3) Achieve two-way verification of identity legitimacy and permission validity, preventing permission overreach and identifier theft. This invention addresses the shortcomings of existing hash mapping schemes, which only verify the existence of identifiers but lack permission verification. When generating zero-knowledge proofs, the prover needs to bind the anonymous identifier (AID) with the business permission identifier (PID) and permission status bit (such as activated / deactivated), and generate the proof in combination with the permission compliance conditions agreed upon by both parties (such as the PID needing to match the email sending permission code and the status bit needing to be activated). During the verification phase, the verifier can simultaneously confirm that the prover is a legitimate user of the other party's enterprise (identity legitimacy) and that the prover has the current business operation permissions (permission validity), and can verify the dynamic status of permissions in real time (such as the old proof immediately becoming invalid when the local mapping table updates the status bit after the user leaves the company). This mechanism completely eliminates the risks of forging business requests after identifier theft and unauthorized users initiating cross-domain operations, and the completeness of permission verification far exceeds that of existing schemes.

[0024] (4) Lightweight and efficient, adaptable to low-latency business scenarios, ensuring smooth cross-domain interaction. This invention uses the Groth16 zero-knowledge proof algorithm, balancing proof generation efficiency and lightweight verification. The prover only needs a single local hash operation and algorithm parameter input to generate the proof, which is time-efficient and adaptable to the performance of ordinary enterprise servers; the verifier only needs 3 bilinear pairing operations to complete the verification, which is time-efficient and the amount of data transmitted across the network is only the proof data (about 200 bytes) and the business identifier (about 50 bytes), which is much smaller than the transmission volume of third-party credentials (such as X.509 certificates, about 1KB) or desensitized identity data (about 500 bytes). This feature can perfectly adapt to latency-sensitive business scenarios such as targeted email delivery and instant file exchange, avoiding business lag caused by the time-consuming credential verification and large data transmission volume of existing solutions, and ensuring the smoothness of cross-domain collaboration.

[0025] (5) It possesses high resistance to forgery and immutability, and its security strength meets enterprise-level requirements. This invention constructs a security barrier based on mathematical encryption theory, far exceeding the security level of existing static account password schemes. The generation of zero-knowledge proofs relies on real data in the local identity mapping table and shared algorithm parameters between the two parties. If an attacker does not obtain the anonymous identifier, permission identifier, and algorithm parameters of the prover, they cannot forge a valid proof. Even if an attacker steals a certain proof data, it cannot be reused in other business scenarios because the proof is bound to a specific business request (such as matching only a certain email sending request ID). At the same time, the proof data contains a generation timestamp, which can verify the timeliness during verification and prevent replay attacks of old proofs. The anti-forgery, immutability, and replay resistance of this mechanism fully meet the high security requirements of enterprise-level cross-domain authentication.

[0026] This invention optimizes five dimensions: sensitive data security, architectural independence, permission verification, business adaptation, and security strength. It not only solves the technical defects of existing solutions, but also can be implemented in physically isolated heterogeneous intranet scenarios, providing enterprises with a secure, reliable, efficient, lightweight, compliant and controllable identity trust solution for cross-domain collaboration. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0028] Figure 2 This is a schematic diagram of the process for generating trusted identity and authorization credentials in this invention;

[0029] Figure 3 This is a schematic diagram of the identity and authorization trusted credential verification process in this invention;

[0030] Figure 4 This is a schematic diagram illustrating the complete business stages of a cross-domain email application as an example in this invention.

[0031] Figure 5 This is a schematic diagram of the business process of the sender's business execution stage in the present invention, taking cross-domain email application as an example;

[0032] Figure 6 This is a schematic diagram of the business process of the recipient's business execution stage in this invention, taking cross-domain email application as an example. Detailed Implementation

[0033] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0034] This invention belongs to the field of heterogeneous intranet identity mutual trust technology in enterprise-level cross-domain collaboration scenarios, specifically involving a two-way anonymous identity mutual trust system and method based on zero-knowledge trusted identity and authorization credentials.

[0035] The purpose of this invention is to address the core deficiencies in existing heterogeneous, physically isolated intranet identity trust technologies. Specifically, it aims to overcome the following technical problems to achieve cross-domain identity trust with zero exposure of sensitive data, no third-party dependence, and two-way verification of identity and permissions:

[0036] This invention addresses the risks of data leakage and compliance conflicts arising from the cross-network transfer of sensitive data in traditional identity data synchronization solutions. Existing solutions achieve association through anonymized or fragmented identity data synchronization, but still carry risks of feature association, reverse engineering, and leakage during cross-network transmission. Furthermore, they violate the compliance constraint that sensitive data should not be transferred across networks. This invention aims to achieve the basic construction of identity association without transmitting any sensitive organizational or user personal data (including plaintext, semi-anonymized, and feature-associable forms).

[0037] This invention addresses the issues of architectural intrusion, trust chain risks, and business latency in third-party trusted institution authentication schemes. Existing solutions rely on third-party institutions to establish trust, which requires breaking physical isolation boundaries, exposing complete identity data, and increasing cross-network interaction latency. This invention aims to eliminate dependence on third parties and build trust solely through pre-defined rules between the two parties, avoiding the risks of breaching intranet deployment boundaries and single points of failure in the trust chain, and adapting to low-latency business requirements.

[0038] This invention addresses the issues of missing permission verification and insufficient anti-forgery capabilities in hash mapping identification schemes. Existing schemes can only verify the existence of anonymous identifiers, cannot bind user permission attributes, and lack dynamic permission status verification, making them prone to identifier theft and permission overreach. This invention aims to achieve linked verification of identity legitimacy and permission validity based on anonymous identifiers, ensuring that identifiers are bound to permissions and improving anti-forgery capabilities.

[0039] This invention addresses the issues of insufficient identity uniqueness verification and inadequate security strength in static account and password authentication schemes. Existing schemes rely on static accounts (including identity features) and password verification, which exposes account information, makes passwords vulnerable to leakage or cracking, and fails to verify the user's legitimate intranet registration identity. This invention aims to replace static authentication methods, achieving unique verification of the user's legitimate intranet identity while eliminating account feature exposure and password security vulnerabilities.

[0040] By solving the above problems, this invention ultimately achieves bidirectional anonymous identity trust between heterogeneous physically isolated intranets, ensuring the secure and accurate flow of cross-domain email transmission, file interaction and other services, while taking into account data security, architectural adaptability and business efficiency.

[0041] (I) Overall Technical Solution

[0042] This invention addresses the core requirement of heterogeneous intranets with physical isolation and zero exposure of sensitive identity data. It focuses on the shortcomings of existing solutions, such as strong reliance on third parties, lack of authorization verification, and easy leakage of sensitive data. It constructs a three-layer architecture including a prover, a cross-network exchange messenger, and a verifier. Through an integrated design of local identity mapping, zero-knowledge proof, and lightweight cross-network transmission, it achieves two-way verification of identity legitimacy and authorization validity, without disclosing any sensitive organizational or user personal data throughout the process. It is perfectly adaptable to business scenarios such as cross-enterprise email and file interaction. Specifically:

[0043] The provider, i.e., the enterprise intranet that initiates the business request (such as enterprise A), is the core carrier for sensitive data isolation and proof generation. It integrates an identity mapping module and a zero-knowledge proof generation module, and completes the conversion of the user's real attributes to anonymous identifiers (AID) and permission identifiers (PID) and the generation of zero-knowledge proofs (Proof) only locally. All operations involving sensitive data do not leave the intranet boundary, blocking the risk of data leakage from the source.

[0044] The verifier, i.e., the enterprise intranet receiving the business request (such as Enterprise B), is the key link in verifying the validity of the proof and matching business permissions. It performs lightweight verification of Proof through a zero-knowledge proof verification module, and at the same time verifies the requester's business permissions in conjunction with the local permission rule table. It only executes business logic after the double verification is passed, eliminating risks such as identity theft and permission overreach.

[0045] The cross-network identity messenger, acting as the sole data exchange channel between the two parties, only performs encrypted forwarding functions and does not store or parse any data. The transmitted content is strictly limited to zero-knowledge proof data and business identifiers (such as email request IDs), and does not contain any identity-related feature information to prevent the platform from becoming a security vulnerability.

[0046] The core technological improvements in this solution precisely address the shortcomings of existing solutions, as detailed below:

[0047] (1) Break through the bottleneck of third-party dependence. Abandon the dependence of traditional solutions on third parties such as CA institutions and unified identity platforms. Self-trust can be achieved by only three core rules agreed upon offline by both parties: identifier generation rules, zero-knowledge proof parameters, and permission verification standards. This avoids the risk of single point of leakage or architectural intrusion by third parties and is compatible with the deployment constraints of physically isolated intranets.

[0048] (2) Solve the problem of missing permission verification. Innovative design of a two-dimensional binding mechanism of anonymous identifier (AID) and permission identifier (PID). AID is used to prove that the user is a legitimate member of the other party, and PID is used to prove that the user has the current business permission. Both are generated locally and bound for transmission, which completely makes up for the shortcomings of the existing hash mapping scheme that only verifies the existence of the identifier and does not verify the permission, and realizes the integrated verification of identity and permission.

[0049] (3) Balancing the contradiction between security and efficiency. The Groth16 zero-knowledge proof algorithm was selected as the core engine. This algorithm has the characteristics of high proof generation efficiency (low single-time consumption), lightweight verification steps (only 3 bilinear pairing operations), and concise data volume (single proof ≈ 200 bytes). It not only meets enterprise-level security requirements, but also adapts to scenarios with limited cross-network bandwidth and low business latency (such as instant email delivery), avoiding the problem of business lag caused by security enhancement.

[0050] (4) Construct a local self-maintenance model. Both parties maintain an identity mapping table (provider side) and an access control rule table (verifier side) locally. The mapping table only stores the association between the user's real attributes and AID and PID, and the rule table only defines the business scenario to the compliant PID range. Neither of them is synchronized across networks, which reduces data synchronization costs and ensures that each enterprise has complete control over its own data, in accordance with data security compliance requirements.

[0051] (II) System Architecture and Module Description

[0052] refer to Figure 1 As shown, the system architecture of this invention includes the following core functional modules:

[0053] (1) Identity Mapping Module

[0054] This module is deployed on the prover's core server. Its core function is to generate an anonymous identifier (AID) and a permission identifier (PID) based on the user's local unique attribute (UID, such as employee ID 2024001 of company A) according to an algorithm agreed upon by both parties. The entire computation is completed within the prover's intranet and does not interact with external systems. In terms of performance, this module possesses high concurrency processing capabilities and extremely low latency response characteristics, easily handling enterprise-level multi-user concurrent request scenarios. From a security perspective, the module only accepts legitimate requests from the prover's business system and rejects unauthorized external access.

[0055] (2) Zero-knowledge proof generation module

[0056] This module is also deployed on the prover's side core server, working in conjunction with the identity mapping module and the Groth16 algorithm engine. Its core function is to load the preset proof key. ), receives the AID and PID output by the identity mapping module, and combines them with the locally stored shared key ( The module uses the Enterprise ID (EID) and R1CS constraints to generate zero-knowledge proofs. In terms of performance, this module generates proofs quickly and efficiently in a single pass, producing concise proof data that can adapt to the bandwidth limitations of cross-network exchange platforms. Regarding functional constraints, the module only outputs the proof and the business identifier, without containing any sensitive information that could be associated with the identity.

[0057] (3) Zero-knowledge proof verification module

[0058] This module is deployed on the core server on the validator side and is a core component for identity mutual trust on the validator side. Its core functions include two parts: first, loading the preset verification key ( The first step is to perform a bilinear pairing operation on the received Proof to verify its mathematical validity; the second step is to query the compliant PID range corresponding to the current business scenario from the permission rule table on the verifier side. The module verifies whether the PID associated with the Proof is within the compliance range. In terms of performance, the module has a fast verification response and excellent high-concurrency processing capabilities, which can effectively meet the needs of cross-domain business scenarios. In terms of security design, the module only receives data transmitted encrypted through a cross-network exchange platform, and does not return specific reasons for failure (such as PID non-compliance or Proof forgery) when verification fails, thus preventing attackers from probing the system rules.

[0059] (4) Identity Mapping Table (Proofer Side)

[0060] This table, stored in the prover's local database, is the core data carrier for associating the prover's identity with their identifier. Its core function is to store the mapping relationship between a user's unique ID (UID), anonymous identifier (AID), and permission identifier (PID), and access is only granted to the prover's identity mapping module. From a security perspective, the database uses the national cryptographic algorithm SM4 to encrypt the stored data, preventing local data leakage. From a maintenance perspective, the data in the table is only updated independently by the prover (e.g., adding mapping records when a new user is added, deleting records when a user leaves), without needing to synchronize with the verifier, thus avoiding the risk of cross-network data transfer.

[0061] (5) Permission rules table (verifier side)

[0062] This table is stored in the validator's local database. Its core function is to establish the mapping between business scenarios and compliant PID ranges, such as the mapping between cross-domain email receiving scenarios. (Binary encoding, representing email services and receiving permissions), corresponding to cross-domain file sending scenarios. In terms of maintenance features, the table supports dynamic updates. Verifier-side administrators can adjust the range of compliant PIDs according to business needs, and the update operation takes effect immediately without requiring a system restart. In terms of access control, only the zero-knowledge proof verification module and the administrator workstation can access the table, while other business systems do not have query permissions, ensuring that the rules cannot be tampered with.

[0063] (6) Cross-network identity messenger is an encrypted transmission messenger

[0064] This messenger, deployed within the cross-network exchange service, acts as an encrypted transmission gateway, serving as the sole data interaction channel between the prover and verifier sides. Its core functions include two parts: first, performing dual encryption of transmitted data using TLS 1.3 and the Chinese national cryptographic standard SM4. The outer TLS 1.3 layer ensures the security of the cross-network transmission link, while the inner SM4 encryption layer ensures the security of the data itself, preventing man-in-the-middle attacks; second, based on access control policies, it only allows data bound to Proof and business identifiers to pass through, rejecting any data transmission containing sensitive identity information (such as UID or user name). In terms of adaptability, the cross-network exchange service can maximize the transmission bandwidth of the underlying cross-network transmission equipment, meeting the cross-network data interaction needs of enterprises of different sizes. In terms of reliability, the gateway has a low packet loss rate and supports breakpoint resumption, ensuring that business data is not lost.

[0065] (III) Key Technologies and Algorithms

[0066] This section focuses on two core technologies: identity generation and zero-knowledge proof implementation. Through rigorous algorithm design and parameter constraints, it addresses the shortcomings of existing solutions, such as easy leakage of sensitive data, lack of authorization verification, and low verification efficiency, while ensuring the feasibility of engineering implementation.

[0067] (1) Algorithm for generating identity and permission identifiers based on dual-identity binding mechanism

[0068] To address the shortcomings of existing hash mapping schemes that only verify identity existence but lack permission association, this invention designs a two-dimensional binding mechanism of anonymous identifier (AID) and permission identifier (PID). AID is used to prove that the user is a legitimate member of the other party's enterprise, and PID is used to prove that the user has the current business operation permission. Both are generated locally and used only for zero-knowledge proofs, without transmitting the original values ​​across the network, thus ensuring the security of sensitive data from the root.

[0069] 1) Anonymous Identifier (AID) Generation Algorithm

[0070] This algorithm is used to complete irreversible identity mapping. AID is an anonymous substitute for a user's identity, generated based on a shared key, unique user attributes, and a random salt value, ensuring that the real identity cannot be irreversibly deduced, and both parties can independently calculate it through unified rules without needing to synchronize the mapping table.

[0071] (a) Algorithm formula (customized by both parties)

[0072]

[0073] (b) Parameter definition and constraints

[0074] a) (Shared key)

[0075] Generation method: The two parties exchange public keys offline based on the ECC elliptic curve encryption algorithm (using the secp256r1 curve), and the public key is calculated through the ECDH (Elliptic Curve Diffie-Hellman) protocol;

[0076] Length and Update: 256-bit binary value, rotated once per quarter, new key is synchronized through offline secure medium, old key is retained for 24 hours to be compatible with unfinished business requests;

[0077] Storage constraints: It is stored only in the encrypted memory of the identity mapping module on the prover side, and is not written to disk. It is automatically destroyed after the process ends to prevent local leakage.

[0078] b) EID (Enterprise Unique ID)

[0079] Format: 3-character ASCII characters (e.g., company A=001, company B=002), to be determined offline, with no business meaning, used only to distinguish company identity;

[0080] Constraints: Do not include sensitive features such as company name and industry attributes; they are used only as fixed parameters in the identity legitimacy constraint of zero-knowledge proof.

[0081] c) UID (User's Local Unique Attribute)

[0082] Definition: A non-sensitive unique identifier of the prover-side user in the local system (such as employee number 2024001 of company A, customer number C0056), which does not contain sensitive information such as name, department, or position;

[0083] Constraints: It can only circulate within the intranet on the certifier's side, and cannot be transmitted across networks. It must also meet the requirement of local global uniqueness, which is guaranteed by the HR system or user management system of enterprise A.

[0084] d) Salt (random salt value)

[0085] Generation method: The identity mapping module on the prover side calls the hardware random number generator (HRNG) to generate the number in real time, avoiding the generation of the same AID by the same UID;

[0086] Length: 128-bit binary value, regenerated each time an AID is generated, and stored in a local identity mapping table bound to the AID for reuse in subsequent business retransmissions.

[0087] (c) Security verification

[0088] Collision resistance based on SHA-256 (collision probability ≤ 2) -128 Due to its one-way nature, even if an attacker obtains the AID and some parameters (such as the EID), they cannot reverse-engineer it. It contains core information such as UID; combined with the randomness of Salt, it can completely avoid the risk of rainbow table attacks, and the same UID will generate different AIDs at different times.

[0089] 2) Permission Identifier (PID) Encoding Rules

[0090] This rule enables the binding of business scenarios and permissions. The PID is the digital carrier of user business permissions. By associating business types and permission levels through fixed coding rules, it solves the problem that existing solutions cannot verify whether users have business permissions, and supports flexible expansion to multiple business scenarios.

[0091] (a) Encoding format

[0092] A fixed-length 16-bit binary code is used to facilitate zero-knowledge proof constraint computation. An example is shown below:

[0093] Fields Number of digits Meaning Explanation Encoding example (binary → hexadecimal) Business type field High 8 bits <![CDATA[Define cross-domain business scenarios, reserve expansion bits, and support 2 8 = 256 types of business]]> Email transfer = 00000001 → 01; File exchange = 00000010 → 02 Permission level field lower 8 bits Define the operation permissions for this business scenario, such as send, receive, read and write; 00 indicates no permission. Send permission = 00000001 → 01; Receive permission = 00000010 → 02 Complete PID 16-bit The combination of business type and permission level uniquely corresponds to the specific permissions for a particular business scenario. Email sending permission = 0000000100000001 → 0101; File receiving permission = 0000001000000010 → 0202

[0094] (b) Generation and maintenance mechanism

[0095] a) Generation logic

[0096] The business systems on the verifier side (such as email systems and file systems) automatically assign PIDs based on user roles. For example, the marketing department collaboration users of Company A are assigned email sending (0101) and file receiving (0202) permissions by default, while ordinary employees are only assigned email receiving (0102) permissions;

[0097] b) Dynamic updates

[0098] When user permissions change (such as promotion or job transfer) or new business scenarios are added, the verifier-side administrator updates the PID in the local identity mapping table through the permission management backend. The update takes effect quickly without notifying the verifier-side. The verifier-side dynamically verifies the compliance of the PID through the permission rule table.

[0099] c) Failure Mechanism

[0100] When a user leaves the company or is frozen, the verifier will set the PID's permission level field to 00 (no permission). Even if the old AID is stolen, the verifier will reject the request because the PID is non-compliant, thus eliminating the risk of permission overreach.

[0101] (2) Lightweight and efficient zero-knowledge proof algorithm for identity and permission verification

[0102] This invention selects the Groth16 algorithm as the core engine for zero-knowledge proof. Its advantages are high proof generation efficiency, lightweight verification steps (only 3 bilinear pairing operations are required), and small proof data volume (about 200 bytes). It is perfectly adapted to the low latency and low bandwidth business requirements in cross-network physical isolation scenarios, while meeting enterprise-level security requirements.

[0103] 1) Algorithm parameter selection

[0104] The security and efficiency of the Groth16 algorithm depend on the reasonable selection of basic parameters. The parameters of this scheme all conform to cryptographic standards and support engineering implementations of mainstream development libraries (such as libsnark and arkworks).

[0105] (a) Basic Elliptic Curve

[0106] The BN254 curve (also known as the BN curve) was chosen for the following reasons:

[0107] a) Security

[0108] The curve order is 254 bits, and its resistance to discrete logarithm attacks is equivalent to 128-bit symmetric encryption, which meets the security level of the national cryptographic standard SM4.

[0109] b) Efficiency

[0110] It supports fast computation of bilinear pairing, with low pairing operation time, far lower than other curves such as BLS12-381;

[0111] c) Compatibility

[0112] Mainstream zero-knowledge proof development libraries all support the BN254 curve, allowing for the direct reuse of mature algorithm implementation code and reducing development costs.

[0113] (b) Generation of public parameters (PK)

[0114] a) Generation method

[0115] The process is conducted offline jointly by both parties to avoid third-party intervention. Company A generates a random private key. (Used to control the identity legitimacy constraints of Proof) (Used to control the validity constraints of Proof permissions), Enterprise B generates a random private key. , (Consistent with logic A), after exchanging public keys through a secure medium, they jointly calculate the public parameter PK, which includes the proof key. With verification key ;

[0116] b) Parameter content

[0117] Generated and stored by the prover, containing , , Equal elliptic curve points are used to generate Proof, where G and H are generators of the BN254 curve; It only contains encrypted secret parameter traces, which attackers cannot extract from... Reverse push , This ensures the security of Company A's confidential parameters.

[0118] Generated and stored by the validator, containing , , Equal elliptic curve points are used to verify the proof; "Used only to verify the validity of Proof", and does not contain , ,even though Even if it is stolen, the Proof cannot be forged.

[0119] c) Offline parameter calibration

[0120] because and Generated by A and B respectively, each calibration parameter requires exchange via offline secure media. Company A will... The public key component is sent to Enterprise B, and Enterprise B verifies it. Does it conform to the pre-defined curve format (no parsing required)? To ensure that both parties use the same BN254 curve parameters and base point G / H, it is necessary to confirm that the parameters are completely consistent to avoid subsequent verification failures due to parameter mismatch.

[0121] d) Safety constraints

[0122] The PK parameter is generated only once, during the initialization phase. If Rotation eliminates the need to regenerate the key-value pair (PK), requiring only updates to the constraints of the zero-knowledge proof, thus reducing maintenance costs.

[0123] (c) Design of the constraint system (R1CS)

[0124] To achieve dual verification of identity legitimacy and authorization validity, business rules are transformed into mathematical constraints of a Rank-1 constraint system (R1CS), ensuring that provers can only generate Proofs that conform to the rules and cannot forge authorizations. The core constraints are as follows:

[0125] a) Constraints on the legitimacy of identity

[0126] Verify that the generated AID conforms to the algorithm agreed upon by both parties, namely:

[0127]

[0128] By decomposing SHA-256 operations into linear operations and nonlinear gate circuits supported by R1CS, the constraints are ensured to be verifiable.

[0129] b) Permission validity constraints

[0130] Verify that the PID is within the compliance range of the current business scenario, that is:

[0131]

[0132] For the validator-side permission rule table, this refers to the compliant PID for the current business scenario, such as the email receiving scenario. "&" represents a bitwise AND operation; a non-zero result indicates that the PID is compliant.

[0133] c) Timestamp constraints

[0134] To prevent Proof from being replay-attacked, i.e.:

[0135]

[0136] Current_Time is the current time on the verifier's side, and Proof_Time is the timestamp when the prover generated the Proof, in seconds. 300 seconds is the valid duration of the Proof; if the timeout occurs, the verification fails.

[0137] 2) Core steps of proof generation and verification

[0138] (a) Proof generation process (prover's side) Reference Figure 2 As shown, the process is as follows:

[0139] a) Parameter input stage

[0140] The identity mapping module receives requests from business systems (such as Enterprise A's email system), inputs the user's UID, outputs the AID, PID, and Salt (queried from the local identity mapping table), and reads the locally stored... EID;

[0141] b) Constraint satisfaction check

[0142] The proof generation module first verifies the validity of the PID locally. If the permission level field of the PID is not equal to 00, it will directly return insufficient permissions and not generate a Proof, thus avoiding invalid cross-network transmission.

[0143] c) R1CS instantiation

[0144] AID, PID, Substitute EID, Salt, and the current timestamp Proof_Time into the R1CS constraint system to generate an R1CS instance (including input vector x, intermediate variable vector w, and output vector y).

[0145] d) Proof generation

[0146] Call the Groth16 algorithm engine and load... Input an R1CS instance and generate Proof is the core data that company A uses to prove to company B that "I have a legitimate identity and authorization," and its generation process is entirely based on local parameters. (AID, PID), without disclosing any sensitive information, the steps are as follows:

[0147] Step S11: Prepare input parameters

[0148] ① Business Data: AID (Anonymous Identifier) ​​and PID (Permission Identifier) ​​obtained by Enterprise A from the identity mapping module. These two data points are the information that needs to be proven. ② Blinding Parameters: Enterprise A randomly generates two temporary parameters. Its function is to hide the true value of business data.

[0149] Step S12: Calculate the three components of Proof Assemble Proof

[0150] Each component is related to the previously generated... Secret parameters ( , ), and strong correlation with business data. Corresponding proof of identity, , Prove that Company A has a valid AID, and that it is based on Generated; Proof of the validity of corresponding permissions. , Prove that Company A has a valid PID, and that it is based on Generated; The relationship between the corresponding blinding parameters and constraints, , It is a connection and This bridge ensures the joint validity of AID and PID, while also allowing the blinding parameters to be offset during verification.

[0151] e) Output results

[0152] The proof generation module outputs a Proof and its associated business identifier. The business identifier is a globally unique request ID (e.g., Mail_20240501_0001, containing business type, date, and sequence number), used by the verifier to associate business data.

[0153] (b) Proof Verification Process (Verifier Side) Reference Figure 3 As shown, the process is as follows:

[0154] a) Data reception and parsing

[0155] The verification module receives Proof and service identifier through the cross-network exchange platform, and parses the service identifier to obtain the current service scenario (such as Mail_receive).

[0156] b) Compliant PID Query

[0157] Query the local permission rules table for the current business scenario. (e.g., "Mail_receiving scenario") =0102);

[0158] c) Proof format verification

[0159] Verify that the Proof format conforms to the BN254 curve point specification (e.g., ...). (Check whether the coordinates are within the curve's domain). If the format is incorrect, reject the calculation directly to avoid invalid calculations.

[0160] d) Bilinear paired verification

[0161] Call the Groth16 algorithm engine and load... Perform the following pairing operation:

[0162]

[0163] e is the bilinear pairing function of the BN254 curve. If the equation holds, then the mathematical validity of Proof is passed.

[0164] e) Business rule verification

[0165] Verify timestamp validity (Current_Time - Proof_Time ≤ 300) and PID compliance (PID & If both conditions are met (!=0), then the overall verification passes.

[0166] f) Results Feedback

[0167] If the verification passes, a permission to execute the business is returned to the business system (such as Enterprise B's email system), along with a business identifier (used to associate email content); if the verification fails, a verification failure is returned (without a specific reason for failure, to prevent attackers from probing the rules).

[0168] 3) Security Analysis

[0169] (a) Unforgeability

[0170] The mathematical security based on the Groth16 algorithm means that if an attacker does not obtain... With valid AID and PID, it is impossible to generate a verified Proof (probability of forgery ≤ 2). -128 );

[0171] (b) Resistance to re-explosion

[0172] The timestamp constraint ensures that the Proof is only valid for 300 seconds and cannot be reused even if the Proof is stolen;

[0173] (c) Sensitive data isolation

[0174] During the proof generation and verification process, Sensitive data such as UID and Salt are not transmitted across networks; only Proof is transmitted, which has no identity characteristics, thus completely blocking the risk of data leakage.

[0175] (iv) Complete business implementation process

[0176] refer to Figure 4 As shown, this section takes sending a cross-domain email from enterprise A to enterprise B as an example to describe in detail the complete process from initialization to business execution, including two stages: pre-initialization and business execution. The business execution stage includes business request and proof generation, cross-network transmission, verification and execution of business, etc.

[0177] (1) Pre-Init phase

[0178] Before the business officially starts, both parties need to complete a one-time parameter agreement and system configuration. All configurations are stored locally and not transmitted across networks, laying a reliable foundation for subsequent business execution.

[0179] 1) Shared key generation and distribution

[0180] Both parties use the ECC (Elliptic Curve Cryptography) algorithm (secp256r1 curve recommended) to negotiate and generate a shared key offline. .

[0181] The specific process is as follows: Company A generates a private key. With public key Company B generates a private key. With public key After exchanging public keys via encrypted USB drives, both parties calculated the same... . The key management system (KMS) is stored locally on both parties, and an access whitelist is set up to allow only the identity mapping module and the zero-knowledge proof generation / verification module to call it. At the same time, a key rotation cycle is agreed upon (it is recommended to rotate it once every quarter) to avoid security risks caused by long-term use.

[0182] 2) Basic Identification Rules

[0183] Enterprise ID (EID): A unique enterprise ID agreed upon offline by both parties. It is used only for identification generation and does not contain sensitive semantic information. For example, Enterprise A=001, Enterprise B=002;

[0184] Anonymous Identifier (AID) generation formula: explicit Salt is a 128-bit random number generated in real time by the identity mapping module to prevent different users from generating the same AID.

[0185] Permission Identifier (PID) encoding rules: The PID is defined as a 16-bit binary number. The high 8 bits represent the business type (e.g., 00000001 represents email), and the low 8 bits represent the permission level (e.g., 00000001 represents send). The encoding lookup table of business type and permission level is synchronized to ensure that both parties can interpret the PID in a consistent manner.

[0186] 3) Zero-knowledge proof parameter configuration

[0187] Both parties jointly generate common parameters (PK) using the Groth16 algorithm, including the proof key ( ) and verification key ( The parameter generation process is completed offline and exchanged via secure media (such as an encrypted USB drive). The prover (Company A) only retains the data. Used to generate proofs, the verifier (Company B) only saves... For verification purposes, the BN254 algorithm curve was selected to balance security and computational efficiency, ensuring lightweight proof generation and verification.

[0188] 4) Initialize the permission rule table: On the verifier side (Enterprise B), configure the permission rule table in the local database to store the mapping relationship between business scenarios and allowed PID ranges, such as the cross-domain email receiving scenario. (Binary "00000001 00000001"). This table supports dynamic updates. Verifier-side administrators can adjust the compliant PID range through the administrator workstation. Updates take effect quickly without requiring a system restart, balancing business flexibility and security.

[0189] (2) Business execution phase (Runtime)

[0190] refer to Figure 5 Flowchart of sender proof generation and transmission Figure 6 The receiver's verification and response flowchart illustrates the main processes during the business execution phase:

[0191] 1) Initiate a business request

[0192] Triggering condition: User A of Company A enters recipient information in an email client (the local unique identifier of User B). ), email subject and body, then click the send button;

[0193] Business system operation: Enterprise A's application server (email business system) generates a unique business identifier (e.g., M20240501001) to mark this email request, and at the same time extracts the sender's local unique identifier ( The information and business type (email sending) are passed to the identity mapping module, which requests the generation of an associated identifier.

[0194] 2) Local identity mapping

[0195] Input parameters: Sender's local unique identifier ( ), Business type (email sending);

[0196] Core processing: The identity mapping module queries the local database (identity mapping table). The corresponding basic information is used to generate a 128-bit random salt in real time; these are then substituted into the AID generation formula to calculate the sender's anonymous identifier. Based on Company A's user permission system, query In cross-domain email sending scenarios, permission levels are defined, and permission identifiers are generated. (Binary "0000000100000001");

[0197] 3) Generate zero-knowledge proofs

[0198] Input parameters: , Enterprise A code ( =001), Business Identifier (M20240501001);

[0199] Core processing: Enterprise A's business system passes the above parameters to the zero-knowledge proof generation module, which loads the locally stored... (Groth16 proof key); compile the input parameters into an R1CS constraint system to construct identity legitimacy constraints (verification). Generate compliance) and permission validity constraints (verification) (This falls within the scope of email sending permissions); execute the Groth16 algorithm to randomly generate blinding parameters. The calculation proves it. ,in Points on the elliptic curve of curve BN254;

[0200] Output: Proof (approximately 200 bytes) and the bound business identifier (M20240501001), while the email content is encrypted using the national cryptographic SM4 algorithm to form the ciphertext of the email.

[0201] 4) Cross-network transmission

[0202] Transmitted content: Proof + business identifier + encrypted email, containing no sensitive identity information, such as... User name;

[0203] Security Measures: Enterprise A's business system sends the transmitted content to the encrypted transmission messenger of the cross-network exchange service. The encrypted transmission first establishes a secure transmission link through the TLS 1.3 protocol to ensure link layer security. The transmitted content is then encrypted again using the national cryptographic SM4 algorithm, forming a dual protection of link encryption and content encryption to prevent man-in-the-middle attacks or data theft. The access control module of the cross-network exchange service verifies the type of the transmitted content. After confirming that it only contains Proof, business identifier, and ciphertext, the transmission log (including proof ID, business identifier, and timestamp) is recorded through the log audit module. The content is then forwarded to Enterprise B's intranet.

[0204] 5) Proof verification and permission check

[0205] Input parameters: Received Proof, Service Identifier (M20240501001), Enterprise A Code ( =001);

[0206] Core Processing: After receiving data, the encrypted messenger of Enterprise B first decrypts it using TLS 1.3 and SM4 to extract the Proof, business identifier, and ciphertext. The Proof and business identifier are then passed to the zero-knowledge proof verification module. The verification module loads the locally stored... (Groth16 verification key), perform bilinear pairing operation to verify the mathematical validity of Proof, if If the condition is met, then the Proof is valid; the verification module queries the local permission rule table for the cross-domain email receiving scenario. Parsing through Proof ,check Whether or not match;

[0207] Output: If Proof is valid and If the match is found, the verification is successful; otherwise, the verification fails without revealing the specific reason for the failure, such as a fake Proof or an incompatible PID.

[0208] 6) Execution of business and feedback of results

[0209] Validation Success Scenario: The zero-knowledge proof validation module sends a validation success notification to Enterprise B's email business system. The system then determines the recipient based on the email address. The system queries the local email database and delivers the decrypted email to the corresponding email address. Enterprise B's business system generates a delivery success response and sends it back to Enterprise A via cross-network exchange service. After receiving the response, Enterprise A's business system displays "sent successfully" in the user's workstation's email client, and the process ends.

[0210] Verification failure scenario: The zero-knowledge proof verification module returns a verification failure to Enterprise B's business system, and the system directly rejects the email delivery; the failure is reported to Enterprise A through the cross-network exchange platform, and Enterprise A's email client displays "Recipient identity verification failed, please check the information and try again", without disclosing the details of the failure and preventing attackers from probing the system rules.

[0211] Beneficial effects:

[0212] This invention is based on a core architecture of zero-knowledge proof and local identity mapping. It comprehensively optimizes existing cross-domain identity mutual trust solutions, achieving breakthrough improvements in sensitive data security, architectural independence, completeness of permission verification, and business adaptability. The specific beneficial effects are as follows:

[0213] (1) Achieve zero cross-network and zero exposure of sensitive identity data, blocking the risk of leakage at the source. This invention completely avoids the leakage risks caused by the synchronization of anonymized data and sharing with third-party data in existing solutions. On the one hand, the prover (such as user A of enterprise) only calls the identity mapping table locally to obtain non-sensitive values ​​such as anonymous identifier (AID) and permission identifier (PID), and does not export sensitive data such as organization name, user name, employee number, etc. outside the intranet throughout the process; on the other hand, the cross-network transmission only contains zero-knowledge proof data and business identifier. The proof data is pure mathematical encrypted information and does not contain any associatable identity features (such as employee number format, department coding rules). Based on the one-way verification characteristic of zero-knowledge proof, the verifier (such as enterprise B) cannot reverse deduce any sensitive information through the proof data. Even if the cross-network exchange service is attacked, the attacker can only obtain meaningless proof data and cannot steal the core identity assets of the enterprise, which fully complies with the compliance requirements of sensitive data not being transferred across networks.

[0214] (2) No need to rely on trusted third-party institutions, reducing architectural complexity and trust chain risks. This invention breaks through the dependence of existing solutions on third-party institutions (such as CAs and unified identity platforms). Both parties only need to negotiate offline before deployment to agree on three core rules: zero-knowledge proof generation rules (such as Groth16 algorithm parameters), identity legitimacy conditions, and permission verification standards. No third party is required in the subsequent authentication process. This design avoids the architectural intrusion of third-party connections breaking physical isolation and eliminates the trust risk of global identity data loss due to single-point leakage of third parties. At the same time, it eliminates the generation, transmission, and signature verification of third-party credentials, reduces cross-network data interaction links, and lowers system deployment and maintenance costs, such as eliminating the need to pay third-party service fees and maintain third-party interfaces.

[0215] (3) Achieve two-way verification of identity legitimacy and permission validity, preventing permission overreach and identifier theft. This invention addresses the shortcomings of existing hash mapping schemes, which only verify the existence of identifiers but lack permission verification. When generating zero-knowledge proofs, the prover needs to bind the anonymous identifier (AID) with the business permission identifier (PID) and permission status bit (such as activated / deactivated), and generate the proof in combination with the permission compliance conditions agreed upon by both parties (such as the PID needing to match the email sending permission code and the status bit needing to be activated). During the verification phase, the verifier can simultaneously confirm that the prover is a legitimate user of the other party's enterprise (identity legitimacy) and that the prover has the current business operation permissions (permission validity), and can verify the dynamic status of permissions in real time (such as the old proof immediately becoming invalid when the local mapping table updates the status bit after the user leaves the company). This mechanism completely eliminates the risks of forging business requests after identifier theft and unauthorized users initiating cross-domain operations, and the completeness of permission verification far exceeds that of existing schemes.

[0216] (4) Lightweight and efficient, adaptable to low-latency business scenarios, ensuring smooth cross-domain interaction. This invention uses the Groth16 zero-knowledge proof algorithm, balancing proof generation efficiency and lightweight verification. The prover only needs a single local hash operation and algorithm parameter input to generate the proof, which is time-efficient and adaptable to the performance of ordinary enterprise servers; the verifier only needs 3 bilinear pairing operations to complete the verification, which is time-efficient and the amount of data transmitted across the network is only the proof data (about 200 bytes) and the business identifier (about 50 bytes), which is much smaller than the transmission volume of third-party credentials (such as X.509 certificates, about 1KB) or desensitized identity data (about 500 bytes). This feature can perfectly adapt to latency-sensitive business scenarios such as targeted email delivery and instant file exchange, avoiding business lag caused by the time-consuming credential verification and large data transmission volume of existing solutions, and ensuring the smoothness of cross-domain collaboration.

[0217] (5) It possesses high resistance to forgery and immutability, and its security strength meets enterprise-level requirements. This invention constructs a security barrier based on mathematical encryption theory, far exceeding the security level of existing static account password schemes. The generation of zero-knowledge proofs relies on real data in the local identity mapping table and shared algorithm parameters between the two parties. If an attacker does not obtain the anonymous identifier, permission identifier, and algorithm parameters of the prover, they cannot forge a valid proof. Even if an attacker steals a certain proof data, it cannot be reused in other business scenarios because the proof is bound to a specific business request (such as matching only a certain email sending request ID). At the same time, the proof data contains a generation timestamp, which can verify the timeliness during verification and prevent replay attacks of old proofs. The anti-forgery, immutability, and replay resistance of this mechanism fully meet the high security requirements of enterprise-level cross-domain authentication.

[0218] This invention optimizes five dimensions: sensitive data security, architectural independence, permission verification, business adaptation, and security strength. It not only solves the technical defects of existing solutions, but also can be implemented in physically isolated heterogeneous intranet scenarios, providing enterprises with a secure, reliable, efficient, lightweight, compliant and controllable identity trust solution for cross-domain collaboration.

[0219] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials, characterized in that, The system includes provers, cross-network exchange messengers, and verifiers; The certifier, i.e., the enterprise intranet that initiates the business request, is the core carrier for sensitive data isolation and proof generation; It integrates an identity mapping module and a zero-knowledge proof generation module, and completes the conversion of the user's real attributes to anonymous identifiers AID and permission identifiers PID, as well as the generation of zero-knowledge proofs Proof, only locally. All operations involving sensitive data do not leave the intranet boundary, blocking the risk of data leakage from the source. The verifier, i.e., the enterprise intranet that receives the business request, is the key link in verifying the validity of the proof and matching the business permissions. It performs lightweight verification of Proof through a zero-knowledge proof verification module, and at the same time verifies the requester's business permissions by combining a local permission rule table, and executes business logic only after the double verification is passed; The cross-network identity messenger, as the sole data exchange channel between the two parties, only undertakes the function of encrypted forwarding, without storing or parsing any data; the transmitted content is strictly limited to zero-knowledge proof data Proof and business identifiers, and does not contain any characteristic information that can be associated with the identity.

2. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 1, characterized in that, The prover includes the following modules: The identity mapping module is deployed on the core server on the prover's side. Its core function is to generate anonymous identifiers AID and permission identifiers PID based on the user's local unique attribute UID and according to the algorithm agreed by both parties. The entire process is completed only within the prover's intranet and does not interact with external systems. The zero-knowledge proof generation module, deployed on the core server on the prover's side, works in conjunction with the identity mapping module and the Groth16 algorithm engine to load preset proof keys. It receives the AID and PID output by the identity mapping module and combines them with the locally stored shared key. Combine the enterprise code EID with the R1CS constraint system to generate a zero-knowledge proof Proof; The identity mapping table, stored in the local database on the prover's side, is the core data carrier for associating the prover's identity with the identifier. Its core function is to store the mapping relationship between the user's real unique attribute UID, anonymous identifier AID, and permission identifier PID, and access is only granted to the identity mapping module on the prover's side.

3. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 1, characterized in that, The validator side includes the following modules: The zero-knowledge proof verification module, deployed on the core server on the verifier side, is a core component for identity trust among verifiers. Its core functions include two parts: first, loading the preset verification key. Perform a bilinear pairing operation on the received Proof to verify its mathematical validity; Second, query the compliant PID range corresponding to the current business scenario from the permission rule table on the verifier side. Verify whether the PID associated with the Proof is within the compliance range; The permission rules table is stored in the local database on the verifier's side. Its core function is to establish the correspondence between business scenarios and the scope of compliant PIDs.

4. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 1, characterized in that, The cross-network identity messenger is an encrypted transmission messenger deployed in the cross-network exchange service, acting as an encrypted transmission gateway. It is the sole data interaction channel between the prover and the verifier. Its core functions include two parts: First, it performs double encryption of transmitted data using TLS 1.3 and the Chinese national cryptographic standard SM4. The outer TLS 1.3 layer ensures the security of the cross-network transmission link, while the inner SM4 encryption layer ensures the security of the data itself and prevents man-in-the-middle attacks. Second, based on access control policies, it only allows data bound to Proof and business identifiers to pass through, and rejects any data transmission containing sensitive identity information.

5. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in any one of claims 1-4, characterized in that, The system is based on an identity and permission generation algorithm with a dual-identity binding mechanism. It designs a dual-dimensional binding mechanism of anonymous identifier (AID) and permission identifier (PID). AID is used to prove that the user is a legitimate member of the other party's enterprise, and PID is used to prove that the user has the current business operation permission. 1) Anonymous ID (AID) generation algorithm This algorithm is used to complete irreversible identity mapping; AID is an anonymous substitute for a user's identity, generated based on a shared key, unique user attributes, and a random salt value, ensuring that the real identity cannot be irreversibly deduced, and both parties can independently calculate it through unified rules without the need to synchronize the mapping table; (a) Algorithm formula (b) Parameter definition and constraints a) For shared keys Generation method: The two parties exchange public keys offline based on the ECC elliptic curve cryptography algorithm, and the public key is calculated through the ECDH protocol; Length and Update: 256-bit binary value, rotated once per quarter, new key is synchronized through offline secure medium, old key is retained for 24 hours to be compatible with unfinished business requests; Storage constraints: It is stored only in the encrypted memory of the identity mapping module on the prover side, not written to disk, and automatically destroyed after the process ends to prevent local leakage; b) EID is a unique code for the enterprise. Format: 3-character ASCII string, negotiated offline, with no business meaning, used only to distinguish enterprise identity; Constraints: Do not include sensitive features; used only as fixed parameters in the identity legitimacy constraints of zero-knowledge proofs. c) UID is a unique attribute of the user locally. Definition: A non-sensitive unique identifier for the prover-side user in the local system, which does not contain sensitive information; Constraints: It can only circulate within the intranet on the certifier's side, and cannot be transmitted across networks. It must also meet the local global uniqueness requirement, which is guaranteed by the HR system or user management system of Company A. d) Salt is a random salt value. Generation method: Generated in real time by the hardware random number generator called by the identity mapping module on the prover side, to avoid the same UID generating the same AID; Length: 128-bit binary value, regenerated each time an AID is generated, and stored in a local identity mapping table bound to the AID for reuse in subsequent business retransmissions; (c) Security verification Based on the collision resistance and one-wayness of SHA-256, even if an attacker obtains the AID and some parameters, they cannot reverse engineer it. UID core information; combined with the randomness of Salt, it avoids the risk of rainbow table attacks, and the same UID generates different AIDs at different times; 2) PID encoding rules for permission identifiers (a) Encoding format It uses a fixed 16-bit binary length to facilitate zero-knowledge proof constraint calculation; the high 8 bits are the business type field, and the low 8 bits are the permission level field; (b) Generation and maintenance mechanism a) Generation logic The certifier-side business system automatically assigns PIDs based on user roles; b) Dynamic updates When user permissions change or new business scenarios are added, the verifier-side administrator updates the PID in the local identity mapping table through the permission management backend. The update takes effect quickly without notifying the verifier-side. The verifier-side dynamically verifies the PID compliance through the permission rule table. c) Failure Mechanism When a user leaves the company or is frozen, the verifier will set the PID's permission level field to 00. Even if the old AID is stolen, the verifier will reject the request because the PID is non-compliant.

6. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 5, characterized in that, This system employs a lightweight and efficient zero-knowledge proof algorithm for identity and authorization verification, selecting the Groth16 algorithm as the core engine for zero-knowledge proof, specifically including: (a) The basic elliptic curve selected is the BN254 curve. (b) Generation of public parameter PK a) Generation method Both parties jointly generate the key offline to avoid third-party intervention; Company A generates a random private key. , Company B generates a random private key. , After exchanging public keys through a secure medium, they jointly calculate the public parameter PK, which contains the proof key. With verification key ; b) Parameter content Generated and stored by the prover, containing , , Equal elliptic curve points are used to generate Proof, where G and H are generators of the BN254 curve; It only contains encrypted secret parameter traces, which attackers cannot extract from... Reverse push , To ensure the security of Company A's confidential parameters; Generated and stored by the validator, containing , , Equal elliptic curve points are used to verify the proof; "Used only to verify the validity of Proof", and does not contain , ,even though Even if stolen, Proof cannot be forged; c) Offline parameter calibration because and Generated separately by A and B, each calibration parameter requires exchange via offline secure media; Company A will... The public key component is sent to Enterprise B, and Enterprise B verifies it. Check whether it conforms to the agreed curve format, and confirm that the BN254 curve parameters and base point G / H used by both parties are completely consistent to avoid subsequent verification failures due to parameter mismatch; d) Safety constraints The PK parameter is generated only once, during the initialization phase; if Rotation does not require regenerating the PK; only the constraints of the zero-knowledge proof need to be updated. (c) Design of constraint system R1CS To achieve dual verification of identity legitimacy and authorization validity, business rules are transformed into mathematical constraints of the Rank-1 Constraint System (R1CS), ensuring that provers can only generate Proofs that conform to the rules and cannot forge authorizations; the core constraints are as follows: a) Constraints on the legitimacy of identity Verify that the generated AID conforms to the algorithm agreed upon by both parties, namely: By decomposing SHA-256 operations into linear operations and nonlinear gate circuits supported by R1CS, the constraints are ensured to be verifiable. b) Permission validity constraints Verify that the PID is within the compliance range of the current business scenario, that is: For the validator-side permission rule table, specify the compliant PID for the current business scenario; c) Timestamp constraints To prevent Proof from being replay-attacked, i.e.: Current_Time is the current time on the verifier's side, and Proof_Time is the timestamp when the prover generated the Proof. If the valid duration of the Proof expires, the verification will fail.

7. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 5, characterized in that, This system employs a lightweight and efficient zero-knowledge proof algorithm for identity and permission verification. The core steps of proof generation and verification include: (a) Proof of the generation process, which is as follows: a) Parameter input stage The identity mapping module receives requests from the business system, inputs the user's UID, outputs the AID, PID, and Salt, and reads data from local storage. EID; b) Constraint satisfaction check The proof generation module first verifies the validity of the PID locally. If it is invalid, it directly returns insufficient permissions and does not generate a Proof, thus avoiding invalid cross-network transmission. c) R1CS instantiation AID, PID, Substitute EID, Salt, and the current timestamp Proof_Time into the R1CS constraint system to generate an R1CS instance, including the input vector x, the intermediate variable vector w, and the output vector y. d) Proof generation Call the Groth16 algorithm engine and load... Input an R1CS instance to generate Proof is the core data that company A uses to prove to company B that "I have a legitimate identity and authorization," and its generation process is entirely based on local parameters. (AID, PID), without disclosing any sensitive information; e) Output results The proof generation module outputs a Proof and its associated business identifier; the business identifier is a globally unique request ID used by the verifier to associate business data. (b) The verification process includes: a) Data reception and parsing The verification module receives Proof and service identifier through the cross-network exchange platform, and parses the service identifier to obtain the current service scenario; b) Compliant PID Query Query the local permission rules table for the current business scenario. ; c) Proof format verification Verify that the format of the Proof conforms to the specifications of BN254 curve points. If the format is incorrect, reject it directly to avoid invalid calculations. d) Bilinear paired verification Call the Groth16 algorithm engine and load... Perform the following pairing operation: e is the bilinear pairing function of the BN254 curve. If the equation holds, then the mathematical validity of Proof is passed. e) Business rule verification Verify the validity of the timestamp and the compliance of the PID. If both pass, the overall verification passes. f) Results Feedback If the verification passes, the system will return permission to execute the business and transmit the business identifier; if the verification fails, the system will return a verification failure message.

8. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 1, characterized in that, The steps for generating Proof are as follows: Step S11: Prepare input parameters ① Business Data: AID and PID obtained by Enterprise A from the identity mapping module; these two data points are the information that needs to be proven. ② Blinding Parameters: Enterprise A randomly generates two temporary parameters. Its function is to hide the true value of business data; Step S12: Calculate the three components of Proof Assemble Proof Each component is related to the previously generated... Secret parameters ( , ), and strong correlation between business data; Corresponding proof of identity, , Prove that Company A has a valid AID, and that it is based on Generated; Proof of the validity of corresponding permissions. , Prove that Company A has a valid PID, and that it is based on Generated; The relationship between the corresponding blinding parameters and constraints, , It is a connection and This bridge ensures the joint validity of AID and PID, while also allowing the blinding parameters to be offset during verification.

9. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 8, characterized in that, During the pre-initialization phase, the system performs the following steps: 1) Shared key generation and distribution Both parties used the ECC algorithm to negotiate and generate a shared key offline. ; The specific process is as follows: Company A generates a private key. With public key Company B generates a private key. With public key After exchanging public keys via encrypted USB drives, both parties calculated the same public key. ; The key management system (KMS) is stored locally on both parties' premises, and an access whitelist is set up to allow only the identity mapping module and the zero-knowledge proof generation / verification module to call it. At the same time, the key rotation cycle is agreed upon. 2) Basic Identification Rules Enterprise ID (EID): A unique enterprise ID agreed upon offline by both parties, used only for identification generation and does not contain sensitive semantic information; Anonymous ID (AID) generation formula: explicit Salt is a 128-bit random number generated in real time by the identity mapping module to prevent different users from generating the same AID. Permission Identifier (PID) Encoding Rules: The PID is defined as a 16-bit binary number, with the high 8 bits representing the service type and the low 8 bits representing the permission level. A coding lookup table for service type and permission level is synchronized to ensure that both parties interpret the PID in a consistent manner. 3) Zero-knowledge proof parameter configuration Both parties jointly generate the common parameter PK using the Groth16 algorithm, including the proof key. and verification key The parameter generation process is completed offline, via secure medium exchange, and the prover only retains the data. Used to generate proofs, the verifier only retains the data. For verification purposes, the algorithm curve used is BN254. 4) Initialize the permission rule table. The verifier configures the permission rule table in the local database, which stores the mapping relationship between business scenarios and allowed PID ranges. This table supports dynamic updates, and the verifier administrator can adjust the compliant PID range through the administrator workstation.

10. The two-way anonymous identity mutual trust system based on zero-knowledge trusted identity and authorization credentials as described in claim 8, characterized in that, The system performs the following steps during the business execution phase: 1) Initiate a business request Triggering condition: User A of Enterprise A enters recipient information, email subject and body content in an email client and clicks the send button; Business system operation: Enterprise A's application server generates a unique business identifier to mark this email request, and at the same time extracts the sender's local unique identifier. The business type is passed to the identity mapping module, which requests the generation of an associated identifier. 2) Local identity mapping Input parameter: Sender's local unique identifier Business type; Core processing: The identity mapping module queries the local database. The corresponding basic information is also generated in real time, along with a 128-bit random salt. Substituting into the AID generation formula, the sender's anonymous identifier is calculated. Based on Company A's user permission system, query In cross-domain email sending scenarios, permission levels are defined, and permission identifiers are generated. ; 3) Generate zero-knowledge proofs Input parameters: , Enterprise A Code Business identifier; Core processing: Enterprise A's business system passes the above parameters to the zero-knowledge proof generation module, which loads the locally stored... ; The input parameters are compiled into an R1CS constraint system to construct identity validity constraints and authorization validity constraints; the Groth16 algorithm is executed to randomly generate blinded parameters. The calculation proves it. ,in Points on the elliptic curve of curve BN254; Output: Proof of the bound business identifier, and the email content is encrypted using the national cryptographic SM4 algorithm to form the ciphertext of the email; 4) Cross-network transmission Transmitted content: Proof + business identifier + encrypted email, with no sensitive identity information; Security measures: Enterprise A's business system sends the transmitted content to the encrypted transmission messenger of the cross-network exchange service. The encrypted transmission first establishes a secure transmission link through the TLS 1.3 protocol to ensure the security of the link layer. The transmitted content is encrypted again using the national cryptographic SM4 algorithm, forming a dual protection of link encryption and content encryption to prevent man-in-the-middle attacks or data theft; the access control module of the cross-network exchange service verifies the type of transmitted content, confirms that it only contains Proof, business identifier, and ciphertext, records the transmission log through the log audit module, and then forwards the content to the enterprise B intranet; 5) Proof verification and permission check Input parameters: Received Proof, service identifier, enterprise A code ; Core Processing: After receiving data, the encrypted messenger of Enterprise B first decrypts it using TLS 1.3 and SM4 to extract the Proof, business identifier, and ciphertext. The Proof and business identifier are then passed to the zero-knowledge proof verification module. The verification module loads the locally stored... Perform bilinear pairing operations to verify the mathematical validity of Proof. If the condition is met, then the Proof is valid; the verification module queries the local permission rule table for the cross-domain email receiving scenario. Parsing through Proof ,check Whether or not match; Output: If Proof is valid and If the match is found, return "verification passed"; otherwise, return "verification failed" without revealing the specific reason for the failure. 6) Execution of business and feedback of results Validation Success Scenario: The zero-knowledge proof validation module sends a validation success notification to Enterprise B's email business system. The system then determines the recipient based on the email address. The system queries the local email database and delivers the decrypted email to the corresponding email address. Enterprise B's business system generates a delivery success response and sends it back to Enterprise A via cross-network exchange service. After receiving the response, Enterprise A's business system displays "sent successfully" in the user's workstation's email client, and the process ends. Verification failure scenario: The zero-knowledge proof verification module returns a verification failure to Enterprise B's business system, and the system directly rejects the email delivery; The failure was reported to Company A through a cross-network exchange platform. Company A's email client displayed "Recipient authentication failed. Please verify the information and try again." This did not disclose the details of the failure and prevented attackers from probing the system rules.

Images