Method, computer and program relating to attestation of signer of document

Abstract

Certifications capable of certifying a signer of a document are enabled. A method executed by one or more computers includes a process of acquiring a user DID identifying a signer handwritten to an electronic document, calculating a hash value representing a document file of the electronic document handwritten by the signer, and calculating a hash value of the document file of the electronic document handwritten by the signer. And generating a certificate containing the user DID and the hash value of the document file.

Description

Technical Field

[0001] The present invention relates to a method, a computer and a program related to certification of a signatory of a document. Background Art

[0002] There is a known technology for adding electronic signatures to electronic documents created using article creation software or the like. An electronic signature is data obtained by encrypting the hash value of a document using the private key of the electronic signature issuer. A person who receives a document with an electronic signature obtains the hash value of the document by decrypting the electronic signature using the public key of the electronic signature issuer, and derives the hash value of the received document. By comparing the two, it is possible to determine whether the document has been tampered with.

[0003] In recent years, a technique for performing user authentication by comparing the features of handwritten data has been known. Patent Document 1 discloses an example of such a technique.

[0004] Prior art literature

[0005] Patent Literature

[0006] Patent Document 1: Japanese Patent No. 6480710 Summary of the invention

[0007] Problems to be solved by the invention

[0008] However, in conventional electronic signatures, it has been impossible to prove who the signer of a document (the person who is responsible for the creation of the document) is.

[0009] Therefore, one of the objects of the present invention is to provide a method, a computer and a program related to certification of the signer of a document.

[0010] Means for solving problems

[0011] The method of the present invention is a method executed by one or more computers, wherein a user DID is obtained to identify a signer who has made a handwritten signature on an electronic document, a hash value of a document file representing the electronic document on which the handwritten signature has been made by the signer is derived, and a certificate containing the user DID and the hash value of the document file is generated.

[0012] The computer of the present invention is a computer having a processor, wherein the processor obtains a user DID for identifying a signer who has handwritten a signature on an electronic document, derives a hash value of a document file representing the electronic document on which the signer has handwritten a signature, and generates a certificate containing the user DID and the hash value of the document file.

[0013] The program of the present invention is used to enable a computer to perform the following processing: obtain the user DID that identifies the signer who hand-signed an electronic document, export the hash value of the document file representing the electronic document hand-signed by the signer, and generate a certificate containing the user DID and the hash value of the document file.

[0014] Effects of the Invention

[0015] According to the method, computer and program of the present invention, it is possible to realize certification of the signer of a document. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 : is a diagram showing the configuration of a certificate issuing system 1 according to the present embodiment.

[0017] Figure 2 It is a diagram showing an example of the hardware configuration of the user terminal 3 , the application server 4 , and the signature verification server 5 .

[0018] Figure 3 is a diagram showing the structure of biometric signature data.

[0019] Figure 4 (a) is a diagram showing the structure of a user DID document, and (b) is a diagram showing the structure of a document DID document.

[0020] Figure 5 (a) is a diagram showing the structure of a user signature VC, and (b) is a diagram showing the structure of a document signature VC.

[0021] Figure 6 It is a diagram showing an overview of the signed VC issuance process.

[0022] Figure 7 It is a diagram showing the processing flow of the signed VC issuance process.

[0023] Figure 8 It is shown in Figure 7 A processing flowchart showing details of the signature authentication processing performed in step S7.

[0024] Fig. 9 It is shown in Figure 7 A processing flowchart showing details of the signature authentication processing performed in step S7.

[0025] Fig.10 It is shown in Figure 7 A processing flowchart showing details of the signature authentication processing performed in step S7.

[0026] Fig.11 It is shown in Figure 7 A processing flowchart showing details of the signature processing performed in step S11.

[0027] Fig.12 It is shown in Figure 7 A processing flowchart showing details of the signature processing performed in step S11.

[0028] Fig.13 It is shown in Figure 7 A processing flowchart showing details of the signature VC generation process performed in step S12.

[0029] Fig.14 : is a diagram showing the processing flow of the signer certification processing.

[0030] Fig.15 : is a diagram showing the processing flow of the signer certification processing.

[0031] Fig.16 : is a diagram showing the processing flow of the signer certification processing. DETAILED DESCRIPTION

[0032] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0033] Figure 1 1 is a diagram showing the structure of the certificate issuing system 1 of the present embodiment. As shown in the figure, the certificate issuing system 1 has a structure in which a user terminal 3, an application server 4, a signature authentication server 5, a distributed file system 6, and a blockchain network 7 are interconnected via a network 2.

[0034] Figure 2 1 is a diagram showing an example of the hardware structure of the user terminal 3, the application server 4 and the signature verification server 5. The user terminal 3, the application server 4 and the signature verification server 5 can be respectively constituted by a computer 100 having the structure shown in the figure. It should be noted that the application server 4 and the signature verification server 5 can also be respectively constituted by combining a plurality of computers 100. In addition, part or all of the functions of the application server 4 and the signature verification server 5 can also be installed as an application in the computer 100 constituting the user terminal 3.

[0035] like Figure 2 As shown, the computer 100 has a structure in which a CPU (Central Processing Unit) 101 , a storage device 102 , an input device 103 , an output device 104 , and a communication device 105 are mutually connected via a bus 106 .

[0036] The CPU 101 is a device that controls each part of the computer 100 and reads and executes various programs stored in the storage device 102. Figure 6~Figure 16Each of the processes described above is implemented by the CPU 101 of each of the user terminal 3 , the application server 4 , and the signature verification server 5 executing a program stored in the respective storage device 102 .

[0037] The storage device 102 includes a main storage device such as a DRAM (Dynamic Random Access Memory) and an auxiliary storage device such as a hard disk, and plays a role of storing various programs for executing the operating system and various application programs of the computer 100 and data used by these programs.

[0038] The input device 103 is a device that receives user input operations and supplies them to the CPU 101, and is configured to include, for example, a keyboard, a mouse, and a touch detection device. The touch detection device is a device including a touch sensor and a touch controller, and is used to detect pen input or touch input. Figure 1 The pen P shown is an electronic pen used for pen input to the touch detection device of the user terminal 3. The pen input by the pen P is realized by, for example, an active electrostatic method or an electromagnetic induction method.

[0039] The output device 104 is a device for outputting the processing result of the CPU 101 to the user, and is configured to include, for example, a display and a speaker. The communication device 105 is a device for communicating with an external device, and transmits and receives data according to the instructions of the CPU 101. The user terminal 3, the application server 4, and the signature authentication server 5 use the communication device 105 to communicate with other devices, systems, networks, etc. including the illustrated blockchain network 7 and the distributed file system 6.

[0040] return Figure 1 The user terminal 3 is a terminal for the signer of the document to be signed, and is composed of a personal terminal such as a smart phone, a tablet terminal, a personal computer, etc. Examples of documents to be signed include various contracts, applications for exhibition of artworks, etc. If the signer writes a signature in the signature column of the document displayed on the display of the user terminal 3 using a pen P, the user terminal 3 performs processing to generate biometric signature data representing the handwritten signature.

[0041] Figure 3: is a diagram showing the structure of biometric signature data. Biometric signature data is data generated, for example, in accordance with FSS (Forensic Signature Stream) or WILL (Wacom Ink Layer Language), and as shown in the figure, is composed of: dynamic signature data, a hash value of the signed document, context information and additional information; dynamic signature data, a hash value of the signed document and a hash value of the context information; the hash value and the hash value of the additional information; and a checksum for detecting errors that may occur when sending and receiving the hash value. The following describes an example of using biometric signature data generated in accordance with FSS, and the biometric signature data is referred to as "FSS". However, of course, biometric signature data generated in accordance with WILL can also be used.

[0042] The dynamic signature data is digital ink data including a series of coordinate data constituting a line drawing. Each coordinate data is data indicating the position of the pen P detected by the above-mentioned touch detection device. If the detection is described in detail, the touch sensor is configured to include a plurality of X electrodes extending in the Y direction and arranged at equal intervals in the X direction, and a plurality of Y electrodes extending in the X direction and arranged at equal intervals in the Y direction. When the pen P is configured to be able to send signals, the touch controller obtains coordinate data indicating the position of the pen P by using the plurality of X electrodes and the plurality of Y electrodes to receive the burst signals sent by the pen P respectively. On the other hand, when the pen P cannot send signals, the touch controller sends signals to the plurality of X electrodes in sequence, receives the signals respectively using the plurality of Y electrodes, and obtains coordinate data indicating the position of the pen P by detecting the amplitude change of the received signals. The touch controller is configured to collect coordinate data at a frequency of, for example, 100 or 200 times per second.

[0043] The hash value of a signed document is the value obtained by inputting the electronic data of the signed document (hereinafter referred to as "document file") into a specified one-way hash function. The same is true for other hash values, which are values ​​obtained by inputting the electronic data of the object into a specified one-way hash function.

[0044] The context information includes the name data of the signer, the date and time of the signature, the purpose of the signature, the information of the touch detection device used for the signature (manufacturer name, model name, etc.), the information of the application used for the signature (application name, version information, etc.), the information of the operating system of the user terminal 3 (operating system name, version information, etc.), the address information of the user terminal 3 (IP address, MAC address, etc.), etc. The additional information is information that can be arbitrarily specified by the administrator of the certificate issuing system 1 in addition to the dynamic signature data, the hash value of the signed document, and the context information.

[0045] return Figure 1 . The user terminal 3 is configured to have an application for managing a distributed identity (Decentralized Identifier. hereinafter referred to as "DID"), namely a user wallet 3a. DID is a distributed ID used in autonomous identity (a mechanism that allows one to own and control one's own identity (Identity. hereinafter referred to as "ID") without the intervention of a management entity, thereby solving various problems caused by centralized ID management. Self-Sovereign Identity. hereinafter referred to as "SSI"), which is permanently recorded in the blockchain network 7.

[0046] The user wallet 3a does not store the DID itself, but stores the token ID issued from the blockchain network 7 when recording the DID, thereby managing the DID. When the user terminal 3 needs to obtain the DID, it accesses the blockchain network 7 based on the token ID of the DID to be obtained, thereby obtaining the DID. The DID managed by the user wallet 3a includes the DID that identifies the user of the user terminal 3 (hereinafter referred to as "user DID").

[0047] In addition, the user wallet 3a is configured to store a key pair (a pair of private key and public key) of the public key encryption method and an encryption key of the shared key encryption method for each DID. Hereinafter, the private key, public key, and encryption key corresponding to the user DID are respectively referred to as "user private key", "user public key", and "user encryption key". These keys are generated by the user terminal 3 when a new user DID is issued and stored in the user wallet 3a.

[0048] The DID is composed of information indicating the location of information that specifically indicates the content of the ID (hereinafter referred to as a "DID document"). Usually, the DID document is stored in the distributed file system 6. In this case, the information indicating the location of the DID document becomes the hash value of the DID document. Hereinafter, the DID document corresponding to the user DID is referred to as a "user DID document".

[0049] Figure 4 (a) is a diagram showing the structure of a user DID document. As shown in the figure, the user DID document includes a user DID and a user public key. A DID document is information that anyone can access using the corresponding DID as a search keyword. Therefore, by configuring the user public key in the user DID document, the user public key is widely disclosed in society.

[0050] return Figure 1. The user terminal 3 receives the document file representing the document to be signed from the application server 4 and displays it to the signer. In addition, if the signer writes a signature in the signature field in the displayed document file, the user terminal 3 also generates a certificate used in the above-mentioned SSI, that is, a verifiable certificate (VerifiableCredentials). The verifiable certificate (hereinafter referred to as "signature VC") generated by the user terminal 3 contains the user DID and the hash value of the document file. In addition, the signature VC generated by the user terminal 3 is then assigned an electronic signature by the application server 4. It should be noted that the generation of the electronic signature is performed by deriving, that is, calculating, the hash value of the electronic data of the object (in this case, the signature VC) and encrypting it using a specified encryption key (in this case, the host private key described later). This is also the same for other electronic signatures described later.

[0051] The signature VC generated by the user terminal 3 includes a user signature VC for management by the user and a document signature VC for management by the administrator of the certificate issuing system 1. The user signature VC is managed by the user wallet 3a, and the document signature VC is managed by the host wallet 4a in the application server 4 described later.

[0052] Figure 5 (a) is a diagram showing the structure of a user signature VC. Figure 5 (b) is a diagram showing the structure of the document signature VC. By observing these figures, it can be understood that the user signature VC and the document signature VC are information containing the same content, except that the ID that serves as the main keyword is different. Specifically, the user signature VC uses the signer DID as the main keyword, and is composed of information including the document name, the reason for signing, the authentication score, the hash value of the document file, the hash value of the document file with an electronic signature, the encrypted FSS, the hash value of the FSS, the document DID, the document size, the issuer DID, and the issuance date. In addition, the document signature VC uses the document DID as the main keyword, and is composed of information including the document name, the reason for signing, the authentication score, the hash value of the document file, the hash value of the document file with an electronic signature, the encrypted FSS, the hash value of the FSS, the signer DID, the document size, the issuer DID, and the issuance date.

[0053] return Figure 1 The application server 4 is a server computer that manages documents before and after signing and performs various processes related to signing documents. The entity of the document file representing the document is stored in the distributed file system 6, but in order to prevent it from disappearing, the application server 4 also stores a copy of it. In one example, the application server 4 can be a server computer that constitutes a part of a banking system or an art trading system.

[0054] The application server 4 is configured to have a host wallet 4a, which is an application that manages DID, private key, public key, and encryption key in the same way as the user wallet 3a. The DID managed by the host wallet 4a includes a DID (hereinafter referred to as "host DID") that identifies the administrator (host) of the certificate issuance system 1. Hereinafter, the private key and public key corresponding to the host DID will be referred to as "host private key" and "host public key", respectively. These keys are generated by the application server 4 when a new host DID is issued and stored in the host wallet 4a.

[0055] In addition to providing the document file representing the document for signature to the user terminal 3 in response to a request from the user terminal 3, the application server 4 also issues a DID (hereinafter referred to as "document DID") for identifying the provided document and records it to the blockchain network 7. When issuing the document DID, the application server 4 also processes a DID document, a private key, and a public key (hereinafter referred to as "document DID document", "document private key", and "document public key", respectively) for the newly generated document DID.

[0056] Figure 4 (b) is a diagram showing the structure of a document DID document. As shown in the figure, the document DID document contains a document DID, a document public key, a document URI (Uniform Resource Identifier) ​​and a user DID. The document URI is the address of a document in the distributed file system 6. The user DID is the DID of the user of the user terminal 3 who requested the issuance of the document DID.

[0057] return Figure 1 The signature authentication server 5 is a server computer that performs authentication of handwritten signatures. Specifically, the following processing is performed: a signature template generated based on one or more past signatures of the user and an FSS representing the handwritten signature of the authentication object are received from the user terminal 3, and the similarity between the handwritten signature represented by the FSS and one or more signatures included in the signature template (hereinafter referred to as "authentication score") is calculated. The signature authentication server 5 is configured to return the authentication score as a result of the authentication process.

[0058] The distributed file system 6 is a network of multiple computers connected in a peer-to-peer manner, such as the InterPlanetary File System. The distributed file system 6 is configured to be able to store any electronic data, and the electronic data stored in the distributed file system 6 is identified by its hash value. That is, in the distributed file system 6, the hash value of the stored electronic data functions as the URI of the electronic data. In this embodiment, the distributed file system 6 is used to store document files and DID documents.

[0059] The blockchain network 7 is a network of multiple computers connected in a peer-to-peer manner, such as the Ethereum network. The blockchain network 7 includes a blockchain configured to record various transactions including DID issuance transactions. Transactions are recorded in the blockchain by some computers (hereinafter referred to as "miners") connected to the blockchain network 7.

[0060] Specifically, each block constituting the blockchain is constituted of data (transaction data) including a block header and the specific content of the transaction. Among them, the block header includes a Merkle root, a hash value of the previous block, and a Nonce value. The Merkle root is data compressed by the size of the transaction data, and the Nonce value is an arbitrary string. In the blockchain network 7, the following rules are determined: in order to connect a new block to the blockchain, the hash value of the block must meet the specified conditions (for example, the condition that the value starts with "000"). Therefore, the miner who wants to record the block in the blockchain performs a brute-force operation (mining) to find the Nonce value in a way that the hash value of the block header of the block satisfies the above-mentioned specified conditions. As a result of this operation, the miner who first succeeds in discovering the Nonce value connects the block to the blockchain, thereby completing the recording of the transaction to the blockchain.

[0061] The following specifically describes the processing performed by the user terminal, the application server 4, and the signature verification server 5 in association with the signature VC. Figure 6 After explaining the outline of the process for issuing a signed VC (hereinafter referred to as "signed VC issuance process"), Figure 7 to Figure 13 The content of the signature VC issuance process will be described in more detail. Figure 14~Figure 16 Next, a process of certifying the signer using the issued signature VC (hereinafter referred to as “signer certification process”) will be described.

[0062] Figure 6 (a) to (d) are diagrams showing an overview of the signature VC issuance process. Figure 6 In (a), the user terminal 3 displays one or more document files stored in the application server 4 to the user in a selectable manner. Figure 6 As exemplified in (a) of FIG. 1 , the specific type of the document file is typically a PDF file, but may be another type of file.

[0063] If the user selects one of the one or more document files displayed by a tap operation, the Figure 6 As shown in (b) of FIG. 1 , the user terminal 3 opens the selected document file so that the user can check the content. In addition, the user terminal 3 displays a signature start button 10 on the screen.

[0064] If the user who has confirmed the contents of the displayed document file and decided to sign presses the signing start button 10, the user terminal 3 displays Figure 6 The signature screen shown in (c) of FIG. 1 includes a signature field 11, a selection button 12, and a signature verification completion display field 13. When the user writes a signature in the signature field 11 using a pen P and presses the selection button 12, the user terminal 3 starts the process for issuing the signature VC. For details of this process, refer to Figure 7 to Figure 13 Although detailed description is given later, this process includes the authentication of the signature by the signature authentication server 5. The user terminal 3 is configured to determine whether the authentication is successful based on the authentication score received as a result of the authentication from the signature authentication server 5, and to display a check mark indicating that the authentication is successful in the signature authentication completion display field 13 if it is determined to be successful.

[0065] If the issuance of the signature VC including the user signature VC and the document signature VC is completed, then Figure 6 As shown in (d), the user's signature VC is saved in the user wallet 3a. The user of the user terminal 3 can receive proof that he is the signer of the document file by submitting the user's signature VC together with the user DID and the document file with electronic signature (or the electronic signature of the document file) to the application server 4.

[0066] Figure 7 to Figure 13 3 and 4. In these figures, the user terminal 3 and the user wallet 3a are shown respectively, but this is only for the convenience of display. In this embodiment, as mentioned above, the actual user wallet 3a is installed in the user terminal 3.

[0067] First, the document file is supplied from the application server 4 to the user terminal 3 (step S1). Figure 6 (c)) Sign (step S2) and press the select button 12 (refer to Figure 6 (c)) (step S3), the user terminal 3 requests the user wallet 3a for a DID list (step S4). The user wallet 3a generates a list of managed DIDs based on the request and replies to the user terminal 3 (step S5). The user terminal 3 allows the user to select a DID from the DID list thus obtained (step S6), and then starts the signature authentication process for authenticating the signature (step S7).

[0068] Figure 8~Figure 10: is a processing flow chart showing the details of the signature authentication process performed in step S7. The user terminal 3 first verifies whether the DID selected in step S6 is a valid DID (step S20). Specifically, with reference to the blockchain network 7, it is confirmed whether the selected DID is an actual DID. If it is confirmed that it is an existing DID, it is determined to be a valid DID. The user terminal 3 determines whether the verification result is a valid DID (step S21). If it is determined to be invalid, information indicating that the authentication failed is returned. On the other hand, if it is determined to be valid, the selected DID is determined as the user DID (step S22).

[0069] Next, the user terminal 3 obtains the signature written by the user in the signature field 11 (step S23), and generates the FSS of the obtained signature (step S24). After that, the user terminal 3 determines whether the user's signature template is stored (step S25). If it is determined that the signature template is stored, the processing is forwarded to step S26. Fig. 9 On the other hand, if it is determined that the FSS is not stored, a request for generating a signature template including the FSS generated in step S24 is generated and sent to the signature verification server 5 (step S26).

[0070] The signature verification server 5 that receives the request to generate the signature template generates the signature template based on the received FSS (step S27), and sends it back to the user terminal 3 (step S28). The user terminal 3 that receives the return generates an encryption request including the signature template received from the signature verification server 5, the user DID determined in step S22, and the FSS generated in step S24, and sends it to the user wallet 3a (step S29).

[0071] Move to Fig. 9 The user wallet 3a that receives the encryption request uses the user encryption key represented by the user DID to encrypt the signature template and FSS respectively (step S30), and sends the encrypted signature template and encrypted FSS obtained as a result back to the user terminal 3 (step S31). The user terminal 3 sends the encrypted signature template and encrypted FSS received from the user wallet 3a to its own storage device 102 (refer to Figure 2 ) is stored (step S32), and information indicating successful authentication is returned. It can be understood from the processing of steps S26 to S32 that if the user terminal 3 does not store the user's signature template, no substantial authentication processing is performed.

[0072] In step S33, the user terminal 3 obtains the stored signature template (step S33). The signature template thus obtained is encrypted by the user encryption key. Therefore, the user terminal 3 generates a decryption request including the obtained encrypted signature template and the user DID determined in step S22, and sends it to the user wallet 3a (step S34). The user wallet 3a decrypts the encrypted signature template using the user encryption key represented by the user DID, and sends the resulting signature template back to the user terminal 3 (step S36).

[0073] The user terminal 3 that has received the decrypted signature template generates an authentication request including the received signature template and the FSS generated in step S24, and sends it to the signature authentication server 5 (step S37). The signature authentication server 5 that has received the authentication request calculates the authentication score using the received signature template and FSS, and sends the authentication result including the calculated authentication score back to the user terminal 3 (step S39).

[0074] Move to Fig.10 The user terminal 3 that receives the authentication result determines whether the signature authentication is successful based on the received authentication result (step S40). Specifically, the authentication is determined to be successful when the authentication score is above a specified value, and is determined to be failed in other cases. The user terminal 3 that is determined to be failed in step S40 returns information indicating that the authentication has failed.

[0075] On the other hand, the user terminal 3 that has determined that the authentication is successful in step S40 generates an update request for a signature template including the signature template received in step S36 and the FSS generated in step S24, and sends it to the signature authentication server 5 (step S41). The signature authentication server 5 that has received the update request for the signature template updates the received signature template by adding the signature represented by the received FSS (step S42), and sends the updated signature template back to the user terminal 3 (step S43).

[0076] Next, the user terminal 3 generates an encryption request including the updated signature template, the user DID determined in step S22, and the FSS generated in step S24, and sends it to the user wallet 3a (step S44). The user wallet 3a that receives the encryption request encrypts the signature template and FSS respectively using the user encryption key represented by the user DID (step S45), and sends the encrypted signature template and encrypted FSS obtained as a result back to the user terminal 3 (step S46). The user terminal 3 sends the encrypted signature template and encrypted FSS received from the user wallet 3a to its own storage device 102 (refer to Figure 2 ) is stored (step S47), and information indicating successful authentication is returned.

[0077] return Figure 7 If the signature authentication process is completed, the user terminal 3 determines whether the authentication is successful based on the return result of the signature authentication process (step S8). As a result, if it is determined that the authentication has failed, the signature VC issuance process is terminated. In this case, the signature VC is not issued. On the other hand, if the user terminal 3 determines that the authentication is successful, Figure 6 The signature authentication completion display column 13 shown in (c) shows a check mark (step S9), and the output is Figure 8 The user terminal 3 then executes a signature process for generating a signed document (step S11).

[0078] Fig.11 and Fig.12 is a processing flow chart showing the details of the signature processing performed in step S11. The user terminal 3 first generates a request to generate a document DID containing information that determines the document file, and sends it to the application server 4 (step S50). The application server 4 that receives the generation request generates a document private key and a document public key, and saves them to the host wallet 4a (step S51). Next, the application server 4 generates a document DID and a document DID document, records the document DID to the blockchain network 7, and saves the document DID document to the distributed file system 6 (step S52). Afterwards, the application server 4 sends the generated document DID back to the user terminal 3 (step S53).

[0079] The user terminal 3 performs a process of adding the document DID received from the application server 4 to the metadata of the document file (step S54). This process may be a process of adding the document DID to the DocMDP field, for example, when the document file is a PDF file. In addition, the user terminal 3 also performs a process of adding the document DID to the DocMDP field. Figure 8 The process of adding the signature image (the image obtained by rasterizing the dynamic signature data) or the dynamic signature data obtained in step S23 to the document file (step S55).

[0080] Next, the user terminal 3 extracts the hash value of the document file (step S56), and generates information for saving to the signature VC (step S57). The information generated in step S57 becomes Figure 5 In each of the information shown in (a) and (b), the signer DID (in Figure 8 The user DID determined in step S22), document name, reason for signing, authentication score (in Fig. 9 the authentication score received in step S39), the hash value of the document file (the hash value derived in step S57), the encrypted FSS (in Fig. 9Step S32 or Fig.10 The encrypted FSS stored in step S47), the hash value of the FSS (in Figure 7 The information of the FSS derived in step S10), document DID (document DID received in step S53), and document size. It should be noted that the document name and document size can be obtained from the attributes of the document file. In addition, the reason for signing can be obtained by inputting or selecting by the user.

[0081] Next, the user terminal 3 generates a hash value including the hash value generated in step S56 and Figure 8 The generation request of the electronic signature of the user DID determined in step S22 is sent to the user wallet 3a (step S58).

[0082] Move to Fig.12 The user wallet 3a that receives the request to generate an electronic signature generates an electronic signature of the document by encrypting the hash value of the document file using the user private key represented by the user DID (step S59). Then, the generated electronic signature is sent back to the user terminal 3 (step S60). The user terminal 3 that receives the electronic signature uses the received electronic signature to generate a document file with an electronic signature and saves it to its own storage device 102 (refer to Figure 2 ) is stored (step S61) and sent to the application server 4 (step S62), and the signature processing is ended. Afterwards, the application server 4 may also save the received document file with electronic signature to the distributed file system 6 (step S63).

[0083] return Figure 7 When the signature process is completed, the user terminal 3 then performs a signature VC generation process for generating a signature VC (step S12).

[0084] Fig.13 is a processing flow chart showing details of the signature VC generation process performed in step S12. In this process, the user terminal 3 first derives Fig.12 The hash value of the document file with electronic signature stored in step S61 of the present invention is then used to obtain the hash value of the document file with electronic signature stored in step S61 of the present invention (step S70). Fig.11 The user terminal 3 generates the user signature VC and the document signature VC based on the information generated in step S56 (step S71). Next, the user terminal 3 generates an additional electronic signature request including each generated signature VC and transmits it to the application server 4 (step S72).

[0085] The application server 4 that receives the request to add an electronic signature adds the host DID and today's date as the issuer DID and the issue date to each signature VC, derives the hash value of each signature VC (step S73), and generates the electronic signature of each signature VC by encrypting the derived hash value with the host private key (step S74). Then, the generated electronic signature is added to each signature VC to generate a user signature VC with an electronic signature and a document signature VC with an electronic signature (step S75).

[0086] The application server 4 saves the document signature VC with electronic signature among the two signature VCs with electronic signature generated in step S76 to the host wallet 4a (step S76). In addition, the user signature VC with electronic signature is sent to the user terminal 3 (step S77). The user terminal 3 that receives the user signature VC with electronic signature transmits the received user signature VC with electronic signature to the user wallet 3a (step S78). The user wallet 3a saves the transmitted user signature VC with electronic signature to itself (step S79). Through the processing so far, the signature VC generation process is completed, and the entire signature VC issuance process is also completed.

[0087] Figure 14~Figure 16 : is a diagram showing the processing flow of the signer certification process. In this diagram, a user of the user terminal 3 uses the user signature VC to request the application server 4 to prove that the signer of a certain document is himself. The following describes the case of requesting certification using the user signature VC, but the same is true for the case of requesting certification using the document signature VC. It should be noted that the following description assumes that the application server 4 executes the signer certification process, but the signer certification process can also be executed by other computers.

[0088] First refer to Fig.14, a certification request including a user signature VC with an electronic signature, a document file with an electronic signature, and a user DID is sent from the user terminal 3 to the application server 4 (step S80). The application server 4 that receives the certification request uses the public key (host public key) corresponding to the issuer DID contained in the received user signature VC to decrypt the electronic signature of the user signature VC (step S81), and derives the hash value of the user signature VC (step S82). Then, the electronic signature of the user signature VC is verified by comparing them (step S83), and it is determined whether the verification is successful (step S84). Specifically, if the decrypted electronic signature and the derived hash value are equal, it is determined that the verification is successful, otherwise it is determined that the verification fails. The application server 4 that determines that the verification has failed returns information indicating the failure of the certification to the user terminal 3 and ends the processing. Through this verification, the application server 4 can confirm that the user signature VC has not been tampered with.

[0089] The application server 4 that determines that the verification is successful in step S84 then confirms that the received user DID is equal to the signer DID in the user signature VC (step S85), and determines whether the verification is successful (step S86). Specifically, if the received user DID is equal to the user DID in the user signature VC, the verification is determined to be successful, otherwise it is determined to be a failure. The application server 4 that determines that the verification has failed returns information indicating the verification failure to the user terminal 3 and ends the process. Through this confirmation, the application server 4 can confirm that the user requesting the certificate is the person identified by the signer DID recorded in the signature VC.

[0090] The application server 4 that determines that the confirmation is successful in step S86 then extracts the document DID from the metadata of the received document file (step S88), confirms that the extracted document DID is equal to the document DID in the user signature VC (step S89), and determines whether the confirmation is successful (step S90). Specifically, if the extracted document DID is equal to the document DID in the user signature VC, the confirmation is determined to be successful, otherwise it is determined to be a confirmation failure. The application server 4 that determines that the confirmation has failed returns information indicating that the verification has failed to the user terminal 3, and the processing ends.

[0091] Move to Fig.15, the application server 4 that determines that the confirmation is successful in step S90 then determines whether to obtain the document file from the distributed file system 6 (step S91). The determination result is preset by the administrator of the certificate issuing system 1. In the case where it is determined that the document file is obtained from the distributed file system 6, the application server 4 obtains the document file from the distributed file system 6 based on the URI of the document file stored in the user's signature VC (= the hash value of the document file) (step S92). It should be noted that in the case where it is determined in step S91 that the document file is obtained from the distributed file system 6, the user Fig.14 In step S80, the document file with the electronic signature may not be sent, or only the electronic signature of the document file may be sent.

[0092] Next, when the application server 4 obtains the document file from the distributed file system 6, it derives the hash value of the document file obtained from the distributed file system 6, and when the document file is not obtained from the distributed file system 6, it derives the hash value of the document file received from the user (step S93). In addition, the application server 4 decrypts the electronic signature of the document file received from the user using the user public key represented by the received user DID (step S94). Then, the application server 4 verifies the electronic signature of the document file by comparing the derived hash value with the decrypted electronic signature (step S95), and determines whether the verification is successful (step S96). Specifically, if the derived hash value and the decrypted electronic signature are equal, it is determined that the verification is successful, otherwise it is determined that the verification fails. The application server 4 that determines that the verification has failed returns information indicating that the certification has failed to the user terminal 3, and ends the processing. Through this verification, the application server 4 can determine the document file obtained from the distributed file system 6 or the document file received from the user as the document file to be certified.

[0093] The application server 4 that determines that the verification is successful in step S96 then determines whether to perform user authentication (biometric user authentication) using biometric signature data (step S97). This determination result is also preset by the administrator of the certificate issuing system 1. If it is determined that it is not to be performed, the application server 4 returns information indicating that the certification is successful to the user terminal 3, and the processing ends.

[0094] The application server 4 that has determined that the process is being carried out in step S97 first obtains the hash value of the FSS and the encrypted FSS from the user signature VC (step S98), and then transmits a decryption request of the encrypted FSS to the user terminal 3 (step S99).

[0095] The user terminal 3 that receives the decryption request of the encrypted FSS uses the user encryption key stored in the user wallet 3a to decrypt the encrypted FSS (step S100). Then, the user private key stored in the user wallet 3a is used to generate the electronic signature of the decrypted FSS (step S101), and the FSS with the electronic signature is sent back to the application server 4 (step S102).

[0096] Move to Fig.16 , application server 4 uses Fig.14 The user public key represented by the user DID received in step S80 will be Fig.15 The electronic signature of the FSS received in step S102 is decrypted (step S103). Then, by comparing the decrypted electronic signature with the hash value of the FSS obtained in step S98, it is confirmed that the encrypted FSS in the user's signature VC has not been tampered with (step S104), and it is determined whether the confirmation is successful (step S105). Specifically, if the decrypted electronic signature is equal to the hash value of the FSS obtained in step S98, it is determined that the confirmation is successful, otherwise it is determined that the confirmation fails. The application server 4 that determines that the confirmation has failed returns information indicating that the certification has failed to the user terminal 3, and the processing ends.

[0097] The application server 4 that determines that the confirmation is successful in step S105 sends a request for executing the signature authentication of the FSS received in step S102 to the user terminal 3 (step S106). Then, the user terminal 3 that receives the request executes the signature authentication of the received FSS using the saved signature template (step S107). Fig. 9 In the same manner as steps S37 to S39 shown, the signature authentication server 5 is caused to execute signature authentication, and an authentication score as an authentication result is received from the signature authentication server 5 .

[0098] The user terminal 3 that has obtained the authentication result uses the user private key stored in the user wallet 3a to generate an electronic signature of the authentication score (step S108), and sends the authentication score with the electronic signature back to the application server 4 (step S109). The application server 4 decrypts the received electronic signature of the authentication score using the user public key represented by the user DID received in step S80 (step S110), and derives the hash value of the received authentication score (step S111). Then, the electronic signature of the authentication score is verified by comparing them (step S112), and it is determined whether the verification is successful (step S113). Specifically, if the decrypted electronic signature and the derived hash value are equal, the verification is determined to be successful, otherwise it is determined to be a verification failure. The application server 4 that determines that the verification has failed returns information indicating that the proof has failed to the user terminal 3, and the processing ends.

[0099] On the other hand, the application server 4 that determines that the verification is successful in step S113 determines whether the signature authentication is successful based on the received authentication score (step S114). Specifically, the authentication is determined to be successful when the authentication score is above the specified value, and it is determined to be failed in other cases. In addition, the application server 4 returns information indicating successful authentication to the user terminal 3 when it is determined that the authentication is successful, and on the other hand, it returns information indicating failed authentication to the user terminal 3 when it is determined that the authentication fails. The user terminal 3 notifies the user of the information indicating successful authentication or failed authentication returned through the processing so far. In this way, the user can know whether it is proved that the signer of the document is himself.

[0100] As described above, according to the certificate issuing system 1 of this embodiment, since the hash value of the document file and the user DID of the signer are stored in the signature VC configured to be verifiable by electronic signature, the document and the signer can be associated with each other through the certificate. Therefore, a certificate that can prove the signer of the document can be issued.

[0101] In addition, according to the certificate issuing system 1 of this embodiment, since it is possible to confirm that the signature VC has not been tampered with, and to confirm that the user requesting the certificate is the person identified by the signer DID recorded in the signature VC, and to identify the document file of the certification object, the issued certificate can be used to certify the signer of the document.

[0102] In addition, since the encrypted FSS obtained by encrypting the FSS representing the signer's handwritten signature using the signer's private key and the hash value of the FSS are stored in the signature VC, the certificate issuing system 1 according to this embodiment can also perform biometric / user authentication-based certification in the certification based on the signature VC.

[0103] As mentioned above, although the preferred embodiment of the present invention has been described, the present invention is not limited to such embodiment at all, and the present invention can be implemented in various forms within the scope not departing from the gist of the present invention.

[0104] Description of Reference Numerals

[0105] 1 Certificate Issuance System

[0106] 2 Network

[0107] 3 User Terminal

[0108] 3a User Wallet

[0109] 4 Application Server

[0110] 4a Host Wallet

[0111] 5 Signature Authentication Server

[0112] 6 Distributed File Systems

[0113] 7 Blockchain Network

[0114] 10 Signature Start Button

[0115] 11 Signature field

[0116] 12 Select button

[0117] 13 Signature verification completion display bar

[0118] 100 Computer

[0119] 101 CPU

[0120] 102 Storage Device

[0121] 103 Input Device

[0122] 104 Output device

[0123] 105 Communication devices

[0124] 106 Bus

[0125] P pen.

Claims

1. A method performed by one or more computers, wherein: Obtain the user DID that identifies the signer who signed the electronic document manually. calculating a hash value of a document file representing an electronic document on which the signatory has made the handwritten signature, Generate a certificate including the user DID and the hash value of the document file.

2. The method according to claim 1, generating a first electronic signature of the certificate by encrypting a hash value of the certificate, A certificate with the first electronic signature is generated by adding the first electronic signature to the certificate.

3. The method according to claim 2, The first electronic signature is generated by encrypting a hash value of the certificate using a host private key, the host private key being a private key of a manager who issued the certificate.

4. The method according to claim 1, obtaining signature data representing the handwritten signature written by the signatory, authenticating the signature data, The certificate is generated after the signature data is authenticated, and the certificate further includes encrypted signature data generated by encrypting the signature data using the encryption key of the signer and a hash value of the signature data.

5. The method according to claim 1, generating a second electronic signature by encrypting the hash value of the document file, by adding the second electronic signature to the document file to generate a document file with the second electronic signature, The hash value of the document file is the hash value of the document file with the second electronic signature.

6. The method according to claim 5, The second electronic signature is generated by encrypting a hash value of the document file using a user private key, the user private key being a private key of the signer.

7. The method according to claim 2, Calculating a hash value of the certificate contained in the certificate with the first electronic signature, A value obtained by decrypting the first electronic signature included in the certificate with the first electronic signature is compared with the calculated hash value.

8. The method according to claim 3, Calculating a hash value of the certificate contained in the certificate with the first electronic signature, A value obtained by decrypting the first electronic signature included in the certificate with the first electronic signature using a host public key corresponding to the host private key is compared with the calculated hash value.

9. The method according to claim 5, Calculating a hash value of the document file contained in the document file with the second electronic signature, A value obtained by decrypting the second electronic signature included in the document file with the second electronic signature is compared with the calculated hash value.

10. The method according to claim 6, Calculating a hash value of the document file contained in the document file with the second electronic signature, A value obtained by decrypting the second electronic signature included in the document file with the second electronic signature using a user public key corresponding to the user private key is compared with the calculated hash value.

11. The method according to claim 4, generating the signature data by decrypting the encrypted signature data contained in the certificate using the encryption key of the signer, A third electronic signature is generated by encrypting the generated hash value of the signature data using a user private key, wherein the user private key is a private key of the signer, generating signature data with a third electronic signature by appending the third electronic signature to the signature data, A value obtained by decrypting the third electronic signature included in the certificate with the third electronic signature and a hash value of the signature data included in the certificate are compared.

12. The method according to claim 11, A value obtained by decrypting the third electronic signature included in the document file with the third electronic signature using a user public key corresponding to the user private key and a hash value of the signature data included in the certificate are compared.

13. A computer is a computer having a processor, wherein: The processor obtains a user DID identifying a signatory who has signed a handwritten signature on an electronic document, the processor calculating a hash value of a document file representing an electronic document on which the handwritten signature is given by the signatory, The processor generates a certificate including the user DID and a hash value of the document file.

14. The computer according to claim 13, The processor generates a first electronic signature of the certificate by encrypting a hash value of the certificate, The processor generates a certificate with a first electronic signature by adding the first electronic signature to the certificate, The processor calculates a hash value of the certificate contained in the certificate with the first electronic signature, The processor compares a value obtained by decrypting the first electronic signature included in the certificate with the first electronic signature with the calculated hash value.

15. A program for causing a computer to execute the following processing: Obtain the user DID that identifies the signer who signed the electronic document manually. calculating a hash value of a document file representing an electronic document on which the signatory has made the handwritten signature, Generate a certificate including the user DID and the hash value of the document file.

16. The program according to claim 15, configured to cause a computer to further execute the following processing: generating a first electronic signature of the certificate by encrypting a hash value of the certificate, generating a certificate with the first electronic signature by adding the first electronic signature to the certificate, Calculating a hash value of the certificate contained in the certificate with the first electronic signature, A value obtained by decrypting the first electronic signature included in the certificate with the first electronic signature is compared with the calculated hash value.

Images