A time-stamp based electronic signature long validity verification method

Abstract

This invention provides a time-stamp-based method for verifying the long-term validity of electronic signatures, comprising: receiving a target file signing request; calculating a target file digest; having an edge computing node collect trusted execution environment measurement values, device security status, user authentication path, network access path digest, signature call time sequence, and signature sequence position via an IoT encrypted channel to generate signature behavior fingerprint data and signature behavior fingerprint records; calling a signing private key to generate an electronic signature value; and binding the electronic signature value, target file digest, signing certificate information, signing business session identifier, signature behavior fingerprint data, and signature behavior fingerprint records to generate a signature occurrence evidence digest; submitting the signature occurrence evidence digest to a trusted timestamp service; and combining the trusted timestamp token, certificate status response information, and business session link information to generate a long-term validity evidence package.

Description

Technical Field

[0001] This invention relates to the field of electronic signature and data security technology, and in particular to a method for verifying the long-term validity of electronic signatures based on timestamps. Background Technology

[0002] Electronic signatures are widely used in scenarios such as electronic contracts, government approvals, and internal enterprise process approvals. Electronic signatures typically require the combination of target document digest, electronic signature value, signing certificate information, trusted timestamp token, and certificate status response information to verify document integrity, signing identity, and signing time.

[0003] Existing methods for verifying the long-term validity of electronic signatures focus on cryptographic verification and timestamp checks. These methods determine whether the file digests are consistent, whether the electronic signature value can be verified by the certificate's public key, whether the trusted timestamp token covers the corresponding digest, and whether the signing certificate is in a verifiable state within a specific time frame. These methods can solve the problems of ordinary file tampering and certificate status tracing. However, when the signing private key is subsequently leaked, the signing terminal environment is replaced, historical business logs are supplemented, or the signing call order is rearranged, it is difficult to distinguish between a genuine electronic signature generated in the original trusted signing environment and a verifiable electronic signature created after the private key is leaked.

[0004] Specifically, after obtaining the signing private key or accessing historical evidence, attackers may regenerate the electronic signature value or concatenate the newly generated electronic signature value with existing certificate status response information, business logs, or other evidence to superficially satisfy cryptographic verification conditions. However, existing technologies lack binding records of the trusted execution environment, device security status, user authentication path, network access path, signature call time sequence, and signature sequence position at the time of the signature. They also lack a mechanism for continuously comparing the aforementioned signature behavior fingerprint data with business session link information during long-term verification.

[0005] Therefore, this invention proposes a method for verifying the long-term validity of electronic signatures based on timestamps. The information disclosed in the background section is only for enhancing understanding of the background of this disclosure and may therefore contain prior art information that is not common knowledge to those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a long-term validity verification method for electronic signatures based on timestamps, thereby resolving the technical problems mentioned in the background section.

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

[0008] A method for verifying the long-term validity of electronic signatures based on timestamps includes the following steps:

[0009] S1. Receive the target file signing request, read the signing certificate information, signing terminal identifier and signing business session identifier generation parameters, calculate the target file digest, and have the edge computing node collect the signing environment data through the IoT encrypted channel to generate signature behavior fingerprint data and signature behavior fingerprint record;

[0010] S2. Verify the signing private key call conditions based on the pre-signing record and signature behavior fingerprint data. After the verification is passed, sign the target file digest to generate an electronic signature value. Bind the electronic signature value, target file digest, signing certificate information, signature behavior fingerprint data and signature behavior fingerprint record to generate a signature occurrence evidence digest.

[0011] S3. Submit a signature occurrence evidence digest to the trusted timestamp service, receive and verify the trusted timestamp token, obtain certificate status response information and business session link information, and generate a long-term validity evidence package.

[0012] S4. Read the file to be verified, the electronic signature value, and the long-term validity evidence package; recalculate the digest of the file to be verified and the anti-tampering verification value; jointly verify the electronic signature value, the trusted timestamp token, the certificate status response information, and the binding digest; and generate a cryptographic validity verification result.

[0013] S5. When the cryptographic validity verification result passes, reconstruct the signature behavior sideprint data, perform a signature behavior sideprint continuity comparison, and output the long-term validity verification result of the electronic signature.

[0014] S1 specifically includes: receiving a target file signing request, reading the target file, signing business session identifier generation parameters, signing certificate information, and signing terminal identifier; calculating the target file digest from the binary data of the target file to generate a pre-signing record; based on the pre-signing record, the edge computing node generates a collection batch number and a random challenge value, and collects trusted execution environment measurement values, device security status, user authentication path, network access path digest, signature call time sequence, and signature sequence position through an IoT encrypted channel to form signing environment collection data; and performing field normalization and sequence binding on the pre-signing record and signing environment collection data to generate signature behavior fingerprint data and signature behavior fingerprint record.

[0015] S2 specifically includes: reading the target file digest, signing certificate information, signing business session identifier, and signing terminal identifier based on the pre-signing record; verifying the correspondence between the certificate, session, terminal, and private key based on the signature behavior fingerprint data; and generating an electronic signature value by calling the signing private key after the verification is passed; reading the electronic signature value, target file digest, signing certificate information, signing business session identifier, signature behavior fingerprint data, signature behavior fingerprint record, signing terminal identifier, and edge computing node collection batch number; generating a signature occurrence evidence unit and binding digest after standardized encoding; performing field integrity, field consistency, and binding digest recalculation verification on the signature occurrence evidence unit; generating a signature occurrence evidence digest after the verification is passed; and synchronously recording the current system time as the evidence unit construction time.

[0016] S3 specifically includes: reading the signature occurrence evidence digest, the signing business session identifier, the collection batch number, and the evidence unit construction time; generating timestamp request data; submitting the trusted timestamp service via the IoT encrypted channel; receiving and verifying the trusted timestamp token; obtaining certificate status response information based on the signing certificate information and the trusted timestamp token; reading the business session link information according to the signing business session identifier; verifying the certificate status response time window and link continuity; and encapsulating the trusted timestamp token, timestamp authority certificate information, signature occurrence evidence unit, binding digest, signature occurrence evidence digest, certificate status response information, and business session link information into a long-term validity evidence package, generating an anti-tampering verification value.

[0017] S4 specifically includes: receiving the document to be verified, the electronic signature value, and the long-term validity evidence package; parsing the signature occurrence evidence unit, binding digest, signature occurrence evidence digest, trusted timestamp token, certificate status response information, business session link information, and timestamp authority certificate information according to the evidence package identifier, encapsulation version number, and anti-tampering verification value to generate a set of evidence to be verified; calculating the document digest to be verified from the binary data of the document to be verified, comparing it with the target document digest, and verifying the electronic signature value using the certificate public key in the signing certificate information to form a set of cryptographic verification materials; and jointly verifying the integrity of the trusted timestamp token, certificate status response information, binding digest, and evidence package to generate a cryptographic validity verification result.

[0018] S5 specifically includes: when the cryptographic validity verification result passes, reading the signature occurrence evidence unit, signature behavior fingerprint data, and signature behavior fingerprint record from the long-term validity evidence package, reconstructing the signature behavior fingerprint data according to the field order consistent with the generation stage, and comparing it with the original signature behavior fingerprint data; performing a continuous comparison between the reconstructed signature behavior fingerprint data and the business session link information, at least verifying the trusted execution environment, user authentication path, signature call time sequence, network access path, signature sequence position, and business event chain; and outputting the long-term validity verification result of the electronic signature and the corresponding break type based on the cryptographic validity verification result and the continuous comparison result of the signature behavior fingerprint.

[0019] The beneficial effects of this invention are as follows:

[0020] Before generating the electronic signature value, this invention collects trusted execution environment measurements, device security status, user authentication path, network access path digest, signature call time sequence, and signature sequence position through edge computing nodes. This generates signature behavior fingerprint data, ensuring the electronic signature value corresponds not only to the target file digest but also to the actual signing environment, improving the traceability of the signing source. The electronic signature value, target file digest, signing certificate information, signing business session identifier, signature behavior fingerprint data, and signature behavior fingerprint record are inseparably bound to generate a signature occurrence evidence digest. This prevents the electronic signature value from being reused independently outside the original signing business session, reducing the risk of a forged signature being mistakenly judged as long-term valid after a private key leak.

[0021] This invention submits a signature occurrence evidence digest to a trusted timestamp service and encapsulates a long-term validity evidence package by combining certificate status response information, business session link information, and timestamp authority certificate information. This expands the object of trusted timestamp proof from a single signature value to the complete fact of signature occurrence, improving the integrity and tamper resistance of long-term archived evidence. During long-term verification, the long-term validity evidence package, the digest of the document to be verified, the electronic signature value, the trusted timestamp token, the certificate status response information, and the binding digest are jointly verified to generate a cryptographic validity verification result. This avoids relying solely on a single verification result to determine the long-term validity of the electronic signature, thus improving accuracy.

[0022] After cryptographic validity verification, this invention further reconstructs signature behavior fingerprint data and compares it with business session link information for continuity. This enables the identification of anomalies such as inconsistent trusted execution environments, unverifiable user authentication paths, broken signature call sequences, and inconsistent network access paths, thus enabling the detection of risky signatures generated in verifiable but not original trusted signing environments. The long-term validity verification result of the electronic signature is generated jointly by the cryptographic validity verification result and the signature behavior fingerprint continuity comparison result, forming a joint verification mechanism for document integrity, certificate status, time existence, and the continuity of signing behavior. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of a long-term validity verification method for electronic signatures based on timestamps according to the present invention. Detailed Implementation

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

[0025] Example: Figure 1 As shown in the figure, this embodiment provides a method for verifying the long-term validity of electronic signatures based on timestamps, including the following steps:

[0026] S1. Receive the target file signing request, read the signing certificate information, signing terminal identifier and signing business session identifier generation parameters, calculate the target file digest, and have the edge computing node collect the signing environment data through the IoT encrypted channel to generate signature behavior fingerprint data and signature behavior fingerprint record;

[0027] S2. Verify the signing private key call conditions based on the pre-signing record and signature behavior fingerprint data. After the verification is passed, sign the target file digest to generate an electronic signature value. Bind the electronic signature value, target file digest, signing certificate information, signature behavior fingerprint data and signature behavior fingerprint record to generate a signature occurrence evidence digest.

[0028] S3. Submit a signature occurrence evidence digest to the trusted timestamp service, receive and verify the trusted timestamp token, obtain certificate status response information and business session link information, and generate a long-term validity evidence package.

[0029] S4. Read the file to be verified, the electronic signature value, and the long-term validity evidence package; recalculate the digest of the file to be verified and the anti-tampering verification value; jointly verify the electronic signature value, the trusted timestamp token, the certificate status response information, and the binding digest; and generate a cryptographic validity verification result.

[0030] S5. When the cryptographic validity verification result passes, reconstruct the signature behavior sideprint data, perform a signature behavior sideprint continuity comparison, and output the long-term validity verification result of the electronic signature.

[0031] S1 specifically includes the following sub-steps:

[0032] S110. Receive an electronic signature request for a target file, read the target file, signature session identifier generation parameters, signature certificate information, and signature terminal identifier; wherein, the signature session identifier generation parameters include the signature request reception time, the signature user identifier, the signature terminal identifier, and a random number, and the signature certificate information includes the certificate serial number, the certificate subject identifier, the certificate issuing authority identifier, the certificate validity period, the certificate public key, and its public key digest.

[0033] After receiving an electronic signature request, the system performs format fixing on the target file, confirming the target file's binary data, file version number, and file state before signing, and does not use file names, page screenshots, or temporary cache files as digest objects. After format fixing, the system calls a preset digest algorithm to calculate the digest of the target file's binary data, generating the target file digest:

[0034]

[0035] in, This represents a summary of the target file. This indicates the preset digest algorithm, and F represents the binary data of the target file.

[0036] Subsequently, a signing service session identifier is generated based on the signing request reception time, signing user identifier, signing terminal identifier, and random number. Specifically, the signing request reception time, signing user identifier, signing terminal identifier, and random number are converted into a unified string format, and sequentially concatenated according to the preset field names in ascending order. A preset cryptographic hash algorithm (such as SHA-256 or SM3) is called to perform a hash operation on the concatenated string to generate a fixed-length hexadecimal string as the signing service session identifier, so as to ensure the global uniqueness and anti-counterfeiting of the session identifier in a distributed environment.

[0037] The target file summary, signing business session identifier, signing certificate information, signing terminal identifier, and target file version number are written into the pre-signing record.

[0038] The pre-signing record is used to define the target file, signing certificate, and business session corresponding to this electronic signature request. It serves as the basic input for subsequent collection of signing environment data, generation of signature behavior fingerprint data, and calling the signing private key to generate electronic signature values.

[0039] The above processing avoids mismatches in target file summary, signing certificate information, and signing session identifier when the same user signs consecutively in multiple business windows. For example, when a user signs three contract documents consecutively on the same terminal, each contract document corresponds to an independent signing session identifier and target file summary. Subsequent steps can only collect signing environment data based on the corresponding pre-signing records, and the signing terminal status of the previous contract document must not be used for the next contract document.

[0040] S120. Based on the pre-signing record, initiate the signing environment collection process in the edge computing node closest to the signing terminal. When initiating the signing environment collection process, the edge computing node generates an edge computing node collection batch number to identify the collection batch of the signing environment data; at the same time, it generates a random challenge value for the fingerprint data generation process of this signature behavior, and writes the random challenge value and the edge computing node collection batch number together into the subsequent signature behavior fingerprint record.

[0041] The edge computing node first establishes an IoT encrypted channel with the signing terminal. This channel verifies the device identities of both the edge computing node and the signing terminal through two-way authentication. Upon successful authentication, a session key is generated, and this key is used to encrypt and verify the integrity of the collected data to meet data security requirements. After the IoT encrypted channel is established, the edge computing node reads the trusted execution environment measurement values, device security status, user authentication path, network access path digest, signature invocation start time, signature invocation end time, and signature sequence position output by the signing terminal.

[0042] Trusted execution environment measurements include secure startup measurements, signature application integrity measurements, key invocation component measurements, and runtime environment status measurements; user authentication path includes authentication method, authentication pass time, and authentication component identifier; network access path summary is generated based on access node, link session, and transmission channel information between the signing terminal and the signing service; signature sequence position is used to indicate the order of this signature invocation within the same signing business session.

[0043] Edge computing nodes perform field integrity and time sequence checks on the collected data locally, and calculate the signature call time based on the start and end times of each signature call. The calculation results are then arranged according to the position in the signature sequence to form a signature call time sequence.

[0044]

[0045] in, This represents the time taken for the i-th signature call. Indicates the end time of the i-th signature call. This indicates the start time of the i-th signature call, where i represents the sequence number (index) of the current signature call in the sequence.

[0046] The edge computing node combines trusted execution environment measurements, device security status, user authentication path, signature call time sequence, network access path digest, signature sequence location, random challenge value, and edge computing node collection batch number into signing environment collection data, and associates the signing environment collection data with the signing business session identifier in the signing pre-record.

[0047] If trusted execution environment measurements are missing, the user authentication path does not match the signing user identifier, the signature call time sequence cannot be arranged according to the signature sequence position, or the IoT encrypted channel integrity verification fails, then the generation of signature behavior fingerprint data will stop and a collection anomaly marker will be output. By performing the above preprocessing at the edge computing node, incomplete or tampered environmental data can be promptly removed at the signing site, avoiding the need for the original collected data to be directly transmitted to the remote system for remedial verification.

[0048] In practical implementation, the signing terminal integrates a security chip that meets the TPM2.0 or TCM standard as a hardware root of trust. The edge computing node sends the random challenge value to the signing terminal through an IoT encrypted channel; the trusted execution environment (TEE) of the signing terminal responds to the random challenge value by calling the underlying security interface instruction (e.g., the TPM2_PCR_Read instruction) to read the security startup measurement value, signature application integrity measurement value, key invocation component measurement value, and runtime environment status measurement value from the current system platform configuration register (PCR);

[0049] Subsequently, the signing terminal uses its internally protected Endorsement Key (EK) or Identity Key to perform asymmetric encryption signature on the random challenge value and the various measurement values ​​read, encapsulates and generates a security status measurement report that conforms to the Remote Attestation protocol, and sends it to the edge computing node through the IoT encrypted channel.

[0050] After the edge computing node verifies the signature using the pre-stored public key of the signing terminal, it parses and extracts the trusted execution environment measurement value and device security status to ensure that the collected environmental fingerprint data is authentic, tamper-proof, and originates from trusted hardware.

[0051] S130. Read the pre-signing record and signing environment data, and perform field normalization processing on the target file digest, signing certificate information, signing business session identifier, trusted execution environment measurement value, device security status, user authentication path, signature call time sequence, network access path digest, signature sequence position and random challenge value to form a unified encoding format; field normalization processing includes fixed field name, field length marking, fixed field order and null value rejection processing.

[0052] After completing the field normalization process, the target file digest, signing certificate information, signing business session identifier, trusted execution environment measurement value, device security status, user authentication path, signature call time sequence, network access path digest, signature sequence position, and random challenge value are sequentially concatenated according to the preset field order. A digest calculation is then performed on the concatenated result to generate signature behavior fingerprint data.

[0053]

[0054] in, This indicates the signature behavior as fingerprint data. This represents a summary of the target file. This indicates the information to be signed as a certificate. Indicates the signature of the business session. This represents a measurement from a trusted execution environment. Indicates the equipment's safe status. Indicates the user authentication path. This indicates the sequence of time consumed by the signature call. Represents a network access path summary. This represents the data field value indicating the position of the recorded signature sequence; R represents the random challenge value. This indicates that the fields are concatenated in order.

[0055] After generating signature behavior fingerprint data, a correspondence is established between this data and the pre-signing record, the signing environment data, and the edge computing node batch number, forming a reproducible signature behavior fingerprint record. The signature behavior fingerprint record includes trusted execution environment measurements, device security status, user authentication path, signature call time sequence, network access path digest, signature sequence position, random challenge value, and edge computing node batch number. These elements characterize the target file, signing certificate, business session, terminal trusted execution environment, user authentication process, network access path, and signature call order at the time the electronic signature actually occurred, and serve as direct input for generating subsequent signature occurrence evidence units.

[0056] By binding the fields in a fixed order, it is possible to make the signature behavior fingerprint data inconsistent if any field is subsequently replaced, missing, or mismatched.

[0057] S2 specifically includes the following sub-steps:

[0058] S210. Read the target file digest, signing certificate information, signing business session identifier and signing terminal identifier according to the signing pre-record, and call the signature behavior sideprint data to perform signing private key call pre-verification.

[0059] The pre-verification of the signing private key includes: verifying whether the certificate serial number, certificate subject identifier, and certificate public key digest in the signing certificate information correspond to the private key identifier to be called; verifying whether the signing business session identifier is in a valid state and has not been occupied by other electronic signature requests; verifying whether the signature behavior fingerprint data has been generated by the edge computing node based on the signing pre-record and signing environment data, and has not been rewritten; and verifying whether the signing terminal identifier corresponds to the trusted execution environment measurement value.

[0060] After all the above verifications pass, the signing system allows the signing private key to perform a signing operation on the target file digest, generating an electronic signature value:

[0061]

[0062] in, Represents the electronic signature value. This indicates that the signing operation is performed using the signing private key. This indicates that the private key was signed. This represents a summary of the target file.

[0063] After generating the electronic signature value, the public key of the certificate in the signing certificate information is used to perform a preliminary verification of the electronic signature value to confirm that the electronic signature value corresponds to the target file digest and the signing certificate information, thus forming the basic data of the electronic signature. If the signing certificate information does not correspond to the signing private key identifier, the signing business session identifier has expired, the signature behavior fingerprint data is missing, or the electronic signature value fails the preliminary verification, the generation of the signature occurrence evidence unit is stopped, and a private key call anomaly flag is output.

[0064] This pre-verification can prevent the misuse of non-corresponding signing private keys when multiple certificates exist on the same signing terminal, and can also prevent the electronic signature value generated after the signing private key is subsequently leaked from the original signing business session and enter the long-term verification process.

[0065] S220: Read the basic data of electronic signature, the pre-signing record, the signature behavior fingerprint data and the signature behavior fingerprint record, and perform standardized encoding on the electronic signature value, target file digest, signing certificate information, signing business session identifier, signature behavior fingerprint data, signature behavior fingerprint record, signing terminal identifier, edge computing node collection batch number and field sequence index to generate a signature occurrence evidence unit.

[0066] Standardized encoding includes fixed field names, field length markers, field type markers, fixed field order, and null value rejection handling; the field order index is used to record the arrangement of each field within the signature evidence unit to prevent field swapping or splicing ambiguity during subsequent verification.

[0067] The signature evidence unit can be represented as:

[0068]

[0069] in, This indicates the unit of evidence that the signature occurred. Represents the electronic signature value. This represents a summary of the target file. This indicates the information to be signed as a certificate. Indicates the signature of the business session. This indicates the signature behavior as fingerprint data. This indicates a fingerprint record of the signature action. Indicates the signature terminal identifier, This indicates the batch number collected by the edge computing node. This indicates a field-order index.

[0070] After forming the signature occurrence evidence unit, the above fields are concatenated sequentially according to the field order index, and a preset digest algorithm is called to generate a binding digest:

[0071]

[0072] in, Indicates the binding summary, Indicates the preset digest algorithm, This indicates that the fields are concatenated in order.

[0073] The binding digest is written into the signature occurrence evidence unit to achieve an inseparable binding between the electronic signature value and the signature behavior fingerprint data and signature behavior fingerprint record. Through this process, the electronic signature value is no longer entered into long-term validity verification as a separate piece of data, but instead constitutes verifiable evidence together with the target document digest, the signing business session identifier, the signing terminal identifier, the signature behavior fingerprint data, and the signature behavior fingerprint record.

[0074] For example, even if an attacker can generate a new electronic signature value for another file digest after the signing private key is leaked, they cannot reuse the historical signature behavior fingerprint record to form a valid binding digest. This is because any change in any field of the electronic signature value, the target file digest, the signing business session identifier, or the signature behavior fingerprint record will lead to inconsistent binding digest recalculation results.

[0075] S230. Perform integrity verification and field consistency verification on the signature generation evidence unit. Integrity verification includes field integrity verification, field order index verification, edge computing node acquisition batch number verification, and binding digest recalculation verification; among which, binding digest recalculation verification is to recalculate the binding digest according to the fixed field order in S220, and compare the recalculated binding digest with the binding digest written into the signature generation evidence unit.

[0076] Field consistency verification includes: the target file digest is consistent with the target file digest in the pre-signing record; the signing certificate information is consistent with the verification public key of the electronic signature value; the signing business session identifier is consistent with the signing business session identifier in the signature behavior sideprint data; the signing terminal identifier corresponds to the measurement value of the trusted execution environment; and the edge computing node collection batch number corresponds to the collection data of the signing environment.

[0077] After the above verification is passed, a digest calculation is performed on both the signature occurrence evidence unit and the bound digest to generate the signature occurrence evidence digest:

[0078]

[0079] in, This indicates a summary of evidence that the signature occurred. This indicates the unit of evidence that the signature occurred. Indicates the binding summary, Indicates the preset digest algorithm, This indicates that the fields are concatenated in order. The current system time is recorded synchronously as the time the evidence unit is constructed.

[0080] The signature occurrence evidence digest serves as the sole submission object for subsequently applying for a trusted timestamp token from the trusted timestamp service via the IoT encrypted channel. If fields are missing, field order indexes are missing, edge computing node collection batch numbers are missing, binding digest recalculation results are inconsistent, or the signing certificate information does not match the electronic signature value, then no signature occurrence evidence digest will be generated, and an evidence unit construction anomaly flag will be output.

[0081] Through the above processing, the object of subsequent proof of the trusted timestamp is not only the electronic signature value itself, but also the binding relationship between the electronic signature value and the target file digest, signing certificate information, signing business session identifier, signing terminal identifier, signature behavior fingerprint data and signature behavior fingerprint record, thereby providing a stable, verifiable and data security-compliant evidentiary basis for the long-term valid evidence package.

[0082] S3 specifically includes the following sub-steps:

[0083] S310: Read the signature occurrence evidence digest, the signing business session identifier, the edge computing node collection batch number, and the evidence unit construction time; perform format verification and recalculation verification on the signature occurrence evidence digest; wherein, the format verification is used to confirm that the signature occurrence evidence digest conforms to the preset encoding rules, and the recalculation verification is used to confirm that the signature occurrence evidence digest is consistent with the signature occurrence evidence unit and the bound digest.

[0084] After successful verification, the system generates timestamp request data according to a fixed field order and submits it to the trusted timestamp service through an IoT encrypted channel. Before submission, the IoT encrypted channel completes identity authentication and session key negotiation between both parties, and encrypts and protects the integrity of the timestamp request data to meet data security requirements.

[0085] The request digest for timestamp request data is generated according to the following formula:

[0086]

[0087] in, This represents a request digest of the timestamp request data. This indicates a summary of evidence that the signature occurred. Indicates the signature of the business session. This indicates the batch number collected by the edge computing node. Indicates the time of evidence unit construction. Indicates the preset digest algorithm, This indicates that the fields are concatenated in order.

[0088] After the trusted timestamp service returns a trusted timestamp token, the system reads the token serial number, token generation time, token digest value, timestamp authority signature value, and timestamp authority certificate information from the trusted timestamp token, and performs signature verification, certificate chain verification, and digest consistency verification on the trusted timestamp token.

[0089] A trusted timestamp token is only associated with a signature occurrence evidence unit when the token digest value matches the signature occurrence evidence digest, the timestamp authority's signature value is verified, and the timestamp authority's certificate information is verifiable. If the digest value in the trusted timestamp token points to another signature occurrence evidence digest, even if the token format is correct, it cannot be used for the long-term validity evidence package of this electronic signature.

[0090] S320. Based on the signed certificate information and the trusted timestamp token, obtain the certificate status response information and read the business session link information corresponding to the signed business session identifier. The certificate status response information includes at least the signed certificate status response, the intermediate certificate status response in the certificate chain, the timestamp authority certificate status response, the response generation time, the response signature value, and the revocation reason field; wherein, the signed certificate status response is used to prove the status of the signed certificate near the time corresponding to the trusted timestamp token, and the timestamp authority certificate status response is used to prove that the issuing entity of the trusted timestamp token has a verifiable status.

[0091] The system uses the generation time of the trusted timestamp token as the time base to perform time window verification on the certificate status response information:

[0092]

[0093] in, Indicates the generation time of the trusted timestamp token. This indicates the time when the certificate status response information was generated. This indicates the allowed certificate status response time window.

[0094] If the certificate status response information fails to verify the signature, exceeds the allowed window time, or is missing the revocation reason field, the certificate status response information must not be written into the long-term validity evidence package. The business session link information uses the signing business session identifier as the primary key and records, in chronological order, the following records: signing request initiation record, user authentication pass record, signature behavior fingerprint data generation record, signing private key call record, electronic signature value generation record, signature occurrence evidence digest generation record, and signing completion record.

[0095] Each business event record includes the event type, event time, event summary, preceding event summary, and execution node identifier, and maintains continuity between adjacent business events through link summaries:

[0096]

[0097] in, This represents the summary of the j-th service session link. This represents the j-th business event record. Indicates the first Summary of each business session link This indicates the signature of the business session, and j represents the sequential number of the business event record.

[0098] Through the above processing, the business session link information can prove the sequential relationship between signature action fingerprint data generation, signing private key invocation, electronic signature value generation, and signing completion. For example, if only user authentication pass records and signing completion records are saved, but signing private key invocation records are missing, it cannot be ruled out that the electronic signature value was added after the signing private key was leaked; through the link digest, any insertion, deletion, or rearrangement of any business event will lead to inconsistencies in the subsequent business session link digests.

[0099] S330. Obtain the current system time as the encapsulation time and read the system's preset encapsulation version number; then read the trusted timestamp token, timestamp authority certificate information, signature occurrence evidence unit, binding digest, signature occurrence evidence digest, certificate status response information, and business session link information, and encapsulate them into a long-term valid evidence package according to the preset evidence package structure.

[0100] A long-term valid evidence package includes at least an evidence package identifier, a signature occurrence evidence unit, a binding digest, a signature occurrence evidence digest, a trusted timestamp token, certificate status response information, business session link information, timestamp authority certificate information, a packaging version number, and an anti-tampering verification value. The evidence package identifier is generated jointly by the signing business session identifier, the signature occurrence evidence digest, the trusted timestamp token serial number, and the packaging time, and is used to uniquely locate the evidence package corresponding to this electronic signature during long-term verification.

[0101] The system fixes the field order of key fields in the long-term validity evidence package and rejects null values, and generates tamper-proof verification values:

[0102]

[0103] in, This represents the tamper-proof verification value. Indicates the evidence package identifier, This indicates the unit of evidence that the signature occurred. Indicates the binding summary, This indicates a summary of evidence that the signature occurred. Indicates a trusted timestamp token. This indicates the certificate status response information. Indicates business session link information, This indicates the timestamp organization certificate information.

[0104] After generating the tamper-proof verification value, the system writes the tamper-proof verification value into the long-term validity evidence package and uses the long-term validity evidence package as the unified input for subsequent long-term validity verification. If the trusted timestamp token verification fails, the certificate status response information does not meet the time window requirements, the business session link information lacks signature behavior fingerprint data generation records or signing private key call records, or the tamper-proof verification value recalculation is inconsistent, then the long-term validity evidence package encapsulation fails, and an evidence package encapsulation anomaly flag is output.

[0105] Through this encapsulation method, the object of trusted timestamp proof is no longer an isolated electronic signature value, but a signature occurrence fact composed of the electronic signature value, signature behavior fingerprint data, signature behavior fingerprint record, certificate status response information, and business session link information. During subsequent verification, the system can complete the joint verification of file integrity, time existence, certificate status, and signing behavior continuity based on the same long-term validity evidence package.

[0106] S4 specifically includes the following sub-steps:

[0107] S410. During long-term validity verification, the system receives the document to be verified, the electronic signature value, and the long-term validity evidence package. The long-term validity evidence package undergoes pre-parsing verification. The system reads the evidence package identifier, encapsulation version number, and anti-tampering verification value from the long-term validity evidence package, confirming that the encapsulation version number is consistent with the evidence package structure supported by the current verification program. Subsequently, following the fixed field order determined in S330, the system extracts the signature occurrence evidence unit, binding digest, signature occurrence evidence digest, trusted timestamp token, certificate status response information, business session link information, and timestamp authority certificate information, and recalculates the anti-tampering verification value.

[0108]

[0109] in, This represents the tamper-proof verification value obtained through recalculation. Indicates the evidence package identifier, This indicates the unit of evidence that the signature occurred. Indicates the binding summary, This indicates a summary of evidence that the signature occurred. Indicates a trusted timestamp token. This indicates the certificate status response information. Indicates business session link information, Indicates timestamp organization certificate information, Indicates the preset digest algorithm, This indicates that the fields are concatenated in order.

[0110] The recalculated anti-tampering verification value is compared with the anti-tampering verification value recorded in the long-term validity evidence package. If they match, an evidence package integrity verification result is generated, and the signature occurrence evidence unit, binding digest, signature occurrence evidence digest, trusted timestamp token, certificate status response information, business session link information, and timestamp authority certificate information are combined into a set of evidence to be verified. If they do not match, or if the long-term validity evidence package is missing any of the evidence package identifier, signature occurrence evidence digest, trusted timestamp token, certificate status response information, or business session link information, subsequent electronic signature value verification is stopped, and an evidence package field missing or evidence package integrity verification failure result is output.

[0111] Through the above processing, the verification process does not directly trust the surface content of the long-term validity evidence package, but first confirms that the electronic signature value, trusted timestamp token, certificate status response information, business session link information and timestamp authority certificate information are still within the same anti-tampering verification scope.

[0112] S420. After the integrity verification of the evidence package passes, read the binary data of the file to be verified and recalculate the digest of the file to be verified using the same preset digest algorithm as S110, without using file name, page screenshot, compressed package shell, system cache file or converted file as digest object.

[0113] The digest of the file to be verified is generated according to the following formula:

[0114]

[0115] in, This represents the summary of the file to be verified. Indicates the preset digest algorithm, This represents the binary data of the file to be verified.

[0116] The system reads the target file digest from the signature generation evidence unit, compares the digest of the file to be verified with the target file digest, and generates a file digest consistency result. If they do not match, it means that the file to be verified is not the same data object as the target file that generated the target file digest during signing, outputs a file digest inconsistency result, and stops further validity checks on the trusted timestamp token and certificate status response information; if they match, the system reads the certificate public key from the signing certificate information and verifies the electronic signature value.

[0117]

[0118] in, This indicates the verification result of the electronic signature value. This indicates that the signature verification operation is performed using the public key of the signing certificate. This refers to the public key of the certificate in the signing certificate information. Represents the electronic signature value. This represents the summary of the file to be verified.

[0119] When the electronic signature value verification passes, the system will assemble a set of cryptographic verification materials, including the digest of the file to be verified, the digest of the target file, the electronic signature value, the signing certificate information, the digest of the evidence of the signature occurrence, the trusted timestamp token, the certificate status response information, and the binding digest. When the electronic signature value verification fails, the system will output a result indicating that the electronic signature value does not match.

[0120] This step ensures that the electronic signature value used for subsequent verification corresponds precisely to the digest of the document being verified, rather than using electronic signature values ​​from other documents. For example, when verifying a long-archived PDF contract, the digest should be recalculated from the archived PDF binary data. It cannot be calculated from a screenshot of the opened page or a converted OFD file, even if the displayed content is similar; it cannot replace the digest of the target document at the time of signing.

[0121] S430. Based on the cryptographic verification material set, jointly verify the correspondence between electronic signature value, signing certificate information, trusted timestamp token, certificate status response information, target file digest and binding digest.

[0122] The joint verification includes: verifying whether the digest of the file to be verified is consistent with the digest of the target file in the signature occurrence evidence unit; verifying whether the electronic signature value can be verified by the certificate public key in the signing certificate information; verifying whether the token digest value in the trusted timestamp token is consistent with the digest of the signature occurrence evidence; verifying whether the timestamp authority signature value of the trusted timestamp token can be verified by the timestamp authority certificate information; verifying whether the certificate status response information covers the signing certificate, intermediate certificates in the certificate chain, and timestamp authority certificates, and whether its response generation time meets the time window specified in S320; and verifying whether the binding digest can be recalculated by the signature occurrence evidence unit according to the fixed field order in S220.

[0123] The above verifications generate the following results: file digest consistency result, electronic signature value verification result, trusted timestamp token verification result, certificate status response information verification result, binding digest verification result, and evidence packet integrity verification result. Based on these results, a cryptographic validity verification result is generated.

[0124]

[0125] in, This indicates the result of the cryptographic validity verification. Indicates the consistency result of document digests. This indicates the verification result of the electronic signature value. This indicates the result of the trusted timestamp token verification. This indicates the certificate status response information verification result. This indicates the result of the binding summary verification. This indicates the result of the evidence package integrity verification. This indicates a logical AND operation.

[0126] When the cryptographic validity verification result is successful, the set of evidence to be verified and the cryptographic validity verification result are input into the subsequent signature behavior fingerprint continuity verification process; when any sub-item verification fails, the corresponding reason for failure is output, and the signature behavior fingerprint continuity verification process is not initiated. Through this process, S410-S430 verify not only whether the electronic signature value can be verified by the public key, but also whether the long-term validity evidence package, trusted timestamp token, signature occurrence evidence digest, certificate status response information, and binding digest all point to the same signing fact.

[0127] S5 specifically includes the following sub-steps:

[0128] S510. When the cryptographic validity verification result is passed, read the signature occurrence evidence unit, signature behavior fingerprint data, signature behavior fingerprint record, business session link information, signing certificate information, target file digest, signing business session identifier and random challenge value from the long-term validity evidence package, and verify the field name, field length, field type and field order of the trusted execution environment measurement value, device security status, user authentication path, signature call time sequence, network access path digest and signature sequence position in accordance with the field normalization rules determined in S130.

[0129] The system does not directly accept the signature behavior fingerprint data stored in the long-term validity evidence package. Instead, it uses the basic fields stored in the signature behavior fingerprint record as input and regenerates and reconstructs the signature behavior fingerprint data according to the same field order as in the generation stage.

[0130]

[0131] in, This indicates the reconstruction of signature behavior fingerprint data. This represents a summary of the target file. This indicates the information to be signed as a certificate. Indicates the signature of the business session. This represents a measurement from a trusted execution environment. Indicates the equipment's safe status. Indicates the user authentication path. This indicates the sequence of time consumed by the signature call. Represents a network access path summary. This represents the data field value indicating the position of the recorded signature sequence; R represents the random challenge value. Indicates the preset digest algorithm, This indicates that the fields are concatenated in order.

[0132] Subsequently, the reconstructed signature behavior fingerprint data is compared with the signature behavior fingerprint data stored in the long-term validity evidence package. If they match, a signature behavior fingerprint reconstruction success result is generated, and the trusted execution environment measurement value, device security status, user authentication path, signature call time sequence, network access path digest, signature sequence position, and business session link information are input into the subsequent continuous comparison process. If they do not match, the continuous comparison is stopped, and a signature behavior fingerprint reconstruction failure result is output. This process ensures that subsequent verification uses recalculated signature behavior fingerprint data, rather than the replaced log fields.

[0133] S520. After the signature behavior fingerprint reconstruction is successful, the reconstructed signature behavior fingerprint data is compared with the business session link information for continuity. The continuity comparison includes trusted execution environment continuity comparison, user authentication path continuity comparison, signature call time sequence continuity comparison, network access path continuity comparison, signature sequence position continuity comparison, and business event chain continuity comparison.

[0134] Trusted execution environment continuity comparison is used to determine whether the trusted execution environment measurement value and device security status correspond to the signing terminal identifier, and to confirm that the trusted execution environment measurement value and the signing private key call record are under the same signing business session identifier; user authentication path continuity comparison is used to determine whether the user authentication pass record is earlier than the signing private key call record, and whether the authentication method, authentication pass time, and authentication component identifier are consistent with the signing business session identifier; network access path continuity comparison is used to determine whether the network access path digest corresponds to the access link in the signing request initiation record, signature call record, and signing completion record; signature sequence position continuity comparison is used to determine whether the current signature sequence position is continuous with the preceding and following signature records within the same signing business session.

[0135] For the continuous comparison of signature call time sequence, the system recalculates and recomputes the signature call time sequence according to the start time and end time of each signature call in the business session link information, based on the position of the signature sequence:

[0136]

[0137] in, This represents the time sequence of signature recalculation calls. This indicates the end time of the nth signature call. This indicates the start time of the nth signature call, where n represents the number of signature calls within the same signing session.

[0138] The system compares the signature call time sequence with the signature call time sequence in the signature behavior fingerprint data. If the number of signature calls, their order, and the time consumed per call all correspond, the signature call time sequence continuity comparison passes. The business event chain continuity comparison is used to determine whether the signing request initiation record, user authentication pass record, signature behavior fingerprint data generation record, signing private key call record, electronic signature value generation record, signature occurrence evidence digest generation record, and signing completion record are continuous according to the chain digest.

[0139] The above sub-items form the results of the signature behavior sideprint continuity comparison:

[0140]

[0141] in, This indicates the result of the signature pattern continuity comparison. This indicates the results of the trusted execution environment continuity comparison. This indicates the result of the user authentication path continuity comparison. This indicates the result of a sequence comparison of signature call execution time. This indicates the results of the network access path continuity comparison. This indicates the result of the signature sequence position continuity comparison. This indicates the result of the business event chain continuity comparison. This indicates a logical AND operation.

[0142] If three documents are signed consecutively in the same signing business session, the business session link information should be able to recalculate the signing call time of the three signatures arranged in the signature sequence position; if only the completion time of the last signing can be obtained, it cannot prove which signature call the electronic signature to be verified corresponds to, and the result of the signature call sequence break should be output.

[0143] S530. Based on the cryptographic validity verification result and the signature behavior sideprint continuity comparison result, generate the long-term validity verification result of the electronic signature:

[0144]

[0145] in, This indicates the result of verifying the long-term validity of the electronic signature. This indicates the result of the cryptographic validity verification. This indicates the result of the signature pattern continuity comparison. This indicates a logical AND operation.

[0146] When the cryptographic validity verification result is passed and the signature behavior fingerprint continuity comparison result is passed, the long-term validity of the electronic signature is output, and the target file digest, electronic signature value, trusted timestamp token, certificate status response information, signing business session identifier and signature behavior fingerprint continuity comparison result are recorded.

[0147] When the cryptographic validity verification fails, the corresponding reason for the cryptographic verification failure will be output, including inconsistent file digest, mismatched electronic signature value, failure to bind trusted timestamp token, unverifiable certificate status, inconsistent binding digest, or failure to verify the integrity of the long-term validity evidence package.

[0148] When the cryptographic validity verification result passes but the signature behavior sideprint continuity comparison result fails, the electronic signature is not directly deemed to be valid in the long term. Instead, a risk result is output indicating that it was generated in a non-original trusted signing environment, and the specific type of break is marked, including inconsistent trusted execution environment, unverifiable user authentication path, broken signature call sequence, inconsistent network access path, discontinuous signature sequence position, or discontinuous business session link.

[0149] Through the above processing, even if the electronic signature value, signing certificate information, and trusted timestamp token can all be cryptographically verified, the system still needs to confirm that the electronic signature value is continuously closed with the original signing business session, the original signing terminal environment, the original user authentication path, and the original signing call sequence. If a verifiable electronic signature value is generated on another terminal after the signing private key is leaked, it will still be identified as a risky signature that does not have long-term validity because it cannot simultaneously meet the continuity requirements of trusted execution environment, user authentication path, network access path, and business event chain.

[0150] In this embodiment of the invention, a preset digest algorithm is used. Secure hash algorithms (such as SHA-256, SHA-3, or the national standard SM3 cryptographic hash algorithm) are preferred; signature operations Verification and signature calculation Choose an elliptic curve-based digital signature algorithm (such as ECDSA or the national cryptographic SM2 digital signature algorithm).

[0151] The cascading splicing symbol in the aforementioned formula This indicates that the binary data stream of each key field or the byte sequence after normalization encoding (such as ASN.1 or DER encoding) is concatenated in the last order.

[0152] The integrity verification, anti-tampering verification, and continuity comparison involved in this invention are all performed based on deterministic algebraic logic and cryptographic logic. The output results are absolute binary logical results (i.e., "pass" or "fail"), without fuzzy fitting or empirical estimation, thereby ensuring the cryptographic rigor of the long-term validity evidence chain of electronic signatures.

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

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

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

Claims

1. A time-stamp based electronic signature long validity verification method, characterized in that, Includes the following steps: S1. Receive the target file signing request, read the signing certificate information, signing terminal identifier and signing business session identifier generation parameters, calculate the target file digest, and have the edge computing node collect the signing environment data through the IoT encrypted channel to generate signature behavior fingerprint data and signature behavior fingerprint record; S2. Verify the signing private key call conditions based on the pre-signing record and signature behavior fingerprint data. After the verification is passed, sign the target file digest to generate an electronic signature value. Bind the electronic signature value, target file digest, signing certificate information, signature behavior fingerprint data and signature behavior fingerprint record to generate a signature occurrence evidence digest. S3. Submit a signature occurrence evidence digest to the trusted timestamp service, receive and verify the trusted timestamp token, obtain certificate status response information and business session link information, and generate a long-term validity evidence package. S4. Read the file to be verified, the electronic signature value, and the long-term validity evidence package; recalculate the digest of the file to be verified and the anti-tampering verification value; jointly verify the electronic signature value, the trusted timestamp token, the certificate status response information, and the binding digest; and generate a cryptographic validity verification result.

2. The time stamp based electronic signature long validity verification method according to claim 1, characterized in that, Also includes: S5. When the cryptographic validity verification result passes, reconstruct the signature behavior sideprint data, perform a signature behavior sideprint continuity comparison, and output the long-term validity verification result of the electronic signature.

3. The time stamp based electronic signature long validity verification method according to claim 1, wherein, S1 specifically includes: Receive a target file signing request, read the target file, signing business session identifier generation parameters, signing certificate information and signing terminal identifier, calculate the target file digest from the binary data of the target file, and generate a pre-signing record; Based on the pre-signing record, the edge computing node generates a collection batch number and a random challenge value, and collects trusted execution environment measurement values, device security status, user authentication path, network access path digest, signature call time sequence and signature sequence position through the IoT encrypted channel to form the signing environment collection data; The fields of the pre-signing record and the data collected in the signing environment are standardized and the order is bound to generate signature behavior fingerprint data and signature behavior fingerprint record.

4. The time stamp based electronic signature long validity verification method according to claim 1, wherein, S2 specifically includes: Based on the pre-signing record, read the target file digest, signing certificate information, signing business session identifier and signing terminal identifier. Verify the correspondence between certificate, session, terminal and private key based on the signature behavior fingerprint data. After the verification is passed, call the signing private key to generate electronic signature value. Read the electronic signature value, target file digest, signing certificate information, signing business session identifier, signature behavior fingerprint data, signature behavior fingerprint record, signing terminal identifier and edge computing node collection batch number, and generate a signature occurrence evidence unit and binding digest after standardized encoding.

5. The time stamp based electronic signature long validity verification method according to claim 4, characterized in that, Also includes: Perform field integrity, field consistency, and binding digest recalculation checks on the signature occurrence evidence unit. After the checks pass, generate the signature occurrence evidence digest and synchronously record the current system time as the evidence unit construction time.

6. The time stamp based electronic signature long validity verification method according to claim 1, wherein, S3 specifically includes: Read the signature occurrence evidence summary, the signed business session identifier, the collection batch number and the evidence unit construction time, generate timestamp request data, submit it to the trusted timestamp service through the IoT encrypted channel, and receive and verify the trusted timestamp token; Obtain certificate status response information based on signed certificate information and trusted timestamp token, read business session link information according to signed business session identifier, and verify certificate status response time window and link continuity.

7. The time stamp based electronic signature long validity verification method according to claim 6, wherein, It also includes: encapsulating trusted timestamp tokens, timestamp authority certificate information, signature occurrence evidence units, binding digests, signature occurrence evidence digests, certificate status response information, and business session link information into a long-term validity evidence package, and generating tamper-proof verification values.

8. The time stamp based electronic signature long validity verification method according to claim 1, wherein, S4 specifically includes: Receive the document to be verified, the electronic signature value, and the long-term validity evidence package. According to the evidence package identifier, the encapsulation version number, and the anti-tampering verification value, parse the signature occurrence evidence unit, the binding digest, the signature occurrence evidence digest, the trusted timestamp token, the certificate status response information, the business session link information, and the timestamp authority certificate information to generate a set of evidence to be verified. The binary data of the file to be verified is used to calculate the digest of the file to be verified, which is then compared with the digest of the target file. The electronic signature value is then verified using the public key of the certificate in the signing certificate information, thus forming a set of cryptographic verification materials.

9. The time stamp based electronic signature long validity verification method according to claim 8, wherein, It also includes: jointly verifying the integrity of trusted timestamp tokens, certificate status response information, binding digests, and evidence packets to generate cryptographic validity verification results.

10. The time stamp based electronic signature long validity verification method according to claim 2, wherein, S5 specifically includes: When the cryptographic validity verification result passes, read the signature generation evidence unit, signature behavior fingerprint data and signature behavior fingerprint record in the long-term validity evidence package, reconstruct the signature behavior fingerprint data according to the field order consistent with the generation stage, and compare it with the original signature behavior fingerprint data. The reconstructed signature behavior fingerprint data is continuously compared with the business session link information, and at least the trusted execution environment, user authentication path, signature call time sequence, network access path, signature sequence position and business event chain are verified. Based on the cryptographic validity verification results and the signature behavior sideprint continuity comparison results, the long-term validity verification results of the electronic signature and the corresponding break type are output.

Images