Digital certificate authentication security electronic signature implementation method under multi-party cooperative operation mechanism

Abstract

The invention discloses a digital certificate authentication security electronic signature implementation method under a multi-party cooperative operation mechanism, particularly relates to the field of computer data processing, and is used for solving the problems that in multi-party cooperative signature, identity roles of participants are difficult to check consistently, session binding is easy to reuse, and a signature result lacks a traceable evidence chain. The server generates a to-be-signed abstract for the to-be-signed content and generates a session identifier and a pre-challenge code, the collaborative participant generates a participation proof based on a participant digital certificate, and the server verifies the participation proof, calculates a certificate role constraint coincidence level and a session echo chain anti-replay level and then outputs a collaborative session credibility level; generating a certification abstract and issuing a signature challenge code or an enhanced signature challenge code, calculating a threshold signature share for the combined abstract by the selected collaborative participant, converging the threshold signature share by the server to generate a signature value and a signature packet, re-calculating the combined abstract and the certification abstract by the verifier, verifying the signature value and participating in certification; and credible judgment and consistent verification of multi-party collaborative signing are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer data processing, and more particularly, to a method for implementing a digital certificate authentication secure electronic signature under a multi-party collaborative operation mechanism. BACKGROUND

[0002] In existing secure electronic signature systems, the identity of the signing subject and the public key are usually first bound by a digital certificate, and the business system then verifies the signature result using the certificate to confirm the authenticity and integrity of the signature. In order to reduce the risk of centralized private key storage, more and more solutions split the signature capability among multiple participants, with the terminal and server holding their own key factors or key components, and generating a signature result through multi-party collaborative operation when signing. At the same time, the server side often applies for and saves the corresponding certificate to the digital certificate service agency according to the public key information obtained through collaborative operation, and the business side directly relies on the certificate to complete the authentication and signing loop. This design takes into account certificate authentication and collaborative security, and is easier to integrate and land quickly in Internet businesses.

[0003] However, the existing approach generally focuses on "being able to generate a signature that passes verification" and "the certificate and public key can be matched", but lacks a means for the system to automatically confirm that "this signature is indeed completed according to the agreed multi-party collaborative operation process". The root of the problem is that certificate verification can only show that the signature result matches the public key in the certificate, and cannot prove that the collaborative process meets the established strategy, nor can it show whether the collaborative participants are real, whether the process messages are replaced, or whether the process is still treated as the same signing after abnormal retries or state branching. In actual operation, once the participants are replaced, the link retry causes the process to repeat, or the internal link is improperly called, the system may still produce a signature that looks completely normal and passes verification, but an external third party cannot independently determine whether the collaborative process is reliable based on the certificate and signature result, and can only rely on internal logs to explain what happened. Logs naturally have inconsistent standards and are difficult to review, ultimately causing "digital certificate authentication secure electronic signature under a multi-party collaborative operation mechanism" to have a breakpoint in auditing, accountability, and dispute resolution, weakening the security and trust advantages that the collaborative mechanism should bring.

[0004] To solve the above problems, a technical solution is provided. SUMMARY

[0005] In order to overcome the above-mentioned defects of the prior art, the embodiment of the present application provides a digital certificate authentication secure electronic signature implementation method under a multi-party collaborative operation mechanism, a server generates a to-be-signed digest for to-be-signed content and generates a session identifier and a pre-challenge code, a collaborative participant generates a participation proof based on a participant digital certificate, the server verifies the participation proof and calculates a certificate role constraint fitting level and a session echo chain anti-replay level, and then outputs a collaborative session trust level, generates a proof digest and issues a signature challenge code or a strengthened signature challenge code, the selected collaborative participant calculates a threshold signature share for the combined digest and generates a signature value and a signature package by the server, and a verifier recalculates the combined digest and the proof digest and verifies the signature value and the participation proof, thereby realizing trust determination and consistent verification of multi-party collaborative signing, so as to solve the problems in the above background art.

[0006] To achieve the above object, the present application provides the following technical scheme: S1: receiving a signing request, extracting to-be-signed content to generate a to-be-signed digest, reading a signature digital certificate, generating a session identifier based on the to-be-signed digest, generating a pre-challenge code based on the session identifier, and sending the pre-challenge code to a collaborative participant; S2: the collaborative participant receives the pre-challenge code, uses the signature private key corresponding to the participant digital certificate to sign the to-be-signed digest, the session identifier and the pre-challenge code, generates a participation proof, and returns the participation proof and the session identifier; S3: the server receives the participation proof and completes validity verification, makes a trust determination based on certificate constraint information and session binding information, and selects to enter the participation proof summary and generate a proof digest according to the determination result; S4: the selected collaborative participant receives the signature challenge code and the proof digest, calculates a signature share for the combined digest of the to-be-signed digest and the proof digest using a local key component, returns the signature share and the session identifier, the server aggregates the signature share to generate a signature value, and generates a signature package; S5: verifying the signature value using the signature digital certificate; verifying that the signature input used to generate the signature value at least includes the to-be-signed digest and the proof digest; verifying each participation proof one by one, and verifying that each participation proof is bound to the to-be-signed digest and the session identifier; verifying that the participation proof set meets the collaborative strategy; if the verification fails, outputting a failure type and participant digital certificate sequence information; the server receives the failure information and writes it into a historical echo library, and updates a rejection fragment set of a role template fragment string.

[0007] Further, after receiving the signing request, the original text of the to-be-signed content is extracted and normalized processing is performed, and the normalized to-be-signed content is output; the fixed hash operation is performed on the normalized to-be-signed content to generate the to-be-signed digest.

[0008] Further, read the signature digital certificate and complete the certificate chain verification and certificate status verification, extract the signature digital certificate sequence information; generate a session random quantity, concatenate the to-be-signed digest and the session random quantity in length prefix manner and write to purpose marker 1 to obtain a session identifier, concatenate the session identifier and the session random quantity in length prefix manner and write to purpose marker 2, and then perform fixed hash operation to obtain a pre-challenge code; write to the session table and issue the session identifier and the pre-challenge code.

[0009] Further, after the collaborative participant receives the session identifier and the pre-challenge code, the participant digital certificate and the corresponding signature private key are read, the validity period verification and the purpose verification are completed, and the participant digital certificate sequence information is extracted; the collaborative participant reads the to-be-signed content and performs standardization processing to obtain standardized to-be-signed content, and performs fixed hash algorithm on the standardized to-be-signed content to generate a to-be-signed digest.

[0010] Further, the collaborative participant writes the to-be-signed digest, the session identifier, the pre-challenge code and the participant digital certificate sequence information in a fixed order to form a participant proof to-be-signed string, each segment of the participant proof to-be-signed string is written to a field category identifier, field length information and field content body, and fixed hash algorithm is performed on the participant proof to-be-signed string to obtain a participant proof to-be-signed digest; the signature private key is used to perform signature operation on the participant proof to-be-signed digest to obtain a signature value, and the participant proof is packaged in a fixed field order and returned with the session identifier.

[0011] Further, after the server receives the session identifier and the participant proof, the to-be-signed digest and the pre-challenge code are obtained from the session table, the participant digital certificate sequence information is extracted from the participant proof and the participant digital certificate is located, the participant proof to-be-signed string is reproduced according to the to-be-signed digest, the session identifier, the pre-challenge code and the participant digital certificate sequence information, and the reproduced participant proof to-be-signed digest is calculated, the reproduced participant proof to-be-signed digest is verified to be consistent with the participant proof to-be-signed digest, the signature value is verified using the participant digital certificate public key, the participant proof that passes the verification is written to the candidate set and recorded to the session evidence area.

[0012] Further, the server parses the participant digital certificate corresponding to the candidate set to generate a field alignment table and maps the certificate role constraint coincidence level, sorts the candidate set according to the participant digital certificate sequence information to generate an echo chain digest and query the historical echo library to obtain the reuse trace marker and the drift trace marker, and then maps the session echo chain anti-replay level, the complementary gate decision maker outputs the collaborative session trust level according to the certificate role constraint coincidence level and the session echo chain anti-replay level and performs session handling action, in the two cases of trust passing and intensive challenge, generates a proof digest, and issues a signature challenge code or an intensive signature challenge code.

[0013] Further, after receiving the proof digest and the signature challenge code or the enhanced signature challenge code, the selected collaborative participant writes the to-be-signed digest and the proof digest in a fixed order into a combined digest to-be-signed string according to a deterministic encoding, calculates a combined digest, selects the signature challenge code or the enhanced signature challenge code as a challenge code input, and derives a random number share based on a local random salt, performs scalar multiplication on the random number share using an elliptic curve base point to generate a curve point share, and returns the curve point share.

[0014] Further, the server aggregates the curve point shares in the selected set to obtain an aggregated curve point, writes the aggregated curve point, the signature digital certificate public key, and the combined digest into a challenge to-be-signed string in a fixed order, calculates a challenge value and issues the challenge value, the selected collaborative participant calculates a response share based on the challenge value random number share key component, and returns the response share; the server verifies the consistency of the session identifier and the consistency of the curve point share identifier, aggregates the response share to generate an aggregated response, forms a signature value, and performs a public verification equation self-check, and generates a signature package in a fixed field order and a deterministic sequence after passing the self-check.

[0015] Further, the verifier parses the signature package to obtain the signature digital certificate, the participant digital certificate, the participant proof set, the proof digest, the session identifier, the pre-challenge code, and the signature value, checks the field type identifier and the field length information in a fixed field order, and completes certificate chain verification and state verification; the to-be-signed content is standardized and a to-be-signed digest is calculated, the combined digest is recalculated, and the signature value is verified using the signature digital certificate public key; the participant proof to-be-signed digest is recalculated using the to-be-signed digest, the session identifier, the pre-challenge code, and the participant digital certificate sequence information, and the participant proof is verified, the proof digest is recalculated, and the consistency of the collaborative strategy is checked, and a failure type and a participant digital certificate sequence information set are output and written into a historical echo library.

[0016] The technical effects and advantages of the digital certificate authentication secure electronic signature implementation method under the multi-party collaborative operation mechanism of the present application are as follows: 1. The to-be-signed digest, the session identifier, the pre-challenge code, and the participant proof to-be-signed digest form an integrated session binding link; the participant proof is reproduced on the server side to complete consistency checking and signature checking; the signature package is recalculated on the verifier side to complete three times of repeated checking, the signature value and the participant proof set and the to-be-signed content are closed in the same evidence chain, the hidden risk caused by cross-session reuse and content replacement is reduced, and the verifiability and traceability of the collaborative signing result are improved.

[0017] 2. Certificate role constraint fitting level is converted into alignable evidence by aligning certificate policy identification set, key usage set, extension usage set, issuer identification, subject identification with field alignment table through role template fragment string, session echo chain anti-replay level is converted into distinguishable input by multiplexing track of participating proof set and pre-challenge code drift track with historical echo library through echo chain digest, complementary gate decision maker decides identity role direction and session binding direction together and outputs cooperative session trust level, so that the disposal of refusing to sign retransmission session strengthens challenge trust to pass has explainable source, reduces policy misjudgment and dispute positioning cost.

[0018] 3. Proof digest solidifies selected set into unique fingerprint, signature challenge code and strengthened signature challenge code write proof digest and echo chain digest into challenge constraint, threshold signature share calculation takes combined digest as unique signature input and completes share consistency check through session identification consistency and signature first parameter consistency, server aggregates signature value and then uses deterministic encoding sequence to generate signature package, cooperative participants and server aggregation form stable cooperation relationship, realizing safe aggregation and repeatable verification of multi-party cooperative signature without increasing complex interaction. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 The figure is a flowchart of the method for realizing digital certificate authentication and secure electronic signature under the multi-party cooperative operation mechanism of the application. DETAILED DESCRIPTION

[0020] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work are within the protection scope of the application.

[0021] Embodiment 1 Figure 1 The method for realizing digital certificate authentication and secure electronic signature under the multi-party cooperative operation mechanism of the application is given, including: S1: receiving a signing request, extracting to-be-signed content to generate a to-be-signed digest, reading a signature digital certificate, generating a session identification based on the to-be-signed digest, generating a pre-challenge code based on the session identification, and sending the pre-challenge code to cooperative participants.

[0022] S2: the cooperative participants receive the pre-challenge code, use the signature private key corresponding to the participant digital certificate to perform signature on the to-be-signed digest, the session identification and the pre-challenge code, generate a participant proof, and return the participant proof and the session identification.

[0023] S3: The server receives the participation proof and completes the validity verification, makes a trusted judgment based on the certificate constraint information and the session binding information, selects to enter the participation proof summary and generate a proof digest according to the judgment result, or issues a strengthened signature challenge code, or invalidates the session identifier and refreshes the pre-challenge code, or outputs the rejection reason and seals the session evidence.

[0024] S4: The selected collaborative participants receive the signature challenge code and the proof digest, use the local key component to calculate the signature share of the combined digest of the to-be-signed digest and the proof digest, return the signature share and the session identifier, the server aggregates the signature share to generate a signature value, and generates a signature package.

[0025] S5: Verify the signature value using the signature digital certificate; check that the signature input used to generate the signature value at least contains the to-be-signed digest and the proof digest; verify the signature of each participation proof one by one, and check that each participation proof is bound to the to-be-signed digest and the session identifier; check that the participation proof set meets the collaborative strategy; if the verification fails, output the failure type and the participant digital certificate sequence information; the server receives the failure information and writes it into the historical echo library, and updates the rejection fragment set of the role template fragment string.

[0026] In the electronic signature scenario of multi-party collaborative operation, the signature value needs to meet the validity of certificate authentication and the consistency of session binding at the same time. If the to-be-signed content is not converted into a stable and consistent to-be-signed digest in the entry stage, the to-be-signed string may be inconsistent when the participants generate the participation proof, and it is also difficult for the server to confirm the same session boundary when verifying the participation proof. If the session identifier and the pre-challenge code are not made into a strong binding mark in the entry stage, the participation proof may be reused under the conditions of retry and forwarding, and the discrimination of the echo chain digest will lose the basis for comparison. However, the entry stage cannot introduce too many parameters to ensure the consistency and engineering feasibility of multi-party implementation, so step S1 is developed around the to-be-signed digest, the session identifier, the pre-challenge code and the certificate verification.

[0027] S101 Normalize the to-be-signed content.

[0028] The differences in the to-be-signed content in different terminals and different transmission links often include character encoding differences, line break differences, white space quantity differences, and field arrangement differences. The pre-challenge code and the certificate verification are carried out in step S2. These differences do not change the business semantics but change the digest results, thereby causing the participants to generate different participation proofs for the same text. After the server receives the signing request, the original text of the to-be-signed content is extracted, normalized processing is performed, and the normalized to-be-signed content is output. The normalization processing uniformly converts the character encoding to a fixed encoding, uniformly converts the line break to a fixed line break format, compresses the white space into a single white space form, fixes the field order to the order of lexicographic arrangement according to the field key name, and when a duplicate key name is encountered, a position serial number is added according to the order of appearance and the serial number rule is fixed. The normalized to-be-signed content obtained after the normalization processing has a unique serialized representation. The same semantic input produces the same normalized to-be-signed content in different device sides. The understanding of the to-be-signed content by the participants when generating the participation proof is no longer dependent on the terminal format difference. The server can also reproduce the same content structure when reviewing the participation proof to-be-signed string.

[0029] S102 to-be-signed digest calculation.

[0030] The to-be-signed digest needs to map the normalized to-be-signed content to a fixed-length digest value, ensuring that the length is fixed to facilitate the splicing of the participation proof to-be-signed string, and ensuring that the same input produces the same output to facilitate the consistency of multiple parties. The server performs a fixed hash operation on the normalized to-be-signed content. The hash operation receives the normalized to-be-signed content in the form of a bit string and outputs a fixed-length bit string. The output result is denoted as the to-be-signed digest. The fixed hash operation only depends on the normalized to-be-signed content itself and does not introduce external time information and external environment information, thereby avoiding different to-be-signed digests for the same content at different times. After the to-be-signed digest is determined, the participants can write the to-be-signed digest in the participation proof to-be-signed string to express the signed semantics. The verifier can also use the to-be-signed digest as the unique representative of the signed content when verifying the signature value, thereby reducing the dependence on the transmission and analysis of long texts.

[0031] S103 signature digital certificate reading and verification.

[0032] The signature digital certificate binds the identity of the signing subject with the public key, and the stability of the certificate chain and the certificate status directly determines the degree of acceptance of the signature result on the verification side. The server reads the signature digital certificate and extracts the signature digital certificate sequence information, which is written into the session table as the unique identification of the certificate. The certificate chain verification first verifies the integrity of the signing link from the signature digital certificate to the root certificate, and then verifies that the validity period of the signature digital certificate covers the session creation time. The certificate status verification is performed in sequence, and the certificate status service must carry the signature digital certificate sequence information and the state effective time when returning the state response, and is signed by the certificate status service using its own signature certificate. The server verifies the signature of the state response and checks the consistency of the signature digital certificate sequence information, confirms that the revocation status and the frozen status are both allowed to use, and then releases it. After the certificate chain verification and the certificate status verification, the signature digital certificate sequence information is locked in the session table, and the verification party can use the same certificate positioning information to complete the review when verifying the signature package.

[0033] S104 session identification and pre-challenge code generation.

[0034] The session identification needs to bind the to-be-signed digest and the randomness of the session together, ensuring that the same to-be-signed digest will not have the same session identification in different signing sessions. The pre-challenge code needs to bind the session identification and the session randomness again and compress it into a fixed length, so that the participating proof to-be-signed string has a stable and short session binding mark. The server generates a session randomness from a cryptographically secure random source, and the session randomness has a fixed length and satisfies the unpredictability. The server concatenates the to-be-signed digest and the session randomness in length prefix order, writes usage marker one in the concatenation content as a session identification usage declaration, and then obtains the session identification. The server concatenates the session identification and the session randomness in length prefix order, writes usage marker two in the concatenation content as a pre-challenge code usage declaration, usage marker two is different from usage marker one, and then performs a fixed hash operation on the concatenation result, outputs a fixed length result as the pre-challenge code. The session identification and the pre-challenge code can be distinguished in structure and cannot be interchanged in use. The participant writes the session identification and the pre-challenge code into the participating proof to-be-signed string when generating the participating proof, and the server can verify the session boundary and the session freshness characteristics when verifying the participating proof.

[0035] S105 session table writing and pre-challenge code issuing.

[0036] The session table needs to provide unique lookup and non-ambiguous review capabilities, so that the server can locate the unique session record with the session identifier when receiving the participation certificate, and reproduce the constituent elements of the participation certificate to be signed string. The server writes the session identifier, the to-be-signed digest, the pre-challenge code, and the signed digital certificate sequence information to the session table. The session table writes with a one-time write semantic, prohibits the modification of the to-be-signed digest and the pre-challenge code for the same session identifier, and avoids multiple to-be-signed digests corresponding to the same session identifier. The server generates and issues a message, and the issued message only contains the session identifier, the pre-challenge code, and the signed digital certificate sequence information. The issued message does not contain the original text of the to-be-signed content, so as to avoid the repeated propagation of the to-be-signed content on the link side. The server sends the issued message to the collaborative participants and records the sending result. When the sending is successful, the session table state is marked as issued completed. When the sending fails, the session table state is marked as issued failed and the failure reason is recorded. After receiving the session identifier and the pre-challenge code, the collaborative participants can construct the participation certificate to be signed string and sign out the participation certificate. After receiving the participation certificate, the server can locate the session table record with the session identifier and complete the signature verification review.

[0037] After the entry stage is completed, the to-be-signed digest accurately expresses the semantic fingerprint of the standardized to-be-signed content, the session identifier accurately expresses the boundary of the one-time signing session, the pre-challenge code accurately expresses the session binding marker that needs to be carried by the participation certificate, and the signed digital certificate sequence information accurately expresses the signature subject certificate positioning information. The session table saves the unique correspondence between the session identifier and the to-be-signed digest and the pre-challenge code. The collaborative participants generate the participation certificate according to the session identifier and the pre-challenge code. The server reproduces the participation certificate to be signed string according to the session table and verifies the validity of the participation certificate. The verifier locates the certificate according to the signed digital certificate sequence information and reviews the signature result.

[0038] The to-be-signed digest, the session identifier, and the pre-challenge code are generated and issued in step S1. The participant digital certificate sequence information exists in the participant digital certificate. The participation certificate needs to bind the four types of information in the same signature input, so that the server can reproduce the participation certificate to be signed digest and complete the signature verification in the subsequent verification stage. However, once the participant digital certificate is invalid or does not match the purpose, the participation certificate cannot be recognized even if it is generated. If the coding rules are inconsistent, the participation certificate to be signed digest will be different between different implementations. Step S2 needs to complete the certificate verification and coding constraint before the signature action.

[0039] S201 Certificate verification and input check.

[0040] The participation proof needs to be signed by the server using the participant digital certificate public key. If the participant digital certificate is invalid or the use is not allowed to sign, the participation proof will be directly judged invalid. After receiving the session identifier and pre-challenge code, the collaborative participant reads the participant digital certificate and the signature private key corresponding to the participant digital certificate, performs validity check and use check, and checks the key use field and the extension use field containing the signature use at the same time. The collaborative participant reads the to-be-signed content from the same signed request, completes character encoding unification, line unification, space compression, and field order fixing according to the same normalization method in step S1, obtains normalized to-be-signed content, and then performs fixed hash algorithm on the normalized to-be-signed content to obtain a to-be-signed digest.

[0041] The collaborative participant extracts the participant digital certificate sequence information, and performs format check on the session identifier and pre-challenge code. The format check includes length format consistency check and use mark consistency check. The use mark refers to a fixed byte sequence, which is used to distinguish the use category of the session identifier and the pre-challenge code, so as to avoid the exchange of the session identifier and the pre-challenge code. After the certificate verification and input check are completed, the participant digital certificate sequence information and the to-be-signed digest remain stable and consistent locally, and the participation proof generation action can form a reproducible binding relationship without relying on external mapping table.

[0042] S202 Participation proof to-be-signed string encoding and participation proof to-be-signed digest calculation.

[0043] The participation proof to-be-signed string needs to obtain the same byte sequence in different participant implementations, otherwise the participation proof to-be-signed digest cannot be consistent, and the server cannot reproduce the participation proof to-be-signed digest to complete the signature verification. The collaborative participant writes the to-be-signed digest, the session identifier, the pre-challenge code, and the participant digital certificate sequence information into the participation proof to-be-signed string in a fixed order. The writing order is fixed as follows: the to-be-signed digest is in front, the session identifier is behind, the pre-challenge code is followed, and the participant digital certificate sequence information is last. Each segment uses deterministic encoding, which includes field category identification, field length information, and field content body. The field category identification is a fixed byte sequence, which is used to indicate that the current paragraph belongs to the to-be-signed digest or the session identifier or the pre-challenge code or the participant digital certificate sequence information. The field length information is used to indicate the byte length of the field content body. The field length information uses a fixed number of bytes to represent and uses a unified byte sequence. The field content body uses unified character encoding or unified binary encoding. After the collaborative participant completes the writing of the four segments, the participation proof to-be-signed string is obtained, and then the fixed hash algorithm is performed on the participation proof to-be-signed string to obtain the participation proof to-be-signed digest. The participation proof to-be-signed digest is a fixed-length digest value, which fixes the order and boundary of the four segments of content. When the server side reconstructs the participation proof to-be-signed string, different digests will not occur due to ambiguous splicing.

[0044] S203 Participation proof signature generation and return packaging.

[0045] The participation proof needs to have identity binding and non-repudiation at the same time. The signature private key corresponding to the participant digital certificate is used to generate a signature value, and the participant digital certificate is used to complete signature verification on the server side. The co-participant uses the signature private key corresponding to the participant digital certificate to perform signature operation on the to-be-signed digest of the participation proof to obtain a signature value. The signature operation adopts the signature algorithm declared by the participant digital certificate, the signature input only contains the to-be-signed digest of the participation proof, and the signature output is a fixed-length or variable-length signature value. The co-participant encapsulates the participant digital certificate sequence information, the to-be-signed digest of the participation proof, and the signature value in the order of the determined fields as the participation proof, the encapsulation order is fixed, the field boundary is represented by length prefix, and parsing ambiguity is avoided. The co-participant returns the participation proof and the session identifier. The session identifier in the return message is used for the server to locate the session table record, and the participation proof is used for the server to verify and extract the participant digital certificate sequence information. After the return of the participation proof is completed, the server can retrieve the to-be-signed digest and the pre-challenge code according to the session identifier, locate the participant digital certificate according to the participant digital certificate sequence information, and reproduce the to-be-signed string of the participation proof and complete the verification check.

[0046] At the end of step S2, the to-be-signed digest, the session identifier, the pre-challenge code, and the participant digital certificate sequence information are compressed into the participation proof to-be-signed digest and signed by the signature private key corresponding to the participant digital certificate. The participation proof structure contains the participant digital certificate sequence information, and the server locates the participant digital certificate path clearly. The session identifier is still returned with the participation proof as a session boundary marker. The participation proof can be reproduced and verified on the server side, the candidate set screening has consistent input basis, the subsequent certificate role constraint agrees with the echo chain anti-replay level, and the participation proof source is stable and repeatable.

[0047] Before the multi-party co-signature enters the calculation stage, the server needs to confirm that the participation proof comes from a real participant, that the participation proof binds the correct to-be-signed digest and pre-challenge code, and that the participation proof in the historical session is not reused to promote a new session. The session table record provides the authoritative source of the to-be-signed digest and the pre-challenge code, and the participation proof provides the participant digital certificate sequence information and the signature value. After cross-rechecking of the two on the server side, a trusted judgment and challenge generation can be made. However, relying only on the signature verification result cannot identify the misplacement of certificate usage and the session replay track. Step S3 models the certificate constraint direction and the session binding direction side by side, and gives the co-session trust level through a complementary gate decision maker and directly falls into the disposal action.

[0048] S301 participation proof validity verification.

[0049] The signature authenticity and the session binding consistency need to be met at the same time before the participation proof enters the candidate set, otherwise the candidate set will mix cross-session materials or fake materials, and the collaborative strategy screening will lose the trusted input. After the server receives the session identifier and the participation proof, the server queries the session table with the session identifier, reads the to-be-signed digest and the pre-challenge code saved in the session table, and then locuses the participant digital certificate from the participation proof. The participation proof carries the participation proof to-be-signed digest and the signature value, the server reproduces the participation proof to-be-signed string in a fixed order according to the participation proof to-be-signed string, and writes the to-be-signed digest, the session identifier, the pre-challenge code, and the participant digital certificate sequence information in the order. The reproduction process adopts a deterministic encoding rule, which is composed of a field category identifier, a field length information, and a field content body. The field category identifier is a pre-agreed fixed byte sequence, the field length information is a byte length representation of the field content body, and the field content body is the encoding result of the to-be-signed digest, the session identifier, the pre-challenge code, and the participant digital certificate sequence information. The field category identifier and the field length information are used to eliminate ambiguity in splicing.

[0050] The server executes a fixed hash algorithm on the reproduced participation proof to-be-signed string to obtain a reproduced participation proof to-be-signed digest, and performs consistency comparison between the reproduced participation proof to-be-signed digest and the participation proof to-be-signed digest carried by the participation proof. After the consistency comparison is established, the signature value is verified using the participant digital certificate public key, and the verification input is the reproduced participation proof to-be-signed digest. The participation proof that passes the verification and has consistent reproduced participation proof to-be-signed digest is written into the candidate set. The candidate set at least saves the participant digital certificate sequence information and the reproduced participation proof to-be-signed digest, and the candidate set is written into the session evidence area with the session identifier as the index. The source of the participation proof and the session binding relationship have a reviewable text at the server end.

[0051] S302 Certificate role constraint fits the level of calculation.

[0052] The collaborative strategy usually requires different participants to assume different roles, and the role difference is often reflected through the policy identifier and the purpose field of the participant digital certificate. Ignoring the certificate role constraint will lead to that the participation proof passes the verification but the role does not meet the requirement, and the signature result will have unclear responsibility boundary on the business side.

[0053] The server reads the participant digital certificate from the candidate set, extracts the certificate policy identifier set, the key purpose set, the extension purpose set, the issuer identifier, and the subject identifier. The server performs deterministic sorting and uniform encoding on the multi-value field, and then splices the role constraint fragment string in a fixed field order to obtain a role constraint digest.

[0054] The server reads the role template fragment string corresponding to the collaboration policy. The role template fragment string provides required values ​​and allowed value ranges at the field granularity, which is consistent with the role constraint fragment string. The server aligns the role constraint fragment string and the role template fragment string field by field to generate a field alignment table. The field alignment table outputs missing flags, conflict flags, and duplicate flags. The missing flag indicates that the required field of the role template fragment string is missing in the participant's digital certificate. The conflict flag indicates that the field value of the participant's digital certificate falls within the prohibited range of the role template fragment string. The duplicate flag indicates that there are multiple conflicting role usage declarations in the participant's digital certificate.

[0055] The server maps certificate role constraint matching levels to level units based on the field alignment table. When a conflict marker appears, a failing level is output; when a critical field is missing or a duplicate marker appears, a low level is output; when a missing marker only appears in a non-critical field, a medium level is output; and when neither a missing nor a conflict marker appears, a high level is output. The field alignment table, role constraint summary, and certificate role constraint matching level are written into the session evidence area. Certificate usage mismatches and role conflicts are presented in a structured manner in the session evidence area, and the rejection reason can be directly located by referencing the marker set in the field alignment table.

[0056] Key fields refer to the certificate fields in the role template fragment string that are marked as required and directly constrain the eligibility to participate in the collaborative strategy. Key fields include the certificate policy identifier set, key usage set, extended usage set, issuer identifier, and subject identifier.

[0057] S303 Session Echo Chain Anti-Replay Level Calculation.

[0058] Common forms of replay risk include the overall reuse of the participation proof set and the reuse of pre-challenge code responses by a single participant in different sessions. Simple signature verification cannot identify historical reuse patterns. Echo chains need to convert candidate sets into stable fingerprints and compare them with historical echo libraries.

[0059] The server extracts the participant digital certificate sequence information and the digest of the reproducible participation proof to be signed from the candidate set, performs deterministic sorting according to the participant digital certificate sequence information, and writes the sorting results into the echo chain fragment string in sequence. When writing, each participant digital certificate sequence information and the corresponding digest of the reproducible participation proof to be signed adopts a deterministic encoding method of field category identifier, field length information, and field content ontology. After the echo chain fragment string is written, a fixed hash algorithm is executed to obtain the echo chain digest.

[0060] The server performs a query in the historical echo database. The historical echo database maintains an echo chain digest index and a certificate sequence pre-challenge index. The echo chain digest index is used to determine whether the same echo chain digest has appeared before, and the certificate sequence pre-challenge index is used to determine whether the same participant's digital certificate sequence information and the same pre-challenge code appear under different session identifiers.

[0061] The reuse trace flag is established when the historical echo library has the same echo chain digest record. The drift trace flag is established when the historical echo library has the same participant digital certificate sequence information and the same pre-challenge code but different session identifiers. The drift trace flag is determined by excluding the current session identifier record to avoid internal read-write interference in the session. The server maps the session echo chain anti-replay level to the level dimension according to the reuse trace flag and the drift trace flag. When both types of traces are established, the output is not passed. When only the reuse trace flag is established, the output is a low level. When only the drift trace flag is established, the output is a medium level. When neither type of trace is established, the output is a high level.

[0062] The echo chain digest, reuse trace flag, drift trace flag, and session echo chain anti-replay level are written to the session evidence area. The historical reuse clue and the session freshness are bound to the session evidence area to obtain a verifiable record.

[0063] S304 complementary gate decision and session handling action.

[0064] The certificate role constraint fit level reflects the trustworthiness of the identity role direction, and the session echo chain anti-replay level reflects the trustworthiness of the session binding direction. The two types of risk sources are different and do not replace each other. The complementary gate decision determines the two levels together to avoid a single indicator covering up the key risk.

[0065] The complementary gate decision reads the certificate role constraint fit level and the session echo chain anti-replay level, and outputs the cooperative session trust level according to the deterministic rule table. The rule table constraints are that the certificate role constraint fit level is in the not passed level or low level, the session echo chain anti-replay level is in the not passed level or low level, and the certificate role constraint fit level is higher than the low level. When the output is a reissued session, the certificate role constraint fit level and the session echo chain anti-replay level are both in the high level, and the output is a trusted pass. Other combinations output a strengthened challenge.

[0066] In the trusted pass and strengthened challenge scenarios, the server filters the selected set from the candidate set according to the cooperative strategy. The filtering conditions include role satisfaction relationship and threshold satisfaction relationship. The selected set is determined by the participant digital certificate sequence information and generates a proof digest. The proof digest is generated by writing each participant digital certificate sequence information and the corresponding repeated participant proof digest to be signed into a proof fragment string and performing a fixed hash algorithm. The server writes a signature challenge code usage flag when generating a signature challenge code. The signature challenge code usage flag is a pre-agreed fixed byte sequence, used to distinguish the usage category of the signature challenge code, session identifier, and pre-challenge code. The server concatenates the session identifier and the proof digest in a fixed order to obtain the signature challenge code by performing a fixed hash algorithm.

[0067] In the case of reinforcement challenge, the server writes a reinforcement signature challenge code usage marker when generating the reinforcement signature challenge code, which is different from the signature challenge code usage marker. The server concatenates the session identifier, proof digest, and echo chain digest in a fixed order and then performs a fixed hash algorithm to obtain the reinforcement signature challenge code.

[0068] In the case of retransmission session, the server marks the session identifier state in the session table as invalid, generates a new session identifier and pre-challenge code, and updates the session table record. The server reissues the session identifier and pre-challenge code.

[0069] In the case of rejection signing, the server outputs the rejection reason and seals the session evidence area, which contains at least the field alignment table, echo chain digest, multiplexing trace marker, drift trace marker, participant digital certificate sequence information set, and session trusted level and handling action with auditable track on the server side.

[0070] After step S3 is completed, the candidate set source passes the participation proof validity verification and is written into the session evidence area. The certificate role constraint level and the session echo chain anti-replay level are supported by the field alignment table and the historical echo library query result, respectively. The complementary gate decision outputs the trusted session level and falls into four types of handling actions: trusted pass, reinforcement challenge, retransmission session, and rejection signing. The trusted pass and reinforcement challenge simultaneously output the proof digest and signature challenge code or reinforcement signature challenge code, the retransmission session outputs a new session identifier and pre-challenge code, and the rejection signing outputs a sealed evidence record. The collaborative signature calculation entry obtains clear challenge input and reviewable evidence set.

[0071] After the multi-party collaborative signature enters the threshold calculation phase, although the selected collaborative participants have passed the collaborative session trusted level screening, there are still two types of engineering risks in signature share generation. One risk comes from inconsistent combined digests caused by inconsistent understanding of the input to be signed by different participants, and the other risk comes from misuse or mismatch of random number shares. The server needs to use the signature challenge code or reinforcement signature challenge code as the session constraint trigger, the proof digest as the collaborative process constraint trigger, and the to-be-signed digest as the signed content constraint trigger. However, only under the same deterministic encoding rule, the three can enter the calculation process, and the threshold signature calculation link can form a reviewable signature value and be verified by the signature digital certificate public key.

[0072] S401 combined digest generation and challenge code input determination.

[0073] The to-be-signed digest only reflects the semantics of the to-be-signed content, the proof digest reflects the participation proof set and collaborative strategy screening result, and the combined digest needs to compress the two types of constraints into a single fixed-length input to avoid boundary ambiguity caused by long field splicing by each participant in the threshold signature.

[0074] After the selected co-participant receives the proof digest and the signature challenge code or the reinforced signature challenge code, the selected co-participant first obtains the to-be-signed digest from the session table or the signing request context, then writes the to-be-signed digest and the proof digest into a combined digest to-be-signed string in a fixed order, and writes the combined digest to-be-signed string in a deterministic encoding rule of a field category identifier, field length information, and field content body. The field category identifier is used to distinguish the to-be-signed digest segment and the proof digest segment, the field length information is used to clearly define the field content boundary, and the field content body is the original byte sequence of the to-be-signed digest and the proof digest. After the combined digest to-be-signed string is written, a fixed hash algorithm is executed to obtain a combined digest, and the combined digest is kept in a fixed-length bit string form.

[0075] The signature challenge code and the reinforced signature challenge code are input as the challenge code. When the reinforced signature challenge code exists, the reinforced signature challenge code is taken; when the reinforced signature challenge code does not exist, the signature challenge code is taken. The challenge code input is consistent within the same session identifier. The random number share generated by the participant is more clearly bound to the session boundary, and the server is more easily positioned to find the source of the session mismatch when receiving the signature share.

[0076] S402 random number share derivation and curve point share generation.

[0077] The threshold signature random number share assumes the role of a one-time secret, and the reuse of the random number share may cause a key component leakage risk. The random number share needs to be bound to the combined digest and the session identifier at the same time and be constrained by the challenge code input. The selected co-participant reads the key component locally, first executes a fixed hash algorithm on the key component to obtain a key component digest, and the key component digest avoids the direct entry of the key component into the derivation splicing. The selected co-participant writes the key component digest, the session identifier, the challenge code input, and the combined digest into a derivation to-be-signed string in a fixed order, and writes the derivation to-be-signed string in a deterministic encoding rule of a field category identifier, field length information, and field content body. After the derivation to-be-signed string is completed, a fixed hash algorithm is executed to obtain a derivation seed. The selected co-participant generates a local random salt from a secure random source, the local random salt is only saved locally and is stored in association with the session identifier, and the derivation seed and the local random salt are again written into a derivation confirmation string in a deterministic encoding rule and a fixed hash algorithm is executed to obtain a random number share original value. The random number share original value needs to be mapped to the elliptic curve order range, and the mapping method is to take the remainder of the curve order after the random number share original value is interpreted as a non-negative integer. When the remainder is zero, derivation is performed again. The repeated derivation is completed by appending a fixed count mark to the derivation confirmation string. The count mark is also encoded by using the field category identifier and the field length information, until a non-zero random number share is obtained. The selected co-participant performs a scalar multiplication operation on the random number share using an elliptic curve base point to obtain a curve point share. The curve point share is used for the server to converge to form a signature first parameter input. The random number share is more difficult to be reused across sessions under the constraints of the session identifier and the challenge code input.

[0078] S403: Aggregation of curve points, generation of challenge value and calculation of response share.

[0079] The response share needs to share the same challenge value among all selected collaborative participants. The challenge value must be determined by the combined digest of the aggregation curve point signature digital certificate public key to avoid single manipulation of the challenge value leading to the signature share being directed to the unintended message. After receiving all curve point shares, the server performs elliptic curve point addition aggregation in the order of the selected set to obtain the aggregation curve point, which is used as the first parameter candidate value of the signature. The server reads the signature digital certificate public key from the signature digital certificate. The server writes the aggregation curve point, the signature digital certificate public key, and the combined digest into the challenge signing string in a fixed order and performs a fixed hash algorithm to obtain the challenge value. The challenge signing string is written in the same way, using the deterministic encoding rules of field category identification, field length information, and field content ontology, to ensure consistent recalculation by each participant.

[0080] The server sends the challenge value to the selected collaborative participants. The selected collaborative participants calculate the response share using the random number share and the key component in the curve order modulus domain. The calculation method is to add the random number share to the product of the challenge value and the key component and take the modulus of the curve order. The response share is returned to the server as the second parameter share of the signature. The response share binds the key component to the combined digest through the challenge value, forming a stable calculation association between the signature value and the proof digest.

[0081] S404: Consistency check of signature share and self-check of signature value aggregation.

[0082] The server needs to exclude session mismatch and curve point mismatch before aggregating the signature value to avoid exposing the error signature value after entering the signature package at the verification end. When the selected collaborative participants return the signature share, the signature share at least contains the session identifier, the curve point share identifier, and the response share. The curve point share identifier is the deterministic compressed encoding result of the curve point share. The server checks the session identifier in the signature share against the session identifier in the session table, and then checks whether the curve point share identifier can reconstruct the curve point share previously submitted by the participant. After passing the check, the response share is written into the aggregation set. The server performs curve order modulus addition on the aggregation set to obtain the aggregation response. The aggregation curve point and the aggregation response form the signature value. The server performs signature self-check using the elliptic curve public verification equation. In the verification process, the aggregation response is multiplied by the elliptic curve base point to obtain the left curve point. The aggregation curve point is multiplied by the signature digital certificate public key to obtain the curve point, which is added to the right curve point. When the left and right curve points are consistent, it is determined that the signature value self-check passes. If the self-check fails, the aggregation result is discarded, and the failure type and the participant digital certificate sequence information are recorded to avoid inconsistent signature values entering the signature package.

[0083] S405: Signature package generation and deterministic serialization packaging.

[0084] The signature package needs to be stably parsed and reproduced by the verifier, and the field order and field boundary are determined. If the field order and field boundary are not determined, the verification input may be deviated. The server writes the signature digital certificate, the participant digital certificate, the participant proof set, the proof digest, and the signature value in a fixed field order to form a signature package. The writing process adopts a deterministic encoding rule for field category identifier, field length information, and field content body. The field category identifier set is fixed and does not repeat. The field length information adopts a unified byte sequence. The signature value is written together with the aggregation response after performing fixed compression encoding on the aggregation curve point, so as to avoid the parsing difference of the first parameter of the signature caused by different encoding methods.

[0085] After the signature package is written, the server performs a fixed hash algorithm on the signature package to obtain a signature package fingerprint and writes it into the session evidence area. When the signature package is truncated or the fields are misaligned in the transmission link, the fingerprint can be compared to quickly locate the position.

[0086] After step S4 is completed, the combined digest binds the to-be-signed digest and the proof digest, and the random number share binds the challenge code input and the combined digest. The curve point share and the response share have the same challenge value constraint. The server controls the quality of the signature value through the consistency of the session identifier and the signature self-check. The signature package ensures the parsing consistency through deterministic serialization. The verifier can directly enter the signature value verification and the participant proof verification stage. The collaborative signature process maintains the reviewable and locatable at the data structure level.

[0087] After the threshold calculation is completed, the multi-party collaborative signature forms a signature package. The signature package has encapsulated the proof digest and the signature value, and carries the participant proof set. The verification link cannot only verify the signature value. The signature value verification can only prove that the signature private key corresponding to the signature digital certificate public key has generated a signature for a certain combined digest. It cannot prove that the participant proof set has not been replaced, and it cannot prove that the collaborative strategy role constraint is satisfied. The verification link needs to convert the to-be-signed content into a to-be-signed digest, convert the proof digest into a combined digest, and then review the participant proofs one by one. However, the verification link also needs to split the failure reason into four categories of structure, certificate, signature, and session binding strategy, so that the server side historical echo library writing has an interpretable source.

[0088] S501 signature package parsing and structure boundary checking.

[0089] The signature package has the risk of field misplacement, truncation, and rearrangement when transmitted across the link. Direct entry into cryptographic signature verification may misjudge structural errors as signature failure. The verifier parses the signature package in fixed field order, and the parsed output includes the signature digital certificate, participant digital certificate, participant proof set, proof digest, session identifier, pre-challenge code, and signature value. The field category identifier is checked field by field, which must be consistent with the pre-agreed set and must not be repeated. The field length information is checked field by field, which must be consistent with the field content byte number. There must be no boundary residue when the field content body is read to the end.

[0090] The verifier performs certificate chain verification and status verification on the signature digital certificate. The certificate chain verification covers the integrity of the issuance link and the validity period coverage. The status verification covers the revocation status query and the frozen state query. The same verification is performed on the participant digital certificate one by one. When the certificate verification fails, the certificate failure type is immediately formed and the participant digital certificate sequence information set is recorded. After the structure boundary check is completed, each evidence field in the signature package has a stable parsing boundary, and failure positioning is no longer dependent on transmission details.

[0091] S502 Recomputes the to-be-signed digest and the combined digest.

[0092] The combined digest must bind the to-be-signed content semantics and the proof digest in the same input to avoid transplanting the signature value from one proof digest to another. The verifier reads the to-be-signed content and generates normalized to-be-signed content according to the consistent normalization rules in step S1. The normalization rules include character encoding unification, line unification, space compression, and fixed field order. The fixed field order is arranged in lexicographic order of field key names and additional fixed position serial numbers are attached to repeated key names.

[0093] The normalized to-be-signed content is subjected to a fixed hash algorithm to obtain a to-be-signed digest. The proof digest is read from the signature package, and the to-be-signed digest and the proof digest are written into the combined digest to-be-signed string in fixed order. The combined digest to-be-signed string is written using a deterministic encoding method, which consists of field category identifier, field length information, and field content body. The field category identifier is used to distinguish the to-be-signed digest segment and the proof digest segment, and the field length information is used to clearly define the field content body boundary. The combined digest to-be-signed string is subjected to a fixed hash algorithm to obtain a combined digest. The combined digest binds the to-be-signed content and the participant proof set fingerprint into a single input, and the signature value verification input has a repeatable calculation result on the verifier side.

[0094] S503 Signature value verification and signature input consistency determination.

[0095] The signature value verification needs to bind the signature value internal curve point information, the signature digital certificate public key and the combined digest at the same time, to avoid the reuse of the signature value between different combined digests. The verifier parses the signature value from the signature package, and the signature value includes the aggregation curve point and the aggregation response. The signature digital certificate public key is extracted from the signature digital certificate. The aggregation curve point, the signature digital certificate public key and the combined digest are written into the challenge to be signed string in a fixed order. The challenge to be signed string is written by using a deterministic encoding method consistent with the combined digest. The challenge value is obtained by executing a fixed hash algorithm on the challenge to be signed string.

[0096] The public verification equation check is performed in the elliptic curve group. The aggregation response is multiplied by the elliptic curve base point to obtain the left curve point. The challenge value is multiplied by the signature digital certificate public key to obtain the challenge public key curve point. The aggregation curve point and the challenge public key curve point are added to obtain the right curve point. When the left curve point is consistent with the right curve point, it is determined that the signature value passes. The passing of the signature value means that the signature digital certificate public key and the combined digest have a determined cryptographic correspondence, and the proof digest is substantially written into the verification link. The signature value no longer exists independently of the proof digest.

[0097] S504 participates in the proof review and the proof digest recalculation.

[0098] The participant proof set assumes the identity of the collaborative participant and the session binding evidence. The participant proof review needs to include the session identifier and the pre-challenge code in the recalculation, otherwise the session binding consistency cannot be verified. The verifier reads the session identifier and the pre-challenge code from the signature package, and parses the participant proof one by one. The participant proof at least includes the participant digital certificate sequence information, the participant proof to be signed digest and the signature value. The participant digital certificate sequence information is used to locate the participant digital certificate and extract the participant digital certificate public key. The to-be-signed digest, the session identifier, the pre-challenge code and the participant digital certificate sequence information are written into the participant proof to be signed string in a fixed order. The writing method follows the deterministic encoding method of the field category identifier, the field length information and the field content body. The participant proof to be signed string is executed by a fixed hash algorithm to obtain the recurred participant proof to be signed digest. The recurred participant proof to be signed digest is compared with the participant proof to be signed digest carried by the participant proof. After consistency, the participant proof signature value is verified by using the participant digital certificate public key. The verification input is fixed as the recurred participant proof to be signed digest.

[0099] The passed participation proof is written into the effective set, and the elements of the effective set simultaneously retain the participant digital certificate sequence information and the reproduced participation proof to be signed digest. The effective set is subjected to deterministic sorting according to the participant digital certificate sequence information, and after sorting, each participant digital certificate sequence information and the corresponding reproduced participation proof to be signed digest are written into the proof fragment string. The proof fragment string is written in a deterministic encoding manner, and a fixed hash algorithm is performed on the proof fragment string to obtain a reproduced proof digest. When the reproduced proof digest is consistent with the proof digest in the signature package, it is determined that the participation proof set has not been replaced, and the proof digest truly plays a set fingerprint role.

[0100] S505 cooperates with the strategy consistency check and failure feedback sedimentation.

[0101] The cooperative strategy consistency check needs to drop the role template fragment string into the participant digital certificate field to avoid the role satisfaction relationship remaining at the abstract level. The failure feedback needs to return the locatable clues to the server to avoid the server side only getting the failure conclusion. The verifier reads the role template fragment string, extracts the certificate policy identifier set, key purpose set, extension purpose set, issuer identifier, and subject identifier from the corresponding participant digital certificate of the effective set field by field, performs deterministic sorting on the multi-value field and executes unified encoding, generates a role constraint fragment string, aligns the role constraint fragment string with the role template fragment string field by field to generate a field alignment table, and outputs missing markers, conflict markers, and duplicate markers. When the field alignment table does not exist conflict markers and the key field is not missing and the duplicate marker is not true, it is determined that the cooperative strategy consistency passes.

[0102] When any checkpoint fails, the failure type and the participant digital certificate sequence information set are output. The failure type uses a fixed enumeration set to distinguish structure failure, certificate failure, signature value failure, participation proof failure, proof digest failure, and cooperative strategy failure. The output also carries a signature package fingerprint, which is obtained by the verifier performing a fixed hash algorithm on the deterministic serialized byte stream of the signature package. After the server receives the failure information, the participant digital certificate sequence information set and the pre-challenge code are written into the certificate sequence pre-challenge index of the historical echo library, the reproduced participation proof to be signed digest set and the participant digital certificate sequence information set are written into the echo chain fragment string according to the deterministic sorting and the echo chain digest is calculated, the echo chain digest is written into the echo chain digest index of the historical echo library, the conflict fragments in the field alignment table are written into the rejection fragment set of the role template fragment string, and the failure type and the evidence field form a direct correspondence relationship. The reuse trace and the drift trace have stable input in the subsequent session determination.

[0103] After the signature package verification phase is completed, the signature value is verified to ensure that the signature digital certificate public key is consistent with the combined digest, the proof calculation and verification are ensured to be consistent with the bound digest, session identifier, and pre-challenge code, the proof digest calculation ensures that the participant proof set is not replaced, the collaborative strategy consistency check ensures that the role usage constraint is met, the failure feedback returns the failure type and participant digital certificate sequence information set to the server and deposits it into the historical echo library and rejection fragment set, the verification result has explainability and traceability, and the collaborative session evidence chain forms a consistent closed record on the verification side and the server side.

[0104] In particular, the above is only a preferred embodiment of the present application and is not used to limit the present application.

[0105] In the description of the present specification, the description referring to the terms "one embodiment", "an example", "a specific example", and the like means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0106] The preferred embodiments of the application disclosed above are only used to help explain the present application. The preferred embodiments do not describe all the details and limit the present application to only the specific embodiments. Obviously, many modifications and changes can be made according to the content of the present specification. The present specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present application, so that those skilled in the art can well understand and utilize the present application. The present application is limited only by the claims and their full scope and equivalents.

Claims

1. A method for implementing secure electronic signatures using digital certificate authentication under a multi-party collaborative computing mechanism, characterized in that, Including the following steps: S1: Receive the signing request, extract the content to be signed to generate a summary to be signed, read the digital certificate of signature, generate a session identifier based on the summary to be signed, generate a pre-challenge code based on the session identifier, and send the pre-challenge code to the collaborating participants; S2: The collaborating participants receive the pre-challenge code, use the signing private key corresponding to the participant's digital certificate to perform a signature on the unsigned digest, session identifier, and pre-challenge code, generate a participation certificate, and send back the participation certificate and session identifier; S3: The server receives the participation proof and completes the validity verification. Based on the certificate constraint information and session binding information, it makes a trust determination, selects the participation proof summary according to the determination result, and generates a proof digest. S4: Selected collaborating participants receive the signature challenge code and proof digest, use the local key component to calculate the signature share using the combined digest of the challenge digest and proof digest, return the signature share and session identifier, and the server aggregates the signature shares to generate the signature value and generate the signature packet. S5: The verifier performs verification on the signature packet, using the signature digital certificate to verify the signature value; verifies that the signature input used to generate the signature value at least contains a digest to be signed and a proof digest; verifies the signature of each participating proof one by one, and verifies that each participating proof is bound to the digest to be signed and the session identifier; verifies that the set of participating proofs meets the coordination policy; if the verification fails, it outputs the failure type and the participating party's digital certificate sequence information; after receiving the failure information, the server writes it into the historical echo library and updates the set of rejected fragments in the role template fragment string.

2. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 1, characterized in that, Step S1 includes the following: Upon receiving a signing request, the system extracts the original text of the content to be signed and performs normalization processing, outputting the normalized content to be signed; then, it performs a fixed hash operation on the normalized content to be signed to generate a digest of the content to be signed.

3. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 2, characterized in that, Step S1 also includes the following: Read the signed digital certificate and complete the certificate chain verification and certificate status verification, extract the signed digital certificate sequence information; generate a session random number, concatenate the digest to be signed and the session random number with the length prefix and write it into the purpose marker one to obtain the session identifier, concatenate the session identifier and the session random number with the length prefix and write it into the purpose marker two, and then perform a fixed hash operation to obtain the pre-challenge code; write it into the session table and issue the session identifier and pre-challenge code.

4. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 3, characterized in that, Step S2 includes the following: After receiving the session identifier and pre-challenge code, the collaborating participants read the participant's digital certificate and corresponding signature private key, complete the validity period verification and purpose verification, and extract the participant's digital certificate sequence information; Collaborating parties read the content to be signed and perform normalization processing to obtain normalized content to be signed. They then perform a fixed hash algorithm on the normalized content to be signed to generate a digest of the content to be signed.

5. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 4, characterized in that, Step S2 also includes the following: Collaborating participants write the pending signature digest, session identifier, pre-challenge code, and participant digital certificate sequence information in a fixed order to form a participation proof pending signature string. Each segment of the participation proof pending signature string contains a field category identifier, field length information, and field content. A fixed hash algorithm is executed on the participation proof pending signature string to obtain the participation proof pending signature digest. The signing private key is used to perform a signing operation on the participation proof pending signature digest to obtain a signature value. The participation proof is then encapsulated in a fixed field order and returned along with the session identifier.

6. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 5, characterized in that, Step S3 includes the following: After receiving the session identifier and participation proof, the server reads the session table to obtain the digest to be signed and the pre-challenge code. It extracts the participant's digital certificate sequence information from the participation proof and locates the participant's digital certificate. It reconstructs the participation proof to be signed string according to the digest to be signed, session identifier, pre-challenge code, and participant's digital certificate sequence information, and calculates the reconstructed participation proof to be signed digest. It verifies that the reconstructed participation proof to be signed digest is consistent with the participation proof to be signed digest. It verifies the signature value using the participant's digital certificate public key. The participation proof that passes the verification is written into the candidate set and recorded in the session evidence area.

7. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 6, characterized in that, Step S3 also Includes the following: The server parses the candidate set corresponding to the participant's digital certificate to generate a field alignment table and maps the certificate role constraint matching level. It sorts the candidate set according to the participant's digital certificate sequence information, generates an echo chain digest, and queries the historical echo library to obtain the multiplexing trace marker and drift trace marker. Then, it maps the session echo chain anti-replay level. The complementary gate decision device outputs the collaborative session trust level based on the certificate role constraint matching level and the session echo chain anti-replay level and executes session handling actions. In both trust pass and enhanced challenge scenarios, it generates a proof digest and issues a signature challenge code or an enhanced signature challenge code.

8. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 7, characterized in that, Step S4 includes the following: After receiving the proof digest and the signature challenge code or the enhanced signature challenge code, the selected collaborative participants write the digest to be signed and the proof digest into the combined digest to be signed string in a fixed order according to deterministic encoding, and calculate the combined digest. They then select the signature challenge code or the enhanced signature challenge code as the challenge code input. Based on the key component digest, session identifier, challenge code input, and combined digest, and combined with the local random salt, the selected collaborative participants derive random number shares and complete zero value exclusion. They then use the elliptic curve base point to perform a scalar multiplication on the random number shares to generate curve point shares and return them.

9. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 8, characterized in that, Step S4 also includes the following: The server gathers the curve points according to the order of the selected set, and writes the curve points, the signature digital certificate public key, and the combined digest into the challenge string in a fixed order. It calculates the challenge value and sends it out. The selected collaborative participants calculate the response share based on the challenge value, the random number share key component, and send it back. After the server verifies the consistency of the session identifier and the curve point share identifier, it generates an aggregation response share, forms a signature value, and performs a public verification equation self-check. If the self-check passes, it deterministically serializes the signature packet according to a fixed field order.

10. The method for implementing secure electronic signatures with digital certificate authentication under a multi-party collaborative computing mechanism according to claim 9, characterized in that, Step S5 includes the following: The verifier parses the signature packet to obtain the signature digital certificate, participant digital certificates, participation proof set, proof digest, session identifier, pre-challenge code, and signature value. It verifies the field category identifier and field length information in a fixed field order and completes certificate chain verification and status verification. It normalizes the content to be signed and calculates the digest to be signed, recalculates the combined digest, and verifies the signature value using the public key of the signature digital certificate. It recalculates the participation proof digest to be signed based on the digest to be signed, session identifier, pre-challenge code, and participant digital certificate sequence information, verifies the participation proof, recalculates the proof digest, performs consistency verification of the collaborative strategy, outputs the failure type and participant digital certificate sequence information set, and writes it to the historical echo library.

Images