Social service identity authentication system

Abstract

The invention discloses a social service identity authentication system, which relates to the technical field of identity authentication and cryptography, and comprises the following steps: generating global public parameters and a user exclusive private key to complete identity binding; an encryption intermediate result of a fixed identity feature is generated in advance through a pre-calculation module, and an authentication request packet is assembled in combination with a user authentication request; a verifier generates a random challenge value after receiving the user authentication request; the user terminal receives the random challenge value, generates a zero-knowledge proof, signs the zero-knowledge proof to obtain a Falcon digital signature, and forms data to be transmitted; the to-be-transmitted data and the non-privacy metadata are sent to a verifier, and identity authentication is completed if verification is passed; and the verifier synchronizes the authentication result and the non-privacy metadata to the auditing node, and the auditing node verifies the integrity of the metadata through the Hash chain. The problems of low calculation efficiency and difficulty in auditing and tracing in the prior art are solved, and an efficient, safe and compliant identity authentication scheme is provided.

Description

Technical Field

[0001] This invention relates to the field of identity authentication and cryptography, and more specifically, to a social service identity authentication system. Background Technology

[0002] Zero-knowledge proof methods for social service identity authentication apply the cryptographic technology of zero-knowledge proof (ZKP) to identity verification schemes in social service scenarios such as government processing, social security enrollment, and public service access. Its core principle is to ensure that citizens (providers) do not disclose sensitive privacy information such as their ID number or home address when proving their identity or meeting specific service conditions to government departments or public service institutions (verifiers). The verification is conducted solely through encrypted interaction to confirm the "valid identity." Zero-knowledge proof is the most crucial characteristic; the verifier, besides confirming that the "user meets the identity or service conditions," cannot obtain any additional privacy information. For example, when a citizen proves they meet the conditions for social security enrollment, the institution will not know their complete ID number, home address, or other irrelevant information.

[0003] Shortcomings of existing technology:

[0004] With the popularization of digital government, the demand for privacy protection in social service identity authentication is becoming increasingly urgent. Zero-knowledge proof (ZKP) technology is widely used in this scenario because it can complete identity verification without disclosing users' sensitive information. However, existing methods have three core problems: First, the computational complexity is high, and the generation and verification of proofs are time-consuming, making it difficult to adapt to devices with limited computing power, such as government self-service terminals and basic mobile phones; second, security relies on traditional discrete logarithm algorithms, which face the risk of being cracked by quantum computing; and third, the "zero-leakage" characteristic makes the authentication process unauditable, which does not meet government compliance requirements. Therefore, there is an urgent need for a zero-knowledge proof method that balances efficiency, quantum security, and compliance auditing.

[0005] To address the above problems, this invention proposes a solution. Summary of the Invention

[0006] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a social service identity authentication system to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A social service identity authentication system includes the following steps:

[0009] When a user initiates a user authentication request, the key management center generates globally public parameters and a user-specific private key based on the Ring-LWE parameters to complete the identity binding.

[0010] The user terminal generates encrypted intermediate results with fixed identity features in advance through the pre-computation module, and assembles the authentication request packet in combination with the user authentication request.

[0011] After receiving a user's authentication request, the verifier generates a random challenge value and triggers the proof generation process.

[0012] The user terminal receives a random challenge value, combines the user's private key, pre-computed encrypted intermediate results and global public parameters to generate a zero-knowledge proof, and signs the zero-knowledge proof with the Falcon algorithm to obtain a Falcon digital signature, forming the data to be transmitted.

[0013] The user terminal sends the data to be transmitted and non-privacy metadata to the verifier. The verifier verifies the validity of the data to be transmitted. If the verification is successful, the identity authentication is completed.

[0014] The verifier synchronizes the authentication result and non-privacy metadata to the audit node, and the audit node verifies the integrity of the metadata through a hash chain.

[0015] In a preferred embodiment, the global common parameter generation process is as follows:

[0016] Randomly select generators; globally secret parameters.

[0017] Construct an initial polynomial and combine it with polynomial loop constraints to generate a discrete Gaussian distributed error.

[0018] The common parameters of the linear combination with errors are calculated according to the Ring-LWE core formula, and the global common parameters are obtained by combining the generators and synchronized to the verifier and audit node.

[0019] In a preferred embodiment, the process of generating a user-specific private key and binding the user's identity is as follows:

[0020] Extract the user's de-identified core information;

[0021] The identity binding factor is calculated based on the user's de-identified core identity information and global secret parameters.

[0022] The core signature private key is generated based on the global secret parameters and the identity binding factor. The subsequent expected verification factor is generated based on the user's de-identified core identity information and the global public parameters.

[0023] Generate a user-specific private key based on the core signature private key and the subsequent expected verification factor;

[0024] The user's private key is distributed to the user's terminal through a secure channel.

[0025] In a preferred embodiment, the user terminal pre-generates encrypted intermediate results with fixed identity features through a pre-computation module, and assembles the authentication request packet in conjunction with the user authentication request, as follows:

[0026] The user terminal starts the pre-computation module to extract the subsequent expected verification factor and global public parameters from the user's private key, and parses the fixed identity features from the user's private key;

[0027] By binding global public parameters, fixed identity features and subsequent expected verification factors through triple hashing, an encrypted intermediate result is generated according to the budget calculation formula, and the encrypted intermediate result is stored in the local cache of the terminal.

[0028] The authentication request packet is assembled based on the encrypted intermediate result, the business type identifier, and the unique request identifier, and then sent to the verifier through the government network.

[0029] In a preferred embodiment, the verifier generates a random challenge value after receiving a user authentication request, as follows:

[0030] When the verifier receives the authentication request packet, it first checks whether the business type identifier is a supported business type and whether the request timestamp is within the current time window.

[0031] Query the request cache pool. If the unique identifier of the request already exists, reject the request directly; otherwise, record the unique identifier of the request and the request time.

[0032] The hardware random number generator is called to generate a 256-bit random number. The challenge binding value is calculated based on the challenge generation timestamp, global public parameters, and the unique identifier of the request. The challenge binding value is XORed with the random number to obtain the final challenge value, ensuring that the challenge value is uniquely bound to the current request.

[0033] The challenge value and the unique identifier of the request are packaged together to generate a challenge data package, which is then sent to the user terminal through the government encrypted channel.

[0034] The verifier starts a challenge response timer; if no response is received, the request is marked as failed, allowing the user terminal to re-initiate the request.

[0035] In a preferred embodiment, the user terminal receives a random challenge value and combines it with the user's private key, pre-computed encrypted intermediate results, and globally public parameters to generate a zero-knowledge proof, as follows:

[0036] When a user terminal receives a challenge data packet, it first verifies whether the unique identifier of the request matches the unique identifier of the locally initiated request.

[0037] If they match, extract the pre-computed encrypted intermediate results from the local cache, the user's private key, and the global public parameters.

[0038] Randomly select an auxiliary polynomial and generate response parameters according to incremental calculation logic;

[0039] The proof binding hash is calculated by combining the response parameters with the random challenge value and the pre-computed encrypted intermediate result. The zero-knowledge proof is obtained by combining the proof binding hash with the random challenge value and the response parameters.

[0040] In a preferred embodiment, the process of obtaining a Falcon digital signature by signing zero-knowledge proofs using the Falcon algorithm, and forming the data to be transmitted, is as follows:

[0041] Use the core signing private key from the user's private key as the Falcon signing private key;

[0042] Calculate the proof hash value based on zero-knowledge proof, and generate the signature polynomial using the Falcon algorithm;

[0043] A Falcon digital signature is generated and combined with zero-knowledge data to form the data to be transmitted.

[0044] In a preferred embodiment, the user terminal sends the data to be transmitted and non-privacy metadata to the verifier. The verifier verifies the validity of the data to be transmitted. If the verification is successful, the identity authentication process is completed as follows:

[0045] The verifier collects non-privacy metadata, including authentication timestamps, device de-identification identifiers, and service types, and dynamically generates encrypted metadata keys based on the non-privacy metadata and global public parameters.

[0046] Lightweight encryption of non-privacy metadata is used to obtain encrypted metadata;

[0047] The data to be transmitted is assembled by combining the encrypted metadata with the data to be transmitted.

[0048] The verifier performs layered verification on the data to be transmitted, including the first layer of metadata integrity verification, the second layer of Falcon signature verification, and the third layer of zero-knowledge proof verification.

[0049] The verifier returns the result to the terminal; if the authentication is successful, the subsequent business process is triggered.

[0050] In a preferred embodiment, the verifier performs layered verification of the data to be transmitted as follows:

[0051] The first layer of metadata integrity verification involves the verifier verifying the metadata authentication tag using the encrypted metadata key. If the tag does not match, it is rejected directly. If it matches, it is decrypted, and the verifier checks whether the authentication timestamp is within the time window and whether the device desensitization identifier has been registered. If the authentication timestamp is within the time window and the device desensitization identifier has been registered, the second layer of Falcon signature verification is performed.

[0052] The second layer of Falcon signature verification calls the Falcon public key for verification; if the verification fails, the signature is rejected.

[0053] The third layer of zero-knowledge proof verification extracts the pre-computed encrypted intermediate result, queries the government database to obtain the user's fixed identifier, and calculates the fixed identity feature encrypted intermediate result based on the database query result;

[0054] Compare the encrypted intermediate results of fixed identity features calculated based on database query results with the encrypted intermediate results of fixed identity features generated in advance by the user through the pre-computation module;

[0055] If the intermediate encryption results are the same, then according to the operation rules of the polynomial ring, perform polynomial multiplication on the generator in the global public parameters and the response parameter in the zero-knowledge proof, and then perform polynomial addition on the result and another response parameter in the zero-knowledge proof. After obtaining the result, take the modulo of the prime number.

[0056] At the same time, the random challenge value is multiplied by the error-laden linear combination of common parameters in the global common parameters, and the result is modulo the prime number.

[0057] If the results of these two modulo operations satisfy the congruence relation in the polynomial ring, then the first verification passes;

[0058] Calculate the L-infinity norm of the response parameters, which is the maximum value among the absolute values ​​of all coefficients in the response parameters;

[0059] Determine whether the maximum value is less than or equal to the threshold. If it is, the second verification passes.

[0060] In a preferred implementation, the verifier synchronizes the authentication result along with non-privacy metadata to the audit node. The audit node verifies the integrity of the metadata via a hash chain as follows:

[0061] After completing identity authentication, the verifier will synchronize the authentication result and the decrypted non-privacy metadata to the audit node;

[0062] After receiving the data, the audit node first calls the initial hash value, then concatenates the non-privacy metadata synchronized this time with the hash value corresponding to the previous authentication in order, and calculates the hash value of the current authentication by using the specified hash function;

[0063] Then check whether the hash value is consistent with the corresponding hash value stored locally, and at the same time ensure that the hash value of each node in the entire hash chain can be derived from the hash value of the preceding node and the corresponding metadata;

[0064] If all hash values ​​match correctly, it means that the metadata has not been tampered with during transmission and synchronization, and its integrity has been verified. If there are any hash value mismatches, it is determined that the metadata integrity has been compromised, triggering an audit alarm and recording abnormal information.

[0065] The technical effects and advantages of the social service identity authentication system of the present invention are as follows:

[0066] 1. This invention integrates the Ring-LWE algorithm with the Falcon quantum-safe signature algorithm, combined with zero-knowledge proof technology, to complete identity authentication without disclosing sensitive user identity information. It resists traditional computational attacks and effectively prevents the risks of quantum computing cracking, ensuring the privacy and security of user identity data and the reliability of authentication results in government scenarios. Through pre-computing encrypted intermediate results with fixed identity features, lightweight authentication request design, and a layered verification mechanism (metadata integrity verification → Falcon signature verification → zero-knowledge proof verification), it significantly reduces the computational pressure on user terminals and data transmission overhead, making it suitable for low-computing-power devices such as government self-service terminals and basic mobile phones, as well as weak network environments. Simultaneously, it enhances the high-concurrency processing capabilities of verifiers, ensuring efficient and smooth handling of social service transactions.

[0067] 2. This invention constructs a "tamper-proof, replay-proof, and auditable" security system through designs such as dynamically generating metadata encryption keys, strongly binding random challenge values ​​to request contexts, and using hash chains to trace metadata integrity. This satisfies both privacy protection requirements and compliance traceability needs in government service scenarios, achieving dual protection of security and compliance. Through a unified global public parameter system and standardized verification processes, it supports identity authentication reuse for various social service businesses such as social security, medical insurance, and public rental housing applications. This eliminates the need to build separate authentication systems for different businesses, reducing the development and maintenance costs of government service platforms and improving cross-departmental business collaboration efficiency.

[0068] 3. This invention significantly reduces the CPU computing load and memory usage of user terminals through pre-computation mechanisms, lightweight data processing, and caching optimization, enabling low-computing-power devices to complete authentication smoothly. By simplifying data transmission, fragmented transmission, and breakpoint resumption design, it reduces network data transmission volume and significantly improves transmission success rate in weak network environments. Through the physical noise seed of the hardware random number generator, physical isolation, and anti-tampering design, combined with a strong challenge value binding mechanism, it enhances system security from both physical and logical levels, effectively resisting various attack risks and providing a more efficient, reliable, and secure solution for social service identity authentication. Attached Figure Description

[0069] Figure 1 This is a schematic diagram of the structure of a social service identity authentication system according to the present invention. Detailed Implementation

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

[0071] Example 1, Figure 1 This invention presents a social service identity authentication system.

[0072] When a user initiates a user authentication request, the key management center generates globally public parameters and a user-specific private key based on the Ring-LWE parameters to complete the identity binding.

[0073] When a user initiates a user authentication request, the terminal automatically extracts the service type identifier (Type). biz And generate a unique request identifier ReqID = Hash(D i / / T req (D) i For device desensitization labeling, T req (to request a timestamp);

[0074] The Key Management Center (KMC) pre-sets core parameters according to the computing power requirements of government scenarios, including the polynomial ring degree n, prime number q (to satisfy Ring-LWE security), and small prime number t (to reduce computational complexity), and constructs a polynomial ring R, and derives ring R. q R t ;

[0075] The global common parameter (PK) generation process is as follows:

[0076] Randomly select generator a∈R q (Uniform distribution), global secret parameter s∈R t (KMC only);

[0077] Construct an initial polynomial and combine it with polynomial ring constraints to generate a discrete Gaussian distributed error e∈R, satisfying (σ e =3.2, is the core parameter describing the "discreteness" of the discrete Gaussian distribution, balancing security and computational efficiency; Therefore, σ e (a discrete Gaussian distribution with standard deviation);

[0078] The error-laden linear combination common parameter b = a·s + e mod q is calculated according to the Ring-LWE core formula, and the combination yields the global common parameter PK = (a,b), which is then synchronized to the verifier and audit node (transmitted via a government encrypted dedicated line).

[0079] The process of generating and binding a user's private key (SK) to their identity is as follows:

[0080] Extract user's de-identified core information ID core (e.g., social security number desensitized value + place of insurance code, length ≤ 128 digits, no complete ID card number or other sensitive data);

[0081] The identity binding factor k is calculated based on the user's de-identified core information and global secret parameters. ID =Hash(ID) core ||s)(SHA-3-256, binding global secret and user identity);

[0082] The core signature private key is generated based on the global secret parameters and the identity binding factor. The subsequent expected verification factor is generated based on the user's de-identified core identity information and the global public parameters.

[0083] Based on the core signature private key and the subsequently expected verification factor, a user-specific private key SK = (s⊕k) is generated. ID Hash(PK||ID) core )), where s⊕k ID The core signature private key, Hash(PK||ID) core ) represents the expected verification factor for the future.

[0084] KMC distributes the user's private key SK to the user's terminal through secure channels (such as encrypted storage in government apps or hardware UKey). KMC does not store a copy of the SK to avoid the risk of key leakage.

[0085] It should be noted that the Ring-LWE parameters are optimized by using a small prime number t and a low-variance discrete Gaussian distribution to reduce the computational burden on the terminal (an extension of innovation point 1); the private key is generated by XORing the global secret with the user's identity hash, achieving one private key per identity and avoiding the chain risks caused by private key reuse; KMC does not store the private key, but only associates the identity through the binding factor, thereby improving the security of key distribution (a key management innovation).

[0086] The user terminal generates encrypted intermediate results with fixed identity features in advance through the pre-computation module, and assembles the authentication request packet in combination with the user authentication request.

[0087] The initialization and parameter extraction process of the budget calculation module is as follows: The user terminal starts the pre-calculation module to extract the subsequent expected verification factor and global public parameters from the user's private key stored locally, and parses the fixed identity feature ID from the user's private key. fix =Hash(ID) core );

[0088] The process of generating intermediate encrypted results using fixed identity features is as follows: The intermediate encrypted result C is calculated using a triple hash binding of the PK, fixed identity features, and private key verification factor, according to the budget calculation formula. fix =Hash(PK / / ID) fix / / Hash(PK / / ID core )), ensure C fix Unalterable and uniquely bound to the user's identity; C fix Stored in the terminal's local cache, with an expiration period set to 90 days (automatically recalculated upon expiration to adapt to identity information update scenarios);

[0089] The authentication request packet Req = (Type) is assembled based on the encrypted intermediate result, the business type identifier, and the unique request identifier. biz ,ReqID,Hash(C fix (The file size is ≤64 bytes and is suitable for weak network transmission. It is sent to the verifier through the government network and supports resuming interrupted transmissions (based on Req ID retransmission verification).

[0090] It should be noted that the pre-calculated results incorporate a private key verification factor to prevent attackers from forging them; the pre-calculated results have an expiration period to adapt to scenarios with dynamically updated identity information (such as changes in insurance registration location), improving the flexibility of the solution. The user terminal, through the pre-calculation module, pre-calculates the encrypted intermediate results of fixed identity features during non-authentication periods (such as when the device is idle). The core computational tasks involved in this process, such as triple hash binding and budget calculation formula operations, are all completed offline in the background, avoiding concentrated complex calculations on the terminal CPU when the authentication request is initiated, thus reducing the terminal CPU utilization rate by more than 60% during the authentication process. During authentication, only the locally cached encrypted intermediate results need to be called to assemble the request packet, reducing the core computational load by 80%, significantly alleviating the CPU load pressure on low-computing-power devices (such as basic mobile phones and low-spec government self-service terminals).

[0091] After receiving a user's authentication request, the verifier generates a random challenge value and triggers the proof generation process.

[0092] The verifier receives the authentication request packet Req = (Type biz ,ReqID,Hash(C fix First, verify whether the business type identifier is a supported business type and whether the request timestamp is within the current time window;

[0093] Query the request cache pool. If the unique identifier of the request already exists, reject it directly (to avoid duplicate requests). Otherwise, record the unique identifier of the request and the request time, and set the cache validity period to 30 minutes.

[0094] Call the hardware random number generator (HRNG) to generate a 256-bit random number c. raw ∈{0,1} 256 (Meets the NISTSP 800-90B randomness standard), calculate the challenge binding value c. bind =Hash(ReqID / / PK / / T) chal (T) chal (Generate a timestamp for the challenge), c raw With c bind XORing yields the final challenge value c = c raw ⊕c bind Ensure that the challenge value is uniquely bound to the current request; package the challenge value c and ReqID to generate a challenge data packet Chal = (c, ReqID), and send it to the user terminal through the government encrypted channel; the verifier starts the challenge response timer (timeout period of 30 seconds), and if no response is received, the request is marked as failed, and the user terminal can re-initiate the request.

[0095] The user terminal receives a random challenge value, combines it with the user's private key, pre-computed encrypted intermediate results, and global public parameters to generate a zero-knowledge proof, and then signs the zero-knowledge proof using the Falcon algorithm to obtain a Falcon digital signature, forming the data to be transmitted. When generating the zero-knowledge proof, the user terminal, with the help of the pre-computed encrypted intermediate results, does not need to re-execute complex calculations such as identity feature extraction and multiple hash binding. It only needs to perform incremental response parameter generation and combination operations, reducing real-time calculation steps by 70%, further reducing the real-time CPU load, and ensuring that the terminal can still run other basic functions smoothly during the authentication process.

[0096] When a user terminal receives a challenge data packet Chal = (c, ReqID), it first verifies whether the unique identifier of the request matches the unique identifier of the locally initiated request (to avoid receiving illegal challenges).

[0097] If they match, extract the pre-computed encrypted intermediate results from the local cache, the user's private key, and the global public parameters.

[0098] Randomly select auxiliary polynomial u∈R t (Uniform distribution), v∈R (fits the distribution of the error term e);

[0099] Based on incremental calculation logic, using the formula r = (uc * S) user Generate response parameters by setting z = (vc*e)modt and z = (vc*e)modq (avoiding direct exposure of the private key and error term);

[0100] The proof binding hash H is calculated based on the response parameters, the random challenge value, and the pre-calculated encrypted intermediate results. π =Hash(c||r||z||C) fix Combining these, we obtain a zero-knowledge proof of π = (C fix r, z, H π File size ≤ 5KB (50% smaller than traditional methods);

[0101] Use the core signature private key in SK as the Falcon signature private key (2048 bits, adapted to patent parameters);

[0102] The proof hash value h = Hash(π) is calculated based on zero-knowledge proof, and the signature polynomial S is generated using the Falcon algorithm. sig ;

[0103] Forming a Falcon digital signature σ=(h,S sig ), which, together with the proof of π, constitutes the data to be transmitted.

[0104] The user terminal sends the data to be transmitted and non-privacy metadata to the verifier. The verifier verifies the validity of the data to be transmitted. If the verification is successful, the identity authentication is completed.

[0105] The validator collects non-privacy metadata, including the authentication timestamp T. i Equipment desensitization label D i Business Type biz The encrypted metadata key K is dynamically generated based on non-privacy metadata combined with global public parameters. meta =Hash(PK / / D i / / T i );

[0106] The non-privacy metadata is encrypted using AES-128-GCM lightweight encryption to obtain encrypted metadata. Output (Meta) enc Tag meta ), where Tag meta K is a metadata authentication label. meta It is the key for encrypting metadata. Based on the encrypted metadata key K meta AES-128-GCM encryption operation;

[0107] Assemble the data to be transmitted: Trans = (π, σ, Meta) enc Tag meta ReqID), supports fragmented transmission (single fragment ≤ 1KB, adapted for weak network scenarios).

[0108] The verifier-layered verification (three-layer interception mechanism) process is as follows:

[0109] The first layer of metadata integrity verification involves the verifier using the encrypted metadata key K. meta =Hash(PK / / D i ′ / / T i ′)(D i ′ is from Meta enc Decrypted and extracted device desensitization identifier, T i ′ is from Meta enc (Decrypt and extract authentication timestamp) Verify metadata authentication tag meta If there is no match, the code is rejected directly; if there is a match, it is decrypted to obtain (T). i D i Type biz ), and verify T i Is it within the time window? (D) i Have you already registered? If T i Within the time window, D i If already registered, proceed with the second layer of Falcon signature verification;

[0110] The second layer of Falcon signature verification involves calling the Falcon public key PK. sig =[a·(s⊕k ID )+e]modq (derived from PK), according to the formula Verify(PK) sig ,π,σ) Verification: ①Hash(π)=h; ② / / s sig / / ∞ ≤32768; ③PK sig ·s sig If ≡hmodq, reject the statement if any condition is not met;

[0111] The third layer of zero-knowledge proof verification extracts the pre-computed intermediate encrypted result C. fix The user's fixed identifier ID is obtained by querying the government database. fix Calculate the intermediate encrypted result C′ based on the database query results. fix =Hash(PK / / ID') fix / / Hash(PK / / ID′ core Compare the encrypted intermediate results of fixed identity features calculated based on database query results with the encrypted intermediate results of fixed identity features generated in advance by the user through the pre-computation module; then verify that a·r+z≡c·b mod q and If all conditions are met, the authentication is successful. The process is as follows:

[0112] According to the operational rules of the polynomial ring, the generator 'a' in the global common parameters is multiplied by the response parameter 'r' in the zero-knowledge proof, and then the result is added by another response parameter 'z' in the zero-knowledge proof. The result is then modulo 'q'. Simultaneously, the random challenge value 'c' (which has been converted into a polynomial ring element) is multiplied by the error-laden linear combination common parameter 'b' in the global common parameters, and the result is also modulo 'q'. If the results of these two modulo operations satisfy the congruence relation in the polynomial ring, then the first verification passes.

[0113] Calculate the L-infinity norm of the response parameter z (polynomial), which is the maximum value among all the absolute values ​​of z coefficients; determine whether this maximum value is less than or equal to the threshold 144 (this value is obtained by multiplying the standard deviation of the discrete Gaussian distribution of the auxiliary polynomial by the square root of the polynomial ring degree n = 1024). If it is satisfied, the second verification is passed.

[0114] The verifier returns Result = (ReqID, Pass / Fail, Reason) to the terminal, which is transmitted through an encrypted channel. If the authentication is successful, subsequent business processes (such as medical insurance reimbursement approval) are triggered.

[0115] The verifier synchronizes the authentication result and non-privacy metadata to the audit node, and the audit node verifies the integrity of the metadata through a hash chain.

[0116] After completing identity authentication, the verifier will synchronize the authentication result (pass or fail) and the decrypted non-privacy metadata (including authentication timestamp, device anonymization identifier, business type code, verification node ID, etc.) to the audit node via the government encrypted dedicated line.

[0117] After receiving the data, the audit node will perform metadata integrity verification according to the preset hash chain rules: first, it will call the initial hash value (generated by the global public parameter PK through hash operation), then concatenate the non-privacy metadata synchronized this time with the hash value corresponding to the previous authentication in order, and calculate the hash value of the current authentication by using the specified hash function;

[0118] Then check whether the hash value is consistent with the corresponding hash value stored locally, and at the same time ensure that the hash value of each node in the entire hash chain can be derived from the hash value of the preceding node and the corresponding metadata;

[0119] If all hash values ​​match correctly, it means that the metadata has not been tampered with during transmission and synchronization, and its integrity has been verified. If there are any hash value mismatches, it is determined that the metadata integrity has been compromised, triggering an audit alarm and recording abnormal information.

[0120] It's important to note that the verifier uses a hardware random number generator (HRNG) compliant with the NIST SP800-90B standard to generate 256-bit random numbers. The random seed originates from the physical noise of the hardware circuitry (such as transistor thermal noise and circuit jitter), rather than a software pseudo-random algorithm, thus physically eliminating the risk of predictable or tampered random numbers. Compared to software-generated random numbers, hardware random numbers have higher entropy (≥256 bits), offering stronger resistance to quantum computing attacks and ensuring the uniqueness and non-repeatability of the challenge value. This blocks replay attacks, forgery attacks, and other security threats at the authentication source. The final challenge value is generated by XORing the challenge binding value with the hardware random number. The challenge binding value is calculated using the unique request identifier, globally common parameters, and the challenge generation timestamp, achieving a strong binding between the challenge value and the current authentication request, time, and system parameters. Even if an attacker obtains historical challenge values, they cannot reuse them for other requests or different time windows. Combined with the physical unpredictability of hardware random numbers, this forms a dual protection of "physical security + logical binding," significantly improving the overall system security.

[0121] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0122] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0123] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0124] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0125] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0126] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A social service identity authentication system, characterized in that, include: User terminal, validator server, key management center and audit node; The user terminal is configured with a pre-computation module and a first communication module, which are used to initiate user authentication requests and assemble authentication request packets based on encrypted intermediate results of fixed identity features generated by the pre-computation module. The key management center is used to generate global public parameters and user-specific private keys based on Ring-LWE parameters to complete user identity binding. The verifier server is configured with a hardware random number generator, a request cache pool, a hierarchical verification module, and a second communication module, for receiving the authentication request packet, generating a random challenge value, receiving data to be transmitted from the user terminal, and verifying it through the hierarchical verification module. The audit node is used to receive authentication results and non-privacy metadata from the validator server, and to verify the integrity of the metadata through a hash chain. The user terminal is further configured to generate a zero-knowledge proof based on the random challenge value, and to sign the zero-knowledge proof using the Falcon algorithm to form the data to be transmitted.

2. The social service identity authentication system according to claim 1, characterized in that, The process for generating the global common parameters is as follows: Randomly select generators; globally secret parameters. Construct an initial polynomial and combine it with polynomial loop constraints to generate a discrete Gaussian distributed error. The common parameters of the linear combination with errors are calculated according to the Ring-LWE core formula, and the global common parameters are obtained by combining the generators and synchronized to the verifier and audit node.

3. The social service identity authentication system according to claim 2, characterized in that, The process of generating a user's private key and binding their identity is as follows: Extract the user's de-identified core information; The identity binding factor is calculated based on the user's de-identified core identity information and global secret parameters. The core signature private key is generated based on the global secret parameters and the identity binding factor. The subsequent expected verification factor is generated based on the user's de-identified core identity information and the global public parameters. Generate a user-specific private key based on the core signature private key and the subsequent expected verification factor; The user's private key is distributed to the user's terminal through a secure channel.

4. A social service identity authentication system according to claim 3, characterized in that, The user terminal generates encrypted intermediate results with fixed identity features in advance through the pre-computation module, and assembles the authentication request packet in combination with the user authentication request as follows: The user terminal starts the pre-computation module to extract the subsequent expected verification factor and global public parameters from the user's private key, and parses the fixed identity features from the user's private key; By binding global public parameters, fixed identity features and subsequent expected verification factors through triple hashing, an encrypted intermediate result is generated according to the budget calculation formula, and the encrypted intermediate result is stored in the local cache of the terminal. The authentication request packet is assembled based on the encrypted intermediate result, the business type identifier, and the unique request identifier, and then sent to the verifier through the government network.

5. A social service identity authentication system according to claim 4, characterized in that, After receiving a user authentication request, the verifier generates a random challenge value as follows: When the verifier receives the authentication request packet, it first checks whether the business type identifier is a supported business type and whether the request timestamp is within the current time window. Query the request cache pool. If the unique identifier of the request already exists, reject the request directly; otherwise, record the unique identifier of the request and the request time. The hardware random number generator is called to generate a 256-bit random number. The challenge binding value is calculated based on the challenge generation timestamp, global public parameters, and the unique identifier of the request. The challenge binding value is XORed with the random number to obtain the final challenge value, ensuring that the challenge value is uniquely bound to the current request. The challenge value and the unique identifier of the request are packaged together to generate a challenge data package, which is then sent to the user terminal through the government encrypted channel. The verifier starts a challenge response timer; if no response is received, the request is marked as failed, allowing the user terminal to re-initiate the request.

6. A social service identity authentication system according to claim 5, characterized in that, The user terminal receives a random challenge value and, in combination with the user's private key, pre-computed encrypted intermediate results, and globally common parameters, generates a zero-knowledge proof. The process is as follows: When a user terminal receives a challenge data packet, it first verifies whether the unique identifier of the request matches the unique identifier of the locally initiated request. If they match, extract the pre-computed encrypted intermediate results from the local cache, the user's private key, and the global public parameters. Randomly select an auxiliary polynomial and generate response parameters according to incremental calculation logic; The proof binding hash is calculated by combining the response parameters with the random challenge value and the pre-computed encrypted intermediate result. The zero-knowledge proof is obtained by combining the proof binding hash with the random challenge value and the response parameters.

7. A social service identity authentication system according to claim 6, characterized in that, The process of obtaining a Falcon digital signature by using the Falcon algorithm to perform zero-knowledge proof signing, and forming the data to be transmitted, is as follows: Use the core signing private key from the user's private key as the Falcon signing private key; Calculate the proof hash value based on zero-knowledge proof, and generate the signature polynomial using the Falcon algorithm; A Falcon digital signature is generated and combined with zero-knowledge data to form the data to be transmitted.

8. A social service identity authentication system according to claim 7, characterized in that, The user terminal sends the data to be transmitted and non-privacy metadata to the verifier. The verifier verifies the validity of the data to be transmitted. If the verification is successful, the identity authentication process is completed as follows: The verifier collects non-privacy metadata, including authentication timestamps, device de-identification identifiers, and service types, and dynamically generates encrypted metadata keys based on the non-privacy metadata and global public parameters. Lightweight encryption of non-privacy metadata is used to obtain encrypted metadata; The data to be transmitted is assembled by combining the encrypted metadata with the data to be transmitted. The verifier performs layered verification on the data to be transmitted, including the first layer of metadata integrity verification, the second layer of Falcon signature verification, and the third layer of zero-knowledge proof verification. The verifier returns the result to the terminal; if the authentication is successful, the subsequent business process is triggered.

9. A social service identity authentication system according to claim 8, characterized in that, The verifier performs layered verification of the data to be transmitted as follows: The first layer of metadata integrity verification involves the verifier verifying the metadata authentication tag using the encrypted metadata key. If the tag does not match, it is rejected directly. If it matches, it is decrypted, and the verifier checks whether the authentication timestamp is within the time window and whether the device desensitization identifier has been registered. If the authentication timestamp is within the time window and the device desensitization identifier has been registered, the second layer of Falcon signature verification is performed. The second layer of Falcon signature verification calls the Falcon public key for verification; if the verification fails, the signature is rejected. The third layer of zero-knowledge proof verification extracts the pre-computed encrypted intermediate result, queries the government database to obtain the user's fixed identifier, and calculates the fixed identity feature encrypted intermediate result based on the database query result; Compare the encrypted intermediate results of fixed identity features calculated based on database query results with the encrypted intermediate results of fixed identity features generated in advance by the user through the pre-computation module; If the intermediate encryption results are the same, then according to the operation rules of the polynomial ring, perform polynomial multiplication on the generator in the global public parameters and the response parameter in the zero-knowledge proof, and then perform polynomial addition on the result and another response parameter in the zero-knowledge proof. After obtaining the result, take the modulo of the prime number. At the same time, the random challenge value is multiplied by the error-laden linear combination of common parameters in the global common parameters, and the result is modulo the prime number. If the results of these two modulo operations satisfy the congruence relation in the polynomial ring, then the first verification passes; Calculate the L-infinity norm of the response parameters, which is the maximum value among the absolute values ​​of all coefficients in the response parameters; Determine whether the maximum value is less than or equal to the threshold. If it is, the second verification passes.

10. A social service identity authentication system according to claim 9, characterized in that, The verifier synchronizes the authentication result along with non-privacy metadata to the audit node. The audit node verifies the integrity of the metadata through a hash chain as follows: After completing identity authentication, the verifier will synchronize the authentication result and the decrypted non-privacy metadata to the audit node; After receiving the data, the audit node first calls the initial hash value, then concatenates the non-privacy metadata synchronized this time with the hash value corresponding to the previous authentication in order, and calculates the hash value of the current authentication by using the specified hash function; Then check whether the hash value is consistent with the corresponding hash value stored locally, and at the same time ensure that the hash value of each node in the entire hash chain can be derived from the hash value of the preceding node and the corresponding metadata; If all hash values ​​match correctly, it means that the metadata has not been tampered with during transmission and synchronization, and its integrity has been verified. If a hash value mismatch is found, the metadata integrity is deemed compromised, triggering an audit alert and logging the anomaly information.

Images