Skip to content

Commit 1edd544

Browse files
chenchanglewchenchanglew
authored
Merge pull request #229 from dedis/feature/verifiability-design-doc
create verifiability docs
2 parents e3d0647 + 1869527 commit 1edd544

File tree

2 files changed

+174
-0
lines changed

2 files changed

+174
-0
lines changed

‎docs/sidebar.md

+2
Original file line numberDiff line numberDiff line change
@@ -9,3 +9,5 @@
99
- **Smart contract**
1010
- [Smart contract](smart_contract.md)
1111
- [Data structure](state_of_smart_contract.md)
12+
- **Security**
13+
- [Vote Verifiability](verifiability_doc.md)

‎docs/verifiability_doc.md

+172
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
# vote verifiability
2+
3+
## Introduction
4+
5+
Verifiability is an important property that enables a voters to check their vote has been cast unaltered, and that it has been registered correctly in the electronic ballot box.
6+
7+
The current d-voting [latest commit](https://github.com/dedis/d-voting/commit/39a2d3363dd064a95186b0c31a44dfdea3325002) did not have this design yet. The current encrypted ballot logic is as follows:
8+
9+
```mermaid
10+
sequenceDiagram
11+
autonumber
12+
participant User
13+
participant Backend
14+
participant NodeX
15+
participant NodeY
16+
User ->>+ NodeX: GET election info
17+
NodeX ->>- User: Return election info.
18+
User ->>+ Backend: POST /api/evoting/elections/<electionId>
19+
Note over User: data: {"Ballot": ...}
20+
Note over User: encrypt ballot via Elgamal encryption using electionPubKey
21+
Note over User, Backend: data = encrypted ballot
22+
Note over Backend: check role and sign payload.
23+
Note over Backend: add userID inside payload.
24+
Note over Backend: sign = kyber.sign.schnorr.sign(edCurve, scalar, hash);
25+
Backend ->>+ NodeX: POST /evoting/elections/
26+
Note over Backend, NodeX: data: {"Payload": dataStrB64, "Signature": ""}
27+
Note over NodeX: verify and execute, then boardcast
28+
NodeX ->> NodeY: boardcase via gRPC
29+
NodeX ->>- Backend: 200 OK text/plain
30+
Backend ->>- User: 200 OK text/plain
31+
```
32+
33+
As the picture shows, the frontend encrypts the ballot using Elgamal encryption which has a nondeterministic result and then sends it to the backend to verify and sign. After that, the backend sends the encrypted + signed ballot to the blockchain node to put it on the chain. However, since the encryption is nondeterministic thus the user will not be able to verify their casted ballot stored in the node.
34+
35+
In this document, we aim to design an implementation to achieve verifiability of the voters' encrypted vote without leaking ballot information to others.
36+
37+
## Requirements
38+
39+
The voter should be able to verify their encrypted ballot in the frontend.
40+
The encrypted vote remains confidential from everyone except the voter.
41+
The Node shall be able to show voters’ encrypted ballot.
42+
43+
## Related work
44+
45+
### Strawman approach
46+
47+
The strawman design is just using a fixed seed to encrypt the ballot which makes the encrypted ballot deterministic. Then the user can verify the encrypted ballot on the chain by just encrypting a new ballot with the same option.
48+
49+
However this design actually will break the confidentiality property of our d-voting system. An adversary is able to decrypt the user's ballot by recording the ciphertext of the encrypted ballot in every possible choice. Then the adversary can just check the ciphertext on the chain and will notify the voter ballot.
50+
51+
Thus we should keep some secret only to the voter themselves or the backend to prevent adversaries unlocking the ballot.
52+
53+
### Swiss POST evoting system
54+
55+
Swiss POST implement their own [e-voting system](https://www.evoting.ch/en) which support the verifiability of the casted ballot.
56+
57+
Their protocol takes place between a User, a trusted device, and an untrusted device. In this example the user will be Alice, the trusted device will be her cellphone, and the untrusted device will be the e-voting backend system. After casting the vote, user will receive a encBallotReport (via QR code). Then the user can verify if their vote has been cast correctly or not.
58+
59+
```mermaid
60+
sequenceDiagram
61+
autonumber
62+
participant User
63+
participant TrustedDevice
64+
participant Backend
65+
participant Node
66+
User ->>+ TrustedDevice: cast vote
67+
TrustedDevice ->>+ Backend: plain ballot
68+
Note Over Backend: Generated random voteID, use it as RNG to generate encBallotReport.
69+
Backend ->> Node: Send encBallotReport to NodeNetwork
70+
Backend ->>- TrustedDevice: encBallotReport + voteID
71+
TrustedDevice ->>- User: show encBallot Report (via QR code etc)
72+
Note Over User: Use the voteID and verify the encBallotReport
73+
Note Over User: verify via Hash of report etc.
74+
```
75+
76+
## Proposed solution
77+
78+
According to our requirements, we assume that the frontend is trusted. If the frontend is compromised, the adversary can already know the plaintext of the ballot which breaks the confidentiality of the ballot.
79+
80+
When the frontend after the frontend encrypted the ballot (use default non-deterministic encryption), it can hash the encrypted ballot and show the hash str of the encrypted ballot. The frontend sends the encrypted ballot to the backend.
81+
82+
A user can then check the hash of the vote by looking at the details of the form if the hash of the vote matches the one he received.
83+
84+
```mermaid
85+
sequenceDiagram
86+
autonumber
87+
participant User
88+
participant Backend
89+
participant NodeX
90+
participant NodeY
91+
User ->>+ NodeX: GET election info
92+
NodeX ->>- User: Return election info.
93+
User ->>+ Backend: POST /api/evoting/elections/<electionId>
94+
Note over User: data: {"Ballot": ...}
95+
Note over User: encrypt ballot via Elgamal encryption using electionPubKey
96+
Note over User: generate hash of encrypted ballot and show to user
97+
Note over User, Backend: data = encrypted ballot
98+
Note over Backend: check role and sign payload.
99+
Note over Backend: add userID inside payload.
100+
Note over Backend: sign = kyber.sign.schnorr.sign(edCurve, scalar, hash);
101+
Backend ->>+ NodeX: POST /evoting/elections/
102+
Note over Backend, NodeX: data: {"Payload": dataStrB64, "Signature": ""}
103+
Note over NodeX: verify and execute, then boardcast
104+
NodeX ->> NodeY: boardcase via gRPC
105+
NodeX ->>- Backend: 200 OK text/plain
106+
Backend ->>- User: 200 OK text/plain + voteSecret
107+
User ->>+ NodeX: get form details
108+
NodeX ->>- User: return form details and hash of encrypted vote.
109+
Note over User: check the hash of the vote is the same or not.
110+
```
111+
112+
However, this design is still not perfect because it doesn't have a coercion resistance property. After all, coercers will know the Hash of the encrypted ballot during the vote. We can achieve coercion resistance by moving the encryption process to the backend and using the Benaloh challenge protocol to encrypt the vote. But currently, our system doesn't require coercion resistance thus we will not implement this.
113+
114+
### frontend
115+
116+
- Edit the submit vote function
117+
- hash the encrypted ballot and show it to the user.
118+
- Edit the form details page to show the hash of the ballot.
119+
- A user can select an election to see the details.
120+
- In the detail page, it shows the voter and the hash of their ballot.
121+
- Users can check if the hash they received is the same as the hash on the details.
122+
123+
### Blockchain node
124+
125+
- edit api "/evoting/forms/{formID}", add the hash of the ballot to the form structure.
126+
127+
## Extension coercion protection
128+
129+
Here we proposed a solution to protect against coercion. However, this will not be implemented because it will need to change most of the current architecture. We will implement the Benaloh challenge in this design.
130+
131+
### Benaloh Challenge
132+
133+
[Benaloh Challenge](https://docs.rs/benaloh-challenge/latest/benaloh_challenge/) (also known as an Interactive Device Challenge), a crytographic technique to ensure the honesty of an untrusted device. While orignially conceived in the context of voting using an electronic device, it is useful for all untrusted computations that are deterministic with the exception of using an RNG. Most cryptography fits in this category.
134+
135+
This protocol takes place between a user, a trusted device, and an untrusted device. In this example the user will be Alice, the trusted device will be her cellphone, and the untrusted device will be a voting machine. The voting machine needs to do some untrusted computation using an RNG (encrypting Alice's vote), the details of which need to be kept secret from Alice so she can't prove to a 3rd party how she voted. However, the voting machine needs to assure Alice that it encrypted the vote correctly and didn't change her vote, without letting her know the secret random factors it used in it's encryption.
136+
137+
```mermaid
138+
sequenceDiagram
139+
autonumber
140+
participant User
141+
participant TrustedDevice
142+
participant Backend
143+
participant Node
144+
User ->>+ TrustedDevice: marks ballot
145+
TrustedDevice ->>+ Backend: plain ballot
146+
Note Over Backend: Encrypted her marked ballot (using random factors from an RNG)
147+
Note Over Backend: presents a one-way hash of her encVote (via QR code) (commitment)
148+
Backend ->>- TrustedDevice: send one-way hash and provide two option (cast/challenge)
149+
TrustedDevice ->>- User: show Report (via QR code etc)
150+
Note Over User: if user decide to "cast", process is done
151+
Note Over User: if he/she choose challenge, she can scan the QR (hash of encVote) and select challenges.
152+
TrustedDevice ->>+ Backend: send challenge request
153+
Backend ->>- TrustedDevice: give the marked-ballot and random factors RNG.
154+
Note Over User, TrustedDevice: checks commitment by re-computing commitment using markedBallot & RNG
155+
Note Over User, TrustedDevice: if different, Backend is compromised
156+
Note Over User, TrustedDevice: if same, return to step 1, (remark ballot)
157+
Note Over User, TrustedDevice: can repeat the protocol as many as they wish until casts her ballot.
158+
```
159+
160+
The voting machine must produce the commitment before it knows whether it will be challenged or not. If the voting machine tries to cheat (change the vote), it does not know if it will be challenged or if the vote will be cast before it must commit to the ciphertext of the encrypted vote. This means that any attempt at cheating by the voting machine will have a chance of being caught.
161+
162+
In the context of an election, the Benaloh Challenge ensues that systematic cheating by voting machines will be discovered with a very high probability. Changing a few votes has a decent chance of going undetected, but every time the voting machine cheats, it risks being caught if misjudges when a user might choose to challenge.
163+
164+
### Proposed solution
165+
166+
Just like the Benaloh challenge, a user can assume that the backend is untrusted, and they have a Benaloh challenge with the backend.
167+
168+
The user first encrypts their ballot using the election public key and then sends it to the backend. Then the backend encrypts the encrypted ballot again with a randomly generated seed and sends the hash of the enc(enc(ballot)) to the user.
169+
170+
Then the user can choose to challenge (which backend reveals the random seed) or accept (which backend executes the vote).
171+
172+
With this approach implemented, we are able to have coercion protection. However, the node will need to decrypt the ballot two times which requires changing the decryption process and increasing the execution time.

0 commit comments

Comments
 (0)