JP6275302B2 - Existence proof device, existence proof method, and program therefor - Google Patents

Description

  The present invention relates to a presence proof program and a presence proof server that prove that specific electronic data existed at a specific time.

  Conventionally, various proof methods for proving that specific electronic data existed at a specific time have been proposed. For example, Patent Document 1 discloses a time stamp update device that enables certification of data to be certified based on time stamp data transmitted from a time stamp authority device. Specifically, when the certification target data is input, the hash value calculated from the certification target data is transmitted to the time stamp authority apparatus, and the time stamp data received from the time stamp authority apparatus is stored in association with the certification target data. Is done. Then, a logical sum of the valid periods of the time stamp data associated with the certification target data is calculated, and a period that goes back from the verification time is output as a period during which the certification target data can be proved.

  Patent Document 2 discloses a data transmission / reception system capable of exchanging data such as e-mail using accurate time information on a network. Specifically, the certificate authority authenticates that an electronic postmark including highly accurate time information can be issued to the authentication mail server. The authentication mail server on the e-mail transmission side stamps an electronic postmark in which highly accurate time information is embedded in the e-mail transmitted by the sender. At this time, the electronic postmark data to which the time information is given by the authentication mail server cannot be altered by a predetermined electronic postmark issuing program, and is further encrypted and transferred to the receiving mail server.

  Further, Patent Document 3 discloses a presence certification program that proves that an original document exists in a specific storage location on a specific date. Specifically, first, the registrant saves a copy of the document in advance as content. In response to a request from the registrant, the document existence certification server obtains a document with a specified URL, generates a hash from the registration date, the document URL, and the content of the document, registers the link in the registration DB, and registers The hash URL is notified to the user. Upon receiving this notification, the registrant creates an existence confirmation page including a hash URL and saves it in an HTML file. The viewer who has acquired a copy of the content and the HTML file generates a hash based on the content, the registration date in the existence confirmation page, and the document URL, and compares the hash acquired from the document presence certificate server with the presence of the original document. To verify.

JP 2010-055634 A JP 2002-116695 A JP-A-11-175512

  The present invention is to provide a novel existence proofing method that proves with high robustness that specific electronic data existed at a specific time.

  In order to solve this problem, the first invention provides a presence proof program for certifying that specific electronic data existed when a transaction occurred. This existence certification program generates a transaction in which a byte array uniquely determined based on the contents of electronic data to be registered for existence certification is embedded in a script, and digitally signs this transaction using public key cryptography. In the above, the first step of broadcasting to the P2P network where the block chain exists, the second step of associating the transaction identifier unique to the transaction and the byte array in association with each other and storing them in the management database, A block chain on the P2P network is searched to identify a transaction corresponding to the transaction identifier, and the computer is caused to execute a process including a third step of extracting a byte array embedded in the transaction.

  Here, the first invention further includes a fourth step of searching the management database using the byte array of electronic data to be verified for existence as a key and identifying a transaction identifier associated with the byte array. Is preferred.

  In the first invention, the first step may include a step of generating a transaction using a virtual currency address designated by a person who intends to register electronic data as a destination of the virtual currency.

  In the first invention, the byte array is preferably a hash value of the file when the electronic data is a file, and is a binary representation of the text message when the electronic data is a text message.

  In the first invention, the electronic data is a file, and the first step includes a step of encrypting the file and storing it in association with a byte array that is a hash value of the file. preferable.

  The second invention provides a presence proof server that is connected to a client via a network and proves that specific electronic data existed when a transaction occurred. The presence certification server includes a data transmission / reception unit, a data registration unit, and a data search unit. The data transmission / reception unit accepts electronic data transmitted from the client and to be registered as a presence certificate. The data registration unit generates a transaction in which a byte array uniquely determined based on the contents of electronic data is embedded in a script, and after digitally signing this transaction using public key cryptography, a block chain exists. Broadcast to a P2P network. The data registration unit registers the transaction identifier unique to the transaction and the byte array in association with each other in the management database. The data search unit searches the block chain on the P2P network using the transaction identifier as a key, specifies a transaction corresponding to the transaction identifier, and extracts a byte array embedded in the transaction.

  Here, in the second invention, it is preferable that the data search unit searches the management database using the byte array of electronic data to be verified for existence as a key, and extracts a transaction identifier associated with the byte array. .

  In virtual currencies including bitcoin and its derivatives, public key cryptography and blockchain, which is a distributed encryption database, are used. A transaction that indicates whether or not the transaction is guaranteed with high robustness. The present invention utilizes such robustness for the existence proof of electronic data, generates a transaction in which a byte array uniquely determined based on the contents of the electronic data is embedded, and generates the transaction as a block chain. Broadcast to the existing P2P network. As a result, the transaction in which the byte array is embedded in the block chain existing on the P2P network is captured. When verifying the presence of electronic data, the blockchain is searched using the transaction identifier as a key, and the byte array embedded in the hit transaction is extracted to determine whether the electronic data existed when the transaction occurred Can be verified and proved with high robustness.

Block configuration diagram of the presence certification server according to the present embodiment Example of input screen for file to be registered for existence certificate Input screen example of text message to be registered for existence certificate Flow chart of electronic data registration routine Conceptual diagram of transaction Illustration of data structure in transaction Diagram showing an example of transaction script with embedded byte array Illustration of blockchain 21 Flowchart of a search routine for searching for a transaction identifier using electronic data as input Blockchain search routine flowchart Illustration of the existence proof of electronic data

  FIG. 1 is a block diagram of a presence proof server according to the present embodiment. The presence certificate server 1 is connected to a client 10 and a virtual currency network 20 operated by a virtual currency user via a network such as the Internet. The virtual currency network 20 is a peer-to-peer (P2P) network, and adopts an architecture in which peers communicate with each other when communicating between a large number of terminals. Further, as will be described later, a block chain 21 which is a kind of distributed encryption database exists on the virtual currency network 20. The existence proof server 1 has an electronic data existence proof function, that is, a function to prove that specific electronic data existed at a specific time. In the present embodiment, there are two types of electronic data that are subject to existence certification: text messages (character strings) having a predetermined number of characters or less, and files such as documents, still images, and moving images. In order to realize such electronic data existence certification function, the existence certification server 1 includes a data transmission / reception unit 2, a data registration unit 3, a data search unit 4, a management database 5, and a file storage unit 6. Have.

  The data transmission / reception unit 2 is an interface that controls transmission / reception of data between the presence certification server 1 and the client 10, and in particular, receives (accepts) from the client 10 electronic data to be registered and verified for existence certification. The registration result and the search result are transmitted to the client 10.

  Based on the received electronic data, the data registration unit 3 generates a byte array BA (hash value or binary expression described later) that is uniquely determined by the contents of the electronic data, and embeds this byte array BA in the script. Generate a transaction. Then, the data registration unit 3 digitally signs this transaction using a public key cryptosystem, and broadcasts it to the virtual currency network 20 for incorporation into the block chain 21. Further, the data registration unit 3 registers and stores the transaction identifier TrID unique to the transaction and the byte array BA in association with each other in the management database 5. Further, when the electronic data received from the client 10 is a file (excluding a text message), the data registration unit 3 stores this file in the file storage unit 6 in association with the byte array BA (file hash value). ·save.

  When verifying the existence proof of the electronic data, the data search unit 4 searches the block chain 21 using the transaction identifier TrID as a key, identifies the transaction corresponding to the transaction identifier TxID, and stores the byte array BA embedded in this transaction. To extract. In addition, the data search unit 4 searches the management database 5 using the byte array BA of the electronic data to be verified for existence as a key as a pre-process of this search, as necessary, and is associated with this byte array BA. The transaction identifier TxID is extracted.

  In this embodiment, attention is focused only on the presence verification function of electronic data, but the presence verification service of electronic data is provided as one function of a platform for trading and managing virtual currency including bitcoin and its derivatives. May be provided.

  FIG. 2 is an example of an input screen for a file to be registered as a presence certificate. A user who operates the client 10 inputs a virtual currency address and a password to which a virtual currency is to be sent, and selects a file to be uploaded in accordance with an instruction on the illustrated input screen. FIG. 3 shows an example of an input screen for a text message to be registered for existence certification. In accordance with the write instruction “Write a Message” in the input screen example, the user inputs the text message to be uploaded into the box in the lower column of the instruction instead of selecting the file shown in FIG. In response to selection of a file selection and transmission icon by the user, and input and writing icon of a text message (“Write Forever” in FIG. 3), the data of the file / text message is transmitted from the client 10 to the presence proof server 1, The data registration unit 3 on the presence certificate server 1 side accepts it. These input screens shown in FIGS. 2 and 3 can be provided from the presence certificate server 1 to the client 10 every time processing is performed, or can be executed by an application provided in advance.

  FIG. 4 is a flowchart of an electronic data registration routine. This registration routine is executed by the data registration unit 2 when electronic data to be registered for the presence certificate is received by the data transmission / reception unit 1.

  First, in step 1, the type of electronic data to be registered is determined. If the electronic data type is a file, a hash value of the file is generated using, for example, SHA256 (step 2). The hash value is characterized in that the same value is always output from the same input value, but a completely different value is output from a slightly different input value. Moreover, since the hash function includes an irreversible one-way function, an input value cannot be determined from the output hash value. Because of these characteristics, hash values are widely used for detecting falsification of files. In the present embodiment, the hash value uniquely determined from the contents of the file is a byte array BA that characterizes the file to be registered for the existence certificate.

  In step 3, the file is encrypted and stored in the file storage unit 6 in association with the byte array BA (hash value) of the file. The reason for encrypting the file is to keep the contents of the file secret from a third party. Therefore, if confidentiality is not required, the file can be stored in the file storage unit 6 in plain text. Good.

  On the other hand, when the type of electronic data is a text message, the process proceeds from step 1 to step 4, and the binary representation of the text message (for example, a value encoded by UTF-8) is set as the byte array BA. Needless to say, this binary representation is also uniquely determined from the contents of the text message.

  In step 5 following step 3 or step 4, a transaction in which the byte array BA is embedded is generated using the virtual currency address designated by the person who intends to register the electronic data as the destination of the virtual currency. Here, based on FIG. 5, the concept of transaction in Bitcoin will be described. In Bitcoin, currency is expressed as a transaction history, that is, a collection of all transactions that the currency has gone through. Each transaction (currency transaction) is digitally signed with the original owner's encryption key, including the hash value of the previous transaction and the public key of the new owner. Information about all transactions is shared across the P2P network. By expressing the transaction in this way, it is not possible to transfer the currency without permission of the original owner, and the third party can objectively confirm the transfer of the currency. Have.

  FIG. 6 is an explanatory diagram of a data structure in a transaction. The data structure of the transaction has “output (currency for withdrawal)” and “input (currency used for deposit)”. For remittance, the currency (face value) to be sent to the other party and the destination are required, but the output is a representation of them. To use the currency addressed to you (= send money to someone), you must refer to the output of a past transaction, which corresponds to the input in the current transaction. Multiple outputs and inputs can be specified for each transaction. In order to send an arbitrary amount of money, it is necessary to collect the output of past transactions addressed to itself and specify it as an input for a future transaction.

  FIG. 7 is a diagram illustrating an example of a transaction script in which the byte array BA is embedded. In Bitcoin, a transaction is described by a Bitcoin script. The transaction shown in the figure means that a predetermined amount of money is sent to the user B using the bit coin sent from the user A to himself / herself in the past. Each transaction is given a transaction identifier TxID unique to the transaction, and usually a transaction hash value is used. As described above, “OutputScript” can specify a plurality of outputs. “Output 2” is a normal description for verifying an input digital signature, whereas “Output 1” has a byte array BA. It is a description for adding. In the Bitcoin script, there is a code called "OP_RETURN", which, like a general program return, stops the script when it comes there and does not allow you to reference its output. is there. If the byte array BA is added using “OP_PUSHDATA” following “OP_RETURN”, “output 1” can be used as a description column of the byte array BA without adversely affecting the digital signature. Taking advantage of the characteristics of “OP_RETURN” as described above, the data registration unit 3 embeds the byte array BA by automatically adding the byte array BA specified in steps 2 and 4 to the description of the normal script. Generated transactions. Note that the number of bytes of the byte array BA that can be added using “OP_PUSHDATA” has an upper limit, so that the hash value is used for the file and the upper limit value is not exceeded for the text message.

  Referring again to FIG. 4, in step 6, the transaction generated in step 5 is digitally signed using public key cryptography, and its hash value is a transaction identifier TxID, a unique identifier for uniquely identifying the transaction. It is numbered as the value of. In step 7, the byte array BA specified in step 2 or step 4 and the transaction identifier TxID numbered in step 6 are associated with each other and registered in the management database 5. In addition, the type of the byte array BA is also stored in the management database 5 in order to determine whether the byte array BA is a hash value or a binary representation when the electronic data is verified.

  In step 8, the transaction (step 5) in which the byte array BA is embedded is broadcast to the virtual currency network 20 which is a P2P network. Here, broadcasting refers to transmitting a transaction to a plurality of users connected to the virtual currency network 20. The broadcasted transaction is shared throughout the virtual currency network 20 and is taken into the block chain 21 by a network node called a miner (minor) in the same manner as a normal transaction. This means that the transaction in which the array BA is embedded is registered in the extremely robust distributed encryption database called the block chain 21.

  FIG. 8 is an explanatory diagram of the block chain 21. The block chain 21 is a mechanism for preventing double transfer adopted in bit coins and derivatives thereof. Double transfer is the transfer of the exact same currency to two or more opponents of the original currency. In order to use it as a currency, only one of the transfers needs to be determined as a correct transaction throughout the network. Generally, it is natural to consider later transactions as invalid in time series, but since these transactions are performed on the P2P network, which is the earlier transaction when viewed as the whole network Cannot be determined reliably. However, what is important here is that only one of the specifics can be consistently determined to be a correct transaction throughout the network, and when there are two conflicting transactions, exactly which transaction was made first. That's not very important. In a block chain, each block has a number of transactions, a special value called a nonce, and a hash of the previous block. Only transactions (transactions) included in the block are recognized as “correct transactions”. And make sure that the entire network has a “single block of blocks”. In this way, the blockchain mechanism is that a consistent transaction history can be shared across the entire network.

  In step 9, a notification that the registration of the electronic data is completed is transmitted to the client 10, thereby exiting this routine.

  FIG. 9 is a flowchart of a search routine for searching for a transaction identifier using electronic data as an input. This search routine is executed by the data search unit 4 when electronic data to be verified for existence certification is received by the data transmission / reception unit 1 and the transaction identifier TxID is searched by using this as input.

  First, in step 11, the type of electronic data to be searched is determined. If the electronic data type is a file, a hash value of the file is generated using the same hash function (for example, SHA256) as that used for registration (step 12). This hash value is a byte array BA that characterizes the file to be verified for existence.

  On the other hand, when the type of electronic data is a text message, the process proceeds from step 11 to step 13, and the binary representation of the text message (for example, a value encoded by UTF-8) is set as the byte array BA.

  In step 14 following step 12 or step 13, the management database 5 is searched using the byte array BA as a key, and the transaction identifier TxID associated with this byte array BA is specified. In step 15, the transaction identifier TxID is notified to the client 10 as a search result, and the routine is exited.

  FIG. 10 is a flowchart of the search routine for the block chain 21. This search routine is executed by the data search unit 4 when searching the block chain 21 using the transaction identifier TxID as a key and extracting the byte array BA embedded in the transaction.

  First, in step 17, the block chain 21 existing on the virtual currency network 20 is searched using the transaction identifier TxID as a key. If there is a transaction corresponding to the transaction identifier TxID in the block chain 21, the process proceeds to step 19 through an affirmative determination in step 18. On the other hand, if there is no transaction corresponding to the transaction identifier TxID in the block chain 21, the process proceeds to step 24 through a negative determination in step 18, transmits an error to the client 10, and exits this routine.

  In step 19, the byte array BA described in the transaction corresponding to the transaction identifier TxID is extracted and acquired. Next, in step 20, the type of electronic data is determined. If the type of electronic data is a file, the process proceeds to step 22 where the file storage unit 6 is searched using the byte array BA as a key. In step 22, the search result is transmitted to the client 10 and the routine is exited.

  This search result may include not only the presence / absence of the electronic data existence proof but also the file name and presentation when the transaction occurs when the existence can be proved. Here, “when a transaction occurs” is strictly the date and time when a new block including a transaction uploaded to the virtual currency network 20 is taken into the block chain 21, and this date and time indicates the block chain 21. By searching, it can be specified at any time. This ensures that the byte array BA (hash value) embedded in the transaction was present when the transaction occurred. As described above, since the hash value that is the byte array BA is a value that is uniquely determined from the file, the hash value BA of the file to be verified for existence proof, the byte array BA extracted from the transaction, That is, it means that a file having the same content as the file to be verified existed when the transaction occurred. Various forms of search results are conceivable. For example, the existence certificate server 1 compares the byte array BA of the file to be verified with the existence certificate and the byte array BA extracted from the transaction. Then, the presence / absence of the existence proof may be explicitly determined / notified, or the client 10 may be notified of the byte array BA extracted from the transaction, and the user may be left to determine whether the existence proof is acceptable. Good.

  On the other hand, if the type of electronic data is a text message, the process proceeds from step 20 to step 23, where the byte array BA is decoded and the text message is restored. Then, this text message is transmitted to the client 10 and the routine is exited. This proves that the text message was present when the transaction occurred.

  As described above, according to the present embodiment, it is possible to verify and prove with high robustness whether electronic data such as a file or a text message existed when a transaction occurred. To elaborate on this point, as shown in FIG. 11, first, the transaction B in which the byte array BA is embedded is uploaded onto the virtual currency network 20, and thereby this transaction is taken into the block chain 21. The byte array BA is a hash value of a file in the case of a file, a binary representation of a text message in the case of a text message, and is a unique value that is uniquely determined from electronic data. Bitcoin employs public key encryption technology and distributed encryption database technology as a mechanism to prevent modification or double transfer by a third party. Transactions that are guaranteed to be highly robust.

  On the other hand, at the time of verification of the electronic data, the transaction B is identified from a large number of transactions by searching the block chain 21 using the transaction identifier TxID = B stored on the existence proof server 1 side as a search key. The Then, by acquiring / extracting the byte array BA embedded in the transaction B, it becomes possible to verify and prove that the electronic data existed when the transaction occurred. That is, when the electronic data is a file, the byte array BA of the file to be verified and the byte array BA acquired / extracted from the block chain 21 have the same contents as the file to be verified. It is proved that things existed at the time of the transaction. If the electronic data is a text message, it is proved that the byte array BA (decoded text message) itself acquired / extracted from the block chain 21 was present when the transaction occurred.

  From the above, from the viewpoint of the existence proof of electronic data, the block chain 21 on the virtual currency network 20 is not a virtual currency transaction history in a general sense, but rather a database for proof of existence. One transaction constituting this database can be regarded as one record in which data (byte array BA) necessary for existence proof is described. Therefore, in this specification, the terms “block chain” and “transaction” are used in such an expanded sense.

In the above-described embodiment, bit coins, which are typical virtual currencies, have been described as examples. However, the present invention is not limited to this, and is widely applied to derivative currencies that satisfy the following two requirements. Applicable.
(1) The block chain exists on the P2P network. (2) Each transaction is digitally signed using a public key cryptosystem.

  In the above-described embodiment, an example has been described in which two types of text message and file are handled as electronic data to be subject to existence certification. However, only one of them may be handled.

  Further, in the above-described embodiment, the example in which the program having the flowcharts shown in FIGS. 6, 9, and 10 is installed in the existence proof server 1 has been described, but this program is installed in the computer operated by the user. By doing so, the user may directly register and verify the electronic data.

DESCRIPTION OF SYMBOLS 1 Existence proof server 2 Data transmission / reception part 3 Data registration part 4 Data search part 5 Management database 6 File storage part 10 Client 20 Virtual currency network 21 Block chain

Claims (10)

A proof of existence method for proving that specific electronic data existed,
When registering electronic data to be registered for existence certification,
A server generates a transaction having a byte arrangement determined based on the content of the electronic data, digitally signs the transaction, and broadcasts the transaction to a network in which a block chain exists;
The server associating the byte array with a transaction identifier corresponding to the transaction in a database of the server ;
When verifying the existence proof of the electronic data,
The server generates a byte array determined based on the content of the electronic data, refers to the association between the byte array stored in the database and a transaction identifier, and determines the transaction identifier associated with the byte array. Identifying steps;
The server searches the block chain existing on the network using the transaction identifier as a key, and determines whether there is a transaction corresponding to the transaction identifier;
The server extracting a byte array from the transaction corresponding to the transaction identifier if the determination result is yes,
A presence proving method characterized in that the existence of the electronic data is proved when the extracted byte array matches the byte array stored at the time of registration.   The existence certifying method according to claim 1, wherein the byte array is either a hash value or a binary representation according to a type of the electronic data.   3. The existence verification method according to claim 1, wherein the byte array is described in a script of the transaction. When verifying the existence proof of the electronic data,
4. The existence verification method according to claim 1, further comprising a step of searching for a byte array stored at the time of registration using the extracted byte array as a key.   5. The existence proof according to claim 4, further comprising a step of notifying the proof that the electronic data existed when a byte arrangement that matches the extracted byte arrangement is stored. Method.   6. The existence certification method according to claim 5, wherein the notification includes a date and time when the electronic data was registered.   The existence proof method according to claim 1, wherein the network is a virtual currency network.   8. The existence certification method according to claim 7, wherein the broadcasted transaction is sent to a virtual currency address designated by a registrant of the electronic data. A program for causing a computer to execute a presence certification method for proving that specific electronic data existed, the existence certification method comprising:
When registering electronic data to be registered for existence certification,
The computer generates a transaction having a byte array determined based on the content of the electronic data, digitally signs the transaction, and broadcasts the transaction to a network in which a block chain exists;
The computer associating and storing the byte array and a transaction identifier corresponding to the transaction in a database of the computer ;
When verifying the existence proof of the electronic data,
The computer generates a byte array determined based on the contents of the electronic data, refers to the association between the byte array stored in the database and a transaction identifier, and determines the transaction identifier associated with the byte array. Identifying steps;
The computer searches the block chain existing on the network using the transaction identifier as a key, and determines whether there is a transaction corresponding to the transaction identifier;
The computer extracting a byte array from the transaction corresponding to the transaction identifier if the result of the determination is yes,
A program characterized in that the existence of the electronic data is proved when the extracted byte array matches the byte array stored at the time of registration. An existence proof device for proving that specific electronic data existed,
When registering electronic data to be registered for existence certification,
Wherein to generate a transaction having the byte sequence determined based on the content of the electronic data, after the transaction digitally signed, Broadcast networks that exist block chain,
Storing the byte array in association with a transaction identifier corresponding to the transaction in the database of the existence proving device ;
When verifying the existence proof of the electronic data,
Generating a byte array determined based on the content of the electronic data, referring to an association between a byte array stored in the database and a transaction identifier, and identifying the transaction identifier associated with the byte array;
Search the block chain existing on the network with the transaction identifier as a key, and determine whether there is a transaction corresponding to the transaction identifier,
If the determination result is yes, a byte array is extracted from the transaction corresponding to the transaction identifier,
Existence and wherein that you prove the existence of the electronic data by the extracted byte array matches the stored byte array during the registration.