Controllable homomorphic encryption data sharing method and system

Abstract

The embodiment of the application discloses a controllable homomorphic encryption data sharing method and system, wherein the method comprises the following steps: a data provider performs homomorphic encryption on local data to obtain original ciphertext, and generates multi-dimensional authorization constraint parameters containing the maximum number of uses, taking the maximum number of uses as the initial current remaining number of uses; a strategy public key and a private key are generated, a single noise increment is calculated according to an initial noise budget and the constraint parameters, the single noise increment, the constraint parameters, the strategy public key and the original ciphertext are bound as a strategy ciphertext and are published; a data user obtains an authorization certificate, generates zero-knowledge proof according to the certificate and the strategy ciphertext, and submits the zero-knowledge proof to a verification node for verification; if the verification fails, the data user is rejected and the record is recorded; if the verification is passed, a homomorphic operation is performed to obtain result ciphertext, a noise mask is generated according to the single noise increment and is superimposed on the result ciphertext, and the current remaining number of uses is updated according to the authorized number of uses in the certificate. The controllability of shared data use is improved.

Description

Technical Field

[0001] This invention relates to the field of data security, and in particular to a controllable homomorphic encrypted data sharing method and system. Background Technology

[0002] In the digital economy era, the open sharing and circulation of public data (such as government data, medical data, and financial data) has become a key element in driving social innovation and economic growth. However, data sharing must be conducted within a strict compliance framework, meeting the data privacy protection requirements of laws and regulations such as the Data Security Law and the Personal Information Protection Law, while also achieving the regulatory goal of "data usable but not visible, and its use controllable and measurable." Data providers (such as government agencies, hospitals, and banks) need to authorize third parties (such as research teams, disease control centers, and joint modeling institutions) to analyze and compute their data, but must not disclose the original plaintext data. They must also be able to precisely control the frequency of use, limit the types of operations allowed, and ensure that the entire authorization process is auditable and traceable.

[0003] Homomorphic encryption allows computations to be performed directly on ciphertext without decryption, making it an ideal tool for achieving "usable but invisible." However, existing homomorphic encryption schemes lack authorization management capabilities: once the ciphertext is shared, anyone holding it can perform arbitrary operations an unlimited number of times. The data provider cannot limit the number of uses or the types of operations, nor can they know the specific circumstances under which the ciphertext is used.

[0004] While Attribute-Based Encryption (ABE) enables attribute-based access control, its authorization becomes invalid during the decryption phase and it does not support direct homomorphic computation on ciphertext. Functional Encryption (FE) binds computational functions to the key, resulting in poor flexibility and an inability to control usage frequency. Digital Rights Management (DRM) typically relies on Trusted Execution Environments (TEEs) or software logic to record usage frequency, but these constraints can be bypassed by side-channel attacks, local clock tampering, and software cracking, failing to provide cryptographic-level security guarantees. Furthermore, existing solutions often require users to expose their identity, attribute credentials, or device identifiers during authorization verification, revealing sensitive information such as "who is analyzing what data," which contradicts privacy protection principles.

[0005] There is currently no effective solution to the problem that existing technologies cannot simultaneously achieve homomorphic computation, count control, type restriction, privacy verification, and audit traceability. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a controllable homomorphic encryption data sharing method and system. By binding an authorization policy to the ciphertext, the user performs homomorphic operations after verifying authorization through zero-knowledge proofs. Noise is injected into the ciphertext and the remaining number of operations is deducted for each operation. When the number of operations is exhausted, the ciphertext becomes permanently invalid due to noise exceeding the threshold. Thus, within the homomorphic encryption framework, the number of operations, type restrictions, privacy verification, and audit traceability are simultaneously achieved.

[0007] To achieve the above objectives, this invention provides a controllable homomorphic encrypted data sharing method, comprising: a data provider performing homomorphic encryption on local data to obtain original ciphertext, and generating multidimensional authorization constraint parameters corresponding to the original ciphertext; wherein, the multidimensional authorization constraint parameters include a maximum number of uses, and the maximum number of uses is used as the initial current remaining number of uses; the data provider generating a corresponding policy public key and policy private key, and calculating a single noise increment based on the initial noise budget corresponding to the original ciphertext and the multidimensional authorization constraint parameters, binding the single noise increment, the multidimensional authorization constraint parameters, the policy public key, and the original ciphertext into a policy-enabled ciphertext and publishing it; a data user obtaining an authorization certificate, generating a zero-knowledge proof based on the authorization certificate and the policy-enabled ciphertext, and submitting it to a verification node for verification; when verification fails, the operation is rejected and recorded; when verification passes, the data user performing homomorphic operation on the original ciphertext to obtain a result ciphertext, generating a noise mask based on the single noise increment and superimposing it on the result ciphertext; and updating the current remaining number of uses based on the authorized usage count in the authorization certificate.

[0008] Further optionally, the multidimensional authorization constraint parameters include: maximum number of uses, set of allowed operation types, expiration time stamp, set of allowed uses, and noise attenuation factor.

[0009] Further optionally, the step of calculating the single noise increment based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext is performed using the following formula: in, Indicates the noise increment in a single instance. Indicates the noise attenuation factor. Represents the initial noise budget ， Indicates the safety margin threshold. Indicates the maximum number of times it can be used.

[0010] Optionally, generating a zero-knowledge proof based on the authorization certificate and policy-encrypted text includes: obtaining the allowed operation type set, expiration time stamp, and policy public key from the policy-encrypted text; obtaining the request operation type, application timestamp, and authorized usage count from the authorization certificate; wherein the authorization certificate is issued by the policy private key, and the authorized usage count is less than or equal to the current remaining usage count; constructing a zero-knowledge proof circuit and generating a zero-knowledge proof based on the circuit, wherein the circuit executes signature verification constraints, expiration constraints, operation type constraints, and count constraints; wherein the signature verification constraint uses the policy public key to verify the signature of the authorization certificate; the expiration constraint requires that the application timestamp is not later than the expiration time stamp; the operation type constraint requires that the request operation type belongs to the allowed operation type set; and the count constraint requires that the authorized usage count is greater than zero.

[0011] Further optionally, the step of generating a noise mask based on the single noise increment and superimposing it onto the result ciphertext includes: determining a noise adjustment coefficient corresponding to the current operation type; calculating a target noise norm based on the single noise increment and the noise adjustment coefficient; randomly generating a random mask vector with the same dimension as the result ciphertext, using the target noise norm as the L2 norm of the random mask vector; and superimposing the random mask vector onto the first component of the result ciphertext.

[0012] On the other hand, the present invention also provides a controllable homomorphic encrypted data sharing system, comprising: a constraint parameter definition module, used by the data provider to homomorphically encrypt local data to obtain original ciphertext, and generate multi-dimensional authorization constraint parameters corresponding to the original ciphertext; wherein, the multi-dimensional authorization constraint parameters include a maximum number of uses, with the maximum number of uses as the initial current remaining number of uses; and a policy-based ciphertext generation module, used by the data provider to generate corresponding policy public key and policy private key, and calculate the single noise increment based on the initial noise budget and multi-dimensional authorization constraint parameters corresponding to the original ciphertext, and combine the single noise increment and multi-dimensional... The authorization constraint parameters, policy public key, and original ciphertext are bound together into policy-enabled ciphertext and published. A zero-knowledge proof generation module is used by the data user to obtain an authorization certificate, generate a zero-knowledge proof based on the authorization certificate and policy-enabled ciphertext, and submit it to a verification node for verification. A first processing module is used to reject the operation and record it when verification fails. A second processing module is used to perform a homomorphic operation on the original ciphertext to obtain the result ciphertext when verification passes, generate a noise mask based on the single noise increment, and superimpose it onto the result ciphertext; and update the current remaining usage count based on the authorized usage count in the authorization certificate.

[0013] Further optionally, the multidimensional authorization constraint parameters include: maximum number of uses, set of allowed operation types, expiration time stamp, set of allowed uses, and noise attenuation factor.

[0014] Further optionally, the step of calculating the single noise increment based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext is performed using the following formula: in, Indicates the noise increment in a single instance. Indicates the noise attenuation factor. Represents the initial noise budget ， Indicates the safety margin threshold. Indicates the maximum number of times it can be used.

[0015] Further optionally, the zero-knowledge proof generation module includes: a first data acquisition submodule, used to acquire the allowed operation type set, validity period expiration timestamp, and policy public key from the policy ciphertext; a second data acquisition submodule, used to acquire the request operation type, application timestamp, and authorized usage count from the authorization certificate; wherein the authorization certificate is issued by the policy private key, and the authorized usage count is less than or equal to the current remaining usage count; and a zero-knowledge proof generation submodule, used to construct a zero-knowledge proof circuit and generate a zero-knowledge proof based on the circuit, wherein the circuit executes signature verification constraints, validity period constraints, operation type constraints, and count constraints; wherein the signature verification constraint uses the policy public key to verify the signature of the authorization certificate; the validity period constraint requires that the application timestamp is not later than the validity period expiration timestamp; the operation type constraint requires that the request operation type belongs to the allowed operation type set; and the count constraint requires that the authorized usage count is greater than zero.

[0016] Further optionally, the second processing module includes: an adjustment coefficient determination submodule, used to determine the noise adjustment coefficient corresponding to the current operation type; a target noise norm calculation submodule, used to calculate the target noise norm based on the single noise increment and the noise adjustment coefficient; a random mask vector calculation submodule, used to randomly generate a random mask vector with the same dimension as the result ciphertext, and use the target noise norm as the L2 norm of the random mask vector; and a noise superposition submodule, used to superimpose the random mask vector onto the first component of the result ciphertext.

[0017] The above technical solution has the following beneficial effects: by embedding the authorization strategy into the ciphertext structure and binding it to the original ciphertext for publication, the integration of authorization and ciphertext is achieved, eliminating the possibility of ciphertext misuse from the root; by utilizing the noise budget characteristic of homomorphic encryption, the number of uses is transformed into a noise increment that can be precisely consumed, and the ciphertext is permanently invalidated based on mathematical principles when the number of uses is exhausted, ensuring the cryptographic-level unbreakable nature of the use limit constraint; by introducing zero-knowledge proof technology, the data user can complete the authorization verification without exposing their identity, certificate plaintext, and computational intent, thus achieving privacy protection in the authorization process. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of the controllable homomorphic encrypted data sharing method provided in the embodiments of the present invention; Figure 2 This is a flowchart of the zero-knowledge proof generation method provided in the embodiments of the present invention; Figure 3 This is a flowchart of the mask overlay method provided in the embodiments of the present invention; Figure 4 This is a schematic diagram of the structure of the controllable homomorphic encrypted data sharing system provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the zero-knowledge proof generation module provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of the second processing module provided in an embodiment of the present invention.

[0020] Figure reference numerals: 100 - Constraint parameter definition module; 200 - Policy-based ciphertext generation module; 300 - Zero-knowledge proof generation module; 3001 - First data acquisition submodule; 3002 - Second data acquisition submodule; 3003 - Zero-knowledge proof generation submodule; 400 - First processing module; 500 - Second processing module; 5001 - Adjustment coefficient determination submodule; 5002 - Target noise norm calculation submodule; 5003 - Random mask vector calculation submodule; 5004 - Noise superposition submodule. Detailed Implementation

[0021] 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 skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] To address the limitations of existing designs in simultaneously implementing homomorphic computation, count control, type restriction, privacy verification, and audit traceability, this invention provides a controllable homomorphic encrypted data sharing method. Figure 1 This is a flowchart of the controllable homomorphic encrypted data sharing method provided in the embodiments of the present invention, such as... Figure 1 As shown, the method includes: S1. The data provider performs homomorphic encryption on the local data to obtain the original ciphertext and generates multidimensional authorization constraint parameters corresponding to the original ciphertext; among which, the multidimensional authorization constraint parameters include the maximum number of uses, and the maximum number of uses is used as the initial current remaining number of uses.

[0023] The data provider first determines the plaintext dataset m that needs to be shared based on its own business needs, such as tax records in government statistical tables, patient statistical characteristics of medical institutions, or risk control indicators of banks.

[0024] To allow third-party computation while ensuring data confidentiality, the data provider encrypts the plaintext dataset m using a homomorphic encryption scheme that supports noise budgeting properties, obtaining the original ciphertext C0. Preferably, CKKS, BFV, or BGV schemes can be used.

[0025] The encryption process for the plaintext dataset uses a homomorphic encryption key pair (including a public key and a private key) generated by the data provider. The public key is used for encryption, while the private key is secretly kept by the data provider for decryption. The resulting original ciphertext C0 is in multinomial vector form with embedded random noise. The initial noise budget budget_0 (number of bits) of the original ciphertext C0 can be obtained through the noise budget query interface of the homomorphic encryption library. This value reflects how many more operations the ciphertext can withstand without losing decryption correctness.

[0026] At the same time, the data provider needs to define multidimensional authorization constraint parameters corresponding to the original ciphertext C0. These parameters are the control rules imposed by the data provider on data usage behavior, including at least the maximum number of uses N_max. The maximum number of uses represents the total number of times the ciphertext can be authorized to perform homomorphic operations throughout its entire lifecycle, for example, set to 50 or 100 times.

[0027] To facilitate subsequent usage management, the data provider uses the maximum usage count N_max as the initial value of the current remaining usage count, i.e., the current remaining usage count N_remaining = N_max.

[0028] Furthermore, the multidimensional authorization constraint parameters can be further expanded to include the set of allowed operation types (e.g., allowing only addition and summation), validity period expiration timestamp, data usage scenario label, and noise attenuation factor, etc., as needed. These extended parameters will be used for refined authorization control in subsequent steps. The multidimensional authorization constraint parameters can be generated by the data provider through a configuration interface or API interface, and are ultimately associated with and stored with the original ciphertext, forming the basis for subsequent authorization verification and usage consumption.

[0029] S2. The data provider generates the corresponding policy public key and policy private key, calculates the single noise increment based on the initial noise budget and multi-dimensional authorization constraint parameters corresponding to the original ciphertext, binds the single noise increment, multi-dimensional authorization constraint parameters, policy public key and original ciphertext into policy-enabled ciphertext and publishes it.

[0030] The data provider first generates a policy key pair for subsequent authorization certificate management, namely the policy private key sk_policy and the policy public key pk_policy. The policy private key is securely stored by the authorization management platform (e.g., stored in a hardware security module) and is used to issue authorization certificates to legitimate users; the policy public key is made public and used to verify the authenticity of the authorization certificate. The key pair can be generated using an elliptic curve digital signature algorithm (such as ECDSA), an Edwards curve digital signature algorithm (EdDSA), or a BLS signature scheme.

[0031] The data provider needs to calculate the amount of noise to be injected for each authorized use, i.e., the noise increment per use. This calculation is based on the initial noise budget `budget_0` of the original ciphertext and the maximum number of uses in the multi-dimensional authorization constraint parameters. The core idea is to evenly divide the initial available noise budget of the ciphertext according to the maximum number of uses, thereby determining the noise intensity that needs to be injected into the ciphertext after each authorized use. In this way, when the cumulative number of uses reaches the maximum number of uses, the total noise in the ciphertext will exceed the decryption threshold, causing the ciphertext to automatically become invalid based on the mathematical principle of homomorphic encryption, thus achieving precise control over the number of uses.

[0032] Finally, the data provider will submit the original ciphertext C0, the multidimensional authorization constraint parameter P, the policy public key pk_policy, and the calculated single-time noise increment. The two components are combined to form a complete policy-enabled ciphertext C_policy. This policy-enabled ciphertext is then sent to the data sharing platform.

[0033] As a specific usage method, some or all parameters in the multidimensional authorization constraint parameter P, the initial noise budget budget_0, and the single noise increment are included. After concatenating the data in a predetermined order, a hash value is calculated to obtain the policy label code L. Then, the policy label code L, the original ciphertext C0, the policy public key pk_policy, the current remaining usage count N_remaining, and the single-use noise increment are processed. Bind to obtain the policy-encrypted text C_policy = (C0, L, pk_policy, N_remaining, Δ_noise).

[0034] S3. The data user obtains an authorization certificate, generates a zero-knowledge proof based on the authorization certificate and the policy-included ciphertext, and submits it to the verification node for verification.

[0035] When a data user wishes to use the original encrypted data, they must first apply for and obtain an authorization certificate from the authorization management platform. The authorization management platform is a trusted third party independent of both the data provider and the user, responsible for verifying the user's qualifications.

[0036] The data user submits its identity identifier U_id and the type of operation Op_req to be performed (such as summation, multiplication, or linear transformation). The authorization management platform verifies whether the user is qualified to use the data (e.g., whether the identity identifier is in the license list, whether a data usage agreement has been signed, whether it belongs to an authorized organization type, etc.), and whether the requested operation type is within the set of allowed operation types preset by the data provider.

[0037] After successful verification, the authorization management platform issues an authorization certificate using the data provider's policy private key sk_policy. This authorization certificate must contain at least the user's identity identifier, the type of operation requested, the application timestamp, and the number of times the authorization is granted (usually once, but can be multiple times).

[0038] After obtaining the authorization certificate, the data user needs to prove to the verification node (preferably a blockchain smart contract) that they have legitimate authorization and that the request complies with policy constraints, while avoiding disclosing their identity, certificate plaintext, or specific computational intent. To this end, the data user employs zero-knowledge proof technology.

[0039] Specifically, the data user extracts necessary public verification parameters (such as the policy public key, authorization constraints, and current remaining usage count) from the policy-ciphertext and extracts corresponding authorization information from the authorization certificate. The user inputs this public information, along with the authorization certificate as private evidence, into a zero-knowledge proof circuit. This circuit is designed to verify the authenticity of the authorization certificate and whether the request complies with the authorization constraints preset by the data provider. After the circuit is built, the user runs a zero-knowledge proof generation algorithm to produce a proof string. Subsequently, the data user submits this zero-knowledge proof, along with necessary public inputs (such as the policy-ciphertext identifier and current remaining usage count), to the verification node.

[0040] S4. If the verification fails, refuse the operation and record it.

[0041] The verification node responds to the verification result of the zero-knowledge proof. If the verification node outputs "verification failed", it means that the zero-knowledge proof submitted by the data user fails to meet the preset constraints. Possible reasons include: invalid authorization certificate signature, requested operation type exceeding the allowed range, application timestamp expired, authorized usage count exceeding the current remaining usage count, or the proof itself has been tampered with.

[0042] In this situation, the validator node rejects the computation request and prohibits the user from performing any homomorphic operations on the policy-encrypted text. Simultaneously, the validator node logs this failure event, including at least the timestamp of the failure, the identifier of the data user submitting the proof, and a summary of the type or reason for the failure. This record can be written to a local log or the blockchain for subsequent auditing and traceability by the data provider and regulators.

[0043] S5. When the verification is successful, the data user performs a homomorphic operation on the original ciphertext to obtain the result ciphertext, generates a noise mask based on the single noise increment and superimposes it on the result ciphertext; and updates the current remaining number of uses based on the authorized use count in the authorization certificate.

[0044] After receiving a "verification passed" result from the verification node, the data user is granted permission to perform homomorphic operations on the policy-bound ciphertext. At this point, the data user can perform the corresponding homomorphic operation on the original ciphertext in the policy-bound ciphertext according to the operation type declared in the authorization certificate (such as addition, multiplication, or summation) to obtain a result ciphertext that is also in ciphertext form.

[0045] Additionally, the data user needs to generate a noise mask based on the pre-calculated single noise increment and then overlay this mask onto the resulting ciphertext. The noise mask is generated in accordance with the rules for noise addition in homomorphic encryption schemes. Typically, it is obtained by randomly sampling a vector with the same dimension as the ciphertext from a specific noise distribution (such as a Gaussian distribution) and associating its norm with the single noise increment.

[0046] After the noise mask is superimposed onto the resulting ciphertext, a portion of the noise budget within the ciphertext is precisely consumed, equivalent to being billed for one use. After the calculation is complete, the data user updates the remaining usage count recorded in the policy-enabled ciphertext based on the authorized usage count in the authorization certificate (usually one, but can be multiple), that is, subtracting the authorized usage count from the current remaining count. Specifically, the current remaining count can be decremented by one after each homomorphic operation. The updated remaining count reflects the number of authorized uses that the ciphertext can still perform. When the remaining count decreases to zero, the accumulated noise within the ciphertext will exceed the decryption threshold. Based on the mathematical properties of homomorphic encryption, the ciphertext will become permanently invalid, and any subsequent computational requests will no longer be able to pass verification.

[0047] Furthermore, after each homomorphic operation, noise injection, and remaining usage update, the data user writes a summary of the operation to the blockchain. This summary includes at least the user's identity hash (to protect privacy), the type of operation performed, the operation timestamp, the noise increment consumed, and the updated remaining usage count. The smart contract automatically stores this information as structured events, forming an immutable audit log.

[0048] Data providers can use the query interface provided by the blockchain to view the usage overview of their published policy-encrypted data at any time, such as the cumulative number of uses, remaining uses, and detailed records of each operation. Regulators can also access the audit interface to obtain complete operation logs and conduct compliance checks accordingly.

[0049] Furthermore, this method also supports authorization renewal and revocation. When a data provider wishes to extend the usage period of the data or increase the number of uses, they can submit a renewal request containing the new maximum number of uses and the new validity period and sign it. After the blockchain smart contract verifies the signature, it reads the actual remaining noise budget of the current ciphertext, recalculates the single noise increment based on the number of uses and the new maximum number of uses, and updates the policy parameters and remaining number of uses stored on the chain.

[0050] When a data provider needs to terminate authorization early, it can initiate a revocation operation. The smart contract will mark the state with the policy ciphertext as revoked. Afterward, any verification request for that ciphertext will be directly rejected, and the rejection event will also be recorded on the blockchain.

[0051] As an optional implementation, the multidimensional authorization constraint parameters include: maximum number of uses, set of allowed operation types, expiration time stamp, set of allowed uses, and noise attenuation factor.

[0052] The maximum number of uses, N_max, is a positive integer used to limit the total number of times the policy-enabled ciphertext can be authorized to perform homomorphic operations throughout its entire lifetime.

[0053] The allowed operation type set Op_set contains the types of homomorphic operations that the data provider allows the user to perform, such as addition, multiplication, summation, inner product, or linear transformation. Operation requests outside this set will be rejected.

[0054] The expiration time stamp T_expire sets the authorization time window; only computation requests initiated before the timestamp are considered valid.

[0055] The permitted uses set of Purposes can be used for compliance control at the business level, such as "statistical analysis", "regression modeling" or "risk control scoring". Before issuing a certificate, the authorization management platform will verify whether the purpose declared by the user belongs to this set.

[0056] The noise attenuation factor λ_noise is an adjustable coefficient used to fine-tune the calculation of a single noise increment. Data providers can flexibly control the rate at which the number of iterations is consumed based on the sensitivity of the data or the computational intensity.

[0057] Based on the above parameters, the multidimensional authorization constraint parameter P defined by the data provider can be expressed as P = (N_max, T_expire, Op_set, Purpose, λ_noise).

[0058] Furthermore, when generating the policy label encoding L, N_max, T_expire, Op_set, Purpose, and the initial noise budget are selected. The policy label encoding is then combined with the single noise increment Δ_noise, so L=H(N_max || T_expire || sort(Op_set) || Purpose || budget_0 || Δ_noise).

[0059] As an optional implementation, the single noise increment is calculated based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext, using the following formula: in, Indicates the noise increment in a single instance. Indicates the noise attenuation factor. Represents the initial noise budget， Indicates the safety margin threshold. Indicates the maximum number of times it can be used.

[0060] Single noise increment This indicates the noise intensity that needs to be actively injected into the ciphertext after each authorized use; noise attenuation factor. It is an adjustable coefficient between 0.5 and 1.5 used to fine-tune the noise consumption rate based on data sensitivity or expected usage intensity; initial noise budget The security margin threshold is automatically determined by the homomorphic encryption scheme based on security parameters. The estimate used to absorb the inherent noise growth of homomorphic operations is typically a fixed percentage (e.g., 10%) of the initial noise budget. This indicates the maximum number of times the multidimensional authorization constraint parameter can be used.

[0061] The formula is designed based on the following principle: the initial available noise budget of the original ciphertext (after deducting the safety margin) is evenly divided according to the maximum number of uses to obtain the base noise increment, which is then multiplied by a noise attenuation factor to provide flexible adjustment capabilities. In this way, it is injected after each authorized use. The noise level increases with the number of uses. At that point, the total noise within the ciphertext will just exceed the decryption threshold, causing the ciphertext, based on the mathematical principles of homomorphic encryption, to permanently fail. If If the number of failures is greater than 1, then the actual number of failures is less than 1. To achieve stricter control over the number of times; if If the number of failures is less than 1, then the actual number of failures is greater than 1. To provide a certain degree of tolerance.

[0062] As an optional implementation method, Figure 2 This is a flowchart of the zero-knowledge proof generation method provided in the embodiments of the present invention, such as... Figure 2 As shown, zero-knowledge proofs are generated based on the authorization certificate and policy-enabled ciphertext, including: S301. Obtain the set of allowed operation types, expiration time stamp, and policy public key from the policy ciphertext.

[0063] Data users can directly read three public parameters from the policy-encrypted text: the set of allowed operation types Op_set, the expiration time stamp T_expire, and the policy public key pk_policy.

[0064] S302. Obtain the request operation type, application timestamp, and authorized usage count from the authorization certificate; wherein, the authorization certificate is issued by the policy private key, and the authorized usage count is less than or equal to the current remaining usage count.

[0065] The authorization certificate issued by the authorization management platform is cert = Sign_{sk_policy}(U_id || Op_req ||t_apply || N_grant), which includes the identity of the data user, the type of requested operation, the application timestamp, and the number of authorized uses. Where N_grant ≤ N_remaining.

[0066] S303. Construct a zero-knowledge proof circuit and generate a zero-knowledge proof based on the circuit. The circuit executes signature verification constraints, validity period constraints, operation type constraints, and number of times constraints. Among them, the signature verification constraint uses the policy public key to verify the signature of the authorization certificate; the validity period constraint requires that the application timestamp is not later than the validity period expiration timestamp; the operation type constraint requires that the requested operation type belongs to the set of allowed operation types; and the number of times constraint requires that the authorized number of times is greater than zero.

[0067] The data user first constructs an R1CS circuit based on the set of allowed operation types, expiration timestamp, and policy public key extracted from the policy ciphertext, as well as the requested operation type, application timestamp, and authorized usage count extracted from the authorization certificate. This circuit is designed to enforce the following four types of constraints: First, signature verification constraints. The circuit uses the policy public key to verify the digital signature of the authorization certificate, ensuring that the certificate was indeed issued by the authorization management platform holding the policy private key, thereby preventing certificate forgery or tampering with the certificate content.

[0068] Second, validity period constraints. The circuit compares the application timestamp in the license certificate with the validity expiration timestamp set in the policy, requiring that the application timestamp be no later than the validity expiration timestamp, thereby preventing expired licenses from being used.

[0069] Third, operation type constraints. The circuit checks whether the requested operation type declared in the authorization certificate belongs to the set of allowed operation types in the policy ciphertext, ensuring that the user can only perform operations that the data provider has previously permitted (e.g., only addition is allowed and multiplication is not).

[0070] Fourth, the usage limit. The circuit verifies whether the authorized usage count in the authorization certificate is greater than zero, that is, to ensure that this request contains at least one valid usage quota. It should be noted that the usage limit is usually also compared with the current remaining usage count (this comparison has been completed by the verification node through public input), and the circuit mainly ensures that the authorized usage count is positive.

[0071] After the circuit is constructed, the data user runs a zero-knowledge proof generation algorithm, using the authorization certificate as private evidence and the aforementioned public parameters as public input, to generate a very short zero-knowledge proof string, which is then sent to the verification node. The verification node then verifies the proof using a verification key; if successful, subsequent homomorphic operations are allowed.

[0072] Zero-knowledge proof schemes include Groth16, PLONK, Bulletproofs protocols, or similar non-interactive zero-knowledge proof protocols. Taking Groth16 as an example, the proof length is approximately 200 bytes, and the verification time is in the sub-millisecond range.

[0073] As an optional implementation method, Figure 3 This is a flowchart of the mask overlay method provided in the embodiments of the present invention, such as... Figure 3 As shown, a noise mask is generated based on a single noise increment and superimposed onto the resulting ciphertext, including: S501. Determine the noise adjustment coefficient corresponding to the current operation type.

[0074] The data user first identifies the specific type of homomorphic operation being performed, such as addition, multiplication, summation, inner product, or linear transformation.

[0075] Different types of operations consume the internal noise budget of the ciphertext at different rates: linear operations such as addition cause noise growth relatively slowly, while nonlinear operations such as multiplication cause noise growth relatively quickly (usually quadratic growth). To ensure that the effective noise budget consumed in each authorized use is approximately equal, thereby precisely controlling the total number of uses, this embodiment introduces a noise adjustment coefficient. This coefficient is a value associated with the operation type and is used to adjust the actual injection intensity of a single noise increment, preventing premature invalidation of the ciphertext in multiplication-intensive scenarios.

[0076] Specifically, for operation types with slow inherent noise growth (such as addition, summation, and linear transformation), the noise adjustment coefficient is set to a relatively large value, for example, 1.0; for operation types with fast inherent noise growth (such as multiplication and inner product), the noise adjustment coefficient is set to a relatively small value, for example, 0.6 or 0.8.

[0077] S502. Calculate the target noise norm based on the single noise increment and the noise adjustment coefficient.

[0078] Single noise increment With noise adjustment factor Multiplying them together yields the target noise norm.

[0079] For operations with slow inherent noise growth (such as addition), the adjustment coefficient is close to 1, and the target noise norm is close to the baseline value. For operations with fast inherent noise growth (such as multiplication), the adjustment coefficient is less than 1, and the target noise norm is reduced accordingly. This avoids premature ciphertext invalidation caused by the large noise growth from multiplication itself combined with injected noise. Conversely, if it is desired to more strictly limit the number of operations, an adjustment coefficient greater than 1 can be used.

[0080] S503. Randomly generate a random mask vector with the same dimensions as the ciphertext of the result, and use the target noise norm as the L2 norm of the random mask vector.

[0081] The data user generates a random mask vector of the same dimension as the ciphertext (e.g., the length of the vector or the degree of the polynomial contained in the ciphertext). Each element of this vector is independently and randomly sampled from a specific noise distribution (e.g., a Gaussian or sub-Gaussian distribution) to ensure the unpredictability and statistical uniformity of the mask.

[0082] After generating the initial random vector, its length is normalized and adjusted so that the L2 norm of the vector (i.e. the square root of the sum of squares of each element) is precisely controlled to be the target noise norm.

[0083] S504. Add the random mask vector to the first component of the resulting ciphertext.

[0084] The data user performs a vector addition operation between the random mask vector (mask) and the resulting ciphertext obtained after homomorphic operations. However, this addition operation only applies to the first component of the ciphertext. Taking the typical CKKS homomorphic encryption scheme as an example, a ciphertext usually consists of two polynomial components, represented as (c0, c1). The first component c0 is the main data carrier of the ciphertext, while the second component c1 is used in conjunction with the private key for decryption calculations. In this embodiment, only the random mask vector is added to the c0 component, while keeping the c1 component completely unchanged, resulting in the updated first component C_updated[·][0] = C_result[·][0] + mask.

[0085] The technical effect of doing this is: First, the ciphertext structure of CKKS is (c0, c1), and the decryption calculation is c0 + c1·s. Adding noise only to c0 does not change the structural integrity of c1; therefore, the homomorphic multiplication structure of the ciphertext is not destroyed—the multiplication operation relies on the cross-product of the two ciphertext components, and c1 remaining unchanged ensures the correctness of the multiplication result. If noise is injected into both components simultaneously, the cross-terms will multiply, accelerating ciphertext invalidation and making it impossible to precisely control the number of uses.

[0086] Second, the random mask vector is sampled from a Gaussian distribution (or a near-Gaussian sub-Gaussian distribution), and its L2 norm is precisely controlled to be... × The introduction of Gaussian noise mask does not compromise the IND-CPA security of the CKKS scheme under the RLWE (Ring Learning With Errors) assumption: the semantic security of the CKKS scheme relies on the indistinguishability of the ciphertext noise. The injected additional Gaussian mask is in the same distribution as the original encryption noise and does not add any exploitable statistical bias. Therefore, the security level of the ciphertext remains unchanged.

[0087] Third, after the noise mask is superimposed, the decryption noise becomes e + mask, and the expected noise increase is exactly 1 / 2. · Consistent with the design. Multiplication compatibility conditions. ·n< Determined by budget_0, its magnitude is much smaller than the modulus q).

[0088] At this point, the noise budget of the encrypted text has been consumed precisely according to the preset value, which is equivalent to completing a billing operation for authorized use.

[0089] This invention also provides a controllable homomorphic encrypted data sharing system. Figure 4 This is a schematic diagram of the structure of the controllable homomorphic encrypted data sharing system provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the system includes: The constraint parameter definition module 100 is used by the data provider to perform homomorphic encryption on local data to obtain the original ciphertext and generate multidimensional authorization constraint parameters corresponding to the original ciphertext; wherein, the multidimensional authorization constraint parameters include the maximum number of uses, and the maximum number of uses is used as the initial current remaining number of uses.

[0090] The data provider first determines the plaintext dataset m that needs to be shared based on its own business needs, such as tax records in government statistical tables, patient statistical characteristics of medical institutions, or risk control indicators of banks.

[0091] To allow third-party computation while ensuring data confidentiality, the data provider encrypts the plaintext dataset m using a homomorphic encryption scheme that supports noise budgeting properties, obtaining the original ciphertext C0. Preferably, CKKS, BFV, or BGV schemes can be used.

[0092] ​The encryption process for the plaintext dataset uses a homomorphic encryption key pair (including a public key and a private key) generated by the data provider. The public key is used for encryption, while the private key is secretly kept by the data provider for decryption. The resulting original ciphertext C0 is in multinomial vector form with embedded random noise. The initial noise budget budget_0 (number of bits) of the original ciphertext C0 can be obtained through the noise budget query interface of the homomorphic encryption library. This value reflects how many more operations the ciphertext can withstand without losing decryption correctness.

[0093] At the same time, the data provider needs to define multidimensional authorization constraint parameters corresponding to the original ciphertext C0. These parameters are the control rules imposed by the data provider on data usage behavior, including at least the maximum number of uses N_max. The maximum number of uses represents the total number of times the ciphertext can be authorized to perform homomorphic operations throughout its entire lifecycle, for example, set to 50 or 100 times.

[0094] To facilitate subsequent usage management, the data provider uses the maximum usage count N_max as the initial value of the current remaining usage count, i.e., the current remaining usage count N_remaining = N_max.

[0095] Furthermore, the multidimensional authorization constraint parameters can be further expanded to include the set of allowed operation types (e.g., allowing only addition and summation), validity period expiration timestamp, data usage scenario label, and noise attenuation factor, etc., as needed. These extended parameters will be used for refined authorization control in subsequent steps. The multidimensional authorization constraint parameters can be generated by the data provider through a configuration interface or API interface, and are ultimately associated with and stored with the original ciphertext, forming the basis for subsequent authorization verification and usage consumption.

[0096] The policy-based ciphertext generation module 200 is used by the data provider to generate the corresponding policy public key and policy private key, calculate the single noise increment based on the initial noise budget and multi-dimensional authorization constraint parameters corresponding to the original ciphertext, bind the single noise increment, multi-dimensional authorization constraint parameters, policy public key and original ciphertext into policy-based ciphertext and publish it.

[0097] The data provider first generates a policy key pair for subsequent authorization certificate management, namely the policy private key sk_policy and the policy public key pk_policy. The policy private key is securely stored by the authorization management platform (e.g., stored in a hardware security module) and is used to issue authorization certificates to legitimate users; the policy public key is made public and used to verify the authenticity of the authorization certificate. The key pair can be generated using an elliptic curve digital signature algorithm (such as ECDSA), an Edwards curve digital signature algorithm (EdDSA), or a BLS signature scheme.

[0098] The data provider needs to calculate the amount of noise to be injected for each authorized use, i.e., the noise increment per use. This calculation is based on the initial noise budget `budget_0` of the original ciphertext and the maximum number of uses in the multi-dimensional authorization constraint parameters. The core idea is to evenly divide the initial available noise budget of the ciphertext according to the maximum number of uses, thereby determining the noise intensity that needs to be injected into the ciphertext after each authorized use. In this way, when the cumulative number of uses reaches the maximum number of uses, the total noise in the ciphertext will exceed the decryption threshold, causing the ciphertext to automatically become invalid based on the mathematical principle of homomorphic encryption, thus achieving precise control over the number of uses.

[0099] Finally, the data provider will submit the original ciphertext C0, the multidimensional authorization constraint parameter P, the policy public key pk_policy, and the calculated single-time noise increment. The two components are combined to form a complete policy-enabled ciphertext C_policy. This policy-enabled ciphertext is then sent to the data sharing platform.

[0100] As a specific usage method, some or all parameters in the multidimensional authorization constraint parameter P, the initial noise budget budget_0, and the single noise increment are included. After concatenating the data in a predetermined order, a hash value is calculated to obtain the policy label code L. Then, the policy label code L, the original ciphertext C0, the policy public key pk_policy, the current remaining usage count N_remaining, and the single-use noise increment are processed. Bind to obtain the policy-encrypted text C_policy = (C0, L, pk_policy, N_remaining, Δ_noise).

[0101] The zero-knowledge proof generation module 300 is used by the data user to obtain an authorization certificate, generate a zero-knowledge proof based on the authorization certificate and policy-included ciphertext, and submit it to the verification node for verification.

[0102] When a data user wishes to use the original encrypted data, they must first apply for and obtain an authorization certificate from the authorization management platform. The authorization management platform is a trusted third party independent of both the data provider and the user, responsible for verifying the user's qualifications.

[0103] The data user submits its identity identifier U_id and the type of operation Op_req to be performed (such as summation, multiplication, or linear transformation). The authorization management platform verifies whether the user is qualified to use the data (e.g., whether the identity identifier is in the license list, whether a data usage agreement has been signed, whether it belongs to an authorized organization type, etc.), and whether the requested operation type is within the set of allowed operation types preset by the data provider.

[0104] After successful verification, the authorization management platform issues an authorization certificate using the data provider's policy private key sk_policy. This authorization certificate must contain at least the user's identity identifier, the type of operation requested, the application timestamp, and the number of times the authorization is granted (usually once, but can be multiple times).

[0105] After obtaining the authorization certificate, the data user needs to prove to the verification node (preferably a blockchain smart contract) that they have legitimate authorization and that the request complies with policy constraints, while avoiding disclosing their identity, certificate plaintext, or specific computational intent. To this end, the data user employs zero-knowledge proof technology.

[0106] Specifically, the data user extracts necessary public verification parameters (such as the policy public key, authorization constraints, and current remaining usage count) from the policy-ciphertext and extracts corresponding authorization information from the authorization certificate. The user inputs this public information, along with the authorization certificate as private evidence, into a zero-knowledge proof circuit. This circuit is designed to verify the authenticity of the authorization certificate and whether the request complies with the authorization constraints preset by the data provider. After the circuit is built, the user runs a zero-knowledge proof generation algorithm to produce a proof string. Subsequently, the data user submits this zero-knowledge proof, along with necessary public inputs (such as the policy-ciphertext identifier and current remaining usage count), to the verification node.

[0107] The first processing module 400 is used to reject the operation and record it when the verification fails.

[0108] The verification node responds to the verification result of the zero-knowledge proof. If the verification node outputs "verification failed", it means that the zero-knowledge proof submitted by the data user fails to meet the preset constraints. Possible reasons include: invalid authorization certificate signature, requested operation type exceeding the allowed range, application timestamp expired, authorized usage count exceeding the current remaining usage count, or the proof itself has been tampered with.

[0109] In this situation, the validator node rejects the computation request and prohibits the user from performing any homomorphic operations on the policy-encrypted text. Simultaneously, the validator node logs this failure event, including at least the timestamp of the failure, the identifier of the data user submitting the proof, and a summary of the type or reason for the failure. This record can be written to a local log or the blockchain for subsequent auditing and traceability by the data provider and regulators.

[0110] The second processing module 500 is used to perform homomorphic operations on the original ciphertext to obtain the result ciphertext when the verification is successful, generate a noise mask based on the single noise increment and superimpose it on the result ciphertext; and update the current remaining number of uses based on the number of authorized uses in the authorization certificate.

[0111] After receiving a "verification passed" result from the verification node, the data user is granted permission to perform homomorphic operations on the policy-bound ciphertext. At this point, the data user can perform the corresponding homomorphic operation on the original ciphertext in the policy-bound ciphertext according to the operation type declared in the authorization certificate (such as addition, multiplication, or summation) to obtain a result ciphertext that is also in ciphertext form.

[0112] Additionally, the data user needs to generate a noise mask based on the pre-calculated single noise increment and then overlay this mask onto the resulting ciphertext. The noise mask is generated in accordance with the rules for noise addition in homomorphic encryption schemes. Typically, it is obtained by randomly sampling a vector with the same dimension as the ciphertext from a specific noise distribution (such as a Gaussian distribution) and associating its norm with the single noise increment.

[0113] After the noise mask is superimposed onto the resulting ciphertext, a portion of the noise budget within the ciphertext is precisely consumed, equivalent to being billed for one use. After the calculation is complete, the data user updates the remaining usage count recorded in the policy-enabled ciphertext based on the authorized usage count in the authorization certificate (usually one, but can be multiple), i.e., subtracting the authorized usage count from the current remaining count. The updated remaining count reflects the number of authorized uses that the ciphertext can still perform. When the remaining count decreases to zero, the accumulated noise within the ciphertext will exceed the decryption threshold. Based on the mathematical properties of homomorphic encryption, the ciphertext will become permanently invalid, and any subsequent computation requests will no longer be able to pass verification.

[0114] Furthermore, after each homomorphic operation, noise injection, and remaining usage update, the data user writes a summary of the operation to the blockchain. This summary includes at least the user's identity hash (to protect privacy), the type of operation performed, the operation timestamp, the noise increment consumed, and the updated remaining usage count. The smart contract automatically stores this information as structured events, forming an immutable audit log.

[0115] Data providers can use the query interface provided by the blockchain to view the usage overview of their published policy-encrypted data at any time, such as the cumulative number of uses, remaining uses, and detailed records of each operation. Regulators can also access the audit interface to obtain complete operation logs and conduct compliance checks accordingly.

[0116] Furthermore, this method also supports authorization renewal and revocation. When a data provider wishes to extend the usage period of the data or increase the number of uses, they can submit a renewal request containing the new maximum number of uses and the new validity period and sign it. After the blockchain smart contract verifies the signature, it reads the actual remaining noise budget of the current ciphertext, recalculates the single noise increment based on the number of uses and the new maximum number of uses, and updates the policy parameters and remaining number of uses stored on the chain.

[0117] When a data provider needs to terminate authorization early, it can initiate a revocation operation. The smart contract will mark the state with the policy ciphertext as revoked. Afterward, any verification request for that ciphertext will be directly rejected, and the rejection event will also be recorded on the blockchain.

[0118] As an optional implementation, the multidimensional authorization constraint parameters include: maximum number of uses, set of allowed operation types, expiration time stamp, set of allowed uses, and noise attenuation factor.

[0119] The maximum number of uses, N_max, is a positive integer used to limit the total number of times the policy-enabled ciphertext can be authorized to perform homomorphic operations throughout its entire lifetime.

[0120] The allowed operation type set Op_set contains the types of homomorphic operations that the data provider allows the user to perform, such as addition, multiplication, summation, inner product, or linear transformation. Operation requests outside this set will be rejected.

[0121] The expiration time stamp T_expire sets the authorization time window; only computation requests initiated before the timestamp are considered valid.

[0122] The permitted uses set of Purposes can be used for compliance control at the business level, such as "statistical analysis", "regression modeling" or "risk control scoring". Before issuing a certificate, the authorization management platform will verify whether the purpose declared by the user belongs to this set.

[0123] The noise attenuation factor λ_noise is an adjustable coefficient used to fine-tune the calculation of a single noise increment. Data providers can flexibly control the rate at which the number of iterations is consumed based on the sensitivity of the data or the computational intensity.

[0124] Based on the above parameters, the multidimensional authorization constraint parameter P defined by the data provider can be expressed as P = (N_max, T_expire, Op_set, Purpose, λ_noise).

[0125] Furthermore, when generating the policy label encoding L, N_max, T_expire, Op_set, Purpose, and the initial noise budget are selected. The policy label encoding is then combined with the single noise increment Δ_noise, so L=H(N_max || T_expire || sort(Op_set) || Purpose || budget_0 || Δ_noise).

[0126] As an optional implementation, the single noise increment is calculated based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext, using the following formula: in, Indicates the noise increment in a single instance. Indicates the noise attenuation factor. Represents the initial noise budget ， Indicates the safety margin threshold. Indicates the maximum number of times it can be used.

[0127] Single noise increment This indicates the noise intensity that needs to be actively injected into the ciphertext after each authorized use; noise attenuation factor. It is an adjustable coefficient between 0.5 and 1.5 used to fine-tune the noise consumption rate based on data sensitivity or expected usage intensity; initial noise budget The security margin threshold is automatically determined by the homomorphic encryption scheme based on security parameters. The estimate used to absorb the inherent noise growth of homomorphic operations is typically a fixed percentage (e.g., 10%) of the initial noise budget. This indicates the maximum number of times the multidimensional authorization constraint parameter can be used.

[0128] The formula is designed based on the following principle: the initial available noise budget of the original ciphertext (after deducting the safety margin) is evenly divided according to the maximum number of uses to obtain the base noise increment, which is then multiplied by a noise attenuation factor to provide flexible adjustment capabilities. In this way, it is injected after each authorized use. The noise level increases with the number of uses. At that point, the total noise within the ciphertext will just exceed the decryption threshold, causing the ciphertext, based on the mathematical principles of homomorphic encryption, to permanently fail. If If the number of failures is greater than 1, then the actual number of failures is less than 1. To achieve stricter control over the number of times; if If the number of failures is less than 1, then the actual number of failures is greater than 1. To provide a certain degree of tolerance.

[0129] As an optional implementation method, Figure 5 This is a schematic diagram of the zero-knowledge proof generation module provided in an embodiment of the present invention, as shown below. Figure 5 As shown, the zero-knowledge proof generation module 300 includes: The first data acquisition submodule 3001 is used to acquire the set of allowed operation types, the expiration time stamp, and the policy public key from the policy ciphertext.

[0130] Data users can directly read three public parameters from the policy-encrypted text: the set of allowed operation types Op_set, the expiration time stamp T_expire, and the policy public key pk_policy.

[0131] The second data acquisition submodule 3002 is used to obtain the request operation type, application timestamp and authorized usage count from the authorization certificate; wherein, the authorization certificate is issued by the policy private key and the authorized usage count is less than or equal to the current remaining usage count.

[0132] The authorization certificate issued by the authorization management platform is cert = Sign_{sk_policy}(U_id || Op_req ||t_apply || N_grant), which includes the identity of the data user, the type of requested operation, the application timestamp, and the number of authorized uses. Where N_grant ≤ N_remaining.

[0133] The zero-knowledge proof generation submodule 3003 is used to construct a zero-knowledge proof circuit and generate a zero-knowledge proof based on the circuit. The circuit executes signature verification constraints, validity period constraints, operation type constraints, and number of times constraints. Among them, the signature verification constraint uses the policy public key to verify the signature of the authorization certificate; the validity period constraint requires that the application timestamp is not later than the validity period expiration timestamp; the operation type constraint requires that the requested operation type belongs to the set of allowed operation types; and the number of times constraint requires that the authorized number of times is greater than zero.

[0134] The data user first constructs an R1CS circuit based on the set of allowed operation types, expiration timestamp, and policy public key extracted from the policy ciphertext, as well as the requested operation type, application timestamp, and authorized usage count extracted from the authorization certificate. This circuit is designed to enforce the following four types of constraints: First, signature verification constraints. The circuit uses the policy public key to verify the digital signature of the authorization certificate, ensuring that the certificate was indeed issued by the authorization management platform holding the policy private key, thereby preventing certificate forgery or tampering with the certificate content.

[0135] Second, validity period constraints. The circuit compares the application timestamp in the license certificate with the validity expiration timestamp set in the policy, requiring that the application timestamp be no later than the validity expiration timestamp, thereby preventing expired licenses from being used.

[0136] Third, operation type constraints. The circuit checks whether the requested operation type declared in the authorization certificate belongs to the set of allowed operation types in the policy ciphertext, ensuring that the user can only perform operations that the data provider has previously permitted (e.g., only addition is allowed and multiplication is not).

[0137] Fourth, the usage limit. The circuit verifies whether the authorized usage count in the authorization certificate is greater than zero, that is, to ensure that this request contains at least one valid usage quota. It should be noted that the usage limit is usually also compared with the current remaining usage count (this comparison has been completed by the verification node through public input), and the circuit mainly ensures that the authorized usage count is positive.

[0138] After the circuit is constructed, the data user runs a zero-knowledge proof generation algorithm, using the authorization certificate as private evidence and the aforementioned public parameters as public input, to generate a very short zero-knowledge proof string, which is then sent to the verification node. The verification node then verifies the proof using a verification key; if successful, subsequent homomorphic operations are allowed.

[0139] Zero-knowledge proof schemes include Groth16, PLONK, Bulletproofs protocols, or similar non-interactive zero-knowledge proof protocols. Taking Groth16 as an example, the proof length is approximately 200 bytes, and the verification time is in the sub-millisecond range.

[0140] As an optional implementation method, Figure 6 This is a schematic diagram of the structure of the second processing module provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the second processing module 500 includes: The adjustment coefficient determination submodule 5001 is used to determine the noise adjustment coefficient corresponding to the current operation type.

[0141] The data user first identifies the specific type of homomorphic operation being performed, such as addition, multiplication, summation, inner product, or linear transformation.

[0142] Different types of operations consume the internal noise budget of the ciphertext at different rates: linear operations such as addition cause noise growth relatively slowly, while nonlinear operations such as multiplication cause noise growth relatively quickly (usually quadratic growth). To ensure that the effective noise budget consumed in each authorized use is approximately equal, thereby precisely controlling the total number of uses, this embodiment introduces a noise adjustment coefficient. This coefficient is a value associated with the operation type and is used to adjust the actual injection intensity of a single noise increment, preventing premature invalidation of the ciphertext in multiplication-intensive scenarios.

[0143] Specifically, for operation types with slow inherent noise growth (such as addition, summation, and linear transformation), the noise adjustment coefficient is set to a relatively large value, for example, 1.0; for operation types with fast inherent noise growth (such as multiplication and inner product), the noise adjustment coefficient is set to a relatively small value, for example, 0.6 or 0.8.

[0144] The target noise norm calculation submodule 5002 is used to calculate the target noise norm based on the single noise increment and the noise adjustment coefficient.

[0145] Single noise increment With noise adjustment factor Multiplying them together yields the target noise norm.

[0146] For operations with slow inherent noise growth (such as addition), the adjustment coefficient is close to 1, and the target noise norm is close to the baseline value. For operations with fast inherent noise growth (such as multiplication), the adjustment coefficient is less than 1, and the target noise norm is reduced accordingly. This avoids premature ciphertext invalidation caused by the large noise growth from multiplication itself combined with injected noise. Conversely, if it is desired to more strictly limit the number of operations, an adjustment coefficient greater than 1 can be used.

[0147] The random mask vector calculation submodule 5003 is used to randomly generate a random mask vector with the same dimension as the result ciphertext, and uses the target noise norm as the L2 norm of the random mask vector.

[0148] The data user generates a random mask vector of the same dimension as the ciphertext (e.g., the length of the vector or the degree of the polynomial contained in the ciphertext). Each element of this vector is independently and randomly sampled from a specific noise distribution (e.g., a Gaussian or sub-Gaussian distribution) to ensure the unpredictability and statistical uniformity of the mask.

[0149] After generating the initial random vector, its length is normalized and adjusted so that the L2 norm of the vector (i.e. the square root of the sum of squares of each element) is precisely controlled to be the target noise norm.

[0150] The noise superposition submodule 5004 is used to superimpose a random mask vector onto the first component of the resulting ciphertext.

[0151] The data user performs a vector addition operation between the random mask vector (mask) and the resulting ciphertext obtained after homomorphic operations. However, this addition operation only applies to the first component of the ciphertext. Taking the typical CKKS homomorphic encryption scheme as an example, a ciphertext usually consists of two polynomial components, represented as (c0, c1). The first component c0 is the main data carrier of the ciphertext, while the second component c1 is used in conjunction with the private key for decryption calculations. In this embodiment, only the random mask vector is added to the c0 component, while keeping the c1 component completely unchanged, resulting in the updated first component C_updated[·][0] = C_result[·][0] + mask.

[0152] The technical effect of doing this is: First, the ciphertext structure of CKKS is (c0, c1), and the decryption calculation is c0 + c1·s. Adding noise only to c0 does not change the structural integrity of c1; therefore, the homomorphic multiplication structure of the ciphertext is not destroyed—the multiplication operation relies on the cross-product of the two ciphertext components, and c1 remaining unchanged ensures the correctness of the multiplication result. If noise is injected into both components simultaneously, the cross-terms will multiply, accelerating ciphertext invalidation and making it impossible to precisely control the number of uses.

[0153] Second, the random mask vector is sampled from a Gaussian distribution (or a near-Gaussian sub-Gaussian distribution), and its L2 norm is precisely controlled to be... × The introduction of Gaussian noise mask does not compromise the IND-CPA security of the CKKS scheme under the RLWE (Ring Learning With Errors) assumption: the semantic security of the CKKS scheme relies on the indistinguishability of the ciphertext noise. The injected additional Gaussian mask is in the same distribution as the original encryption noise and does not add any exploitable statistical bias. Therefore, the security level of the ciphertext remains unchanged.

[0154] Third, after the noise mask is superimposed, the decryption noise becomes e + mask, and the expected noise increase is exactly 1 / 2. · Consistent with the design. Multiplication compatibility conditions. ·n< Determined by budget_0, its magnitude is much smaller than the modulus q).

[0155] At this point, the noise budget of the encrypted text has been consumed precisely according to the preset value, which is equivalent to completing a billing operation for authorized use. Specific Implementation Example 1: Scenario Description: The city's Big Data Bureau encrypts and publishes the city's corporate tax statistics data to a public data authorization platform, authorizing certified university research teams to conduct statistical analysis.

[0157] Participants: Data owner: Municipal Big Data Bureau; Data user: University research team; Authorization management platform: Municipal Public Data Authorization and Operation Platform; Verification node: Government Alliance Chain Smart Contract.

[0158] Parameter configuration (see Table 1):

[0159] Table 1 The process is as follows: ​Ciphertext Generation: The Big Data Bureau encrypts the plaintext vector of enterprise tax statistics (100,000 records) using CKKS to generate the original ciphertext C0, obtaining budget_0 = 2^42 (example). The single-instance noise increment Δ_noise is calculated as 1.0 × (2^42 - 2^39) / 50 ≈ 2^35.6. A policy label L and an EdDSA policy key pair are generated, and the policy-enabled ciphertext C_policy is output and published to the platform.

[0160] Here, budget_0=2^42 is just an example value. The actual value depends on the specific parameter configuration of the homomorphic encryption scheme (such as the polynomial modulus n, the modulus q, etc.).

[0161] Authorization Verification: The research team applies for SUM operation permissions. The authorization platform issues an authorization certificate (N_grant=10). A zero-knowledge proof π is generated (approximately 12,280 gates in the R1CS circuit: 12,000 gates for EdDSA verification + 200 gates for operation type determination + 50 gates for timestamp comparison + 30 gates for count determination). Groth16 proof generation takes approximately 0.8 seconds, and the proof is approximately 200 bytes. On-chain verification takes approximately 8 milliseconds; upon successful verification, an authorization token is obtained.

[0162] Homomorphic operation: Perform the sum operation using the authorization token, inject a noise mask (|mask|=2^35.6×1.0), and update N_remaining to 49.

[0163] On-chain audit: The operation record (using the hash of the operation, the sum of the operation type, the noise change from 42 to 38, and the remaining number of times 49) is written to the consortium chain.

[0164] After 50 uses, the accumulated noise exceeds the threshold, and the ciphertext becomes irreversibly invalid based on mathematical principles. Specific Implementation Example 2: Scenario Description: Multiple top-tier hospitals share encrypted patient statistical characteristics (de-identified and aggregated into group-level data) and authorize the Center for Disease Control and Prevention to conduct epidemiological regression analysis.

[0166] Participants: Data owner: Top-tier hospital; Data user: Center for Disease Control and Prevention; Authorization management platform: Public data authorization platform; Verification node: Medical consortium blockchain smart contract.

[0167] Parameter configuration (see Table 2):

[0168] Table 2 The process is as follows: Multiple hospitals, individually or jointly, generate ciphertext with a strategy. In the strategy, N_max=200, Op_set includes add, multiply, and dot_product, and the BLS aggregation signature scheme is used.

[0169] The CDC applies for an authorization certificate, and the authorization management platform issues the certificate after verifying its qualifications. The requested operation type is the various operations required for regression analysis.

[0170] The CDC uses the PLONK protocol to generate zero-knowledge proofs and submits them to the medical consortium blockchain smart contract for verification.

[0171] After successful verification, the CDC performs homomorphic regression calculations on the encrypted text (such as calculating the covariance matrix and solving the regression coefficients). After each execution, the CDC selects the corresponding noise adjustment coefficient according to the operation type (1.0 for addition, 0.6 for multiplication, and 0.8 for inner product), injects the corresponding noise mask, and updates the remaining number of executions.

[0172] All computational records are uploaded to the blockchain for auditing by hospitals and regulatory agencies.

[0173] The encrypted message will automatically expire after 200 uses.

[0174] Key Design Considerations: Since the Op_set allows multiplication (`multiply`) and dot-product (`dot_product`) operations, these operations exhibit quadratic noise growth characteristics. This means that each multiplication operation consumes the ciphertext noise budget faster than addition. To ensure the ciphertext only becomes invalid after N_max = 200 uses, the adjustment factor `n_multiply` for multiplication is set to 0.6, and the adjustment factor `n_dot_product` for dot-product is set to 0.8. This reduces the amount of actively injected noise during actual multiplication or dot-product operations, thus providing budget space for the inherent noise of the operations themselves. Setting `n_multiply = 0.6` and `n_dot_product = 0.8` provides budget space for inherent noise.

[0175] Based on the typical computational ratio of regression analysis tasks (assuming 50% addition, 30% multiplication, and 20% inner product), the total noise just exceeds the decryption threshold on the 200th use, and the ciphertext becomes irreversibly invalid based on mathematical principles. Specific Implementation Example 3: Scenario Description: In Example 1 (Authorized Analysis of Government Statistical Data), the Big Data Bureau needs to renew the data.

[0177] Process: The Big Data Bureau submits a new maximum usage count (e.g., 100 times) and a new expiration date (e.g., June 30, 2027). After the blockchain smart contract verifies the data provider's signature, it reads the actual remaining noise budget `budget_current` from the current encrypted data. Based on the number of times it has been used and the new maximum usage count, it recalculates the single-use noise increment `Δ_noise_new = (budget_current - δ_safety) / (100 - N_used)` and updates the policy parameters and remaining usage count stored on the chain. Afterward, the user needs to reapply for an authorization certificate based on the new policy parameters. Specific Implementation Example 4: Scenario Description: Multiple banks share their respective risk control feature data (anonymized and aggregated into group-level indicators) after encryption, and authorize a joint modeling center to calculate credit risk scores.

[0179] Participants: Data owners: multiple banks (joint data providers); users: joint modeling center; authorization management platform: financial data authorization operation platform; verification node: financial consortium blockchain smart contract.

[0180] Parameter configuration (see Table 3; other parameters not shown are set according to actual conditions):

[0181] Table 3 The process is as follows: Each bank will use CKKS encryption to generate the original ciphertext from the de-identified and aggregated risk control feature data (such as customer historical transaction statistics, default rate indicators, etc.), set an authorization policy (maximum number of uses 100 times, allowed operation types include addition, multiplication, inner product and linear transformation), generate policy-enabled ciphertext and publish it.

[0182] The Joint Modeling Center applies for an authorization certificate from the authorization management platform, stating that its purpose is "risk control modeling" and requesting operation types including linear transformation, inner product, etc. (for logistic regression or neural network inference).

[0183] After the authorization management platform approves the application, it issues a certificate, and the center generates a zero-knowledge proof which is then submitted to the financial consortium blockchain smart contract for verification.

[0184] After successful verification, the center performs homomorphic operations on the encrypted text, such as calculating a linear combination of credit scores or forward propagation of a neural network. After each operation, a corresponding noise adjustment coefficient is selected based on the operation type, a noise mask is injected, and the remaining number of uses is updated.

[0185] All computational records are stored on the blockchain, making them auditable by banks and regulatory agencies.

[0186] The encrypted message will automatically expire after 100 uses.

[0187] Key Design: This embodiment demonstrates that the present invention is applicable to complex machine learning inference scenarios. It not only supports simple addition and multiplication, but also inner product and linear transformation. It can be applied to logistic regression prediction, neural network forward propagation, etc. At the same time, the noise adjustment coefficient ensures that the number of times it is used under different types of operations is precisely controllable. Specific Implementation Example 5: In Example 2 (Joint Epidemiological Study by Medical Institutions), if a user (such as a CDC) exceeds the permitted computational range (e.g., performs a multiplication operation prohibited by policy), the data provider (multiple hospitals) can urgently initiate a revocation operation. The blockchain smart contract marks the corresponding ciphertext as "revoked." Thereafter, any authorization verification request for that ciphertext will be directly rejected, even if the data user has a local cached copy of the ciphertext, it will no longer be able to pass verification or perform legitimate homomorphic operations. The revocation event is simultaneously recorded on the blockchain for regulatory auditing. Specific Implementation Example Six: As the regulator, the Municipal Data Bureau conducts quarterly compliance audits on the authorized use of a certain encrypted document.

[0190] The regulator invoked the audit query interface of the blockchain smart contract, inputting a ciphertext identifier and a time range to obtain the complete computation log. The log contains information such as the user's identity hash, computation type, noise budget changes, remaining computation timestamps, etc. for each computation.

[0191] Based on this, the regulator will verify whether all users operated within the validity period, whether the actual types of operations performed were all within the allowed set of operation types, whether the total number of uses did not exceed the maximum number of uses, and whether there were any records of illegal operations after the authorization was revoked.

[0192] A compliance report is generated based on the audit results, serving as the regulatory basis for the authorized operation of public data.

[0193] The above technical solution has the following beneficial effects: by embedding the authorization strategy into the ciphertext structure and binding it to the original ciphertext for publication, the integration of authorization and ciphertext is achieved, eliminating the possibility of ciphertext misuse from the root; by utilizing the noise budget characteristic of homomorphic encryption, the number of uses is transformed into a noise increment that can be precisely consumed, and the ciphertext is permanently invalidated based on mathematical principles when the number of uses is exhausted, ensuring the cryptographic-level unbreakable nature of the use limit constraint; by introducing zero-knowledge proof technology, the data user can complete the authorization verification without exposing their identity, certificate plaintext, and computational intent, thus achieving privacy protection in the authorization process.

[0194] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A controllable homomorphic encrypted data sharing method, characterized in that, include: The data provider performs homomorphic encryption on the local data to obtain the original ciphertext and generates multidimensional authorization constraint parameters corresponding to the original ciphertext; wherein, the multidimensional authorization constraint parameters include the maximum number of uses, and the maximum number of uses is used as the initial current remaining number of uses; The data provider generates the corresponding policy public key and policy private key, calculates the single noise increment based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext, and binds the single noise increment, multidimensional authorization constraint parameters, policy public key and original ciphertext into policy-enabled ciphertext and publishes it. The data user obtains an authorization certificate, generates a zero-knowledge proof based on the authorization certificate and policy-encrypted text, and submits it to the verification node for verification. If the verification fails, the operation is rejected and recorded. When the verification is successful, the data user performs a homomorphic operation on the original ciphertext to obtain the result ciphertext, generates a noise mask based on the single noise increment and superimposes it on the result ciphertext; and updates the current remaining usage count according to the authorized usage count in the authorization certificate.

2. The controllable homomorphic encrypted data sharing method according to claim 1, characterized in that, The multidimensional authorization constraint parameters include: maximum number of uses, set of allowed operation types, expiration time stamp, set of allowed uses, and noise attenuation factor.

3. The controllable homomorphic encrypted data sharing method according to claim 2, characterized in that, The single noise increment is calculated based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext, using the following formula: in, Indicates the noise increment in a single instance. Indicates the noise attenuation factor. Represents the initial noise budget ， Indicates the safety margin threshold. Indicates the maximum number of times it can be used.

4. The controllable homomorphic encrypted data sharing method according to claim 2, wherein generating zero-knowledge proofs based on the authorization certificate and policy-based ciphertext includes: Retrieve the set of allowed operation types, expiration timestamp, and policy public key from the policy ciphertext; Obtain the request operation type, application timestamp, and authorized usage count from the authorization certificate; wherein the authorization certificate is issued by the policy private key, and the authorized usage count is less than or equal to the current remaining usage count; A zero-knowledge proof circuit is constructed, and a zero-knowledge proof is generated based on the circuit. The circuit executes signature verification constraints, validity period constraints, operation type constraints, and number of times constraints. The signature verification constraint uses the policy public key to verify the signature of the authorization certificate. The validity period constraint requires that the application timestamp is not later than the validity period expiration timestamp. The operation type constraint requires that the requested operation type belongs to the set of allowed operation types. The number of times constraints require that the authorized usage count is greater than zero.

5. The controllable homomorphic encrypted data sharing method according to claim 1, characterized in that, The step of generating a noise mask based on the single noise increment and superimposing it onto the resulting ciphertext includes: Determine the noise adjustment coefficient corresponding to the current operation type; The target noise norm is calculated based on the single noise increment and the noise conditioning coefficient. A random mask vector with the same dimension as the ciphertext of the result is randomly generated, and the target noise norm is used as the L2 norm of the random mask vector; The random mask vector is superimposed on the first component of the resulting ciphertext.

6. A controllable homomorphic encrypted data sharing system, characterized in that, include: The constraint parameter definition module is used by the data provider to perform homomorphic encryption on local data to obtain the original ciphertext and generate multidimensional authorization constraint parameters corresponding to the original ciphertext; wherein, the multidimensional authorization constraint parameters include the maximum number of uses, and the maximum number of uses is used as the initial current remaining number of uses; The policy-enabled ciphertext generation module is used by the data provider to generate the corresponding policy public key and policy private key, calculate the single noise increment based on the initial noise budget and multi-dimensional authorization constraint parameters corresponding to the original ciphertext, bind the single noise increment, multi-dimensional authorization constraint parameters, policy public key and original ciphertext into policy-enabled ciphertext and publish it. The zero-knowledge proof generation module is used by the data user to obtain an authorization certificate, generate a zero-knowledge proof based on the authorization certificate and policy-included ciphertext, and submit it to the verification node for verification. The first processing module is used to reject the operation and record the result when the verification fails. The second processing module is used to perform a homomorphic operation on the original ciphertext to obtain the result ciphertext when the verification is successful, generate a noise mask based on the single noise increment and superimpose it on the result ciphertext; and update the current remaining number of uses based on the number of authorized uses in the authorization certificate.

7. The controllable homomorphic encrypted data sharing system according to claim 6, characterized in that, The multidimensional authorization constraint parameters include: maximum number of uses, set of allowed operation types, expiration time stamp, set of allowed uses, and noise attenuation factor.

8. The controllable homomorphic encrypted data sharing system according to claim 7, characterized in that, The single noise increment is calculated based on the initial noise budget and multidimensional authorization constraint parameters corresponding to the original ciphertext, using the following formula: in, Indicates the noise increment in a single instance. Indicates the noise attenuation factor. Represents the initial noise budget ， Indicates the safety margin threshold. Indicates the maximum number of times it can be used.

9. The controllable homomorphic encrypted data sharing system according to claim 7, characterized in that, The zero-knowledge proof generation module includes: The first data acquisition submodule is used to obtain the set of allowed operation types, the expiration time stamp, and the policy public key from the policy ciphertext. The second data acquisition submodule is used to acquire the request operation type, application timestamp, and authorized usage count from the authorization certificate; wherein the authorization certificate is issued by the policy private key, and the authorized usage count is less than or equal to the current remaining usage count; A zero-knowledge proof generation submodule is used to construct a zero-knowledge proof circuit and generate a zero-knowledge proof based on the circuit. The circuit executes signature verification constraints, validity period constraints, operation type constraints, and number of times constraints. The signature verification constraint uses the policy public key to verify the signature of the authorization certificate. The validity period constraint requires that the application timestamp is not later than the validity period expiration timestamp. The operation type constraint requires that the requested operation type belongs to the allowed operation type set. The number of times constraints require that the authorized usage count is greater than zero.

10. The controllable homomorphic encrypted data sharing system according to claim 6, characterized in that, The second processing module includes: The adjustment coefficient determination submodule is used to determine the noise adjustment coefficient corresponding to the current operation type; The target noise norm calculation submodule is used to calculate the target noise norm based on the single noise increment and the noise adjustment coefficient. The random mask vector calculation submodule is used to randomly generate a random mask vector with the same dimension as the ciphertext of the result, and uses the target noise norm as the L2 norm of the random mask vector. The noise superposition submodule is used to superimpose the random mask vector onto the first component of the resulting ciphertext.

Images