JanisErdmanis
commented
7 months ago I've made a significant advancement in integrating the API authorisation on the Julia side, achieving compatibility with the existing JavaScript implementation right from the outset. This small milestone includes the development of fetchAuthorize in JavaScript, mirroring the functionality of the standard fetch method but with an additional feature: it accepts an authorisation key to sign the request and verify the signed response.
On the Julia side, I've introduced AuthorizationMiddleware, which is designed to simplify adaptation to various requirements. This middleware facilitates the seamless integration of authorisation mechanisms into our existing infrastructure. Also, CORS issues have been resolved so that the requests can be made from a random static page without issues.
I have put proof of concept in this gist. This implementation freezes Julia and JavaScript for endpoint authorisation APIs for #14, so work can continue on the refactor.
At present, voters can only confirm that their vote has been cast as intended and accurately counted after the vote has ended and the votes are published. As the publication of votes can be delayed as a measure against coercion, it might discourage voters' participation from verifying that their vote is indeed cast as intended and counted as cast. The key issue lies in the possibility of unnoticed malware on voting devices. If voters don't verify their votes, the likelihood of malware affecting a significant number of votes without detection increases. Thus, having a procedure that enables immediate verification of the voting process is essential to engage more voters to check their votes.
The PeaceFounder system can address this by providing voters with a token displayed on the client's screen for vote verification. This token can be used in a web browser to confirm that the vote has been cast as intended. It also indicates if the vote has been superseded by a subsequent vote or one with a higher sequence number, which may occur if the member's key is compromised. To maintain receipt-freeness, the token remains valid for only a short period, such as 15 minutes. The expiration is crucial; it allows voters to verify their votes while preventing coercion or bribery attempts. It also hinders any unsolicited checks on voters' choices.
The most straightforward method to generate a token is using the byte string of the vote. This is done by setting the token as $token={\rm{Hash}}(0|vote)$, where the vote itself is the secret to be safeguarded. To utilise this token, an HTTP request is sent to the server containing $TokenID={\rm Hash}(token)$ along with an HMAC of the request. This request is directed to:
When the server receives a vote verification request, it first checks that the token is valid and has not expired and then returns the vote's metadata. To maintain the integrity of this response during its transmission, the reply is secured with HMAC. Additionally, encrypting this reply would be advantageous to safeguard the voter's privacy when their network is under surveillance.
However, this approach has limitations. It doesn't prevent the possibility of a network monitor storing data for future comparison with the information on the ballotbox ledger, where votes and, therefore, tokens are eventually published. To enhance security in this aspect, the token could be derived from the Diffie-Hellman key, which could remain secret indefinitely. The server would generate a key pair and incorporate the public key into the receipt, whereas locally exponentiate pseudonym to derive the key.
There's also the risk of a corrupt election authority monitoring the voter. That could trace the voter's pseudonym back to their IP address and, ultimately, their identity. The most effective way to mitigate this risk is to run these requests through a TOR browser, ensuring anonymity. An ultimate solution from a usability point of view would be if the TOR client could be embedded within web assembly to make the request, but there does not seem to be support for that.
For this issue, the following tasks thus need to be addressed:
Regarding the website interface, several technical details must be specified: the server's address, the Hash/HMAC function for request authorisation, and the encryption method for replies. However, these technicalities will be seamlessly integrated into the user experience. A custom-designed bulletin board facade will hardcode these parameters, requiring the user only to input the token.
It's crucial to highlight that while voters can verify their vote to be cast as intended through this system, there remains uncertainty. Voters cannot be assured that malware won't ultimately influence the election results by altering their votes or adding a coercion tag invalidating it (which is not disclosed). Additionally, this implementation does not guard against the possibility of the server providing misleading information about the vote being cast. In such a scenario, the worst-case recourse for voters would be to recast their vote and eventually compare it with the ballotbox ledger after the votes are published.