4. Cryptographic protocol analysis
[DRAFT VERSION]
This section analyze the whole Agora main process described in the functional analysis under the point of view of the cryptographic protocol.
The network is already full of many implementation and examples of voting applications that use blockchains; the added value of the Agora project is the implementation of a cryptographic protocol on top of the Ethereum blockchain, in order to achieve confidentiality of transactions and information inside the blocks. At the moment of writing exist only some academic works that goes in this direction, this is a terrain still little explored.
The possible implications of such an implementation go beyond the single use case of a voting system that Agora represents.
The cryptographic protocol that Agora wants to implement is therefore a key point of the project and since such protocol is so important in terms of security and success of the project and since there are no expert cryptographers working on the project, this analysis is public and open to anyone who wants to read it and improve it.
the protocol is divided into the following phases:
- DECs Registry deploy: the Public Authority (aka Admin) deploys the Registry on the blockchain. This operation is done only once.
- EOA and DEC registration: the Admin creates for the Voter the EOA and the DEC, register the DEC on the registry and delivery the EOA credentials to the Voter.
- Election registration: the Admin creates and election, deploying thr related smart contract with the registration period where parties can register and build coalitions. At the end of the registration phase a ballot is defined.
- Vote casting: an election voting period is defined, where Voters cal download from the Agora platform the voting platorfm and cast the vote;
- Vote acquisition: The Voter express the vote and cast it to the election smart contract. The smart contract checks the vote rights and the ballot compliance, then acquires the vote;
[continue...]
The Registry smart contract is deployed by the Public Authority, the smart contract registers the address of the owner that is the only one that has write permissions to the contract itself. Anyone can consult the registry but only the Public Authority can write on it.
The registry smart contract takes track of:
- The DECs registered in a list;
- The "stamps" (election metadata) on each DEC that certify which elections the voter participated in;
For each Voter, a DEC smart contract is deployed and registered on the Registry smart contract using the DEC address. In the registration phase, the Registry smart contract checks that for a given Voter there isn't a DEC already registered and active.
The DEC contains the following data:
- Tax Code;
- Municipality;
- Region;
- Country;
- isDECActive;
The tax code, municipality, region and country are encrypted on client side before to deploy the contract, by using the Authenticated Encryption AES-GCM algorithm.
The AES-GCM has been standardized by NIST in 2007 and is widely used on the web.
This primitive uses the 256-bit length private key of the Voter's EOA.
This is how each field of the DEC (taxCode, municipality, region, country) looks like on the DEC smart contract:
{
"hash": "9fc47b042655dfb0eef46388757c9e78ee9b80b88b187b696d1937abdd2879af"
"chiper": "f571155c51df4b641547f1310dce3acea1b7c99e495c33ad82319f9334cb5072",
"nonce": "736f56a5f1576e0ff7fd6626"
}The hashes of the fields are registered on the DEC using the SHA-3-256 bit security. The hash of the taxCode is used to prevent the Public Authority to register a second active DEC for the same Voter, when the Public Authority registers the DEC on the Registry it is checked:
- if already exists a DEC with the same taxCode hash;
- in case exists, if the DEC registered is active;
The hashes of the other fields are used to check the voting rights for a certain election (see later steps).
After the DEC registration, the Public Authority delivers the EOA credentials (private key and public address) to the Voter.
| attack | attack description | countermeasures |
|---|---|---|
| man-in-the-middle | the attacker intercepts the data before it is encrypted | the data is encrypted on client side before to send them to the blockchain |
| cryptoanalysis | the attacker discover vulnerabilities in the primitives used | the software that implements the primitives is kept updated |
| attack on the contracts | the attacker breaks the smart contracts | the smart contracts are implemented following the best practices and secure standards, they are tested and audited |
The primitives described above are implemented using the Cryptography Python library.
The election registration allow parties and candidates to register to the election. The data is acquired on the election smart contract. At the end of the registration period it is possible to define the ballot paper. No particular cryptographic algorithms are expexcted at this stage, but this phase is important for the protocol because it defines data structure of the ballot paper. As an example we define a ballot paper for a municipality election where up to 20 voting points can be assigned:
{
"coalition1": {
"mayorCandidate": 5,
"parties": {
"partitoDemocratico": 2,
"cinqueStelle": 2,
}
},
"coalition2": {
"mayorCandidate": 4,
"parties": {
"forzaItalia": 1,
"lega": 3
}
}
}from this moment on, it is convenient to represent this ballot as a vector:
["5", "2", "2", "4", "1", "3"]Naturally, in this phase no voting points are assigned. We reported the points only to better describe the ballot vector.
The ballot paper and consequentially the vector (v) changes based on the type of the election and the electoral rules to respect for a particular election. Anyway, it is always possible to represent a ballot using a vector v.
When the registration period ends, the Admin set the data required by a client application that the Voter downloads from the Agora platform in order to cast the vote. The Voter does not vote using the Agora dApp directly because we want to keep secret the vote and do not in any way go through server-side operations: the client casts the vote directly to the election smart contract.
This is the key phase of the Agora cryptographic protocol: the vote, represented by the vector v, is the secret to maintain, it is defined on the client side and in order to be casted to the election smart contract we need to:
- Encrypt v in order to not allow anyone to decrypt it;
- Allow to sum all the ballots still encrypted: v1 + v2 + vn, in order to calculate the election results;
- Verify that the ballot v is formally correct and respect all the rules without revealing v itself;
- Verify that the encrypted ballot v1 has been encrypted starting from v without revealing v;
Points 1 and 2 are implemented by using a partially homomorphic encryption scheme: during the setup of the client application a public/private key pair is generated. The public key is set on the client app and it is used by the Voters to encrypt the votes. When the election closes the encrypted vectors are summed and the Admin decrypt the results using the private key. The private key is not able to decrypt the single vector:
