A zero trust based threat intelligence bounty method with privacy protection

Abstract

The application discloses a threat intelligence bounty method with privacy protection based on zero trust. First, the buyer publishes the task and configures the authorized capability label and threshold, and the system generates the authorized token, which is split into corresponding shares based on the Shamir algorithm, and is implicitly encoded into a public authorization structure using OKVS. Second, the seller completes anonymous identity authentication by generating zero-knowledge proof with verifiable credentials, and decodes the public structure with local labels to restore the valid authorized shares. Finally, when the number of shares reaches the set threshold, the seller restores the authorized token based on the Lagrange interpolation, and confirms the order qualification after passing the commitment value verification, and synchronously binds the subsequent task state. The application realizes fine-grained and verifiable trusted authorization without exposing the complete capability label of the seller and the core authorization strategy of the buyer, significantly improving the privacy protection level and security of the platform.

Description

Technical Field

[0001] This invention relates to the fields of network security, threat intelligence sharing, privacy computing, and access control, and in particular to a threat intelligence bounty privacy authorization method based on zero-trust architecture, verifiable credentials, zero-knowledge proofs, OKVS privacy coding, and Shamir threshold secret sharing. Background Technology

[0002] Threat intelligence bounties are a crucial mechanism in collaborative cybersecurity defense. With the continuous emergence of complex attacks such as Advanced Persistent Threats (APTs), supply chain attacks, ransomware, and zero-day vulnerabilities, single organizations often struggle to promptly identify and analyze all security risks. Threat intelligence bounty platforms attract qualified security researchers by issuing tasks such as vulnerability discovery, malware sample analysis, attack chain tracing, and threat intelligence submission, thereby enhancing vulnerability discovery, attack warning, and security response capabilities.

[0003] However, in practical applications, threat intelligence bounty platforms face significant challenges in terms of both authorization credibility and privacy protection.

[0004] First, seller capabilities are easily exposed. Existing threat intelligence bounty platforms mostly employ traditional access control mechanisms such as RBAC, ABAC, and ACL, centrally storing seller identity information, capability tags, historical achievements, and permission mappings. When a seller applies for a job, they typically need to submit relatively complete capability tags or qualification information to the platform, which then matches them according to the buyer's preset policies. This approach easily allows the platform to maintain long-term access to the seller's professional capabilities, research directions, and business profile. If the platform's database is leaked or internal permissions are abused, the seller's private information may be exposed.

[0005] Secondly, the buyer's authorization strategy is easily leaked. Bounty missions typically involve sensitive information such as attack targets, vulnerability types, technical approaches, and analysis directions. The authorization capability tags and threshold conditions set by the buyer often reflect the difficulty of the mission, the scope of the target, and the security requirements. If the buyer's authorization strategy is stored in plaintext or centrally maintained by the platform, attackers may infer the buyer's true bounty intentions and the sensitive direction of the mission by stealing strategy data, analyzing permission mapping relationships, or repeatedly probing the order acceptance results.

[0006] Furthermore, current authorization results are typically only reflected as a "pass" or "reject" status on the platform side, lacking verifiable cryptographic authorization evidence. If the platform is attacked, or if internal personnel tamper with the permission status, it could lead to problems such as unauthorized order acceptance, forged authorization status, and policy inference. Although some platforms have introduced technologies such as digital certificates, verifiable credentials, and zero-knowledge proofs to enhance the credibility of identity authentication, identity authentication can only prove that the participant has legitimate qualifications; it still makes it difficult to complete fine-grained capability authorization without exposing complete capability tags and complete authorization policies.

[0007] Therefore, there is an urgent need for a threat intelligence bounty method that can achieve privacy-preserving authorization under a zero-trust architecture. This method would allow sellers to avoid exposing their full capability labels to the platform, buyers to avoid disclosing their full authorization policies, and the platform to avoid maintaining plaintext permission mapping relationships. At the same time, it would still be able to reliably verify whether sellers meet the authorization conditions of the current bounty task, thereby improving the privacy protection capabilities, authorization credibility, and overall security of the threat intelligence bounty platform. Summary of the Invention

[0008] The purpose of this invention is to provide a zero-trust, privacy-protected threat intelligence bounty method, which aims to overcome the shortcomings of existing threat intelligence bounty platforms, such as the easy exposure of seller capability tags, the easy leakage of buyer authorization strategies, the reliance on centralized permission mapping, and the lack of verifiable evidence for order acceptance authorization results. Without disclosing the complete capability tags of sellers and the complete authorization strategies of buyers, it achieves credible verification of bounty task acceptance qualifications and minimal information disclosure.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a zero-trust-based threat intelligence bounty method with privacy protection, the threat intelligence bounty method comprising the following steps:

[0010] S1.1: The buyer issues a threat intelligence bounty mission, configuring the authorized capability tag set, authorization threshold, policy random salt, and policy version information;

[0011] S1.2: The buyer or the authorization management platform generates a bounty authorization token τ corresponding to the current bounty task, calculates the token commitment value tauCommitment, maps τ to a finite field secret tauField, generates a field commitment value tauFieldCommitment, and generates an authorization share corresponding to each capability tag in the authorization capability tag set based on the Shamir threshold secret sharing algorithm.

[0012] S1.3: Generate an OKVS query key based on the task identifier, policy random salt, and capability tag, and implicitly encode the OKVS query key with the corresponding authorization share to generate an OKVS public authorization structure E and an authorization structure digest H. EPolicy Commitment, encryptedTau (authorization token wrapper), and authorization policy integrity commitment (C);

[0013] S1.4: The seller proves to the platform that it has the legal qualifications to participate based on the verifiable certificate VC or zero-knowledge proof envelope issued by the platform, and does not disclose the complete set of capability tags;

[0014] S1.5: The seller uses local capability tags to generate candidate OKVS query keys and decodes the OKVS public licensing structure to restore the set of valid licensing shares that match its own capability tags;

[0015] S1.6: When the number of shares in the set of valid authorized shares reaches the authorization threshold, the candidate finite field secret tauField is recovered based on the Lagrange interpolation algorithm. ' and based on tauField ' Unpack the ciphertext encryptedTau of the authorization token to obtain the candidate bounty authorization token τ. ' ;

[0016] S1.7: Verify the candidate tauField based on tauFieldCommitment and tauCommitment respectively. ' and candidate bounty authorization token τ ' Is it correct?

[0017] S1.8: If the verification is successful, the seller is confirmed to be qualified to accept the current bounty task, and the authorization result is bound to the task identifier, the seller's anonymous identity, the strategy version, and the authorization status.

[0018] 1. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 1, characterized in that step S1.1 specifically includes the following steps:

[0019] S1.1: The buyer determines the set of authorized capability tags P corresponding to the current bounty mission based on the mission type, sensitivity level, technical difficulty, and expected results of the threat intelligence bounty mission. Among them, L i This represents the i-th authorized capability tag, and n represents the number of authorized capability tags; the authorized capability tags are used to characterize the professional capabilities, qualification types, or task adaptability required for the seller to participate in the current bounty task.

[0020] S1.2: The buyer configures an authorization threshold t based on the authorization capability tag set P, where the authorization threshold t represents the minimum number of valid authorization shares required for the seller to obtain the qualification to accept the current bounty task, and satisfies: When t=1, it means that the seller can enter the subsequent authorization process if any one of the authorization capability tags is met; when t=n, it means that the seller needs to meet all the authorization capability tags before entering the subsequent authorization process.

[0021] S1.3: The buyer or the authorization management platform generates a unique task identifier bountyId for the current bounty task. The task identifier bountyId is used to distinguish different threat intelligence bounty tasks and is used for subsequent bounty authorization token generation, OKVS query key generation, authorization share binding and token commitment verification.

[0022] S1.4: The buyer or the authorization management platform generates a policy random salt (policySalt) for the current bounty task. The policy random salt (policySalt) is used to participate in the generation of capability tag query keys, so that the same capability tag generates different OKVS query keys in different bounty tasks, thereby preventing attackers from inferring the buyer's authorization policy through cross-task key-value association.

[0023] S1.5: The buyer or the authorization management platform generates a policy version number, policyVersion, which identifies the authorization policy version corresponding to the current authorization capability tag set P, authorization threshold t, policy random salt policySalt, and bounty authorization token τ. When the buyer modifies the authorization capability tag set, authorization threshold, policy random salt, task authorization validity period, or capability tag version, the system increments or regenerates policyVersion and triggers the bounty authorization token τ corresponding to the current policy version. policy The token random salt (tokenSalt), token commitment value (tauCommitment), Shamir authorization share, and OKVS public authorization structure are regenerated, while the authorization status records corresponding to the old policy version are marked as invalid, revoked, or replaced.

[0024] S1.6: The buyer or the authorization management platform combines the authorization capability tag set P, authorization threshold t, task identifier bountyId, policy random salt policySalt, and policy version number policyVersion into the authorization policy parameter Policy for the current bounty task:

[0025] The authorization policy parameter is used for subsequent generation of bounty authorization tokens, Shamir authorization share generation, and construction of the OKVS public authorization structure.

[0026] 2. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 2, characterized in that step S1.2 specifically includes the following steps:

[0027] S2.1: The buyer or the authorization management platform generates a random bounty authorization token τ based on the current task identifier bountyId and the current policy version policyVersion. policy It generates a random salt token (tokenSalt); different strategy versions correspond to different bounty authorization tokens (τ). policy Tokens corresponding to the old strategy version cannot be used in the order acceptance, submission or reward process of the new strategy version;

[0028] S2.2: Calculate the token commitment value tauCommitment based on the bounty authorization token τ, the task identifier bountyId, and the token random salt tokenSalt: Where H(·) is a cryptographic hash function, and tauCommitment is used for subsequent verification of whether the recovered candidate bounty authorization token is correct;

[0029] S2.3: Map the bounty authorization token τ to a finite field secret tauField: Where p is the modulus of the finite field, tauField=H_to_Fp("hunter-tau-field:" || τ);

[0030] S2.4: Construct the Shamir secret sharing polynomial f(x) of degree t−1 based on the authorization threshold t: Among them, a1 to a t−1 Let f(0) be the coefficients of a polynomial randomly selected within a finite field, and f(0) = tauField;

[0031] S2.5: For each capability tag L in the authorized capability tag set P i Generate a unique non-zero x-coordinate. i : Among them, Canonicalize(L i ) indicates the ability label L i Standardize the process;

[0032] S2.6: Calculate the corresponding secret share y based on the Shamir secret sharing polynomial f(x). i :

[0033] S2.7: Set the x-coordinate... i and secret share y i Composition and Ability Labels L i Corresponding authorized share: Share i = (x i , y i )

[0034] S2.8: Based on the finite field secret tauField, task identifier bountyId, policy version policyVersion, and token random salt tokenSalt, generate the field commitment value tauFieldCommitment: Among them, tauFieldCommitment is used to verify whether the finite field secret obtained by Lagrange interpolation is correct, and together with the subsequent OKVS public grant structure digest HE, it participates in the generation of grant policy integrity commitment and grant token wrapper ciphertext.

[0035] 3. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 3, characterized in that step S1.3 specifically includes the following steps:

[0036] S3.1: Perform normalization processing on each capability tag Li in the authorized capability tag set P to obtain a normalized capability tag Li*:

[0037] S3.2: Based on the task identifier bountyId, the policy random salt policySalt, and the standardized capability label L i * Calculate the corresponding OKVS query key k i :

[0038] S3.3: Will be related to the ability tag L i The corresponding authorized share is encapsulated as an authorized share payload v i : Among them, tag versionFor capability tag version information, check i This is a share integrity check value generated based on the current task context, used to filter invalid shares from OKVS misinterpreted codes, random collisions, or abnormally constructed ones.

[0039] In another implementation, check i Message authentication codes can be used for calculation:

[0040] S3.4: Use OKVS query key k i As a key, with authorized share payload v i As the value, construct the OKVS encoding set D:

[0041] S3.5: Use the OKVS encoding algorithm to encode the OKVS encoding set D to generate the OKVS public license structure E:

[0042] The OKVS public license structure E satisfies the following correctness and anti-misinterpretation constraints: For any (k) i , v i )∈D,OKVS.Decode(E, k i )=v i ; For any k ∉ {k i | (k i , v i )∈D}, Pr[VerifyShare(OKVS.Decode(E, k))=1]≤negl(λ). Where λ is the security parameter, m is the OKVS structural parameter, and negl(λ) represents a negligible function with respect to λ; the above constraints indicate that a matching query key can stably recover the corresponding authorized share payload, while a non-matching query key, even if it generates a candidate decoding result, will have difficulty passing the share integrity check; The input to the OKVS encoding algorithm is the OKVS encoding set D = {(k i , v i The process involves taking the OKVS query key k, the security parameter λ, and the OKVS structure parameter m, and outputting the OKVS public authorization structure E. The processing includes: based on each OKVS query key k... i Calculate one or more storage locations or linear equations to obtain the corresponding authorized share load v iAs the right-hand side of the equation, the encoded array, seed, hash function identifier, and structure parameters are obtained by solving the equation, and these are combined into E, such that any key k holding a matching query key... i One side can obtain v by E decoding. i The party that does not hold the matching query key cannot reliably obtain the authorized share payload that passes the integrity check;

[0043] In one embodiment, the OKVS encoding algorithm employs PaXoS, GBF (Blurred Bloom Filter), or an equivalent decodeable privacy key-value encoding structure; in the demonstration implementation, E can also be represented as shares[] containing a key digest, value payload, and structure digest, as long as it satisfies the same input, output, and decoding verification interfaces;

[0044] S3.6: Calculate the license structure digest H based on the OKVS public license structure E. E The authorization policy integrity commitment C is generated by combining the token commitment values ​​tauCommitment, tauFieldCommitment, the encryptedTau wrapped in the authorization token, and the policy version information. Wherein, Serialize(E) represents the deterministic serialization of the OKVS public authorization structure E; policyCommitment is used to bind the current task, policy version, authorization structure digest, and threshold parameters; encryptedTau is used to avoid directly publicizing the bounty authorization token τ; authorization policy integrity commitment C is used to bind the public authorization structure, task identifier, policy version, authorization threshold, token commitment, field commitment, and authorization token wrapper ciphertext;

[0045] S3.7: Include the task identifier bountyId, the OKVS public authorization structure E, and the authorization structure digest H. E The authorization threshold t, token commitment value tauCommitment, tauFieldCommitment, encryptedTau, policy random salt or its public derivative, policy version information, and authorization policy integrity commitment C are used as the public authorization parameters for the current bounty task.

[0046] 4. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 4, characterized in that step S1.4 specifically includes the following steps:

[0047] S4.1: The seller holds a verifiable credential VC issued by a credential issuing institution, wherein the verifiable credential VC includes at least the seller's wallet entity, a set of capability tags, a validity period of the credential, the credential issuing institution, and the issuing institution's digital signature; in one embodiment, the verifiable credential is a qualification VC issued by the platform based on CNVD certificate materials;

[0048] S4.2: The seller, based on the verifiable credential VC and the proof private key sk S Generate zero-knowledge proof π or qualification certificate envelope:

[0049] S4.3: The seller submits the zero-knowledge proof π or qualification certificate envelope to the platform instead of submitting the complete set of capability tags to the platform;

[0050] S4.4: The platform is based on the credential issuing institution's public key PK. I Verify the zero-knowledge proof π or qualification certificate envelope regarding the certificate revocation status, certificate holder wallet, and certificate validity period:

[0051] S4.5: If the verification result is not 1, the platform will terminate the authorization process for the current bounty task.

[0052] S4.6: If the verification result is 1, the platform confirms that the seller has the legal qualifications to participate and returns the public authorization parameters of the current bounty task to the seller.

[0053] 5. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 5, characterized in that step S1.5 specifically includes the following steps:

[0054] S5.1: The seller reads its own capability tag set A from locally verifiable credentials or digital identity wallet:

[0055] S5.2: For each capability tag a in the capability tag set A, the seller... j Perform standardization processes consistent with those on the buyer's side to obtain the standardized capability label a. j * :

[0056] S5.3: The seller uses the task identifier bountyId, the policy random salt policySalt, and the standardized capability label a. j * Generate candidate OKVS query key k j ' :

[0057] S5.4: The seller uses the candidate OKVS query key k j Decode the OKVS public license structure E to obtain the candidate license share payload v. j ':

[0058] The DecodeShare algorithm executed in this step is the license share decoding algorithm, whose inputs include the OKVS public license structure E and the candidate OKVS query key k. j The task identifier bountyId, policy version policyVersion, and tag version information are used to output the candidate authorization share payload v. j 'or null value⊥; its processing includes: using k j Locate the corresponding encoded position or equation system in E, recover the candidate value byte string, parse the candidate value byte string according to the field format of EncodeShare, and output ⊥ if parsing fails, otherwise output the candidate x-coordinate. j '、 Candidate share value y j 'tagversion' and candidate integrity check value j 'candidate authorization share payload v j ';

[0059] S5.5: Invoke VerifyShare to process the candidate license share payload v j Perform validity checks, including field format checks, limited field range checks, tag version checks, context integrity checks, and x-axis duplication checks; specifically: parse v j ' Obtain the candidate x-coordinate j '、 Candidate share value y j 'tagversion' and candidate integrity check value j ', determine x j ' and y j Does it belong to the finite field Fp and x j 'Non-zero, and recalculate check' j * If check j* With check j If they are inconsistent, then determine v. j 'Rejects OKVS misinterpreted code results, random collision results, or invalid construction results; if multiple candidate loads correspond to the same horizontal axis, only loads that pass the integrity check and have a unique source are retained; otherwise, the loads corresponding to that horizontal axis are marked as conflicting and invalid.'

[0060] VerifyShare is the grant share verification algorithm, whose inputs include the candidate grant share payload v. j '、Candidate OKVS query key k j ', Task identifier bountyId, Policy version policyVersion, Authorization structure summary H E Given a finite field parameter p, the output is the effective grant share (x). j ', y j ') or invalid tag ⊥; its processing includes field format validation, limited field range validation, tag version validation, context integrity validation, and x-axis duplicate validation, only when x j 'with y j 'All belong to Fp, x j 'Non-zero, check j 'With recalculated check j * A valid authorized share is output only when there are consistent loads and no conflicting loads on the same horizontal axis.

[0061] S5.6: Parse the candidate grant share payloads that have passed the validity check into valid grant shares, and form a valid grant share set S from all valid grant shares. S = {(x j , y j ) | Validate(v j ') = True}

[0062] 6. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 6, characterized in that step S1.6 specifically includes the following steps:

[0063] S6.1: Count the number q of valid authorized shares in the set S of valid authorized shares:

[0064] S6.2: Determine whether the number of valid authorized shares q is greater than or equal to the authorization threshold t;

[0065] S6.3: if q < t, determining that the seller does not satisfy the authorization condition of the current reward task, and terminating the reward authorization token recovery process;

[0066] S6.4: if q ≥ t, selecting t valid authorization shares with different horizontal coordinates, passing integrity check and bound to the current task context from the valid authorization share set S, to form a threshold recovery set T; when q > t, the system may perform Lagrange interpolation on a plurality of t-element subsets respectively according to a preset order, and perform token commitment verification on each candidate recovery result;

[0067] S6.5: for each share (x i , y i ), calculating the Lagrange basis function at zero point:

[0068] S6.6: calling RecoverToken to recover the candidate finite field secret tauField' based on the threshold recovery set T, and further recover the candidate reward authorization token τ':

[0069] wherein RecoverToken is a threshold token recovery algorithm, the input of which comprises the threshold recovery set T, an authorization threshold t, a finite field parameter p, an authorization token wrapped ciphertext encryptedTau, a policy commitment policyCommitment, a tauField commitment tauFieldCommitment and a tau commitment tauCommitment, and the output of which is a candidate reward authorization token τ', a candidate finite field secret tauField' or a failure marker ⊥; the processing process thereof comprises: performing Lagrange interpolation on t valid authorization shares in T to obtain tauField'; calculating tauMask'=H("hunter-okvs-tau-wrap:" ||policyCommitment || tauField') based on tauField'; unsealing τ' by using encryptedTau xor tauMask'; finally calculating tauFieldCommitment' and tauCommitment' respectively and calling VerifyShare or an equivalent commitment comparison logic for verification, outputting τ' and tauField' when the verification passes, otherwise outputting ⊥;

[0070] S6.7: according to the candidate finite field secret tauField 'Calculate tauMask'=H("hunter-okvs-tau-wrap:" || policyCommitment || tauField) ' ), and through τ ' =encryptedTau xor tauMask' Unsealed to obtain candidate bounty authorization token τ ' .

[0071] S6.8: Based on candidate tauField ' Calculate the candidate field commitment value tauFieldCommitment ' And compare it with the tauFieldCommitment generated during the task release phase; based on the candidate bounty authorization token τ ' Calculate the candidate token commitment value tauCommitment ' It is then independently compared with the tauCommitment generated during the task release phase and bound to the current policyVersion; if no threshold recovery set T exists that allows both commitments to pass, it is determined that the current recovery process has at least one of the following conditions: insufficient share, share conflict, misunderstanding code residue, or abnormal share injection, and the authorization success result is rejected, and no specific tag information that can be used to infer the buyer's authorization strategy is returned to the seller.

[0072] 7. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 7, characterized in that step S1.7 specifically includes the following steps:

[0073] S7.1: Based on candidate tauField ' and candidate bounty authorization token τ ' Calculate the tauFieldCommitment value for each candidate field. ' and candidate token commitment value tauCommitment ' :

[0074] S7.2: Set the candidate field commitment value tauFieldCommitment ' Compare the candidate token commitment value (tauCommitment) with the tauFieldCommitment generated during the task release phase, and use the tauCommitment as the basis for the commitment. ' Compare with the tauCommitment generated during the task release phase;

[0075] S7.3: If tauFieldCommitment '≠ tauFieldCommitment or tauCommitment ' If the value is not equal to tauCommitment, then the candidate bounty authorization token τ is determined. ' Invalid, and the failure reason will be classified as at least one of the following: insufficient threshold, share conflict, abnormal share integrity, or inconsistent recovery results; the platform refuses the seller the qualification to accept the current bounty task and does not return specific tag information that can be used to infer the buyer's authorization strategy;

[0076] S7.4: If tauFieldCommitment' = tauFieldCommitment and tauCommitment' = tauCommitment, then the candidate bounty authorization token τ' is determined to be the valid bounty authorization token corresponding to the current bounty task;

[0077] S7.5: After successful verification, generate an authorization success result Auth=1; if verification fails, generate an authorization failure result Auth=0.

[0078] 8. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 8, characterized in that step S1.8 specifically includes the following steps:

[0079] S8.1: Upon successful authorization, the platform generates an authorization status record (AuthRecord) corresponding to the current bounty task. Among them, sellerp id Indicates the seller's anonymous identity, t auth Indicates the authorization completion time;

[0080] S8.2: The platform controls the order acceptance or submission entry for the current bounty task based on the authorization status record;

[0081] S8.3: When a seller submits the results of the current bounty task, the platform verifies whether the task identifier, seller anonymous identity identifier, policy version information, and token commitment value in the submission request are consistent with the authorization status record, and queries the latest valid policy version of the current task; if the policyVersion in the authorization status record is not the current valid policy version, or the corresponding policy status PolicyStatus is revoked, expired, or superseded, then the authorization status record is determined to be invalid.

[0082] S8.4: If the verification is consistent, the authorization result Auth=1, and the authorization status record has not exceeded the expiration time. timeIf the policyVersion is the current valid policy version, then the seller is allowed to submit the results of the current bounty task;

[0083] S8.5: If the verification is inconsistent or the authorization result Auth=0, the seller shall be rejected from submitting the results of the current bounty task.

[0084] S8.6: The platform only saves the necessary information required to complete the authorization status management, and does not save the complete set of seller capability tags, the complete set of buyer authorization capability tags, or the plaintext of the bounty authorization token.

[0085] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0086] 1. This invention proposes a zero-trust-based threat intelligence bounty privacy authorization method. It uses verifiable credentials and zero-knowledge proofs to complete anonymous seller identity authentication, enabling sellers to prove their legitimate participation qualifications without disclosing their real identity, complete credential content, and complete set of capability tags. This method separates "legitimate qualification authentication" from "capability threshold authorization," effectively reducing the privacy leakage risk caused by platforms centrally storing seller identity information and capability profiles.

[0087] 2. This invention binds the buyer's authorization capability tags to the authorization shares generated by Shamir threshold secret sharing, and generates a public authorization structure through OKVS privacy encoding. This eliminates the need for the buyer to disclose the complete authorization policy in plaintext, and the platform does not need to maintain the traditional plaintext mapping relationship of "user-tag-permission". The seller can only attempt to recover the corresponding authorization shares using its own local capability tags, and cannot directly read or enumerate the complete set of buyer's authorization capability tags, thereby achieving privacy protection of the buyer's authorization policy and minimal disclosure of seller capability information.

[0088] 3. This invention transforms the traditional server-side permission judgment into a threshold recovery process for bounty authorization tokens. Only when the number of valid authorization shares recovered by the seller reaches the authorization threshold can the candidate bounty authorization token be recovered based on Lagrange interpolation, and the correctness of the recovery result is verified through the token commitment value. This mechanism provides cryptographically verifiable evidence for successful authorization results, preventing unauthorized order acceptance, authorization status forgery, and authorization strategy probing, thereby improving the credibility and security of the threat intelligence bounty platform's authorization.

[0089] 4. This invention uses task identifiers, policy random salts, and policy version information to contextually bind authorized capability tags, OKVS query keys, authorized shares, and token commitments. This allows the same capability tag to generate different query keys in different bounty tasks, avoiding cross-task correlation analysis and replay attacks. When a task ends, the policy is updated, or the credential status changes, the system can update the policy version and public authorization structure, invalidating the old authorization results, thereby meeting the requirements of continuous verification and dynamic authorization under a zero-trust architecture.

[0090] 5. Upon successful authorization, this invention binds the authorization result with the task identifier, seller's anonymous identity, strategy version, and authorization status, and controls subsequent order acceptance or submission entry points based on this authorization status. The platform only stores the necessary information for authorization status management, and does not store the seller's complete capability tag set, the buyer's complete authorization strategy, or the plaintext of the bounty authorization token. This ensures that bounty tasks are manageable, traceable, and auditable while achieving minimal access permissions and minimal information disclosure. Attached Figure Description

[0091] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0092] Figure 1 is The method flowchart of the present invention. Detailed Implementation

[0093] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 a part of the embodiments of the present invention, and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the protection scope of the present invention.

[0094] like Figure 1 As shown in this embodiment, a zero-trust-based threat intelligence bounty method with privacy protection includes the following steps:

[0095] S1.1: The buyer issues a threat intelligence bounty mission, configuring the authorized capability tag set, authorization threshold, policy random salt, and policy version information;

[0096] S1.2: The buyer or the authorization management platform generates a bounty authorization token τ corresponding to the current bounty task, calculates the token commitment value tauCommitment, maps τ to a finite field secret tauField, generates a field commitment value tauFieldCommitment, and generates an authorization share corresponding to each capability tag in the authorization capability tag set based on the Shamir threshold secret sharing algorithm.

[0097] S1.3: Generate an OKVS query key based on the task identifier, policy random salt, and capability tag, and implicitly encode the OKVS query key with the corresponding authorization share to generate an OKVS public authorization structure E and an authorization structure digest H. E Policy Commitment, encryptedTau (authorization token wrapper), and authorization policy integrity commitment (C);

[0098] S1.4: The seller proves to the platform that it has the legal qualifications to participate based on the verifiable certificate VC or zero-knowledge proof envelope issued by the platform, and does not disclose the complete set of capability tags;

[0099] S1.5: The seller uses local capability tags to generate candidate OKVS query keys and decodes the OKVS public licensing structure to restore the set of valid licensing shares that match its own capability tags;

[0100] S1.6: When the number of shares in the set of valid authorized shares reaches the authorization threshold, the candidate finite field secret tauField is recovered based on the Lagrange interpolation algorithm. ' and based on tauField ' Unpack the ciphertext encryptedTau of the authorization token to obtain the candidate bounty authorization token τ. ' ;

[0101] S1.7: Verify the candidate tauField based on tauFieldCommitment and tauCommitment respectively. ' and candidate bounty authorization token τ ' Is it correct?

[0102] S1.8: If the verification is successful, the seller is confirmed to be qualified to accept the current bounty task, and the authorization result is bound to the task identifier, the seller's anonymous identity, the strategy version, and the authorization status.

[0103] In some specific embodiments, step S1.1 specifically includes the following steps:

[0104] S1.1.1: Based on the task type, sensitivity level, technical difficulty, and expected outcome requirements of the threat intelligence bounty mission, the buyer determines the set of authorized capability tags P corresponding to the current bounty mission. Among them, L i This represents the i-th authorized capability tag, and n represents the number of authorized capability tags. The authorized capability tags may include capability tags such as vulnerability discovery, malicious sample analysis, attack chain tracing, vulnerability reproduction, report writing, and specific industry security experience.

[0105] S1.1.2: The buyer configures an authorization threshold t based on the authorization capability tag set P, where the authorization threshold t represents the minimum number of valid authorization shares required for the seller to obtain the qualification to accept the current bounty task, and satisfies:

[0106] For example, a lower authorization threshold can be set for common vulnerability reproduction tasks; a higher authorization threshold can be set for highly sensitive tasks such as APT attack analysis, malware source tracing, or critical infrastructure vulnerability analysis.

[0107] S1.1.3: The buyer or the authorization management platform generates a unique task identifier bountyId for the current bounty task. The task identifier bountyId is used to distinguish different threat intelligence bounty tasks and is used for subsequent bounty authorization token generation, OKVS query key generation, authorization share binding and token commitment verification.

[0108] S1.1.4: The buyer or the authorized management platform generates a policy random salt for the current bounty task. The policy random salt is used to participate in the generation of capability tag query keys, so that the same capability tag generates different OKVS query keys in different bounty tasks, thereby avoiding cross-task key-value association analysis.

[0109] S1.1.5: The buyer or the authorization management platform generates a policy version number, policyVersion, which identifies the authorization policy version corresponding to the current authorization capability tag set P, authorization threshold t, policy random salt policySalt, and bounty authorization token τ. When the buyer modifies the authorization capability tag set, authorization threshold, policy random salt, task authorization validity period, or capability tag version, the system increments or regenerates policyVersion and triggers the bounty authorization token τ corresponding to the current policy version. policyThe token random salt (tokenSalt), token commitment value (tauCommitment), Shamir authorization share, and OKVS public authorization structure are regenerated, while the authorization status records corresponding to the old policy version are marked as invalid, revoked, or replaced.

[0110] S1.1.6: The buyer or the authorization management platform combines the authorization capability tag set P, authorization threshold t, task identifier bountyId, policy random salt policySalt, and policy version number policyVersion into the authorization policy parameter Policy for the current bounty task:

[0111] In some specific embodiments, step S1.2 specifically includes the following steps:

[0112] S1.2.1: The buyer or the authorization management platform generates a random bounty authorization token τ for the current task identifier bountyId and the current policy version policyVersion. policy It generates a random salt token (tokenSalt); different strategy versions correspond to different bounty authorization tokens (τ). policy Tokens corresponding to the old strategy version cannot be used in the order acceptance, submission or reward process of the new strategy version;

[0113] S1.2.2: Calculate the token commitment value tauCommitment based on the bounty authorization token τ, the task identifier bountyId, and the token random salt tokenSalt: Where H(·) is a cryptographic hash function, and tauCommitment is used for subsequent verification of whether the recovered candidate bounty authorization token is correct;

[0114] S1.2.3: Map the bounty authorization token τ to a finite-field secret tauField: Where p is the modulus of the finite field, and HashToField(·) represents a function that maps the input to elements of the finite field;

[0115] S1.2.4: Construct the Shamir secret sharing polynomial f(x) of degree t−1 based on the authorization threshold t: Where a1 to at−1 are polynomial coefficients randomly selected within a finite field, and f(0) = tauField;

[0116] S1.2.5: For each capability tag L in the authorized capability tag set P i Generate a unique non-zero x-coordinate. i : Among them, Canonicalize(L i ) indicates the ability label L i Standardization processes are implemented, including case normalization, space pruning, synonym mapping, version number binding, and illegal character filtering.

[0117] S1.2.6: Calculate the corresponding secret share y based on the Shamir secret sharing polynomial f(x). i :

[0118] S1.2.7: The x-coordinate... i and secret share y i Composition and Ability Labels L i Corresponding authorized share:

[0119] S1.2.8: Based on the finite field secret tauField, task identifier bountyId, policy version policyVersion, and token random salt tokenSalt, generate the field commitment value tauFieldCommitment: Among them, tauFieldCommitment is used to verify whether the finite field secret obtained by Lagrange interpolation is correct, and together with the subsequent OKVS public grant structure digest HE, it participates in the generation of grant policy integrity commitment and grant token wrapper ciphertext.

[0120] In some specific embodiments, step S1.3 specifically includes the following steps:

[0121] S1.3.1: For each capability tag L in the authorized capability tag set P i Perform standardization processing to obtain the standardized capability label L. i * :

[0122] S1.3.2: Based on the task identifier bountyId, the policy random salt policySalt, and the standardized capability label L i * Calculate the corresponding OKVS query key k i :

[0123] S1.3.3: Will be related to the ability tag L i The corresponding authorized share is encapsulated as an authorized share payload v i : EncodeShare is the authorized share payload encoding algorithm, whose input includes the x-axis. i Secret share y i Tag version and integrity check value i The output is a writable OKVS license share payload v i The processing steps include: concatenating x according to the preset field order. i y i tagversion and check i Each field is serialized with a fixed length or a length prefix to generate a share plaintext byte string `sharePlaini`, and `sharePlaini` is used as the value field in the OKVS key-value pair; in one embodiment, This is used to bind the authorized share to the current task, policy version, and OKVS query key.

[0124] Here, tagversion is the capability tag version information, check i This is a share integrity check value generated based on the current task context, used to filter invalid shares from OKVS misinterpreted codes, random collisions, or abnormally constructed ones;

[0125] In another implementation, check i Message authentication codes can be used for calculation:

[0126] S1.3.4: Query key k using OKVS i As a key, with authorized share payload v i As the value, construct the OKVS encoding set D:

[0127] S1.3.5: Use the OKVS encoding algorithm to encode the OKVS encoding set D to generate the OKVS public license structure E:

[0128] The OKVS public license structure E satisfies the following correctness and anti-misinterpretation constraints: For any ; For any , . Where λ is the security parameter, m is the OKVS structural parameter, and negl(λ) represents a negligible function with respect to λ; the above constraints indicate that a matching query key can stably recover the corresponding authorized share payload, while a non-matching query key, even if it generates a candidate decoding result, will have difficulty passing the share integrity check. The input to the OKVS encoding algorithm is the OKVS encoding set D = {(k i , v i The process involves taking the OKVS query key k, the security parameter λ, and the OKVS structure parameter m, and outputting the OKVS public authorization structure E. The processing includes: based on each OKVS query key k... i Calculate one or more storage locations or linear equations to obtain the corresponding authorized share load v i As the right-hand side of the equation, the encoded array, seed, hash function identifier, and structure parameters are obtained by solving the equation, and these are combined into E, such that any key k holding a matching query key... i One side can obtain v by E decoding. i The party that does not hold the matching query key cannot reliably obtain the authorized share payload that passes the integrity check.

[0129] In one embodiment, the OKVS encoding algorithm employs PaXoS, GBF (Browser Bloom Filter), or an equivalent decodeable privacy key-value encoding structure; in the demonstration implementation, E can also be represented as shares[] containing a key digest, value payload, and structure digest, as long as it satisfies the same input, output, and decoding verification interfaces. Among them, E can be publicly stored by the platform or distributed along with the task parameters, but E does not directly store the plaintext of the capability label, nor does it directly expose the plaintext mapping relationship between the capability label and the authorized share;

[0130] S1.3.6: Calculate the license structure digest H based on the OKVS public license structure E. E The authorization policy integrity commitment C is generated by combining the token commitment values ​​tauCommitment, tauFieldCommitment, the encryptedTau wrapped in the authorization token, and the policy version information. Wherein, Serialize(E) represents the deterministic serialization of the OKVS public authorization structure E; policyCommitment is used to bind the current task, policy version, authorization structure digest, and threshold parameters; encryptedTau is used to avoid directly publicizing the bounty authorization token τ; authorization policy integrity commitment C is used to bind the public authorization structure, task identifier, policy version, authorization threshold, token commitment, field commitment, and authorization token wrapper ciphertext.

[0131] By binding E, task identifier, authorization threshold, token commitment, and policy version, it is possible to prevent the platform or attackers from silently replacing the authorization structure, tampering with threshold parameters, or re-placing authorization parameters from other tasks into the current task after the task is published.

[0132] S1.3.7: Include the task identifier bountyId, the OKVS public authorization structure E, and the authorization structure digest H. E The authorization threshold t, token commitment value tauCommitment, tauFieldCommitment, encryptedTau, policy random salt or its public derivative, policy version information, and authorization policy integrity commitment C are used as the public authorization parameters for the current bounty task;

[0133] In some specific embodiments, step S1.4 specifically includes the following steps:

[0134] S1.4.1: The seller holds a verifiable credential VC issued by a credential issuing institution, wherein the verifiable credential VC includes at least the seller's identity identifier, a set of capability tags, the validity period of the credential, the credential issuing institution, and the issuing institution's digital signature;

[0135] S1.4.2: The seller, based on the verifiable credential VC and the proof private key sk... S Generate zero-knowledge proof π or qualification certificate envelope:

[0136] S1.4.3: The seller submits the zero-knowledge proof π to the platform, but does not submit the complete verifiable credential VC and the complete set of capability tags to the platform.

[0137] S1.4.4: The platform is based on the credential issuing institution's public key PK. I Verify the zero-knowledge proof π or qualification certificate envelope regarding the certificate revocation status, certificate holder wallet, and certificate validity period:

[0138] S1.4.5: If the verification result is not 1, the platform will terminate the authorization process for the current bounty task.

[0139] S1.4.6: If the verification result is 1, the platform confirms that the seller has the legal qualifications to participate and returns the public authorization parameters of the current bounty task to the seller. This step only proves that the seller has the legal qualifications to participate and does not determine whether the seller meets the capability threshold conditions of the current bounty task;

[0140] In some specific embodiments, step S1.5 specifically includes the following steps:

[0141] S1.5.1: The seller reads its own capability tag set A from locally verifiable credentials or digital identity wallet: Among them, a j This represents the j-th capability tag held by the seller;

[0142] S1.5.2: The seller for each capability tag a in the capability tag set A j Perform standardization processes consistent with those on the buyer's side to obtain the standardized capability label a. j * :

[0143] S1.5.3: The seller uses the task identifier bountyId, the policy random salt policySalt, and the standardized capability label a. j * Generate candidate OKVS query key k j ' :

[0144] S1.5.4: The seller uses the candidate OKVS query key k j Decode the OKVS public license structure E to obtain the candidate license share payload v. j ':

[0145] The DecodeShare algorithm executed in this step is the license share decoding algorithm, whose inputs include the OKVS public license structure E and the candidate OKVS query key k. j The task identifier bountyId, policy version policyVersion, and tag version information are used to output the candidate authorization share payload v. j 'or null value⊥; its processing includes: using k jLocate the corresponding encoded position or equation system in E, recover the candidate value byte string, parse the candidate value byte string according to the field format of EncodeShare, and output ⊥ if parsing fails, otherwise output the candidate x-coordinate. j '、 Candidate share value y j 'tagversion' and candidate integrity check value j 'candidate authorization share payload v j '.

[0146] If the seller's capability label is a j If the tag belongs to the buyer's authorization capability set P, then the decoding result v j 'The corresponding authorized share payload can be recovered; if the tag does not belong to the buyer's authorization strategy, the decoding result cannot pass the subsequent verification and cannot be used as a valid authorized share;

[0147] Because the OKVS decoding algorithm may output candidate payloads v in random form for uncoded keys. j The candidate grant share payload shall not be used directly as a valid grant share. It must pass the context integrity check of S5.5 before it can be added to the set of valid grant shares S.

[0148] S1.5.5: Invoke VerifyShare to process the candidate license share payload v j Perform validity checks, including field format checks, limited field range checks, tag version checks, context integrity checks, and x-axis duplication checks; specifically: parse v j ' Obtain the candidate x-coordinate j '、 Candidate share value y j 'tagversion' and candidate integrity check value j ', determine x j ' and y j Does it belong to the finite field Fp and x j 'Non-zero, and recalculate check' j * If check j * With check j If they are inconsistent, then determine v. j 'Rejects OKVS misinterpreted code results, random collision results, or invalid construction results; if multiple candidate loads correspond to the same horizontal axis, only loads that pass the integrity check and have a unique source are retained; otherwise, the loads corresponding to that horizontal axis are marked as conflicting and invalid.'

[0149] Wherein, VerifyShare is an authorized share verification algorithm, and its inputs include the candidate authorized share payload v j ', the candidate OKVS query key k j ', the task identifier bountyId, the policy version policyVersion, the authorization structure digest HE and the finite field parameter p, and the output is a valid authorized share (x j ', y j ') or an invalid flag ⊥; the processing process thereof includes field format verification, finite field range verification, tag version verification, context integrity verification and abscissa duplicate verification, and only when x j ' and y j ' both belong to Fp, x j ' is non-zero, check j ' is consistent with the recalculated check j * and there is no conflicting payload for the same abscissa, then a valid authorized share is output.

[0150] S1.5.6: parsing the candidate authorized share payload that passes the legality verification into valid authorized shares, and forming a valid authorized share set S from all valid authorized shares: S = {(x j , y j ) | Validate(v j ') = True}

[0151] Through the above steps, the seller does not need to upload the complete capability tag set to the platform, and can locally attempt to recover the authorized shares matching its own capability tags.

[0152] In some specific embodiments, the step S1.6 specifically includes the following steps:

[0153] S1.6.1: counting the number of valid authorized shares q in the valid authorized share set S:

[0154] S1.6.2: judging whether the number of valid authorized shares q is greater than or equal to the authorization threshold t;

[0155] S1.6.3: if q<t, determining that the seller does not meet the authorization condition of the current bounty task, and terminating the bounty authorization token recovery process. In this case, the platform returns neither which specific capability tags are missing, nor information that can infer the complete authorization policy of the buyer;

[0156] S1.6.4: If q≥t, then select t valid authorization shares with different x-coordinates, all of which pass the integrity check and are bound to the current task context from the set of valid authorization shares S to form a threshold recovery set T; when q>t, the system can select multiple t-element subsets in a preset order to perform Lagrange interpolation respectively, and perform token commitment verification on each candidate recovery result;

[0157] S1.6.5: For each share (x) in the threshold recovery set T i , y i ), calculate its Lagrange basis function at zero:

[0158] S1.6.6: Invoke RecoverToken to recover the candidate finite field secret tauField' based on the threshold recovery set T, and further recover the candidate bounty authorization token τ': The RecoverToken algorithm is a threshold token recovery algorithm. Its inputs include the threshold recovery set T, the authorization threshold t, the finite field parameter p, the authorization token wrapper encryptedTau, the policy commitment, tauFieldCommitment, and tauCommitment. The outputs are candidate bounty authorization tokens τ', candidate finite field secrets tauField', or failure flags ⊥. The processing steps include: performing Lagrange interpolation on the t valid authorization shares in T to obtain tauField'; calculating tauMask'=H("hunter-okvs-tau-wrap:" ||policyCommitment || tauField') based on tauField'; desealing tauMask' using encryptedTau xor tauMask' to obtain τ'; finally, calculating tauFieldCommitment' and tauCommitment' respectively and calling VerifyShare or equivalent commitment comparison logic for verification. If the verification is successful, output τ' and tauField'; otherwise, output ⊥.

[0159] Since the Shamir polynomial constructed during the bounty task release phase satisfies f(0)=tauField, when the authorized share recovered by the seller is real, valid and the quantity reaches the threshold, the interpolated tauField' should be equal to the finite field secret tauField corresponding to the task release phase.

[0160] S1.6.7: Based on the candidate finite field secret tauField ' Calculate tauMask'=H("hunter-okvs-tau-wrap:" || policyCommitment || tauField) ' ), and through τ ' =encryptedTau xortauMask' Unsealed to obtain candidate bounty authorization token τ ' ;

[0161] S1.6.8: Calculate the candidate field commitment value tauFieldCommitment' based on the candidate tauField' and compare it with the tauFieldCommitment generated during the task release phase; calculate the candidate token commitment value tauCommitment' based on the candidate bounty authorization token τ' and independently compare it with the tauCommitment generated during the task release phase and bound to the current policyVersion; if no threshold recovery set T exists that allows both commitments to pass, it is determined that the current recovery process has at least one of the following situations: insufficient share, share conflict, misunderstanding code residue, or abnormal share injection, and the authorization success result is rejected, and no specific tag information that can be used to infer the buyer's authorization strategy is returned to the seller;

[0162] In some specific embodiments, step S1.7 specifically includes the following steps:

[0163] S1.7.1: Based on candidate tauField ' and candidate bounty authorization token τ ' Calculate the tauFieldCommitment value for each candidate field. ' and candidate token commitment value tauCommitment ' :

[0164] S1.7.2: Compare the candidate field commitment value tauFieldCommitment' with the tauFieldCommitment generated during the task release phase, and compare the candidate token commitment value tauCommitment' with the tauCommitment generated during the task release phase;

[0165] S1.7.3: If tauFieldCommitment ' ≠ tauFieldCommitment or tauCommitment 'If the value is not equal to tauCommitment, then the candidate bounty authorization token τ is determined. ' Invalid, and the failure reason will be classified as at least one of the following: insufficient threshold, share conflict, abnormal share integrity, or inconsistent recovery results; the platform refuses the seller the qualification to accept the current bounty task and does not return specific tag information that can be used to infer the buyer's authorization strategy;

[0166] S1.7.4: If tauFieldCommitment' = tauFieldCommitment and tauCommitment' = tauCommitment, then the candidate bounty authorization token τ' is determined to be the valid bounty authorization token corresponding to the current bounty task;

[0167] S1.7.5: Upon successful verification, generate an authorization success result Auth=1; upon failed verification, generate an authorization failure result Auth=0.

[0168] In some specific embodiments, step S1.8 specifically includes the following steps:

[0169] S1.8.1: Upon successful authorization, the platform generates an authorization status record (AuthRecord) corresponding to the current bounty task. Among them, sellerp id Indicates the seller's anonymous identity, t auth Indicates the authorization completion time;

[0170] S1.8.2: The platform controls the order acceptance or submission entry point for the current bounty task based on the authorization status record. Only when Auth=1 in the authorization status record will the platform allow the seller to enter the subsequent process of the current bounty task;

[0171] S1.8.3: When a seller submits the results of the current bounty task, the platform verifies whether the task identifier, seller anonymous identity identifier, policy version information, and token commitment value in the submission request are consistent with the authorization status record, and queries the latest valid policy version of the current task; if the policyVersion in the authorization status record is not the current valid policy version, or the corresponding policy status PolicyStatus is revoked, expired, or superseded, then the authorization status record is determined to be invalid;

[0172] S1.8.4: If the verification is consistent, the authorization result Auth=1, and the authorization status record has not exceeded the expiration time. time If the policyVersion is the current valid policy version, then the seller is allowed to submit the results of the current bounty task;

[0173] S1.8.5: If the verification is inconsistent or the authorization result Auth=0, the seller shall be rejected from submitting the results of the current bounty task.

[0174] S1.8.6: The platform only saves the necessary information required to complete the authorization status management, and does not save the complete set of seller capability tags, the complete set of buyer authorization capability tags, or the plaintext of the bounty authorization token.

[0175] In summary, this embodiment transforms the capability authorization process in threat intelligence bounty missions into a verifiable cryptographic recovery process through anonymous identity authentication, OKVS privacy authorization, Shamir threshold recovery, and token commitment verification. This allows sellers to complete capability threshold verification without disclosing complete capability tags, buyers to complete order acceptance qualification control without disclosing complete authorization policies, and platforms to complete authorization status management without maintaining plaintext permission mapping relationships.

[0176] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0177] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A zero-trust, privacy-preserving threat intelligence bounty method, characterized in that, Includes the following steps: S1.1: The buyer issues a threat intelligence bounty mission, configuring the authorized capability tag set, authorization threshold, policy random salt, and policy version information; S1.2: The buyer or the authorization management platform generates a bounty authorization token τ corresponding to the current bounty task, calculates the token commitment value tauCommitment, maps τ to a finite field secret tauField, generates a field commitment value tauFieldCommitment, and generates an authorization share corresponding to each capability tag in the authorization capability tag set based on the Shamir threshold secret sharing algorithm. S1.3: Generate an OKVS query key based on the task identifier, policy random salt, and capability tag, and implicitly encode the OKVS query key with the corresponding authorization share to generate an OKVS public authorization structure E and an authorization structure digest H. E Policy Commitment, encryptedTau (authorization token wrapper), and authorization policy integrity commitment (C); S1.4: The seller proves to the platform that it has the legal qualifications to participate based on verifiable credentials (VC) or zero-knowledge proof envelopes, and does not disclose the complete set of capability tags; S1.5: The seller uses local capability tags to generate candidate OKVS query keys and decodes the OKVS public licensing structure to restore the set of valid licensing shares that match its own capability tags; S1.6: When the number of shares in the set of valid authorized shares reaches the authorization threshold, the candidate finite field secret tauField' is recovered based on the Lagrange interpolation algorithm, and the authorization token is decrypted based on tauField' to obtain the candidate bounty authorization token τ'; S1.7: Verify the correctness of candidate tauField' and candidate bounty authorization token τ' based on tauFieldCommitment and tauCommitment respectively; S1.8: If the verification is successful, the seller is confirmed to be qualified to accept the current bounty task, and the authorization result is bound to the task identifier, the seller's anonymous identity, the strategy version, and the authorization status.

2. The threat intelligence bounty method based on zero trust and with privacy protection as described in claim 1, characterized in that, Step S1.1 specifically includes the following steps: S2.1: The buyer determines the set of authorized capability tags corresponding to the current bounty mission based on the mission type, mission sensitivity level, and expected outcome requirements of the threat intelligence bounty mission; S2.2: The buyer configures an authorization threshold value according to the authorized capability tag set. The authorization threshold value represents the minimum number of valid authorization shares required for the seller to obtain the qualification to accept the current bounty task, and is not greater than the number of authorized capability tags. S2.3: The buyer or the authorized management platform generates the task identifier corresponding to the current bounty task; S2.4: The buyer or the authorization management platform generates a random salt for the strategy corresponding to the current bounty task; S2.5: The buyer or the authorization management platform generates the strategy version number corresponding to the current bounty task; when the authorization capability tag set, authorization threshold value, strategy random salt, task authorization validity period or capability tag version changes, the system updates the strategy version number and regenerates the authorization information corresponding to the current strategy version; S2.6: Use the set of authorized capability tags, authorization threshold, task identifier, policy random salt, and policy version number as the authorization policy parameters for the current bounty task.

3. The threat intelligence bounty method based on zero trust and with privacy protection according to claim 2, characterized in that, Step S1.2 specifically includes the following steps: S3.1: The buyer or the authorization management platform generates a bounty authorization token corresponding to the current bounty task based on the task identifier and the current strategy version, and generates a random salt for the token; different strategy versions correspond to different bounty authorization tokens, and bounty authorization tokens corresponding to the old strategy version cannot be used in the authorization process of the new strategy version; S3.2: Generate a token commitment value based on the bounty authorization token, task identifier, and token random salt, which is used to verify whether the recovered candidate bounty authorization token is correct; S3.3: Map the bounty authorization token to a finite-domain secret and generate a field commitment value corresponding to the finite-domain secret; S3.4: Construct a Shamir threshold secret sharing structure based on the authorization threshold value, and generate secret sharing parameters using the finite field secret as the secret to be shared; S3.5: Generate a unique corresponding horizontal coordinate value for each capability tag in the authorized capability tag set, and bind the capability tag to the corresponding horizontal coordinate; S3.6: Generate the authorized share corresponding to each capability tag based on the secret sharing parameters and the corresponding horizontal coordinate; S3.7: Associate the authorized share with the corresponding capability tag to form the authorized share set for the current bounty task.

4. The zero-trust-based threat intelligence bounty method with privacy protection according to claim 3, characterized in that, Step S1.3 specifically includes the following steps: S4.1: Perform standardization processing on each capability tag in the authorized capability tag set to obtain standardized capability tags; S4.2: Generate the corresponding OKVS query key based on the task identifier, policy random salt, and standardized capability label; S4.3: Encapsulate the authorized share corresponding to the capability tag, the capability tag version information, and the share integrity verification information into an authorized share payload. The share integrity verification information is used to verify the legality and integrity of the authorized share. S4.4: Construct an OKVS encoding set using the OKVS query key as the key and the authorized share payload as the value; S4.5: Call the OKVS encoding algorithm to encode the OKVS encoding set to generate an OKVS public licensing structure, so that the party holding the matching capability tag can recover the corresponding licensing share, while the party not holding the matching capability tag cannot obtain a valid licensing share; S4.6: Generate an authorization structure digest based on the OKVS public authorization structure, and generate an authorization policy integrity commitment by combining the token commitment value, field commitment value, authorization token package ciphertext, and policy version information, which is used to verify the integrity of the current authorization policy and the validity of the authorization token; S4.7: The task identifier, OKVS public authorization structure, authorization structure digest, authorization threshold value, token commitment value, field commitment value, authorization token wrapped ciphertext, policy random salt or its public derivative value, policy version information, and authorization policy integrity commitment are used as the public authorization parameters for the current bounty task.

5. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 4, characterized in that, Step S1.4 specifically includes the following steps: S5.1: The seller holds a verifiable certificate issued by a certificate issuing authority, the verifiable certificate including at least the seller's identity identifier, a set of capability tags, the certificate's validity period, the certificate issuing authority, and the issuing authority's digital signature; S5.2: The seller generates zero-knowledge proof or qualification proof information based on the verifiable credential and the proof private key; S5.3: The seller submits the zero-knowledge proof or qualification proof information to the platform, instead of submitting the complete set of capability tags to the platform; S5.4: The platform verifies the zero-knowledge proof or qualification certificate information based on the certificate issuing institution's public key, certificate revocation status, certificate subject wallet, and certificate validity period; S5.5: If verification fails, terminate the authorization process for the current bounty task; S5.6: If the verification is successful, the seller is confirmed to have the legal qualifications to participate, and the public authorization parameters of the current bounty task are returned to the seller.

6. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 5, characterized in that, Step S1.5 specifically includes the following steps: S6.1: The seller reads its own capability tag set from locally verifiable credentials or digital identity wallet; S6.2: The seller performs standardization processing on each capability tag in the capability tag set in the same manner as the buyer, to obtain standardized capability tags; S6.3: The seller generates candidate OKVS query keys based on the task identifier, strategy random salt, and standardized capability tags; S6.4: The seller uses the candidate OKVS query key to decode the OKVS public licensing structure to obtain the candidate licensing share payload; S6.5: Perform a legality check on the candidate license share payload. The legality check includes at least field format check, tag version check, context integrity check, and license share conflict check. Candidate license share payloads that fail the legality check are discarded, while candidate license share payloads that pass the legality check are retained. S6.6: Parse the candidate grant share payload that has passed the legality check into valid grant shares, and form a set of valid grant shares from all valid grant shares.

7. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 6, characterized in that, Step S1.6 specifically includes the following steps: S7.1: Count the number of valid authorized shares in the set of valid authorized shares, and determine whether the number of valid authorized shares meets the authorization threshold; S7.2: If the number of valid authorized shares is less than the authorization threshold, it is determined that the seller does not meet the authorization conditions of the current bounty task, and the bounty authorization token recovery process is terminated; S7.3: If the number of valid authorized shares is greater than or equal to the authorization threshold, then select valid authorized shares that satisfy the integrity check and are bound to the current task context from the set of valid authorized shares to form a threshold recovery set; when the number of valid authorized shares is greater than the authorization threshold, the system can select multiple threshold recovery sets according to preset rules to perform token recovery operations respectively; S7.4: Execute the threshold secret recovery algorithm based on the threshold recovery set to recover the candidate finite field secret, and recover the candidate bounty authorization token according to the candidate finite field secret; S7.5: Deseal the ciphertext of the authorization token package according to the candidate finite field secret to obtain the candidate bounty authorization token; S7.6: Generate corresponding candidate commitment values ​​based on the candidate finite domain secret and the candidate bounty authorization token, and compare them with the commitment values ​​generated during the task release phase; if the commitment value verification fails, refuse to generate an authorization success result.

8. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 7, characterized in that, Step S1.7 specifically includes the following steps: S8.1: Generate corresponding candidate field commitment values ​​and candidate token commitment values ​​based on the candidate finite field secret and the candidate bounty authorization token, respectively; S8.2: Compare the candidate field commitment value with the field commitment value generated during the task release phase, and compare the candidate token commitment value with the token commitment value generated during the task release phase; S8.3: If any commitment value fails to be verified, the candidate bounty authorization token is deemed invalid, the seller is denied the right to accept the current bounty task, and no specific tag information that can be used to infer the buyer's authorization strategy is returned. S8.4: If both the candidate field commitment value and the candidate token commitment value pass the verification, then the candidate bounty authorization token is determined to be the valid bounty authorization token corresponding to the current bounty task; S8.5: Generate the corresponding authorization result based on the verification result of the commitment value, and use the authorization result to control the seller's subsequent order acceptance authorization process.

9. A zero-trust-based threat intelligence bounty method with privacy protection according to claim 8, characterized in that, Step S1.8 specifically includes the following steps: S9.1: After the authorization verification is successful, the platform generates an authorization status record corresponding to the current bounty task. The authorization status record includes at least the task identifier, the seller's anonymous identity identifier, the token commitment value, the strategy version information, the authorization result, and the authorization completion time. S9.2: The platform controls the order acceptance or task result submission entry of the current bounty task based on the authorization status record; S9.3: When the seller submits the results of the current bounty task, the platform verifies whether the task identifier, seller anonymous identity identifier, strategy version information and token commitment value in the submission request are consistent with the authorization status record, and verifies whether the current authorization strategy is in a valid state; S9.4: If the authorization status record is verified and the current authorization policy is a valid policy, the seller is allowed to submit the results of the current bounty task; S9.5: If the authorization status record verification fails or the current authorization policy has expired, been revoked or replaced, the seller shall be refused to submit the results of the current bounty task. S9.6: The platform only saves the necessary information required to complete the authorization status management, and does not save the complete set of seller capability tags, the complete set of buyer authorization capability tags, or the plaintext of the bounty authorization token.

10. A zero-trust-based threat intelligence bounty system with privacy protection, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the method according to any one of claims 1 to 9.

Images