CN111277407B - Anti-quantum computing alliance chain voting system and method based on secret sharing - Google Patents

Anti-quantum computing alliance chain voting system and method based on secret sharing Download PDF

Info

Publication number
CN111277407B
CN111277407B CN202010041056.7A CN202010041056A CN111277407B CN 111277407 B CN111277407 B CN 111277407B CN 202010041056 A CN202010041056 A CN 202010041056A CN 111277407 B CN111277407 B CN 111277407B
Authority
CN
China
Prior art keywords
information
voter
voting
client
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010041056.7A
Other languages
Chinese (zh)
Other versions
CN111277407A (en
Inventor
富尧
钟一民
刘骄
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ruban Quantum Technology Co Ltd
Nanjing Ruban Quantum Technology Co Ltd
Original Assignee
Ruban Quantum Technology Co Ltd
Nanjing Ruban Quantum Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ruban Quantum Technology Co Ltd, Nanjing Ruban Quantum Technology Co Ltd filed Critical Ruban Quantum Technology Co Ltd
Priority to CN202010041056.7A priority Critical patent/CN111277407B/en
Publication of CN111277407A publication Critical patent/CN111277407A/en
Application granted granted Critical
Publication of CN111277407B publication Critical patent/CN111277407B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C13/00—Voting apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention discloses an anti-quantum computing alliance chain voting system and method based on secret sharing, wherein the system comprises alliance chain members, namely a block chain client and a server, the client comprises a vote counter and a voter, and the server comprises a plurality of Endorsers, orderer and Committer; the method comprises the communication between a client and a server, and the specific process comprises the steps of initiating a vote by a voter, anonymously taking a vote and voting by the voter, inquiring by the voter, publishing a voting result and anonymously inquiring the voting result by the voter. In the invention, the voter and the voter are all members of a alliance chain, a voting registration mechanism is cancelled, and the problem of counterfeit of the voting registration mechanism is solved.

Description

Anti-quantum computing alliance chain voting system and method based on secret sharing
Technical Field
The invention relates to the field of secret sharing, in particular to a quantum computing alliance chain resisting voting system and method based on secret sharing.
Background
The block chain is a brand new distributed infrastructure and computing paradigm, stores data by using an ordered chain data structure, updates data by using a consensus algorithm, and ensures data security by using a cryptography technology. In blockchain based transactions, ensuring data security for the transaction and privacy for the customer is a necessary condition for the blockchain to be able to develop further. For this reason, cryptography is widely used in block chaining. The alliance chain is a branch of the block chain, so the alliance chain is a distributed and decentralized public database, and the alliance chain is the block chain which is different from other chains in that the alliance chain is directed to members of a specific group and limited third parties, a plurality of preselected nodes are designated as bookkeeping persons inside the alliance chain, and the consensus process of the preselected nodes is controlled by the preselected nodes.
As most people know, quantum computers have great potential in password cracking. Most of the asymmetric encryption algorithms, such as RSA encryption algorithm, which are mainstream today are based on two mathematical problems, i.e. factorization of large integers or computation of discrete logarithms over finite fields. Their difficulty in breaking depends on the efficiency of solving these problems. On a traditional computer, the two mathematical problems are required to be solved, and the time is taken to be exponential (namely, the cracking time increases in exponential order along with the increase of the length of the public key), which is not acceptable in practical application. The xiuer algorithm tailored for quantum computers can perform integer factorization or discrete logarithm calculation within polynomial time (i.e. the cracking time increases at the speed of k power along with the increase of the length of a public key, wherein k is a constant irrelevant to the length of an ID), so that the possibility is provided for the cracking of RSA and discrete logarithm encryption algorithms.
In a patent of a voting system, a method and a voting terminal based on a block chain with publication number CN110162996A, by adopting an asymmetric encryption technology and a timestamp, the problem that false voting data is mixed in the system and the voting data is stolen is solved, and the uniqueness of voting equipment and the safety and the effectiveness of the voting data are ensured; by adopting a block chain technology and compiling an intelligent contract to process the voting data, the problem that the voting data are falsified in the data processing and counting stages is solved, a centralized system is removed, the bill processing is automatically executed by codes, the manual data touch is avoided, the transparency and the effectiveness of the data in the system are ensured, and the possibility of dark box operation is avoided; however, the identity of the user is directly checked and stored in the voting process, so that the problem of user identity leakage is easy to occur; in addition, a voting terminal module is provided for inputting voting data of voters and uploading the voting data in an encrypted manner, and the voting terminal has overlarge right and does not exclude the possibility of being forged.
As can be seen from the above description, some blockchain schemes exist today that improve the security of the voting system, but these problems still exist as follows:
1. in the prior art, the computation amount of signature and verification is large; for example, RSA signature is used for encryption to resist quantum computation, i.e., encryption signature = { MS } R | { R } SK, where MS, R, SK are respectively signature, symmetric key, RSA private key; the digital signature is protected in the form, and the calculated amount is 2 times of that of the original signature (RSA signature is 1 time and RSA encryption is 1 time); similarly, the amount of computation for decrypting and verifying the signature is 2 times that of the original verification signature; in the existing anti-quantum computing alliance chain system, the number of signatures is large, so the computation amount of the signatures and the verification is large;
2. the same identity appears in the alliance chain for many times, an enemy can track the identity, and the problem of user identity leakage can occur;
3. the existing voting mode has over-high authority of a voting registration mechanism, and has the capacity of making false votes and interfering the authenticity and fairness of voting.
Disclosure of Invention
The purpose of the invention is as follows: the invention discloses an anti-quantum computing alliance chain voting system and method based on secret sharing, aiming at the problems that the voter identity leakage may be caused by the fact that the voter identity is fake after a voting registration mechanism is introduced, the voting authenticity and fairness are interfered, and the same identity appears in an alliance chain for multiple times, and the computation amount of signature and verification in an anti-quantum computing alliance chain system is large.
The technical scheme is as follows: the invention discloses a quantum computation resistant alliance chain voting system and method based on secret sharing, wherein the system comprises alliance chain members, and the alliance chain members comprise a block chain client and a block chain server; the block chain client comprises a voter and a voter, the block chain server comprises Peer and Order, the Peer comprises Committer and Endorer, and the Order comprises a plurality of Order devices;
the IDU of the voter obtains a secret component I and a secret component II through secret sharing (2, 2), wherein the secret component I comprises a secret component random number I and the IDU component I, and the secret component II comprises a secret component random number II and the IDU component II;
each client is provided with a unique client key card, a public key area and a private key are arranged in the ticket counter key card, a public key area and a private key area are arranged in the voter key card, and the public key areas of the ticket counter and the voter store a plurality of groups of identity and public key information, including the identity and public key information of each block chain server, the identity and public key information of the ticket counter, and the identity and public key information of the voter; the private key in the voter key fob stores a self private key, and a private key area in the voter key fob stores self false identity information, a secret component I and the private key;
the Endorser, orderer and Committer are all provided with a unique server key fob, and a public part shared by the block chain server, a private part stored by the server and additional functions are arranged in the server key fob; the public part comprises a public information pool, a block chain server public key pool and a voter public key pool, wherein the public information pool stores false identity information, a secret component random number I, a secret component random number II and voter public keys of voters, the block chain server public key pool stores identity and public key information of each server, and the voter public key pool stores identity and public key information of voters; the private part stores the private keys of the block chain servers, and the additional function stores the real identity information of the client and the change history of the false identity information of the voters;
in the voting activity of the system, a voter generates voting identity information IDVOTE and an identity information list of the voter corresponding to the voting identity information, and sends the voting identity information to a service end, wherein the identity information of the voter comprises a voting marker bit, and the voting information cast by the voter is contained in the voting list; when the block chain client side and the server side communicate with each other, a sender adds a corresponding secret value to content to be sent and then carries out digital signature, and sent information comprises the content and the digital signature of the sender.
A method for a quantum computing alliance chain voting resisting system based on secret sharing comprises the following steps of communication between a block chain client and a server Endorer, wherein the communication comprises the following steps:
step A1, a client proposes a transaction to an Endorser: the transaction comprises transaction information and a client signature, the transaction information comprises client identity information, the serial number (namely a chain code) of an intelligent contract function, transaction parameters and a timestamp, and the client signature is used for digitally signing the transaction information and a corresponding secret value by a private key of the client;
step A2, the Endorser executes the transaction: the Endorser receives the transaction, finds out a public key corresponding to the client in the public part of the key fob of the server according to the identity information of the client to verify the digital signature, judges whether the client has the right to propose the transaction and whether the difference between the acquired timestamp and the local time is within a reasonable range, and the Endorser approves the transaction after all the judgments are passed;
step A3, the Endorser sends a transaction response to the client: the transaction response comprises response information and an Endorser signature, wherein the response information comprises Endorser identity information, a transaction hash value, the number (chain code) of an intelligent contract function, transaction parameters, read information and write information, and the Endorser signature is that the Endorser digitally signs the response information and a corresponding secret value by using a self private key;
step A4, the client receives the transaction result: the client receives the transaction response, screens out the transaction approved by the Endorser, and verifies the digital signature by using an Endorser public key stored in a client key fob public key area; and after the verification is passed, judging whether the transaction response meets the requirement of the endorsement strategy, if so, obtaining effective response information, and obtaining read information and write information by the client.
Preferably, the communication between the blockchain client and the server Endorser exists in the process of anonymous ticket fetching by a voter, the client identity information in the step A1 is false identity information of the voter, the transaction parameters include an IDU component one and an instruction for anonymous ticket fetching, and the secret value corresponding to the transaction information in the digital signature is a secret component random number one and a timestamp to calculate two hash values; in the step A3, the read information is voting identity information and votes, and the value of the written information is null.
Preferably, the communication between the blockchain client and the server Endorser exists in the process of inquiring the voting result by the voter, the client identity information in the step A1 is the identity information of the voter, the transaction parameter is the voting identity information, and the secret value corresponding to the transaction information in the digital signature is the hash value of the public key set of all voters in the voting list; in the step A3, the read information is a voting list, and the value of the written information is null.
Preferably, the communication between the blockchain client and the server Endorser exists in the process of anonymously inquiring the voting result by the voter, the client identity information in the step A1 is false identity information of the voter, the transaction parameter comprises an IDU component one and an instruction for anonymously inquiring the voting result, and the secret value corresponding to the transaction information in the digital signature is a secret component random number one and a timestamp to calculate two hash values; in the step A3, the read information is voting identity information, a voting list and a voting result, and the value of the written information is null.
Preferably, the method further comprises the communication between the blockchain client and the service end order and commit, the communication comprises the communication process between the blockchain client and the service end Endorser, and the method further comprises the following steps:
step B1: the client sends the endorsement to the order: the client combines the effective response information sets into an endorsement and sends the endorsement to an Orderer;
and step B2: order sends the ordered endorsement set to commit: the Order collects endorsements sent by a plurality of clients and sequences the endorsements, after the maximum value of the blocks is reached or exceeds the maximum value of time, the Order combines the endorsements, and the Order sends an endorsement set to the Committer, wherein the endorsement set comprises an endorsement serial number, a hash value of a last alliance chain block and a plurality of combined endorsements;
step B3, committer verifies the endorsement set and updates the world state, namely updates the local key pool information: the Committee takes out valid transaction responses in all endorsements, finds out a public key verification digital signature corresponding to the Endorser in a block chain service public key pool of a service end key fob, calculates and verifies read information, checks whether the verified transaction responses meet requirements of endorsement strategies, makes valid or invalid marks for corresponding endorsements according to verification results, and updates the local world state by the Committee, and also comprises a Committee update voting state database, namely the Committee adds write-in information in the transaction responses in all the valid endorsements into the local world state;
and B4, sending an endorsement notification to the client by the Committer: after the Committer operations are completed, generating an endorsement notification to be sent to the client, wherein the endorsement notification comprises a transaction hash value, a transaction result and a Committer signature, and the Committer signature is a digital signature of the Committer on the transaction result and a corresponding secret value by using a private key of the Committer;
step B5, the client receives the endorsement notification: the client side verifies the digital signature through a Committer public key stored in a client key fob public key area; and the client acquires the transaction result after the verification is passed.
Preferably, the communication between the blockchain client and the service commander exists in a process of initiating a vote by a voter, the client identity information in step A1 is identity information of the voter, the transaction parameters are vote identity information, an identity information list of the voter and a voting list, the secret value corresponding to the transaction information in the digital signature is a hash value of a public key set of all voters in the voting list, the read information in step A3 is a hash value of the public key set of the voter and the identity information of the voter, and the value of the write-in information is the vote identity information, the voter identity information and a vote flag bit.
Preferably, the communication between the blockchain client and the service end Committer exists in the process of anonymous voting by the voter, the step A1 further includes a process of judging whether the current timestamp meets the requirement of replacing the false identity information in the key fob of the voter, the client identity information in the step A1 is the false identity information of the voter, the transaction parameters include an IDU component one, an instruction of anonymous voting and a vote set, contents in the votes in the vote set are encrypted by a public key of the voter, secret values corresponding to the transaction information in the digital signature are the updated secret component random number one and the updated secret component random number two, the read information in the step A3 is the false identity information of the voter, the hash values of the secret component random number one and the secret component two, the write information is the IDU component one and the valid vote set, the Committer updates the local key pool information in the step B3 and includes the false identity information of the voter, the secret component random number one and the secret component two in the updated local public information pool, the Committer updates the false identity information in the local public information pool, the secret component random number one and the secret component random number two, the secret component number one and the secret component of the voter is stored in the updated local public information pool, the updated local public pool, and the secret key card in the step B5 is updated, and the false identity information of the voter is updated, and the secret component of the false identity information of the voter is updated.
Preferably, the method for judging whether the current timestamp meets the requirement of replacing the false identity information in the key fob of the voter, which is included in the step A1, includes: acquiring a current timestamp, reading a secret component random number I from a key fob of a voter, calculating to obtain two hash values according to the secret component random number I and the current timestamp, taking the two hash values as a new secret component random number, comparing the secret component random number I with the two hash values, if any two hash values are equal, judging that the current timestamp does not meet the condition of replacing the false identity information, and acquiring the timestamp again and calculating the two hash values until the condition of replacing the false identity information is met.
Preferably, the communication between the blockchain client and the server commatter exists in a process in which a vote counter publishes a voting result, and after the vote counter queries the voting result, the valid votes in the voting list are decrypted by using a private key of the vote counter to obtain voting content, in the step A1, the client identity information is identity information of the vote counter, the transaction parameters include voting identity information and the voting result, the secret value corresponding to the transaction information in the digital signature is a hash value of a public key set of all voters in the voting list, in the step A3, the read information is a hash value of the public key set of all voters and the identity information of the vote counter, and the write information is the voting identity information and the voting result.
Has the advantages that:
the invention ensures that the signature object cannot be known by the enemy through the form of adding the secret value to the signature object, solves the problem that the calculated amount of signature and verification signature in the prior art is twice of that of the original signature and verification signature, and does not increase the calculated amount. After each voting is finished, the false identity of the voting user is randomly updated, namely the same identity cannot appear in the alliance chain for many times and cannot be tracked by an enemy. In the invention, all users are members of the alliance chain, and no special voting registration mechanism exists, so that the problem of counterfeit voting mechanism is basically solved.
Drawings
FIG. 1 is a block diagram of a system according to an embodiment of the present invention;
fig. 2 is an internal structural diagram of a blockchain service key fob according to the present invention;
FIG. 3 is an internal structural view of a V-key fob of the present invention;
fig. 4 is an internal structural view of a U-key fob according to the present invention.
Detailed Description
The architecture of the system of the present invention is shown in fig. 1, where a federation chain is composed of a blockchain service and blockchain clients, and a dedicated key fob issuing server issues key fobs to members of the blockchain, each of which is equipped with a key fob.
In the invention, all the voter IDUs are stored in a secret sharing mode.
After (2, 2) secret sharing is performed on the IDU, secret components (x 1, IDU 1) and (x 2, IDU 2) are obtained. According to the formula f (x) = IDU + RAND x, RAND is a random number (different IDU and RAND), IDU1= IDU + RAND x1, IDU2= IDU + RAND x2 can be obtained. The IDU can be recovered by the user collecting the group 2 secrets, and the specific recovery steps are as follows: lagrangian parameters were derived from 2 sets of secrets: λ 1= (-x 2)/(x 1-x 2), λ 2= (-x 1)/(x 2-x 1) to obtain IDU = λ 1 × IDU1+ λ 2 × IDU2= (x 1 × IDU2-x2 × IDU 1)/(x 1-x 2); RAND = (IDU 2-IDU 1)/(x 2-x 1).
The asymmetric algorithm used in the invention is RSA algorithm. Let the asymmetric key pair of the RSA algorithm be E/D, both of which can be used as public keys, and the remaining one as private key. That is, the public key/private key can be set as E/D, and the public key/private key can also be set as D/E.
There are 3 key fobs in the present invention, wherein the key fobs of the blockchain client are divided into two types, i.e. U (voter) key fobs and V (voter) key fobs, as shown in fig. 3 and 4. The blockchain server has a key fob that serves the blockchain as a blockchain key fob. The U-key card is divided into a public key zone and a private key zone. The public key area stores a list of a plurality of groups of identity public key information, and the identity public key information of each group comprises: ID PK (PK is a public key; ID PK is expressed as the concatenation of ID and PK, the same applies hereinafter). The multi-group identity public key information comprises: block chain service, tally, voter ID PK. The private key area stores a PIDU | (x 1, IDU 1) | | SKU, where the PIDU is a false identity and is obtained by performing HASH operation on IDU | | IDU1| | IDU2, and the expression is PIDU = HASH (IDU | | IDU1| | IDU 2). (x 1, IDU 1) is a secret component obtained after secret sharing is carried out by (2, 2) by the voter IDU, and SKU is a private key; the V key fob is divided into a public key area and a private key, the contents of the public key area of the V key fob and the contents of the public key area of the U key fob are the same, and the private key of the V key fob is marked as SKV; as shown in fig. 2, the blockchain service key fob is divided into a public portion, a private portion, and additional functionality. The public part stores a public information pool, a block chain service public key pool and a ticket counter public key pool, and each group of public information comprises: the PIDU | | | x1| (x 2, IDU 2) | | PKU, where (x 2, IDU 2) is a secret component obtained after the voter IDU performs (2, 2) secret sharing. The ID and the public key of each member of the block chain service end are stored in the public key pool of the block chain service: a plurality of groups of IDV | | | PKVs (the ticket counter ID and the ticket counter PK) are stored in the ticket counter public key pool. The private part stores its own private key. The additional function is to record the actual IDU of each blockchain client key fob and the history of the change of the PIDU of the actual IDU, including recording the block number and transaction number of the change of the PIDU, which facilitates tracing by a blockchain supervisory authority. The history is stored in the blockchain server key fob or encrypted by the blockchain server key fob and stored outside of the blockchain server key fob.
Federation chain members also include respective blockchain services, each service having 1 ID. The block chain service includes a Peer service, an Order service, and the like. Wherein the Peer service is divided into Committer and Endorser; the Order service consists of a number of orderers. All the members of the blockchain service end have Committer function and store blockchain data, the Endorser also stores an intelligent contract, the intelligent contract runs in the key fob, and the world status WorldState is stored in the key fob.
The following labels for User Client, endosser, orderer, committer are given as follows:
(1) Are referred to as U, E, O, C respectively
(2) ID is IDU, IDE, IDO, IDC
(3) The public keys are PKU, PKE, PKO and PKC respectively
(4) Private keys are SKU, SKE, SKO, SKC respectively
Stage 1: the voter initiating the vote
Step 1: client proposes transaction
V (voter) specifies that the ID of the voting campaign is IDVOTE and the list of legal IDs (voter's IDs) corresponding to IDVOTE is IDVOTE _ IDs. IDVOTE carries IDV information.
The ticket counter V takes the random number VR and, in the case of ensuring that TN (ticket number) does not exist in the current ticket list IDVOTE _ TICKETS of IDVOTEs, obtains the ticket number TN = IDVOTE | | | VR, and replaces VR if TN already exists. TC is the vote content, i.e. the content supported or opposed, initially empty, vote TICKET = TN | | TC. V generates a sufficient number of TICKETs to put into idvolte _ TICKETs. V proposes a transaction tx, which consists of propofol and clientSig, i.e. may be denoted as tx = { propofol, clientSig }. Wherein propofol includes IDV, chain code chaincoded id (i.e. using the number of the intelligent contract function), txPayload (i.e. the parameter of the function), and timestamp, where txPayload has the value IDVOTE | | IDVOTE _ IDS | | | IDVOTE _ TICKETS, so that propofol = { IDV, chaincoded id, txPayload = IDVOTE | | | IDVOTE _ IDS | | IDVOTE _ TICKETS, timestamp }. If the data volume of IDVOTE _ IDS or IDVOTE _ TICKETS is huge and is not suitable for being placed into the block chain, the IDVOTE _ IDS or IDVOTE _ TICKETS is placed into the block chain as a data link, and actual data is stored in IPFS or cloud storage. The IDVOTE is processedThe set of PKs for all IDs in an IDS is denoted as Σ IDVOTE_IDS PK, using function H1 to match IDVOTE_IDS HASH calculation is carried out on PK to obtain VK IDVOTE_IDS ＝H1(∑ IDVOTE_IDS PK). Wherein let clientSig be V vs propofol VK IDVOTE_IDS The signature of (1), the calculation formula of the signature is clientSig = SIGN (propofol VK) IDVOTE_IDS SKV). SIGN (m, k) indicates that an RSA signature is obtained with m as a message and k as a key.
tx＝{{IDV，chaincodeID，IDVOTE||IDVOTE_IDS||IDVOTE_TICKETS，timestamp}，
SIGN(proposal||VK IDVOTE_IDS SKV). Because the signature object propofol VK IDVOTE_IDS In which there is a secret value VKI that cannot be known by an adversary DVOTE_IDS Therefore, an enemy cannot crack the private key of the signature through the signature, so that the signature has the effect of resisting quantum computation, and the computation amount of the signature is consistent with that of the common RSA signature. V sends tx to Endorser.
Step 2: endorser performs transactions
And the Endorser takes out the IDV in the proxy after receiving the transaction, finds out the PKV corresponding to the local storage, and verifies the clientSig by using the PKV, wherein the verification method comprises the following steps:
obtaining VK from local key fob according to the method described above IDVOTE_IDS And combined to be a signature object, namely proposal VK IDVOTE_IDS And RSA signature verification is performed.
After the signature is verified, the Endorser judges whether the IDV has the authority of initiating the voting, and then judges whether the difference between the timestamp and the local time is within a reasonable range. If all the determinations are passed, the Endorser approves the transaction tx, otherwise the Endorser does not approve the transaction.
And 3, step 3: endorser initiates a transaction response
The Endorser initiates a transaction response rtx consisting of a tran-propesal and a signature epSig. tran-propofol = { IDE, tid, chaincodeID, txPayload, readset, writeset }. Wherein tid is obtained by performing HASH operation on tx by the Endorser; acquire multiple PKs in IDV and IDVOTE _ IDS, not approve the transaction if either acquisition fails, e.g.If all variables are successfully obtained, then readset = HASH (IDV | | Σ) IDVOTE_IDS PK). The Endorser records a FLAG idVOTE ID FLAG indicating whether each ID has already been voted for IDVOTE _ IDS, and the initial state is not voted (0). The value of IDVOTE _ IDS | | Σ IDVOTE _ ID _ FLAG is assigned to writeset. The value of readset/writeset is invalid if Endorser does not approve the transaction tx. epSig is Endorser vs tran-propofol VK IDVOTE_IDS Signature of (3), signature epSig = SIGN (tran-propofol | | VK) IDVOTE_IDS SKE). Due to the signed object tran-propofol | | | VK IDVOTE_IDS And the enemy cannot know the private signature key through the signature. The Endorser gets the transaction response rtx = { tran-propassal, epSig }, and sends rtx to V.
And 4, step 4: client sends an Endorsement (Endorment) etx to Orderer
And after the V receives the transaction response, screening out the transaction approved by the Endorser, finding out the PKE corresponding to the IDE in the tran-prophase, and verifying the signature epSig by using the public key PKE.
And V, after receiving a plurality of transaction responses and respectively verifying the transaction responses, checking whether the rtx passing the verification meets the requirement of the endorsement strategy, forming an rtx set obtained by verification selection into a set etx, namely an endorsement, and sending the set etx to an Orderer.
And 5: order sends the ordered etx set to Committer
Order summarizes the etx submitted by each user for sorting. After reaching the maximum size of the block or reaching the timeout time, orderer packs a plurality of etxs into blocks, i.e., an endorsement set etxs, which includes the sequence number seqno and the hash value prevhash of the last block of the coalition chain. The endorsement set etxs is denoted as etxs = { seqno, prevhash, Σ etx }. Orderer sends etxs to Committer.
Step 6: committer verifies transactions and updates world status
Committer looks at each rtx of all etxs and verifies its digital signature with PKE. Then, HASH (IDV | | | Sigma) is calculated IDVOTE_IDS PK) to see if it is equal to the readset value, and is verified. After passing the verification, checking the passing verificationWhether certificate rtx meets the requirements of the endorsement policy. And if the requirement is met, after the verification is passed, the Committer approves the etx as a valid endorsement and marks the valid endorsement, otherwise, the Committer does not approve the etx as a valid endorsement and marks the valid endorsement as an invalid endorsement. And then Committer writes the block into the block chain and updates the local world state according to the effective endorsement in the block chain. That is, newly adding the writeset values contained in all rtxs in each etx, wherein the writeset values in the transaction flow are as follows: IDVOTE | | IDVOTE _ IDS | | Σ IDVOTE _ ID _ FLAG.
And 7: committer sending transaction notification
After completion of execution of the Committer(s), a notification of the transaction results (success or failure) is sent to V. Committer generates a transaction notification ntx including tid, result (i.e., success or failure) and a signature Committer Sig. Committerstig, committer, uses the private key SKC to solve VK IDVOTE_IDS The signature of (2) can be expressed as SIGN (result | | | VK) IDVOTE_IDS ，SKC)。
V uses IDC to find PKC after receiving notice, uses PKC to SIGN SIGN (result | | VK) IDVOTE_IDS SKC), and if result = success, the transaction is completed.
And (2) stage: voting phase
2.1 anonymous voting by voters
Step 1: client proposes transaction
The voting user U proposes a transaction tx, which consists of propofol and clientSig, and can be expressed as tx = { propofol, clientSig }. propofol = { PIDU, chaincodeID, txPayload = IDU1| | MSG, timetag }, where MSG contains instructions to anonymously fetch a ticket. Let x0= timeframe, and calculate x1'= HASH (x 1| | x 0), x2' = HASH (x 0| | x 1). And splicing x1', x2' and propofol to obtain propofol | | | x1'| | x2', wherein clientSig is a signature of U on propofol | | | x1'| | x2', and a signature clientSig = SIGN (propofol | | | x1'| | x2', SKU). Since the signed object (propofol | | | x1'| | x 2') cannot be known by the enemy, the enemy cannot crack the private signature key through the signature.
U sends tx to Endorser.
Step 2: endorser performs transactions
And the Endorser searches PIDU items in the local public information list according to the PIDUs, and if the PIDUs cannot be found, the transaction verification fails. After finding the PIDU, corresponding PKUs, x1, and (x 2, IDU 2) can be obtained from the PIDU in the public portion of the blockchain service key fob, (x 1, IDU 1), (x 2, IDU 2) can be obtained from IDU1 in the propofol, and f (x) = IDU + RAND x, i.e., IDU and RAND of U are recovered according to the method described above. Let x0= timeframe, and calculate x1'= HASH (x 1| | x 0), x2' = HASH (x 0| | x 1). The clientSig is then verified using PKU. After the verification is passed, the Endorser judges whether the IDU of the voter U has the authority of anonymous ticket taking, and then judges whether the difference between the timestamp and the local time is within a reasonable range. If all the judgments are passed, the transaction is approved; if the determination fails, the transaction is not approved. In addition, the IDU is not stored in the blockchain server key fob, and therefore cannot be obtained by power-down disassembly of the IDU alone.
And step 3: endorser initiates a transaction response
And (3) carrying out Hash operation on tx by the Endorser to obtain tid, wherein the tran-propofol comprises { IDE, tid, chaincodeID, txPayload, readset and writeset }. And searching by the Endorser by using the IDU to obtain a plurality of ongoing voting campaigns related to the IDU, checking whether the IDU votes or not according to the IDVOTE _ ID _ FLAG for each voting campaign, wherein if the IDU votes, the voting cannot be taken, and then randomly acquiring 1 non-voted TICKET from the voting campaigns. the readset value in tran-proposal is the set of all IDVOTE | | | TICKETs related to IDU, i.e. sigma (IDVOTE | | TICKET), and the writeset value is null. If Endorser does not approve the transaction, then readset and writeset are invalid values.
And splicing x1', x2' and tran-propofol to obtain tran-propofol | | | x1'| | x2', wherein epSig is the signature of Endorser on tran-propofol | | x1'| | x2', and the signature epSig = SIGN (tran-propofol | | x1'| | x2', SKE) is obtained. Since the signed object (tran-proposall | | | x1'| | | x 2') cannot be known by the adversary, the adversary cannot crack the private signature key through the signature. The Endorser gets the transaction response rtx = { tran-proporal, epSig }, and sends rtx to U.
And 4, step 4: client receives the result
And after receiving the rtx, the U screens the transactions approved by the Endorser, finds the corresponding PKE according to the IDE in the tran-propofol, and verifies the digital signature epSig by using the PKE. After the signature verification passes, whether the rtx passing the verification meets the requirements of the endorsement policy or not is checked. If all the verifications pass, the result Σ (IDVOTE | | | TICKET) is determined to be correct, i.e., U acquires all votes about the IDU.
2.2 voter anonymous voting
Step 1: client proposes transaction
The voting user U proposes a transaction tx, which consists of propofol and clientSig, and can be represented as tx = { propofol, clientSig }. MSG contains anonymous voting instructions, then the propofol can be expressed as:
propofol = { PIDU, chaincodeID, txPayload = IDU1| | MSG | | Σ TICKET, timesmamp }. At this time, x0= timeframe, and x1'= HASH (x 1| | x 0), x2' = HASH (x 0| | x 1) may be calculated. And comparing the x1, the x1 'and the x2', and if any two of the x1, the x1 'and the x2' are equal, the current timestamp does not meet the condition of replacing the PIDU. At the moment, the timestamp needs to be replaced, and whether the timestamp meets the condition of replacing the PIDU or not is checked until the timestamp meets the condition of replacing the PIDU; and the user U finds the PKV according to the IDV information in the IDVOTE. Encrypting TC in the vote by using a public key PKV of a vote counter, wherein others cannot read the TC, and the TICKET is represented as TN | { TC } PKV; and splicing x1', x2' and propofol, wherein clientSig is a signature of U on propofol | | x1'| | x2', and obtaining a signature clientSig = SIGN (propofol | | x1'| | x2', SKU). Since the signed object (propofol | | | x1'| | x 2') cannot be known by the adversary, the adversary cannot crack the private signature key through the signature.
U sends tx to Endorser.
And 2, step: endorser performs transactions
And the Endorser searches the PIDU items in the local public information list according to the PIDU, and if the PIDU cannot be found, the transaction fails. After finding the PIDU, the corresponding PKU, x1, and (x 2, IDU 2) can be obtained in the public portion of the block chain service key card according to the PIDU, and (x 1, IDU 1), (x 2, IDU 2) is obtained by combining with IDU1 in the propofol. F (x) = IDU + RAND x is recovered according to the method described above, i.e. IDU and RAND of U are recovered. Let x0= timeframe, and calculate x1'= HASH (x 1| | x 0), x2' = HASH (x 0| | x 1). The clientSig is then verified with the PKU. After the verification is passed, the Endorser judges whether the IDU has the authority of anonymous voting, and the judging method is as follows:
firstly, finding IDVOTE by the Endorser according to TICKET, then finding IDVOTE _ IDS according to IDVOTE, checking whether IDU is positioned in IDVOTE _ IDS or not, and if not, failing authentication; then checking whether the IDU votes according to the IDVOTE _ ID _ FLAG, wherein if the IDU votes, the IDU cannot vote; and finally, judging whether the TN exists in the IDVOTE _ TICKETS and judging whether the TN is voted. And judging whether the difference between the timestamp and the local time is within a reasonable range. If all the judgments pass, the transaction is approved. If the determination fails, the transaction is not approved.
Furthermore, the IDU is not stored in the blockchain service key fob, so power-down disassembly of it alone cannot obtain the IDU.
And 3, step 3: endorser initiates a transaction response
tran-propofol = { IDE, tid, chaincodeID, txPayload, readset, writeset }, and Endorser performs hash operation on tx to obtain tid. The PIDUs, x1, and (x 2, IDU 2) are concatenated to obtain PIDUs | | x1| (x 2, IDU 2), and subjected to a HASH operation to obtain readset = HASH (PIDUs | | x1| (x 2, IDU 2)). The IDU1'= IDU + RAND × 1', IDU2'= IDU + RAND × 2' are calculated. The content written should be: the PIDU is updated to PIDU ', x1 is updated to x1', (x 2, IDU 2) is updated to (x 2', IDU 2'). But because these cannot be disclosed, the write is still IDU1 and TICKET, writeset = IDU1| | ∑ TICKET. If Endorser does not approve the transaction, readset/writeset is invalid. Splicing x1', x2' and tran-propofol to obtain tran-propofol | | | x1'| x2', wherein epSig is the signature of Endorser on tran-propofol | | x1'| x2', and obtaining the signature epSig = SIGN (tran-propofol | | x1'| | x2', SKE). Since the signed object (tran-proposall | | | x1'| | x 2') cannot be known by the adversary, the adversary cannot crack the private signature key through the signature. Endorser obtains the transaction response rtx = { tran-pro pass, epSig }, and sends rtx to U.
And 4, step 4: client sends an Endorsement (Endorment) etx to Orderer
And after the U receives the transaction response, screening out the transaction approved by the Endorser, finding out the PKE corresponding to the IDE in the tran-prophase, and verifying the signature epSig by using the public key PKE.
And after the U receives a plurality of transaction responses and respectively passes the verification, checking whether the rtx passing the verification meets the requirement of the endorsement strategy, combining the rtx passing the verification into a set etx, namely the endorsement, and sending the set etx to the Orderer.
And 5: order sends the ordered etx set to Committer
Order summarizes and sorts etx submitted by each user. After reaching the maximum size of the block or reaching the timeout time, orderer packs a plurality of etxs into blocks, i.e., an endorsement set etxs, which includes the sequence number seqno and the hash value prevhash of the last block of the coalition chain. The endorsement set etxs is denoted as etxs = { seqno, prevhash, Σ etx }. Orderer sends etxs to Committer.
Step 6: committer verifies transactions and updates world status
Committer looks at each rtx of all etxs and verifies its digital signature epSig with PKE. After the verification is passed, corresponding PKUs, x1, and (x 2, IDU 2) are found in the public part of the blockchain service key card according to the PIDU, and (x 1, IDU 1), (x 2, IDU 2) is obtained by combining with IDU1 in the propofol. F (x) = ID + RAND x, i.e. the voter's ID, i.e. IDU and RAND, are recovered according to the method described above. Then let x0= timeframe, calculate x1'= HASH (x 1| | x 0), x2' = HASH (x 0| | x 1). And reading the public information pool unit according to the PIDU, performing hash calculation on the read PID | x1| (x 2, IDU 2), checking whether the contents of the PID and the readset are the same, and if the contents of the PID and the readset are the same, passing the readset verification. After the verification is passed, whether the rtx passing the verification meets the requirements of the endorsement policy or not is checked. After the verification is passed, committer approves the etx as a valid endorsement and marks the valid endorsement, otherwise, committer does not approve the etx as a valid endorsement and marks the valid endorsement as an invalid endorsement.
And the Committer writes the verified blocks into the block chain, and then updates the local world state according to the valid endorsements in the block chain. From f (x) = IDU + RAND x, IDU1' can be calculated by x1', IDU2' can be calculated by x2', and PIDU ' = HASH (IDU | | IDU1' | | IDU2 ') can be calculated. The local world state is updated, and the vote status database is updated in addition to updating the local key pool. The process of updating the local key pool by Committer is as follows: updating each PIDU in the local key pool into a PIDU ', updating x1 into x1', (x 2, IDU 2) into (x 2', IDU 2'); updating the voting state database means writing Σ ticlet into the state database, and the process is as follows: finding IDVOTE according to the TICKET, assigning a new TICKET at the position of the original TICKET, wherein the TICKET comprises an effective TC, indicating that the TICKET is effective voting, assigning IDVOTE _ ID _ FLAG as voted, and then the IDU can not vote for the IDVOTE, thus updating the state database. And the local key pool and the state database are updated, namely the local world state update is completed.
And 7: committer sending transaction notification
After completion of execution of the Committer(s), a notification of the transaction results (success or failure) is sent to U. Committer generates a transaction notification ntx including tid, result (i.e., success or failure), IDU2', and signature commimitersSig. Committer sig is a signature of resultesult | | | IDU2'| | x1' | x2 'by the Committer using the private key SKC, and can be expressed as Committer sig = SIGN (result | | IDU2' | x1'| x2', SKC). After the U receives the notification, the user finds the PKC according to the IDC, verifies the signature commanterSig by using the PKC, and if result = failure, the transaction fails after the verification is passed. If result = succeeds, the recovery f (x) = IDU + RAND × x, i.e., the voter IDU and RAND can be calculated from (x 1, IDU 1) and (x 2', IDU 2'). And then calculating IDU1 'according to x 1'. Finally, U calculates PID ' = HASH (IDU | | | IDU1' | | IDU2 '). The fake identity PIDU in the own key fob is updated to PIDU ' and (x 1, IDU 1) is updated to (x 1', IDU1 '). And at this point, the transaction of replacing the false identity PIDU is completed, and the voter anonymously votes for the transaction to be completed.
Furthermore, the IDU is not stored in the blockchain client key fob, so power-down disassembly of it alone cannot obtain the IDU.
And (3) stage: ticket counting stage
When all votes have been voted, the alliance chain sends a notice to the voter to enter the voting stage. Or all votes are not voted completely, but the voting deadline is up, the alliance chain also sends a notice to the voter, and the voting stage is entered.
3.1 Ticket seller Inquiry results
Step 1: client proposes transaction
User V proposes a transaction tx, tx consisting of propofol and clientasig, i.e., tx = { propofol, clientasig }, where propofol includes IDV, the chain code chaincodecoid (i.e., the number of the function using the smart contract), txpad (i.e., the parameter of the function), and a timestamp, timetag, where txpad has a value IDVOTE, i.e., propofol = { IDV, chaincodecoid, txpad = IDVOTE, timetag }. clientSig is V vs proposal VK IDVOTE_IDS Signature of (2), resulting in signature clientSig = SIGN (propofol | | | VK) IDVOTE_IDS SKV). Because the signature object propofol VK IDVOTE_IDS And the private signature cannot be known by an enemy, so that the enemy cannot crack the private signature key through the signature.
V sends tx to Endorser.
Step 2: endorser performs transactions
And the Endorser finds the PKV stored locally according to the IDV and verifies the signature clientSig by using the PKV. After the signature verification is passed, the Endorser judges whether the V has the authority of the query result, and judges whether the difference between the timestamp and the local time is within a reasonable range. If all the determinations are passed, the Endorser approves the transaction tx, otherwise the Endorser does not approve the transaction.
And 3, step 3: endorser initiates a transaction response
The transaction response rtx consists of tran-propofol and the signature epSig. Carrying out Hash operation on tx by the Endorser to obtain tid, tran-propofol = { IDE, tid, chaincodeID, txPayload, readset, writeset }. Wherein the contents of readset is IDVOTE _ TICKETS, and the contents of writeset is empty. If Endorser does not approve the transaction tx, then the values of readset and writeset are invalid. epSig is EndorserSignature on tran-propofol, signature epSig = SIGN (tran-propofol | | VK) IDVOTE_IDS SKE). Due to the signed object tran-propofol | | | VK IDVOTE_IDS And the enemy cannot know the private signature key through the signature. Endorser gets the transaction response rtx = { tran-pro pass, epSig }, and sends rtx to V.
And 4, step 4: client receives the result
After receiving rtx, V screens the transactions approved by Endorser and verifies the digital signature epSig using PKE. After the signature verification is passed, whether the rtx passing the verification meets the requirements of the endorsement policy or not is checked. If all verifications pass, the result IDVOTE _ TICKETS is determined to be correct.
3.2 ticketing person publishes results
The TICKET counter V obtains a plurality of TICKETs according to IDVOTE _ TICKETS, and decrypts { TC } PKV to obtain TC by using SKV for each TICKET. Then, carrying out statistical calculation to obtain a statistical result IDVOTE _ RESULTS of the ticket counter.
Step 1: client proposes transaction
The voter V proposes a transaction tx, which consists of propofol and clientSig, that is, tx = { propofol, clientSig }, where propofol includes IDV, chain code chaincodeID (i.e., number using intelligent contract function), txPayload (i.e., parameter of function), and timestamp timetag, where txPayload has a value of idspace | | | idspace _ RESULTS. So propofol = { IDV, chaincodeID, txPayload = IDVOTE | | | IDVOTE _ RESULTS, timemap }. Signature clientSig = SIGN (propofol | | | VK) IDVOTE_IDS SKV), i.e., V vs propofol | | VK IDVOTE_IDS So tx can be expressed as tx = { { IDV, chaincodeID, IDVOTE | | IDVOTE _ RESULTS, timetag }, SIGN (proposal | | VK) IDVOTE_IDS SKV). Because the signature object propofol VK IDVOTE_IDS And the private signature cannot be known by an enemy, so that the enemy cannot crack the private signature key through the signature.
V sends tx to Endorser.
Step 2: endorser performs transactions
And the Endorser finds the PKV corresponding to the local storage according to the IDV and verifies the clientSig by using the PKV. If the verification is not passed, the flow ends. After the signature is verified, the Endorser judges whether the IDV has the authority of publishing the voting result, and then judges whether the difference between the timestamp and the local time is within a reasonable range. If all the determinations are passed, the Endorser approves the transaction tx, otherwise the Endorser does not approve the transaction.
And step 3: endorser initiates a transaction reply
The transaction response rtx consists of tran-propofol and the signature epSig. tran-propofol = { IDE, tid, chaincodeID, txPayload, readset, writeset }. Wherein tid is obtained by performing HASH operation on tx by Endorser, readset = HASH (IDV | | Σ) IDVOTE_IDS PK). And the Endorser marks IDVOTE as voted, and assigns IDVOTE I IDVOTE _ RESULTS to writeset. If Endorser does not approve the transaction tx, then the value of readset/writeset is invalid. epSig is Endorser vs tran-propofol VK IDVOTE_IDS Signature of (1), signature epSig = SIGN (tran-propofol | | | VK) IDVOTE_IDS SKE). Due to the signed object tran-propofol | | | VK IDVOTE_IDS And the enemy cannot know the private signature key through the signature. The Endorser gets the transaction response rtx = { tran-propassal, epSig }, and sends rtx to V.
And 4, step 4: client sends Endorsement (Endorment) etx to Orderer
And after the V receives the transaction response, screening out the transaction approved by the Endorser, finding out the PKE corresponding to the IDE in the tran-prophase, and verifying the signature epSig by using the public key PKE.
And V, after receiving a plurality of transaction responses and respectively verifying the transaction responses, checking whether the rtx passing the verification meets the requirement of the endorsement strategy, forming an rtx set obtained by verification selection into a set etx, namely an endorsement, and sending the set etx, namely the endorsement, to Orderer.
And 5: order sends the ordered etx set to Committer
Order summarizes the etx submitted by each user for sorting. After reaching the maximum size of the block or reaching the timeout time, orderer packs a plurality of etxs into blocks, i.e., an endorsement set etxs, which includes the sequence number seqno and the hash value prevhash of the last block of the coalition chain. The set of endorsements etxs is denoted as etxs = { seqno, prevhash, Σ etx }. Orderer sends etxs to Committer.
Step 6: committer verifies transactions and updates world status
Committer looks at each rtx of all etxs and verifies its digital signature with PKE. Then, HASH (IDV | | | Sigma) is calculated IDVOTE_IDS PK) to see if it is equal to the readset value, and is verified. After the verification is passed, whether the rtx passing the verification meets the requirements of the endorsement policy or not is checked. And if the requirement is met, after the verification is passed, the Committer approves the etx as a valid endorsement and marks the valid endorsement, otherwise, the Committer does not approve the etx as a valid endorsement and marks the valid endorsement as an invalid endorsement. And then Committer writes the block into the block chain and updates the local world state according to the effective endorsement in the block chain. Namely, newly adding the writeset values contained in all rtxs in each etx, wherein the writeset values in the transaction flow are as follows: IDVOTE | | IDVOTE _ RESULTS. I.e. to store the tally statistics and indicate that the vote of IDVOTE has ended.
And 7: committer sending transaction notification
After completion of the execution of the Committer's, a notification of the transaction results (success or failure) is sent to V. Committer generates a transaction notification ntx including tid, result (i.e., success or failure) and a signature Committer Sig. Committerstig, committer, uses the private key SKC to solve VK IDVOTE The signature of (2) can be expressed as SIGN (result | | | VK) IDVOTE SKC). V uses IDC to find PKC after receiving notice, uses PKC to SIGN SIGN (result | | VK) IDVOTE SKC), and if result = success, the transaction is completed.
3.3 voter anonymous query results
Step 1: client proposes transaction
The voting user U proposes a transaction tx, which consists of propofol and clientSig, and can be expressed as tx = { propofol, clientSig }. propofol = { PIDU, chaincodeID, txPayload = IDU1| | MSG, timetag }, where MSG contains instructions for anonymous query results. Let x0= timemap, and calculate x1'= HASH (x 1| | x 0), x2' = HASH (x 0| | x 1). Splicing x1', x2' with propofol, clientSig is the signature of U on propofol | | | x1'| x2', resulting in signature clientSig = SIGN (propofol | | x1'| x2', SKU). Since the signed object (propofol | | | x1'| | x 2') cannot be known by the adversary, the adversary cannot crack the private signature key through the signature.
U sends tx to Endorser.
And 2, step: endorser performs transactions
And the Endorser searches PIDU items in the local public information list according to the PIDUs, and if the PIDUs cannot be found, the transaction verification fails. After finding the PIDU, corresponding PKUs, x1 and (x 2, IDU 2) can be obtained from the PIDU in the public portion of the block chain service key fob, and (x 1, IDU 1), (x 2, IDU 2) can be obtained by combining with IDU1 in the propofol. F (x) = IDU + RAND x is recovered according to the method described above, i.e. IDU and RAND of U are recovered. Let x0= timemap, and calculate x1' = HASH (x 1' | x 0), x2' = HASH (x 0| | xl). The clientSig is then verified using PKU. After the verification is passed, the Endorser judges whether the ID of the voter U, namely the IDU has the authority of anonymous query result, and then judges whether the difference between the timestamp and the local time is in a reasonable range. If all the judgments are passed, the transaction is approved; if the determination fails, the transaction is not approved. In addition, no ID is stored in the blockchain server key fob, so that power-down disassembly of the blockchain server key fob alone cannot acquire the ID.
And step 3: endorser initiates a transaction reply
And (3) carrying out Hash operation on tx by the Endorser to obtain tid, wherein the tran-propofol comprises { IDE, tid, chaincodeID, txPayload, readset and writeset }. And searching by the Endorser by using the IDU to obtain a plurality of voting campaigns related to the IDU, and inquiring results anonymously if the voting is finished for each voting campaign according to the IDVOTE, otherwise. And the Endorser splices IDVOTE, IDVOTE _ TICKETS and IDVOTE _ RESULTS of all voting activities capable of anonymously inquiring the result. Thus obtaining IDVOTE | | | IDVOTE _ TICKETS | | | | IDVOTE _ RESULTS. the readset value in tran-proposal is the set of all IDVOTE | | | IDVOTE _ TICKETS | | | IDVOTE RESULTS, i.e. sigma (IDVOTE | | IDVOTE _ TICKETS | | | IDVOTE _ RESULTS), and the writeset value is null. If Endorser does not approve the transaction, readset and writeset are invalid values. And splicing x1', x2' and tran-propofol to obtain tran-propofol | | | x1'| | x2', wherein epSig is the signature of Endorser on tran-propofol | | x1'| | x2', and the signature epSig = SIGN (tran-propofol | | x1'| | x2', SKE) is obtained. Since the signed object (tran-proposall | | | x1'| | | x 2') cannot be known by the adversary, the adversary cannot crack the private signature key through the signature. Endorser sends transaction response rtx = { tran-pro passal, epSig } to U.
And 4, step 4: client receives the result
After receiving rtx, U screens the transactions approved by Endorser and verifies the digital signature epSig using PKE. After the signature verification is passed, whether the rtx passing the verification meets the requirements of the endorsement policy or not is checked. If all the verifications pass, the result Σ (idvotate _ ticks | idvolte _ RESULTS) is determined to be correct. Then, for each IDVOTE, U checks whether the vote of U is in IDVOTE _ TICKETS, and if the vote is not in IDVOTE _ TICKETS, the U reports the failure of counting the vote to the voting organization. And the voting organization mechanism executes an offline auditing process, and a professional audits the result to find a voting counterfeiter and punish the result. If the vote is in IDVOTE _ TICKETS, determining that IDVOTE _ RESULTS is a correct counting result of the vote, and anonymously querying the result successfully.
The above description is only of the preferred embodiments of the present invention, and it should be noted that: it will be apparent to those skilled in the art that various modifications and adaptations can be made without departing from the principles of the invention, and such modifications and adaptations are intended to be within the scope of the invention.

Claims (10)

1. A quantum computing resistant league chain voting system based on secret sharing comprises league chain members, and is characterized in that: the alliance chain member comprises a block chain client and a block chain server; the block chain client comprises a vote counter and a voter, the block chain server comprises a Peer and an Order, the Peer comprises a Committer and an Endorser, and the Order comprises a plurality of Order;
the identity information IDU of the voter obtains a secret component I and a secret component II through secret sharing (2, 2), wherein the secret component I comprises a secret component random number I and an IDU component I, and the secret component II comprises a secret component random number II and an IDU component II;
each client is provided with a unique client key card, a public key area and a private key are arranged in the ticket counter key card, a public key area and a private key area are arranged in the voter key card, and the public key areas of the ticket counter and the voter store a plurality of groups of identity and public key information, including the identity and public key information of each block chain server, the identity and public key information of the ticket counter, and the identity and public key information of the voter; the private key in the voter key fob stores a private key of the voter key fob, and a private key area in the voter key fob stores false identity information of the voter key fob, a secret component I and the private key;
the Endorser, orderer and Committer are all provided with a unique server key fob, and a public part shared by the blockchain server, a private part stored by the server and additional functions are arranged in the server key fob; the public part comprises a public information pool, a block chain server public key pool and a voter public key pool, wherein the public information pool stores false identity information, a secret component random number I, a secret component random number II and voter public keys of voters, the block chain server public key pool stores identity and public key information of each server, and the voter public key pool stores identity and public key information of voters; the private part stores the private keys of the block chain servers, and the additional function stores the real identity information of the client and the change history of the false identity information of the voters;
in the voting activity of the system, a voter generates voting identity information IDVOTE and an identity information list of the voter corresponding to the voting identity information, and sends the voting identity information and the identity information list to a server, wherein the identity information of the voter comprises a voting marker bit, and the vote information cast by the voter is contained in the voting list; when the communication is carried out between the block chain client and the server, the sender carries out digital signature after adding a corresponding secret value to the content to be sent, and the sent message comprises the content and the digital signature of the sender.
2. The method for the quantum computing alliance link voting resisting system based on secret sharing is characterized in that communication is conducted between the blockchain client and the server-side Endorser, and the communication comprises the following steps:
step A1, a client proposes a transaction to an Endorser: the transaction comprises transaction information and a client signature, the transaction information comprises client identity information, the serial number (namely a chain code) of an intelligent contract function, transaction parameters and a timestamp, and the client signature is used for digitally signing the transaction information and a corresponding secret value by a private key of the client;
step A2, the Endorser executes the transaction: the Endorser receives the transaction, finds out a public key corresponding to the client in the public part of the key fob of the server according to the identity information of the client to verify the digital signature, judges whether the client has the right to propose the transaction and whether the difference between the acquired timestamp and the local time is within a reasonable range, and the Endorser approves the transaction after all the judgments are passed;
step A3, the Endorser sends a transaction response to the client: the transaction response comprises response information and an Endorser signature, wherein the response information comprises Endorser identity information, a transaction hash value, the number, namely chain code, of an intelligent contract function, transaction parameters, reading information and writing information, and the Endorser signature is that the Endorser digitally signs the response information and a corresponding secret value by using a self private key;
step A4, the client receives the transaction result: the client receives the transaction response, screens out the transaction approved by the Endorser, and verifies the digital signature by using an Endorser public key stored in a client key fob public key area; and after the verification is passed, judging whether the transaction response meets the requirement of the endorsement strategy, if so, obtaining effective response information, and obtaining read information and write information by the client.
3. The secret sharing-based method for voting in the quantum computing alliance chain resisting voting system, according to claim 2, wherein the communication between the blockchain client and the server Endorser exists in the process of anonymous vote taking by a voter, the client identity information in the step A1 is false identity information of the voter, the transaction parameters include IDU component one and an anonymous vote taking instruction, and the secret value corresponding to the transaction information in the digital signature is a secret component random number one and a timestamp to obtain two hash values; in the step A3, the read information is voting identity information and votes, and the value of the written information is null.
4. The secret sharing-based method for resisting the quantum computing alliance chain voting system according to claim 2, wherein the communication between the blockchain client and the server Endorser exists in the process of inquiring the voting result by the voter, the client identity information in the step A1 is the identity information of the voter, the transaction parameter is the voting identity information, and the secret value corresponding to the transaction information in the digital signature is the hash value of the public key set of all the voters in the voting list; in the step A3, the read information is a voting list, and the value of the written information is null.
5. The method for the quantum computing alliance chain voting system based on secret sharing is characterized in that communication between the blockchain client and the server Endorser exists in the process of anonymously inquiring the voting result of the voter, in the step A1, the client identity information is false identity information of the voter, the transaction parameters comprise IDU component I and an instruction of anonymously inquiring the voting result, and the secret value corresponding to the transaction information in the digital signature is a secret component random number I and two hash values are obtained by time stamp calculation; in the step A3, the read information is voting identity information, a voting list and a voting result, and the value of the written information is null.
6. The method for the secret sharing-based anti-quantum computing alliance-chain voting system is characterized in that the method further comprises the following steps of carrying out communication between the blockchain client and the service terminals Orderer and Committer, wherein the communication comprises a communication process between the blockchain client and the service terminal Endorser:
step B1: the client sends the endorsement to the order: the client combines the effective response information sets into an endorsement and sends the endorsement to an Orderer;
and step B2: order sends the ordered endorsement set to Committer: the Order collects endorsements sent by a plurality of clients and sequences the endorsements, after the maximum value of the blocks is reached or exceeds the maximum value of time, the Order combines the endorsements, and the Order sends an endorsement set to the Committer, wherein the endorsement set comprises an endorsement serial number, a hash value of a last alliance chain block and a plurality of combined endorsements;
step B3, committer verifies the endorsement set and updates the world state, namely updates the local key pool information: the Committer takes out valid transaction responses in all endorsements, finds a public key verification digital signature corresponding to the Endorser in a block chain service public key pool of a service key fob of a service end, calculates and verifies read information, checks whether the verified transaction responses meet requirements of endorsement strategies, makes a valid or invalid mark for the corresponding endorsements according to verification results, and updates a local world state by the Committer, and also comprises a Committer updating voting state database, namely the Committer adds write-in information in all the valid endorsement transaction responses to the local world state;
step B4, the Committer sends an endorsement notification to the client: after the operation of the Committer is completed, generating an endorsement notification and sending the endorsement notification to the client, wherein the endorsement notification comprises a transaction hash value, a transaction result and a Committer signature, and the Committer signature is a digital signature of the Committer on the transaction result and a corresponding secret value by using a private key of the Committer;
step B5, the client receives the endorsement notification: the client side verifies the digital signature through a Committer public key stored in a client key fob public key area; and the client acquires the transaction result after the verification is passed.
7. The secret sharing-based quantum computing alliance-chain resistant voting system method according to claim 6, wherein the communication between the blockchain client and the service commander exists in a process of initiating a vote by a voter, the client identity information in step A1 is identity information of the voter, the transaction parameters are voting identity information, an identity information list of the voter and a voting list, the secret value corresponding to the transaction information in the digital signature is a hash value of a public key set of all voters in the voting list, the read information in step A3 is a hash value of the public key set of the voter and the identity information of the voter, and the written information values are voting identity information, voter identity information and a voting flag bit.
8. The method of claim 6, wherein the communication between the blockchain client and the server commander exists in the anonymous voting process of the voter, the step A1 further includes determining whether the current timestamp satisfies the process of replacing the false identity information in the key card of the voter, the client identity information in the step A1 is the false identity information of the voter, the transaction parameters include an IDU component one, an anonymous voting instruction, and a vote set, the contents of the votes in the vote set are encrypted by the public key of the voter, the secret value corresponding to the transaction information in the digital signature is the updated secret component random number one and the updated secret component random number two, the reading information in the step A3 is the false identity information of the voter, the hash values of the secret component random number one and the secret component two, the writing information is the IDU component one and the valid vote set, the updated local key information in the vote pool in the step B3 includes the false identity information in the updated local key pool, the false identity information in the public vote pool one and the secret component random number B, and the secret component in the secret component random number B5 are stored, and the false identity information in the secret component in the voter itself is obtained, and the false identity information in the secret component B is updated in the voter.
9. The method for resisting a quantum computing alliance chain voting system based on secret sharing according to claim 8, wherein the step A1 comprises the following steps of: acquiring a current time stamp, reading a secret component random number I from a key card of a voter, calculating to obtain two hash values according to the secret component random number I and the current time stamp, taking the hash values as a new secret component random number, comparing the secret component random number I with the two hash values, if any two are equal, the current time stamp does not meet the condition of replacing the false identity information, and acquiring the time stamp again and calculating the two hash values until the condition of replacing the false identity information is met.
10. The method according to claim 6, wherein the communication between the blockchain client and the server commander exists in a process of publishing a voting result by a voter, after the voter queries the voting result, a valid vote in the voting list is decrypted by using its own private key to obtain a voting content, the client identity information in step A1 is identity information of the voter, the transaction parameters include voting identity information and a voting result, the secret value corresponding to the transaction information in the digital signature is a hash value of a public key set of all voters in the voting list, the read information in step A3 is a hash value of the public key set of all voters and the identity information of the voter, and the write information is the voting identity information and the voting result.
CN202010041056.7A 2020-01-14 2020-01-14 Anti-quantum computing alliance chain voting system and method based on secret sharing Active CN111277407B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010041056.7A CN111277407B (en) 2020-01-14 2020-01-14 Anti-quantum computing alliance chain voting system and method based on secret sharing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010041056.7A CN111277407B (en) 2020-01-14 2020-01-14 Anti-quantum computing alliance chain voting system and method based on secret sharing

Publications (2)

Publication Number Publication Date
CN111277407A CN111277407A (en) 2020-06-12
CN111277407B true CN111277407B (en) 2023-01-24

Family

ID=71002180

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010041056.7A Active CN111277407B (en) 2020-01-14 2020-01-14 Anti-quantum computing alliance chain voting system and method based on secret sharing

Country Status (1)

Country Link
CN (1) CN111277407B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112543101B (en) * 2020-12-17 2021-08-17 广州欧赛斯信息科技有限公司 Traceable anonymous voting method and traceable anonymous voting system based on time release

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004013606A (en) * 2002-06-07 2004-01-15 Nippon Telegr & Teleph Corp <Ntt> Electronic voting method and system, voter device and manager device and tabulator device, electronic voting program and storage medium with its program stored
CN109964446A (en) * 2018-06-08 2019-07-02 北京大学深圳研究生院 A kind of common recognition method based on ballot
CN110555933A (en) * 2019-07-31 2019-12-10 中钞信用卡产业发展有限公司杭州区块链技术研究院 Electronic voting method, device, equipment and computer storage medium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030008182A (en) * 2002-12-24 2003-01-24 학교법인 한국정보통신학원 Method of id-based blind signature by using bilinear parings

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004013606A (en) * 2002-06-07 2004-01-15 Nippon Telegr & Teleph Corp <Ntt> Electronic voting method and system, voter device and manager device and tabulator device, electronic voting program and storage medium with its program stored
CN109964446A (en) * 2018-06-08 2019-07-02 北京大学深圳研究生院 A kind of common recognition method based on ballot
CN110555933A (en) * 2019-07-31 2019-12-10 中钞信用卡产业发展有限公司杭州区块链技术研究院 Electronic voting method, device, equipment and computer storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
一种基于区块链技术的可信电子投票方法;范洪博等;《软件导刊》;20180515(第05期);全文 *

Also Published As

Publication number Publication date
CN111277407A (en) 2020-06-12

Similar Documents

Publication Publication Date Title
Lee et al. Electronic voting service using block-chain
CN110189128B (en) Distributed consensus method and device for block rapid generation
Tran et al. A survey on privacy-preserving blockchain systems (PPBS) and a novel PPBS-based framework for smart agriculture
CN114450708B (en) Chain code recommendation based on existing chain codes
CN110008720A (en) Internet of Things dynamic data source tracing method and device based on alliance&#39;s chain
CN115174089A (en) Distributed management method and system for electronic property right voucher (EDT)
CN111416705A (en) Quantum computing resistance alliance chain voting system and method based on identity cryptography
CN110690957B (en) Anti-quantum computing private key backup, loss report and recovery method and system
CN111160998B (en) Comment data processing method and device based on block chain and comment system
Abbade et al. Blockchain applied to vehicular odometers
CN110868295A (en) Anti-quantum computing alliance chain system based on secret sharing and communication method
CN116192405B (en) Electronic voting method and related device
CN110737915B (en) Anti-quantum-computation anonymous identity recognition method and system based on implicit certificate
US20230259901A1 (en) Issuing entity and method for issuing electronic coin data sets, and payment system
CN112801778A (en) Federated bad asset blockchain
CN112733159A (en) Free ride node identification for blockchains
CN110661613A (en) Anti-quantum-computation implicit certificate issuing method and system based on alliance chain
CN114726535B (en) Privacy protection anti-fake automobile supply chain method based on blockchain
CN114693241A (en) Block chain-based electronic resume system and implementation method thereof
CN111277407B (en) Anti-quantum computing alliance chain voting system and method based on secret sharing
Preece Ticket to ride: an investigation into the use of blockchain technology in the rail industry
US20240022398A1 (en) System and method for decentralized confirmation of entries in a directed acyclic graph for rapidly confirming as authentic ledger entries without requiring centralized arbitration of authenticity
DE102021002329A1 (en) METHOD OF REGISTERING AN ELECTRONIC COIN RECORD IN A COIN REGISTER; A COIN REGISTER; A SUBSCRIBER UNIT AND A COMPUTER PROGRAM PRODUCT
Cherukupally Blockchain technology: Theory and practice
WO2023002640A1 (en) Fully distributed blockchain system and computer program for crypto asset transaction that allows participation of anonymous user while preventing illegal transaction

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant