Online bidding data transmission security encryption method based on multi-party signature

Abstract

The invention discloses a multi-party signature-based online bidding data transmission security encryption method, which belongs to the technical field of communication security in the field of electronic bidding, and comprises the following steps of: obtaining a preset bidding process stage division parameter, and generating a role dynamic permission set; receiving target bid invitation data, and generating a stage signature identifier; generating a data unit with a stage verification tag based on the stage signature identifier and the corresponding process stage identifier; when process stage conversion is detected, generating a cross-stage data encapsulation chain; analyzing historical stage signature identifiers in the cross-stage data encapsulation chain, and calculating the cumulative weight sum of all effective signature contributors; and when the accumulated weight sum reaches a preset tracing weight requirement and signature verification of all stages is passed, generating a data credibility verification result. A flow stage identifier is adopted to drive the generation of a role dynamic permission set, a tamper-proof complete electronic evidence chain can be formed, and the credibility and service continuity of the bid invitation data in the whole life cycle are guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication security technology in the field of electronic bidding, and in particular to an online bidding data transmission security encryption method based on multi-party signature. BACKGROUND

[0002] Currently, electronic bidding systems rely on encryption technology to ensure the transmission security of sensitive data such as bidding documents and evaluation reports. Existing solutions usually use public key infrastructure to achieve identity authentication and data encryption. Such systems involve multiple parties such as bidders, bidders, and evaluation experts, and need to ensure the verifiability and anti-repudiation of each operation.

[0003] Current technology mainly uses digital signature combined with timestamp to protect data, and some solutions introduce blockchain to store signature records. In terms of permission management, most systems pre-set static role permission tables and bind fixed operation permissions through certificates. End-to-end encryption channels are used for data transmission, and hash values are generated for key files for integrity verification.

[0004] The existing technology has the defect that the static permission mechanism cannot adapt to the stage conversion requirements of the bidding process, resulting in unauthorized operation of the authorized role in the early stage in the subsequent stage. Discrete signature verification lacks cross-stage correlation, and historical data tampering is difficult to trace to the current operation. In the multi-party signature scenario, the absence of a single role can easily lead to process interruption, and the lack of weight accumulation mechanism makes global trusted verification lack quantitative basis. SUMMARY

[0005] To solve the above problems, the present application provides an online bidding data transmission security encryption method based on multi-party signature, which generates a dynamic role permission set driven by a process stage identifier, constructs a chain cross-stage data encapsulation chain combined with a threshold signature rule, and forms a tamper-proof complete electronic evidence chain through a weight accumulation and stage signature dual verification mechanism, ensuring the trustworthiness and business continuity of the bidding data throughout its life cycle.

[0006] The above object can be achieved by the following scheme:

[0007] A secure encryption method for online bidding data transmission based on multi-party signatures includes: obtaining preset bidding process stage division parameters and generating process stage identifiers; generating a dynamic permission set for roles based on the process stage identifiers; receiving target bidding data and generating a stage signature identifier based on the dynamic permission set for roles and preset threshold signature rules, wherein the stage signature identifier includes the process stage identifier and the permission set hash value; generating a data unit with a stage verification tag based on the stage signature identifier and the corresponding process stage identifier; when a process stage transition is detected, performing chained encapsulation based on the data unit of the previous stage and the newly generated stage signature identifier to generate a cross-stage data encapsulation chain; parsing the historical stage signature identifiers in the cross-stage data encapsulation chain and calculating the cumulative weight sum of all valid signature contributors; and generating a data trust verification result when the cumulative weight sum reaches a preset traceability weight requirement and all stage signature verifications pass.

[0008] Optionally, generating a dynamic permission set for roles includes: obtaining a preset role weight allocation rule; calculating a dynamic signature weight based on the functional criticality and real-time status of the participating roles; filtering according to the current process stage identifier to generate a preset set of role types that must participate; and binding the dynamic signature weight to the set of role types to generate a dynamic permission set for roles with weight attributes.

[0009] Optionally, the generation of the stage signature identifier includes: monitoring the signature request status of each role in the role dynamic permission set and generating an asynchronous signature task queue; when the total weight of the signed roles in the asynchronous signature task queue reaches a preset stage threshold, triggering an aggregate signature operation; and based on the aggregate signature operation, performing multi-signature verification on the target bidding data to generate a stage signature identifier containing process stage identifiers and weight distribution information.

[0010] Optionally, the multi-signature verification of the target bidding data includes: receiving the encrypted bid document uploaded by the bidder and using it as the target bidding data; setting the current process stage identifier as the bidding stage identifier; binding the permission set combination of the bidding party's receiving end and the current bidder to generate a signature verification symbol containing the bidder's identity fingerprint and the file hash value, thereby completing the multi-signature verification.

[0011] Optionally, generating the data unit with the stage verification label includes: extracting the process stage identifier and the permission set hash value from the stage signature identifier; concatenating the process stage identifier, the permission set hash value, and the target bidding data to generate concatenated data; encrypting the concatenated data based on the current role's dynamic permission set to generate the data unit with the stage verification label.

[0012] Optionally, generating the cross-stage data encapsulation chain includes:

[0013] Obtain the data unit with stage verification tag generated in the previous stage to generate a historical input block; combine the newly generated stage signature identifier with the historical input block to form a data body to be signed; perform a threshold signature operation on the data body to be signed based on the dynamic permission set corresponding to the new stage to generate an encrypted encapsulation chain containing historical link pointers.

[0014] Optionally, calculating the cumulative weight sum of all valid signature contributors includes:

[0015] The weight distribution information of the signature identifiers at each stage in the cross-stage data encapsulation chain is analyzed, and the participating roles that pass the signature verification and their corresponding dynamic signature weights are selected; cross-stage accumulation is performed to generate a cumulative weight sum value.

[0016] Optionally, the method further includes an exception handling step: when it is detected that the total signature weight of the current stage does not reach the preset stage threshold, an exception status code is generated; based on the exception status code, a dynamic reorganization mechanism of the permission set is triggered to recalculate the signature weight of the substitute role; when the total signature weight after reorganization reaches the set proportion of the preset stage threshold, a downgrade signature identifier is generated and an exception mark is recorded.

[0017] Optionally, the generation of the data trust verification result includes: based on the preset traceability weight requirement, comparing the cumulative weight total, and when the stage signature weight total reaches the preset traceability weight requirement, verifying the stage signature and generating a composite verification mark; and generating the data trust verification result based on the composite verification mark.

[0018] Based on the same inventive concept, this invention also provides a secure encryption system for online bidding data transmission based on multi-party signatures. The system includes: a process stage management module: acquiring preset bidding process stage division parameters and generating process stage identifiers; a role dynamic permission management module: generating a set of dynamic permissions for roles based on the process stage identifiers; a stage signature processing module: receiving target bidding data and generating stage signature identifiers based on the set of dynamic permissions for roles and preset threshold signature rules; a data encapsulation and verification module: generating data units with stage verification tags based on the stage signature identifiers and the corresponding process stage identifiers; a cross-stage chain encapsulation module: when a process stage transition is detected, performing chain encapsulation based on the data units of the previous stage and the newly generated stage signature identifiers to generate a cross-stage data encapsulation chain; a weight backtracking analysis module: parsing the historical stage signature identifiers in the cross-stage data encapsulation chain and calculating the cumulative weight sum of all valid signature contributors; and a global trusted verification module: generating a data trusted verification result when the cumulative weight sum reaches a preset traceability weight requirement and all stage signature verifications pass.

[0019] Compared with the prior art, the present invention has the following advantages:

[0020] 1. This invention implements phased dynamic access control in the bidding process. By precisely binding process phase identifiers with dynamic permission sets for roles, it ensures that only authorized roles are allowed to operate on data at each stage, avoiding the risk of unauthorized access. At the same time, the permission set is automatically updated as the stage changes, significantly improving the real-time performance and accuracy of access management.

[0021] 2. Construct a cross-stage tamper-proof data chain. A chain-like encapsulation technology is used to encrypt and associate stage signature identifiers with historical data units, forming a dependent encrypted encapsulation chain. Any tampering with historical data will cause subsequent stage signature verification to fail, fundamentally ensuring the integrity of the bidding data throughout its entire lifecycle.

[0022] 3. Establish a globally trusted verification mechanism for multi-party signatures. By accumulating the effective signature weight across stages and combining it with the dual checks of stage signature verification, a trustworthy data result is generated when the traceability weight requirements are met. This strengthens the non-repudiation of operations in multi-party collaboration scenarios and provides an auditable legal evidence chain for electronic bidding.

[0023] 4. Enhance system fault tolerance under abnormal conditions. When the signature weight does not reach the threshold, a dynamic permission set reorganization mechanism is triggered to maintain process continuity by downgrading the signature identifier. At the same time, anomaly markers are recorded to ensure traceability of operations, effectively responding to emergencies such as temporary role absence and ensuring high robustness of bidding operations.

[0024] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0025] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the structure of a secure encryption method for online bidding data transmission based on multi-party signatures, according to an embodiment of the present invention.

[0027] Figure 2 This is a schematic diagram comparing the signature weight distribution and threshold achievement during the bid evaluation stage in an embodiment of the present invention.

[0028] Figure 3This is a schematic diagram of the cumulative signature weight curve and traceability threshold in an embodiment of the present invention.

[0029] Figure 4 This is a schematic diagram of the structure of an online bidding data transmission security encryption system based on multi-party signature, according to an embodiment of the present invention. Detailed Implementation

[0030] 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 some embodiments of the present invention, 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.

[0031] Reference Figure 1 One embodiment of the present invention proposes a secure encryption method for online bidding data transmission based on multi-party signatures. It adopts process stage identifiers to drive the generation of dynamic permission sets for roles, and constructs a chain-like cross-stage data encapsulation chain by combining threshold signature rules. Through a dual verification mechanism of weight accumulation and stage signature, a complete electronic evidence chain that is tamper-proof can be formed, ensuring the credibility and business continuity of bidding data throughout its entire lifecycle.

[0032] The method described in this embodiment specifically includes:

[0033] Obtain the preset parameters for dividing the bidding process into stages, and generate process stage identifiers;

[0034] Based on the process stage identifier, a dynamic set of role permissions is generated;

[0035] Receive target bidding data, generate a stage signature identifier based on the dynamic permission set of the role and the preset threshold signature rules, wherein the stage signature identifier includes a process stage identifier and a permission set hash value;

[0036] Based on the stage signature identifier and the corresponding process stage identifier, a data unit with a stage verification label is generated.

[0037] When a process phase transition is detected, the data units of the previous phase are chained together with the newly generated phase signature identifier to generate a cross-phase data encapsulation chain.

[0038] Parse the historical stage signature identifiers in the cross-stage data encapsulation chain and calculate the cumulative weight sum of all valid signature contributors;

[0039] When the cumulative weights reach the preset traceability weight requirements and all stage signature verifications pass, a data credibility verification result is generated.

[0040] Specifically, a dynamic permission system is constructed based on process phase divisions, achieving precise phase identification by generating process phase identifiers. Role permission sets are dynamically generated based on these identifiers, and a phase signature identifier containing the process phase identifier and the permission set hash value is generated by combining threshold signature rules. This identifier is used to add phase verification tags to the bidding data, forming data units, and a cross-phase data association chain is established through chain encapsulation during phase transitions. Finally, the cumulative weight of valid signers is calculated by parsing historical signature identifiers. Data credibility is confirmed when the traceability weight requirements are met and all phase signature verifications pass, forming a closed-loop verification mechanism. This achieves dynamic permission control throughout the entire lifecycle of bidding data, ensuring that operations and permissions at each stage are strictly bound. Cross-phase tamper-proof protection is established through chain encapsulation technology; any modification to historical data will destroy the subsequent signature chain. The multi-signature mechanism combined with cumulative weight verification improves the reliability and non-repudiation of multi-party collaboration, and phased tags significantly reduce the risk of unauthorized operations. This provides an auditable legal evidence chain for electronic bidding, effectively ensuring data integrity, process credibility, and business continuity.

[0041] Optionally, generating a dynamic permission set for roles includes: obtaining a preset role weight allocation rule; calculating a dynamic signature weight based on the functional criticality and real-time status of the participating roles; filtering according to the current process stage identifier to generate a preset set of role types that must participate; and binding the dynamic signature weight to the set of role types to generate a dynamic permission set for roles with weight attributes.

[0042] Specifically, the system retrieves preset role weight allocation rules, stored in the system configuration module, which define the weight calculation benchmarks for different participating roles. Dynamic signature weights are calculated based on the functional criticality and real-time status of the participating roles. Functional criticality indicates the role's importance in the bidding process, obtained from a preset functional criticality table. This table assigns values ​​based on role type, such as the bidding party, bidder, or supervisor. Real-time status indicates the role's current availability, such as online or offline, obtained in real-time by the system status monitoring module. The dynamic signature weight w is then calculated. i When using a weighted formula:

[0043] w i =s i ·k i ,

[0044] Where s i Let k be the dynamic signature weight for the i-th role, representing the real-time status value of the i-th role as 1 when online and 0 when offline; iThe functional criticality value for the i-th role is obtained by querying the functional criticality table. Based on the current process stage identifier, such as the bidding stage or the bid evaluation stage identifier, a set of preset role types that must participate is selected from a preset role type library. This library defines the role types that must be included in each stage; for example, the bidding stage must include both the bidding party and the bidder. The calculated dynamic signature weight is bound to the selected set of role types, and a dynamic set of role permissions with weight attributes is generated through data structure mapping.

[0045] For example, in the bid opening stage process, the system obtains the current process stage identifier as the bid opening stage identifier. A preset role weight allocation rule defines a functional criticality table: the bidding party's criticality is 0.8, the bidding party's criticality is 0.6, and the supervisor's criticality is 0.7. Real-time status monitoring shows the bidding party's online status as 1, the bidding party's online status as 1, and the supervisor's offline status as 0. Dynamic signature weights are calculated: w1 equals 0.8 multiplied by 1 (0.8), w2 equals 0.6 multiplied by 1 (0.6), and w3 equals 0.7 multiplied by 0 (0). Based on the bid opening stage identifier, a preset set of mandatory role types is selected; this stage requires the participation of both the bidding party and the bidding party. The dynamic signature weight w1 is bound to the bidding party role type, and w2 is bound to the bidding party role type, generating a dynamic permission set for roles with weight attributes. The beneficial effect of this verification example is that it ensures that key roles such as the bidding party and the bidding party must participate in the signature during the bid opening stage, even if the supervisor is offline, it will not affect the core process. Simultaneously, the dynamic weight calculation avoids invalid role participation, enhances data authenticity and anti-tampering capabilities, and improves the overall credibility of the bidding process.

[0046] Optionally, the generation of the stage signature identifier includes: monitoring the signature request status of each role in the role dynamic permission set and generating an asynchronous signature task queue; when the total weight of the signed roles in the asynchronous signature task queue reaches a preset stage threshold, triggering an aggregate signature operation; and based on the aggregate signature operation, performing multi-signature verification on the target bidding data to generate a stage signature identifier containing process stage identifiers and weight distribution information.

[0047] Optionally, the multi-signature verification of the target bidding data includes: receiving the encrypted bid document uploaded by the bidder and using it as the target bidding data; setting the current process stage identifier as the bidding stage identifier; binding the permission set combination of the bidding party's receiving end and the current bidder to generate a signature verification symbol containing the bidder's identity fingerprint and the file hash value, thereby completing the multi-signature verification.

[0048] Specifically, the system monitors the signature request status of each role in the dynamic permission set. Based on the signature request status, the system creates an asynchronous signature task queue to manage signature tasks for each role, categorized by status. The system calculates the sum of the weights of all signed roles in the asynchronous signature task queue by accumulating the dynamic signature weights of each signed role. If the sum of weights is greater than or equal to a preset stage threshold, an aggregate signature operation is triggered. After triggering the aggregate signature operation, the system receives the encrypted bid document uploaded by the bidder through an encrypted channel. This document is stored as the target bidding data in the system's data buffer. The current process stage identifier is set as the bidding stage identifier, extracted from the preset bidding process stage division parameters. The system binds the permission set combination of the bidding party's receiving end and the current bidder. Based on the threshold signature rules, multi-signature verification is performed on the verification base data. The bidding party's receiving end signs the data using its private key, and the bidder signs the same data using its private key. The system verifies the validity of both signatures. After successful verification, a signature verification symbol is generated, which contains the bidder's identity fingerprint, file hash value, and the aggregate value of both signatures. After successful verification, a stage signature identifier is generated. This identifier contains a process stage identifier and weight distribution information. The process stage identifier is obtained from the current process stage, and the weight distribution information records the weight values ​​and role types of the signed roles. For example... Figure 2 The diagram shown is a comparison of the signature weight distribution and threshold achievement during the bid evaluation stage.

[0049] For example, in the bid evaluation phase, the dynamic permission set for roles includes a dynamic signature weight of 0.8 for the bidding party, 0.6 for the bidders, and 0.7 for the bid evaluation experts. The system monitors the signature request status. Initially, the bidding party's status is signed, the bidder's status is unsigned, and the bid evaluation expert's status is signed. An asynchronous signature task queue is generated, marking the bidding party and bid evaluation expert tasks as signed partitions. The total weight of the signed roles is calculated to be equal to the bidding party's weight of 0.8 plus the bid evaluation expert's weight of 0.7, which equals 1.5. A preset stage threshold value is set to 1.5. When the total weight of the signed roles reaches the threshold value, an aggregated signature operation is triggered to perform multi-signature verification on the target bidding data, such as the bid evaluation report. After successful verification, a stage signature identifier is generated, containing the bid evaluation stage identifier and weight distribution information, such as the bidding party's weight of 0.8 and the bid evaluation expert's weight of 0.7. The beneficial effect of this verification example is that it ensures that the signatures of key roles in the bid evaluation stage, such as the bidding party and the bid evaluation experts, take effect in a timely manner. Even if the bidder does not sign, it will not block the process. The data verification is completed efficiently through the weight accumulation mechanism, which prevents unauthorized modifications and improves the reliability and efficiency of the bidding and bid evaluation process.

[0050] Optionally, generating the data unit with the stage verification label includes: extracting the process stage identifier and the permission set hash value from the stage signature identifier; concatenating the process stage identifier, the permission set hash value, and the target bidding data to generate concatenated data; encrypting the concatenated data based on the current role's dynamic permission set to generate the data unit with the stage verification label.

[0051] Specifically, the process stage identifier and permission set hash value are extracted from the stage signature identifier. The extracted process stage identifier and permission set hash value are then concatenated with the target bidding data in binary format to generate concatenated data.

[0052] D concat =ID phase ||H perms ||D target ,

[0053] Where D concat Indicates concatenated data, ID phase H is the binary representation of the process stage identifier string. perms D is a 128-bit permission set hash value. target This is the binary stream of the target bidding data. Retrieve the current role's dynamic permission set, which contains a list of public keys and corresponding weights for participating roles. Encrypt the concatenated data using a threshold encryption algorithm, generating a shared key from the public key list. The encryption formula is:

[0054]

[0055] Enc is an elliptic curve integrated encryption scheme, and PK... set The public key set of all valid roles in the current role dynamic permission set is used to generate a data unit with a stage verification label. This unit contains encrypted data and plaintext process stage identifiers.

[0056] For example, in the bid awarding phase, the phase signature identifier includes the process phase identifier DB2023 and the permission set hash value 0x8a2f. The target bidding data is the bid awarding resolution document. The process phase identifier DB2023 and the permission set hash value 0x8a2f are extracted and concatenated with the bid awarding resolution document byte-order to form concatenated data. The current role's dynamic permission set includes the bidding party's public key and the supervisor's public key. The bidding party's public key and the supervisor's public key are combined to execute an integrated encryption algorithm to generate encrypted data, forming a data unit with a phase verification tag. The beneficial effect of this verification example is that the bid awarding resolution document is cryptographically bound to the bid awarding phase identifier and the permission set. If the file is maliciously replaced in a subsequent phase, the H_perms will become invalid due to the change in the permission set, making decryption impossible. Simultaneously, the explicit association of the phase identifier avoids cross-phase data confusion, significantly improving the security of the bidding data lifecycle management.

[0057] Optionally, generating the cross-stage data encapsulation chain includes:

[0058] Obtain the data unit with stage verification tag generated in the previous stage to generate a historical input block; combine the newly generated stage signature identifier with the historical input block to form a data body to be signed; perform a threshold signature operation on the data body to be signed based on the dynamic permission set corresponding to the new stage to generate an encrypted encapsulation chain containing historical link pointers.

[0059] Specifically, the process involves retrieving data units with stage verification tags generated in the previous stage as historical input blocks. The newly generated stage signature identifier is then combined with the historical input block in binary to form the data body to be signed. The dynamic permission set corresponding to the new stage, including the public key list and dynamic signature weights of participating roles, is obtained. Signing operations are performed based on preset threshold signature rules, requiring the total sum of currently valid signature weights to reach a threshold value. During signing, each role uses its private key to generate a partial signature on the data body to be signed. When the total dynamic weights of signed roles are satisfied, the partial signatures are aggregated to generate a complete signature. Finally, a cross-stage data encapsulation chain is generated, containing the complete signature, the new stage identifier, and a pointer to the storage address of the historical input block.

[0060] For example, data units generated during the bid evaluation phase serve as historical input blocks. A new stage signature identifier is generated during the bid awarding phase. These are combined to form the data body to be signed. The permission set during the bid awarding phase includes a weight of 0.8 for the bidding party and 0.7 for the supervisory party, with a preset threshold T = 1.2. The bidding party and the supervisory party each generate partial signatures using their private keys, with a total weight of 1.5 ≥ 1.2, which are then aggregated to generate the complete signature. The output encrypted encapsulation chain contains the complete signature, the bid awarding identifier, and a pointer to the data unit's storage address. The beneficial effect of this verification example is that it strongly emphasizes that the bid awarding operation depends on the bid evaluation results. If data units during the bid evaluation phase are maliciously modified, the data body to be signed will change, thus compromising the verification of the complete signature. This forms a cross-stage anti-tampering protection chain, significantly improving the audit reliability and legal evidentiary validity of the bidding process.

[0061] Optionally, calculating the cumulative weight sum of all valid signature contributors includes:

[0062] The weight distribution information of the signature identifiers at each stage in the cross-stage data encapsulation chain is analyzed, and the participating roles that pass the signature verification and their corresponding dynamic signature weights are selected; cross-stage accumulation is performed to generate a cumulative weight sum value.

[0063] Specifically, the cross-stage data encapsulation chain is parsed to obtain data units and stage signature identifiers for multiple stages. Stage signature identifiers are stored in the metadata portion of the encapsulation chain, including process stage identifiers and weight distribution information. The weight distribution information records the dynamic signature weights and role types of the participating signing roles in that stage. During chain parsing, each stage signature identifier is traversed, and the weight distribution information is extracted. For each stage, the signature validity of the stage signature identifier is verified by executing a signature verification algorithm using a public key list, filtering out the verified participating roles and their corresponding dynamic signature weights. A cross-stage accumulation operation is then performed, calculated using the following formula:

[0064] S total =∑w k ,

[0065] Where S total w represents the cumulative weighted sum. k The dynamic signature weight of the kth valid signature contributor is extracted from the weight distribution information of the corresponding stage, where k is the role that has passed the signature verification in all stages.

[0066] For example, when the bidding process includes the bidding stage, the evaluation stage, and the award stage, a cross-stage data encapsulation chain stores the signature identifiers for the three stages. Parsing the bidding stage identifier reveals that the effective roles are the bidding party (0.8 weight) and the bidder (0.6 weight), and the signature verification passes. The evaluation stage identifier shows that the effective role is the evaluation expert (0.7 weight), and the signature verification passes. The award stage identifier shows that the effective role is the supervisor (0.9 weight), and the signature verification passes. All effective weights are filtered and accumulated; the total accumulated weight equals 0.8 (bidding stage), 0.6 (bidding stage), 0.7 (evaluation stage), and 0.9 (award stage), which equals 3.0. The beneficial effect of this verification example is that it mandates that the effective signature weights of each stage be included in the global accumulation. If a stage, such as the evaluation stage, is maliciously modified, its signature verification failure will exclude the weight of that stage, resulting in an insufficient total accumulated weight to meet the preset traceability weight requirements. This exposes the tampering behavior, effectively preventing cross-stage collaborative attacks and significantly enhancing the reliability of bidding data auditing and the integrity of legal evidence.

[0067] Optionally, the method further includes an exception handling step:

[0068] When the total signature weight of the current stage is detected to be less than the preset stage threshold, an abnormal status code is generated; based on the abnormal status code, a dynamic reorganization mechanism of the permission set is triggered to recalculate the signature weight of the substitute role; when the total signature weight after reorganization reaches the set proportion of the preset stage threshold, a downgraded signature identifier is generated and an abnormal mark is recorded.

[0069] Specifically, the system monitors the total signature weight of the current stage. When the total signature weight of the current stage is less than a preset stage threshold, the system generates an abnormal status code, indicating insufficient signature weight. Based on the abnormal status code, a dynamic permission set reorganization mechanism is triggered. This mechanism includes retrieving alternative role types, such as supervisors or agents, from a preset alternative role library, recalculating the signature weights of these alternative roles, and calculating the new total signature weight after reorganization. When the new total signature weight is greater than or equal to the product of the preset stage threshold and a set ratio (where the set ratio is a downgrade threshold obtained from the system configuration), the system generates a downgraded signature identifier. This identifier contains the process stage identifier and weight distribution information but with an additional downgrade flag, and the abnormal flag is recorded in the audit log.

[0070] For example, during the bid evaluation stage, if the current total signature weight is detected to be 1.3, which is less than the preset stage threshold of 1.5, an abnormal status code is generated. This triggers a dynamic reorganization of the permission set, selecting a proxy supervisor from the alternative role pool. The proxy supervisor's functional criticality is set to 0.7 and their online status to 1. The new proxy supervisor's weight is calculated to be 0.7, resulting in a new total signature weight of 1.5 after reorganization. Setting the ratio α to 0.8, and multiplying it by the preset stage threshold to 1.2, the new total signature weight is greater than or equal to 1.2. A downgraded signature identifier is generated, containing the bid evaluation stage identifier and the proxy supervisor's weight of 0.7, and an abnormal flag is recorded. The beneficial effect of this verification example is that when the weight of core roles such as bid evaluation experts is insufficient, the system automatically introduces alternative roles to complete the signature, preventing the bid evaluation process from stalling. Simultaneously, the downgraded identifier and abnormal flag ensure that subsequent audits can identify non-ideal operations, preventing malicious use of anomalies to tamper with data, and significantly improving the flexibility and reliability of the bidding process.

[0071] Optionally, the generation of the data trust verification result includes: based on the preset traceability weight requirement, comparing the cumulative weight total, and when the stage signature weight total reaches the preset traceability weight requirement, verifying the stage signature and generating a composite verification mark; and generating the data trust verification result based on the composite verification mark.

[0072] Specifically, based on a preset traceability weight requirement—a system-preset global weight threshold—the system compares the cumulative weights of all valid signature contributors across stages. When the total cumulative weight is greater than or equal to the global weight threshold, a stage signature verification operation is performed. This stage signature verification operation involves traversing the signature identifier of each stage in the cross-stage data encapsulation chain, verifying its signature validity using the corresponding stage's public key set, and generating a composite verification token after all stage verifications pass. Once the composite verification token is generated, the data trusted verification result generation module is triggered, outputting a trusted verification result containing the verification timestamp and stage integrity status.

[0073] For example, the preset traceability weight requirement is 3.5, and the cumulative weight sum is 4.2. If the cumulative weight sum exceeds the preset traceability weight requirement, stage signature verification is triggered. The verification process sequentially verifies the signatures using the tendering party's public key during the bidding stage, the evaluation committee's public key during the bid evaluation stage, and the supervisory party's public key during the awarding stage. After all verifications pass, a composite verification token is generated. The final output data credibility verification result includes a timestamp of 2023-11-01T10:30:00Z and a status field VALID. The beneficial effect of this verification example is that it provides dual protection for the legal validity of the bidding data: the cumulative weight requirement ensures the full participation of key roles, and the stage signature verification ensures the authenticity and traceability of each operation, effectively preventing post-event tampering with bidding results or denial of decisions, and significantly improving the judicial evidence collection capabilities of electronic bidding.

[0074] Based on the same inventive concept, such as Figure 4 As shown, the present invention also provides a secure encryption system for online bidding data transmission based on multi-party signatures, the system comprising:

[0075] Process Stage Management Module: Obtains preset bidding process stage division parameters and generates process stage identifiers;

[0076] Role-based dynamic permission management module: Generates a set of dynamic permissions for roles based on the process stage identifier;

[0077] Stage signature processing module: Receives target bidding data and generates stage signature identifiers based on the dynamic permission set of the role and the preset threshold signature rules;

[0078] Data encapsulation and verification module: Based on the stage signature identifier and the corresponding process stage identifier, generate data units with stage verification labels;

[0079] Cross-stage chain encapsulation module: When a process stage transition is detected, the data unit of the previous stage is chained and encapsulated in combination with the newly generated stage signature identifier to generate a cross-stage data encapsulation chain.

[0080] Weighted backtracking analysis module: parses the historical stage signature identifiers in the cross-stage data encapsulation chain and calculates the cumulative weight sum of all valid signature contributors;

[0081] Global Trusted Verification Module: When the cumulative weight sum reaches the preset traceability weight requirement and all stage signature verifications pass, a data trusted verification result is generated.

[0082] It should be noted that the electrical connections between the various units described above do not necessarily represent direct or indirect connections. Any indirect connection method is applicable to the embodiments of the present invention as long as it achieves the purpose of the present invention. The above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the present invention.

[0083] All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of this invention upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this invention that follow the general principles of this invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A secure encryption method for online bidding data transmission based on multi-party signatures, characterized in that, include: Obtain the preset parameters for dividing the bidding process into stages, and generate process stage identifiers; Based on the process stage identifier, a dynamic set of role permissions is generated; Receive target bidding data, generate a stage signature identifier based on the dynamic permission set of the role and the preset threshold signature rules, wherein the stage signature identifier includes a process stage identifier and a permission set hash value; Based on the stage signature identifier and the corresponding process stage identifier, a data unit with a stage verification label is generated. When a process phase transition is detected, the data units of the previous phase are chained together with the newly generated phase signature identifier to generate a cross-phase data encapsulation chain. Parse the historical stage signature identifiers in the cross-stage data encapsulation chain and calculate the cumulative weight sum of all valid signature contributors; When the cumulative weights reach the preset traceability weight requirements and all stage signature verifications pass, a data credibility verification result is generated.

2. The secure encryption method for online bidding data transmission based on multi-party signature as described in claim 1, characterized in that, The generated dynamic permission set for roles includes: Obtain the preset role weight allocation rules, and calculate the dynamic signature weight based on the functional criticality and real-time status of the participating roles; Based on the current process stage identifier, a set of preset role types that must participate is generated; The dynamic signature weight is bound to the set of role types to generate a dynamic permission set for roles with weight attributes.

3. The secure encryption method for online bidding data transmission based on multi-party signature as described in claim 1, characterized in that, The signature identifier for the generation stage includes: Monitor the signature request status of each role in the dynamic permission set and generate an asynchronous signature task queue; When the total weight of the signed roles in the asynchronous signature task queue reaches a preset stage threshold, an aggregate signature operation is triggered. Based on aggregated signature operations, multi-signature verification is performed on the target bidding data to generate a stage signature identifier that includes process stage identifiers and weight distribution information.

4. The secure encryption method for online bidding data transmission based on multi-party signature as described in claim 3, characterized in that, The multi-signature verification of the target bidding data includes: Receive encrypted bid documents uploaded by bidders and use them as target bidding data; Set the current process stage identifier to the bidding stage identifier; Bind the permission set combination of the receiving end of the bidding party and the current bidder to generate a signature verification symbol containing the bidder's identity fingerprint and file hash value, and complete the multi-signature verification.

5. A secure encryption method for online bidding data transmission based on multi-party signatures as described in claim 1, characterized in that, The data unit that generates the stage verification label includes: Extract the process stage identifier and permission set hash value from the stage signature identifier; The process stage identifier, permission set hash value, and target bidding data are concatenated to generate concatenated data; The concatenated data is encrypted based on the current role's dynamic permission set, generating data units with stage verification tags.

6. The secure encryption method for online bidding data transmission based on multi-party signature as described in claim 1, characterized in that, The generation of the cross-stage data encapsulation chain includes: Retrieve data units with stage verification labels generated in the previous stage to generate historical input blocks; The newly generated stage signature identifier is combined with the historical input block to form the data body to be signed; Based on the dynamic permission set corresponding to the new stage, a threshold signature operation is performed on the data body to be signed to generate an encrypted encapsulation chain containing historical link pointers.

7. A secure encryption method for online bidding data transmission based on multi-party signatures as described in claim 1, characterized in that, The calculation of the cumulative weight sum of all valid signature contributors includes: The weight distribution information of the signature identifiers at each stage in the cross-stage data encapsulation chain is analyzed to filter the participating roles that pass the signature verification and their corresponding dynamic signature weights. Perform cross-stage accumulation to generate a cumulative weighted sum.

8. A secure encryption method for online bidding data transmission based on multi-party signatures according to claim 7, characterized in that, The method also includes an exception handling step: When the total signature weight of the current stage is detected to be less than the preset stage threshold, an abnormal status code is generated. Based on the abnormal status code, a dynamic reorganization mechanism for the permission set is triggered, and the signature weight of the replaceable role is recalculated. When the total weight of the recombined signatures reaches a preset threshold value, a downgraded signature identifier is generated and an anomaly marker is recorded.

9. A secure encryption method for online bidding data transmission based on multi-party signatures according to claim 1, characterized in that, The generated data credibility verification results include: Based on the preset traceability weight requirements, the cumulative weight is compared. When the total stage signature weight reaches the preset traceability weight requirements, the stage signature is verified and a composite verification mark is generated. Based on composite verification tags, generate data credibility verification results.

10. A secure encryption system for online bidding data transmission based on multi-party signatures, applied to the secure encryption method for online bidding data transmission based on multi-party signatures as described in any one of claims 1-9, characterized in that, The system includes: Process Stage Management Module: Obtains preset bidding process stage division parameters and generates process stage identifiers; Role-based dynamic permission management module: Generates a set of dynamic permissions for roles based on the process stage identifier; Stage signature processing module: Receives target bidding data and generates stage signature identifiers based on the dynamic permission set of the role and the preset threshold signature rules; Data encapsulation and verification module: Based on the stage signature identifier and the corresponding process stage identifier, generate data units with stage verification labels; Cross-stage chain encapsulation module: When a process stage transition is detected, the data unit of the previous stage is chained and encapsulated in combination with the newly generated stage signature identifier to generate a cross-stage data encapsulation chain. Weighted backtracking analysis module: parses the historical stage signature identifiers in the cross-stage data encapsulation chain and calculates the cumulative weight sum of all valid signature contributors; Global Trusted Verification Module: When the cumulative weight sum reaches the preset traceability weight requirement and all stage signature verifications pass, a data trusted verification result is generated.

Images