Information processing terminal, machine learning method, information processing method, and program

Abstract

The purpose of the present disclosure is to reduce a storage usage amount, network communications, and costs such as participant incentives, while ensuring the security of proof of existence (time stamp).　To achieve this purpose, provided is an information processing terminal that implements an electronic signature according to a proof of existence, wherein each participant of the electronic signature individually generates a random number, and a participation management unit is provided that participates as an information processing terminal related to a signer if the random number is less than a threshold value.

Description

[Technical Field]

[0001] The present disclosure relates to a technology for implementing digital signatures using proof of existence (timestamps) at the information processing terminals of multiple signers. [Background technology]

[0002] In recent years, there has been a growing call for data utilization using AI (artificial intelligence), and motivation for its use is spreading throughout society. However, practical application has not progressed due to a lack of data volume and concerns about the security of data sharing. To solve this problem, there is a need for a data distribution platform that anyone can use safely and at low cost.

[0003] Furthermore, data distribution platforms can be divided into centralized models, in which a trusted third party (TPP) such as a service provider is trusted to handle all processing, and decentralized models, in which participants verify safety without trusting others. Given the current situation in which data sharing is not progressing due to concerns about data misuse by service providers, a decentralized data distribution platform that is not based on trust in others is desirable. Known examples of decentralized data distribution platforms include Bitcoin and Blockene (Non-Patent Documents 1 and 2), which use blockchain, and a method of building a ledger platform based on a directed acyclic graph (DAG) to improve cost and performance (Non-Patent Document 3).

[0004] An important function of data distribution platforms is "proof of existence (timestamp)," which proves that data existed at a certain time. However, the above method cannot confirm the security of proof of existence if there is no trust in the signer (i.e., if a decentralized trusted third party (TTP) is not assumed).

[0005] Therefore, in order to perform proof of existence safely in a decentralized data distribution platform, methods have been proposed that ensure security by using data sharing and consensus processing (Non-Patent Documents 4, 5, 6). [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" [Non-patent document 2] Sambhav Satija, Apurv Mehra, Sudheesh Singanamalla, Karan Grover, Muthian Sivathanu, Nishanth Chandran, Divya Gupta, and Satya Lokam. 2020. Blockene: a high-throughput blockchain over mobile devices. Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation. USENIX Association, USA, Article 32, 567-582. [Non-patent document 3] Wang, Q., Yu, J., Chen, S., and Xiang, Y., "SoK: Diving into DAG-based Blockchain Systems", arXiv e-prints, 2020. [Non-patent document 4] Colin LeMahieu, "Nano: A Feeless Distributed Cryptocurrency Network", 2017 [Non-patent document 5] L. Baird and A. Luykx, "The Hashgraph Protocol: Efficient Asynchronous BFT for High-Throughput Distributed Ledgers," 2020 International Conference on Omni-layer Intelligent Systems (COINS), 2020, pp. 1-7, doi: 10.1109 / COINS49042.2020.9191430. [Non-patent document 6] Quan Nguyen, Andre Cronje, Michael Kong, Egor Lysenko, Alex Guzev, "Lachesis: Scalable Asynchronous BFT on DAG Streams", 2021 Summary of the Invention [Problem to be solved by the invention]

[0007] However, the methods described in Non-Patent Documents 4, 5, and 6 all require the shared management of each individual or organization's blockchain to detect inconsistencies, which requires large-capacity storage and high-speed networks to manage all blockchain information on the nodes that make up the system. Implementing such nodes is costly, impairs scalability, and creates a relationship of providing and receiving resources between node providers and resource users. For example, while system providers provide resources, those who generally use Bitcoin or similar cryptocurrencies do not provide resources themselves, resulting in a shortage of node providers. Furthermore, these systems rely on the number of node participants to ensure security, which increases incentives for node providers and user costs in order to ensure a high number of participants.

[0008] The present invention has been made in consideration of the above points, and aims to reduce costs such as storage usage, network communication, and participant incentives while ensuring the security of existence proofs (timestamps). [Means for solving the problem]

[0009] In order to solve the above problem, the invention of claim 1 is an information processing terminal that performs electronic signatures using proof of existence, and has a participation management unit in which each participant in the electronic signature individually generates a random number, and if the random number is less than a threshold, the information processing terminal participates as an information processing terminal related to the signer. [Effects of the Invention]

[0010] As described above, according to the present invention, it is possible to reduce costs such as storage usage, network communication, and participant incentives while ensuring the security of existence proofs. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a diagram illustrating the overall configuration of an existence proof system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram illustrating an electrical hardware configuration of the information processing terminal according to the present embodiment. [Figure 3] 1 is a flowchart showing the concept of signature security. [Figure 4] FIG. 10 is a diagram showing countermeasures against forged signatures using local chains. [Figure 5] FIG. 10 is a sequence diagram showing the processing of the existence proof system. [Figure 6] FIG. 10 is a sequence diagram showing the processing of the existence proof system. [Figure 7] 10 is a flowchart showing a process relating to a signature. [Figure 8] 10 is a flowchart showing a process related to verification that does not assume malicious intent; [Figure 9] 10 is a flowchart showing a process related to verification that does not assume malicious intent; [Figure 10] FIG. 10 is a diagram showing an example of data content in each process. DETAILED DESCRIPTION OF THE INVENTION

[0012] [System configuration of the embodiment] Hereinafter, an embodiment of the present invention will be described with reference to FIGS.

[0013] First, the overall configuration of an existence proof system according to an embodiment will be described with reference to Fig. 1. Fig. 1 is an overall configuration diagram of an existence proof system according to an embodiment.

[0014] The existence proof system is constructed by a plurality of information processing terminals of participants of electronic signatures (hereinafter sometimes simply referred to as "signatures"). In Fig. 1, the information processing terminals of the plurality of participants are shown on the left side, and the information processing terminals of those who have become signers among the plurality of information processing terminals on the left side are shown on the right side. Here, an information processing terminal 10 of an arbitrary participant and an information processing terminal 10a of a requester a of a signature are shown. Also shown are an information processing terminal 10d of signer d and an information processing terminal 10e of signer e, who have become signers among the participants. Note that, In FIG. 1, signers d and e of information processing terminals 10d and 10e randomly join the signer group according to a random variable p. Information processing terminal 10a requests information processing terminals 10d and 10e to sign. When a signature request is received, the information processing terminals of all signers (information processing terminals 10d and 10e in this case) cooperate to execute the signature. The signature is stored among the information processing terminals of all signers (information processing terminals 10d and 10e in this case) and is also stored in information processing terminal 10a of requester a.

[0015] The functional configuration of the arbitrary information processing terminal 10 will be explained later. The arbitrary information processing terminal 10 includes information processing terminals 10a, 10d, and 10e.

[0016] <Use Case> On the posting (information processing terminal 10a) side, timestamps for posting information (blogs, messages, etc.), transaction records, receipts, etc. are decentralized without relying on TTP.

[0017] Receiving side (information processing terminal 10d): The timestamp verification of the information presented by the other party is performed in a decentralized manner without relying on TTP.

[0018] <Application example> (1) To guarantee the time of data creation for a message written on a smartphone (an example of the information processing terminal 10a), a photograph taken, or the body of an email about a transaction, the signature requester assigns local chain information to the signature subject and requests a randomly selected signer. The participants in the signature process utilize the available resources of the smartphone (an example of the information processing terminals 10d and 10e) to automatically sign, thereby achieving free electronic signatures.

[0019] (2) The signature requester is the same as in (1) above, but the signature participants are assumed to be blockchain miners. The signature participants sign using their free mining resources.

[0020] [Hardware configuration] FIG. 2 is a diagram showing the electrical hardware configuration of the information processing terminal.

[0021] As shown in FIG. 2, the information processing terminal 10 is a computer and includes a CPU 101, a ROM 102, a RAM 103, an SSD 104, an external device connection I / F (Interface) 105, a network I / F 106, a display 107, an input device 108, a media I / F 109, and a bus line 110.

[0022] Of these, the CPU 101 as a processor controls the overall operation of the information processing terminal 10. The ROM 102 stores programs such as IPL used to drive the CPU 101. The RAM 103 is used as a work area for the CPU 101.

[0023] The SSD 104 reads or writes various data under the control of the CPU 101. Note that instead of the SSD 104, an HDD (Hard Disk Drive) may be used.

[0024] The external device connection I / F 105 is an interface for connecting various external devices, such as a display, a speaker, a keyboard, a mouse, a USB memory, and a printer.

[0025] The network I / F 106 is an interface for performing data communication via a communication network such as the Internet.

[0026] The display 107 is a type of display means such as a liquid crystal display or organic EL (Electro Luminescence) display that displays various images.

[0027] The input device 908 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. Examples of the input device 908 include a pointing device and a touch panel.

[0028] The media I / F 109 controls reading and writing (storing) of data from and to a recording medium 109m such as a flash memory, etc. The recording medium 109m includes DVDs, Blu-ray Discs (registered trademarks), etc.

[0029] The bus line 110 is an address bus, a data bus, etc. for electrically connecting the components such as the CPU 101 shown in FIG.

[0030] [Functional configuration of information processing terminal] Returning to Fig. 1, any information processing terminal 10 has a random signature unit 11. The random signature unit 11 is a function realized by instructions from the CPU 101 in Fig. 2 based on a program. The random signature unit 11 also has subordinate functional units, including an electronic signature unit 12, a participation management unit 13, a ledger management unit 14, and a verification unit 15.

[0031] The random signature unit 11 acts as an intermediary for the subordinate functional units and provides a user UI for "information submission" and "ledger verification."

[0032] The digital signature unit 12 executes signature and verifies the signature in cooperation with the information processing terminal 10 of the (ring) signatory by synchronizing time and signing with proof of existence (timestamp) for the signature request information.

[0033] The participation management unit 13 makes a participation decision within a time span agreed upon in the signature system and raises its hand as a signer's terminal with probability p. The participation management unit 13 also raises its hand as a signer's terminal when posting information, and at the same time shares its own signature request.

[0034] The ledger management unit 14 manages the ledger of the local chain closed within each terminal. When participating as a signer, the ledger management unit 14 shares the latest state of the ledger with the information processing terminals of other signers, generates a new signature based on the information indicating the latest state, and connects it to the ledger it manages as a local chain of signatures, thereby ensuring security.

[0035] The verification unit 15 verifies the signature and the conditions, and searches for a matching signature by comparing the local chain of the presented signature with the local chain of the signature of its own terminal.

[0036] Note that random signature units 11a, 11d, and 10e of information processing terminals 10a, 10d, and 10e have the same functions as random signature unit 11. Similarly, electronic signature units 12a, 12d, and 12e have the same functions as electronic signature unit 12. Participation management units 13a, 13d, and 13e have the same functions as participation management unit 13. Ledger management units 14a, 14d, and 14e have the same functions as ledger management unit 14. Verification units 15a, 15b, and 15e have the same functions as verification unit 15.

[0037] [Concept of signature security] Next, before describing the processing of this embodiment, the concept of signature security will be described with reference to Fig. 3. Fig. 3 is a flowchart showing the concept of signature security. Here, the concept of signature security is shown.

[0038] S1: Is the signer trustworthy?

[0039] S2: If the signer is trustworthy (S1; True), verify the signature.

[0040] S3: If the signer is not trustworthy (S1; False), trust is ensured by gathering a certain number of signers.

[0041] S4: Furthermore, verify that the protocol operation is reliable.

[0042] S5: If the protocol operation is trustworthy (S4; True), that is, in the case of a semi-honest attacker, there is always a trustworthy signer among the signers, and any forged signatures will be reported. Also, signatures that are not reported are trustworthy.

[0043] S6: If the protocol operation cannot be trusted (S4; False), that is, in the case of a malicious attacker, all signatures are connected as a graph. By evaluating the connection between the verifier's signature and the signature to be verified, the target signature can be trusted based on trust in the verifier's own signature.

[0044] In this embodiment, the contents relating to S3 to S6 will be proposed.

[0045] Figure 4 shows countermeasures against forged signatures using local chains.

[0046] Figure 4(A) shows a local chain consisting of valid signatures, which indicates a pass in verification, including the order of signatures.

[0047] Figure 4(B) shows a local chain with forged signature 2 as a countermeasure against S5(a) in Figure 3. The "time -5" in signature 2 means that verification, including the order of the signature, is invalid.

[0048] Figure 5(C) shows a local chain in which all signatures from signature 2 onwards are forged, as a countermeasure against S5(a) and S6(b) in Figure 3. Even if further forgeries are attempted, NG verification is possible using the signatures of the verifier chain.

[0049] [Security Considerations (Signer Reliability)] Next, consideration of security (trustworthiness of the signer) will be explained.

[0050] The reliability of the signatory is ensured by the number of signing participants.

[0051] 1. Calculate the number of participants in the signature according to the assumed upper limit of the attacker's percentage Given the proportion of good citizens, α, we want to calculate the lower bound of the number of good citizens. The idea is to find the lower bound, eg, that is negligible (2-30=9.3132257e-10) by a probability test for the possible fluctuations, eg, that can occur for the proportion of good citizens, α.

[0052] The proportion of good citizens, α, can be set to several conditions, such as 51% or more, 2 / 3 or more, or 1 / 3 or more, depending on the assumptions of the blockchain. Since a signature is valid as long as there is at least one good citizen who correctly verifies the time in the signature, we want to find the minimum number of signing participants, n, that has at least one good citizen. (1) If the number of attackers / total number of participants is less than 1 / 3, then if there are 24 signers, there is a probability that there will be one honest signer. (2) If the number of attackers / total number of participants is less than 1 / 2, then if there are 37 signers, there is one honest signer. (3) If the number of attackers / total number of participants is less than 2 / 3, then if there are 63 signers, there is one honest signer.

[0053] For example, in (1) above, if the number of attackers among all participants is less than 1 / 3, then if there are 24 signers, it is assumed that there is at least one honest person. This is based on the idea that it is virtually impossible for there to be zero honest people, since the probability that there are no honest people is only about (1 / 9)^-10. Also, in the case of (1) above, if we collect 24 signers, we can derive from the proportion of attackers among the total that there will be at least one honest person. If we can assume that there are no attackers less than 1 / 3, then we can say that if we collect 24 people, there will definitely be at least one honest signer.

[0054] 2. Calculate the signature participation probability p according to the number of signature participants and the number of system subscribers M (= denominator in the example below) This embodiment is characterized by deriving a probability p that there is always at least one honest signer among the signers.

[0055] If all M devices participate in a vote as clients in a particular round with a probability of p = n / M (determined according to a Bernoulli distribution with a binary choice of whether to participate or not), then the upper and lower bounds on the number of participants can be calculated. The idea is to find an ec such that the probability of a fluctuation of more than ec occurring for the probability of p is negligible (2^-30 = 9.3132257e-10) using a probability test. The lower bound n* on the number of participants can be said to be M(p-ec) if an ec can be selected where the probability exp(-KL(p-ec,p)n) such that n* = M(p-ec) is sufficiently small. (1) Example of probability of signature participation when collecting at least 24 signers: p=64 / 100, 74 / 1000, 125 / 10000, 1024 / 100000 (2) Example of probability of signature participation when collecting at least 37 signers: p=68 / 100, 96 / 1000, 138 / 10000, 1037 / 100000 (3) Example of probability of signature participation when collecting at least 63 signatures: p=89 / 100, 133 / 1000, 163 / 10000, 1063 / 100000 〔supplement〕 As a supplement, we will show an example of the probability p of signing participation when N signers are gathered (for each condition α) so that at least one of the M participants is guaranteed to be honest.

[0056] Here, whether or not to become a signer is decided based on the probability that "if it is less than p, I will participate as a signer, but if it is p or greater, I will not participate as a signer." This is like deciding whether or not to become a signer by rolling a die that indicates "if it is less than p, I will participate as a signer, but if it is p or greater, I will not participate as a signer."

[0057] (1) α=1 / 3: When the attacker is less than 2 / 3M and the honest user is more than 1 / 3M ·for N = 63 n = 89 M = 100 p = 0.89 ·for N = 63 n = 125 M = 1000 p = 0.125 ·for N = 63 n = 130 M = 10000 p = 0.013 ·for N = 63 n = 134 M = 100000 p = 0.00134 ·for N = 63 n = 164 M = 1000000 p = 0.000164 For example, in the third example from the top, if there are 10,000 participants, approximately 130 of them will be signers. In this case, the amount of data that needs to be stored is 0.013 times larger than in the case of existing blockchains.

[0058] (2) α=1 / 2: When the attacker is less than 1 / 2M and the honest user is more than 1 / 2M ·for N = 37 n = 69 M = 100 p = 0.69 ·for N = 37 n = 89 M = 1000 p = 0.089 ·for N = 37 n = 93 M = 10000 p = 0.0093 ·for N = 37 n = 98 M = 100000 p = 0.00098 ·for N = 37 n = 138 M = 1000000 p = 0.000138 (3) α=1 / 3: When the attacker is less than 1 / 3M and the honest user is more than 2 / 3M ·for N = 24 n = 56 M = 100 p = 0.56 ·for N = 24 n = 70 M = 1000 p = 0.07 ·for N = 24 n = 71 M = 10000 p = 0.0071 ·for N = 24 n = 75 M = 100000 p = 0.00075 ·for N = 24 n = 125 M = 1000000 p = 0.000125 [Safety Considerations] Next, as a consideration of security, the reliability of signature information will be explained.

[0059] <Reliability of signature information 1> 1.Semi-honest attacker: If the signer does not deviate from the operational protocol, security can generally be verified using only the electronic signature made for individual information based on the probability of signature participation.

[0060] If only one user (participant) is honest, another participant (attacker) may create a signature that excludes the honest user. To counter this, the honest user can share counter information about the time error and use it in the next signature to detect the forged signature.

[0061] 2. Malicious attackers: Considering an attacker who deviates from the protocol and manipulates the random variable p, it would be possible for the attacker to sign on his own by managing signing participants in a separate system that does not include honest users.

[0062] (1) If only one "attack using a signature for proof of existence = signing at an incorrect time in the past" is performed, the validity of the target signature can be verified by comparing the local chain of the signature with the previous and following signature times (times).

[0063] (2) If an attack using signatures for proof of existence (signing until the correct time at an incorrect past time of existence) is continued, it is not possible to detect an error in the target signature by comparing the local chain of signatures with the previous and following signature times (times). Since signatures are continued, only the attacker will sign during the period when signatures continue, and no signatures will be made by the Honest User. Therefore, verification becomes possible by examining the connection in the signature chain from the Honest User to the signature to be verified.

[0064] If a malicious attacker is suspected during signature verification taking the above into consideration, the verification requester does not simply send the signature to the verifier, but collects the signatures recorded after the signature to be verified and compares them with the verifier's signature to confirm their existence.

[0065] <Reliability of signature information 2> Verifiability in the case of a malicious attacker: As a Sybil, we consider the possibility of deviating from the protocol and independently assigning a signature. In particular, since each individual manages their own signature, the only way to obtain signatures from others is to use the presented information.

[0066] (1) To detect forgery of the local chain of the presented signature itself, it is possible to use a buffer period, which is the time until the verifier's signature is added to the local chain of the signature. In this case, the buffer period varies greatly, from a few minutes to a few days, depending on the system's signature participation probability p.

[0067] The probability of overlap between the verifier and the signature holder's local chain: p 2 In this case, when the holder of the signature to be verified and the verifier bring together γ signatures made immediately after the signature to be verified, the probability that the verifier and the signer have never signed the same signature is (1-p 2 )γ However, since γ signatures have already been executed, the posterior probability is (1 - p). γ is obtained.

[0068] (1 - p) γ The negligible number of signatures γ can be calculated based on p, and it can be shown that there must be a signature by the verifier within a certain number of signatures. However, considering the signature interval (the round period during which one does not participate in the signature with a probability of p), a certain buffer period occurs until verification is possible.

[0069] (2) As a method for shortening the buffer in the above recent case (1), consider the spread of signatures and related parties connected in a tree shape. In the system, joint signatures by multiple third parties are performed each time one participates in the signature as a Bernoulli trial. By tracing that tree, it was found through simulation that it is necessary to verify 500 to 900 signatures (a delay time of about 5 hours if one signature is made every 10 seconds) until everyone can verify the signatures of others.

[0070] [Determination of Participants in Each Signature Round] Subsequently, the determination of participants in each signature round will be explained.<0OO0310>

[0071] As synchronization of processing in the information processing terminals of each signatory (for example, information processing terminals 10d, 10e), the information processing terminals of each signatory refer to an external time server or other blockchains and participate in a DHT (Distributed Hash Table) created every few seconds. Signing is started after setting a certain communication buffer.

[0072] [Signature Conditions and Processing Flow] Subsequently, the signature conditions and processing flow will be explained. Here, the use of BLS (Boneh-Lynn-Shacham) signatures will be explained.

[0073] 1. Information Synchronization (1) The information processing terminal 10 determines the "total information to be signed" target_m by consensus among participants such as Raft (a distributed consensus algorithm) or rules. If there is a time error, the information processing terminal 10 requests the honest user to refute it. If the majority of Byzantine nodes do not include a refutation, the information processing terminal 10 requests the honest user to include the "list of participating nodes," the agreed-upon "total information to be signed" target_m, and evidence of the refutation (hash information of the current time on an external decentralized platform) in the next round, thereby preventing the subsequent distribution of the signatures created in all rounds with Byzantine nodes. (2) The information processing terminal of each signer i performs a pairing signature on the message “m_i = target_m + t_i” created from “all information to be signed” target_m and the latest transaction hash t_i on the local chain.

[0074] 2.Signature sharing (1) The information processing terminal 10 determines the “list of signatures” using Raft. (2) The information processing terminal 10 generates one signature s by aggregating the pairing signatures (Reference 1). (3) Each signer i and requester j connects the combination of signature s and target_m to the local chain. <Reference 1> Aggregate and Verifiably Encrypted Signatures from Bilinear Maps (https: / / crypto.stanford.edu / ~dabo / pubs / papers / aggreg.pdf) 3. Signature Verification (1) The information processing terminal 10 verifies whether the signature is shared as a Byzantine node. (2) The information processing terminal 10 performs signature verification using the signature s and target_m+the latest transaction hash t_i on the local chain and the public key of i, by using pairing signature aggregation (Reference 1).

[0075] [Proof of Existence System Processing] Next, the processing of the existence proof system according to this embodiment will be described with reference to Figs. 5 to 10. Figs. 5 and 6 are sequence diagrams showing the processing of the existence proof system. Fig. 5 in particular shows the processing when posting information (when signing). Also, Fig. 6 in particular shows the processing when referencing (when verifying the signature). Fig. 7 is a flowchart showing the processing related to signatures. Fig. 8 is a flowchart showing the processing related to verification that does not assume maliciousness. Fig. 9 is a flowchart showing the processing related to verification that assumes maliciousness. Fig. 10 is a diagram showing an example of the content of data in each process.

[0076] Here, as shown in Figures 5 and 6, information processing terminals 10a, 10b, 10c, 10d, 10e, and 10f of participants a, b, c, d, e, and f are shown, but due to space limitations, only six information processing terminals are shown, and in actual operation, more information processing terminals will participate. In Figures 5 and 6, information processing terminal 10a is the terminal of the information sender (signature requester). Information processing terminals 10d and 10e are terminals that participated in the signature process in establishing p. Information processing terminals 10c and 10f are terminals that do not participate in the signature process. Information processing terminal 10b is the terminal of the signature verifier (who also signs at a different time).

[0077] The timing at which each piece of data (D1 to D8) in FIG. 10 is handled will also be explained together with the processing.

[0078] <Processing when posting information (signing)> S10: As shown in FIG. 5, the participation manager 13a of the information processing terminal 10a requests the information processing terminals of all other participants to sign.

[0079] S20: The participation manager 13d of the information processing terminal 10d determines whether or not to participate in the signature. Note that the same process is performed in the information processing terminals 10e, 10c, and 10f. Here, the process S20 will be described in detail with reference to FIG.

[0080] S21: The participation manager 13d generates a probability (random number) p.

[0081] S22: The participation management unit 13d determines whether p<threshold value.

[0082] S23: If p is not less than the threshold (S22; False), the participation manager 13d waits for a specified time and returns to step S21. On the other hand, if p is less than the threshold (S22; True), the process proceeds to the next step S31.

[0083] S30 (S31): Returning to FIG. 5, the participation manager 13d of the information processing terminal 10d raises his / her hand to volunteer as a signer (see D1 to D2 in FIG. 10). When the participation manager 13d raises his / her hand, the participant of the information processing terminal 10d is treated as a signer. The same process is performed in the information processing terminal 10e. Note that the information processing terminal 10a that has requested the signature may also participate in the signing.

[0084] S40: Digital signature unit 12d of information processing terminal 10d of the participant who has become a signer and digital signature unit 12e of information processing terminal 10e of the participant who has become a signer verify information using a BLS signature (see D3 to D6 in FIG. 10). Note that if information processing terminal 10a, the signature requester, participates in the signing, digital signature unit 12a of information processing terminal 10a also performs information verification using a BLS signature. Here, the processing S40 by digital signature unit 12d will be described in detail with reference to FIG. 7. The processing by digital signature unit 12e is similar, and if information processing terminal 10a participates in the signing, the processing by digital signature unit 12a is similar.

[0085] S41: The digital signature unit 12d assigns a time stamp to the signature object as receipt of the signature object.

[0086] S42: The digital signature unit 12d determines whether the added time is appropriate.

[0087] S43: If the time is not appropriate (S42; False), the digital signature unit 12d shares the rebuttal. Specifically, the digital signature unit 12d registers the rebuttal information in a sharing system that can be accessed by the participants.

[0088] S44: If the time is not appropriate (S42; True), the digital signature unit 12d signs the document and proceeds to the next process 51.

[0089] S50 (S51): Returning to Fig. 5, the ledger management units 14d and 14e of the information processing terminals 10d and 10e record the signatures in their respective local chains (ledgers) (see D7 to D8 in Fig. 10). Note that if the information processing terminal 10a that requested the signature participates in the signature, the ledger management unit 14a of the information processing terminal 10a also records the signature in its local chain (ledger). Note that after the process of S51 in Fig. 7, the process returns to step S23.

[0090] This concludes the description of the process when posting information (signing).

[0091] <Processing at the time of reference (signature verification)> S60: As shown in Fig. 6, the random signature unit 11a of the information processing terminal 10a that has requested the signature verification presents the target information and the signature to the information processing terminal 10b of the verifier b. Note that the information processing terminal 10b has the same random signature unit 11 as the other information processing terminals 10.

[0092] S61: As shown in FIG. 8, the random signature unit 11b of the information processing terminal 10b acquires the target information and the signature in accordance with the process S60.

[0093] S70: Returning to Fig. 6, the verification unit 15b of the information processing terminal 10b verifies the signature and the condition. Here, the process 70 of verifying the signature and the condition will be described in detail with reference to Fig. 8.

[0094] S71: The verification unit 15b accesses the sharing system that is accessible to the participants and determines whether or not a counterargument is shared.

[0095] S72: If a rebuttal is shared (S71; True), the verification unit 15bd checks the content of the rebuttal.

[0096] S73: Then, the verification unit 15b determines whether the trail is valid.

[0097] S74: If the trail is valid (S73; True), the verification unit 15b determines that the verification has failed.

[0098] S75: On the other hand, if there is no shared objection (S72; True), the verification unit 15b searches for the people involved (participants). Note that if the trail is invalid (S73; False), the process S75 is also executed.

[0099] S76: The verification unit 15b verifies the signature and determines whether it is successful.

[0100] S77: If the verification is successful (S76; True), the verification unit 15b determines that the verification is successful. On the other hand, if the verification is not successful (S76; False), the verification unit 15b determines that the verification is unsuccessful.

[0101] This completes the process for verification that does not assume maliciousness. This is the process for S5 (idea (a)) in Figure 3. If the implementation and protocol operation cannot be trusted, the process from S80 onwards in Figure 6 is executed based on S6 (idea (b)) in Figure 3.

[0102] S80: As shown in FIG. 6, the verification unit 15b of the information processing terminal 10b compares the local chain of the presented signature with the local chain of the signature of its own terminal, and searches for a matching signature.

[0103] Here, the processing S80 and S91 to S96 by the verification unit 15b will be described in detail with reference to Figures 6 and 8. Note that even in the case of processing related to verification assuming maliciousness, the processing is similar to the first half of the processing (S61, S71 to S76) of verification not assuming maliciousness in Figure 8, and therefore description of these processing will be omitted.

[0104] S91: In FIG. 8, even if the signature verification is successful in the process S76 (S76; True), the verification unit 15b still requests verification from the information processing terminal 10a that has requested the verification.

[0105] S92: The ledger management unit 14a of the information processing terminal 10a presents the local chain of signatures managed by the information processing terminal 10a to the verification unit 15b of the information processing terminal 10b as a response to the process S91.

[0106] S93: Furthermore, the verification unit 15b requests the information processing terminal 10d of the participant (signer) for the signature blockchain. In this case, the verification unit 15b also transmits time information around the time (for example, around 3 hours) based on the time of the signature blockchain presented by the information processing terminal 10a.

[0107] S94: In response to step S93, the ledger management unit 14d of the information processing terminal 10d narrows down the local chains of signatures managed by the terminal itself (10d) to a specific local chain of signatures that corresponds to the time information and presents it.

[0108] S81: Subsequently, the verification unit 15b determines whether or not the signature of the verifier's own terminal (10b) is found in the local chain presented by the information processing terminal 10d.

[0109] S82: If the verifier's signature is found (S81; True), the verification unit 15b determines that the verification has been successful.

[0110] S83: If the verifier's signature is not found (S81; False), the verification unit 15b determines whether or not the search limit has been reached in the local chains of all the presented co-signatories. If the search limit has been reached (S83; True), the verification unit 15b proceeds to step 74 and determines that the verification has failed.

[0111] S84: If the search limit is not reached (S83; False), the verification unit 15b acquires the local chain of the other party. As a result, the process returns to step S61 and the same process is carried out. Note that the other party is, for example, the signer e of the information processing terminal 10e in FIG. 6. Therefore, similar to step S93, the verification unit 15b requests the local chain of signatures from the information processing terminal 10e (S95). Also, similar to step S94, the verification unit 15b receives the local chain of signatures from the information processing terminal 10e.

[0112] This completes the process for verification assuming malicious.

[0113] [Effects of this embodiment] As described above, according to this embodiment, it is possible to ensure the security of the existence proof while reducing costs such as storage usage, network communication, and participant incentives. For example, participants only need to possess information related to the signatures they periodically perform, and if the signature participation probability is p≈1 / 1000, then they only need to manage a ledger with 1 / 1000 of the amount of communication required for signing and the amount of stored data compared to existing blockchains (distributed ledgers).

[0114] The effects will be described in detail below.

[0115] <Safety> To ensure the security of the existence proof, it is sufficient to guarantee that at least one signer is honest. We gather n people based on random selection of signing participants, and ensure the security of the signature itself using a multi-person signature method that uses signature conditions that can probabilistically show that at least one of them is honest. We ensure security by verifying the signature chain, which can probabilistically identify forged signatures based on the signing participant conditions and the context of the signature. We ensure security against Sybil by providing a correspondence from any signing participant to their own signature.

[0116] <Cost> In order to secure the number of signers, the signature requester is required to participate in a certain number of signatures and keep a record of the participant candidates, but in exchange, the node that aims to provide resources (a cost increase factor) is eliminated. The data storage conditions are relaxed from storing all data to storing information on the own device, reducing storage capacity and communication volume.

[0117] <Signer reliability> If an upper limit on the proportion of attackers can be estimated, the correctness of the signature can be guaranteed by gathering a number of signers that can be probabilistically guaranteed to be safe.

[0118] That is, we assume a system in which the information processing terminals 10 of all participants decide whether or not to participate in signing in each round according to the probability of p, and signing is performed only at the information processing terminals of participants (those who have become signers). The upper and lower limits of the number of people participating in signing in any round can be calculated as a probability using the Chernoff bound based on the KL divergence for the Bernoulli distribution of p. The method for calculating the number of participants will be described later.

[0119] Similarly, if we assume the ratio of attacker terminals among all participants' information processing terminals, we can calculate the lower limit of the number of honest users (participants) among the participants of the signature. The method for calculating this number of participants will be described later.

[0120] When performing proof of existence (time signature), as long as there is at least one honest user (participant), repudiation and collusion attacks will not be successful, ensuring security as a proof of existence.

[0121] <Reliability of signature storage> To make it possible to verify the long-term validity of a signature, the requester of the signature stores the signature information of his / her own terminal (for example, information processing terminal 10a) in a local chain. The signature recipient (a person who has become a signer) continues to participate in signing even after receiving the signature, and links the executed signature (by referring to the latest transaction in the local chain) to the local chain of his / her own terminal. In this way, the chain stored by each participant is periodically extended, and the resistance to tampering of past signatures is strengthened by both the signer and the signature requester.

[0122] <Reliability of signature information> If the protocol for gathering signers is not deviated from, authenticity is confirmed by signature verification and counter-verification. If the protocol for gathering signers can be deviated from, the accuracy of the signing time is guaranteed by self-signature search from any verifier (who participates in the signing) by tracing the connections between the local chains held by each signer.

[0123] In other words, if a semi-honest attacker with probability p makes a forged signature with a "different time," the error can be detected because there is always an honest participant in the signing round. Also, if a malicious attacker who does not follow probability p makes a forged signature with a "different time," the forged signature can be detected by checking the order relationships in each local chain for inconsistencies or the lack of joint signatures with other people's local chains.

[0124] (How to calculate the number of participants) (1) Upper and lower limits on the number of people who can sign in any round If all M information processing terminals participate in a vote as clients in a particular round with a probability of p=n / M (determined according to a Bernoulli distribution with a binary choice of whether to participate or not), then the upper and lower bounds on the number of participants can be calculated.

[0125] As a concept, the information processing terminal 10 searches for e_c such that the probability of occurrence of a fluctuation of e_c or more for probability p is negligible (2^-30 = 9.3132257e-10) by a probability test.

[0126] The lower limit of the number of participants, n^*, can be said to be M(p-e_c) if e_c is selected such that the probability exp(-KL(p-e_c,p)n) that n^* = M(p-e_c) is sufficiently small.

[0127] The upper limit of the number of participants, n^~, can be said to be M(p+e_c) if e_c is selected such that the probability exp(-KL(p+e_c,p)n) that n^~ = M(p+e_c) is sufficiently small.

[0128] (2) The minimum number of honest users among the signing participants Given the proportion of good citizens (honest users) α, the proportion of attacking servers γ, and the number of transactions in a block m, we can calculate a lower bound on the number of good citizens.

[0129] The idea is that the information processing terminal 10 searches for e_g and e_f such that the upper limit e_g of the fluctuation that can occur for the proportion α of good citizens and the upper limit e_f of the fluctuation that can occur when all m writes are made to an attacking server are negligible (2^{-30} = 9.3132257e-10) by probability testing.

[0130] 〔others〕 The present invention is not limited to the above-described embodiment, and may have the following configurations or processes (operations).

[0131] (1) The information processing terminal 10 can be realized by a computer and a program, but this program can also be recorded on a (non-transitory) recording medium or provided via a communication network such as the Internet.

[0132] (2) In the above embodiment, the information processing terminal 10 is, for example, a notebook computer, a desktop computer, a tablet terminal, a smartphone, a smartwatch, or the like.

[0133] (3) Each CPU 101, 501 may be a single CPU or may be multiple CPUs. [Explanation of symbols]

[0134] 10 Information processing terminal 11 Random Signature Section 12 Electronic Signature Section 13 Participation Management Department 14 Ledger management department 15 Verification Department

Claims

1. An information processing terminal that performs electronic signatures using proof of existence, An information processing terminal having a participation management unit in which each participant of the electronic signature individually generates a random number, and participates as an information processing terminal related to the signer if the random number is less than a threshold value.

2. 2. The information processing terminal according to claim 1, An information processing terminal having an electronic signature unit that performs the electronic signature by time synchronization and existence proof in cooperation with another information processing terminal that has become an information processing terminal related to the signer.

3. 3. The information processing terminal according to claim 2, An information processing terminal having a ledger management unit that manages a ledger of a local chain and shares the latest state of the ledger with the other information processing terminals when participating as the signer.

4. The information processing terminal according to claim 3 , wherein the ledger management unit generates a new electronic signature based on the information indicating the latest state, and links the new electronic signature to the ledger as the local chain.

5. An information processing terminal according to any one of claims 1 to 4; Another information processing terminal that has become an information processing terminal related to the signer; An existence proof system having

6. An information processing method executed by an information processing terminal that performs electronic signatures using existence proof, comprising: The information processing terminal An information processing method in which each participant of the electronic signature individually generates a random number, and if the random number is less than a threshold, executes a participation management process to participate as an information processing terminal related to the signer.

7. A program causing a computer to execute the method according to claim 6.

Images