Electronic voting or e-vote is the process of casting a vote electronically from a computer phone or tablet.
For the very first time the Italian government coordinated an e-vote for all abroad residents between 12th and 13th of December 2023 (https://evote.interno.gov.it/). This experiment did not have any effect (dummy test). However, as a security professional, I was curious to see how it was implemented and what cybersecurity issues might arise from a process like this.
The founding principles of voting
Article 48 of the Italian Constitution also encapsulates the basic principles regarding voting. Specifically mentioning that: "The vote must be personal and equal, free and secret". Let’s take a look at each of the above elements in details, which will be useful for later analysis of e-voting:
Vote must be personal
The voter must vote in person and may not vote by proxy. However, the constitution accommodates any physical limitations by permitting home voting and providing assistance to the blind.
Vote must be equal
Every vote has the same worth and weight regardless of who casts it. This concept emphasises the absence of any social or other distinction (gender, origin, religious belief, etc.) in the manifestation of the vote.
Vote must be free
The vote must be cast freely and without reservation. The voter must be free to vote without interference from outside parties. Voting is kept secret precisely to guarantee this concept.
Vote must be secret
The vote must be cast in perfect confidentiality. No one can learn about the voter's preferences. This concept guarantees that voting is free and that voters may express themselves freely.
It is therefore important to keep the electronic vote in line with the founding principles of “standard” voting.
Benefits of e-vote
e-voting would be a sleek and modern answer to today's voting issues. Long lineups would be eliminated, as would the use of paper ballots and obsolete voting equipment. It would also make voter registration and ballot counting more efficient. Ultimately, transitioning to an e-voting system would reduce the overall cost of elections.
Citizens would find online voting exceedingly handy. It would make voting available to all qualified voters. Many individuals cannot afford to take time off work to wait in huge queues to vote, but not only, it would allow citizens with mobility issues to finally take part at the vote in the comfort of their house. Furthermore, many individuals in rural areas must travel long distances to vote. Online voting would solve these issues by allowing everyone to vote using their cell phones, tablets, or desktop computers.
Challenges of e-vote
We can all agree that e-vote is extremely convenient and cheap for both governments and citizens, but how can we apply the founding principles of voting into an on-line system? How could someone trust that they are actually applied? What kind of data do we need to look at for reassurance? In this section we will analyse each of the founding principles to understand how an attacker could take advantage of an e-vote system from several perspectives:
Vote must be personal
The only method to validate a user’s identity behind a screen is via one of the dozens of Identity Verification providers. Specifically for Italy, there are three major paths to be verified:
- Electronic Identity Card (CIE) - issued in a Government building upon manual verification face to face (and with another valid form of ID)
- Public Digital Identity System (SPID) - can be requested online and, very similarly at how it’s done for Crypto Trading, a virtual assistant will video-call you to match the ID’s picture with your face
- National Health Card (CNS) - is issued by the Revenue Agency and can only be used with a smart card reader (very similar to a GSM SIM card)
In accordance with EU regulation, the above methods provide people with easy and rapid access to online services provided via three authentication levels of increasing security:
- Level 1: access is granted with a set of credentials (username and password)
- Level 2: access is granted with level 1 credentials and a temporary OTP code
- Level 3: a reader or an NFC-enabled smartphone is required to read the CIE
For online voting like the one carried out in December, a Level 2 access was required.
From an attacker perspective, violating this principle is pretty hard, since you should have credentials and physical access to the voter’s device.
Vote must be equal and free
Once you own a digital identity, these principles are already met. Online you’ll be voting regardless of your gender, origin, or religious belief. It’s also harder for an attacker to influence your voting decision if you’re doing it from the comfort of your home; also considering that many years ago voters were bribed with 20,00€ outside polling stations to vote for (and prove it) the criminal’s chosen party.
Vote must be weight equally and must be secret
This is probably the point where most people against e-voting could raise valid arguments. There must be an implicit trust between the voting machine/software/network and the voters. Let’s start by analysing how attackers could interfere with a vote by looking at some macro categories:
Communication channel
Whatever the vote is casted from a kiosk or from the voter’s laptop/tablet/phone, the communication channel has the responsibility of keeping the vote’s integrity and confidentiality. A motivated attacker able to intercept the vote (or even change it before being casted) will breach the secrecy principle. What are then the highest security standards for a secure communication channel? Today’s most secure standard is TLS 1.2 and 1.3 using only strong ciphers suites like Elliptic Curve Diffie–Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA).
Insider
A digital system is fully made (and maintained) by humans. There might be pressure from criminals (in form of bribe or psychological threats) to make changes on the voting system or infrastructure. For example, there will always be at least one person with full access (read/write) to the voting database, which could be pressured to change results just before voting ends. This scenario can be prevented by having full visibility on access and changes (logging), which should be monitored by externals (read only) users.
Insiders could also work before the vote opens to the public. The software handling user’s choices could be tampered to show something on screen, but actually change the vote before submission to the database. This can be prevented by open sourcing the voting’s software and let experts to review it for potential bugs or tampering. It is however hard to prove that a specific software is really running on the backend of the voting system. In this case, a third-party committee should validate this process.
Not only software, but also hardware shouldn’t be trusted – in case of kiosk voting system. However, we’re now probably going into the rabbit hole of conspiracy theory.
Being anonymous online
If we consider the secrecy of the vote, we must also take into consideration how we could be anonymous online. Is it really possible to not being tracked during the e-voting process? What are the trace we could leave behind?
Whenever we visit a website, we leave behind some unique trace, mostly (and importantly) the following:
- Internet public IP
- Device resolution, aspect ratio, and display dimension
- Browser name, version and window’s dimension
- Network congestion (ping time/TTL)
If all the above are correlated, the website can create a unique fingerprint of our session and track our clicks and choices – this is roughly what happens when we’re tracked for advertisement.
Another important consideration to make is that Internet e-voting portals are often available between 24 and 72 hours, where millions of people will need to connect, login, express their choice and logout. Not to mention potential dissidents that will try to DDoS (Distribute Denial of Service) the system. To handle that amount of traffic and being available to all legit users, IT administrators will often opt to host the e-voting system on the cloud, with CDN (Content Delivery Network), and behind a WAF (Web Application Firewall).
Analysing the Italian e-vote system
Now that you have a rough idea of what should and shouldn’t be done on a e-voting system, let’s take a look at how the Italian e-voting was implemented.
Regarding the communication channel, the Italian government opted to use the following configuration, which was in line with today’s standards and offering great protection for the end-user.
Figure 1: TLS versions and cipher suites
The whole infrastructure was hosted on Amazon AWS behind a web application firewall named Cloudfront. It is therefore hard to identify where the origin web servers and databases were physically hosted (I suppose in a datacentre located in Italy). Another advantage of using Cloudfront is the high standards on the provided SSL certificate, which was using a SHA256-RSA algorithm with a key of 2048-bit.
Figure 2: SSL certificate details
Looking at the cookie issued by the webapp, we can only observe one by BigIP, used for load balancing purposes (so technical, not tracking cookie). These cookies are known to encode (not encrypt) the server’s internal IP address:
Figure 3: Cookie and internal IP
For the purpose of this mock e-vote, only Italian residents abroad were allowed to login and express their vote. Therefore, the next test we performed was to access the website (using Level 2 authentication described above) with two different SPIDs (one belonging to a resident abroad, and another one from a resident in Italy):
Figure 4: Landing page using a SPID belonging to a resident abroad
Figure 5: Error message while using a SPID belonging to a resident in Italy
No issues while accessing with credentials belonging to a resident abroad but, while trying to access the portal using credentials belonging to an Italian resident, we got an error message saying that the citizen was not present in the list, which is in line with the directives of this e-vote.
The authentication process is handled by the Identity Verification Provider, which will communicate to the voting portal using Security Assertion Markup Language (SAML) which is an open standard for exchanging authentication and authorization data between parties. Once the SAML is validated by the voting application, a token is issued to the browser to perform authenticated requests:
Figure 6: The authentication token issued after a valid login
The analysis of this session token highlighted that it was fully encrypted and there was no way to identify potential data carried in the token (like you would normally do for a JWT).
Before proceeding with the actual vote, the user was asked to accept to vote electronically (a simple checkbox). Once done, the system requested an additional authentication token (named VoteToken) to the endpoint ‘/elettori-ms/protected/oracle/qa’. Once again the VoteToken was fully encrypted.
Figure 7: The VoteToken request and response
Once filling all the choices and names in the e-ballot, one single POST request was issued to the application containing:
- The Authorization header with the VoteToken in it
- Fully encrypted POST body
The server responded with a “200 OK” confirming that the vote was successfully submitted.
Figure 8: Vote submitted
One of the test we performed, was to repeat this exact same request (known as replay attack) to see if the server would accept an additional vote using the same VoteToken and encrypted body but, as expected, the application returned a “500 Internal Server Error”, denying our attempt to re-submit a previous vote.
Figure 9: Vote re-submit
Let’s now focus on the encrypted body of the vote. This element must be calculated on the client-side (via JavaScript) to be constructed. From a first look at the JS files (Webpack with heavy obfuscation), we identified the file responsible for the encryption and discovered it was using AES-CBC with pretty strong IV and Key:
Figure 10: JavaScript file containing the encryption keys
Figure 11: The decrypted content of the vote
The server must have the same IV and Key to decrypt the body and read what were the choices of the voter. Once again no sensitive information related to the current logged-in user were included in the request (maintaining secrecy of the vote). It would have been possible to manually tamper with the choices, but most probably the vote would be invalidated afterwards.
After submitting the vote, we tried to challenge the system to issue a new VoteToken (with a fresh session and browser), however the system prevented this, returning a “500 Internal Server Error”, which is in line with e-vote business logic.
Figure 12: Attempting to get a new VoteToken
After submitting a vote, the web UI did not allow users to see the ballots or to change their consent to e-vote, but it was however possible to do so via the API calls. For the ballot details, it was possible to submit the following GET request to ‘/schede-ms/protected/scheda?id=448’ or 447:
Figure 13: Accessing ballots details after voting
As a side note about the data returned in the response, each candidate (fakes, as a reminder – since this was a dummy test) had their PII included, for example:
- Full name (that’s the only element shown in the e-ballot UI)
- Date of Birth
- Sex
- City of Birth
- Italian NIN (known as Codice Fiscale)
I’m not a legal expert, but I suppose those shouldn’t be included in the response.
Figure 14: API response with candidate's PII
It was possible to change the e-vote consent (after the actual vote), via the following PUT request to ‘/elettori-ms/protected/elettori/consenso-voto’:
Figure 15: Change consent to e-vote after the vote
It is unclear if the server actually accepted the change, but from the response we can assume so.
Finally, after digging more in the JavaScript files, we identified an additional microservice used by the e-voting system, which was:
• /admin-ms/
Figure 16: admin-ms microservice in the JavaScript file
Upon a simple unauthenticated request to the microservice, it seemed that it was blocked by Cloudfront:
Figure 17: Cloudfront 403 error message
The problem seemed to be the use of the word ‘admin’ in the request URL, so by simply URL-encode it, it was possible to get a different error message (401 Unauthorized), which highlighted that a valid Authorization token was needed to be able to interact with the /admin-ms/ microservice:
Figure 18: Cloudfront 403 bypass
Figure 19: Confirmation that URL-encoding worked
It was not possible to further investigate this endpoint without breaching the Computer Misuse Act (CMA), but I hope this simple bypass might be useful for the infosec community in case you’re presented with the same behaviour.
Conclusion
E-voting is nothing new, considering that Estonia first allowed its citizens to vote online back in 2005. To overcome some criticisms they implemented vote verification for individual voters in 2013, which is a simple method to enhance transparency and verifiability of the vote.
For this very first Italian e-vote test, the overall experience was flawless. From what we observed, without interfering much with the system, it seemed not be possible to tamper with the voting weight and counts. Only one vote allowed for each valid login.
I still have in mind some additional tests that could have been done to validate my assertion here but couldn’t because of potential legal consequences and the stability of the voting system itself. It would be great to have better transparency about the software supporting the e-voting system, maybe open sourcing its code would give better reassurances and could potentially help uncovering security vulnerabilities.
I hope these observations could be useful to anyone planning to work on an e-voting system. If you want to have a chat with us and test a product, get in touch.
