A few days ago I gave a lecture about innovation and one topic that came up was the security of e-voting. It is widely accepted by the security community that e-voting cannot be made secure enough, and yet existing literature on the topic seems to lack high level discussion on the basis for this assumption.
Following is my opinion on why reliable fully digital e-voting cannot be accomplished given its threat and security models.
It is largely accepted by the security community that electronic voting cannot be made secure enough. I am not even discussing Internet voting, where yet additional problems are involved, but just what is often referred to as DRE (direct-recording electronic) voting machines. Those are physical kiosk-like stations at polling sites that allow voters to submit their votes by clicking on the screen, and that record and transmit the votes electronically.
To the best of my knowledge, most if not all DRE voting systems that were ever seriously examined from the security perspective were found to be severely flawed, such as in the well-publicized case of Premier Election Solutions (formerly Diebold Election Systems). That said, I find it more interesting to discuss the conceptual flaws of DRE voting rather than particular flaws in particular products. The question we should try to answer is not “is this product secure", but it is rather “is there a chance for a secure-enough e-voting system?”
Two aspects of voting security
There are two categories of requirements from a voting system to make it considered trustworthy:
The system shall be robust (“secure”), and
The system shall be verifiable by the public.
Meeting the first requirement is “just” very hard. Meeting the second requirement is discouragingly challenging even at the conceptual level, as we will see below.
Making the DRE voting machine secure
It is very difficult to make a robust voting system, especially when one needs to take care not only of the polling station devices themselves, but also of the overall system including the back-end analysis, the communication security, and at least as importantly: the security of the supply chain of the voting machines and other devices. Supply chain security is critical. If voting devices are improperly guarded physically, then someone can easily hack them, or even replace them with modified versions. It has been done with ATMs, so it can certainly be done with DRE voting devices. Some hardware security controls can be deployed against this threat, such as code attestation (see below), but those components are also subject to supply chain security considerations of their own, and they cover us only against software alteration, not necessarily against hardware alterations.
The supply chain problem is just one problem; there are many more. But then again, the need to make the system secure does not make the e-voting problem unsolvable, as many people believe it is. Those security challenges resemble those of ATMs, and we are pretty much happy with the ATMs we have by now.
The main concern with electronic voting as a concept is not the security of the system, as it is the verifiability of the system. The vote collection and counting process is so critical to democracy that it cannot depend on the goodwill and skills of the DRE voting machines vendor employees. If the public cannot ascertain that the logic of vote collection and counting indeed works as advertised, then there is absolutely no reason for the public to agree to cast the fate of democracy on this opaque device. The paper ballot system we use today is dumb and simple, but this mechanical simplicity is what allows visibility to anyone who cares to inspect the process.
The problem of public scrutiny of code is a problem we already solve in the open source community. Technically, the public may be given access to the source code of the voting devices (and of the other components of the system). However, how can the voter assure that the code actually running in the DRE device on which he casts his vote is indeed the same code that has been made public and verified? The code that runs in practice has complete control over the screen and over any other interface of the machine. It follows that nothing that is reported by that machine can really be trusted. Integrity shall therefore be ascertained not through a statement of the examined machine, but rather “from underneath", i.e., using logic that is unaffected by the code that is being verified. It is difficult to come up with such an “underneath” reporting mechanism when all interaction between the human examiner and the machine that he needs to trust is controlled by that same possibly-flawed machine.
One technology that could come to the rescue is that of attested boot and code integrity. There are technologies incorporated into some micro-controller chips that can attest to a third party on the checksum of the code that the chip loads. The DRE voting device would be able to add a signature by that chip, on each vote, ascertaining that the correct software was loaded before the vote was cast. This may satisfy the “underneath” requirement above, because a modified running code will not be able to make the hardware chip cheat when reporting on what is running.
This approach is not perfect, though. For example, it is not entirely resistant to hardware tampering. A lot of the activity on the voting machine is related to peripherals that are not the processor, such as the touch screen. If the touch screen hardware is compromised to report different locations of the user touch points, then the security of the code itself does not help as it will get false information from the screen to start with. This problem of tampered hardware is very difficult to solve without physically securing the supply chain of the device and of all its components.
Also, when a chip attests on the code it runs, it attests using its identity and associated keys. Messing up with the supply chain of the chip or station may allow different keys to be introduced for verification, and consequently the acceptance of attestation by the wrong pieces of hardware.
The outcome is that while boot and code attestation technologies can help, they do not entirely eliminate the need for securing the supply chain.
It can be said that auditability is required in systems where security is suspected to be imperfect. The primary reason to have after-the-fact auditing capability is as a safety net against occasional glitches in the security of the system. Security tends to fail at times, and at those times one needs to be aware of the failure, and have the necessary information to revert the impact of that failure.
ATMs are secure, albeit not perfectly, and they are not verifiable by the public at all. However, ATMs are strong on auditability. Their operation leaves tracks in monetary records of the banking system. If an ATM is broken and spits out bills without charging anyone, inconsistencies in banking records will reveal this pretty soon.
DRE voting machines cannot be assumed to be perfectly secure, and they are subject to complex supply chain security requirements that are extremely difficult to meet, given their powerful potential adversaries. E-voting is therefore the last domain to afford improper auditability. Unfortunately, voting also requires anonymity, and combining anonymity with auditability in electronic records is not trivial, to say the least. This critical point is worth further explanation.
We trust the DRE voting machine to properly collect people’s votes, properly count them, and properly communicate them to a properly-operating back-end, leaving no room for even the most sophisticated opponent to infiltrate the process. This trust will occasionally fail, as explained earlier: systems are hard to be made entirely secure, and public verifiability is limited regardless of how hard we try. Consequently, auditability is a must; we must be able to carry out a recount if we suspect that something went wrong, or if our confidence in the system is limited. Unfortunately, when vote collection is done by a machine keeping a counter of voter clicks, there is no way for such a recount to take place. The clicks by authentic voters can never be reproduced. Looking at this situation from the reverse perspective: not being able to recount the votes in case of suspected fraud implies that security (also of the supply chain) is critical to a higher extent than to which we can actually build it.
The auditability issue is also the most significant difference between the security of e-voting and security of traditional paper ballot voting. Proponents of e-voting justifiably claim that whereas fraud against e-voting is possible, fraud against paper ballot voting is also possible and does occur from time to time. Therefore, we are not supposed to require a perfect solution to replace an already imperfect one. This is a valid statement in general, but just until we address verifiability and auditability. With paper ballots, the ballots are kept, people can witness their counting, and they can be recounted if needed.
We cannot blindly trust the secure operation of DRE voting devices, if members of the public cannot audit them and where security in general, and secure supply chain in particular, are so hard to get right. In situations of such high value (our democracy) at stake, combined with the inability to design enough security and assurances into the system, we must revert to auditability that will allow us to detect fraud and respond to it.
Unfortunately, it is conceptually impossible to achieve the necessary auditability in combination with another essential feature of elections, which is: anonymity, in a fully digital system. To keep votes anonymous, we need to give up their auditability after the fact, and rely on the DRE voting machine to properly count the votes as they are cast and to properly submit the results with zero oversight.
If an ATM is hacked on its supply chain or otherwise, only certain monetary damage is caused and the hack is discovered through the auditability means of the banking system. If a voting station is hacked, we may never find it out and our democracy is at risk.