Information processing program, information processing device, and information processing method

Abstract

To enable the detection of unauthorized certificate information.SOLUTION: A signer 1101 creates a proof 1110 including nonce "abc" corresponding to his / her own DIDa, generates an electronic signature 1120 to an electronic document D and the proof 1110 by using a secret key corresponding to the DIDa, and transmits the electronic signature to a sender 1102 in association with the DIDa. The sender 1102 peeps at the nonce "abc" of the signer 1101, and creates a proof 1130. The sender 1102 generates an electronic signature 1140 to the electronic document D and the proof 1130 by using the secret key corresponding to the own DIDe, and transmits the electronic signature to a recipient 1103 in association with the DIDa. A verification server 204 verifies the electronic signature 1140 by using a public key corresponding to DIDa included in a verification request 1150. Here, the electronic signature 1140 becomes a verification NG because it is generated by using the secret key corresponding to the DIDe of the sender 1102.SELECTED DRAWING: Figure 11

Description

[Technical field]

[0001] The present invention relates to an information processing program, an information processing device, and an information processing method. [Background technology]

[0002] In recent years, self-sovereign ID distribution infrastructure, which safely, securely and easily distributes digitalized identity information (ID information) as certificates with the consent of the individual, has been attracting attention. One use case of the self-sovereign ID distribution infrastructure is, for example, attaching an electronic signature of an organization or representative to a document before sending it, and then verifying the authenticity of the document using the electronic signature on the other side.

[0003] The prior art includes, for example, a technology for generating, distributing, and storing a distribution certificate in an electronic document distribution system based on an authorized electronic address, and a system for generating and verifying an authenticated electronic credential. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Special Publication No. 2013-535859 [Patent Document 2] US Patent Application Publication No. 2016 / 0294845 Summary of the Invention [Problem to be solved by the invention]

[0005] However, in conventional technologies, it is difficult to confirm the signer's attributes and verify their correctness when verifying the authenticity of an electronic document. For example, it is possible to attach a proof (certificate information) that certifies the signer's attributes to the electronic document, but it is not possible to detect if the proof has been obtained illegally.

[0006] In one aspect, the present invention aims to make it possible to detect fraudulent certificate information. [Means for solving the problem]

[0007] In one embodiment, an information processing program is provided that obtains a value specific to an identifier corresponding to an identifier that uniquely identifies a user in a system capable of issuing attribute certificate information for the user from a verification device capable of verifying authenticity of an electronic document to be signed, creates certificate information including attribute information identified from the attribute certificate information, certification information for certifying the attribute information, and the obtained value, generates an electronic signature for the electronic document and the certificate information using a private key corresponding to the identifier, and outputs the electronic document and the certificate information to which the generated electronic signature has been attached, in association with the identifier. Effect of the Invention

[0008] Advantageous Effects of Invention According to one aspect of the present invention, it is possible to make it possible to detect fraudulent certificate information. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of an information processing method according to the first embodiment. [Diagram 2] FIG. 2 is an explanatory diagram showing an example of a system configuration of an information processing system 200. As shown in FIG. [Diagram 3] FIG. 3 is a block diagram showing an example of the hardware configuration of the signature device 201. As shown in FIG. [Figure 4] FIG. 4 is a block diagram showing an example of the hardware configuration of the validation server 204. As shown in FIG. [Diagram 5] FIG. 5 is an explanatory diagram showing an example of the contents stored in the ID management table 230. As shown in FIG. [Figure 6] FIG. 6 is an explanatory diagram showing a specific example of the credential. [Figure 7] FIG. 7 is an explanatory diagram showing a specific example of proof. [Figure 8]FIG. 8 is an explanatory diagram showing a specific example of the certification information. [Figure 9] FIG. 9 is a block diagram illustrating an example of a functional configuration of the signature device 201 according to the first embodiment. As shown in FIG. [Figure 10] FIG. 10 is a block diagram illustrating an example of a functional configuration of the validation server 204 according to the first embodiment. As shown in FIG. [Figure 11] FIG. 11 is an explanatory diagram showing a first example of detection of fraud in proofs. [Figure 12] FIG. 12 is an explanatory diagram showing a second example of detection of fraud in proofs. [Figure 13] FIG. 13 is an explanatory diagram showing a third example of detection of fraud in proofs. [Figure 14] FIG. 14 is a flowchart of an example of a signature processing procedure of the signature device 201 according to the first embodiment. [Figure 15] FIG. 15 is a flowchart of an example of a validation process procedure of the validation server 204 according to the first embodiment. [Figure 16] FIG. 16 is an explanatory diagram showing an example of providing proofs to a plurality of electronic documents. [Figure 17] FIG. 17 is a block diagram illustrating an example of a functional configuration of a signature device 201 according to the second embodiment. As shown in FIG. [Figure 18] FIG. 18 is an explanatory diagram showing an example of the contents of the first management table 1800. As shown in FIG. [Figure 19] FIG. 19 is a flowchart of an example of a signature processing procedure of the signature device 201 according to the second embodiment. [Figure 20] FIG. 20 is a flowchart (part 1) showing an example of a specific processing procedure for creating a proof. [Figure 21] FIG. 21 is a flowchart (part 2) showing an example of a specific processing procedure for creating a proof. [Figure 22] FIG. 22 is an explanatory diagram showing an example of the contents of the second management table 2200. As shown in FIG. [Figure 23]FIG. 23 is a flowchart of an example of a validation process procedure of the validation server 204 according to the second embodiment. [Figure 24] FIG. 24 is a flowchart illustrating an example of a specific procedure for the nonce validity determination process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an information processing program, an information processing device, and an information processing method according to embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0011] (Embodiment 1) Fig. 1 is an explanatory diagram showing an example of an information processing method according to the first embodiment. In Fig. 1, a first information processing device 101 is a computer that signs a digital document to be signed. A second information processing device 102 is a computer that can verify the authenticity of the digital document.

[0012] An electronic document is content that is used in electronic form. For example, an electronic document is a document or image created by various applications. An electronic document may also be a paper document that is scanned and saved as electronic data.

[0013] A signature is applied to an electronic document by attaching an electronic signature. An electronic signature is information for verifying the authenticity (legitimacy) of data (electronic document). An electronic signature can be realized, for example, by using a public key cryptosystem.

[0014] When verifying the authenticity of an electronic document using a digital signature, there are cases where it is necessary to ascertain the attributes of the signer before guaranteeing the correctness of the electronic document. For example, when issuing an invoice for a company, the signature of the company's representative is required. In this case, if the attributes of the signer cannot be confirmed, it can be confirmed that the invoice has not been tampered with, but it cannot be known whether the signature is actually that of the representative.

[0015] In other words, merely attaching an electronic signature does not allow one to confirm the signer's attributes or verify the correctness of the signature. For this reason, for example, it is conceivable to attach certificate information that certifies the signer's attributes to the electronic document. The certificate information includes the signer's attribute information and certification information for certifying the attribute information.

[0016] Attribute information is information about the inherent properties and characteristics of people or things (such as name, gender, age, occupation, and job title). Proof information is information for proving attribute information, and includes, for example, multiple variable groups. Certificate information is verified using a protocol called zero-knowledge proof, for example, based on the attribute information, proof information, and the public key of the certificate issuer.

[0017] The certificate information is, for example, a proof created based on the signer's attribute certificate information (credentials) issued by a certification authority. The attribute certificate information is information that indicates the attribute certificate of the user (signer). The attribute certificate information is, for example, information for proving that the user is a legitimate person linked to identity information.

[0018] Identity information is, for example, a collection of attributes (attributes and attribute values) that define a user. Attributes include, for example, name, address, date of birth, My Number, age, occupation, job title, and career history. An authentication authority is an organization that manages the identity information of users (signers), and is, for example, a specific company (authenticating company) or a specific department within a company.

[0019] To explain in more detail, for example, the certificate information may be part of the attribute certificate information that is disclosed, part of the attribute certificate information that is concealed, or proof that the attribute certificate information satisfies a certain condition. A specific example of the attribute certificate information (credential) will be described later with reference to Fig. 6. A specific example of the certificate information (proof) will be described later with reference to Fig. 7.

[0020] On the other hand, certificate information (proofs) can be obtained illegally. For example, a signer may illegally obtain a proof created by another person and use it as his / her own. However, with conventional technology, even if a signer uses someone else's proof to sign, the recipient cannot verify whether the proof was created from the signer's own credentials.

[0021] In the first embodiment, therefore, an information processing method is described that, when verifying the authenticity of an electronic document, checks the attributes of a signer and makes it possible to detect fraud in certificate information (proof) that is added to the electronic document to make its correctness verifiable. Processing examples of the first information processing device 101 and the second information processing device 102 are described below.

[0022] (1) The first information processing device 101 obtains a value that corresponds to a user's identifier and is specific to the identifier from the second information processing device 102. The user's identifier is an identifier that uniquely identifies the user in the system 110. The system 110 is a system that can issue attribute certificate information of a user, and is, for example, a self-sovereign ID distribution infrastructure.

[0023] The self-sovereign ID distribution infrastructure is a system that distributes digitalized identity information as a certificate safely, securely, and easily with the consent of the individual. The first information processing device 101 corresponds to, for example, a signature device in the system 110. The second information processing device 102 corresponds to, for example, a verification device in the system 110.

[0024] In a self-sovereign ID distribution platform, communication partners can be identified by IDs known as DIDs (Decentralized Identifiers), which can be obtained by all participants. For example, DIDs can be used as user identifiers. For example, a private key and a public key for electronic signatures are linked to the DID.

[0025] The value corresponding to the user's identifier is a value unique to the user's identifier, and is, for example, a random number (random character string). The value corresponding to the user's identifier is, for example, transmitted from the second information processing device 102 to the first information processing device 101 in response to a request from the first information processing device 101. As the value corresponding to the user's identifier, for example, a random number called a nonce can be used. The user is, for example, a signer (for example, the president of a certain company).

[0026] 1, an identifier that uniquely identifies the signer 103 (user) is “DIDa”, and a nonce corresponding to the DIDa is “abc.” In this case, the first information processing device 101 obtains, for example, the nonce “abc” corresponding to the DIDa of the signer 103 from the second information processing device 102.

[0027] (2) The first information processing device 101 creates certificate information including attribute information identified from the attribute certificate information, certification information for certifying the attribute information, and the acquired value. The attribute information may indicate some attributes of the attribute certificate information, may be some attributes of the attribute certificate information that have been concealed, or may be certification that an attribute of the attribute certificate information satisfies a certain condition.

[0028] In the example of Figure 1, it is assumed that proof121 has been created. Proof121 includes attribute information, proof information, and nonce "abc".

[0029] (3) The first information processing device 101 generates a digital signature for the digital document and certificate information to be signed. Specifically, for example, the first information processing device 101 generates a digital signature for the digital document and certificate information to be signed by using a private key corresponding to an identifier that uniquely identifies a user.

[0030] 1, it is assumed that a private key corresponding to DIDa is used to generate a digital signature 123 for a digital document 122 and a proof 121. The digital document 122 is the digital document to be signed.

[0031] (4) The first information processing device 101 outputs the generated electronic document to which the digital signature has been added and the certificate information in association with an identifier that uniquely identifies the user. The destination of the electronic document to which the digital signature has been added and the certificate information is, for example, the submitter of the electronic document.

[0032] The source of an electronic document corresponds to a sender (e.g., an employee of a company) who sends an electronic document (e.g., an invoice of a company) to a recipient. The destination of an electronic document corresponds to a recipient (e.g., an accountant of a company or an employee of a company to which an invoice is being sent) who receives the electronic document sent from the source.

[0033] 1, it is assumed that electronic document 122 and proof 121 to which digital signature 123 has been affixed are associated with DIDa of signer 103 and output to source 104 of electronic document 122. Electronic document 122 and proof 121 to which digital signature 123 has been affixed are transmitted, for example, from source 104 of electronic document 122 to destination 105 of electronic document 122.

[0034] (5) The second information processing device 102 accepts the electronic document to which the electronic signature has been affixed and the certificate information in association with a first identifier that uniquely identifies a user in the system 110. The user is, for example, the signer who signed the electronic signature.

[0035] 1, it is assumed that the second information processing device 102 has received a verification request 130 from a submission destination 105 of an electronic document 122. The verification request 130 includes the DIDa of the signer 103, the electronic document 122 to which a digital signature 123 has been affixed, and a proof 121.

[0036] (6) The second information processing device 102 detects fraud in the certificate information when the first value included in the certificate information does not match the value corresponding to the first identifier by referring to the correspondence information 120. The correspondence information 120 indicates the correspondence relationship between an identifier that uniquely identifies each user in the system 110 and a value specific to the identifier.

[0037] 1, the correspondence information 120 indicates a correspondence relationship between DIDa and nonce "abc." The second information processing device 102 refers to the correspondence information 120 and determines whether the nonce included in the proof 121 matches the nonce corresponding to the DIDa. In this example, the nonce included in the proof 121 is "abc."

[0038] For this reason, it is determined that the nonce included in the proof 121 matches the nonce corresponding to the DIDa. In this case, the second information processing device 102 determines that the creator of the proof 121 is the same person as the signer 103, for example, and does not detect any fraudulent nature of the proof 121.

[0039] If proof121 was obtained illegally, the nonce included in proof121 will be a value belonging to a user other than signer 103. In this case, the nonce included in proof121 will not match the nonce corresponding to DIDa, and the illegality of proof121 will be detected.

[0040] The second information processing device 102 may also verify the electronic signature by using a public key corresponding to the first identifier. Specifically, for example, the second information processing device 102 verifies the electronic signature 123 by using a public key corresponding to DIDa. This makes it possible to verify the authenticity of the electronic document 122.

[0041] For example, when the verification result of the electronic signature 123 is verification OK, the second information processing device 102 can detect that neither the electronic document 122 nor the proof 121 has been tampered with. Also, when the verification result of the electronic signature 123 is verification NG, the second information processing device 102 can detect that at least one of the electronic document 122 and the proof 121 has been tampered with.

[0042] The second information processing device 102 may also verify the certificate information based on the attribute information and proof information included in the received certificate information. The certificate information is verified, for example, using an existing protocol called zero-knowledge proof based on the attribute information, proof information, and the public key of the issuer of the attribute certificate information. This makes it possible to verify the authenticity of the proof 121 (that it has not been tampered with).

[0043] In this way, the first information processing device 101 and the second information processing device 102 can detect any tampering with the proof 121 by checking whether the nonce included in the proof 121 matches the nonce corresponding to the signer's DIDa. This makes it possible to prevent tampering with the proof 121, which is added to verify the attributes of the signer 103 when verifying the authenticity of the electronic document 122.

[0044] (System configuration example of information processing system 200) Next, a system configuration example of the information processing system 200 according to the first embodiment will be described. In the following description, a case where the first information processing device 101 shown in Fig. 1 is applied to a signature device 201 in the information processing system 200 will be described as an example. Also, a case where the second information processing device 102 shown in Fig. 1 is applied to a validation server 204 in the information processing system 200 will be described as an example.

[0045] Furthermore, attribute certificate information may be written as a “credential”, and certificate information created from the attribute certificate information may be written as a “proof”. The information processing system 200 is applied to, for example, a self-sovereign ID distribution infrastructure in which digitized identity information (ID information) is distributed as a certificate with the consent of the individual.

[0046] Fig. 2 is an explanatory diagram showing an example of a system configuration of an information processing system 200. In Fig. 2, the information processing system 200 includes a signature device 201, a user terminal 202, a user terminal 203, a validation server 204, and an authentication server 205. In the information processing system 200, the signature device 201, the user terminal 202, the user terminal 203, and the validation server 204 are connected via a wired or wireless network 210. The network 210 is, for example, a local area network (LAN), a wide area network (WAN), the Internet, or the like.

[0047] Moreover, the signature device 201, the validation server 204, and the authentication server 205 are included in an ID distribution infrastructure 220. The ID distribution infrastructure 220 is a self-sovereign ID distribution infrastructure. In the ID distribution infrastructure 220, the signature device 201, the validation server 204, and the authentication server 205 are connected via a dedicated network. The ID distribution infrastructure 220 is a single platform, and is realized by, for example, a cloud.

[0048] Here, the signature device 201 is a computer that signs (digitally signs) an electronic document to be signed. The signature device 201 is, for example, a PC (Personal Computer) or a tablet PC used by a signer.

[0049] The user terminal 202 is a computer used by a user who is the submitter (sender) of an electronic document. The user terminal 203 is a computer used by a user who is the recipient (receiver) of the electronic document. The user terminals 202 and 203 are, for example, PCs, tablet PCs, etc.

[0050] 1 corresponds to, for example, the user terminal 202. Moreover, the submission destination 105 shown in FIG.

[0051] The verification server 204 is a computer that has an ID management table 230 and can verify the authenticity of a digital document. An example of the contents stored in the ID management table 230 will be described later with reference to FIG. 5. The authentication server 205 is a computer that manages the credentials (attribute certificate information) of users (signers). The authentication server 205 is, for example, a server of a certification company (certification authority).

[0052] 2, only one each of the signature device 201, user terminal 202 (submission source), user terminal 203 (submission destination), validation server 204, and authentication server 205 are shown, but this is not limited to the above. For example, the information processing system 200 may include multiple each of the signature device 201, user terminal 202 (submission source), user terminal 203 (submission destination), validation server 204, and authentication server 205.

[0053] In the following description, an identifier that uniquely identifies a user in the ID distribution infrastructure 220 may be referred to as a "DID," and a value specific to the DID that corresponds to the DID managed in the verification server 204 may be referred to as a "nonce."

[0054] (Example of Hardware Configuration of Signature Device 201) Next, an example of the hardware configuration of the signature device 201 will be described.

[0055] Fig. 3 is a block diagram showing an example of the hardware configuration of signature device 201. In Fig. 3, signature device 201 has a CPU (Central Processing Unit) 301, a memory 302, a disk drive 303, a disk 304, a communication I / F (Interface) 305, a display 306, an input device 307, a portable recording medium I / F 308, and a portable recording medium 309. In addition, each component is connected to each other by a bus 300.

[0056] Here, CPU 301 is responsible for the overall control of signature device 201. CPU 301 may have multiple cores. Memory 302 is a storage unit having, for example, a ROM, a RAM, and a flash ROM. Specifically, for example, a flash ROM or a ROM stores various programs, and the RAM is used as a work area for CPU 301. The programs stored in memory 302 are loaded into CPU 301 to cause CPU 301 to execute the coded processes.

[0057] The disk drive 303 controls reading / writing of data from / to the disk 304 under the control of the CPU 301. The disk 304 stores data written under the control of the disk drive 303. Examples of the disk 304 include a magnetic disk and an optical disk.

[0058] The communication I / F 305 is connected to a network (e.g., the network 210 and the ID distribution platform 220 shown in FIG. 2) through a communication line, and is connected to an external computer (e.g., the user terminal 202, the verification server 204, and the authentication server 205) through the network. The communication I / F 305 manages the interface between the network and the inside of the device itself, and controls the input and output of data from and to external devices.

[0059] The display 306 is a display device that displays a cursor, an icon, a tool box, and data such as documents, images, function information, etc. As the display 306, for example, a liquid crystal display or an organic EL (Electroluminescence) display can be adopted.

[0060] The input device 307 has keys for inputting characters, numbers, various instructions, etc., and is used to input data. The input device 307 may be a keyboard, a mouse, or a touch panel type input pad or numeric keypad.

[0061] The portable recording medium I / F 308 controls reading / writing of data from / to the portable recording medium 309 under the control of the CPU 301. The portable recording medium 309 stores data written under the control of the portable recording medium I / F 308. Examples of the portable recording medium 309 include a CD (Compact Disc)-ROM, a DVD (Digital Versatile Disk), and a USB (Universal Serial Bus) memory.

[0062] Of the above-mentioned components, signature device 201 may not necessarily have disk drive 303, disk 304, portable recording medium I / F 308, and portable recording medium 309. User terminals 202 and 203 shown in FIG. 2 may also be realized by a hardware configuration similar to that of signature device 201.

[0063] (Example of Hardware Configuration of Verification Server 204) Next, an example of the hardware configuration of the validation server 204 will be described.

[0064] Fig. 4 is a block diagram showing an example of the hardware configuration of the validation server 204. In Fig. 4, the validation server 204 has a CPU 401, a memory 402, a disk drive 403, a disk 404, a communication I / F 405, a portable recording medium I / F 406, and a portable recording medium 407. In addition, each component is connected to each other via a bus 400.

[0065] Here, the CPU 401 is responsible for the overall control of the verification server 204. The CPU 401 may have multiple cores. The memory 402 has, for example, a ROM, a RAM, and a flash ROM. Specifically, for example, the flash ROM stores an OS program, the ROM stores an application program, and the RAM is used as a work area for the CPU 401. The programs stored in the memory 402 are loaded into the CPU 401 to cause the CPU 401 to execute the coded processes.

[0066] The disk drive 403 controls reading / writing of data from / to the disk 404 under the control of the CPU 401. The disk 404 stores data written under the control of the disk drive 403. Examples of the disk 404 include a magnetic disk and an optical disk.

[0067] The communication I / F 405 is connected to a network (e.g., the network 210 and ID distribution platform 220 shown in FIG. 2) via a communication line, and is connected to an external computer (e.g., the signature device 201 and the user terminal 203 shown in FIG. 2) via the network. The communication I / F 405 manages the interface between the network and the inside of the device, and controls the input and output of data from the external computer. For example, a modem or a LAN adapter can be used as the communication I / F 405.

[0068] The portable recording medium I / F 406 controls reading / writing of data from / to the portable recording medium 407 under the control of the CPU 401. The portable recording medium 407 stores the data written under the control of the portable recording medium I / F 406.

[0069] In addition to the above-mentioned components, the validation server 204 may have, for example, an input device, a display, etc. Also, the validation server 204 may not have, for example, the disk drive 403, the disk 404, the portable recording medium I / F 406, and the portable recording medium 407 among the above-mentioned components. Also, the authentication server 205 shown in FIG. 2 can be realized by the same hardware configuration as the validation server 204.

[0070] (Contents stored in ID management table 230) Next, the contents stored in the ID management table 230 of the validation server 204 will be described with reference to Fig. 5. The ID management table 230 is realized by, for example, a storage device such as the memory 402 or disk 404 of the validation server 204 shown in Fig. 4.

[0071] Fig. 5 is an explanatory diagram showing an example of the contents stored in the ID management table 230. In Fig. 5, the ID management table 230 has fields for DID and nonce, and stores ID management information (for example, ID management information 500-1, 500-2) as records by setting information in each field.

[0072] Here, the DID is an identifier that uniquely identifies a user in the ID distribution infrastructure 220. The nonce is a random number that is assigned to a DID and is specific to the DID. For example, the management information 500-1 indicates the correspondence between the DID "X1ngMp9LRfyMEtNz7WdiLa" and the nonce "233cb0806bd5234c4946c4bee5be61ae".

[0073] (Example of credentials) Next, a specific example of the credential will be described with reference to FIG.

[0074] Fig. 6 is an explanatory diagram showing a specific example of a credential. In Fig. 6, credential 600 is an example of a credential (attribute certificate information) issued by authentication server 205. Credential 600 is information that certifies the attributes of a signer.

[0075] Here, the attributes of the signer are shown as job title "President", name "Fuji Taro", address "XXX, Nakahara Ward, Kawasaki City", date of birth "1 / 1 / 1988", My Number "123456...", and age "33". In addition, based on the electronic signature mechanism, the signature "XXXX" is affixed to credential 600 using the private key of the issuer (e.g., the certification company).

[0076] (Example of proof) Next, a specific example of proof will be described with reference to FIG.

[0077] Fig. 7 is an explanatory diagram showing a specific example of proof. In Fig. 7, proof 700 is an example of a proof (certificate information) created from credential 600 shown in Fig. 6. Proof 700 includes attribute information 710 and certification information 720.

[0078] The attribute information 710 includes disclosure attribute information 711, confidential attribute information 712, and condition proof information 713. The disclosure attribute information 711 is information to be disclosed among the credential 600. The confidential attribute information 712 is information in which attributes of the credential 600 that do not need to be disclosed are concealed by sanitization processing.

[0079] The condition proof information 713 is information (range proof) that proves that the age included in the credential 600 satisfies the condition that the age is 30 years old or older. The proof information 720 is information (multiple variable groups) for proving the attribute information 710. The proof information 720 includes, for example, a nonce. A specific example of the proof information 720 will be described later with reference to FIG. 8.

[0080] Fig. 8 is an explanatory diagram showing a specific example of proof information. In Fig. 8, proof information 800 (equivalent to, for example, the proof information 720 shown in Fig. 7) includes a set of responses of ZKP (Zero Knowledge Proof). "primary_proof" is a set of ZKP responses related to attributes. "revealed_attributes" indicates disclosed attributes.

[0081] name#1:value#1 etc. indicate the value of each disclosed attribute. The number of bits of each disclosed attribute's value depends on the value of each disclosed attribute. unrevealed_attributes indicates hidden attributes. mj_hat#1 etc. indicate the ZKP response of each hidden attribute.

[0082] credential_signature_ZKP indicates the ZKP response for the credential signature (a,e,v). predicate_attribute indicates the condition proof. u_hat1, u_hat4, etc. indicate the ZKP response to each condition proof.

[0083] "non_revoc_proof" indicates the ZKP response of the non-revocable proof. "aggregated_proof" indicates the challenge hash. According to the proof information 800, the correctness of the proof attributes can be verified by the ZKP protocol from the ZKP response and the challenge hash.

[0084] (Example of functional configuration of signature device 201) Fig. 9 is a block diagram showing an example of a functional configuration of signature device 201 according to the first embodiment. In Fig. 9, signature device 201 includes a receiving unit 901, an acquiring unit 902, a creating unit 903, a generating unit 904, and an output unit 905. The receiving unit 901 to the output unit 905 are functions that become a control unit, and specifically, the functions are realized by causing CPU 301 to execute a program stored in a storage device such as memory 302, disk 304, or portable recording medium 309 shown in Fig. 3, or by communication I / F 305. The processing results of each functional unit are stored in a storage device such as memory 302 or disk 304.

[0085] The reception unit 901 receives a signature request for an electronic document. The signature request is a request to attach a digital signature to the electronic document. The signature request includes the electronic document to be signed. In the following description, the electronic document to be signed may be referred to as "electronic document D."

[0086] Specifically, for example, the reception unit 901 receives a signature request for electronic document D by receiving the signature request from the user terminal 202 shown in Fig. 2. The reception unit 901 may also receive a signature request for electronic document D by a user's operation input using the input device 307 shown in Fig. 3.

[0087] The acquiring unit 902 acquires the signer's credentials (attribute certificate information) issued by a certification authority. Specifically, for example, the acquiring unit 902 acquires the credentials 600 (see FIG. 6) from the authentication server 205 (e.g., an authentication company) shown in FIG. 2 via the ID distribution infrastructure 220 in response to a signature request for electronic document D. However, the signer's credentials may be acquired in advance, for example, prior to the signature request for electronic document D.

[0088] In addition, the acquiring unit 902 acquires a nonce corresponding to the signer's DID from the validation server 204. Specifically, for example, the acquiring unit 902 transmits an offer to the validation server 204 shown in Fig. 2 in response to a signature request for electronic document D. The offer is a notification for requesting the validation server 204 to send a nonce required for creating a proof.

[0089] The offer includes, for example, the DID of the signer. Then, the acquiring unit 902 acquires the nonce corresponding to the DID of the signer by receiving the nonce from the validation server 204. However, the nonce corresponding to the DID of the signer may be acquired in advance, for example, prior to a signature request for the electronic document D.

[0090] The creation unit 903 creates a proof (certificate information) of the signer based on the signer's credentials. The proof includes the signer's attribute information, certification information for certifying the attribute information, and a nonce corresponding to the signer's DID. The attribute information is information that represents an attribute identified from the signer's credentials.

[0091] The attribute information includes, for example, at least one of information on an attribute included in the credential (disclosed attribute), information on the attribute included in the credential that has been concealed (concealed attribute), and information that proves that the attribute information included in the credential satisfies a specific condition (condition proof). The nonce corresponding to the signer's DID is the nonce acquired by the acquisition unit 902.

[0092] Specifically, for example, the creation unit 903 creates attribute information 710 by concealing attributes that do not need to be disclosed and proving whether a certain condition is satisfied based on the acquired credential 600 in response to a user's operational input. Furthermore, the creation unit 903 creates proof information 720 including the acquired nonce in response to a user's operational input. Then, the creation unit 903 creates proof 700 (see FIG. 7) including the created attribute information 710 and proof information 720 (including the nonce) in response to a user's operational input.

[0093] The generating unit 904 generates a digital signature for the digital document D and the proof. Specifically, for example, the generating unit 904 calculates a hash value of the digital document D. The hash value is calculated using a hash function (cryptographic one-way hash function). The hash value generated using the cryptographic one-way hash function is unique information that can only be generated from the original data, and has the characteristic that the original data cannot be restored from the generated hash value. In addition, the hash function makes it possible to compress data to a certain size (length), for example.

[0094] Next, the generating unit 904 creates proof 700 including the hash value of electronic document D by setting the calculated hash value of electronic document D in the corresponding field of proof 700. The generating unit 904 also calculates a hash value for proof 700 including the hash value of electronic document D.

[0095] The generation unit 904 then generates a digital signature by encrypting the calculated hash value using a private key corresponding to the signer's DID. The private key corresponding to the signer's DID is stored, for example, in the memory 302 or the disk 304. This makes it possible to sign the digital document D to which the proof 700 has been added. In the following description, the digital document D and the digital signature on the proof may be referred to as "digital signature S."

[0096] The output unit 905 outputs the electronic document D and the proof to which the generated electronic signature S has been attached in association with the signer's DID. The output format of the output unit 905 may be, for example, storage in a storage device such as the memory 302 or the disk 304, transmission to another computer via the communication I / F 305, display on the display 306, or the like.

[0097] Specifically, for example, the output unit 905 assigns the generated electronic signature S to the electronic document D and the proof in association with the signer's DID, and transmits them to the submitter of the electronic document D. Here, the submitter of the electronic document D corresponds to the sender who sends the electronic document D to the destination. The submitter of the electronic document D is, for example, the user terminal 202 that is the requester of the signature request for the electronic document D.

[0098] More specifically, for example, the output unit 905 assigns a digital signature S to the digital document D to which the proof 700 has been added. The output unit 905 then transmits a signed response to the requesting user terminal 202 via the network 210. The signed response includes the signer's DID, the digital document D to which the proof 700 has been added, and the digital signature S.

[0099] For example, when the user terminal 202 receives the signature response, it transmits via the network 210 the signer's DID included in the signature response, the electronic document D with the proof 700 added, and the electronic signature S to the user terminal 203, which is the destination of the electronic document D. The destination of the electronic document D corresponds to the recipient who receives the electronic document D sent from the submitter. Transmission to the destination is performed, for example, by email or the like.

[0100] (Example of Functional Configuration of the Verification Server 204) FIG. 10 is a block diagram showing an example of a functional configuration of the validation server 204 according to the first embodiment. In FIG. 10, the validation server 204 includes a reception unit 1001, a notification unit 1002, a verification unit 1003, an output unit 1004, and a storage unit 1010. The reception unit 1001 to the output unit 1004 are functions that become a control unit, and specifically, the functions are realized by making the CPU 401 execute a program stored in a storage device such as the memory 402, the disk 404, or the portable recording medium 407 shown in FIG. 4, or by the communication I / F 405. The processing results of each functional unit are stored in a storage device such as the memory 402 or the disk 404. The storage unit 1010 is realized by a storage device such as the memory 402 or the disk 404. Specifically, for example, the storage unit 1010 stores the ID management table 230 shown in FIG. 5.

[0101] The reception unit 1001 receives an offer. Here, the offer is a notification for requesting a nonce required to create a proof. Specifically, for example, the reception unit 1001 receives an offer from the user terminal 203 via the network 210. The offer includes, for example, the DID of the user (signer).

[0102] The notification unit 1002 notifies the user of a nonce corresponding to the DID. Specifically, upon receiving an offer, the notification unit 1002 creates a random number corresponding to the DID included in the offer (the DID of the communication partner). The created random number is a value that does not match any nonce corresponding to another DID.

[0103] To explain in more detail, for example, the notification unit 1002 may use a hash function to create a random number (random character string) from the credentials of a user (signer) identified by a DID. However, a nonce corresponding to the user's DID may be created in advance and stored in a storage device such as the memory 402 or the disk 404.

[0104] Then, the notification unit 1002 transmits the created random number as a nonce to the user terminal 203 that is the sender of the offer. The notification unit 1002 also stores the created nonce in the ID management table 230 shown in FIG. 5 in association with the DID of the user (signer).

[0105] The reception unit 1001 also receives the electronic document D and the proof to which the electronic signature S has been affixed, in association with the DID (first identifier) ​​of the signer. Specifically, for example, the reception unit 1001 receives a verification request from the user terminal 203 via the network 210. The verification request is, for example, a request to verify the authenticity of the electronic document D.

[0106] The verification request includes, for example, the signer's DID (first identifier), an electronic document D to which the proof has been added, and an electronic signature S. The proof includes a nonce (first value). The receiving unit 1001 then receives the signer's DID, the electronic document D to which the proof has been added, and the electronic signature S included in the received verification request.

[0107] The reception unit 1001 may receive a verification request by a user's operation input using an input device (not shown) of the verification server 204 .

[0108] The verification unit 1003 refers to the storage unit 1010, and detects fraud in the proof if the nonce (first value) included in the accepted proof does not match the nonce corresponding to the DID (first identifier). The storage unit 1010 stores information indicating the correspondence between the DID that uniquely identifies each user in the ID distribution infrastructure 220 and the nonce (random number) specific to the DID.

[0109] Specifically, for example, the verification unit 1003 refers to the ID management table 230 shown in Fig. 5 to identify a nonce corresponding to the received DID (first identifier). Next, the verification unit 1003 determines whether or not the nonce (first value) included in the received proof matches the identified nonce.

[0110] Here, if the nonce (first value) does not match the identified nonce, the verification unit 1003 detects that the proof is fraudulent. On the other hand, if the nonce (first value) matches the identified nonce, the verification unit 1003 does not detect that the proof is fraudulent.

[0111] The verification unit 1003 may refer to the ID management table 230 to identify a DID corresponding to the nonce (first value) included in the received proof. If the received DID (first identifier) ​​does not match the identified DID, the verification unit 1003 may determine that the nonce (first value) included in the proof does not match the nonce corresponding to the DID (first identifier).

[0112] Furthermore, the verification unit 1003 verifies the digital signature S by using a public key corresponding to the received DID. Specifically, for example, the verification unit 1003 calculates a hash value of the digital document D to which the proof is added. However, the verification unit 1003 uses the same hash function as that used when the digital signature S was generated in the signature device 201.

[0113] More specifically, for example, the verification unit 1003 calculates a hash value of the received electronic document D. Next, the verification unit 1003 creates a proof including the hash value of the electronic document D by setting the calculated hash value of the electronic document D in a corresponding field of the proof. Then, the verification unit 1003 calculates a hash value of the proof including the hash value of the electronic document D.

[0114] Next, the verification unit 1003 obtains a public key corresponding to the received DID, and uses the obtained public key to decrypt the digital signature S. The verification unit 1003 then compares the hash value obtained by decryption with the calculated hash value. If the hash values ​​match, the verification unit 1003 determines that the verification is OK (the digital document D with the proof added is correct).

[0115] On the other hand, if the hash values ​​do not match, the verification unit 1003 determines that the verification is NG (the electronic document D to which the proof is added is not correct). This makes it possible to verify the authenticity of the electronic document D to which the proof is added (that the electronic document D and the proof have not been tampered with).

[0116] Furthermore, the verification unit 1003 may determine, for example, whether or not a hash value of the received electronic document D matches a hash value of the electronic document D included in the proof. If the hash values ​​match, the verification unit 1003 determines that the received electronic document D has not been tampered with. On the other hand, if the hash values ​​do not match, the verification unit 1003 determines that the received electronic document D has been tampered with.

[0117] As a result, when the verification unit 1003 verifies the electronic signature S and the verification is NG (the electronic document D to which the proof is attached is not correct), for example, if the electronic document D has not been tampered with, the verification unit 1003 can detect that the proof has been fraudulently created.

[0118] The verification unit 1003 also verifies the authenticity of the proof based on the attribute information and certification information included in the accepted proof. The proof is verified, for example, using an existing protocol called zero-knowledge proof based on the attribute information (see FIG. 7), the certification information (see FIG. 8), and the public key of the issuer of the credential.

[0119] In zero-knowledge proof, the correctness of the proof attribute is verified by the ZKP protocol from the ZKP response and the challenge hash. To explain in more detail, for example, the verification unit 1003 verifies the correctness of the proof attribute from the value obtained by calculating the proof attribute and the challenge hash using a calculation method (e.g., AND, OR) determined in the ZKP response and the ZKP response ((proof attribute, challenge hash) → ZKP response).

[0120] The output unit 1004 outputs the verification result. The output form of the output unit 1004 may be, for example, storage in a storage device such as the memory 402 or the disk 404, or transmission to another computer via the communication I / F 405. Here, the verification result indicates whether or not fraud (unauthorized use) of the proof has been detected. The verification result may also indicate the authenticity (that it has not been tampered with) of the electronic document D to which the proof has been added. The verification result may also indicate the authenticity (that it has not been tampered with) of the proof.

[0121] Specifically, for example, the output unit 1004 transmits the verification result to the user terminal 203 that has made the verification request via the network 210. This makes it possible to confirm that the proof has not been used illegally and that the electronic document D and the proof have not been tampered with.

[0122] Furthermore, the verification result may include, for example, attribute information included in the proof. This makes it possible to confirm the attributes of the signer at the user terminal 203 (recipient).

[0123] The verification request may be a request to detect unauthorized use of the proof. In this case, the verification unit 1003, for example, only detects unauthorized use of the proof. Verification of the electronic signature S and verification that the proof has not been tampered with may be performed by the user terminal 203 (recipient).

[0124] (An example of detecting fraud in proof) Next, an example of detecting fraud in a proof will be described with reference to Figures 11 to 13. First, it is assumed that the sender of electronic document D (the requester of the signature request for electronic document D) is a malicious sender.

[0125] Fig. 11 is an explanatory diagram showing a first detection example of fraud in a proof. In Fig. 11, in response to an offer from a signer 1101 (signature device 201), the validation server 204 creates a nonce "abc" corresponding to the DIDa of the signer 1101 and registers it in the ID management table 230. In addition, the validation server 204 transmits the nonce "abc" corresponding to the DIDa of the signer 1101 to the signer 1101 (signature device 201).

[0126] The signer 1101 obtains the nonce "abc" corresponding to his / her own DIDa from the validation server 204. The signer 1101 creates a proof 1110 based on his / her own credentials. The proof 1110 includes the attribute information of the signer 1101, proof information for proving the attribute information, and the nonce "abc" corresponding to the signer's 1101 DIDa.

[0127] Next, the signer 1101 (signature device 201) generates a digital signature 1120 for the digital document D and the proof 1110, using a private key corresponding to his / her own DIDa. The signer 1101 (signature device 201) transmits the digital document D and the proof 1110, to which the digital signature 1120 has been affixed, to the sender 1102 (user terminal 202), in association with his / her own DIDa.

[0128] Here, it is assumed that the sender 1102 is a malicious sender who has spied on the nonce "abc" corresponding to the DIDa of the signer 1101 and created a proof 1130 based on his own credentials. The proof 1130 includes the attribute information of the sender 1102, proof information for proving the attribute information, and the nonce "abc" corresponding to the DIDa of the signer 1101.

[0129] The sender 1102 does not have a private key corresponding to the DIDa of the signer 1101. Therefore, the sender 1102 uses a private key corresponding to his / her own DIDe to generate a digital signature 1140 for the digital document D and the proof 1130. Specifically, for example, the sender 1102 (user terminal 202) first calculates a hash value of the digital document D.

[0130] Next, the sender 1102 (user terminal 202) creates proof 1130 including the hash value of electronic document D by setting the calculated hash value in the corresponding field of proof 1130. Next, the sender 1102 (user terminal 202) calculates the hash value of proof 1130 including the hash value of electronic document D.

[0131] The sender 1102 (user terminal 202) then encrypts the calculated hash value using a private key corresponding to its own DIDe to generate a digital signature 1140. The sender 1102 (user terminal 202) then transmits the digital document D with the proof 1130 added and the digital signature 1140 to the recipient 1103 (user terminal 203) in association with the DIDa of the signer 1101.

[0132] When the recipient 1103 (user terminal 203) receives the electronic document D to which the proof 1130 has been added and the electronic signature 1140 in association with the DIDa, the recipient 1103 transmits a verification request 1150 to the verification server 204. The verification request 1150 includes the DIDa of the signer 1101, the electronic document D to which the proof 1130 has been added, and the electronic signature 1140.

[0133] When the verification server 204 receives the verification request 1150, it verifies the electronic signature 1140 by using the public key corresponding to the DIDa of the signer 1101 included in the verification request 1150. Here, the electronic signature 1140 was generated by using the private key corresponding to the DIDe of the sender 1102.

[0134] For this reason, the result of the verification is NG (the electronic document D to which proof 1130 is added is not correct). If the hash value of the electronic document D to be verified included in the verification request 1150 matches the hash value of the electronic document D included in the proof 1130, then the electronic document D has not been tampered with.

[0135] In this case, the validation server 204 can detect that the proof 1130 has been fraudulently created. As a result, the validation server 204 can detect that the digital document D has been signed using the fraudulently created proof 1130.

[0136] Next, it is assumed that the signer of electronic document D (the recipient of the signature request for electronic document D) is a malicious signer.

[0137] Fig. 12 is an explanatory diagram showing a second example of detection of fraud in a proof. In Fig. 12, in response to an offer from a signer 1201 (signature device 201), the validation server 204 creates a nonce "abc" corresponding to the DIDa of the signer 1201 and registers it in the ID management table 230. In addition, the validation server 204 transmits the nonce "abc" corresponding to the DIDa of the signer 1201 to the signer 1201 (signature device 201).

[0138] The signer 1201 obtains the nonce "abc" corresponding to his / her own DIDa from the validation server 204. Here, it is assumed that the signer 1201 is a malicious signer who has illegally obtained another person's proof 1210. The proof 1210 includes the nonce "hij" corresponding to the other person's DIDb.

[0139] Next, the signer 1201 (signature device 201) generates a digital signature 1220 for the digital document D and the proof 1210, using a private key corresponding to his / her own DIDa. The signer 1201 (signature device 201) transmits the digital document D and the proof 1210, to which the digital signature 1220 has been affixed, to the sender 1202 (user terminal 202), in association with his / her own DIDa.

[0140] The sender 1202 (user terminal 202) transmits the electronic document D with the proof 1210 added and the electronic signature 1220 to the recipient 1203 (user terminal 203) in association with the DIDa of the signer 1201.

[0141] When the recipient 1203 (user terminal 203) receives the electronic document D to which the proof 1210 has been added and the electronic signature 1220 in association with the DIDa, the recipient 1203 transmits a verification request 1230 to the verification server 204. The verification request 1230 includes the DIDa of the signer 1201, the electronic document D to which the proof 1210 has been added, and the electronic signature 1220.

[0142] When the verification server 204 receives the verification request 1230, it refers to the ID management table 230 and identifies the nonce "abc" corresponding to the DIDa included in the verification request 1230. Next, the verification server 204 determines whether the nonce "hij" included in the proof 1210 included in the verification request 1230 matches the identified nonce "abc".

[0143] Here, the nonce "hij" does not match the identified nonce "abc." In this case, the validation server 204 detects the fraud (fraudulent acquisition) of the proof 1210. As a result, the validation server 204 can detect that the digital document D has been signed using the fraudulently obtained proof 1210.

[0144] Fig. 13 is an explanatory diagram showing a third example of detection of fraud in a proof. In Fig. 13, in response to an offer from a signer 1301 (signature device 201), the validation server 204 creates a nonce "abc" corresponding to the DIDa of the signer 1301 and registers it in the ID management table 230. In addition, the validation server 204 transmits the nonce "abc" corresponding to the DIDa of the signer 1301 to the signer 1301 (signature device 201).

[0145] Here, it is assumed that the signer 1301 is a malicious signer who has illegally obtained someone else's proof 1310 and rewritten the nonce "hij" included in that proof 1310 with the nonce "abc" corresponding to his or her own DIDa.

[0146] Next, the signer 1301 (signature device 201) generates a digital signature 1320 for the digital document D and the proof 1310, using a private key corresponding to his / her own DIDa. The signer 1301 (signature device 201) transmits the digital document D and the proof 1310 to which the digital signature 1320 has been added, in association with his / her own DIDa, to the sender 1302 (user terminal 202).

[0147] A sender 1302 (user terminal 202) transmits, to a recipient 1303 (user terminal 203), electronic document D to which proof 1310 has been added and an electronic signature 1320, in association with DIDa of the signer 1301.

[0148] When the recipient 1303 (user terminal 203) receives the electronic document D to which the proof 1310 has been added and the electronic signature 1320 in association with the DIDa, the recipient 1303 transmits a verification request 1330 to the verification server 204. The verification request 1330 includes the DIDa of the signer 1301, the electronic document D to which the proof 1310 has been added, and the electronic signature 1320.

[0149] When the verification server 204 receives the verification request 1330, it identifies the attribute information and the proof information from the proof 1310 included in the verification request 1330. Then, the verification server 204 verifies the authenticity of the proof 1310 based on the identified attribute information and the proof information. Here, the nonce included in the proof 1310 has been rewritten.

[0150] Therefore, the result of the verification is NG (proof 1310 has been tampered with). This enables the validation server 204 to detect that the digital document D has been signed using proof 1310 that was illegally obtained by rewriting the nonce (although other information may have been rewritten).

[0151] (Signature Processing Procedure of Signature Device 201) Next, a signature processing procedure of the signature device 201 will be described with reference to Fig. 14. The signature processing of the signature device 201 is executed in response to a signature request for a digital document D from the user terminal 202, for example.

[0152] Fig. 14 is a flowchart showing an example of a signature processing procedure of the signature device 201 according to the first embodiment. In the flowchart of Fig. 14, first, the signature device 201 transmits an offer to the validation server 204 (step S1401). The offer is a notification for requesting the validation server 204 to send a nonce required for generating a proof.

[0153] Next, signature device 201 judges whether or not a nonce corresponding to the signer's DID has been received from validation server 204 (step S1402). Here, signature device 201 waits to receive a nonce (step S1402: No).

[0154] When the signature device 201 receives the nonce (step S1402: Yes), the signature device 201 creates a proof of the signer based on the credentials of the signer (step S1403). The proof includes attribute information of the signer, proof information for proving the attribute information, and a nonce corresponding to the DID of the signer.

[0155] Next, the signature device 201 calculates a hash value of electronic document D (step S1404). Then, the signature device 201 calculates a hash value of a proof including the calculated hash value of electronic document D (step S1405). Next, the signature device 201 generates a digital signature by encrypting the calculated hash value using a private key corresponding to the signer's DID (step S1406).

[0156] Then, the signature device 201 outputs the electronic document D to which the generated electronic signature S has been attached in association with the signer's DID and the proof (step S1407), and ends the series of processes according to this flowchart. This makes it possible to verify the authenticity of the electronic document D and to detect any tampering with the proof used to confirm the attributes of the signer.

[0157] (Verification process procedure of the verification server 204) Next, a procedure of the validation process of the validation server 204 will be described with reference to Fig. 15. The validation process of the validation server 204 is executed in response to a validation request for the electronic document D (electronic signature S, proof) from the user terminal 203, for example.

[0158] 15 is a flowchart showing an example of a verification process procedure of the validation server 204 according to the first embodiment. In the flowchart of FIG. 15, first, the validation server 204 calculates a hash value of a digital document D (step S1501). The digital document D is included in a verification request from the user terminal 203, for example.

[0159] Next, the validation server 204 judges whether the calculated hash value matches the hash value of the electronic document D in the proof (step S1502). The proof is included in the validation request from the user terminal 203, for example.

[0160] If the hash values ​​do not match (step S1502: No), the validation server 204 detects that the electronic document D has been tampered with and determines that the validation is NG (step S1503).Then, the validation server 204 proceeds to step S1512.

[0161] On the other hand, if the hash values ​​do not match (step S1502: Yes), the verification server 204 acquires a public key corresponding to the signer's DID (step S1504). The signer's DID is included in, for example, the verification request from the user terminal 203. Then, the verification server 204 verifies the electronic signature S using the acquired public key (step S1505). The electronic signature S is included in, for example, the verification request from the user terminal 203.

[0162] Next, the validation server 204 judges whether the validation of the electronic signature S has been successful (step S1506). If the validation of the electronic signature S has failed (step S1506: No), the validation server 204 detects an illegality in the proof and determines the validation to be NG (step S1503). Then, the validation server 204 proceeds to step S1512.

[0163] On the other hand, if the verification of the digital signature S is successful (step S1506: Yes), the validation server 204 verifies the proof based on the attribute information and certification information included in the proof (step S1507). Next, the validation server 204 determines whether the verification of the proof is successful (step S1508).

[0164] If the verification of the proof fails (step S1508: No), the validation server 204 detects that the proof has been tampered with and determines the verification to be NG (step S1503).Then, the validation server 204 proceeds to step S1512.

[0165] On the other hand, if the proof is successfully verified (step S1508: Yes), the validation server 204 refers to the ID management table 230 and identifies the nonce corresponding to the signer's DID (step S1509). Then, the validation server 204 determines whether the nonce included in the proof matches the identified nonce (step S1510).

[0166] If the nonce does not match (step S1510: No), the validation server 204 detects an illegal proof and rejects the verification (step S1503). Then, the validation server 204 proceeds to step S1512.

[0167] On the other hand, if the nonce matches (step S1510: Yes), the validation server 204 determines that the validation is OK (step S1511) and outputs the validation result (step S1512). The validation result is output to, for example, the user terminal 203 that is the source of the validation request. This makes it possible to validate the authenticity of the electronic document D and detect any tampering with the proof used to confirm the attributes of the signer.

[0168] The order of execution of steps S1501 and S1502, steps S1504 to S1506, steps S1507 and S1508, and steps S1509 and S1510 may be interchanged. For example, steps S1509 and S1510 may be executed before steps S1501 and S1502.

[0169] As described above, according to the information processing system 200 of the first embodiment, the signature device 201 can obtain from the validation server 204 a nonce corresponding to a DID that uniquely identifies a user (signer) in the ID distribution infrastructure 220. The signature device 201 can also create a proof including attribute information identified from the user's credentials, proof information for proving the attribute information, and a nonce. The signature device 201 can then generate a digital signature S for the digital document D and the proof using a private key corresponding to the DID, and output the digital document D and the proof to which the generated digital signature S has been attached, in association with the DID.

[0170] This allows the signature device 201 to verify the authenticity of electronic document D and to detect any fraudulent use of the proof used to confirm the attributes of the signer. Furthermore, the signature device 201 can use a decentralized digital ID as an identifier that uniquely identifies a user (signer). Furthermore, by using a random character string as the nonce, the signature device 201 can make the nonce difficult to remember even if it is intercepted, thereby preventing fraudulent use.

[0171] Moreover, according to the information processing system 200, when generating a digital signature S for a digital document D and the proof, the signature device 201 can calculate a hash value of the digital document D and create a proof including the calculated hash value. Furthermore, the signature device 201 can calculate a hash value of the proof including the hash value of the digital document D and generate a digital signature by encrypting the calculated hash value using a private key corresponding to the signer's DID.

[0172] This enables the validation server 204 to verify, from the hash value included in the proof, whether or not the electronic document D has been tampered with.

[0173] Furthermore, according to the information processing system 200, the validation server 204 accepts the electronic document D and the proof to which the electronic signature S has been affixed, in association with a DID (first identifier) ​​that uniquely identifies a signer (user) in the ID distribution infrastructure 220. Then, the validation server 204 refers to the ID management table 230, and detects fraud in the proof if the nonce (first value) included in the proof does not match the nonce corresponding to the DID (first identifier).

[0174] This allows the validation server 204 to detect fraud in the proof used to verify the attributes of the signer. For example, it is possible to detect that the electronic document D has been signed using a proof that has been fraudulently obtained by a malicious signer.

[0175] Furthermore, according to the information processing system 200, the validation server 204 can validate the digital signature S by using a public key corresponding to the DID (first identifier) ​​of the signer.

[0176] This allows the validation server 204 to validate the authenticity of the electronic document D. For example, when the validation result of the electronic signature S is validation OK, the validation server 204 can detect that neither the electronic document D nor the proof has been tampered with. Also, when the validation result of the electronic signature S is validation NG, the validation server 204 can detect that at least one of the electronic document D and the proof has been tampered with.

[0177] Furthermore, according to the information processing system 200, the verification server 204 calculates a hash value of the electronic document D to be signed, and if the calculated hash value matches the hash value included in the proof, it can detect that the electronic document D has not been tampered with.

[0178] As a result, the verification server 204 can detect that the electronic document D was signed using a fraudulently created proof, for example, if the verification result of the electronic signature S is NG and the hash value of the electronic document D to be signed matches the hash value contained in the proof.

[0179] Furthermore, according to the information processing system 200, the validation server 204 can validate the proof based on the attribute information and certification information included in the accepted proof.

[0180] This allows the validation server 204 to detect that the proof has been tampered with. For example, the validation server 204 can detect that the digital document D has been signed using a proof that has been fraudulently obtained by rewriting the nonce.

[0181] For these reasons, the information processing system 200 according to the first embodiment can prevent unauthorized use of the proof attached to the electronic document D for verifying the attributes of the signer when verifying the authenticity of the electronic document D.

[0182] (Embodiment 2) Next, an information processing system 200 according to the second embodiment will be described. In the second embodiment, a signer can use the same nonce for proofs using different attributes, or can use the same proof for different electronic documents D. Note that the same reference numerals are used for the same parts as those described in the first embodiment, and illustrations and descriptions thereof will be omitted.

[0183] Fig. 16 is an explanatory diagram showing an example of providing proofs to multiple digital documents. In Fig. 16, proof 1610 is a proof created from credential 1600 of signer 1601 and nonce "abc" corresponding to the DID of signer 1601. Signer 1601 can use the same proof 1610 for different digital documents D as long as it is within a preset upper limit.

[0184] 16, proof1610 is added to electronic document D1 to be signed, and digital signature S1 is generated for electronic document D1 and proof1610. Furthermore, proof1610 is added to electronic document D2 to be signed, and digital signature S2 is generated for electronic document D2 and proof1610. Furthermore, proof1610 is added to electronic document D3 to be signed, and digital signature S3 is generated for electronic document D3 and proof1610.

[0185] This allows the signer 1601 to reduce the burden of creating proofs when signing multiple electronic documents D (e.g., electronic documents D1 to D3). Although not shown in the figure, the signer 1601 can use the same nonce "abc" for proofs using different attributes within a preset validity period.

[0186] (Example of functional configuration of signature device 201) Fig. 17 is a block diagram showing an example of a functional configuration of signature device 201 according to the second embodiment. In Fig. 17, signature device 201 includes a receiving unit 901, an acquiring unit 902, a creating unit 903, a generating unit 904, an output unit 905, and a setting unit 1701. The receiving unit 901 to the output unit 905 and the setting unit 1701 are functions that become a control unit, and specifically, the functions are realized by causing CPU 301 to execute a program stored in a storage device such as memory 302, disk 304, or portable recording medium 309 shown in Fig. 3, or by communication I / F 305. The processing results of each functional unit are stored in a storage device such as memory 302 or disk 304.

[0187] The following describes the processing contents of the functional units of the signature device 201 according to the second embodiment that are different from those of the functional units of the signature device 201 according to the first embodiment.

[0188] The setting unit 1701 sets the validity period of the acquired nonce. Here, the acquired nonce is a nonce corresponding to the signer's DID. The validity period is a period during which a proof including the acquired nonce can be created. The validity period can be set arbitrarily, and is set to, for example, about 10 minutes. The validity period is determined, for example, by agreement between the signer and the verifying organization (the organization that has the verification server 204). The designation of the validity period is accepted, for example, by the accepting unit 901.

[0189] The set validity period is stored in, for example, a first management table 1800 as shown in FIG. 18, which will be described later.

[0190] When creating a proof including the acquired nonce, the creation unit 903 judges whether the current time is within the set validity period. If it is within the validity period, the creation unit 903 creates a proof including the acquired nonce. On the other hand, if it is outside the validity period, the creation unit 903 does not create a proof including the acquired nonce.

[0191] In this case, the generating unit 903 may delete the acquired nonce. The acquired nonce is stored in a storage device such as the memory 302 or the disk 304. The acquiring unit 902 may also acquire a new nonce corresponding to the signer's DID by sending a new offer to the validation server 204.

[0192] Furthermore, the output unit 905 may output a notification urging the signer to obtain a new nonce if the validity period has expired. This notification is displayed, for example, on the display 306 (see FIG. 3). In response to this notification, the signer can obtain a new nonce corresponding to his / her own DID by submitting a new offer to the validation server 204.

[0193] The setting unit 1701 may also set the number of times the proof can be used that is created. Here, the number of times that the proof can be used that is created indicates the upper limit number of times that the proof can be used. The number of times that the proof can be used that is created can be set arbitrarily, for example, to about 10 times. The number of times that the proof can be used that is created is determined, for example, by an agreement between the signer and the verifying organization. The designation of the number of times that the proof can be used is received, for example, by the receiving unit 901.

[0194] The set effective usage count is stored in, for example, a first management table 1800 as shown in FIG. 18, which will be described later.

[0195] When creating a proof including the acquired nonce, the creating unit 903 may determine whether there is a previously created proof with the same required attributes. The required attributes are attributes (disclosure attribute, confidential attribute, condition proof) to be included in the proof (attribute information). The previously created proofs are stored in a storage device such as the memory 302 or the disk 304.

[0196] If there is a proof that has already been created with the same required attributes, the creation unit 903 judges whether the number of uses of the created proof exceeds the valid number of uses. If the valid number of uses is not exceeded, the creation unit 903 designates the created proof as the proof to be used this time. In this case, the generation unit 904 generates a digital signature S using the created proof. On the other hand, if the valid number of uses is exceeded, the creation unit 903 creates a proof that includes the acquired nonce.

[0197] (Storage contents of the first management table 1800) 18, the contents stored in the first management table 1800 of the signature device 201 will be described. The first management table 1800 is realized by a storage device such as the memory 302 or the disk 304, for example.

[0198] Fig. 18 is an explanatory diagram showing an example of the contents stored in a first management table 1800. In Fig. 18, the first management table 1800 has fields for nonce, remaining number of valid uses, validity period, and saved proof list, and stores management information (for example, management information 1800-1) as records by setting information in each field.

[0199] Here, nonce indicates the nonce corresponding to the DID of the signer (user of signature device 201). The remaining number of valid uses indicates the remaining number of valid uses of a proof that has already been created. The remaining number of valid uses is decremented each time a proof that has already been created is reused. The validity period indicates the validity period of the nonce. The validity period is represented by the start date and time (start) and end date and time (end) of the validity period. The stored proof list is a list of proofs that have already been created using a nonce.

[0200] For example, when creating a proof for a signer (a user of the signature device 201), the setting unit 1701 can refer to the first management table 1800 to determine whether the current time (time of creation) is within the validity period set for the nonce corresponding to the signer's DID.

[0201] Furthermore, when creating a proof for a signer, the setting unit 1701 can refer to the saved list in the first management table 1800 to determine whether or not there is a proof that has already been created with the same required attributes. Furthermore, the setting unit 1701 can refer to the remaining number of valid uses in the first management table 1800 to determine whether or not the number of uses of the created proof exceeds the number of valid uses.

[0202] (Signature Processing Procedure of Signature Device 201) Next, a signature processing procedure of the signature device 201 will be described with reference to Fig. 19. The signature processing of the signature device 201 is executed, for example, when signing a plurality of electronic documents D.

[0203] Fig. 19 is a flowchart showing an example of a signature processing procedure of the signature device 201 according to the embodiment 2. In the flowchart of Fig. 19, first, the signature device 201 selects an unselected electronic document D among electronic documents D to be signed (step S1901).

[0204] Then, the signature device 201 executes a proof creation process to create a proof of the signer (step S1902). A specific procedure of the proof creation process will be described later with reference to Figures 20 and 21. Next, the signature device 201 calculates a hash value of the electronic document D (step S1903).

[0205] Then, the signature device 201 calculates a hash value of the proof including the calculated hash value of the electronic document D (step S1904). Next, the signature device 201 generates a digital signature by encrypting the calculated hash value using a private key corresponding to the signer's DID (step S1905).

[0206] Then, the signature device 201 outputs the electronic document D to which the generated electronic signature S has been attached and the proof in association with the signer's DID (step S1906). Next, the signature device 201 determines whether or not there is an unselected electronic document D among the electronic documents D to be signed (step S1907).

[0207] If there is an unselected electronic document D (step S1907: Yes), the signature apparatus 201 returns to step S1901. On the other hand, if there is no unselected electronic document D (step S1907: No), the signature apparatus 201 ends the series of processes according to this flowchart.

[0208] This makes it possible to verify the authenticity of each electronic document D when signing multiple electronic documents D, and also makes it possible to detect any tampering with the proof used to verify the attributes of the signer.

[0209] Next, a specific procedure for generating proof in step S1902 will be described with reference to FIGS. 20 and 21.

[0210] 20 and 21 are flowcharts showing an example of a specific processing procedure of proof creation processing. In the flowchart of Fig. 20, first, the signature device 201 refers to the first management table 1800 and judges whether or not there is a created proof (step S2001). If there is no created proof (step S2001: No), the signature device 201 proceeds to step S2101 shown in Fig. 21.

[0211] On the other hand, if there is a proof that has already been created (step S2001: Yes), the signature device 201 judges whether the required attributes of the proof to be created this time are the same as those of the already created proof (step S2002). Note that the required attributes of the proof to be created this time are specified for the electronic document D by, for example, a user's operation input using the input device 307.

[0212] If the required attributes are not the same as those in the already-created proof (step S2002: No), the signature device 201 proceeds to step S2101 shown in FIG.

[0213] On the other hand, if the required attributes are the same as those of the already created proof (step S2002: Yes), signature device 201 refers to first management table 1800 and judges whether the remaining number of valid uses is 1 or more (step S2003). If the remaining number of valid uses is 0 (step S2003: No), signature device 201 proceeds to step S2101 shown in FIG.

[0214] On the other hand, if the remaining number of valid uses is 1 or more (step S2003: Yes), signature device 201 refers to first management table 1800 and judges whether the current time is within the validity period of the nonce included in the created proof (step S2004). If the current time is outside the validity period (step S2004: No), signature device 201 proceeds to step S2104 shown in FIG.

[0215] On the other hand, if it is within the valid period (step S2004: Yes), signature device 201 uses the previously created proof with the same required attributes as the proof to be used this time (step S2005). Then, signature device 201 decrements the remaining valid usage count (step S2006) and returns to the step that called the proof creation process.

[0216] 21, first, signature device 201 refers to first management table 1800 to determine whether or not there is a stored nonce (step S2101). If there is no stored nonce (step S2101: No), signature device 201 proceeds to step S2105.

[0217] On the other hand, if there is a stored nonce (step S2101: Yes), signature device 201 refers to first management table 1800 and determines whether the current time is within the validity period of the stored nonce (step S2102). If it is within the validity period (step S2102: Yes), signature device 201 creates a proof for the signer based on the signer's credentials (step S2103), and returns to the step that called the proof creation process.

[0218] On the other hand, if it is outside the validity period (step S2102: No), signature device 201 deletes the stored nonce (step S2104). Then, signature device 201 transmits an offer to validation server 204 (step S2105). The offer is a notification for requesting validation server 204 to transmit a nonce required for generating a proof. Note that in step S2105, the offer is transmitted in response to, for example, a user's operational input.

[0219] Next, signature device 201 judges whether or not a nonce corresponding to the signer's DID has been received from validation server 204 (step S2106). Here, signature device 201 waits to receive a nonce (step S2106: No). Then, when signature device 201 receives a nonce (step S2106: Yes), it sets the validity period of the nonce (step S2107) and proceeds to step S2103.

[0220] This makes it possible to reduce the processing load required for creating a proof when signing multiple electronic documents D, and the amount of communication (offer, nonce) between the signature device 201 and the verification server 204. In addition, by setting the validity period of the nonce and the number of valid uses of the proof, it is possible to prevent the nonce and proof from being used without limit, making them easier to manage.

[0221] Furthermore, the validity period of the nonce corresponding to the signer's DID and the number of valid uses of a created proof may be managed, for example, by the validation server 204. In this case, when verifying the authenticity of electronic document D, the validation server 204 may reject the verification if, for example, a nonce outside the validity period is used or a proof is used beyond the number of valid uses.

[0222] Note that an example of a functional configuration of the validation server 204 according to the second embodiment is similar to the example of the functional configuration of the validation server 204 according to the first embodiment (see FIG. 10), and therefore is not illustrated. Hereinafter, the processing contents that are different from those of the validation server 204 according to the first embodiment will be described with reference to FIGS. 22 to 24.

[0223] (Storage contents of the second management table 2200) Here, the contents stored in the second management table 2200 of the validation server 204 will be described with reference to Fig. 22. The second management table 2200 is realized by a storage device such as the memory 302 or the disk 304, for example.

[0224] Fig. 22 is an explanatory diagram showing an example of the contents stored in the second management table 2200. In Fig. 22, the second management table 2200 has fields for DID, nonce, remaining number of valid uses, validity period, and verified proof list, and stores management information (for example, management information 2200-1, 2200-2) as records by setting information in each field.

[0225] Here, the DID is an identifier that uniquely identifies a user in the ID distribution infrastructure 220. The nonce is a nonce that corresponds to the DID. The remaining number of valid uses indicates the remaining number of valid uses of a proof that has already been created. The validity period indicates the validity period of the nonce. The verified proof list is a list of verified proofs.

[0226] (Verification process procedure of the verification server 204) Next, the verification process procedure of the validation server 204 will be described with reference to Fig. 23. The validation process of the validation server 204 is executed in response to, for example, a verification request for a digital document D (digital signature S, proof) from the user terminal 203. In the case of a verification request for multiple digital documents D, the validation server 204 executes the verification process for each of the multiple digital documents D.

[0227] 23 is a flowchart showing an example of a verification process procedure of the validation server 204 according to the second embodiment. In the flowchart of FIG. 23, first, the validation server 204 calculates a hash value of a digital document D (step S2301). The digital document D is included in a verification request from the user terminal 203, for example.

[0228] Next, the validation server 204 judges whether or not the calculated hash value matches the hash value of the electronic document D in the proof (step S2302). The proof is included in the validation request from the user terminal 203, for example.

[0229] If the hash values ​​do not match (step S2302: No), the validation server 204 detects that the electronic document D has been tampered with and determines that the validation is NG (step S2303).Then, the validation server 204 proceeds to step S2314.

[0230] On the other hand, if the hash values ​​match (step S2302: Yes), the verification server 204 acquires a public key corresponding to the signer's DID (step S2304). The signer's DID is included in, for example, the verification request from the user terminal 203. Then, the verification server 204 verifies the electronic signature S using the acquired public key (step S2305). The electronic signature S is included in, for example, the verification request from the user terminal 203.

[0231] Next, the validation server 204 judges whether the validation of the electronic signature S has been successful (step S2306). If the validation of the electronic signature S has failed (step S2306: No), the validation server 204 detects an illegality in the proof and determines the validation to be NG (step S2303). Then, the validation server 204 proceeds to step S2314.

[0232] On the other hand, if the verification of the digital signature S is successful (step S2306: Yes), the validation server 204 executes a nonce validity determination process (step S2307). A specific procedure of the nonce validity determination process will be described later with reference to Fig. 24. Then, the validation server 204 judges whether the result of the determination is valid or not (step S2308).

[0233] If the determination result is not valid (step S2308: No), the validation server 204 detects that the nonce is invalid and determines the verification to be NG (step S2303).Then, the validation server 204 proceeds to step S2314.

[0234] On the other hand, if the proof is valid (step S2308: Yes), the validation server 204 verifies the proof based on the attribute information and certification information included in the proof (step S2309). Next, the validation server 204 determines whether the proof has been successfully verified (step S2310).

[0235] If the verification of the proof fails (step S2310: No), the validation server 204 detects that the proof has been tampered with and determines the verification to be NG (step S2303).Then, the validation server 204 proceeds to step S2314.

[0236] On the other hand, if the proof is successfully verified (step S2310: Yes), the validation server 204 refers to the second management table 2200 and identifies the nonce corresponding to the signer's DID (step S2311). Then, the validation server 204 determines whether the nonce included in the proof matches the identified nonce (step S2312).

[0237] If the nonce does not match (step S2312: No), the validation server 204 detects an illegal proof and rejects the verification (step S2303). Then, the validation server 204 proceeds to step S2314.

[0238] On the other hand, if the nonce matches (step S2312: Yes), the validation server 204 determines that the validation is OK (step S2313) and outputs the validation result (step S2314). The validation result is output to, for example, the user terminal 203 that made the validation request.

[0239] This makes it possible to verify the authenticity of electronic document D and detect fraud in the proof used to verify the attributes of the signer. It also makes it possible to determine the validity of the nonce and detect proofs that use invalid nonce.

[0240] A verified proof is registered in a list of verified proofs in the second management table 2200. Each time a proof is verified, the remaining number of valid uses corresponding to the nonce included in that proof is decremented. However, taking into consideration the case where a verification API (Application Programming Interface) is executed multiple times for the same proof, the verification server 204 does not change the remaining number of valid uses when verifying a verified proof. Verified proofs are identified from the list of verified proofs.

[0241] Next, a specific procedure for the nonce validity determination process in step S2307 will be described with reference to FIG.

[0242] Fig. 24 is a flowchart showing an example of a specific procedure for determining the validity of a nonce. In the flowchart of Fig. 24, first, the validation server 204 refers to the second management table 2200 and determines whether the remaining valid number of uses corresponding to the nonce included in the proof is 1 or more (step S2401).

[0243] If the remaining number of valid uses is 0 (step S2401: No), the validation server 204 proceeds to step S2404. On the other hand, if the remaining number of valid uses is 1 or more (step S2401: Yes), the validation server 204 refers to the second management table 2200 and determines whether the time when the proof was created is within the validity period of the nonce included in the proof (step S2402). The time when the proof was created is included in the proof, for example.

[0244] If it is within the validity period (step S2402: Yes), the validation server 204 determines that the nonce is valid (step S2403) and returns to the step where the nonce validity determination process was called. On the other hand, if it is outside the validity period (step S2402: No), the validation server 204 determines that the nonce is invalid (step S2404) and returns to the step where the nonce validity determination process was called.

[0245] This makes it possible to determine the validity of a nonce based on the validity period set for the nonce corresponding to the signer's DID and the number of valid uses set for the proof including that nonce. However, the validation server 204 does not have to determine the validity period or the number of valid uses.

[0246] According to the information processing system 200 according to the second embodiment described above, the signature device 201 can set, for an acquired nonce, a validity period during which a proof including the acquired nonce can be created. For example, when creating a proof including the acquired nonce, the signature device 201 determines whether the current time is within the set validity period. If it is within the validity period, the signature device 201 creates a proof including the acquired nonce. On the other hand, if it is outside the validity period, the signature device 201 does not create a proof including the acquired nonce.

[0247] This allows the signature device 201 to use the same nonce to create multiple proofs within the validity period, which reduces the processing load required for creating proofs when signing multiple electronic documents D, and the amount of communication (offers, nonce) with the validation server 204.

[0248] Furthermore, according to information processing system 200, signature device 201 can set the number of valid uses of a proof including an acquired nonce. For example, when creating a proof including an acquired nonce, signature device 201 determines whether or not there is a previously created proof with the same required attributes and whether the number of uses of the previously created proof exceeds the valid use number. If the valid use number is not exceeded, signature device 201 designates the previously created proof as the proof to be used this time. On the other hand, if the valid use number is exceeded, signature device 201 does not designate the previously created proof as the proof to be used this time.

[0249] As a result, the signature device 201 can use a created proof for a different electronic document D within the valid usage count. This allows the signature device 201 to reduce the processing load required for creating a proof when signing multiple electronic documents D, and the amount of communication (offer, nonce) with the validation server 204.

[0250] For these reasons, the information processing system 200 according to the second embodiment can speed up the process of assigning a proof to the electronic document D. Also, by allowing the use of multiple proofs using the same nonce, the size of the management table in the validation server 204 can be reduced compared to the case where a nonce is prepared for each electronic document D, for example.

[0251] The information processing method described in the present embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation. The information processing program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, a DVD, or a USB memory, and is executed by being read from the recording medium by the computer. The information processing program may also be distributed via a network such as the Internet.

[0252] In addition, the first information processing device 101 (signature device 201) and the second information processing device 102 (verification server 204) described in this embodiment can also be realized by application-specific ICs such as standard cells and structured ASICs (Application Specific Integrated Circuits) and PLDs (Programmable Logic Devices) such as FPGAs.

[0253] The following supplementary notes are further disclosed regarding the above-described embodiment.

[0254] (Supplementary Note 1) A value specific to an identifier that uniquely identifies a user in a system that can issue attribute certificate information of the user is obtained from a verification device that can verify the authenticity of an electronic document to be signed; creating certificate information including attribute information identified from the attribute certificate information, certification information for certifying the attribute information, and the acquired value; generating an electronic signature for the electronic document and the certificate information using a private key corresponding to the identifier; outputting the electronic document and the certificate information to which the generated electronic signature has been added in association with the identifier; An information processing program that causes a computer to execute a process.

[0255] (Supplementary Note 2) The information processing program according to Supplementary Note 1, wherein the value is set to a validity period during which certificate information including the value can be created.

[0256] (Appendix 3) The process for creating the above is as follows: When generating certificate information including the value, it is determined whether the current time is within the validity period; generating certificate information including the attribute information, the certification information, and the value if the validity period is within the validity period; 3. The information processing program according to claim 2,

[0257] (Supplementary Note 4) The information processing program according to any one of Supplementary Notes 1 to 3, wherein the value is set to an upper limit number of certificate information including the value that can be used.

[0258] (Supplementary Note 5) When creating certificate information including the value, it is determined whether there is already created certificate information with the same required attribute and whether the number of times the already created certificate information has been used exceeds the upper limit, If the upper limit number is not exceeded, the created certificate information is used as the certificate information to be used this time. 5. The information processing program according to claim 4,

[0259] (Supplementary Note 6) The information processing program according to any one of Supplementary Notes 1 to 5, wherein the identifiers are DIDs (Decentralized Identifiers).

[0260] (Supplementary Note 7) The information processing program according to any one of Supplementary Notes 1 to 6, wherein the value is a random character string.

[0261] (Appendix 8) In a system capable of issuing attribute certificate information of a user, a first identifier that uniquely identifies the user is associated with the electronic document and certificate information to which a digital signature is attached, and the electronic document and certificate information are received; referencing information indicating a correspondence between an identifier that uniquely identifies each user in the system and a value specific to the identifier, and detecting fraud in the certificate information when a first value included in the certificate information does not match a value corresponding to the first identifier; An information processing program that causes a computer to execute a process.

[0262] (Appendix 9) The electronic signature is verified using a public key corresponding to the first identifier. 9. The information processing program according to claim 8, which causes the computer to execute a process.

[0263] (Supplementary Note 10) The certificate information is verified based on attribute information and certification information included in the received certificate information. 10. The information processing program according to claim 8 or 9, which causes the computer to execute a process.

[0264] (Appendix 11) Obtaining a value specific to an identifier that uniquely identifies the user in a system that can issue attribute certificate information of the user from a verification device that can verify the authenticity of the electronic document to be signed; creating certificate information including attribute information identified from the attribute certificate information, certification information for certifying the attribute information, and the acquired value; generating an electronic signature for the electronic document and the certificate information using a private key corresponding to the identifier; outputting the electronic document and the certificate information to which the generated electronic signature has been added in association with the identifier; An information processing device comprising a control unit for executing processing.

[0265] (Appendix 12) In a system capable of issuing attribute certificate information of a user, a first identifier that uniquely identifies the user is associated with the electronic document and certificate information to which a digital signature is attached, and the electronic document and certificate information are received; referencing information indicating a correspondence between an identifier that uniquely identifies each user in the system and a value specific to the identifier, and detecting fraud in the certificate information when a first value included in the certificate information does not match a value corresponding to the first identifier; An information processing device comprising a control unit for executing processing.

[0266] (Supplementary Note 13) A system including a first information processing device that signs an electronic document to be signed, and a second information processing device that can verify the authenticity of the electronic document, The first information processing device, obtain from the second information processing device a value specific to an identifier which corresponds to an identifier that uniquely identifies a user in the system, create certificate information including attribute information specified from attribute certificate information of the user issued in the system, certification information for certifying the attribute information, and the obtained value, generate a digital signature for the electronic document and the certificate information using a private key corresponding to the identifier, and output the electronic document and the certificate information to which the generated digital signature has been attached, in association with the identifier; The second information processing device, the system receives an electronic document and certificate information to which an electronic signature has been affixed, in association with a first identifier that uniquely identifies a user in the system, and, by referring to information indicating a correspondence relationship between an identifier that uniquely identifies each user in the system and a value specific to the identifier, detects fraud in the certificate information if a first value included in the received certificate information does not match a value corresponding to the first identifier; 23. An information processing method comprising: [Explanation of symbols]

[0267] 101 First information processing device 102 Second information processing device 103,1101,1201,1301,1601 Signed by 104 Submitted by 105 Where to submit 110 System 120 Supported Information 121,700,1110,1130,1210,1310,1610 proof 122,D Electronic Documents 123,1120,1140,1220,1320,S Electronic signature 130,1150,1230,1330 Verification request 200 Information Processing Systems 201 Signature device 202,203 User terminal 204 Verification Server 205 Authentication Server 210 Network 220 ID Distribution Infrastructure 230 ID Management Table 300,400 Bus 301,401 CPU 302,402 Memory 303,403 Disk Drives 304,404 Disks 305,405 Communication I / F 306 Display 307 Input Device 308,406 Portable recording medium I / F 309,407 Portable recording media 600,1600 credentials 710 Attribute information 720,800 Certification Information 901,1001 Reception 902 Acquisition Department 903 Creation Department 904 Generation part 905,1004 Output section 1002 Notification Department 1003 Verification Department 1010 Storage section 1102,1202,1302 sender 1103,1203,1303 Recipients 1701 Setting Department 1800 First Management Table 2200 Second Management Table

Claims

1. obtaining, from a verification device capable of verifying authenticity of an electronic document to be signed, a value specific to an identifier that uniquely identifies the user in a system capable of issuing attribute certificate information of the user; creating certificate information including attribute information identified from the attribute certificate information, certification information for certifying the attribute information, and the acquired value; generating an electronic signature for the electronic document and the certificate information using a private key corresponding to the identifier; outputting the electronic document and the certificate information to which the generated electronic signature has been added in association with the identifier; An information processing program that causes a computer to execute a process.

2. 2. The information processing program according to claim 1, wherein the value is set to a validity period during which certificate information including the value can be created.

3. 3. The information processing program according to claim 1, wherein the value is set to an upper limit number of certificate information including the value that can be used.

4. receiving an electronic document and certificate information to which a digital signature has been added in association with a first identifier that uniquely identifies the user in a system capable of issuing attribute certificate information of the user; referring to information indicating a correspondence relationship between an identifier that uniquely identifies each user in the system and a value specific to the identifier, if a first value included in the certificate information does not match a value corresponding to the first identifier, detecting fraud in the certificate information; An information processing program that causes a computer to execute a process.

5. verifying the electronic signature using a public key corresponding to the first identifier; 5. The information processing program according to claim 4, which causes the computer to execute a process.

6. verifying the certificate information based on attribute information and certification information included in the received certificate information; 6. The information processing program according to claim 4, which causes the computer to execute a process.

7. obtaining, from a verification device capable of verifying authenticity of an electronic document to be signed, a value specific to an identifier that uniquely identifies the user in a system capable of issuing attribute certificate information of the user; creating certificate information including attribute information identified from the attribute certificate information, certification information for certifying the attribute information, and the acquired value; generating an electronic signature for the electronic document and the certificate information using a private key corresponding to the identifier; outputting the electronic document and the certificate information to which the generated electronic signature has been added in association with the identifier; An information processing device comprising a control unit for executing processing.

8. receiving an electronic document and certificate information to which a digital signature has been added in association with a first identifier that uniquely identifies the user in a system capable of issuing attribute certificate information of the user; referring to information indicating a correspondence relationship between an identifier that uniquely identifies each user in the system and a value specific to the identifier, if a first value included in the certificate information does not match a value corresponding to the first identifier, detecting fraud in the certificate information; An information processing device comprising a control unit for executing processing.

9. A system including a first information processing device that signs an electronic document to be signed, and a second information processing device that can verify authenticity of the electronic document, The first information processing device, obtain from the second information processing device a value specific to an identifier which corresponds to an identifier that uniquely identifies a user in the system, create certificate information including attribute information specified from attribute certificate information of the user issued in the system, certification information for certifying the attribute information, and the obtained value, generate a digital signature for the electronic document and the certificate information using a private key corresponding to the identifier, and output the electronic document and the certificate information to which the generated digital signature has been attached, in association with the identifier; The second information processing device, the system receives an electronic document and certificate information to which an electronic signature has been affixed, in association with a first identifier that uniquely identifies a user in the system, and, by referring to information indicating a correspondence relationship between an identifier that uniquely identifies each user in the system and a value specific to the identifier, detects fraud in the certificate information if a first value included in the received certificate information does not match a value corresponding to the first identifier; 23. An information processing method comprising:

Images