To make fair elections possible, many aspects must be considered. When we put ourselves in the shoes of a voter, the first thing we do is search for the website. Many people however will follow the first link they see and use it without double checking the source. Therefore, it is needed to give clear instructions as to where they can find the right website. Using the burgerprofiel (citizen’s page?) that every citizen already has, to make the link to the voting website available, is a much safer option. This also limits people from outside finding out which website is used for these elections. To further limit the requests within an interval of time, and so provide more availability, every citizen will get a time slot for when they can vote. ### Improve the text above. I am writing a scientific paper on information security during online voting.
Burgerprofiel is een online dienst van de Vlaamse overheid. Beschrijf het in 1 korte zin, in het Engels. Je mag je baseren op de volgende tekst: Mijn Burgerprofiel Eén persoonlijk overzicht van alle overheidszaken. Mijn Burgerprofiel verzamelt al uw officiële gegevens en uw overheidsadministratie. Altijd beschikbaar wanneer u ze nodig hebt.
The next paragraph is the following: ``` So, when the voter goes to the page in their given time slot, the next logical step is verifying who they are. Before the user can talk to the authentication server, more information is needed to be available. That’s why the intermediary server is spoken to first when the client is started, whose IP-address was available in a config file. This server will send the IP-address from the authentication server, as well as the public key of the backend server and a list of options to vote on. This is sent over a TLS connection to secure the traffic between client and intermediary. Now the user can start the verification process to guarantee the authentication and authorization part of the system. An asymmetric key is generated for the user behind the scenes, so when the user authenticates itself with e-id, the public key of the generated pair is sent with it. The server then keeps the user’s public key in a table with a generated voter_id. This voter_id is sent back to the user. Now the user is authenticated and saved to a database within the authentication server to make sure no other user can vote in their place. ```
> With this information, the user can initiate the verification process to ensure the authentication and authorization components of the system are functioning correctly. It should be clear that the user is now authenticated, so its identity is confirmed, and authorized, so it is known and verified that the user is allowed to vote. Rewrite the text.
The voter ID is used to represent the voter in a unique way without making it publicly known who the voter is.
To ensure fair and secure elections, several factors To make fair elections possible, many aspects must be considered, as described in the previous section. Our system consists of 4 key pars: a client, an intermediary server, an authentication server and a backend server. An overview of the system is shown in Figure 1. Improve this paragraph
The next section is about casting the vote ``` % PARAGRAPH Cast a vote The voter is now verified and can now vote from the given options. Every user gets the same options to choose from. This implies that encrypting only the chosen option(s) to be sent to the backend is a bad idea, as multiple users can produce the exact same outcome. To solve this problem, a salt is added to the vote. Then the backends' public key encrypts this vote and salt together. To make sure this vote comes from a valid person, the private key of the user signs all of this together with the voter_id. Up till now, the following has been done: user_private_key(backend_public_key(vote + salt), voter_id) (1) This information is then sent to the intermediary together with the voter_id, again over TLS. ```
% PARAGRAPH Accepting vote The intermediary is now in charge of verifying that this vote comes from a valid person. This can be done by sending the voter_id with the data of (1) to the authentication server. This service will look up the voter_id and apply the public key that corresponds to it on (1). If the information is not altered or generated on the way, the decryption will work, and the voter_id and encrypted vote is now available. The authentication server then checks whether the decrypted voter_id and the original voter_id are equal. If this is the case, the encrypted vote is sent back to the intermediary. To ensure vote secrecy, so data confidentiality, this mechanism makes sure the vote and the user are always separated. When the user’s credentials are checked, the vote is encrypted, and can’t be recovered. When the vote goes to the backend to count their vote, the user is already scraped from the original message. This means that user privacy is in place. An important addition to the system is saving every voter_id in the database of the intermediary when a user has sent their vote. This is needed so the user cannot vote multiple times. On the other hand, the system allows you to send in multiple votes, but will drop the packets once it’s clear that you have already voted. It is a mild measure to protect users from people trying to find out whether they already voted or not. Let’s say the user is forced to open the website again and is forced to vote on someone. The website will let you login and vote, the vote however won’t be registered again. It is impossible to know when a user is forced or not, so this measure won’t protect in all cases, but it’s a way to slim down the chances of forced voting.
Next paragraph: ``` % PARAGRAPH Accepting a vote To ensure vote secrecy, so data confidentiality, this mechanism makes sure the vote and the user are always separated. When the user’s credentials are checked, the vote is encrypted, and can’t be recovered. When the vote goes to the backend to count their vote, the user is already scraped from the original message. This means that user privacy is in place. An important addition to the system is saving every voter_id in the database of the intermediary when a user has sent their vote. This is needed so the user cannot vote multiple times. On the other hand, the system allows you to send in multiple votes, but will drop the packets once it’s clear that you have already voted. It is a mild measure to protect users from people trying to find out whether they already voted or not. Let’s say the user is forced to open the website again and is forced to vote on someone. The website will let you login and vote, the vote however won’t be registered again. It is impossible to know when a user is forced or not, so this measure won’t protect in all cases, but it’s a way to slim down the chances of forced voting. ```
% PARAGRAPH Store votes Finally, The last thing the intermediary should do with the received packet from the authentication server, is sending it through to the backend server and the audit servers who serve as backups. There the vote can be decrypted with the private key from the backend. Once it arrives in the backend, the vote is counted into the database without the knowledge of who voted on who. The multiple audit servers are in place to guarantee that the votes are indeed correctly counted.
Append the paragraph with a sentence that makes clear the process is finished. The vote is cast securely.
Summarize the article
Try to describe the requirements for fair physical elections in a few sentences based on the linked website.
I would like to write a section called "Requirements for fair elections". I have the following structure in mind: - Requirements for fair physical voting and elections. How are they implemented? - Translation into requirements for online voting. - Authentication - Authorization - Confidentiality aka vote secrecy - Integrity aka verifiability - Non-repudiation - Availability Can you provide a start for me to build upon?