Program, voting management method, terminal, and voting management system

Abstract

To provide a vote management system which allows a third party to verify the validity of a voting result while sufficiently concealing voting information.SOLUTION: A manager terminal 100 related to a vote management system 10 includes: a voting information acquisition unit 103 which acquires voting information; a vote generation unit 104 which generates encrypted voting information with threshold signatures of the manager terminal 100 and a voter terminal 200; a key information generation unit 105 which generates public key information to be used for verification of the threshold signatures; a vote management information recording unit 106 which records vote management information on a distributed ledger 300; a voting unit 107 which records the encrypted voting information on the distributed ledger 300 on the basis of the vote management information; a vote inspection information generation unit 108 which generates vote inspection information with verification information added thereto which indicates that the vote management information is recorded by a user of the manager terminal 100 without encrypting a party voted, in a verifiable manner; and a vote inspection information recording unit 109 which records the vote inspection information on the distributed ledger 300.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a program, a voting management method, a terminal, and a voting management system. [Background technology]

[0002] One voting system that enables electronic voting in elections or decisions where the outcome is determined by votes from eligible voters is an electronic voting system that utilizes a distributed ledger. In the electronic voting system described in Patent Document 1, the exhaustion of voting rights is recorded in the first distributed ledger (blockchain), the transfer of voting tokens to an anonymous account is recorded in the second distributed ledger, and the correspondence between exhaustion and transfer is recorded in the third distributed ledger. In this way, the electronic voting system described in Patent Document 1 prevents multiple voting and ensures anonymity. [Prior art documents] [Patent Documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2019-95884 [Overview of the project] [Problems that the invention aims to solve]

[0004] In the electronic voting system described in Patent Document 1, the number of votes for each voting destination can be audited by making public a second distributed ledger, which was kept secret from third-party access during the voting period. In audits using the second distributed ledger, the voters for each vote are kept secret, while the voting destination and the number of votes are made public.

[0005] The disclosure of voting preferences and vote counts can sometimes allow third parties to infer which voters cast those votes. For example, in the exercise of voting rights at a shareholders' meeting, votes with a large number of votes can be inferred to have been cast by voters who own a large number of shares. Therefore, based on voting preferences and vote counts disclosed for auditing purposes, a third party may be able to infer which voters cast those votes.

[0006] In this case, the legitimacy of the voting results can be verified, but it becomes difficult to adequately conceal the votes cast, the number of votes cast, and the voters themselves.

[0007] Therefore, the present invention aims to provide a program, a voting management method, a terminal, and a voting management system that enable verification of the legitimacy of voting results by a third party while keeping voting information sufficiently confidential. [Means for solving the problem]

[0008] A program according to one aspect of the present invention causes a first terminal to perform a voting information acquisition process, which involves acquiring voting information from a second terminal capable of communicating with the first terminal, including voting destination information indicating at least one voting destination by a user of the second terminal and vote count information indicating the number of votes for at least one voting destination; and a vote generation process, which involves generating encrypted voting information that includes encrypted at least one voting destination information and encrypted vote count information, and which is threshold-signed by the first terminal and the second terminal.

[0009] Furthermore, the program according to the above embodiment causes the program to execute a key information generation process that generates public key information used for verifying threshold signatures, and a vote management information recording process that records vote management information, which includes vote record information encrypted based on the public key information and random number information, and approval information indicating whether or not the user of the second terminal has approved that the encrypted voting information is recorded through the first terminal, in a distributed ledger that can communicate with the first and second terminals, so that the user of the second terminal can update the approval information.

[0010] Furthermore, the program according to the above embodiment causes the first terminal to execute a voting process that records encrypted voting information in a distributed ledger when the user of the second terminal has approved that encrypted voting information be recorded in a distributed ledger based on vote management information; a vote verification information generation process that generates vote verification information which includes at least one unencrypted vote destination information, verifiable indication that the vote management information was recorded by the user of the first terminal, and to which verification information based on random number information is added; and a vote verification information recording process that records the vote verification information in a distributed ledger.

[0011] According to this aspect, the voting information of the user of the second terminal obtained by the voting information acquisition process is recorded in the distributed ledger through the first terminal as encrypted voting information by the voting process. Since the information indicating the user of the second terminal is not recorded in the distributed ledger, the anonymity of the voter at the time of voting can be achieved.

[0012] The user of the second terminal can update the approval information on the distributed ledger. Thereby, whether the user has approved the recording of the voting information through the first terminal can be recorded on the distributed ledger in a verifiable manner by a third party.

[0013] The voting process records the encrypted voting information in the distributed ledger based on the ballot management information. The encrypted voting information is information in which the voting destination and the number of votes are encrypted. The ballot verification information generated by the ballot verification information generation process is information in which the voting destination information is recorded without being encrypted.

[0014] A third party can obtain information about the voting destination from the encrypted voting information based on the ballot verification information. On the other hand, since the ballot verification information does not include the number of votes information, the third party cannot obtain the numerical value of the number of votes itself.

[0015] The voting result needs to be determined based on the encrypted voting information signed with a threshold signature by the user of the second terminal. A third party can confirm the validity of the voting result by using the ballot verification information when the ballot verification information is recorded by the user of the first terminal and is information based on the voting information common to the encrypted voting information.

[0016] The ballot verification information includes verification information based on the random number information used for generating the ballot management information. A third party obtains the verification information of the ballot verification information recorded on the distributed ledger. The third party refers to the ballot management information on the distributed ledger based on the verification information. The third party can associate the encrypted voting information corresponding to the referred ballot management information with the ballot verification information.

[0017] Regarding the voting destination in the ballot inspection information, the encrypted number of votes in the encrypted voting information can be associated. The encrypted number of votes is encrypted in an encrypted state using, for example, a homomorphic encryption method that allows arithmetic operations. At this time, by summing the encrypted numbers of votes, the encrypted number of votes obtained, which is the total number of votes for a certain voting destination, can be calculated. By comparing this obtained number of votes with the encrypted number of the final number of votes, a third party can verify the legitimacy of the election result. At this time, in both the encrypted voting information and the ballot inspection information, since the number of votes obtained is anonymized, the voting information is sufficiently anonymized even in the verification process.

[0018] In the processing by the program according to the above aspect, in the ballot generation process, a threshold signature is applied to the encrypted voting information based on the first secret key information recorded in the first terminal and the second secret key information recorded in the second terminal. In the key information generation process, the first public key information based on the first secret key information and the second public key information based on the second secret key information may be shared with the second terminal, and public key information may be generated based on the first public key information and the second public key information.

[0019] According to this aspect, between the first terminal and the second terminal, public key information used for verifying the threshold signature can be generated without each terminal sharing the first secret key and the second secret key. Therefore, while ensuring the security of the first secret key and the second secret key in the voting through the first terminal, it becomes possible to manage the voting.

[0020] In the above embodiment, the user's voting destination information, vote count information, and voting information are, respectively, the first voting destination information, the first vote count information, and the first voting information. In the program processing according to the above embodiment, the voting information acquisition process may further acquire second voting information from a third terminal that can communicate with the first terminal, which includes second voting destination information indicating at least one voting destination by the user of the third terminal, and second vote count information indicating the number of votes for at least one voting destination. Furthermore, the program processing in this embodiment may further cause the first terminal to perform a vote aggregation process that calculates the number of votes for at least one voting destination based on the first voting information and the second voting information.

[0021] In this embodiment, the first terminal acquires the first voting information from the user of the second terminal and the second voting information from the user of the third terminal. The first terminal records encrypted voting information based on the first voting information and encrypted voting information based on the second voting information in the distributed ledger. The first terminal also records vote verification information based on the first voting information and vote verification information based on the second voting information in the distributed ledger. As a result, voting information from each user is recorded in the distributed ledger in a state that is confidential yet verifiable by a third party.

[0022] The first terminal calculates the number of votes for each candidate based on the first and second voting information. This allows a third party to obtain the vote count from the first terminal, encrypt it, and compare it with the encrypted vote count based on the encrypted voting information to verify the legitimacy of the election results.

[0023] In the program processing described above, the voting information acquisition process may acquire a first voting destination and a second voting destination as at least one voting destination.

[0024] This embodiment makes it possible to obtain voting information for multiple parties. For example, even if a user on a second terminal has multiple voting rights, the voting information can be sufficiently kept confidential, and the legitimacy of the voting results can be verified by a third party.

[0025] A program according to another aspect of the present invention causes a second terminal to execute a voting information transmission process that transmits voting information, including voting destination information indicating at least one vote by the user of the second terminal and vote count information indicating the number of votes for at least one vote, to a first terminal that can communicate with the second terminal.

[0026] Furthermore, the program according to the above embodiment associates encrypted vote record information based on public key information and random number information with approval information indicating whether the user of the second terminal has approved that encrypted vote information, which includes encrypted vote destination information and encrypted vote count information and has been threshold signed by the first and second terminals, be recorded through the first terminal. The program executes a vote management information update process that updates the vote management information used for verifying threshold signatures, which is recorded in a distributed ledger that can communicate with the first and second terminals, by transmitting vote validity information to the distributed ledger.

[0027] In this embodiment, the user of the second terminal can record in the distributed ledger that they have authorized the recording of encrypted voting information through the first terminal by transmitting vote validation information. By recording this authorization in the distributed ledger, a third party can verify the legitimacy of the vote cast through the first terminal. The recording of this authorization in the distributed ledger, based on the vote validation information from the user of the second terminal, verifies that there has been no double voting by the user of the second terminal.

[0028] In the processing by the program according to the other embodiments described above, the voting information transmission process may transmit the first voting destination and the second voting destination to the first terminal, with at least one voting destination being the first voting destination.

[0029] According to this embodiment, even if the user of the second terminal has multiple voting rights, a third party can verify the legitimacy of the vote cast through the first terminal.

[0030] A voting management system according to another aspect of the present invention comprises a first terminal storing a program according to the above aspect, and a second terminal storing a program according to the other aspect. The vote management information recording process in the first terminal includes the first terminal transmitting vote management information to a smart contract provided on a distributed ledger, and the vote management information updating process in the second terminal includes the second terminal transmitting vote validation information to the smart contract. The smart contract records the vote management information in a distributed ledger, updates the vote management information recorded in the distributed ledger based on the vote validation information, and generates approved vote management information, which is vote management information indicating that the recording of voting information through the first terminal has been approved by a second user.

[0031] According to this configuration, updates to vote management information can be recorded in a distributed ledger, thus preventing tampering with the vote management information. Furthermore, by generating approved vote management information, a third party can verify the legitimacy of the vote cast through the first terminal. [Effects of the Invention]

[0032] According to the present invention, it is possible to provide a program, a voting management method, a terminal, and a voting management system that enable verification of the legitimacy of voting results by a third party while keeping voting information sufficiently confidential. [Brief explanation of the drawing]

[0033] [Figure 1] This is a block diagram of the voting management system according to the first embodiment. [Figure 2] This is an example of information stored in the memory unit of the voting management device according to the first embodiment. [Figure 3] This is a diagram illustrating the voting information according to the first embodiment. [Figure 4] This diagram illustrates the recording process of encrypted voting information according to the first embodiment. [Figure 5] This diagram illustrates the document management information and the updating of document management information according to the first embodiment. [Figure 6]This diagram illustrates the recording process of checklist information according to the first embodiment. [Figure 7] This diagram illustrates the recording process of encrypted voting information according to the first embodiment. [Figure 8] This diagram illustrates the recording process of checklist information according to the first embodiment. [Figure 9] This figure illustrates an example of ticket management information according to the first embodiment. [Figure 10] This figure illustrates an example of vote counting information that publishes the number of votes received according to the first embodiment. [Figure 11] This is a flowchart illustrating the vote count verification process according to the first embodiment. [Figure 12] This diagram illustrates the case where the voting information according to the first embodiment includes multiple voting destinations. [Figure 13] This is a block diagram of the voting management system according to the second embodiment. [Figure 14] This figure illustrates an example of vote counting information that publishes the number of votes received according to the second embodiment. [Figure 15] This diagram illustrates the recording process of checklist information according to the second embodiment. [Figure 16] This figure illustrates an example of ticket management information according to the second embodiment. [Figure 17] This is a flowchart illustrating the vote count verification process according to the second embodiment. [Figure 18] This is a block diagram of the voting management system according to the third embodiment. [Figure 19] This diagram illustrates the process for obtaining voting information according to the third embodiment. [Figure 20] This diagram illustrates the recording process of ticket management information according to the third embodiment. [Figure 21] This diagram illustrates the document management information and the updating of document management information according to the third embodiment. [Figure 22] This diagram illustrates the recording process of checklist information according to the third embodiment. [Modes for carrying out the invention]

[0034] A preferred embodiment of the present invention will be described with reference to the attached drawings. In each drawing, components denoted by the same reference numerals have the same or similar configuration.

[0035] Figure 1 shows a block diagram of the voting management system 10 according to the first embodiment. The voting management system 10 comprises an administrator terminal 100, voter terminals 200a, 200b, 200c, and 200d, a distributed ledger 300, and a verifier terminal 400. When there is no need to distinguish between them, the voter terminals 200a, 200b, 200c, and 200d are collectively referred to as the voter terminal 200.

[0036] In the first embodiment, as an example, a case in which voting on proposals at a shareholders' meeting is conducted using the voting management system 10 will be described. In this case, the administrator terminal 100 is a terminal used by an administrator, such as a trust bank, that performs securities agency services and manages voting at the shareholders' meeting. Voter terminals 200a, 200b, 200c, and 200d are terminals used by each shareholder to exercise their respective voting rights and cast their votes. There may be multiple voter terminals. The votes from each voter are recorded in the distributed ledger 300. The verifier terminal 400 is a terminal used by a person who verifies or audits the votes. The verifier only needs to be a person who can access the distributed ledger 300.

[0037] The administrator terminal 100 (first terminal) is connected to the voter terminal 200 and the distributed ledger 300 via network N. The verifier terminal 400 is connected to the distributed ledger 300 via network N. Network N is, for example, the internet.

[0038] The administrator terminal 100 is an information processing device having a computer that performs predetermined processing by executing a predetermined program. For example, the administrator terminal 100 is a server or a personal computer.

[0039] The components of the administrator terminal 100 will now be described. The administrator terminal 100 includes a storage unit 101, a communication unit 102, a voting information acquisition unit 103, a vote generation unit 104, a key information generation unit 105, a vote management information recording unit 106, a voting unit 107, a vote inspection information generation unit 108, a vote inspection information recording unit 109, and a vote collection unit 110. Each component of the administrator terminal 100 can be implemented, for example, by using a storage area such as memory in the administrator terminal 100, or by having a processor execute a program stored in the storage area.

[0040] The memory unit 101 stores various types of information used for processing on the administrator terminal 100. As shown in Figure 2, voter information and candidate information are stored in the memory unit 101.

[0041] Voter information includes the voter's name, voter ID, and number of votes held. The voter ID is an identifier for each voter. The number of votes held is the number of votes each voter has, for example, in proportion to the number of shares they own. For illustrative purposes, four voters are shown, but the number of voters may be greater.

[0042] The proposal information includes the following fields: proposal name, proposal ID, and voting ID. The proposal ID is used to identify each proposal. The voting ID has two parts for each proposal: one indicating a vote in favor and another indicating a vote against. For example, the voting ID for proposal ID "PR01" is "PR01F" if you vote in favor, and "PR01A" if you vote against.

[0043] The voting management system 10 manages each voter based on voter information stored in the memory unit 101. Voters are managed so that they can vote using voter terminals 200 and administrator terminals 100 after undergoing identity verification on a portal site managed by an administrator. Because identity verification is performed, voting in the voting management system 10 is done by registered vote.

[0044] The communications unit 102 controls communication between the administrator terminal 100 and external parties, including voter terminals 200 and distributed ledgers 300, via the network N.

[0045] The voting information acquisition unit 103 acquires voting information from the voter terminal 200, including a voting destination ID (voting destination information) indicating the voting destination and the number of votes for that destination (voting count information).

[0046] Figure 3 shows, as an example, the voting information of four voters in the voter information of Figure 2 for proposal ID "PR01". The voting information includes the voter ID, voting destination ID, and number of votes. Figure 3 shows the voting information V1 (first voting information), V2 (second voting information), V3, and V4 for each voter. When there is no need to distinguish between them, voting information V1 to V4 are collectively referred to as voting information V.

[0047] For example, suppose voter A, whose voter ID is "SH01," is in favor of proposal A. In this case, voter A sends voting information V1, indicating that they will cast 10 votes (corresponding to the number of shares they own) for voting ID "PR01F," to the administrator terminal 100 via voter terminal 200a, along with their voter ID "SH01." The same procedure applies to other voters.

[0048] The vote generation unit 104 generates encrypted voting information EV1 (encrypted voting information) in which the voting destination ID and the number of votes are encrypted and threshold signed by the administrator terminal 100 and the voter terminal 200. Figure 4 shows an example of encrypted voting information EV1. Here, encrypted voting information EV11, EV12, EV13, and EV14 based on each voter's voting information V are shown. When there is no need to distinguish between them, encrypted voting information EV11 to EV14 are collectively referred to as encrypted voting information EV1. Encrypted voting information EV1 is recorded in the storage unit 101 of the administrator terminal 100.

[0049] The vote generation unit 104 encrypts the voting information using a type of encryption that allows addition, that is, an encryption of a type in which the result of adding encrypted information matches the encrypted information obtained by adding the unencrypted information. In other words, the vote generation unit 104 encrypts the voting information using homomorphic encryption. In Figure 4, for example, in the encrypted voting information EV11, the fact that the voting destination ID "PR01F" is encrypted is indicated as "E(PR01F)". The same applies to the number of votes. The vote generation unit 104 encrypts the voting destination ID using voting destination random number information, which is predetermined random number information, to encrypt the voting destination ID.

[0050] When encrypting the vote count, it is also acceptable to blind the vote count before encryption. Blinding is a technique that, for example, multiplies the vote count by a random number to make it practically impossible to determine the encrypted vote count.

[0051] Blinding is performed under the following conditions: (1) The total number of votes after blinding is the sum of the total number of votes and the random numbers used for blinding. (2) It is possible to extract the total number of votes from the total number of votes after blinding. (3) It is not possible to derive the number of votes or the random numbers used for blinding from the encrypted number of votes after blinding. (4) The total number of encrypted blinded votes is equal to the total number of blinded votes that has been encrypted.

[0052] Furthermore, a threshold signature is a type of digital signature. A threshold signature is a digital signature that becomes valid when a certain number of those who participated in creating the signature agree, but is invalid if the number is less than that. In the first embodiment, a threshold signature where there are two participants, a voter and an administrator, and the number of people required for agreement is two, is simply referred to as a threshold signature.

[0053] Threshold signatures indicate that the data has been verified by both the voter and the administrator. Threshold signatures utilize the administrator's private key SK0 (first private key information) and the voter's private key SK1 (second private key information), which are generated from random numbers by the administrator terminal 100 and the voter terminal 200, respectively. For example, in the encrypted voting information EV11 shown in Figure 4, signatures are made by adding signature information σ0 based on private key SK0 and signature information σ1 based on private key SK1 to the encrypted voting information EV11.

[0054] In Figure 4, the signature information is shown as "σ1,σ0(PK10)". This indicates that the encrypted voting information EV11 is signed by the signature information σ0,σ1, and the public key PK10 is used for verification. The signature information includes the public key used for the signature. The threshold signature process according to the first embodiment will be described later. It is guaranteed that the probability of two independently created threshold signatures having the same public key by chance is extremely low in practical terms.

[0055] The encrypted voting information EV11 to EV14 is recorded in the distributed ledger 300 by the voting unit 107, which will be described later. It is not possible to determine the original voting destination ID from the encrypted voting destination ID. Similarly, it is not possible to determine the original vote count from the encrypted vote count. Therefore, even if a third party obtains the encrypted voting information EV11 to EV14, which is recorded in the distributed ledger 300, the third party cannot learn the progress of the voting.

[0056] The key information generation unit 105 generates public key information used for verifying threshold signatures. The key information generation unit 105 shares public key PK0 (first public key information) based on private key SK0 and public key PK1 (second public key information) based on private key SK1 with the voter terminal 200. The key information generation unit 105 generates public key PK10 (public key information) based on public key PK0 and public key PK1. For example, public key PK10 is generated by multiplying private key SK0 by public key PK1.

[0057] The vote management information recording unit 106 records vote management information in the distributed ledger 300. The vote management information is managed by a smart contract 301 provided in the distributed ledger 300. The smart contract 301 is a mechanism that specifies that processing based on a program is executed when a program recorded on the distributed ledger 300 is executed. In subsequent embodiments, the execution of the mechanism specified in the smart contract 301 will be described using the smart contract 301 as the subject, for example, "The smart contract 301 performs the predetermined processing."

[0058] Voter management information is information that voters can update, and indicates whether or not a voter has approved the recording of encrypted voting information EV1 in the distributed ledger 300 via the administrator terminal 100. Voter management information includes a commitment (vote verification information) encrypted based on the hash value S1 of the public key PK10 and a random number r1. Voter management information includes the commitment and the status (approval information) associated with the commitment.

[0059] In the first embodiment, a commitment is expressed as c(S,r) using, for example, a hash value S and a random number r (random number information). Alternatively, as the j-th commitment, it is expressed as cj(Sj,rj).

[0060] Figure 5 shows an example of commitments and the status associated with a commitment recorded in the distributed ledger 300. When the vote generation unit 104 generates encrypted voting information EV1 for each voter, the vote management information recording unit 106 generates a commitment. At this time, the vote management information recording unit 106 obtains a random number r from the voter terminal. The commitment is transmitted to the smart contract 301 by the vote management information recording unit 106. The commitment is managed by the smart contract 301 and recorded in the commitment pool, which is a data structure provided on the distributed ledger 300. The vote management information recording unit 106 also transmits the commitment to the voter terminal 200.

[0061] Each commitment in the commitment pool is associated with an approval status. The status records approval information, such as "Approved," indicating that the voters corresponding to each commitment have approved the vote by the administrator terminal 100, or "Unapproved," indicating that it has not been approved.

[0062] A commitment can be encrypted, for example, using an elliptic curve. It is not possible to derive a hash value and random elements from a commitment. A commitment satisfies several operational rules. In operations on a commitment, the portion using the hash value can be decrypted based on the hash value S. That is, the encrypted component of the portion using the hash value can be subtracted from the commitment based on the hash value S.

[0063] Voters update the status associated with the commitment corresponding to their voting information by setting it to "approved," based on the commitment obtained from the administrator terminal 100. The update process is performed by the smart contract 301. Figure 5 shows the commitments and statuses before and after approval by four voters.

[0064] Based on the vote management information, the voting unit 107 records the encrypted voting information EV1 in the distributed ledger 300 if the voter has approved its recording in the distributed ledger 300. An example of recorded encrypted voting information is shown in Figure 4.

[0065] As shown in Figure 6, the vote verification information generation unit 108 generates vote verification information EV2 (vote verification information) with verification information VR attached, without encrypting the vote destination ID. The vote verification information EV2 also includes random number information and signature information. The vote verification information EV2 is information that can be verified as having been jointly created by the voter and the administrator, and is generated by the voter terminal 200.

[0066] Figure 6 shows the vote counting information EV21, EV22, EV23, and EV24 based on each voter's voting information. When there is no need to distinguish between them, the vote counting information EV21 to EV24 are collectively referred to as vote counting information EV2.

[0067] The random number information for voting destination is the random number Rj used to encrypt the voting destination ID. The random number Rj is generated based on the random numbers generated by each voter terminal. The signature information, similar to the encrypted voting information EV1, indicates, for example, that the vote verification information EV21 is signed by the signature information σ0 and σ1, and that the public key PK10 is used for verification.

[0068] Verification information VR is information expressed in the form VR(Qj,Σ(j,rj)). Here, Qj is the public key associated with the signature information attached to the encrypted voting information EV1. j is the number that points to the commitment in the commitment list described later. rj is the random number of the commitment pointed to by j. Σ(j,rj) is information generated based on the commitments on the commitment list. Σ(j,rj) is generated using j and rj, but it is not possible to derive j or rj from Σ(j,rj). Furthermore, in order to create a valid Σ(j,rj), the information of j and rj associated with the commitments on the commitment list is required. The creation of the commitment list and verification information VR will be described later.

[0069] Verification is performed using the verifier terminal 400, based on the verification information VR. Verification is performed by the verifier terminal 400 performing calculations based on the vote management information and the verification information VR(Qj,Σ(j,rj)). The verifier terminal 400 verifies that the encrypted voting information EV1, which corresponds to the vote inspection information EV2 containing the verification information VR(Qj,Σ(j,rj)), was jointly created by the voters and the administrator.

[0070] Due to the above features, it becomes possible for a third party to verify the votes using the verifier terminal 400. The verification process will be described later.

[0071] The vote counting information recording unit 109 records the vote counting information EV2 for each voter in the distributed ledger 300, for example, when the vote collection period ends, as shown in Figure 6.

[0072] The vote collection unit 110 calculates the number of votes for each voter based on the voting information of each voter obtained through the voter terminal 200. That is, it sums up the number of votes cast for each voter. The vote collection unit 110 publishes the number of votes for each voter as the vote collection result through the network N.

[0073] Next, we will describe the various parts of the voter terminal 200. Here, we will describe the parts of voter terminal 200a, but the same applies to voter terminals 200b, 200c, 200d and other voter terminals. The voter terminal 200 comprises a storage unit 201, a communication unit 202, a voting information transmission unit 203, and a vote management information update unit 204.

[0074] The voter terminal 200 (second terminal) is an electronic device used by the voter, and in this case, it is assumed to be a smartphone. However, the voter terminal 200 may also be a tablet device or a personal computer. The functions of each part of the voter terminal 200 are realized by programs stored on the voter terminal 200.

[0075] The storage unit 201 stores various types of information used for processing at the voter terminal 200. The communication unit 202 controls communication with external parties, including the administrator terminal 100 and the distributed ledger 300, via the network N.

[0076] The voting information transmission unit 203 receives voting information input from voters and transmits the received voting information to the administrator terminal 100.

[0077] The vote management information update unit 204 transmits vote management information to the distributed ledger 300 and updates the commitment of the smart contract 301 in the distributed ledger 300. This allows voters to authorize the recording of their voting information V in the distributed ledger 300 via the administrator terminal 100.

[0078] The Distributed Ledger 300 is a system that allows multiple terminals to share information and the history of records recorded in the Distributed Ledger 300. The Distributed Ledger 300 can also be called a blockchain network. In the Distributed Ledger 300, information is added while multiple ledgers maintain the history, making it difficult to tamper with the history.

[0079] The distributed ledger 300 according to the first embodiment is a publicly accessible distributed ledger whose access is not protected by confidentiality. A commonly used distributed ledger can be used as the publicly accessible distributed ledger. Since there is no need to maintain a separate confidential distributed ledger, the burden on administrators is reduced, and administrator convenience may be improved.

[0080] The distributed ledger 300 has a smart contract 301. The smart contract 301 manages the commitment pool.

[0081] When a commitment is sent from the administrator terminal 100, smart contract 301 adds a new commitment to the commitment pool. When smart contract 301 receives a commitment, it associates the commitment with a "number" previously assigned by the administrator terminal 100, sets the "status" to "unapproved," and adds the commitment to the commitment pool.

[0082] Smart contract 301 enables devices accessing smart contract 301 to retrieve information about commitments in the commitment pool.

[0083] When a commitment is sent from the voter terminal 200, the smart contract 301 updates the status associated with that commitment from "unapproved" to "approved".

[0084] When the voting period ends, smart contract 301, upon request from administrator terminal 100, extracts commitments with a status of "approved" and generates a commitment list. The commitment list is available to verifier terminal 400. Furthermore, any terminal with access to smart contract 301 can retrieve the commitment list.

[0085] The verifier terminal 400 is a terminal used by the verifier who verifies the votes, and in this case, it is assumed to be a personal computer. The verifier terminal 400 has a storage unit 401, a communication unit 402, a verification information acquisition unit 403, and a verification unit 404. The verifier terminal 400 may also be a smartphone or a tablet terminal. The functions of each part of the verifier terminal 400 are realized by programs recorded on the verifier terminal 400.

[0086] The storage unit 401 stores various types of information used for processing on the verifier terminal 400. The communication unit 402 controls communication with external parties, including the distributed ledger 300, via the network N.

[0087] The verification information acquisition unit 403 acquires information necessary for verifying the voting results from both the administrator terminal 100 and the distributed ledger 300. Specifically, the verification information acquisition unit 403 acquires encrypted vote counts from the administrator terminal 100 and a commitment list from the smart contract 301.

[0088] The verification unit 404 performs verification processing of the voting results based on the information acquired by the verification information acquisition unit 403. Details of the verification process will be described later.

[0089] The operation of the voting management system 10 will be explained with reference to Figure 7. Figure 7 shows a flowchart of the process by which voting information transmitted by voter A via voter terminal 200a is recorded in the distributed ledger 300 as encrypted voting information EV11.

[0090] In step S101, the voting information transmission unit 203 transmits the voting information V1 to the administrator terminal 100. At the same time, the voting information transmission unit 203 also transmits a random number to the administrator terminal 100 for generating the random number R1, which is the random number information for the voting destination. The voting information V1 may be generated by the vote generation unit 104 so as to include information necessary, for example, to encrypt the voting destination.

[0091] In step S102, the vote generation unit 104 encrypts the voting information V1 and generates encrypted voting information EV11 in which the voting destination and the number of votes are encrypted. The voting information acquisition unit 103 also stores the voting information V1 in the storage unit 101. Here, the vote generation unit 104 generates encrypted voting information EV11 based on the information contained in the voting information V1, for example, the information necessary to encrypt the voting destination.

[0092] In step S103, the vote generation unit 104 transmits encrypted voting information EV11 to the voter terminal 200a.

[0093] In step S104, the voting information transmission unit 203 generates signature information σ1 based on the private key SK1 of the voter terminal 200a. In step S105, the vote generation unit 104 generates signature information σ0 based on the private key SK0 of the administrator terminal 100.

[0094] In step S106, the key information generation unit 105 shares public key PK1 and public key PK0 between the administrator terminal 100 and the voter terminal 200a. The key information generation unit 105 also shares signature information σ1 and signature information σ0 between the administrator terminal 100 and the voter terminal 200a.

[0095] In step S107, the voting information transmission unit 203 verifies the validity of the signature information σ0 based on the public key PK0. In step S108, the vote generation unit 104 verifies the validity of the signature information σ1 based on the public key PK1.

[0096] In step S109, the voting information transmission unit 203 signs the encrypted voting information EV11 using the signature information σ1.

[0097] In step S1010, the voting information transmission unit 203 transmits the encrypted voting information EV11(σ1), signed with signature information σ1, to the administrator terminal 100. Here, "(σ1)" indicates that the encrypted voting information EV11 is signed with signature information σ1.

[0098] In step S1011, the vote generation unit 104 signs the encrypted vote information EV11(σ1) using the signature information σ0. In step S1012, the key information generation unit 105 generates the public key PK10 using the public key PK1 and the private key SK0.

[0099] In step S1013, the vote management information recording unit 106 calculates the hash value S1 of the public key PK10. The vote management information recording unit 106 also generates a random number r1.

[0100] In step S1014, the vote management information recording unit 106 generates a commitment c1(S1,r1) based on the hash value S1 and the random number r1.

[0101] In step 1015, the vote management information recording unit 106 sends commitment c1(S1,r1) to the smart contract 301 of the distributed ledger 300.

[0102] In step S1016, the vote management information recording unit 106 transmits commitment c1(S1,r1) to the voter terminal 200.

[0103] In step S1017, smart contract 301 adds commitment c1(S1,r1) to the commitment pool.

[0104] In step S1018, the vote management information update unit 204 sends commitment c1(S1,r1) to the smart contract 301 as vote validation information.

[0105] In step S1019, smart contract 301 processes the status associated with commitment c1(S1,r1) to approved. In this way, voters approve commitment c1(S1,r1) associated with their vote. Note that each voter cannot approve commitments in the commitment pool that are not associated with their vote.

[0106] In step S1020, the administrator terminal 100 retrieves the commitment pool from the distributed ledger 300. Since the status associated with commitment c1(S1,r1) in the commitment pool is "approved", in step S1021, the voting unit 107 sends the encrypted voting information EV11(σ1,σ0) to the distributed ledger 300 and records it.

[0107] Through the processing described above, the encrypted voting information EV11 is threshold-signed by the signature information σ1 and σ0 and recorded in the distributed ledger 300.

[0108] Referring to Figure 8, the vote counting and verification processes after the voting period has ended will be explained. Here, as shown in Figure 7, voting information V will be used to explain the process without distinguishing between individual voters.

[0109] In step S201, the ticket inspection information generation unit 108 sends a request to the smart contract 301 to generate a commitment list.

[0110] In step S202, smart contract 301 extracts commitments with an approved status from the commitment pool and generates a commitment list. An example of a commitment list is shown in Figure 9.

[0111] In step S203, the ticket inspection information generation unit 108 obtains the commitment list from the smart contract 301.

[0112] In step S204, the ticket verification information generation unit 108 generates verification information VR(Qj,Σ(j,rj)) based on the public key Qj used to generate each commitment, as shown in Figure 9. At this time, Σ(j,rj) is generated based on the public key Qj and is generated by subtracting the value corresponding to Sj of each commitment from the commitment.

[0113] In step S205, the ticket inspection information generation unit 108 transmits the ticket inspection information EV2, to which the verification information VR(Qj,Σ(j,rj)) has been attached, to the distributed ledger 300 and records it.

[0114] In step S206, the vote collection unit 110 tally the number of votes for each party based on the voting information V stored in the storage unit 101.

[0115] In step S207, the vote collection unit 110 publishes the vote collection results via the network N. An example of the vote collection results is shown in Figure 10. For each proposal, the vote collection results are published as the number of votes received for each voting ID. In Figure 10, for proposal ID "PR01", the number of votes received by voting ID "PR01F" indicating support is published as the published vote count "40".

[0116] In step S208, the verification information acquisition unit 403 requests a commitment list from the smart contract 301.

[0117] In step S209, the smart contract 301 sends the commitment list to the verifier terminal 400.

[0118] In step S210, the verification information acquisition unit 403 acquires encrypted voting information EV1 and vote verification information EV2 from the distributed ledger 300.

[0119] In step S211, the verification unit 404 performs verification processing.

[0120] Refer to Figure 11 for a detailed explanation of the verification process. Figure 11 shows a flowchart of the process in the verification unit 404.

[0121] In step S301, the verification unit 404 associates the encrypted voting information EV1 with the corresponding vote verification information EV2 based on the public key. Specifically, it associates the encrypted voting information EV1, which includes a common public key, with the vote verification information EV2.

[0122] In step S302, the verification unit 404 compares the number of commitments N1 included in the commitment list with the number of pairs of encrypted voting information EV1 and vote verification information EV2 associated with them, N2.

[0123] In step S303, the verification unit 404 determines whether the number N1 and the number N2 match. If they do not match, the verification unit 404 determines in step S309 that there was fraud in the voting. In this case, the fraud is either double voting by a voter or intentional forfeiture or addition of votes by an administrator.

[0124] In step S304, the verification unit 404 determines whether the signature information contained in the encrypted voting information EV1 and the vote verification information EV2 is valid. If the signature information is not valid, the verification unit 404 determines in step S311 that there was fraud in the voting. In this case, the fraud is the alteration of votes by an administrator.

[0125] In step S305, the verification unit 404 determines whether Σ(j,rj) is valid for each commitment in the commitment list based on the public key Qj. Here, valid means that the vote is from an eligible voter. If Σ(j,rj) is not valid, the verification unit 404 determines in step S309 that there was fraud in the voting. In this case, the fraud is the intentional confiscation and addition of votes by the administrator.

[0126] In step S306, the verification unit 404 determines whether the vote destination recorded in the acquired encrypted voting information EV1 corresponds to the vote destination in the vote verification information EV2. This determination is made based on the random number information included in the vote verification information EV2 that corresponds to that vote destination. If they do not match, the verification unit 404 determines in step S309 that there was fraud in the voting. In this case, the fraud is the rewriting of the vote destination by the administrator.

[0127] In step S307, the verification unit 404 determines whether the sum of encrypted vote counts based on encrypted voting information EV1 for each voting destination matches the encrypted value of the vote count results published by the vote counting unit 110 through the network N. If they do not match, the verification unit 404 determines in step S309 that there was fraud in the counting process.

[0128] In step S308, the verification unit 404 determines that there was no fraud in the voting.

[0129] When a voter sets the status of the commitment associated with their voting information to "approved," the information of the voter who made the update is recorded on the distributed ledger 300. The commitment list is extracted from the commitment pool of commitments whose status is "approved." In addition, in order to create a valid Σ(j,rj), the information of j and rj associated with the commitment on the commitment list is required. Therefore, the validity of the verification information VR(Qj,Σ(j,rj)) means that the vote corresponds to an "approved" commitment by a certain voter. Thus, by verifying the verification information VR(Qj,Σ(j,rj)), the verifier can confirm that the encrypted voting information EV1 and vote verification information EV2 were votes created by a certain voter.

[0130] On the other hand, the recording of encrypted voting information EV1 and vote verification information EV2 onto the distributed ledger 300 is performed by the administrator via the administrator terminal 100. Therefore, a third party cannot infer which specific voter the encrypted voting information EV1, vote verification information EV2, and public key Qj are associated with. Furthermore, it is not possible to derive j or rj from Σ(j,rj). Thus, a third party cannot determine from the verification information VR(Qj,Σ(j,rj)) which voter created the encrypted voting information EV1 and vote verification information EV2. As a result, the validity of the vote is verified without linking the information of a specific voter recorded on the distributed ledger 300 with the encrypted voting information EV1 and vote verification information EV2.

[0131] Furthermore, the verification process by the verifier terminal 400 is performed based on encrypted vote counts. Therefore, since the verifier does not obtain the actual number of votes for each party, voter information remains sufficiently confidential. In this way, the voting management system 10 allows for verification of the legitimacy of voting results by a third party while keeping voting information sufficiently confidential.

[0132] In the embodiments described above, voters cast their votes using voting information that had one voting destination. However, the voting information is not limited to one voting destination; as shown in Figure 12, there may be multiple voting destinations.

[0133] For example, voter C in Figure 12 may use voting information to divide their votes for proposal "PR02" and cast an equal number of votes for both "yes" and "no." In this case, voter C can express their support for both the "yes" and "no" positions. Therefore, the degree of freedom of voters to express their will through their voting actions is increased.

[0134] Furthermore, as shown by voter D in Figure 12, voters may cast their votes using voting information that includes the voting IDs for each of the multiple proposals within a single voting record. In this case, voter D only needs to create one voting record to cast their vote, thus improving voter convenience.

[0135] Furthermore, although the voting management system 10 was described using the voting of voting rights at a shareholders' meeting as an example in the embodiments described above, the voting management system 10 can be used for other types of voting. An example of voting that requires voting is voting in an election, where one candidate is selected from among several candidates.

[0136] A second embodiment will now be described. In the second embodiment and subsequent embodiments, descriptions of matters common to the first embodiment will be omitted, and only the differences will be described. In particular, similar effects and advantages due to similar configurations will not be mentioned sequentially for each embodiment.

[0137] In the voting management system 10A of the second embodiment, the vote collection results are not published as the number of votes received, as in the voting management system 10 of the first embodiment, but only the ranking of the vote collection results is published as the vote collection result.

[0138] Figure 13 shows a block diagram of the voting management system 10A according to the second embodiment. The voting management system 10A comprises an administrator terminal 100A, voter terminals 200a, 200b, 200c, 200d, a distributed ledger 300, and a verifier terminal 400. The administrator terminal 100A (first terminal) is connected to the voter terminals 200 and the distributed ledger 300 via a network N.

[0139] The administrator terminal 100A is an information processing device that has a computer that performs predetermined processing by executing a predetermined program. For example, the administrator terminal 100A is a server or a personal computer.

[0140] The various parts of the administrator terminal 100A will now be described. The administrator terminal 100A includes a storage unit 101, a communication unit 102, a voting information acquisition unit 103, a vote generation unit 104, a key information generation unit 105, a vote management information recording unit 106, a voting unit 107, a vote verification information generation unit 108A, a vote verification information recording unit 109, a vote collection unit 110, a certification information generation unit 111, a vote count encryption unit 112, a ranking information generation unit 113, and a ranking information recording unit 114. Each part of the administrator terminal 100A can be realized, for example, by using a storage area such as memory in the administrator terminal 100A, or by having a processor execute a program stored in the storage area.

[0141] The memory unit 101, communication unit 102, voting information acquisition unit 103, vote generation unit 104, key information generation unit 105, vote management information recording unit 106, voting unit 107, vote verification information recording unit 109, and vote collection unit 110 have the same functions as the administrator terminal 100 according to the first embodiment. However, in the second embodiment, the vote collection unit 110 does not publish the vote collection results including the number of votes received, but publishes the vote collection results including ranking information. The vote verification information generation unit 108A differs from the vote verification information generation unit 108 in that it generates vote verification information EV2, which has vote certification information added to the verification information VR, but otherwise they are the same.

[0142] The certification information generation unit 111 generates vote certification information that proves that the encrypted vote information EV1 contains encrypted vote count information. The vote certification information is included in the encrypted vote information EV1 and recorded in the distributed ledger 300 when the voting unit 107 records the encrypted vote information EV1 in the distributed ledger 300. The vote certification information is used to prove that even if only the ranking is published as the vote count result, that ranking is based on the vote count information.

[0143] The certification information generation unit 111 generates rank certification information (second certification information) that certifies the rank information generated by the rank information generation unit 113, based on the number of votes received by each voting destination or the number of encrypted votes. The rank certification information is used to prove the correctness of the publicly announced rank itself. Details of the vote certification information and rank certification information will be described later.

[0144] The vote count encryption unit 112 generates encrypted vote count information based on the number of votes for each voter calculated by the vote collection unit 110, with each vote count encrypted.

[0145] The ranking information generation unit 113 generates ranking information indicating the ranking of votes based on the number of votes each voting destination has received, calculated by the vote collection unit 110. For example, if there are multiple voting destinations X, Y, and Z, the ranking information will show the ranking of votes as "1st: Y, 2nd: X, 3rd: Z". In addition to showing the win or loss for each voting destination, the ranking information can also show the case of a tie where there are tied voting destinations. For example, the ranking of votes may be shown as "1st: Y, 2nd: X, 2nd: Z".

[0146] The ranking information recording unit 114 records the ranking information generated by the ranking information generation unit 113 and the ranking certification information generated by the certification information generation unit 111 in the distributed ledger 300. The timing of the ranking information recording unit 114 recording the ranking information and ranking certification information is after the end of the voting period.

[0147] The overview of ranking information generation and ranking publication will be explained with reference to Figure 14. As shown in Figure 14(a), in the voting management system 10A, as in Figure 3, the administrator terminal 100 obtains voting information V1, V2, V3, and V4 from voters A, B, C, and D, respectively. Next, the vote collection unit 110 and the ranking information generation unit 113 calculate the number of votes and generate ranking information. The vote collection unit 110 publishes the vote collection results as shown in Figure 14(b). The vote collection results in Figure 14(b) do not include the "published number of votes" as in the vote collection results in Figure 10, but include the "published ranking". In Figure 14(b), for example, it is shown that for proposal ID "PR01", the ranking of vote destination ID "PR01F", which indicates support, is higher than the ranking of vote destination ID "PR01A", which indicates opposition.

[0148] Details of the vote verification information and ranking verification information will be explained. The vote verification information is information that proves that encrypted vote count information is included in encrypted vote information EV1. Here, it is assumed that the vote count in encrypted vote information EV1 is encrypted after being blinded. Blinding is a method, as explained in the first embodiment, that practically makes it extremely difficult to determine the encrypted vote count by, for example, multiplying the vote count by a random number.

[0149] The encrypted voting information EV1 is recorded in the distributed ledger 300 by the voting unit 107. At this time, the encrypted number of votes is expressed as "vg" by multiplying the blinded number of votes "v" by a point "g" on the specified elliptic curve. Here, v is a scalar represented as a 256-bit binary number and contains the following information. The bit value of v is such that (i) the bottom 128 bits are a "random number" for blinding, (ii) the 32 bits above that are "0", (iii) the 64 bits above that are the "number of votes", and (iv) the 32 bits above that are "0". In this embodiment, a 256-bit elliptic curve cryptography is explained as an example, but it is possible to use elliptic curve cryptography with other numbers of bits in the same way. Specifically, v is expressed by the following formula (1).

[0150]

number

[0151] Here, "x" and "y" in equation (1) are either 0 or 1. Since the encrypted voting information EV1 is recorded in an encrypted state as "vg", it is not possible to check "v" itself by referring to the encrypted voting information EV1 on the distributed ledger 300. In other words, it is not possible to determine from the encrypted voting information EV1 whether or not the encrypted vote count is included. Therefore, it is not possible to know the vote count itself from the encrypted voting information EV1. Also, in equation (1), v is explained with bits separated as 2+30+64+2+30+128 for explanatory purposes, but it is possible to adjust the format of v according to the voting method. For example, the bits may be separated as 2+14+32+2+14+192. When setting the bit separation method, the "random number" part must be long enough, such as 128 bits or more, so that it cannot be cracked by brute force, and the maximum value of the vote weight (maximum number of votes) in the "vote count" part must be 2. 64 The number of records being recorded is less than 2. 30 Care must be taken to ensure that the condition of being less than is met.

[0152] The proof information is generated as a range proof. Known common generation methods can be used to generate range proofs. A range proof is information that proves verifiable that the first few digits of a number "α" are 0 based on "αg". The first proof information is (i) proof information Ra that proves that the first 32 digits of "v" are 0, and (ii) "2 2+30+64 It includes proof information Rb that the top 32 digits of "v" are 0. Both proof information Ra and Rb are range proofs. Proof information Ra proves that the 32 bits above the vote count are 0, and proof information Rb proves that the 32 bits between the random number and the vote count are 0. The first proof information proves that the encrypted vote information EV1 is an encrypted version of the vote count.

[0153] This section explains ranking verification information. Ranking verification information is information that verifies ranking information based on encrypted vote count information. The vote count information V for a given vote before the encrypted vote count information is encrypted can be expressed by the following formula.

[0154]

number

[0155] Note that, as in equation (1), "x" and "y" are used, but these are used only to indicate that the number of bits in question is 0 or 1, and do not mean that the "x" and "y" in equation (2) are the same as the "x" and "y" in equation (1). In the following explanation as well, "x" and "y" will be used to indicate that the number of bits in question is 0 or 1.

[0156] In formula (2), the sum of the votes represents the specific number of votes for a given candidate. Let W be the vote count information for a candidate different from V. The vote count encryption unit 112 multiplies the vote count information generated by the vote collection unit 110 by g to generate encrypted vote count information, such as "Vg" and "Wg". The encrypted vote count information does not reveal the actual number of votes.

[0157] The ranking information generation unit 113 determines the ranking of votes based on the vote count information. Here, we will explain how to rank votes based on two pieces of vote count information V and W, but if it is possible to determine the relative sizes and ties (ranks) of the two pieces of vote count, it is possible to rank votes based on multiple pieces of vote count information by repeating this method.

[0158] The ranking information generation unit 113 combines the vote count information W, represented by formula (3), and the vote count information V, represented by formula (4), into 2 128+30 Based on the sum of these numbers, we perform the operation to obtain the result shown in formula (5). Here, we assume that the number of votes for W (first vote count) is greater than the number of votes for V (second vote count).

[0159]

number

[0160] Here, the number obtained by adding 2 128+30 to the vote count information V has the value of the bit one higher than the bit of the sum of random numbers being "1". Therefore, when performing the operation shown in Equation (5), a bit shift occurs due to the operation of 2 + 30 + 128 bits below the bit portion of the difference in vote counts. When the first vote count is larger than the second vote count, the shift is canceled within the vote count bits (30 + 64 bits) and does not affect the value of the upper 2 bits in (iii) of Equation (5).

[0161] The ranking proof information is generated by the proof information generation unit 111 as a range proof that proves that the upper 2-bit value of "W - V - 2 128+30 " is 0. Specifically, the ranking proof information is information that can prove that the upper 2-bit value of "W - V - 2 128+30 " is 0 based on "Wg - Vg - 2 128+30 g" obtained by encrypting "W - V - 2 128+30 ". That the upper 2-bit value of "W - V - 2 128+30 " is 0 means that "the first vote count is larger than the second vote count", that is, the ranking is that "the vote destination of W is higher than the vote destination of V". Since this is proven by the range proof, it is possible to prove that only the ranking is published without publishing the vote counts and that there is no fraud in the aggregation.

[0162] The ranking information recording unit 114 records the ranking information in the distributed ledger 300. The ranking information is, for example, information indicating that "the vote count for W's vote destination is more than that for V's vote destination". The ranking information recording unit 114 records the ranking proof information corresponding to this ranking in the distributed ledger 300. The recorded ranking proof information is used in the verification process described later. Information in which the difference in vote counts, which is necessary for verifying the ranking, is encrypted (for example, "Wg - Vg - 2 128+30 g") is generated in the verifier terminal 400 that performs the verification process based on the encrypted vote counts recorded in the distributed ledger 300.

[0163] The method described above makes it possible to generate and record ranking information indicating the magnitude of the number of votes in a verifiable manner. Next, we will explain the case where the number of votes is the same, i.e., a tie. In the method described above, when the number of votes for the first and second votes are the same, the borrow in the calculation shown in formula (5) is not canceled out within the number of vote bits (30 + 64 bits), and affects the value of the upper 2 bits (iii) of formula (5). Therefore, "WV-2 128+30 It cannot be proven that the top two bits of the expression are 0, and as a result, it is not possible to prove a draw. Therefore, a different method is needed to prove a draw than to prove a win or loss.

[0164] In the case of a tie, the ranking information generation unit 113 adds 2 to the vote count information W represented by formula (6). 128+30 Based on the number obtained by adding the given factors and the vote count information V represented by formula (6), the calculation is performed to obtain the result shown in formula (7).

[0165]

number

[0166] In the case of a tie, the number of votes for the first and second candidates are the same, so the difference in the number of votes is 0. Here, the vote count information W is 2 128+30 The number obtained by adding the random numbers has a bit value of "1" one position above the sum of the random numbers. Therefore, when performing the operation shown in equation (8), if borrowing occurs in the operation to calculate the difference of the random numbers, that borrowing is canceled out by the bit value one position above the sum of the random numbers. Consequently, the bit value of the 2+30+64th digit from the top in equation (8) is 0.

[0167] In this case, the rank proof information is "W+2 128+30 The proof information generation unit 111 generates a range proof that the top 2+30+64 digits of "-V" are zero. Specifically, the rank proof information is "W+2 128+30 -V" is encrypted "Wg+2 128+30Based on "g-Vg", "W+2 128+30 This information allows us to prove that the bit values ​​of the top 2+30+64 digits of "-V" are 0. 128+30 The fact that the first 2+30+64 bits of "-V" are 0 means that "the number of votes for the first and second votes are equal," that is, "the ranking is a tie between the votes for W and the votes for V." This can be proven by range proof, so it is possible to publish only the rankings without disclosing the number of votes, and to prove that there is no fraud in the counting.

[0168] "W+2 128+30 When the rank proof information that proves the bit values ​​of the top 2+30+64 digits of "-V" is taken as the first rank proof information, in the case of a tie, the rank proof information is obtained by swapping V and W to "V+2 128+30 A range proof that the bit values ​​of the top 2+30+64 digits of "-W" are 0 may be used as the second-rank proof. Since the number of votes in the vote count information V and W are the same, a draw is proven for the same reason as above. Alternatively, both the first-rank proof and the second-rank proof may be combined to form the rank proof.

[0169] The ranking information recording unit 114 records ranking information in the distributed ledger 300. In this case, the ranking information is information such as, "The number of votes received by W and the number of votes received by V are the same." The ranking information recording unit 114 records ranking certification information corresponding to this ranking in the distributed ledger 300. The recorded ranking certification information is used in the verification process described later. The encrypted information of the difference in the number of votes (for example, "Wg+2") is necessary for verifying the ranking. 128+30 g-Vg and Vg+2 128+30 At least one of the "g-Wg" is generated in the verifier terminal 400, which performs verification processing based on the encrypted number of votes recorded in the distributed ledger 300.

[0170] In the voting management system 10A, the vote count is calculated by the vote collection unit 110, so the ranking information generation unit 113 can generate ranking information based on the unencrypted vote count. Therefore, the ranking information generation unit 113 can perform calculations based on the vote count to determine whether to generate ranking information indicating the magnitude of the vote count or ranking information indicating a tie in the vote count. The certification information generation unit 111 generates ranking certification information according to the determination result.

[0171] Referring to Figures 15 and 16, the vote counting and verification processes in the voting management system 10A after the voting period has ended will be described. Here, the explanation will not distinguish between individual voters. The procedure for each voter's encrypted voting information EV1 being threshold-signed and recorded in the distributed ledger 300 is the same as the procedure in the first embodiment.

[0172] In step S401, the ticket inspection information generation unit 108A sends a request to the smart contract 301 to generate a commitment list. In step S402, the smart contract 301 extracts commitments with an approved status based on the commitment pool and generates a commitment list. In step S403, the ticket inspection information generation unit 108A retrieves the commitment list from the smart contract 301.

[0173] In step S404, the ticket verification information generation unit 108A generates verification information VR(Qj,Σ(j,rj)) based on the public key Qj used to generate each commitment, as shown in Figure 16. At this time, Σ(j,rj) is generated based on the public key Qj and is generated by subtracting the value corresponding to Sj of each commitment from the commitment.

[0174] In step S405, the certification information generation unit 111 generates vote certification information Ra and Rb based on the number of votes received.

[0175] In step S406, the ticket inspection information generation unit 108A generates ticket inspection information EV2 to which verification information VR(Qj,Σ(j,rj)) and ticket certification information Raj,Rbj are attached, as shown in Figure 16.

[0176] In step S407, the slip inspection information recording unit 109 transmits the slip inspection information EV2 to the distributed ledger 300 and records it.

[0177] In step S408, the vote collection unit 110 tally the number of votes for each party based on the voting information V stored in the storage unit 101 and calculate the total number of votes.

[0178] In step S409, the ranking information generation unit 113 generates ranking information based on the number of votes.

[0179] In step S410, the certification information generation unit 111 generates rank certification information that proves the rank information.

[0180] In step S411, the rank information recording unit 114 transmits and records the rank information and rank certification information to the distributed ledger 300.

[0181] In step S412, the vote collection unit 110 publishes the vote collection results via the network N. An example of the vote collection results is explained with reference to Figure 14(b).

[0182] In step S413, the verification information acquisition unit 403 requests a commitment list from the smart contract 301. In step S414, the smart contract 301 sends the commitment list to the verifier terminal 400. In step S415, the verification information acquisition unit 403 acquires encrypted voting information EV1, vote verification information EV2, and ranking proof information from the distributed ledger 300.

[0183] In step S416, the verification unit 404 performs verification processing.

[0184] The details of the verification process will be explained with reference to Figure 17. Figure 17 shows a flowchart of the process in the verification unit 404. The processes from steps S501 to S506 are the same as the processes from steps S301 to S306 described with reference to Figure 11 in the first embodiment. Note that in Figure 17, the process in step S309 corresponds to the process in step S511.

[0185] In step S507, the verification unit 404 determines whether the encrypted voting information EV1 contains encrypted vote counts based on the vote verification information EV2. If it is determined that the encrypted voting information EV1 does not contain encrypted vote counts, the verification unit 404 determines in step S511 that there was fraud in the voting process. In this case, the fraud is the rewriting of the vote count by the administrator. More specifically, the rewriting is such that the encrypted voting information EV1 does not contain encrypted blinded vote counts, but instead contains encrypted scalar values.

[0186] In step S508, the verification unit 404 totals the encrypted vote counts based on the encrypted voting information EV1 for each voting destination and calculates the encrypted number of votes.

[0187] In step S509, the verification unit 404 determines that the ranking proof information is generated based on the encrypted number of votes for each voting destination, and the difference in the number of votes is encrypted information (for example, "Wg-Vg-2 128+30 g", Wg+2 128+30 g-Vg, or Vg+2 128+30 It determines whether or not it is consistent with "g-Wg". In other words, it determines whether or not the range proof is correct. If the rank proof information is inconsistent, the verification unit 404 determines in step S511 that there was an error in the aggregation process.

[0188] In step S510, the verification unit 404 determines that there was no fraud in the voting.

[0189] In the second embodiment of the voting management system 10A, in addition to ensuring sufficient confidentiality of voting information, even when only the ranking of the vote count results is made public, the accuracy of the vote count results can be verified by a third party using ranking certification information. This allows for the adoption of a vote counting method that publishes only the rankings, in addition to the method that publishes the number of votes received, thereby increasing the options for vote counting methods.

[0190] A third embodiment will now be described. In the voting management system 10B of the third embodiment, voting is conducted in a manner that allows voters to re-vote, unlike in the voting management systems 10 and 10A where the voting result is not updated once a voter has cast a vote. In addition, in the voting management system 10B of the third embodiment, the number of votes is certified by a certifier, preventing the administrator from changing the number of votes. Voting is conducted in a manner that allows for re-voting.

[0191] Figure 18 shows a block diagram of the voting management system 10B according to the third embodiment. The voting management system 10B comprises an administrator terminal 100B, voter terminals 200a, 200b, a distributed ledger 300, a verifier terminal 400, and a certifier terminal 500. The administrator terminal 100B (first terminal) is connected to the voter terminals 200, the certifier terminal 500, and the distributed ledger 300 via a network N.

[0192] The administrator terminal 100B is an information processing device that has a computer that performs predetermined processing by executing a predetermined program. For example, the administrator terminal 100B is a server or a personal computer.

[0193] The components of the administrator terminal 100B will now be described. The administrator terminal 100B includes a storage unit 101, a communication unit 102, a voting information acquisition unit 103, a vote generation unit 104, a key information generation unit 105, a vote management information recording unit 106B, a voting unit 107, a vote verification information generation unit 108B, a vote verification information recording unit 109B, a vote destination information acquisition unit 115, a signature unit 116, and a vote count information acquisition unit 117. Each component of the administrator terminal 100B can be implemented, for example, by using a storage area such as memory in the administrator terminal 100B, or by having a processor execute a program stored in the storage area.

[0194] The memory unit 101, communication unit 102, voting information acquisition unit 103, vote generation unit 104, key information generation unit 105, voting unit 107, vote inspection information recording unit 109, and vote collection unit 110 have the same functions as the respective units of the administrator terminal 100 in the first embodiment.

[0195] Next, we will describe the vote destination information acquisition unit 115, the signature unit 116, and the vote count information acquisition unit 117, which are configurations added to the administrator terminal 100 of the first embodiment. Next, we will describe the vote management information recording unit 106B and the vote inspection information generation unit 108B, which are configurations that have been changed from the administrator terminal 100 of the first embodiment.

[0196] The voter information acquisition unit 115 acquires voter information from the voter terminal 200, including a voter ID (voter information) indicating the voter's choice. The voter information acquisition unit 115 also encrypts the acquired voter information to generate encrypted voter information.

[0197] The signature unit 116 generates voting destination information that has been threshold-signed by the administrator terminal 100B and the voter terminal 200. The signature unit 116 also generates public key information used to verify the threshold signature.

[0198] The vote count information acquisition unit 117 acquires encrypted vote count information from the voter terminal 200, which contains encrypted vote counts. The encrypted vote count information is signed by the certifier (the user of the certifier terminal 500). The vote count information acquisition unit 117 also acquires unencrypted vote count information from the voter terminal 200.

[0199] The vote management information recording unit 106B records vote management information in the distributed ledger 300. The vote management information is managed by a smart contract 301B provided in the distributed ledger 300. The vote management information is information that can be updated by voters and indicates whether or not a voter has approved the recording of encrypted voting information in the distributed ledger 300 via the administrator terminal 100. Similar to the vote management information in the first embodiment, the vote management information includes commitments and the status (approval information) associated with those commitments.

[0200] Figures 19(a) and (b) show an example of a commitment and the status associated with the commitment recorded in the distributed ledger 300. The commitment is transmitted to the smart contract 301 by the vote management information recording unit 106. The commitment is managed by the smart contract 301B and recorded in the commitment pool, which is a data structure provided on the distributed ledger 300. The vote management information recording unit 106 also transmits the commitment to the voter terminal 200.

[0201] As shown in Figure 19(a), each commitment in the commitment pool is associated with the last commitment approved by the voter and the status of that approval, for each voter managed by the voter ID. The status records approval information, such as "Approved" indicating that the voter corresponding to each commitment has approved the vote by the administrator terminal 100, or "Unapproved" indicating that it has not been approved.

[0202] Voters update the status of the commitment associated with their voting information to "approved," based on the commitment obtained from the administrator terminal 100B. The update process is performed by smart contract 301B. As shown in Figure 19(b), if voter 1 casts a re-vote, the commitment pool information is updated so that the commitment generated in the most recent vote becomes the commitment corresponding to voter 1's vote.

[0203] The commitments recorded by the vote management information recording unit 106B are further associated with information (identity verification information) indicating that the voter's approval has been authorized by a certifier, a third party distinct from the voter and the administrator. Here, the certifier is a trust bank or the like that manages the voting. In the third embodiment, the administrator terminal 100 is a terminal used by a business operator providing voting services, and the certifier terminal 500 is a terminal used by a trust bank or the like. The identity verification information is recorded in the commitment pool in Figures 19(a) and (b) such that the "Identity Verification" item is "Verified" or "Unverified".

[0204] The vote verification information generation unit 108B generates vote verification information EV2 (vote verification information) with verification information VR attached, without encrypting the voting destination, similar to the vote verification information generation unit 108. The vote verification information generation unit 108B further generates vote verification information by including the signature applied to the encrypted vote count information in the vote verification information EV2.

[0205] The certifier terminal 500 is a terminal used by the certifier who certifies the vote, and in this case, it is assumed to be a personal computer. The certifier terminal 500 has a storage unit 501, a communication unit 502, a vote count encryption unit 503, and a certification unit 504. The certifier terminal 500 may also be a smartphone or a tablet device. The functions of each part of the certifier terminal 500 are realized by programs recorded on the certifier terminal 500.

[0206] The memory unit 501 stores various types of information used for processing at the certifier terminal 500. The communication unit 502 controls communication with the outside world via the network N.

[0207] The vote count encryption unit 503 receives a vote request from the voter terminal 200 and obtains the voter's vote count. The vote count encryption unit 503 may, for example, authenticate the voter based on the voter information stored in the storage unit 501. The storage unit 501 also stores the voter ID from the administrator terminal 100, and voter management is performed.

[0208] The certification unit 504 encrypts the number of votes for a particular voting destination obtained from the voter terminal 200 and generates encrypted vote count information. Here, the voting destination information obtained by the certification unit 504 is encrypted voting destination information. The certification unit 504 generates a signature to certify the encrypted voting destination information and the encrypted vote count information. In the third embodiment, the encrypted voting destination information and encrypted vote count information with the signature are collectively referred to as encrypted voting information.

[0209] Furthermore, the certification unit 504 transmits the signed encrypted voting information to the voter terminal 200. The voter terminal 200 transmits the signed encrypted voting information to the administrator terminal 100B. At this time, the voter terminal 200 also transmits the unencrypted vote count information.

[0210] The operation of the voting management system 10B will be explained with reference to Figure 20. Figure 20 shows a flowchart of the process from when voter A transmits encrypted voting information via voter terminal 200a until it is acquired by administrator terminal 100B.

[0211] In step S601, voter terminal 200a sends a vote start request to certifier terminal 500 with information indicating that it has started voting. The vote start request includes the voter ID.

[0212] In step S602, the vote count encryption unit 503 refers to the storage unit 501 to check whether the voter who sent the vote start request is already registered in the storage unit 501. If the voter is registered, in step S603, the vote count encryption unit 503 sends the voter ID of that voter to the administrator terminal 100B. If the voter is not registered, the process is interrupted.

[0213] When the administrator terminal 100B receives the voter ID from the certifying terminal 500, the vote information acquisition unit 115 acquires vote information VD1 from the voter in step S604. The acquisition of vote information VD1 is performed, for example, through a portal site managed by the administrator. The vote information VD1 is generated so that it includes the information necessary for the vote information acquisition unit 115 to encrypt the vote information VD1.

[0214] In step S605, the vote information acquisition unit 115 encrypts the vote information VD1 based on the information contained in the vote information VD1 and the information necessary to encrypt the vote information VD1, thereby generating encrypted vote information EVD1 in which the vote is encrypted. In step S606, the vote information acquisition unit 115 transmits the encrypted vote information EVD1 to the voter terminal 200a.

[0215] In step S607, the key information generation unit 105 shares public key PK1 and public key PK0 between the administrator terminal 100 and the voter terminal 200a. The key information generation unit 105 also shares signature information σ1 and signature information σ0 between the administrator terminal 100 and the voter terminal 200a. The generation of signature information σ1 and σ2 is performed in the same manner as in the first embodiment.

[0216] In step S608, the voting information transmission unit 203 verifies the validity of the signature information σ0 based on the public key PK0. In step S609, the vote generation unit 104 verifies the validity of the signature information σ1 based on the public key PK1. In step S610, the voting information transmission unit 203 signs the encrypted voting information EV11 using the signature information σ1. In step S611, the voting information transmission unit 203 transmits the vote destination information VD1(σ1), signed with the signature information σ1, to the administrator terminal 100.

[0217] In step S612, the signature unit 116 signs the voting destination information VD1(σ1) using the signature information σ0, and generates the voting destination information VD1(σ1,σ0).

[0218] In step S613, the voting information transmission unit 203 transmits encrypted voting destination information EVD1 and vote count information VA1 to the certifier terminal 500. Here, the vote count information VA1 is blinded.

[0219] In step S614, the vote count encryption unit 503 verifies the vote count information VA1. Specifically, the vote count encryption unit 503 verifies whether the blinds in the blinded vote count information are valid blinds. If the vote count encryption unit 503 determines that the blinds are not valid, the process is interrupted.

[0220] In step S615, the certification unit 504 signs the encrypted voting destination information EVD1 and the encrypted vote count information EVA1 with signature information σ2 based on the secret key SK2 of the certifier terminal 500. As a result, encrypted voting information EV1(σ2) is generated. In step S616, the certification unit 504 transmits the encrypted voting information EV1(σ2) to the voter terminal 200a.

[0221] In step S617, the vote count information acquisition unit 117 acquires vote count information VA1 and encrypted vote information EV1(σ2) from the voter terminal 200a. In step S618, the vote count information acquisition unit 117 verifies the signature information σ2 using the public key corresponding to the private key SK2.

[0222] Through the processes described so far, the administrator terminal 100B obtains encrypted vote count information to be recorded in the distributed ledger 300. By recording the encrypted vote count information, which has been signed by the certifier, in the distributed ledger 300 in this way, it becomes impossible for the administrator terminal 100B to alter the vote count obtained from the voters. This ensures the reliability of the voting results.

[0223] Referring to Figure 21, the recording and approval of commitments in the voting management system 10B will be described. Detailed explanations of processes common to the first embodiment will be omitted, but the processing by the vote management information recording unit 106 will be the processing performed by the vote management information recording unit 106B. The processing from step S701 to step S703 is the same as the processing from step S1012 to step S1014 in Figure 7, and the processing in step S704 is the same as the processing in step S1016.

[0224] In step S705, the vote management information recording unit 106B receives a response from the voter terminal 200a indicating that commitment c1 has been confirmed. The processing in steps S706 and S707 is the same as the processing in steps S1015 and S707.

[0225] In step S708, the vote management information update unit 204 sends an approval request to the smart contract 301B of the distributed ledger 300 to approve the approval information of the commitment associated with it. The approval request includes the voter's voter ID.

[0226] In step S709, smart contract 301B sends an inquiry request to certifier terminal 500 to inquire about the voter who submitted the approval request. In step S710, the voter inquiry result based on the voter ID is sent from certifier terminal 500 to smart contract 301B. If the inquiry result in step S709 indicates that the voter is not the correct voter, the process is interrupted.

[0227] In step S711, smart contract 301B associates commitment c1 with a voter and updates the status and identity verification information associated with that commitment. Specifically, as shown in Figure 19(a), the "Status" information is changed to "Approved" and the "Identity Verification" information is changed to "Verified".

[0228] Here, we will explain the re-voting process in the voting management system 10B. In the voting management system 10B, when a voter who has already voted sends a request to start voting, as in step S601, the process described in Figure 20 is executed again.

[0229] Voters can change their voting preferences and vote counts, and the changed information is recorded on the administrator terminal 100B as updated encrypted voting information EV1 and updated encrypted voting preference information EVD1. Based on the updated information, vote verification information EV3, described below, is generated and recorded.

[0230] Next, the administrator terminal 100B generates a new commitment (e.g., commitment c6) that is different from commitment c1, and records it in the smart contract 301B through the processing from steps S701 to S707.

[0231] In step S708, the voter submits an approval request for commitment c6. Subsequently, after processing in steps S709 and S710, in step S711, a process is performed to associate a new commitment c6 with the voter and update the status associated with that commitment. The status of commitments after the re-vote is shown in Figure 19(b).

[0232] Referring to Figure 22, the process in the voting management system 10B, from recording votes by the administrator terminal 100B to verification processing by the verifier terminal 400, will be explained.

[0233] In step S801, the ticket inspection information generation unit 108B sends a request to the smart contract 301B to generate a commitment list. In step S802, the smart contract 301B extracts commitments with an approved status based on the commitment pool and generates a commitment list. In step S803, the ticket inspection information generation unit 108B retrieves the commitment list from the smart contract 301.

[0234] In step S804, the ticket verification information generation unit 108B generates verification information VR(Qj,Σ(j,rj)) based on the public key Qj used to generate each commitment.

[0235] In step S805, the vote verification information generation unit 108B generates vote verification information EV3 which includes unencrypted voting destination information VDj, verification information VR(Qj,Σ(j,rj)), threshold-signed encrypted voting destination information EVDj, and encrypted voting information EVj signed by the certifier.

[0236] The vote verification information EV3 includes the vote destination i, blind b, verification information VR(Qj,Σ(j,rj)), encrypted vote destination information EVDj, encrypted voting information EVj, threshold signature T1 to encrypted vote destination information EVDj, and signature T2 to encrypted voting information EVj.

[0237] Here, since the threshold signature T1 is information signed by both the administrator and the voters, the administrator alone cannot change the matters that should be certified by the threshold signature T1 (vote destination and blinds). This is because if they were to change them, the threshold signature itself would need to be updated, and the administrator cannot update the threshold signature alone.

[0238] Furthermore, since Signature T2 is information signed by the certifier, the administrator cannot change the matters that should be certified by Signature T2 (encrypted voting destination and encrypted number of votes). This is because changing them would require updating Signature T2 itself, and the administrator cannot perform the update of Signature T2.

[0239] In step S806, the vote verification information generation unit 108 transmits the vote verification information EV3 to the distributed ledger 300 for recording. In the voting management system 10B, votes are recorded using the vote verification information EV3, and the encrypted voting information itself is not recorded, as in the case of the voting management system 10 of the first embodiment (see step S1021 in Figure 7).

[0240] In step S807, the vote collection unit 110 aggregates the number of votes for each voter based on the voting destination information VD and the number of votes information VA stored in the storage unit 101. In step S808, the vote collection unit 110 publishes the vote collection results via the network N. The vote collection results may be published as the number of votes for each voting destination ID for each proposal, or only the rankings may be published using the method described in the second embodiment. In other words, the method used in the voting management system 10A in the second embodiment and the method used in the voting management system 10B can be combined.

[0241] In step S809, the verification information acquisition unit 403 requests a commitment list from the smart contract 301. In step S810, the smart contract 301 sends the commitment list to the verifier terminal 400.

[0242] In step S811, the verification information acquisition unit 403 acquires the slip inspection information EV3 from the distributed ledger 300. In step S211, the verification unit 404 performs verification processing. The verification processing in the verification unit 404 is the same as the verification processing in the first embodiment. When combined with the method of the second embodiment, the verification processing is the same as the verification processing in the second embodiment.

[0243] In the voting management system 10B according to the third embodiment, tampering with votes can be prevented by signatures from the certifier terminal 500 and threshold signatures from the voter terminal 200 and the administrator terminal 100. Furthermore, since voters can re-vote during the voting period, the will of the voters can be appropriately reflected. In addition, by requiring approval from the certifier when updating vote management information, it can be ensured that the person updating the vote management information is the actual voter, eliminating any possibility of fraud.

[0244] The embodiments described above are for the purpose of facilitating understanding of the present invention and are not intended to limit its interpretation. The elements and conditions of each embodiment are not limited to those exemplified and can be modified as appropriate. Furthermore, the programs described in the embodiments above can be stored in a storage medium. The storage medium on which the program is stored may be a non-transitory computer-readable medium. The non-transitory storage medium is not particularly limited, but may be, for example, a USB memory stick or a CD-ROM. [Explanation of Symbols]

[0245] 10...Voting management system, 100...Administrator terminal, 101...Storage unit, 102...Communication unit, 103...Voting information acquisition unit, 104...Vote generation unit, 105...Key information generation unit, 106,106B...Vote management information recording unit, 107...Voting unit, 108,108B...Vote verification information generation unit, 109...Vote verification information recording unit, 110...Vote collection unit, 111...Certification information generation unit, 112...Vote count encryption unit, 113...Ranking information generation unit, 114...Ranking information recording unit, 115...Voting destination information Information acquisition unit, 116... Signature unit, 117... Voting count information acquisition unit, 200... Voter terminal, 201... Storage unit, 202... Communication unit, 203... Voting information transmission unit, 204... Vote management information update unit, 300... Distributed ledger, 301... Smart contract, 400... Verifier terminal, 401... Storage unit, 402... Communication unit, 403... Verification information acquisition unit, 404... Verification unit, 500... Certifier terminal, 501... Storage unit, 502... Communication unit, 503... Voting count encryption unit, 504... Certification unit

Claims

1. On the first terminal, A voting information acquisition process that acquires voting information from a second terminal capable of communicating with the first terminal, including voting destination information indicating at least one voting destination by the user of the second terminal and voting number information indicating the number of votes for that at least one voting destination, A vote generation process that generates encrypted voting information which includes encrypted information on at least one voting destination and encrypted information on the number of votes, and which is threshold signed by the first terminal and the second terminal, A key information generation process that generates public key information used for verifying the threshold signature, A vote management information recording process records vote management information, which associates vote record information encrypted based on the public key information and random number information with approval information indicating whether or not the user of the second terminal has approved the recording of the encrypted voting information through the first terminal, in a distributed ledger that can communicate with the first terminal and the second terminal, so that the user of the second terminal can update the approval information. Based on the aforementioned vote management information, if the user of the second terminal has approved that the encrypted voting information be recorded in the distributed ledger, the voting process includes recording the encrypted voting information in the distributed ledger, A vote verification information generation process that generates vote verification information which includes the at least one unencrypted vote destination information, which verifiablely indicates that the vote management information was recorded by the user of the first terminal, and to which verification information based on the random number information is added; A program that performs a record check information recording process, which records the record check information in the distributed ledger.

2. The program according to claim 1, The vote generation process performs the threshold signature on the encrypted voting information based on the first secret key information recorded in the first terminal and the second secret key information recorded in the second terminal. The key information generation process is a program that shares a first public key information based on the first private key information and a second public key information based on the second private key information with the second terminal, and generates the public key information based on the first public key information and the second public key information.

3. A program according to either claim 1 or 2, The user's voting destination information, vote count information, and voting information are, respectively, the first voting destination information, the first vote count information, and the first voting information. The voting information acquisition process further acquires second voting information from a third terminal that can communicate with the first terminal, which includes second voting destination information indicating at least one voting destination by the user of the third terminal and second vote count information indicating the number of votes for that at least one voting destination. On the first terminal, A program that further performs a vote counting process, which calculates the number of votes received for each of the at least one voting destinations based on the first voting information and the second voting information.

4. The program according to claim 1, The voting information acquisition process is a program that acquires a first vote destination and a second vote destination as the at least one vote destination.

5. The first terminal is, Obtaining voting information from a second terminal capable of communicating with the first terminal, which includes voting information indicating at least one voting destination by the user of the second terminal and voting information indicating the number of votes for that at least one voting destination; To generate encrypted voting information which includes encrypted information on at least one voting destination and encrypted information on the number of votes, and which is threshold-signed by the first terminal and the second terminal, To generate public key information used for verifying the threshold signature, Vote management information, which associates vote record information encrypted based on the public key information and random number information with approval information indicating whether or not the user of the second terminal has approved the recording of the encrypted vote information through the first terminal, is recorded in a distributed ledger that can communicate with the first terminal and the second terminal, so that the user of the second terminal can update the approval information. If the user of the second terminal approves that the encrypted voting information be recorded in the distributed ledger based on the vote management information, the encrypted voting information is recorded in the distributed ledger. The process involves generating vote verification information that includes at least one unencrypted vote destination information, verifiable that the vote management information was recorded by the user of the first terminal, and with verification information based on the random number information added; A voting management method that includes recording the aforementioned vote inspection information in the aforementioned distributed ledger.

6. It is a terminal, A voting information acquisition unit acquires voting information from a second terminal capable of communicating with the aforementioned terminal, including voting destination information indicating at least one voting destination by the user of the second terminal and voting number information indicating the number of votes for that at least one voting destination. A vote generation unit that generates encrypted vote information which includes encrypted information for at least one voting destination and encrypted vote count information, and which is threshold signed by the terminal and the second terminal, A key information generation unit that generates public key information used for verifying the threshold signature, A vote management information recording unit records vote management information, which associates vote record information encrypted based on the public key information and random number information with approval information indicating whether or not the user of the second terminal has approved the recording of the encrypted voting information through the terminal, in a distributed ledger that can communicate with the terminal and the second terminal, so that the user of the second terminal can update the approval information. A voting unit records the encrypted voting information in the distributed ledger when the user of the second terminal has approved that the encrypted voting information be recorded in the distributed ledger based on the aforementioned vote management information. A vote verification information generation unit generates vote verification information which includes the at least one unencrypted vote destination information, which can be verified to indicate that the vote management information was recorded by the user of the terminal, and to which verification information based on the random number information is added; A terminal comprising a ticket inspection information recording unit that records the aforementioned ticket inspection information in the distributed ledger.

7. On the second terminal, Voting information transmission process that transmits voting information, including voting destination information indicating at least one voting destination by the user of the second terminal and voting count information indicating the number of votes for the at least one voting destination, to a first terminal that can communicate with the second terminal, A program that performs a vote management information update process, which updates the vote management information used for verifying the threshold signature, recorded in a distributed ledger that can communicate with the first and second terminals, and which includes encrypted vote record information encrypted based on public key information and random number information, and approval information indicating whether or not the user of the second terminal has approved that encrypted voting information, which includes encrypted at least one voting destination information and encrypted vote count information and has been threshold signed by the first and second terminals, be recorded through the first terminal.

8. The program according to claim 7, The voting information transmission process is a program that transmits a first voting destination and a second voting destination to the first terminal as at least one voting destination.

9. The first terminal having the program described in claim 1 stored in it, The second terminal, which stores the program described in claim 7, The process of recording the vote management information in the first terminal includes the first terminal transmitting the vote management information to a smart contract provided on the distributed ledger. The process of updating the vote management information in the second terminal includes the second terminal transmitting the vote validation information to the smart contract. The aforementioned smart contract is The aforementioned ticket management information is recorded in the distributed ledger, Based on the aforementioned ticket validity information, the ticket management information recorded in the distributed ledger is updated. The system generates approved vote management information, which is the vote management information among the vote management information that indicates that the recording of the voting information through the first terminal has been approved by the user of the second terminal. Voting management system.

10. The program according to claim 3, On the first terminal, A first proof information generation process generates first proof information that proves that the encrypted voting information includes the encrypted vote count information, A vote count encryption process generates encrypted vote count information in which the number of votes is encrypted based on the number of votes received for each of the at least one voting destinations, A ranking information generation process that generates ranking information indicating the ranking of the vote counts based on the number of votes each of the at least one voting destinations, A second proof information generation process that generates second proof information to prove the aforementioned ranking information, Further, the system performs a ranking recording process that records the ranking information and the second proof information in the distributed ledger. The aforementioned form inspection information generation process is a program that generates the form inspection information to which the first certification information is further added.

11. On the first terminal, A voting information acquisition process that acquires voting information indicating at least one voting destination by the user of the second terminal from a second terminal that can communicate with the first terminal, A signature process that generates at least one voting destination information that has been threshold-signed by the first terminal and the second terminal, and generates public key information used to verify the threshold signature, A vote count information acquisition process that acquires encrypted vote count information from a second terminal that can communicate with the first terminal, which is encrypted to show at least one vote count by the user of the second terminal and signed by the user of the fourth terminal. A vote management information recording process records vote management information, which associates vote record information encrypted based on the public key information and random number information with approval information indicating whether or not the user of the second terminal has approved the recording of the encrypted vote count information through the first terminal, in a distributed ledger that can communicate with the first terminal and the second terminal, such that the user of the second terminal can update the approval information and the approval information can be associated with information indicating that the approval by the user of the second terminal was authorized by the user of the fourth terminal; A vote verification information generation process generates vote verification information that includes the unencrypted at least one voting destination information and the signature, which verifiablely indicates that the vote management information was recorded by the user of the first terminal, and to which verification information based on the random number information is added; A program that performs a record check information recording process, which records the record check information in the distributed ledger.

12. The program according to claim 11, The user's voting destination information and the number of votes information are, respectively, the first voting destination information, the first number of votes information, and the first vote information. The voting information acquisition process further acquires second voting information from a fifth terminal that can communicate with the first terminal, which indicates at least one voting destination of the user of the fifth terminal. The vote count information acquisition process further acquires second vote count information indicating the number of votes cast by the user of the fifth terminal for at least one of the voting destinations, On the first terminal, A program that further executes a vote counting process, which calculates the number of votes received for each of the at least one voting destinations based on the first vote count information and the second vote count information.

13. The program according to claim 12, On the first terminal, A first proof information generation process generates first proof information that proves that the encrypted vote count information includes the encrypted vote count information, A vote count encryption process generates encrypted vote count information in which the number of votes is encrypted based on the number of votes received for each of the at least one voting destinations, A ranking information generation process that generates ranking information indicating the ranking of the vote counts based on the number of votes each of the at least one voting destinations, A second proof information generation process that generates second proof information to prove the aforementioned ranking information, Further, the system performs a ranking recording process that records the ranking information and the second proof information in the distributed ledger. The aforementioned form inspection information generation process is a program that generates the form inspection information to which the first certification information is further added.

Images