Document electronic signature processing method and electronic device

Abstract

The application discloses a processing method of electronic signature seal of a document and electronic equipment, and relates to the technical field of information security and electronic document processing, and comprises the following steps: determining a characteristic value of the content of a to-be-signed area on a server, generating a document digital signature according to a preset signature private key, constructing a binding structure based on the characteristic value of the seal image and the characteristic value of the document content, generating a binding signature for the binding structure, embedding the document digital signature, the binding signature and the seal image into a signature field to generate a signed document, and realizing integrated signing of the document content and the seal image. The document digital signature and the binding signature are generated based on the same signature private key, and the binding structure comprises the characteristic value of the document content and the characteristic value of the seal image, so that a strong binding relationship is formed between the document content and the seal image at the level of cryptography, and tampering with the document content or the seal image will lead to signature verification failure; the whole processing procedure is completed independently on the server, and the client does not participate in the cryptographic operation, so that the overall security of the signature system is improved.

Description

Technical Field

[0001] This application relates to the fields of information security and electronic document processing technology, and in particular to a method and electronic device for processing electronic signatures and seals on documents. Background Technology

[0002] An electronic signature system is a business system that uses cryptographic technology to digitally sign electronic documents such as PDF (Portable Document Format), OFD (Open Fixed-layout Document), and XML (eXtensible Markup Language). It integrates two core capabilities: digital signature and visual electronic seal. The digital signature is used to prove the integrity of the document content and the real identity of the signatory using cryptographic algorithms, while the electronic seal image meets the visual needs of intuitively verifying the signatory in business scenarios. It is widely used in online contract signing, government document circulation, and electronic certificate issuance.

[0003] Current mainstream electronic signature systems adopt a step-by-step processing approach. After the client uploads the original document to the server, the system processes it in two independent processes. First, the document content is extracted separately and an algorithm is used to calculate the document digest. Then, the digital signature is completed and embedded in the document using the private key stored in plaintext on the local client or server. Finally, the seal image is retrieved and overlaid onto the designated signature area of ​​the document.

[0004] In this process, digital signature computation and seal image rendering are two separate, unbound execution flows. The digital signature only covers the document content, while the seal image is superimposed on a designated location in the document as an independent visual element. There is a lack of effective correlation and verification mechanism between the two, leaving a gap that can be maliciously exploited for tampering. This architectural flaw results in the signature only verifying the original document text and not including the seal image in the protection scope. Attackers can replace the seal image in the document separately after completing a legitimate digital signature. The system cannot identify the seal tampering behavior, and the signature and seal cannot form a unique correspondence. The authenticity and integrity of the electronic document cannot be effectively guaranteed. Summary of the Invention

[0005] This application provides a method for processing electronic signatures and seals on documents, which can solve the problem that the signature and seal cannot form a unique correspondence, resulting in the inability to effectively guarantee the authenticity and integrity of electronic documents.

[0006] The first aspect of this application provides a method for processing electronic signatures and seals on documents, applied on a server side, including:

[0007] Determine the feature values ​​of the content in the area to be signed in the original document;

[0008] A digital signature of the document is generated by signing the feature value of the content in the area to be signed based on a preset signature private key.

[0009] A binding structure is constructed based on the feature values ​​of the preset seal image and the feature values ​​of the content of the area to be signed;

[0010] The binding structure is signed using the preset signature private key to generate a binding signature;

[0011] The document digital signature, the bound signature, and the preset seal image are embedded into the signature field of the original document to generate a signed document.

[0012] A second aspect of this application provides an electronic device, comprising: a processor and a memory connected to the processor, wherein:

[0013] The memory is used to store computer programs;

[0014] The processor is used to execute the computer program, enabling the electronic device to implement the document electronic signature and sealing processing method of the first aspect or any implementation thereof.

[0015] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the document electronic signature and sealing processing method described in the first aspect or any implementation thereof.

[0016] A fourth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to perform a document electronic signature processing method as described in the first aspect or any implementation thereof.

[0017] In summary, this application provides a method and electronic device for processing electronic document signatures and seals. By sequentially determining the feature values ​​of the content to be signed on the server side, generating a digital signature for the document based on a preset signature private key, constructing a binding structure based on the feature values ​​of the seal image and the document content, generating a binding signature on the binding structure, and embedding the document digital signature, binding signature, and seal image into the signature field to generate a signed document, integrated signing of document content and seal image is achieved. Since the document digital signature and binding signature are generated based on the same preset signature private key, and the binding structure simultaneously contains both document content feature values ​​and seal image feature values, a strong cryptographic binding relationship is formed between the document content and the seal image. Tampering with either the document content or the seal image will result in signature verification failure. Furthermore, the entire processing flow is completed independently on the server side, with the client not participating in any cryptographic operations, reducing the risk of private key leakage and improving the overall security of the signing system. Attached Figure Description

[0018] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0019] Figure 1 This is an application system structure diagram of a document electronic signature and sealing processing method provided in an embodiment of this application;

[0020] Figure 2 This is a flowchart illustrating a document electronic signature and sealing method provided in an embodiment of this application;

[0021] Figure 3 This is a flowchart illustrating the process of determining the feature values ​​of the area to be signed in the original document, as provided in an embodiment of this application.

[0022] Figure 4 This is a schematic diagram of the process of generating a document digital signature by signing the feature value of the content to be signed based on a preset signature private key, as provided in the embodiments of this application.

[0023] Figure 5 This is a flowchart illustrating the process of constructing a binding structure based on the feature values ​​of a preset seal image and the feature values ​​of the content of the area to be signed, as provided in this application embodiment.

[0024] Figure 6 This is a flowchart illustrating the verification process of signed documents provided in the embodiments of this application;

[0025] Figure 7This is a flowchart illustrating how the digital signature and the bound signature of a document are verified according to the verification rules corresponding to the signature algorithm used when generating the digital signature and the bound signature of the document, and the verification results are obtained.

[0026] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0028] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0029] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0030] Figure 1 This is an application system structure diagram of a document electronic signature processing method provided in an embodiment of this application. The application system includes multiple clients 101 and servers 102, and the clients and servers establish communication and interaction through the network.

[0031] The client 101 is only responsible for human-computer interaction and data transmission: the operator uploads the original document to be signed and initiates a signing request through the client, and the client transmits the original document to the server 102; after the server 102 completes the entire signing process, the client 101 receives the signed document returned by the server 102 and displays it to the operator.

[0032] If verification of the authenticity of a signed document is required, the operator can upload the document to be verified through client 101. Client 101 then sends the verification request and the document to be verified to server 102. Client 101 receives the document verification result returned by server 102 and presents it externally. Throughout the entire interaction, client 101 is only responsible for sending and receiving documents, requests, and results; it does not participate in any cryptographic operations, private key calls, or seal binding related processing. All core processing logic related to signing and verification is executed independently by server 102.

[0033] Figure 2 This is a flowchart illustrating a document electronic signature processing method provided in this application embodiment. The document electronic signature processing method provided in this application embodiment is applied to the server and may include steps 201 to 205. These steps are described in detail below.

[0034] 201. Determine the feature values ​​of the content in the area to be signed in the original document;

[0035] The original document is an electronic document that is to be signed and sealed, but does not contain any signature or seal data. It is transmitted from an external client to the server and can adapt to a variety of common document formats.

[0036] The area to be signed contains all the text data in the document except for the area specifically reserved for placing signature information. This is the core business content that needs to be protected during the signing process.

[0037] This feature value can be a fixed-length identifier obtained by performing a one-way hash operation on a complete binary data segment. The same original data will only generate the same feature value; any modification to the data will change the feature value, used to determine whether the content has been tampered with. The feature value uniquely identifies this portion of the content and is highly sensitive to data changes, accurately reflecting any subtle alterations to the content of the area to be signed.

[0038] In one possible implementation, the server reads the complete original document data, distinguishes between the reserved signature placeholder area and the main text content, removes the corresponding byte data of the placeholder area, retains only the main text data, and then generates the corresponding feature value to establish a unique input benchmark for subsequent signature operations, ensuring the determinism of the signature object.

[0039] 202. Sign the feature value of the content to be signed based on the preset signature private key to generate a digital signature for the document;

[0040] The default signature private key is a private cryptographic key assigned to the corresponding signature object, which only has the right to use it. It is only used to initiate the signature operation and cannot be disclosed to the public. Its corresponding public key is used for subsequent signature verification.

[0041] The server uses a preset signature private key to perform encryption operations on a defined feature value, generating a digital signature for the document. The document digital signature is encrypted verification data obtained by operating on the document content feature value using the private key; others can verify the signature's validity using the accompanying public key.

[0042] Based on the characteristics of asymmetric encryption algorithms, only the entity holding the preset signature private key can generate a valid signature, while any entity holding the corresponding public key can verify the signature's validity. As a core credential for the legal validity of electronic documents, a digital signature proves the authenticity of the source of the content in the area to be signed and ensures tamper-proof security after signing.

[0043] Among them, certificate-based domestic commercial cryptographic signature algorithms can be used to complete the signature operation, such as SM2 (Commercial Cryptography No. 2). Alternatively, identifier-based domestic commercial cryptographic signature algorithms can be used to implement the signature, such as SM9 (Commercial Cryptography No. 9).

[0044] The process of generating a digital signature for a document will be described in detail in subsequent embodiments, but will not be described in detail in this embodiment.

[0045] 203. Construct a binding structure based on the feature values ​​of the preset seal image and the feature values ​​of the content of the area to be signed;

[0046] The preset seal image is a visual seal graphic file matched for this signing transaction, used to display the visual identity of the signing entity. This preset seal image can include an official seal, contract seal, or personal name seal, etc.

[0047] Correspondingly, the feature value of the seal image is a unique identifier obtained by performing a hash operation on the complete seal graphic file data, which is used to identify whether the seal image has been replaced.

[0048] The binding structure is a standardized structured data carrier that can carry multiple types of associated verification information, facilitating unified execution of cryptographic signature and parsing verification.

[0049] The binding structure uses structured formats such as JSON (JavaScript Object Notation), XML (Extensible Markup Language), or binary data blocks to encapsulate the feature values ​​of the content to be signed and the feature values ​​of the preset seal image in the same data unit.

[0050] The server reads the complete data of the target seal image, generates seal image feature values ​​using hash operations, and then integrates the document content feature values ​​and seal image feature values ​​according to preset data structure rules to form a complete binding structure.

[0051] In one alternative implementation, the document content feature values ​​and the seal image feature values ​​can be assembled into a structure using standardized structured coding rules. Alternatively, a custom ordered data sequence can be used to complete the information assembly.

[0052] The binding structure method logically establishes a strong association between document content and seal image, so that the seal image no longer exists as an isolated picture, but is tightly bound to the document content through data structure, providing a data foundation for preventing seal replacement or content tampering.

[0053] 204. Sign the bound structure according to the preset signature private key to generate a binding signature;

[0054] A binding signature is encrypted verification data generated by operating the entire binding structure using the same signing private key. As a digital fingerprint of the binding structure, the binding signature verifies the integrity and binding relationship between the feature values ​​of the content to be signed and the feature values ​​of the preset seal image at the time of signing. Since the binding structure simultaneously encompasses the feature information of both the document and the seal, the binding signature effectively locks both together.

[0055] If an attacker replaces the seal image, the feature values ​​of the preset seal image will change, causing the reconstructed binding structure to be inconsistent with the original signature object, thus leading to the failure of the binding signature verification. This binding signature ensures the inseparability of the seal image and the document content.

[0056] The server can reuse the preset signature private key used in the aforementioned document digital signature generation process to execute signature logic on the bound structure and generate the bound signature.

[0057] The signature of the bound structure can be completed by independently calling the cryptographic unit interface, or the document signature operation channel can be reused to continuously complete the signature processing.

[0058] 205. Embed the document's digital signature, bound signature, and preset seal image into the original document's signature field to generate a signed document.

[0059] The signature field is a pre-defined fixed area within the original document specifically used to store signature verification data and seal images; the signed document is the final signed document that has completed all signature and seal embedding operations, can be issued externally, and supports authenticity verification.

[0060] The server locates the preset signature field position within the document, first writes the two types of digital signatures as hidden verification metadata into the bottom layer of the signature field, then renders and overlays the seal image onto the visual position of the signature field, and outputs the signed document after integrating all the data.

[0061] In practice, the signature metadata can be encrypted and hidden before being embedded in the document, or the signature metadata can be directly embedded in plaintext for basic verification scenarios.

[0062] The location and size of this signature field are usually defined during the document creation stage.

[0063] The server writes the data stream of the document's digital signature, bound signature, and preset seal image into the signature field. This can be done by serializing the data according to document format standards and storing it in a specific field, hidden layer, or additional data packet. The final signed document integrates the visible preset seal image with the invisible digital signature data, achieving unified storage and transmission of the document, signature, and seal, and giving the signed document independent, complete, and verifiable validity.

[0064] The server can use the SM4 (Commercial Cryptography No. 4) block cipher algorithm to encrypt and protect the signature data embedded in the signature field to prevent the signature metadata from being read illegally. In another possible implementation, the ZUC (Zu Chongzhi) stream cipher algorithm can be used instead of SM4 for encryption protection. In this case, a stream cipher mode must be used and an additional IV (Initialization Vector) must be generated.

[0065] The document format standard can be PDF, OFD, etc.

[0066] Steps 201 to 205 are executed consecutively within the same server-side processing flow without interruption, completing as a single atomic transaction. This integrated processing method ensures that both the document digital signature and the bound signature are generated based on the document and seal states at the same moment, eliminating uncertainties in intermediate states. Alternatively, each step can be executed in segments, with intermediate data temporarily cached after each step before proceeding to the next step. However, no other data is responded to between any two steps to prevent tampering with intermediate data. The document digital signature guarantees the integrity and authenticity of the content, while the bound signature establishes a strong binding relationship between the seal and the document through joint signatures. The synergy between the two ensures that any alteration to the document content or replacement of the seal image can be effectively identified during the signature verification process, significantly improving the security and anti-attack capabilities of the electronic signature system.

[0067] In this embodiment, the server sequentially calculates the feature values ​​of the area to be signed, generates a digital signature for the document using a preset private key, constructs a binding structure by combining the seal and document features, signs the structure to obtain the binding signature, and finally embeds the two types of signatures and the seal image into the document signature field to generate a signed document. This dual signature system protects both the original document and the binding relationship between the document and the seal. Both are generated using the same private key to form a cryptographic binding, ensuring that any tampering with the document or seal can be detected during signature verification. All cryptographic processing logic is centralized on the server side, and the client does not access the key, effectively improving the overall tamper-proof capability of the electronic signature and the security of the key.

[0068] Figure 3This is a flowchart illustrating the process of determining the feature values ​​of the area to be signed in the original document, as provided in the embodiments of this application. It may include steps 301 to 304, which are described in detail below.

[0069] 301. Receive the original document to be signed uploaded by the client;

[0070] The server receives the original document to be signed from the client through a network transmission interface. This document is a digital file object to be electronically signed and stamped, and its format includes PDF, OFD open format document or other structured document formats.

[0071] The server can use a pre-configured application programming interface to receive document data streams and store them in a temporary buffer or a specified storage path, providing a data foundation for subsequent parsing operations.

[0072] In practical applications, the client is only responsible for uploading documents and is decoupled from the signature processing logic; after receiving the original document to be signed, the server independently completes the entire signature and seal processing flow until the signed document is output.

[0073] The client obtains the document to be signed selected by the operator through a human-computer interaction interface and transmits it to the server via the network. After receiving the original document, the server can temporarily store it in memory or a temporary storage area, awaiting further processing.

[0074] The server can perform format validation on the received original document to confirm that it is a supported document format. If it is not supported, it will return an error message to the client. The server can also receive document fragments transmitted by the client in the form of streaming data and process them as it is received.

[0075] 302. Parse the original document and identify the pre-defined signature fields within the document;

[0076] The obtained original document to be signed is parsed and processed to accurately locate the pre-set signature field within the document.

[0077] The server can read the structural information of the original document and parse its internal organization. For PDF format, the server can parse its page tree, annotation dictionary, and other structures to check for the existence of defined signature fields, such as the signature field field in AcroForm. For OFD format, the server can parse its Signs node (signature collection node) or Signature structure (signature structure) to identify pre-defined signature areas.

[0078] Pre-defined signature fields are placeholder areas embedded in advance during the document creation stage to mark the location and scope of signatures. They typically contain parameters such as rectangular coordinate information, page number index, and visual appearance attributes.

[0079] Deep parsing based on document structure can accurately identify the boundary range of pre-defined signature fields, thus clearly distinguishing the signature placeholder area from the actual document content. This recognition process employs structured analysis based on document syntax, improving the accuracy and robustness of signature field recognition.

[0080] If the original document does not have a pre-defined signature field, the server can automatically create a signature field at a specified location in the document, or dynamically generate a signature field based on the location specified by the client.

[0081] 303. Extract the content data of the area to be signed from the original document, excluding the signature field;

[0082] Based on the specific range of the identified preset signature field, further extract the content data of the area to be signed.

[0083] The content data of the area to be signed refers to the actual document content that needs to be protected by signing. It is all the content data in the original document except for the bytes occupied by the preset signature field itself.

[0084] During the extraction process, the server filters the original byte stream of the document based on the obtained signature field coordinates and range information. It removes placeholder data such as dictionary structures and appearance streams occupied by the signature field from the original document's binary data, retaining only the byte sequences that constitute the document's substantive information, such as the main text, images, tables, and fonts. For example, when processing PDF documents, cross-reference objects and content stream fragments located outside the signature field rectangle in the page content stream are extracted and reconstructed into the content data of the area to be signed. This extraction method ensures the purity of the document content participating in the digest calculation, eliminating hash value fluctuations caused by changes in signature field placeholders (such as minor position adjustments or appearance updates), ensuring that the signature operation only applies to the substantive content of the document.

[0085] The server can use byte offsets to concatenate the data before and after the signature field into a continuous area to be signed. Alternatively, the server can directly read the document's logical content (such as the page content stream of a PDF), skipping the graphic or form elements corresponding to the signature field. The extracted area to be signed should maintain the integrity and order of the original document to ensure consistency in subsequent hash calculations.

[0086] Because the extraction process is performed uniformly by the server, inconsistencies in content caused by differences in parsing logic between different clients are avoided, ensuring that the signing and stamping operations are based on the exact same document data snapshot.

[0087] 304. Calculate the first digest value of the content to be signed using a preset hash algorithm. The first digest value is used as the feature value of the content to be signed.

[0088] Based on the extracted data of the area to be signed, a hash algorithm is used to calculate its digest, generating a first digest value.

[0089] This calculation process maps data of arbitrary length to be signed region content to a fixed-length hash value. A pre-defined hash algorithm converts the input data stream into a digest string using a specific compression function. During calculation, the data to be signed region content is used as input, and after padding, grouping, and multiple rounds of iterative compression, the feature value of the data to be signed region content is obtained.

[0090] The first digest value, serving as a feature value for the content to be signed, is a digital fingerprint of the document content. It possesses uniqueness and collision resistance; that is, any slight change in the document content will cause a significant change in the first digest value. By condensing massive amounts of document data into fixed-length feature values, standardized input data is provided for subsequent digital signature operations, greatly reducing the data processing volume for signature calculations and ensuring a strong binding relationship between the signature and the document content.

[0091] In one possible implementation, the SM3 cryptographic hash algorithm can be used to meet security compliance requirements, and it can output a fixed-length binary digest and convert it into a hexadecimal string identifier; in addition, other general-purpose compliant one-way hash algorithms can also be used to complete the digest calculation.

[0092] In this embodiment, the server receives the original document from the client, parses and identifies the document's pre-set signature field, removes the signature placeholder data, extracts the pure business text, and then calculates the document's feature value using a unified hash algorithm. By distinguishing between the signature field and the business content, it avoids erroneous changes in feature value caused by signature frame style adjustments, generating a unique digital fingerprint only for the actual business content. This ensures from the source that the signature only protects valid signed content, improving the accuracy of tamper detection.

[0093] Figure 4 This is a flowchart illustrating the process of generating a document digital signature by signing the feature value of the content to be signed based on a preset signing private key, as provided in this application embodiment. It may include steps 401 to 403, which are described in detail below, including:

[0094] 401. Obtain the identity information of the signature object;

[0095] The signatory refers to the party initiating or responsible for this signing act, which can be a natural person, a legal person, or other organization.

[0096] The identity information of the signing object serves as a core credential for verifying the operator's permissions and locating their corresponding key resources. It uniquely identifies the signing entity's registered identity in the cryptographic management system. This identity information can be structured data, and in practical applications, it includes, but is not limited to, the signing object's name, ID card number, mobile phone number, email address, digital certificate serial number, user account ID (Identity), organization code, and the digital certificate serial number of this signing operation.

[0097] Using the above information, the system can accurately locate the key object that should be used in a storage environment with a large number of keys, while preventing unauthorized users from misusing other people's private keys.

[0098] Typically, this identity information originates from the authentication token carried by the client when initiating a signature request. This authentication token is issued by the server after the user logs in or passes identity authentication. It encapsulates identity fields that have been encrypted and signed or digested, ensuring the authenticity and integrity of the identity information during transmission and providing a prerequisite for subsequent secure calls.

[0099] 402. Based on the identity information of the signing object, obtain the access permission to call the preset signing private key corresponding to the signing object from the password management module of the server. The password management module can be either a key management service or a hardware cryptographic machine. The preset signing private key is stored inside the password management module.

[0100] The cryptography management module is responsible for the secure storage and access control of keys. It is a key component for ensuring the security of preset signature private keys and is responsible for the full lifecycle management of preset signature private keys, including key generation, storage, use and destruction.

[0101] In terms of physical deployment, the password management module and the server-side business server are located in the same trusted network area, such as within the same data center's internal private network, communicating via intranet protocols to prevent direct attacks from the internet. The specific form of the password management module varies depending on the security level and business scale.

[0102] The cryptographic management module can be either a Key Management Service (KMS) or a Hardware Security Module (HSM).

[0103] If a key management service is used, it typically manifests as key management software running on a high-security server cluster. The default signing private key is persistently stored in a database as encrypted ciphertext; only the secure memory environment within the key management service has decryption privileges, and the business server cannot directly access the plaintext private key.

[0104] If a hardware cryptographic machine is used, it is a dedicated hardware device with an independent encryption chip and anti-tampering mechanism (such as a hardware cryptographic machine that conforms to the standards of the State Cryptography Administration). In this scenario, the preset signature private key is directly burned into the hardware secure area (non-volatile memory inside the HSM) during the hardware cryptographic machine's production or initialization stage, and it cannot be exported to the external environment under any circumstances.

[0105] In this application, the preset signature private key is stored inside the password management module, which means that the private key never leaves the security boundary of the password management module. The server application layer cannot directly read or copy the plaintext of the private key, but can only indirectly use the private key to perform signature operations through the call interface provided by the password management module, thus fundamentally eliminating the risk of private key leakage.

[0106] The process of obtaining access permission is essentially a strict authentication and access control procedure. The server, based on the identity information of the obtained signature object, initiates a request to the password management module. Upon receiving the request, the password management module first parses and verifies the validity of the identity information, checking whether the entity has the permission to use the target key. For example, the system checks whether the certificate serial number in the identity information matches the key index, or verifies the legality of the operation token signature. Only when the identity is confirmed to be legitimate and the permissions meet the preset policies (such as not exceeding the operation time window or quota limits) will the password management module grant access permission for this operation, thus opening a protected secure session context. Through this mechanism, regardless of whether software encryption storage or hardware physical isolation is used, the preset signature private key is stored internally within the password management module. The plaintext of the private key never leaves the security boundary of the password management module, thereby completely eliminating the risk of the private key being leaked in the business server's memory or intercepted during network transmission.

[0107] 403. Send the feature value of the content to be signed to the password management module to call the built-in signature interface of the password management module, and use the signature interface to call the preset signature private key to complete the signature operation and generate a digital signature for the document.

[0108] After obtaining access permissions, the server sends the feature values ​​of the content to be signed, calculated through the aforementioned steps, to the password management module as input data for this signature operation. Since only the feature values ​​of the document content are sent to the password management module, rather than the complete content stream of the original document, this further reduces the risk of data leakage and minimizes network transmission overhead.

[0109] The cryptographic management module's built-in signature interface serves as a standardized execution unit for cryptographic operations, encapsulating the underlying implementation details of the national cryptographic algorithms. The built-in signature interface performs data mapping and compression calculations according to general asymmetric signature operation logic. For example, in a scenario using the SM2 algorithm, the built-in signature interface is configured to perform dot product operations and hash mappings on elliptic curves. When the cryptographic management module receives a feature value, it triggers the signature operation process within its internal secure execution environment. In this process, the cryptographic management module directly reads a preset signature private key from its internal key storage area to participate in the operation, but this private key is only used as an input parameter for internal calculations; intermediate variables involved in the calculation process and the private key itself are not output through any interface. After the signature operation is completed, the cryptographic management module outputs the result, i.e., the document digital signature, through the built-in signature interface. This document digital signature typically contains two parts of value (e.g., the r value and s value in the SM2 algorithm), which are encoded (e.g., Base64 encoding or ASN.1 encoding) to form a standard signature byte string and returned to the server. This computational model of data in, signature out, and private key retention ensures that even if the server-side business system is controlled by a malicious attacker, the attacker cannot extract a valid preset signature private key from memory or logs, thus achieving a high level of key security protection.

[0110] In one possible implementation, when the cryptographic management module is a KMS, the signature interface is exposed to the server via RPC (Remote Procedure Call) or HTTP RESTful API (Representational State Transfer Application Programming Interface). The server serializes the first digest value into a request message and sends it to the KMS. After the KMS completes the signature, it returns the document digital signature. In another possible implementation, when the cryptographic management module is an HSM, the server communicates with the HSM through a dedicated driver provided by the HSM vendor or the PKCS#11 (Public-Key Cryptography Standards #11) standard interface, passes the first digest value to the HSM, and obtains the signature result.

[0111] A document digital signature is the output of a signature operation. It can be a string of binary data containing the signature value and possibly accompanying information such as the signature algorithm identifier and the signer's certificate. This document digital signature will be embedded in the document along with the binding signature generated in subsequent steps to verify the integrity of the document content and the authenticity of the signer.

[0112] In this embodiment, the server obtains the identity credentials of the signing object and retrieves the private key from the isolated cryptographic management module according to its permissions. Only the document feature value is transmitted to complete the remote signature calculation. The signing private key is stored in the cryptographic management module throughout the process and is not output externally. By relying on identity authentication to control the access permissions of the private key, the risk of plaintext leakage of the private key is avoided, and the data transmission volume is reduced through lightweight feature transmission, thereby improving the security level of the signing process.

[0113] Figure 5 This is a flowchart illustrating the construction of a binding structure based on the feature values ​​of a preset seal image and the feature values ​​of the content of the area to be signed, as provided in this application embodiment. It may include steps 501 to 505, which are described in detail below, including:

[0114] 501. Based on the identity information of the signing object, obtain the signing identity certificate corresponding to the signing object from the password management module of the server. The type of the signing identity certificate is adapted to the preset signing algorithm. The signing identity certificate includes a public key certificate or a user identifier.

[0115] The signature identity credential serves as key data for verifying the legitimacy of the initiator of the signature operation, and its specific type depends on the preset signature algorithm system used.

[0116] When using a certificate-based PKI (Public Key Infrastructure) system, the signature identity credential is a public key digital certificate. For example, when the default signature algorithm is the SM2 algorithm, the signature identity credential is a public key certificate.

[0117] When using an identity-based cryptography system, the signature identity credential serves as a unique user identifier. For example, when the preset signature algorithm uses the SM9 algorithm, the signature identity credential could be the signature recipient's ID card number, unified social credit code, mobile phone number, email address, etc.

[0118] The server initiates a query request to the password management module deployed on the server, based on the identity information of the signing object. This password management module can be a key management service or a hardware cryptographic machine. In response to the query request, the password management module returns a signature identity credential that matches the signing object.

[0119] If the default signature algorithm is SM2, a standard X.509 format public key certificate is obtained, which contains the signer's public key and the issuing authority's signature; if the default signature algorithm is SM9, a user identifier string distributed by the system key generation center (KGC) is obtained.

[0120] 502. Determine the preset seal image corresponding to the signature object and seal position of the original document;

[0121] Preset stamp images are typically stored in common image formats, including Portable Network Graphics (PNG), Joint Photographic Experts Group (JPEG), Bitmap (BMP), or Scalable Vector Graphics (SVG).

[0122] Matching decisions are made based on the context parameters of the current signing transaction. The system can search the seal resource index based on the identity information of the signing object and the signature location specified in the business requirements (including page number, coordinates, seal size, and other parameters).

[0123] The server typically maintains a set of seal usage permission configuration tables, which define the seal images allowed for different signing objects in different document types or specific signing locations. By querying this configuration table, a uniquely matching preset seal image can be selected.

[0124] For example, when a signature request is requested in the bottom right corner of page 1 of a Contract Type A document, the system matches a preset seal image named "Contract Seal 01". Determining the preset seal image is a prerequisite for subsequent image data extraction and feature value calculation, ensuring the business compliance and positional accuracy of the stamped document.

[0125] On the server side, a signature object may correspond to one or more seal images, such as official seals and contract seals for different purposes. The server selects the matching seal image from them based on the seal position or seal type (such as signature seal or seal across the seam).

[0126] When uploading the original document, the client specifies the seal image identifier to be used, and the server directly determines the preset seal image based on the identifier.

[0127] The server also automatically matches a default seal image based on the document type or signing scenario.

[0128] 503. Retrieve image data of preset seal images from the seal management library on the server.

[0129] The seal management library is a database or file system on the server side specifically used to store and manage various electronic seal image files. The image data stored inside is usually in uncompressed or compressed bitmap formats, such as BMP (Bitmap), PNG (Portable Network Graphics), or JPG (Joint Photographic Experts Group).

[0130] The seal management library can be implemented based on relational databases (such as MySQL, PostgreSQL), object storage services (such as MinIO, cloud object storage), or distributed file systems (such as Hadoop Distributed File System, HDFS).

[0131] Using the unique identifier of the preset seal image determined in the previous step (such as seal ID or filename), a read request is initiated to the seal management library to obtain the complete binary data stream of the image. This image data is a digital form of the seal's visual representation, including the complete image file header, color space information, pixel data, and all pixel information that constitutes the seal pattern. By obtaining the image data from a centrally managed seal management library, the singularity and reliability of the seal's source are ensured.

[0132] For example, the seal image data in the seal management library is stored in plaintext, and the server directly reads the original image file; or the seal image data in the seal management library is encrypted using a symmetric encryption algorithm (such as the SM4 block cipher algorithm), and the server needs to read the ciphertext data first, and then use the corresponding decryption key to decrypt it to obtain the original image data; or the seal management library stores thumbnails or vector descriptions of seal images, and the server needs to render and generate the final image data in real time according to the template.

[0133] 504. Use a preset hash algorithm to perform hash calculation on the image data of the preset seal image to obtain the feature value of the preset seal image;

[0134] In order to convert large-capacity image data into fixed-length digests that are easy to cryptographically process, a preset hash algorithm is used to perform digest calculations on the acquired image data to generate feature values ​​that can uniquely and accurately represent the content of the seal image. Any tampering with the image pixels will lead to drastic changes in the feature values.

[0135] The complete image data of the acquired preset seal image is used as input, and the same preset hash algorithm as used to calculate the feature value of the content of the area to be signed is used to perform hash calculation to obtain the feature value of the preset seal image. The feature value of the preset seal image is highly sensitive to any modification to the seal image data (including minor changes at the pixel level, image format conversion, size adjustment, etc.). Any modification will cause a significant change in the feature value, which will be detected during signature verification.

[0136] This feature value is a fixed-length binary data used to uniquely identify the content of the preset seal image. Because it uses the same hash algorithm as the document content feature value, consistency in feature value calculation is ensured throughout the entire signature system, facilitating subsequent binding structure construction and signature verification operations.

[0137] The preset hash algorithm can employ the SM3 cryptographic hash algorithm. This process maps image data of arbitrary length into a 256-bit (32-byte) hash value, which is the feature value of the preset seal image. This transforms unstructured image data into structured, short data, reducing the amount of data required for subsequent signature calculations and providing a quantitative comparison basis for verifying whether the seal has been replaced. Even if an attacker replaces the visual appearance of the seal image, the mismatch in feature values ​​makes this tampering easily detectable in subsequent verification stages.

[0138] 505. Construct a binding structure based on the feature values ​​of the content to be signed, the feature values ​​of the preset seal image, and the signature identity certificate.

[0139] The binding structure is a standardized structured data carrier used to encapsulate the feature values ​​of the content to be signed, the feature values ​​of the preset seal image, and the signature identity certificate in the same data unit, establishing a cryptographic association between the document content and the seal image.

[0140] The feature values ​​of the acquired area to be signed (representing the integrity of the document content), the feature values ​​of the preset seal image (representing the authenticity of the seal image), and the signature identity certificate (representing the legitimacy of the signature subject's identity) are encapsulated according to the preset data structure specifications to form a binding structure.

[0141] The binding structure can be encapsulated using JavaScript Object Notation (JSON) format, with the three elements treated as fields of a JSON object. Alternatively, it can be encapsulated using eXtensible Markup Language (XML) format, with the three elements treated as child nodes of an XML element. Furthermore, the binding structure can be encapsulated using Protocol Buffers or a custom binary data block format to improve parsing efficiency and reduce storage space.

[0142] The binding structure may also include other auxiliary information, such as globally unique transaction identifiers (TransactionID), trusted timestamp tokens, signature algorithm identifiers, and other extended fields, to enhance the integrity and traceability of the binding relationship. This additional information will be further explained in subsequent embodiments.

[0143] In one possible implementation, the binding structure may also include the following optional fields: seal identifier (seal_id), used to uniquely identify the seal used; signing reason (sign_reason), used to record the business purpose of this signing; seal coordinates (sign_location), used to record the seal's position information in the document (such as page number, x-coordinate, y-coordinate); and algorithm object identifier (algorithm_oid), used to identify the algorithm suite used for signing. These optional fields can be selectively included in the binding structure according to business needs to enhance the integrity and traceability of the seal information.

[0144] Once the binding structure is constructed, it will serve as the input data for generating the binding signature. Since the binding structure contains feature information from both the document content and the seal image, the signing operation on it essentially performs a strong cryptographic binding between the document content and the seal image. By constructing this binding structure, physically independent document feature values, seal image features, and identity credentials are logically locked into a single whole, providing a reliable data object for subsequent binding signature operations. Any tampering with the document content or seal image will result in the reconstructed binding structure being inconsistent with the original binding structure, thus being effectively identified by the signature verification process. This technically prevents the possibility of the document signature and seal image being forged or replaced separately.

[0145] After generating the signed document, the process includes: calculating the overall hash value of the final signed document (including embedded signature data and superimposed seal image) using a preset hash algorithm, which serves as the document fingerprint for this signing operation; and storing the document fingerprint in the signing log database in pairs with the transaction identifier (sign_id) for subsequent rapid verification of document integrity and traceability of signing behavior.

[0146] In this embodiment, by encapsulating the feature values ​​of the content to be signed and the feature values ​​of the preset seal image in the same binding structure, a cryptographic association between the document content and the seal image is established, so that the seal image no longer exists as an isolated visual element; the introduction of the signature identity credential incorporates the identity information of the signing object into the binding structure, so that the binding relationship not only covers the document and the seal, but also extends to the identity verification of the signing object; the binding structure is encapsulated in a standardized structured format, which facilitates subsequent unified signature and parsing verification, and improves the system's compatibility and scalability.

[0147] In one possible implementation, after calculating the feature value of the content of the region to be signed using a preset hash algorithm, the following is also included:

[0148] Generate a globally unique transaction identifier for this signature and seal, which is used to associate the entire process log of this signature and seal; obtain a timestamp token as the time identifier for this signature and seal;

[0149] A transaction identifier serves as a consistent tracking index throughout the entire signing and sealing transaction. This transaction identifier is a unique coded sequence that identifies the specific operation performed.

[0150] The transaction identifier can be formed by concatenating a UUID (Universally Unique Identifier) ​​with the current system's millisecond-level timestamp. For example, a 128-bit UUID can be generated using the Java language's UUID.randomUUID() method, and the current system timestamp can be obtained (e.g., System.currentTimeMillis()). The two are then combined using a separator to form a string, such as 550e8400-e29b-41d4-a716-446655440000_1717488000000, where the separator is an underscore (_).

[0151] By leveraging the spatial uniqueness of UUIDs and the temporal uniqueness of timestamps, the global uniqueness of transaction identifiers is ensured in high-concurrency, distributed environments. In addition, other general-purpose unique identifier generation methods, such as distributed snowflake algorithms and auto-incrementing sequence encoding, can also be used to construct transaction identifiers, all of which can meet the requirement of globally non-repeating usage.

[0152] Based on the transaction identifier, the server will uniformly associate and store all operation data in the backend database, including document parsing records, feature value calculation records, key permission call records, signature operation records, seal resource call records, and document output archiving records, so as to achieve end-to-end operation traceability and auditing and meet the compliance requirements of the Electronic Signature Law for the traceability of signing behavior.

[0153] The time stamp is used to accurately record the actual time of the signature and seal operation. It is generated based on an external authoritative and credible time source, which can effectively avoid problems such as local device time tampering and time offset, eliminate the risk of signing time forgery, and provide a real, credible and legally valid time benchmark for electronic signature behavior.

[0154] The server can first construct a timestamp request message, which includes the first digest value of the content to be signed generated in the previous steps and the hash value of the transaction identifier, to ensure that the timestamp is strongly bound to the specific document content. The server then sends this request to the connected TSA (Trusted Timestamp Authority), such as a legally qualified and authoritative time service organization, to complete the request verification and timestamp issuance.

[0155] Upon receiving a request, the trusted timestamp service verifies its legitimacy and uses its own private key to digitally sign the feature values, receipt time, and other information contained in the request, generating a timestamp token which is returned to the server. This timestamp token contains an electronic signature signed by an authoritative timestamp service, possessing the characteristics of being tamper-proof and unforgeable. It serves as valid legal proof that the electronic document truly existed at the corresponding time point and that the signing act actually occurred, effectively solving the problems of signing time verification and time non-repudiation in electronic signatures.

[0156] In addition, the server can also obtain time identifiers by means of timed time synchronization and batch pre-application of valid time tokens, adapting to different business operation scenarios such as offline and weak network, and ensuring the validity and reliability of the signature time identifier.

[0157] Accordingly, constructing the binding structure includes:

[0158] Construct a binding structure based on the feature values ​​of the content to be signed, the feature values ​​of the preset seal image, the signature identity certificate, the transaction identifier, and the time identifier.

[0159] Having already obtained the feature values ​​of the area to be signed, the preset seal image, and the signature authentication certificate in the previous steps, the transaction identifier and time identifier are further incorporated and assembled into a binding structure. By including the transaction identifier and time identifier in the binding structure, the information carried by the binding structure becomes richer and more complete. The transaction identifier makes each signing operation traceable, while the time identifier provides legal time proof of the signing act.

[0160] Logically, this binding structure is a data container that contains all the key signature elements.

[0161] The binding structure can be defined using structured coding rules such as ASN.1 (Abstract Syntax Notation One), and includes five core fields: a document digest field (filled with feature values ​​of the content to be signed), a seal digest field (filled with feature values ​​of a preset seal image), an identity credential field (filled with the signature identity credential), a transaction identifier field (filled with the transaction identifier), and a timestamp field (filled with a timestamp token). By incorporating the transaction identifier and timestamp into this structure and cryptographically protecting them together during the subsequent binding signature process, it is ensured that any tampering with the signing time or operation record will result in verification failure. This achieves the indivisibility of electronic documents, seal images, signing entities, signing time, and operation logs at the physical level, constructing a complete electronic evidence chain.

[0162] In this embodiment, a globally unique transaction identifier is generated to associate with the entire signing process log, and a timestamp token is obtained as a time identifier. The transaction identifier and time identifier, along with the feature values ​​of the content to be signed, the feature values ​​of the preset seal image, and the signature identity certificate, are combined to construct a binding structure, achieving full-element binding of the signing operation. The introduction of the transaction identifier ensures that each signing operation has a globally unique serial number, facilitating subsequent auditing, tracing, and problem investigation. The entire operation log of the current signing can be quickly retrieved through the transaction identifier. The introduction of the timestamp token provides legally valid time proof for the signing behavior, ensuring the authenticity and non-repudiation of the signing time. Including the transaction identifier and time identifier in the binding structure and subjecting them to signature protection also brings the operation serial number and signing time under cryptographic protection. Any tampering with this information will be effectively identified by the signature verification process, further enhancing the security of the signed document.

[0163] In one possible implementation, the construction of the binding structure is performed after the document digital signature is generated, and the generation of the binding signature is performed immediately after the construction of the binding structure.

[0164] Generating a document digital signature, constructing a binding structure, and generating a binding signature are completed consecutively as a single atomic transaction within the same processing flow, without any external operations intervening or interrupting the process.

[0165] Atomic transactions refer to integrating multiple related operations into an indivisible whole execution unit. This execution unit has the binary execution characteristics of complete execution or complete rollback, and there are no intermediate states such as partial execution, mid-process pause, or intermediate residual data.

[0166] To avoid the risks of data inconsistency caused by asynchronous execution, process interruption, and external interleaving operations, and to ensure that document signing, structure binding, and binding signature are logically highly coupled and completely consistent, this embodiment encapsulates the three core operations into the same secure processing context for serial execution, strictly limits the execution sequence, and constructs a closed-loop signature cryptographic operation chain.

[0167] Based on a pre-defined atomic transaction constraint mechanism, after the preceding document digital signature generation operation is successfully completed, the system triggers the construction process of the binding structure without delay. The moment the binding structure is fully generated and the data state is solidified, the system immediately starts the signature calculation process for the binding signature. These three operations form a fixed, orderly, tightly connected, and indivisible execution chain. There is no time window for external tasks, third-party calls, or manual intervention to be inserted into the entire calculation chain, completely eliminating the risk of tampering during process gaps.

[0168] The atomicity of the overall execution can be guaranteed by relying on a transaction consistency control mechanism. The server uniformly opens a dedicated signing transaction context and completes the entire process of document digital signature generation, binding structure construction and storage, and binding signature generation and writing in a fixed sequence. The overall state is only unified and takes effect after all three core operations are successfully verified and the data is written in compliance with regulations; if any step encounters problems such as calculation abnormalities, data writing failures, or system abnormalities, the overall transaction is immediately rolled back, and all intermediate data and temporary states generated in this transaction are revoked to prevent incomplete signature data residue.

[0169] The continuity and exclusivity of operations can be ensured through an exclusive resource locking mechanism. Before initiating the first signature operation, the server requests exclusive lock resources for this signing transaction, and releases the lock resources only after the final step of binding and generating the signature. During the lock resource holding period, all intervention operations from external threads, processes, and business requests are blocked, ensuring the exclusive execution of a single signing transaction and avoiding timing errors and data pollution caused by multiple tasks overlapping.

[0170] Furthermore, atomic process control can be achieved through a standardized task orchestration mechanism. The three core signing operations are defined as consecutive task nodes under the same transaction chain. The process scheduling mechanism ensures that the nodes are executed strictly in sequence, without interruption or skipping. Any abnormal execution of any node triggers the overall compensation and rollback mechanism to ensure the overall consistency of the transaction.

[0171] At the temporal logic level, this solution strictly limits subsequent operations to relying on previously solidified data, ensuring strong consistency of the signed data. Specifically, the binding structure must be executed after the document's digital signature is generated. This is because the core components of the binding structure contain the feature values ​​of the content to be signed. These feature values ​​are the core input data for generating the document's digital signature. After the document's digital signature is generated, the document content feature values ​​are completely solidified and no longer change. Constructing the binding structure at this point ensures that the document feature data carried in the binding structure is completely identical and source-specific to the core content of the document protected by the document's digital signature, thus avoiding inconsistencies in document data status from the outset.

[0172] Furthermore, the binding signature must be executed immediately after the binding structure is constructed. The binding structure is the only legitimate input carrier for generating the binding signature. If there is an execution gap between the completion of the structure construction and the generation of the binding signature, malicious actors can exploit this time window to tamper with or replace the seal feature data, document feature data, or identity credential data within the binding structure. This would cause the binding signature to provide protection for the tampered data, completely undermining the signature security system. By executing the binding signature in a seamless, continuous manner, the time window for the structure data to be tampered with is completely eliminated.

[0173] Furthermore, the overall constraint characteristics of atomic transactions ensure that the generation states of document digital signature, binding structure, and binding signature are completely synchronized. There are no incomplete intermediate states such as document signature being successful but binding signature missing, or structure being constructed but not signed. This allows document content anti-tampering verification and seal binding verification to form an integrated security protection system, achieving synchronous locking and synchronous effectiveness of signing and sealing actions.

[0174] In this embodiment, the construction of the binding structure and the generation of the binding signature are sequentially executed following the document digital signature generation operation. These three operations are encapsulated as indivisible atomic transactions and executed serially. Timing constraints eliminate the time window for tampering, and the transaction rollback mechanism prevents incomplete or incomplete signatures, ensuring that the document signature and the seal binding signature are generated based on the same document snapshot, resulting in completely consistent data states.

[0175] Figure 6 This is a flowchart illustrating the verification process of signed documents provided in this application embodiment, which may include steps 601 to 605. These steps are described in detail below, including:

[0176] 601. Parse the signature field of the document to be verified and signed to obtain the document digital signature, bound signature, preset seal image, signature identity certificate, transaction identifier, and time identifier carried in the signature field;

[0177] A document awaiting verification and signature is an electronic document that has already been signed and requires verification of its authenticity and integrity. It is uploaded to the server by the client, which then initiates a verification request. The document can be in PDF, OFD, or other document formats that support digital signatures.

[0178] The signature field is a pre-defined, fixed area used exclusively for storing signature verification data and a visual seal image during the document creation stage. The server-side performs deep analysis of the document's internal structured data to accurately locate the signature field and extract all the core data encapsulated within. For different document formats, an appropriate structured parsing logic is used to locate the signature field: for PDF documents, the signature field data corresponding to the form signature structure is parsed; for OFD documents, the unique signature nodes and signature structure data are parsed to extract the signature elements.

[0179] Through standardized parsing, six core verification elements encapsulated within the signature field can be fully extracted: document digital signature, bound signature, preset seal image, signature identity credential, transaction identifier, and time identifier. Specifically, the document digital signature is encrypted verification data generated based on the document's content feature values; the bound signature is encrypted verification data generated based on the bound structure; the preset seal image is standardized visual seal image data used in this signing; the signature identity credential is a subject identity verification credential adapted to the signature algorithm system; the transaction identifier is a globally unique tracking code that runs throughout the entire signing process; and the time identifier is a standardized timestamp token issued and authenticated by TSA. This process ensures that all elements required for signature verification can be obtained from the document itself, without relying on external databases, thus providing a data foundation for subsequent offline signature verification.

[0180] The server can use standardized document parsing tools to read data from each field of the signature domain, perform deserialization based on a predefined data structure, and quickly obtain various verification elements. If the signature domain data is stored in encrypted form, the server can restore the data through a compliant decryption mechanism before extracting the elements. Furthermore, for embedded or attachment-based storage of seal images and other data, data can be read using structured node traversal, adapting to different document storage standards. The entire parsing process can independently obtain all verification data from the signed document itself, without relying on external databases, providing reliable data support for offline self-verification.

[0181] 602. Based on the signature verification rules corresponding to the signature algorithms used when generating the document digital signature and binding signature, perform signature verification operations on the document digital signature and binding signature respectively, and obtain the signature verification results;

[0182] Cryptographic operations are used to verify the authenticity and validity of signatures.

[0183] Verification rules are the verification methods corresponding to the signature algorithm. Different signature algorithms correspond to different verification rules. For example, the SM2 elliptic curve public key cryptography algorithm corresponds to the SM2 verification algorithm, and the SM9 identifier cryptography algorithm corresponds to the SM9 verification algorithm.

[0184] First, the public key information is parsed from the extracted signature identity credential. In the SM2 scenario, this is the public key in the public key certificate; in the SM9 scenario, it is the system's public parameters. Then, this public key is used to perform verification operations on the document's digital signature and the bound signature. For the document's digital signature, it is verified whether it corresponds to the content in the document to be verified, excluding the signature field. For the bound signature, it is verified whether it corresponds to the bound structure data reconstructed in subsequent steps. The verification operation outputs a Boolean value or status code indicating whether the signature has passed cryptographic verification. This step confirms that the signature was indeed generated by the signing subject holding the private key and that the data has not been tampered with during transmission or storage, thus ensuring the authenticity of the signature's origin and the integrity of the data.

[0185] The server can call the signature verification interface of the password management module (such as a key management service or hardware cryptographic machine) to complete the signature verification operation. The public key corresponding to the signature verification private key is managed by the password management module. The server also performs signature verification calculations locally using the public key.

[0186] The signature verification result is a Boolean value or status code indicating whether the signature is valid. If both the document's digital signature and the bound signature pass verification, the signature verification result indicates success; if either signature verification fails, the signature verification result indicates failure.

[0187] 603. Calculate the verification feature value of the content outside the signature field in the document to be verified and the feature value of the current seal image;

[0188] Obtain the feature value of the object to be verified, and compare it with the original signature data.

[0189] The verification feature value can refer to the hash value calculated from the current document content. The calculation process is consistent with the calculation of the feature value of the content to be signed. First, all content data outside the signature field in the document to be verified is extracted, ensuring that the extracted range is completely consistent with the range during signing. Then, the content is hashed using the same preset hash algorithm (such as the SM3 algorithm) as in the signing stage to obtain the verification feature value. This verification feature value can be the digest value of the content of the area to be signed. For the feature value of the current seal image, the byte data of the seal image is extracted from the document to be verified, and its hash value is calculated using the same preset hash algorithm. The calculation of these two feature values ​​simulates the data processing process during signing and is the key basis for determining whether the document content and seal image have been tampered with.

[0190] If the document to be verified and signed is modified after it is generated, or if the seal image is replaced, the calculated feature value will not match the original value.

[0191] 604. Based on the verification feature value, the feature value of the current seal image, and the extracted signature identity certificate, transaction identifier, and time identifier, reconstruct the binding structure;

[0192] This step strictly replicates the structure construction rules of the signature stage, reconstructs the complete binding structure based on the latest data of the current verification document, and uses it to compare the consistency with the original binding structure to verify the integrity of the binding relationship of multi-dimensional signature elements.

[0193] Reconstructing the binding structure involves assembling the various data units obtained earlier according to specific data structure rules. The binding structure is the original data packet used to generate the binding signature, and the reconstruction process strictly follows the structure definition defined at the time of generation.

[0194] The verification feature value (corresponding to the original document content feature value), the feature value of the current seal image, the signature identity credential, the transaction identifier, and the time identifier are used as fields to populate the binding structure. The data structure rules used to reconstruct the binding structure must be completely consistent with those used during signing, including field order, encoding method, and format type.

[0195] For example, standardized structured coding rules can be used to define and encapsulate the binding structure. During reconstruction, the field definitions and order of the signing phase must be strictly followed to ensure complete matching of data organization rules. The reconstructed binding structure will serve as the verification object for consistency comparison. This verification logic can not only independently verify that each signature element itself has not been tampered with, but also verify whether the binding relationship between multiple types of elements is complete. It can effectively identify combined attack behaviors such as tampering with single data items and replacing matching element classes.

[0196] In one implementation, the binding structure used during signing is in JSON format, and the same JSON structure is used during reconstruction, with field names and field order remaining consistent. In another possible implementation, the binding structure used during signing is in XML format or Protocol Buffers format, and the corresponding format and rules are used during reconstruction.

[0197] The purpose of reconstructing the binding structure is to generate a data object that should theoretically be completely identical to the original binding structure at the time of signing, for subsequent comparison and verification. If the document content or seal image is tampered with after signing, the reconstructed binding structure will be inconsistent with the original binding structure.

[0198] 605. If the verification result indicates that both the digital signature and the binding signature of the document have passed the verification operation, and the reconstructed binding structure is consistent with the original binding structure used when generating the binding signature, the signed document is determined to be normal; otherwise, the signed document is determined to be abnormal.

[0199] The signature verification passes as a prerequisite for cryptographic verification, proving that both types of digital signatures were generated by legitimate signing entities and that the signature data itself has not been tampered with or forged. The consistency of the binding structure serves as a prerequisite for data consistency verification, proving that the multi-dimensional binding relationships between document content, seal image, signature identity, signing transaction, and signing time are complete and intact, without any violations such as partial replacement or data misalignment. These two conditions are mutually restrictive and complementary, mitigating the vulnerabilities of a single verification method.

[0200] In this context, consistency can mean that the binary encoding of the reconstructed data or the key field values ​​are exactly the same as the original signature data parsed by the verification algorithm.

[0201] The logic for determining the document signing status is based on the AND relationship of two necessary conditions: first, the signature verification at the cryptographic level is successful, that is, both the document digital signature and the binding signature are successfully verified by the public key; second, the comparison at the data consistency level is successful, that is, the reconstructed binding structure is completely consistent with the original binding structure.

[0202] If both of the above conditions are met, it means that the document content has not been tampered with, the seal image has not been replaced, and the binding relationship between the seal and the document is complete and valid. In this case, the signed document is considered normal. If the digital signature verification fails, it means that the document content or the signature identity certificate has been tampered with; if the binding signature verification fails, it means that the binding relationship has been broken; if the reconstructed binding structure is inconsistent with the original structure, it means that although the signature may have passed, the correspondence between the seal and the content has changed, for example, the seal has been replaced but not re-signed.

[0203] In any of the aforementioned anomalies, the signed document is deemed abnormal. This dual verification mechanism ensures the legal validity and tamper-proof capability of the signed document.

[0204] By analyzing the signature field of the document to be verified and signed, six core elements are extracted. Verification operations are then performed on both the digital signature and the bound signature. Finally, based on the feature values ​​of the current document content and the seal image, the bound structure is reconstructed and compared for consistency. These technical processes collaboratively achieve end-to-end verification of the integrity and authenticity of the signed document. The dual verification mechanism ensures the cryptographic strength of the signature itself, while the comparison between the reconstructed bound structure and the original structure effectively mitigates the risk of the seal image being replaced or the document and seal not matching. This verification process only requires the public key information contained within the document itself, without relying on online signature services. Therefore, it can accurately determine the authenticity of a signed document even in an offline environment, meeting the stringent requirements for self-verification and tamper-proofing of electronic documents in long-term archiving and cross-institutional circulation.

[0205] The server can return the judgment result (normal or abnormal) and a detailed verification report to the client. The report includes the result of each verification step, comparison details and the reason for the abnormality.

[0206] The server can also return a simplified signature verification status code, and the client can display the signature verification result based on the status code.

[0207] In this embodiment, the signature field of the signed document is parsed to extract the complete set of verification elements. Adaptive matching of verification rules is used to complete dual signature verification. The document and seal feature values ​​are recalculated, and the binding structure is reconstructed to comprehensively determine the document's authenticity. Employing a dual verification logic of password verification and multi-element association comparison, it can identify both single-content tampering and complex attacks such as seal replacement and element misalignment. Furthermore, it can be verified offline using only the document's built-in data, adapting to the needs of long-term document archiving.

[0208] Figure 7 This is a flowchart illustrating how the digital signature and the bound signature of a document are verified according to the verification rules corresponding to the signature algorithm used when generating the digital signature and the bound signature, and the verification results are obtained. It may include steps 701 to 705, which are described in detail below.

[0209] 701. Extract the algorithm identifier from the signature field. The algorithm identifier includes at least the signature algorithm identifier and is embedded in the signature attribute of the signature field.

[0210] The server reads the algorithm identifier from the parsed signature field attribute. This algorithm identifier is in ASN.1 encoded object identifier form and is used to uniquely identify the parameter set of the signature algorithm, rather than a simple text description.

[0211] An algorithm identifier is a set of identification information used to indicate the type of cryptographic algorithm used in the signing process, and at least includes a signature algorithm identifier. This algorithm identifier may include hash algorithm identifiers, signature algorithm identifiers, encryption algorithm identifiers, etc., and is used to fully describe the algorithm system used for the signature.

[0212] A signature field is a pre-defined, fixed area within a document used to store signature verification data. It contains one or more signature attribute fields to store metadata information related to the signature. The algorithm identifier is embedded in these signature attributes and is persistently stored as part of the signature metadata.

[0213] In practical applications, the algorithm identifier must at least include a signature algorithm identifier, such as a specific OID (Object Identifier) ​​used to identify the SM2 or SM9 algorithm. Furthermore, this identifier may also include a hash algorithm identifier and a cryptographic pattern identifier, thus forming a complete algorithm suite description.

[0214] The algorithm identifier can be a custom enumeration value or a string identifier, such as "SM2-SM3" indicating a combination of the SM2 signature algorithm and the SM3 hash algorithm. The server can determine the corresponding signature verification rules by parsing this string identifier. The algorithm identifier can also be embedded in the signature attributes as binary flag bits; different bit combinations represent different algorithm combinations, and the server can parse the specific algorithm type through bitwise operations.

[0215] When parsing the signature field of a document to be verified, the server reads the signature attribute field and extracts the algorithm identifier. If the algorithm identifier is missing or cannot be parsed, the server can attempt to infer the algorithm based on the type of signature credentials, or return an error message indicating that the algorithm is unclear.

[0216] By embedding the algorithm identifier into the signature attribute of the signature field instead of hardcoding it in the code, the signature verification logic can dynamically adapt to the actual algorithm information carried in the document, thus making it compatible with algorithm standards from different periods or business scenarios with different security levels.

[0217] 702. Determine the first verification algorithm corresponding to the document's digital signature and the second verification algorithm corresponding to the bound signature based on the signature algorithm identifier;

[0218] Based on the extracted signature algorithm identifier, the server determines the signature verification algorithm to be used when performing signature verification operations on the digital signature and the bound signature of the document.

[0219] Since both the document digital signature and the binding signature are generated from the same preset signing private key, they typically use the same signing algorithm. Therefore, the first and second verification algorithms can be the same. However, in some implementations, the document digital signature and the binding signature may use different signing algorithms. For example, the document digital signature may use the SM2 algorithm, while the binding signature may use the SM9 algorithm. In this case, the first and second verification algorithms will differ.

[0220] The signature algorithm identifier can directly indicate the signature algorithm type. For example, OID 1.2.156.10197.1.501 indicates the SM2 signature algorithm. Based on this, the server determines that both the first and second verification algorithms are SM2 verification algorithms. The signature algorithm identifier can contain two independent sub-identifiers, which correspond to the signature algorithms of the document digital signature and the binding signature, respectively. The server parses them separately to determine the corresponding verification algorithms.

[0221] Although the same algorithm is typically used to generate the digital signature and binding signature of the document in the current embodiment, by determining the first verification algorithm and the second verification algorithm respectively, the system architecture has the ability to independently process signatures of different algorithm layers, reserving technical interfaces for future expansion or compatibility with hybrid algorithm signature scenarios.

[0222] 703. Extract the signature identity credential from the signature field and determine the verification public key that matches the signature identity credential based on the signature algorithm identifier;

[0223] A signature identity credential is data extracted from the signature field to identify the identity of the signing object; it can be a public key certificate or a user identifier. The server needs to determine how to obtain the verification public key from the signature identity credential based on the signature algorithm identifier.

[0224] When the signature algorithm identifier uses a certificate-based signature algorithm (such as the SM2 elliptic curve public key cryptography algorithm), the signature identity credential is a public key certificate. The server extracts the verification public key from the public key certificate, which is the key data contained in the public key information field of the certificate's body. Before extracting the public key, the server also needs to verify the validity period and the legitimacy of the issuance chain of the public key certificate to ensure that the certificate is valid at the time of signing and was issued by a trusted CA (Certificate Authority).

[0225] When the signature algorithm uses an identifier-based signature algorithm (such as the SM9 identifier cryptography algorithm), the signature identity credential is the user identifier, such as a mobile phone number, email address, ID card number, or unified social credit code. The server derives the verification public key based on the user identifier using the identifier cryptography algorithm. In the SM9 algorithm, the system public parameters and the user identifier jointly determine the user's public key, and the server calculates the corresponding verification public key based on the user identifier and the system master public key.

[0226] The server can call the signature verification public key acquisition interface of the password management module, taking the signature algorithm identifier and signature identity certificate as input parameters, and the password management module will return the corresponding signature verification public key; the server can also perform public key extraction or derivation operations locally to directly obtain the signature verification public key.

[0227] 704. Perform a signature verification operation on the digital signature of the document using the first signature verification algorithm and the signature verification public key to obtain the first signature verification sub-result; perform a signature verification operation on the bound signature using the second signature verification algorithm and the signature verification public key to obtain the second signature verification sub-result;

[0228] The server uses a predetermined first verification algorithm and the obtained verification public key to perform a verification operation on the document's digital signature, obtaining a first verification sub-result. Simultaneously, it uses a second verification algorithm and the verification public key to perform a verification operation on the bound signature, obtaining a second verification sub-result.

[0229] The verification process for a document's digital signature is used to confirm that the feature value of the content in the area to be signed was indeed signed by the corresponding private key and has not been tampered with. This process can be as follows: The server calculates the verification feature value of the content in the area to be signed outside the signature field of the document to be verified. It then uses a first verification algorithm and the verification public key to decrypt or compare the document's digital signature, verifying whether the document's digital signature was generated by signing the verification feature value with the preset signature private key corresponding to the verification public key. If the verification passes, the first verification result is valid; otherwise, it is invalid.

[0230] The signature verification process for bound signatures is used to verify that the current seal image is the original seal affixed during the signature process. This process can be as follows: The server extracts the original bound structure from the signature field, uses the second verification algorithm and the verification public key to decrypt or compare the bound signature, and verifies whether the bound signature was generated by signing the original bound structure with the preset signature private key corresponding to the verification public key. If the verification passes, the second verification result is valid; otherwise, it is invalid. This bound signature verification process can simultaneously verify that metadata such as signature time and transaction records are also complete and intact.

[0231] The server can send the document digital signature and the binding signature to the password management module at the same time, and the password management module can perform two signature verification operations in parallel to improve the verification efficiency. Alternatively, the server can perform two signature verification operations in sequence, first verifying the document digital signature and then verifying the binding signature, so that subsequent operations can be terminated in time if the first signature verification fails, saving computing resources.

[0232] 705. If both the first and second verification results indicate that the signature is valid, the verification result indicates that the verification has passed; otherwise, the verification result indicates that the verification has failed.

[0233] The server combines the results of the first and second signature verifications to arrive at the final signature verification result.

[0234] The signature verification result indicates that the signature has been verified only if both the first and second verification results indicate that the signature is valid. This means that both the document digital signature and the binding signature are verified as valid at the cryptographic level, that is, the document content and the binding structure have not been tampered with, and both have been signed with a legitimate preset signature private key.

[0235] If the first verification result indicates that the signature is invalid, it means that the document's digital signature verification failed, the document content may have been tampered with, or the signature was not generated by the claimed signer. If the second verification result indicates that the signature is invalid, it means that the binding signature verification failed, the binding structure may have been tampered with, or the signature was not generated by the claimed signer. In either case, the verification result indicates that the verification failed.

[0236] The server can record the first and second verification results separately in the verification report so that users can understand the specific reasons for the verification failure. Alternatively, the server can return only a comprehensive verification result without revealing the specific verification details to prevent attackers from using the verification feedback information for further attacks.

[0237] In this embodiment, by introducing algorithm identifiers, the signature verification process can adaptively adapt to different signature algorithm systems. Whether it is a certificate-based signature algorithm or an identifier-based signature algorithm, the signature verification operation can be executed correctly. By performing signature verification operations on the document digital signature and the binding signature separately, a dual verification mechanism is implemented to ensure that the document content and the binding structure have not been tampered with. By combining the results of the two signature verification sub-results, the final signature verification conclusion is obtained, avoiding the security blind spots that may exist in single signature verification, and significantly improving the reliability and security of the signature verification result.

[0238] In one possible implementation, the signature verification public key, which is determined based on the signature algorithm identifier and matches the signature identity credential, includes:

[0239] 1. If the signature algorithm identifier uses a certificate-based signature algorithm, determine that the signature identity credential is a public key certificate; verify the validity period of the public key certificate and the legality of the issuance chain; after successful verification, extract the signature verification public key from the public key certificate;

[0240] Before using the public key within an identified public key certificate for signature verification, a complete certificate validity check must be performed. This is a crucial step in building a trust chain. By checking the NotBefore and NotAfter fields of the certificate, it is confirmed whether the current time is within the certificate's validity period, thus preventing the use of expired or ineffective certificates for signature verification.

[0241] Simultaneously, it can perform certificate chain validity verification, starting from the current certificate and verifying upwards level by level until reaching the trusted anchor (usually the root certificate authority), ensuring that the signature of each superior certificate is valid and has not been revoked. This chain verification mechanism can effectively eliminate the risk of fraud using forged certificates or certificates issued in violation of regulations.

[0242] After confirming that the public key certificate is valid and the issuance chain is complete and legitimate, the specific verification public key is parsed and extracted from the public key information field of the certificate. In the architecture of certificate-based signature algorithms (such as SM2), the verification public key usually exists as the public part of an asymmetric key pair, for example, represented as the coordinates of a point on a curve in elliptic curve cryptography. The extracted verification public key will be directly used in subsequent digital signature verification operations to verify the mathematical correctness of the document's digital signature and binding signature.

[0243] The certificate validity verification also includes checking the revocation status.

[0244] The server can perform revocation checks in one of the following ways: Query the certificate revocation status in real time from the Certificate Authority via OCSP (Online Certificate Status Protocol). OCSP response results include Good, Revoked, or Unknown. Alternatively, download and cache the CRL (Certificate Revocation List), update it periodically, and verify offline whether the certificate's serial number is on the revocation list.

[0245] Possible verification results include: Pass (certificate is valid), Expired (certificate's NotAfter time has expired), Revoked (certificate is in the CRL list or OCSP returns Revoked), Broken certificate chain (intermediate CA or root CA is untrusted), Unknown (OCSP returns Unknown and cannot be found in the CRL), and Certificate usage mismatch (certificate's KeyUsage or ExtKeyUsage does not contain a digital signature).

[0246] 2. If the signature algorithm identifier is represented by an identifier-based signature algorithm, the signature identity credential is determined to be the user identifier, and the signature verification public key is derived from the user identifier using an identifier cryptographic algorithm.

[0247] When the signature algorithm identifier points to an identifier-based cryptosystem (such as the Chinese national cryptographic algorithm SM9), the method of obtaining the signature verification public key is different from that of certificate-based algorithms.

[0248] The signature identity credential embedded in the signature field is no longer a complex digital certificate file, but rather concise information that uniquely identifies the user, such as the email address, mobile phone number, or specific identification string of the signing object. The user identifier of the signing object not only serves as a representation of identity, but also directly participates in the public key generation process in the identity cryptographic algorithm system, enabling users to establish encryption or signature verification channels without having to apply for and exchange digital certificates in advance.

[0249] After determining that an identifier-based signature algorithm should be used, the public key for signature verification corresponding to the user identifier is dynamically calculated or derived based on the extracted user identifier and the specific mathematical parameters of the identifier cryptography algorithm and the master key parameters.

[0250] Taking the SM9 algorithm as an example, its signature verification public key can be generated in real time using the system's master public key and the user identifier as input, through a specific mapping function and dot product operation. This identifier-derived public key technique eliminates the overhead of certificate transmission and storage, greatly simplifies the key management process, and ensures that the correct private key can only be generated when the system's master key is known. Thus, while simplifying the process of obtaining the signature verification public key, it maintains the security of the cryptographic system.

[0251] In this embodiment, by determining the type of the signature algorithm identifier, two cases are handled separately: certificate-based signature algorithms and identifier-based signature algorithms. For certificate-based signature algorithms, the public key certificate is extracted from the signature field, and its validity period and the legitimacy of the issuance chain are verified before extracting the verification public key. For identifier-based signature algorithms, the user identifier is extracted from the signature field, and the verification public key is derived through an identifier cryptographic algorithm. This achieves unified support for obtaining verification public keys for different signature algorithm systems. By distinguishing between certificate-based and identifier-based scenarios, the signature verification system can flexibly adapt to different cryptographic infrastructures, expanding the applicability of this solution and balancing security and convenience.

[0252] The above describes a document electronic signature processing method provided by the embodiments of this application. The following will describe an electronic device that performs the above document electronic signature processing method.

[0253] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device includes: a processor 801 and a memory 802 connected to the processor;

[0254] Memory 802 is used to store computer programs;

[0255] The processor 801 is used to execute computer programs to enable electronic devices to implement the document electronic signature and sealing processing method as described in any one of claims 1-9.

[0256] A processor is the core of an electronic device, responsible for execution of computer program instructions and performing data processing tasks. This processor can be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), or other programmable logic devices. In one possible implementation, the processor employs a multi-core architecture, supporting parallel processing of multiple threads to improve the efficiency of document signing and stamping. In another possible implementation, the processor uses an ARM (Advanced RISC Machine) or x86 architecture to adapt to deployment scenarios with different power consumption and performance requirements.

[0257] Memory is a component in electronic devices used to store data and programs, and it is connected to the processor via a bus or other communication interface. This memory can include volatile memory and non-volatile memory. Volatile memory, such as RAM (Random Access Memory), is used for temporary storage of running programs and data, providing high-speed read and write capabilities; non-volatile memory, such as ROM (Read Only Memory), flash memory, SSD (Solid State Drive), or HDD (Hard Disk Drive), is used for long-term storage of computer programs and static data.

[0258] In one possible implementation, the electronic device may further include a communication interface for network communication with clients or other servers, receiving original documents to be signed and sending signed documents. The communication interface may be a wired network interface (such as an Ethernet interface) or a wireless network interface (such as Wi-Fi (Wireless Fidelity) or a mobile communication interface). In another possible implementation, the electronic device may further include a cryptographic management module, which may be a cryptographic coprocessor integrated within the processor, or a separate security chip or hardware cryptographic machine (HSM), for securely storing preset signing private keys and performing signing operations.

[0259] In another possible implementation, the electronic device may also include a stamp management library for storing and managing preset stamp image data, which may be implemented based on a database system in memory.

[0260] Electronic devices can take the form of servers, workstations, personal computers, embedded devices, or cloud computing nodes. Specifically, electronic devices can be high-performance servers deployed in data centers, equipped with multi-core processors and large-capacity memory to support high-concurrency document signing requests; electronic devices can also be edge computing nodes deployed at the network edge close to users to reduce network latency and provide real-time signing services; and electronic devices can also be virtualized instances running on cloud platforms, dynamically adjusting computing resources based on load.

[0261] In this embodiment, by integrating the document electronic signature and sealing processing method into the electronic device, the device possesses complete document electronic signature and sealing capabilities, enabling it to independently complete the entire process from document reception, feature value calculation, dual signature, binding structure construction to signed document generation. Furthermore, due to the inherent security design of the document electronic signature and sealing processing method, the electronic device offers high security and reliability when providing sealing services, effectively preventing attacks such as document content tampering and seal image replacement. This electronic device can be widely applied in scenarios such as electronic contract signing, government document circulation, and electronic certificate issuance, demonstrating significant practicality and promotional value.

[0262] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the document electronic signature processing methods provided in this application.

[0263] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the document electronic signature and sealing methods provided in this application.

[0264] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0265] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application program, server, or storage medium executing the operation of this invention, based on the prompt message.

[0266] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

Claims

1. A method for processing electronic signatures and seals on documents, characterized in that, Applied to the server side, including: Determine the feature values ​​of the content in the area to be signed in the original document; A digital signature of the document is generated by signing the feature value of the content in the area to be signed based on a preset signature private key. A binding structure is constructed based on the feature values ​​of the preset seal image and the feature values ​​of the content of the area to be signed; The binding structure is signed using the preset signature private key to generate a binding signature; The document digital signature, the bound signature, and the preset seal image are embedded into the signature field of the original document to generate a signed document.

2. The document electronic signature and sealing processing method according to claim 1, characterized in that, The process of determining the feature values ​​of the content of the area to be signed in the original document includes: Receive the original document to be signed uploaded by the client; The original document is parsed and pre-defined signature fields within the document are identified; Extract the content data of the area to be signed from the original document, excluding the signature field; A first digest value of the content to be signed is calculated using a preset hash algorithm, and the first digest value is used as the feature value of the content to be signed.

3. The document electronic signature and sealing processing method according to claim 1, characterized in that, The step of signing the feature value of the content to be signed based on a preset signing private key to generate a document digital signature includes: Obtain the identity information of the signature object; Based on the identity information of the signing object, the access permission to call the preset signing private key corresponding to the signing object is obtained from the password management module of the server. The password management module can be either a key management service or a hardware cryptographic machine, and the preset signing private key is stored inside the password management module. The feature value of the content to be signed is sent to the password management module to call the built-in signature interface of the password management module. The signature interface is used to call the preset signature private key to complete the signature operation and generate a digital signature for the document.

4. The document electronic signature and sealing processing method according to claim 3, characterized in that, The construction of the binding structure based on the feature values ​​of the preset seal image and the feature values ​​of the content of the area to be signed includes: Based on the identity information of the signature object, the signature identity credential corresponding to the signature object is obtained from the password management module of the server. The type of the signature identity credential is adapted to the preset signature algorithm. The signature identity credential includes a public key certificate or a user identifier. Determine the preset seal image corresponding to the signature object and seal position of the original document; Obtain the image data of the preset seal image from the seal management library on the server; The image data of the preset seal image is hashed using the preset hash algorithm to obtain the feature value of the preset seal image. A binding structure is constructed based on the feature values ​​of the content of the area to be signed, the feature values ​​of the preset seal image, and the signature identity certificate.

5. The document electronic signature and sealing processing method according to claim 4, characterized in that, After calculating the feature value of the content of the area to be signed using a preset hash algorithm, the method further includes: Generate a globally unique transaction identifier for this signature and seal, which is used to associate with the entire process log of this signature and seal; Obtain a timestamp token as a time identifier for this signature / signature. Accordingly, the construction of the binding structure includes: A binding structure is constructed based on the feature values ​​of the content to be signed, the feature values ​​of the preset seal image, the signature identity certificate, the transaction identifier, and the time identifier.

6. The method for processing electronic signatures and seals on documents according to claim 5, characterized in that, The construction of the binding structure is executed after the generation of the document digital signature, and the generation of the binding signature is executed immediately after the construction of the binding structure; The generation of the document digital signature, the construction of the binding structure, and the generation of the binding signature are completed continuously as a single atomic transaction in the same processing flow, without any external operation intervention or interruption.

7. The method for processing electronic signatures and seals on documents according to claim 5, characterized in that, After generating the signed document, the process also includes: Parse the signature field of the document to be verified and signed to obtain the document digital signature, bound signature, preset seal image, signature identity certificate, transaction identifier, and time identifier carried by the signature field; According to the verification rules corresponding to the signature algorithm used when generating the document digital signature and the binding signature, the verification operation is performed on the document digital signature and the binding signature respectively to obtain the verification result; Calculate the verification feature value of the content in the area outside the signature field in the document to be verified and the feature value of the current seal image; Based on the verification feature value, the feature value of the current seal image, and the extracted signature identity certificate, transaction identifier, and time identifier, the binding structure is reconstructed; If the verification result indicates that both the digital signature and the binding signature of the document have passed the verification operation, and the reconstructed binding structure is consistent with the original binding structure used when generating the binding signature, the signed document is determined to be normal; otherwise, the signed document is determined to be abnormal.

8. The method for processing electronic signatures and seals on documents according to claim 7, characterized in that, The step of performing verification operations on the document digital signature and the bound signature respectively according to the verification rules corresponding to the signature algorithm used when generating the document digital signature and the bound signature, and obtaining the verification result, includes: Extract the algorithm identifier from the signature field, wherein the algorithm identifier includes at least a signature algorithm identifier and is embedded in the signature attribute of the signature field; Based on the signature algorithm identifier, a first verification algorithm corresponding to the document digital signature and a second verification algorithm corresponding to the bound signature are determined; Extract the signature identity credential from the signature field, and determine the verification public key that matches the signature identity credential based on the signature algorithm identifier; The first signature verification algorithm and the signature verification public key are used to perform a signature verification operation on the digital signature of the document to obtain a first signature verification result; the second signature verification algorithm and the signature verification public key are used to perform a signature verification operation on the bound signature to obtain a second signature verification result. If both the first and second signature verification results indicate that the signature is valid, then the signature verification result indicates that the signature verification has passed; otherwise, the signature verification result indicates that the signature verification has failed.

9. The method for processing electronic signatures and seals on documents according to claim 8, characterized in that, The step of determining the verification public key that matches the signature identity credential based on the signature algorithm identifier includes: If the signature algorithm identifier represents a certificate-based signature algorithm, the signature identity credential is determined to be a public key certificate; the validity period and issuance chain of the public key certificate are verified; after successful verification, the signature verification public key is extracted from the public key certificate; If the signature algorithm identifier is represented by an identifier-based signature algorithm, the signature identity credential is determined to be a user identifier, and a verification public key is derived based on the user identifier using an identifier cryptographic algorithm.

10. An electronic device, characterized in that, include: The processor and the memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the document electronic signature and sealing processing method as described in any one of claims 1-9.

Images