PDF signature document generation and verification method, storage medium and electronic equipment

Abstract

The invention relates to the technical field of electronic signature, and particularly provides a PDF signature document generation and verification method, a storage medium and electronic equipment, and the method can comprise the steps: determining a to-be-verified original document in a to-be-signed document; calculating the original document to be verified to obtain data to be verified; creating a signature object and signature data description in the to-be-signed document under the condition of confirming that the to-be-verified data is the same as the document data of the original document, and signing the signature object and the signature data description to obtain a signed document; wherein the document data is determined after a plurality of users respectively calculate the original document and confirm that calculation results are consistent. According to some embodiments of the invention, the security of PDF document signature and the reliability of signature document verification can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of electronic signatures, and in particular to a method, storage medium and electronic device for generating and verifying a PDF signature document. Background Art

[0002] The true intention of the signing behavior is an important component of the effectiveness of the signed document. One of the conditions for a reliable electronic signature is that any changes to the content and form of the data message after signing can be discovered.

[0003] Currently, in the scenario of multiple people signing electronically in parallel, the object of each signatory's signing intention is the original document. However, during the transmission of the original document, the document data may be lost or maliciously tampered with by others, resulting in the documents reviewed by different signatories being inconsistent with the original document to be signed. Moreover, it is impossible to locate abnormal data in the document during the subsequent retrospective verification of the signed document.

[0004] Therefore, how to provide a technical solution for a method of generating and verifying a PDF signature document with higher security has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The purpose of some embodiments of the present application is to provide a method, storage medium and electronic device for generating and verifying a PDF signed document. The technical solutions of the embodiments of the present application can improve the signature security of the PDF signed document, and can also realize retrospective verification of the integrity of the signed document, which is highly practical.

[0006] In a first aspect, some embodiments of the present application provide a method for generating a PDF signed document, comprising: determining an original document to be verified in a document to be signed; calculating the original document to be verified to obtain data to be verified; when confirming that the data to be verified is the same as the document data of the original document, creating a signature object and a signature data description in the document to be signed, and signing the signature object and the signature data description to obtain a signed document; wherein the document data is determined after multiple users respectively calculate the original document and confirm that the calculation results are consistent.

[0007] Some embodiments of the present application compare and verify the data to be verified of the original document to be verified in the document to be signed with the document data of the original document. If the two are the same, a signature object and a signature data description are created in the document to be signed, and the signature is signed to obtain the signed document. Some embodiments of the present application can improve the signature security of PDF signed documents to prevent the original document from being tampered with, and the user's signature intention can be stored through the signature data description.

[0008] In some embodiments, determining the original document to be verified in the document to be signed includes: if there is no signature in the document to be signed, using the original document to be signed as the original document to be verified; if there is a signature in the document to be signed, determining the original document to be verified from the document to be signed.

[0009] Some embodiments of the present application determine the original document to be verified by confirming whether there is a signature in the document to be signed, and can subsequently confirm whether the original document to be verified has been maliciously modified, thereby improving the security of the signature.

[0010] In some embodiments, determining the original document to be verified from the document to be signed includes: parsing the first signature object in the document to be signed to obtain a signature byte array; obtaining a file end offset value based on the signature byte array; searching for a file end flag through the file end offset value to obtain the original document to be verified, wherein the file end flag is the end position of the original document to be verified.

[0011] Some embodiments of the present application determine the file tail offset value through the first signature object in the document to be signed, and then obtain the original document to be verified through the file tail flag, with high accuracy.

[0012] In some embodiments, the signature data description represents the willingness of the user corresponding to the signature object to agree to sign the original document.

[0013] Some embodiments of the present application can clearly indicate the user's willingness to sign through the signature data description.

[0014] In a second aspect, some embodiments of the present application provide a method for verifying a PDF signed document, comprising: confirming that the signature value in a signed document corresponding to an original document passes verification, wherein the signed document is obtained by any one of the method embodiments in the first aspect; performing backtracking verification on the signature data in the signed document to obtain a verification result of the signed document, wherein the verification result indicates whether the signed document is valid.

[0015] Some embodiments of the present application first verify the signature value of the signed document and then perform retroactive verification to obtain a verification result of whether the signed document is valid, thereby realizing retroactive verification of the integrity of the signed document and ensuring the authenticity and accuracy of the signed document.

[0016] In some embodiments, the signature data in the signed document is retroactively verified to obtain the verification result of the signed document, including: traversing the file tail flag in the signed document to obtain the incremental update data and the file tail offset value array in the signed document; traversing all signature objects in the signed document to obtain the file tail offset value to be verified for each signature object; determining the array item type of the incremental update data by comparing the file tail offset value to be verified with the file tail offset value array, and the array item type includes: electronic signature type and incremental modification type; based on the array item type and the original document consistency result in the signed document, determining the verification result, wherein the original document consistency result indicates whether the data to be verified of the document to be signed corresponding to the signed document is consistent with the document data of the original document.

[0017] Some embodiments of the present application obtain the incremental update data and the file tail offset value array by traversing the file tail flag in the signed document, and determine the array item type of the incremental update data by comparing the file tail offset value in the signed document with the file tail offset value array, thereby obtaining the verification result. This method can timely detect whether the signed document has been tampered with, and realize effective retrospective verification of the signed document, which is highly practical.

[0018] In some embodiments, the array item type of the incremental update data is determined by comparing the file tail offset value to be verified with the file tail offset value array, including: if the file tail offset value to be verified is consistent with the offset value in the file tail offset value array, then the array item type is the electronic signature type; if the file tail offset value to be verified is inconsistent with the offset value in the file tail offset value array, then it is determined that the incremental modification type exists in the incremental update data.

[0019] Some embodiments of the present application determine the array item type in the incremental update data by the consistency between the end offset value of the file to be verified and the offset value in the file end offset value data group, thereby achieving effective judgment on whether there is malicious incremental modification in the signed document.

[0020] In some embodiments, the verification result is determined based on the array item type and the original document consistency result in the signed document, including: when the array item types of the incremental update data are all the electronic signature types, and the original document consistency result is consistent, the verification result is that the signed document is valid; when the incremental modification type exists in the array item type of the incremental update data, and / or the original document consistency result is inconsistent, the verification result is that the signed document is invalid.

[0021] Some embodiments of the present application can quickly determine whether a signed document is valid by incrementally updating the array item type in the data.

[0022] In some embodiments, the method further includes: displaying content data corresponding to different array item types in the signed document; and / or locating an abnormal user who signed the signed document through the document data corresponding to the different array item types.

[0023] Some embodiments of the present application can display the content data of a signed document when the signed document is invalid and locate the abnormal user, thereby facilitating the discovery of malicious signatures and ensuring the integrity of the document traceability chain of evidence.

[0024] In some embodiments, the array items corresponding to the incremental modification type include: an array item between two adjacent electronic signature types, an array item after the last electronic signature type in the signed document, and an array item between the original document and the first electronic signature type in the signed document.

[0025] On the third aspect, some embodiments of the present application provide a device for generating a PDF signed document, comprising: a determination module, used to determine the original document to be verified in the document to be signed; a calculation module, used to calculate the original document to be verified to obtain the data to be verified; a signing module, used to confirm that the data to be verified is the same as the document data of the original document, create a signature object and a signature data description in the document to be signed, and sign the signature object and the signature data description to obtain the signed document; wherein the document data is determined after multiple users calculate the original document separately and confirm that the calculation results are consistent.

[0026] In a fourth aspect, some embodiments of the present application provide a device for verifying a PDF signed document, comprising: a first verification module, used to confirm that the signature value in a signed document corresponding to the original document has passed the verification, wherein the signed document is obtained by any one of the method embodiments in the first aspect; a second verification module, used to perform retroactive verification on the signature data in the signed document to obtain a verification result of the signed document.

[0027] In a fifth aspect, some embodiments of the present application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the method described in any embodiment of the first aspect.

[0028] In a sixth aspect, some embodiments of the present application provide an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement a method as described in any embodiment of the first aspect.

[0029] In a seventh aspect, some embodiments of the present application provide a computer program product, wherein the computer program product comprises a computer program, wherein the computer program, when executed by a processor, can implement the method described in any embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of some embodiments of the present application, the drawings required for use in some embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0031] Figure 1 A schematic diagram of the signing process in a countersigning scenario provided for some embodiments of the present application;

[0032] Figure 2 A system diagram for generating and verifying PDF signature documents provided in some embodiments of the present application;

[0033] Figure 3 A flowchart of a method for generating a PDF signature document provided in some embodiments of the present application;

[0034] Figure 4 A flowchart of a method for verifying a PDF signature document provided in some embodiments of the present application;

[0035] Figure 5 A schematic diagram of a document backtracking mechanism provided for some embodiments of the present application;

[0036] Figure 6 A schematic diagram of the specific process of PDF signature document generation and verification provided in some embodiments of the present application;

[0037] Figure 7 A block diagram of the device composition for generating a PDF signature document provided in some embodiments of the present application;

[0038] Figure 8 A block diagram of the device composition for PDF signature document verification provided in some embodiments of the present application;

[0039] Fig. 9 A schematic diagram of an electronic device is provided for some embodiments of the present application. DETAILED DESCRIPTION

[0040] The technical solutions in some embodiments of the present application will be described below in conjunction with the drawings in some embodiments of the present application.

[0041] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0042] In the related art, for the electronic signature application of PDF documents, the signature specification requires that the signature of the document be appended in an incremental update manner to form a hierarchical inclusion relationship. In actual application, there are a series of attack vulnerabilities and security risks. For example, for the scenario of joint approval (multiple people stamping in parallel), the incompatibility of business processes and signature specifications leads to an increase in the complexity of document circulation. The object of each signatory's signing intention is the original document, but in the process of document circulation, due to unintentional behavior or malicious attacks, it is very likely that the review document and the document to be signed will be inconsistent, such as: preprocessing of the document processing program, data loss caused by unreliable transmission, malicious modification by external middlemen, etc. In the process of signature implementation, the document content is changed by maliciously writing non-signature-related data information. In the approval signature process, the later the signer's node order, the greater the risk as the circulation chain becomes longer and the document protection scope increases. Moreover, it is currently impossible to achieve complete behavior backtracking of archived files. For signature archived files with long-term storage requirements, in the absence of the original document, it is impossible to achieve complete document backtracking, and it is impossible to prove the responsibility for disputes caused by document content.

[0043] by Figure 1 Take the signing process in the joint signing scenario as an example. When the original document T is distributed to users A, B, and C at the same time, all users agree that the signed data is the original document T. However, in the actual signing process, B's signature content includes the original document T and the signature increment of user A; in turn, C's signature content includes the original document T, the signature increment of user A, and the signature increment of user B. Among them, the attack behaviors in the file distribution and signing process include: 1) tampering with the original document. Figure 1 Example b in the example made incremental modifications to the document before signing, and example c tampered with or rewrote the document before signing; 2) Malicious injection in the signing process. Example d and example e maliciously injected non-signature related information into the signing process of the pre-signature node A and the intermediate signature node B respectively. The above situations may lead to modifications in the display of the original document, changes in the meaning of the content, and the electronic signature is valid during document verification, and the true intention of the subsequent signer is not correctly expressed.

[0044] In addition, the prior art also discloses a method in which each signing object signs a document in parallel and then seals the document after all the objects sign it. However, although this parallel signing method solves the convenience problem of parallel signing in business, it has greater security risks. That is, any modification to the incremental update content outside the protection scope of any signature, such as modifying the signing time, will pass the verification. The existing backtracking method has an opaque implementation mechanism and there are gaps in the backtracking chain. For example, when verifying archived files that require long-term storage, signature A and previous nodes (for example b, c, d) cannot be reviewed without saving the original document.

[0045] It can be seen from the above-mentioned related technologies that in the application process of PDF electronic signatures, the security of the signatures is relatively low, and there are problems such as the signer's signing intention is not clear enough, document tampering is not easy to detect, and once the tampered document is signed, the document traceability evidence chain is incomplete.

[0046] In view of this, some embodiments of the present application provide a method for generating and verifying a PDF document signature document, in which the original document to be verified in the signature document is compared with the locked data of the original document (as a specific example of document data) to confirm that the two are consistent; then a signature object and a signature data description are created in the document to be signed to obtain a signature document. By solidifying the signer's intention (i.e., the signature data description) containing the locked data within the scope of the signature protection, the intention of the signature behavior is recorded. When verifying the signed document, the data status and display content of each stage of the signed document are clarified through the document backtracking mechanism. The user clarifies the true intention of the signature, avoiding problems caused by technical rules. At the same time, the various processing nodes of the document can be traced back during verification, and finally a complete chain of evidence is formed.

[0047] The following is combined with Figure 2 The overall structure of the system for generating and verifying PDF signature documents provided by some embodiments of the present application is exemplified.

[0048] like Figure 2 As shown, some embodiments of the present application provide a system for generating and verifying a PDF signature document, which may include a service platform 100 and multiple user terminals 200, such as Figure 2The first user terminal 210, the second user terminal 220 and the third user terminal 230 shown in FIG. Among them, the business platform 100 can distribute the original document that needs to be signed to multiple user terminals 200. After the first user terminal 210, the second user terminal 220 and the third user terminal 230 review and confirm the original document, the users of the three user terminals can sign the original document in a certain order (the order is not fixed), obtain the final signed document and send it to the business platform 100. The business platform 100 can subsequently use the document backtracking mechanism to verify the signed document to confirm whether the signed document is valid.

[0049] In some embodiments of the present application, the number of user terminals 200 can be flexibly set according to the number of signatories (that is, users) in the actual application scenario, and the embodiments of the present application are not limited thereto. The user terminal 200 can be a mobile terminal or a non-portable computer terminal, and the embodiments of the present application are not specifically limited thereto.

[0050] In some embodiments of the present application, before the user terminals 200 perform electronic signatures respectively, the business platform 100 first distributes the original document to the first user terminal 210, the second user terminal 220 and the third user terminal 230 at the same time. After that, after the users of the first user terminal 210, the second user terminal 220 and the third user terminal 230 review the original document respectively, if each user approves the content of the document, the locking data (as a specific example of document data) is generated for the original document based on the consensus algorithm (for example, the hash algorithm) and transmitted back to the business platform 100. If the business platform 100 confirms that the locking data transmitted back by the three user terminals are the same, it is considered that the reviewed original documents are consistent, and a consensus on the signing intention is reached, and the subsequent signing operation is continued; if the locking data are not all the same, the subsequent process is interrupted. The locking data is used as a data benchmark for matching and verification during the signing and verification process, and is stored in the original document as a signature intention.

[0051] It should be noted that in addition to the hash algorithm, the data locking mechanism for the original document based on the consensus algorithm can also be replaced by other data integrity protection methods such as digital signatures.

[0052] The following is combined with Figure 3 The implementation process of generating a PDF signature document performed by any user terminal among multiple user terminals 200 provided in some embodiments of the present application is exemplified.

[0053] Please see attached Figure 3 , Figure 3 A flowchart of a method for generating a PDF signature document is provided for some embodiments of the present application. The method for generating a PDF signature document may include:

[0054] S310, determining the original document to be verified in the document to be signed.

[0055] For example, in some embodiments of the present application, by determining the original document to be verified in the document to be signed, the original document to be verified can be matched and verified to prevent the original document from being maliciously modified during the circulation process, thereby ensuring that the document to be signed is consistent with the reviewed document.

[0056] In some embodiments of the present application, S310 may include: if there is no signature in the document to be signed, using the original document to be signed as the original document to be verified; if there is a signature in the document to be signed, determining the original document to be verified from the document to be signed.

[0057] For example, in some embodiments of the present application, a data stream of a PDF document to be signed (i.e., a document to be signed) is loaded, the PDF document to be signed is parsed, and then the number of signatures in the document to be signed is obtained. If there is no signature in the document to be signed, the entire document is used as the original document to be verified. If there is a signature in the document to be signed, the original document to be verified is determined therefrom.

[0058] In some embodiments of the present application, S310 may include: parsing the first signature object in the document to be signed to obtain a signature byte array; obtaining a file end offset value based on the signature byte array; searching for a file end flag through the file end offset value to obtain the original document to be verified, wherein the file end flag is the end position of the original document to be verified.

[0059] For example, in some embodiments of the present application, the first signature object Annot in the document to be signed is parsed, the ByteRange array in the signature value object / V is obtained (as the signature byte array), the last two elements of the ByteRange array are added, and the file tail offset value of the first signature object is obtained. Then, the file tail flag %%EOF is searched in reverse order, and the data corresponding to the file tail offset value is used as the original document to be verified. Alternatively, after obtaining the file tail offset value of the first signature object, the file tail flag of the original document to be verified is directly located through a preset program to obtain the original document to be verified. Among them, ByteRange represents the exact byte range of the hash calculation during the signing process.

[0060] S320, calculating the original document to be verified to obtain data to be verified.

[0061] For example, in some embodiments of the present application, the same algorithm as that used in the calculation of the locked data is used to calculate the original document to be verified to obtain the data to be verified. The data to be verified is compared with the locked data. If the two are consistent, the verification passes. Otherwise, the verification fails and the signature process is exited.

[0062] S330, when confirming that the data to be verified is the same as the document data of the original document, a signature object and a signature data description are created in the document to be signed, and the signature object and the signature data description are signed to obtain a signed document. The signature data description represents the willingness of the user corresponding to the signature object to sign the original document.

[0063] For example, in some embodiments of the present application, when the data to be verified and the locked data are the same, a signature object Annot of the user is created in the document to be signed, and a description of the intention (as a specific example of the signature data description) containing the locked data of the original document is written in the reason attribute / Reason in the path: signature value object / V. The description of intention indicates that the user agrees to sign the content as the original document. The description of intention may also include other content. For example, the storage content may be further improved in combination with evidence requirements at the level of judicial appraisal. Afterwards, the signature object Annot and the description of intention are signed to obtain the signature value and stored in the document to be signed, thereby obtaining the signed document.

[0064] It should be understood that after multiple user terminals 200 complete signing of the document to be signed, a final signed document is generated. It is understandable that, although the above is an explanation of the implementation process of signing a document by any user terminal, in actual application, if the signing is performed in the order of the first user terminal 210, the second user terminal 220 and the third user terminal 230, the signed document obtained by the first user terminal 210 according to the above implementation process is the document to be signed by the second user terminal 220, and the signed document obtained by the second user terminal 210 according to the above implementation process is the document to be signed by the third user terminal 220. The signed document obtained by the third user terminal 230 according to the above implementation process is the final signed document used for subsequent archiving and verification.

[0065] The following is combined with Figure 4 The specific process of PDF signature document verification performed by the business platform 100 provided in some embodiments of the present application is exemplified.

[0066] Please see attached Figure 4 , Figure 4 A flow chart of a method for verifying a PDF signed document is provided for some embodiments of the present application. The method for verifying a PDF signed document may include: S410, confirming that the signature value in the signed document corresponding to the original document has passed the verification; S420, performing back-verification on the signature data in the signed document to obtain a verification result of the signed document, wherein the verification result indicates whether the signed document is valid.

[0067] For example, in some embodiments of the present application, multiple user terminals 200 are connected in sequence according to Figure 3The method embodiment shown generates a PDF signed document after signing the original document. Then, the PDF signed document data stream is loaded and parsed, and then the signature value in the signed document is verified. After the verification is passed, the signed document is verified using the document backtracking mechanism to confirm whether the signed document is valid. Figure 5 The dotted part of the electronic signature part in the document traceability mechanism diagram shown in is the storage location of the signature value.

[0068] The implementation principle of the document backtracking mechanism is to use the PDF file tail flag %%EOF, the signature field flag / Sig and the ByteRange protection range in the electronic signature object, combined with the stored lock data Hash (T), to clearly divide each incremental update data of the signature document into original document, incremental modification, electronic signature and other types, combined with the business flow chain, as shown below: Figure 5 The status of the signed document at each node in the document traceability mechanism diagram shown. Among them, ByteRange represents the signature range of the three signature objects, signature A, signature B, and signature C (which can be understood as the signatures of the users corresponding to the first user terminal 210, the second user terminal 220, and the third user terminal 230 mentioned above). 100 yuan is the content in the original document.

[0069] The above process is explained below as an example.

[0070] In some embodiments of the present application, S420 may include:

[0071] S421, traverse the file end flag in the signed document to obtain the incremental update data and the file end offset value array in the signed document.

[0072] For example, in some embodiments of the present application, by traversing the file end flag %%EOF in the signed document, all incremental update segments in the signed document are obtained (as a specific example of incremental update data), the file end offset value is recorded, and stored as a structure array (as a specific example of a file end offset value array). Among them, the structure array can also include: sequence number, file end flag offset value, array item type (original text, electronic signature, incremental modification, etc.) and backtracking description related content, etc. It can also include other data, such as document modification time, if it is an electronic signature type, it can include signer information, etc.

[0073] S422, traverse all signature objects in the signature document to obtain the tail offset value of the file to be verified for each signature object.

[0074] For example, in some embodiments of the present application, all signature objects in the signature document are traversed according to the signature field / AcroForm and the signature object / Sig, and the tail offset value of the file to be verified corresponding to each signature object is calculated using the last two digits of the / ByteRange array in the signature value object / V in each signature object.

[0075] S423, determining the array item type of the incremental update data by comparing the end offset value of the file to be verified with the file end offset value array, the array item type including: electronic signature type and incremental modification type.

[0076] For example, in some embodiments of the present application, the tail offset value of the file to be verified corresponding to each signature object is compared with the tail offset value of the file in the structure array to determine the type of array item in the incremental update segment.

[0077] In some embodiments of the present application, S423 may include: if the end offset value of the file to be verified is consistent with the offset value in the file end offset value array, then the array item type is the electronic signature type; if the end offset value of the file to be verified is inconsistent with the offset value in the file end offset value array, then it is determined that the incremental modification type exists in the incremental update data.

[0078] For example, in some embodiments of the present application, Figure 5 As can be seen from the document backtracking mechanism diagram shown, Figure 5 The signature document shown contains six file tail flags %%EOF. If the file tail offset value to be verified is consistent with the file tail offset value array, the array item corresponding to the file tail offset value to be verified is the electronic signature type. If there is an inconsistency, it is confirmed that there is an incremental modification type (that is, malicious tampering content) in the incremental update segment.

[0079] For example, Figure 5 For example, after obtaining the file tail offset value array of the six file tail flags %%EOF and the three file tail offset values ​​to be verified for the three signature objects, the three file tail offset values ​​to be verified are compared with the file tail offset value array to locate the array items corresponding to the three electronic signature types. Then, the array item corresponding to the original document is located by locking the data. Then, the array items corresponding to the six file tail flags %%EOF are judged one by one to confirm whether there is an incremental modification type. It can be understood that under normal circumstances, the results of comparing the three file tail offset values ​​to be verified with the file tail offset value array are the same, and when the number of file tail offset values ​​after the original document in the file tail offset value array is consistent with the number of signatures, the signature document only contains the electronic signature type.

[0080] When determining the original document in a signed document, if there are one or more array items before the first electronic signature type (which can be understood as there are multiple file end flags before the first electronic signature), the verification value of the document content corresponding to different array items in the entire document can be calculated based on the file end offset value, and the verification value can be compared with the locked data to determine the position of the original document in the corresponding array item.

[0081] Specifically, the array items corresponding to the incremental modification type include: the array items between two adjacent electronic signature types, the array items after the last electronic signature type in the signed document, and the array items between the original document and the first electronic signature type in the signed document.

[0082] For example, Figure 5 As shown, if there is data content between the two electronic signatures, the array item type of the data content is an incremental modification type (i.e. Figure 5 If there is data content after the last electronic signature, the array item type of the data content is the incremental modification type. In addition, the array items before the original document are considered to be part of the original document, and the array items between the file end mark of the original document and the first electronic signature are considered to be the incremental modification type (i.e. Figure 5 The range indicated by the first "incremental modification" in .

[0083] S424, determining the verification result based on the array item type and the original document consistency result in the signed document, wherein the original document consistency result indicates whether the data to be verified of the document to be signed corresponding to the signed document is consistent with the document data of the original document.

[0084] For example, in some embodiments of the present application, the above-mentioned document backtracking mechanism is applied to obtain the verification result by confirming whether the locked data is consistent with the data to be verified in the original document in the signed document (as a specific example of the consistency result of the original document), and whether there is an incremental modification type in the signed document.

[0085] It can be seen that in the verification process, the document status type of the node corresponding to each array item is listed by adding a document backtracking mechanism (that is, the document status at this node is the original document, electronic signature, or incremental modification, etc.), and the consistency of the original document is determined through matching verification. The document backtracking mechanism can be used to timely discover risks in the signing stage and realize the termination of signing; it can also be used to realize post-event evidence only by using archived documents when disputes arise.

[0086] Specifically, S424 may include: when the array item types of the incremental update data are all the electronic signature types, and the consistency result of the original document is consistent, the verification result is that the signed document is valid; when the incremental modification type exists in the array item types of the incremental update data, and / or the consistency result of the original document is inconsistent, the verification result is that the signed document is invalid.

[0087] For example, in some embodiments of the present application, when the consistency result of the original document is consistent and there is no array item of the incremental modification type, the signed document is valid, otherwise the signed document is invalid.

[0088] In some embodiments of the present application, the method further includes: displaying content data corresponding to different array item types in the signed document; and / or locating an abnormal user who signed the signed document through document data corresponding to the different array item types.

[0089] For example, in some embodiments of the present application, the method can also display the status of each array item node in the signed document, that is, the array item type of each array item, and issue an alarm. In addition, the intention in the signature can be used to describe the storage data, restore all chains of the signed document flow, confirm and locate malicious nodes and corresponding abnormal users (that is, users who maliciously tamper with the document content). For example, when there is an incremental modification type, the incremental modified content data can be displayed; when there is a Figure 5 When the information shown in the figure is that the signatory B maliciously injects 100 yuan to change it into 700 yuan, the abnormal user B can be located through the display.

[0090] In actual application scenarios, the content of the incremental update segment can be further parsed, the types of each array item can be expanded, and a more specific and clear change prompt can be given to the signed document. The embodiment of the present application is not limited to the above method embodiment.

[0091] The following is an example of a specific scenario. Figure 3 and Figure 4 The implementation process of PDF signature document generation and verification is shown.

[0092] For example, in a typical business scenario: users A and B, as peer signature users, jointly sign a certain original document T through the document preview and electronic signature service provided by business platform S (that is, business platform 100). In compliance with the PDF electronic signature technical specifications, it is necessary to clarify each user's intention to sign only the original document T. Business platform S can implement data backtracking based on the signature archive file, and combine the business process to prove the entire document processing process and clarify the behavior of all parties. The specific implementation process in this business scenario includes:

[0093] 1) Business platform S distributes the original document T to signing users A and B. After reviewing and confirming, users A and B lock the document based on the consensus algorithm. If the locking data of users A and B are consistent, business platform S stores the locking data and continues the following process. If they are inconsistent, the subsequent process is terminated;

[0094] 2) The business platform S determines the order of signatures according to the locking time of users A and B, assuming that A signs first and B later. User A signs the original document T according to Figure 3 The signature generation method verifies and stores Hash(T) and generates a signature document Ta. After receiving Ta, user B follows Figure 3 The signature generation method verifies and stores Hash(T) and generates the signature document Tab;

[0095] 3) If after locking the document, the original document T is lost during circulation due to improper handling in the file preprocessing stage, unreliable transmission, or external factors such as external personnel C tampering with or incrementally modifying the original document T, causing T to be changed to Tc, when the signing user A or B performs the electronic signature, through matching verification, it will be found that the data to be verified Hash(Tc) of the original document to be verified ≠ Hash(T), that is, the document to be signed is inconsistent with the original document, and the signing behavior is interrupted;

[0096] 4) If user A, after locking the document, intentionally modifies the data in the electronic signature process through a third-party platform to generate a signed document Ta', and then transmits it back to the business platform S; the electronic signature of the document Ta' is verified to be valid, and if user B does not review it again, he will not be able to find the abnormality of the document, and then sign and generate Ta'b. During the electronic signature verification, user B's signature intention is clearly described as the original document T, and the reading difference between Ta' and T can be located through node backtracking to form evidence, thereby locating the abnormal behavior of user A. At this time, A is an abnormal user;

[0097] 5) Similarly, if the malicious node is user B, for the formed Tab', it can be traced back to find that Ta is consistent with T and has a reading difference with Tab', thereby locating the abnormality of user B's signature data.

[0098] At this point, signing users A and B can clearly express their intention to sign during the signing process. If the original document is modified by external factors as mentioned above, the signing can be terminated through matching verification during the signature document generation stage of the method; for malicious behavior of signing users A or B, a chain of evidence can be formed by tracing back nodes during the verification stage of the signature document.

[0099] The following is combined with Figure 6 The specific process of PDF signature document generation and verification provided by some embodiments of the present application is exemplified. Figure 6As can be seen from the figure, the process of PDF signature document generation and verification includes a review phase, a signature phase, and a verification phase. The method of PDF signature document generation and verification may include:

[0100] The review phase includes:

[0101] In the first step, the business platform distributes document T (that is, the original document) to user A, user B, and user C (as a specific example of multiple user terminals).

[0102] In the second step, user A, user B, and user C perform hash calculations on document T respectively to obtain HASH(A), HASH(B), and HASH(C).

[0103] In the third step, the business platform determines that HASH(A)=HASH(B)=HASH(C), and then stores the locked data of document T.

[0104] The signing phase includes:

[0105] In the fourth step, the document to be signed (that is, the document to be stamped) is sent to user A. User A matches and verifies the data to be verified of the original document to be verified in the document to be signed with the locked data. After the verification is passed, a stamped document Ta is generated.

[0106] In the fifth step, the business platform sends the signed document Ta to user B. User B matches and verifies the data to be verified of the original document to be verified in the signed document Ta with the locked data. After the verification passes, the signed document Tab is generated.

[0107] In the sixth step, the business platform sends the signed document Tab to user C. User C matches and verifies the data to be verified of the original document to be verified in the signed document Tab with the locked data. After the verification passes, the signed document Tabc is generated.

[0108] Among them, Ta, Tab and Tabc all contain locked data.

[0109] The verification phase includes:

[0110] In the seventh step, after the business platform obtains the signed document Tabc, it locates the signed document Ta through backtracking comparison, and then locates the document T.

[0111] It should be noted that there may be multiple attack nodes in the process of document T signature circulation. Through some embodiments of the present application, it is possible to locate the attack node, and form an evidence chain by tracing back the node to achieve accurate positioning of the attack node. Specifically, the specific process of signature document generation and backtracking verification of the signature document can refer to the method embodiment provided above. To avoid repetition, the detailed description is appropriately omitted here.

[0112] Through the consistency confirmation and retroactive verification method of the signed document provided by the above embodiment of the present application, the original document can be locked based on the consensus algorithm during the document review stage to form locked data. In the electronic signature process, the matching verification mechanism and the signature reason mark can be used to effectively prevent tampering during the document circulation process or data loss during the transmission process, and the true intention of the signer can be expressed. At the same time, in the process of electronic signature document verification, the status of each processing stage of the document is retroactively restored, which can effectively locate abnormal nodes, form a complete traceability chain and evidence, and improve the security of electronic signature applications.

[0113] Please refer to Figure 7 , Figure 7 The block diagram of the device for generating a PDF signature document provided by some embodiments of the present application is shown. It should be understood that the device for generating a PDF signature document corresponds to the above method embodiment and can execute each step involved in the above method embodiment. The specific functions of the device for generating a PDF signature document can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0114] Figure 7 The device for generating a PDF signature document includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the device for generating a PDF signature document. The device for generating a PDF signature document includes: a determination module 710, used to determine the original document to be verified in the document to be signed; a calculation module 720, used to calculate the original document to be verified to obtain the data to be verified; a signature module 730, used to create a signature object and a signature data description in the document to be signed when confirming that the data to be verified is the same as the document data of the original document, and obtain a signature document after signing the signature object and the signature data description; wherein the document data is determined after multiple users respectively calculate the original document and confirm that the calculation results are consistent.

[0115] Please refer to Figure 8 , Figure 8 The block diagram of the device for verifying PDF signature documents provided by some embodiments of the present application is shown. It should be understood that the device for verifying PDF signature documents corresponds to the above method embodiment and can execute each step involved in the above method embodiment. The specific functions of the device for verifying PDF signature documents can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0116] Figure 8The device for verifying PDF signature documents includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the device for verifying PDF signature documents, and the device for verifying PDF signature documents includes: a first verification module 810, used to confirm that the signature value in the signature document corresponding to the original document has passed the verification, wherein the signature document is obtained by any method embodiment in the first aspect; a second verification module 820, used to perform back-testing on the signature data in the signature document to obtain the verification result of the signature document.

[0117] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method, and will not be described in detail here.

[0118] Some embodiments of the present application further provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the operations of the method corresponding to any of the above methods provided in the above embodiments.

[0119] Some embodiments of the present application further provide a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operations corresponding to any of the above methods provided in the above embodiments.

[0120] like Fig. 9 As shown, some embodiments of the present application provide an electronic device 900, which includes: a memory 910, a processor 920, and a computer program stored in the memory 910 and executable on the processor 920, wherein the processor 920 can implement a method as described in any of the above embodiments when reading the program from the memory 910 through a bus 930 and executing the program.

[0121] Processor 920 can process digital signals and can include various computing structures, such as complex instruction set computer structure, reduced instruction set computer structure, or a structure that implements a combination of multiple instruction sets. In some examples, processor 920 can be a microprocessor.

[0122] The memory 910 may be used to store instructions executed by the processor 920 or data related to the execution of instructions. These instructions and / or data may include codes for implementing some or all functions of one or more modules described in the embodiments of the present application. The processor 920 of the disclosed embodiment may be used to execute instructions in the memory 910 to implement the method shown above. The memory 910 includes a dynamic random access memory, a static random access memory, a flash memory, an optical memory, or other memory known to those skilled in the art.

[0123] The above description is only an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0124] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0125] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Claims

1. A method for generating a PDF signature document, characterized in that: include: Determine the original document to be verified in the document to be signed; Calculating the original document to be verified to obtain data to be verified; When it is confirmed that the data to be verified is identical to the document data of the original document, a signature object and a signature data description are created in the document to be signed, and after signing the signature object and the signature data description, a signed document is obtained; wherein, the document data is determined after multiple users respectively calculate the original document and confirm that the calculation results are consistent.

2. The method according to claim 1, characterized in that The step of determining the original document to be verified in the document to be signed includes: If there is no signature in the document to be signed, the original document to be signed is used as the original document to be verified; If the document to be signed has a signature, the original document to be verified is determined from the document to be signed.

3. The method according to claim 2, characterized in that The step of determining the original document to be verified from the document to be signed comprises: Parse the first signature object in the document to be signed and obtain the signature byte array; Based on the signature byte array, obtain the file end offset value; The file end flag is searched through the file end offset value to obtain the original document to be verified, wherein the file end flag is the end position of the original document to be verified.

4. The method according to any one of claims 1 to 3, characterized in that The signature data description represents the willingness of the user corresponding to the signature object to sign the original document.

5. A method for verifying a PDF signature document, characterized in that: include: Confirming that the signature value in the signed document corresponding to the original document passes verification, wherein the signed document is obtained by the method of any one of claims 1 to 4; The signature data in the signed document is retroactively verified to obtain a verification result of the signed document, wherein the verification result indicates whether the signed document is valid.

6. The method according to claim 5, characterized in that The backtracking verification of the signature data in the signed document to obtain the verification result of the signed document includes: Traversing the file tail flag in the signed document to obtain the incremental update data and the file tail offset value array in the signed document; Traverse all signature objects in the signature document to obtain the tail offset value of the file to be verified for each signature object; By comparing the tail offset value of the file to be verified with the file tail offset value array, the array item type of the incremental update data is determined, and the array item type includes: electronic signature type and incremental modification type; The verification result is determined based on the array item type and the original document consistency result in the signed document, wherein the original document consistency result indicates whether the data to be verified of the document to be signed corresponding to the signed document is consistent with the document data of the original document.

7. The method according to claim 6, characterized in that The determining the array item type of the incremental update data by comparing the end offset value of the file to be verified with the end offset value array of the file includes: If the end offset value of the file to be verified is consistent with the offset value in the end offset value array, then the array item type is the electronic signature type; If the file tail offset value to be verified is inconsistent with the offset value in the file tail offset value array, it is determined that the incremental modification type exists in the incremental update data.

8. The method according to claim 6 or 7, characterized in that The determining the verification result based on the array item type and the consistency result of the original document in the signed document includes: When the array item types of the incremental update data are all of the electronic signature type, and the consistency result of the original document is consistent, the verification result is that the signed document is valid; When the incremental modification type exists in the array item type of the incremental update data, and / or the original document consistency result is inconsistent, the verification result is that the signed document is invalid.

9. The method according to claim 6 or 7, characterized in that The method further comprises: Displaying content data corresponding to different array item types in the signed document; and / or, The abnormal user who signed the signed document is located through the document data corresponding to the different array item types.

10. The method according to claim 6 or 7, characterized in that: The array items corresponding to the incremental modification type include: an array item between two adjacent electronic signature types, an array item after the last electronic signature type in the signed document, and an array item between the original document and the first electronic signature type in the signed document.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program executes the method according to any one of claims 1 to 10 when executed by a processor.

12. An electronic device, characterized in that: The method comprises a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the computer program executes the method according to any one of claims 1 to 10 when being run by the processor.

Images