E-voting security: getting it right
Not cheap, but easier than we think
As we noted in our previous story - E-voting security: looking good on paper? - the much-celebrated voter verifiable paper trail is useless as a security measure for Direct Recording Electronic (DRE) election systems, and actually introduces far more problems than it solves.
What to fix
The chief problems encountered with the machines in real-world use have resulted from myriad sloppy - indeed shady - security practices by the vendors, certification authorities, and election supervisors. For example, there are some DRE machines with the capacity for remote connections, through which vendors have downloaded software patches after the machines have been tested and certified.
Connecting printers to these poorly secured machines is fixing the wrong thing. However, there's no shortage of other things that do, in fact, need fixing. For example, there are inadequate physical security protocols, with vendor representatives and service personnel installing software patches and swapping out hardware after certification. The problem with DRE gear is that it's prone to tampering. Thus physical security is crucial, and must therefore be tightened considerably.
And the testing and certification authorities themselves are often private companies with financial ties to the vendors. This is intolerable: testing and certification should be handled by a government agency, funded by the vendors, but completely independent of them, in the manner of Las Vegas' many one-armed bandits. Furthermore, certification authorities must be in possession of the complete source code for all approved DRE-system software, including database software and even compilers.
How to fix it
Nevertheless, the paper trail remains security fool's gold, made popular merely because it's easily grasped. What's needed instead are commonsense security protocols to make e-voting systems resistant to tampering, to make it evident when tampering has occurred, and to make it possible to stage a reliable recount.
There are two avenues to mischief that need to be closed off: the individual DRE terminals and their software and hardware components, and the election database.
Hacking the terminal
Attacks could be mounted against DRE machines by the vendor, or a poll worker, or a group of skilled voters, but these would have to be done after testing and certification, or the glitch would become known at that time and the questionable machines would be pulled. So security here is really a matter of physically protecting the machines after adequate and independent testing and certification has been performed, which is not terribly difficult. This is because an attacker would need unsupervised physical access in order to tamper with the software or the hardware, and such access can easily be prevented with commonsense protocols.
Guarding against post-certification tampering would be a simple matter. First, as soon as certification is complete, checksums of all software components, compilers included, would be recorded, and then verified later, on election day before the machines are put to use. Any machine with the wrong checksums would be pulled.
Second, fragile seals would be placed so that no hardware component could be disconnected, removed, added, or serviced without breaking a seal. DRE machines without all of their original seals intact would be pulled.
Third, protocols would be established so that no one person would have unsupervised access to any machine after certification. The machines would be stored in a secure location with limited access, perhaps with two locks that cannot both be opened by a single person. Motion detectors and video surveillance would provide an extra layer of security.
There would also have to be sensible physical security protocols established for election day or the eve, when the machines are delivered to the polling places. However, this should not require much modification of existing schemes. After all, one of the simplest attacks against any sort of equipment would be vandalism or theft, by which means voters in a district favorable to one's opponent could be inconvenienced. So there actually are physical security protocols, although these would have to be reviewed and beefed-up as needed because DRE machines are vulnerable to tampering, whereas a punch-card table is not (you can't rig them to punch the wrong hole - only the voter can do that; but you can destroy or steal them, or steal the ballot cards, etc).
The DRE terminals must not have any capacity for remote connections. And they hardly need it: often, removable memory modules record the election results and are later removed and uploaded to a database via a separate device. This is a basically sound design, so long as physical access protocols are observed, and the upload device is also secured, that is, sealed after certification, stored securely, and unsealed only when used. At least two election supervisors should be present when the modules are removed and uploaded, and the chain of custody should be logged scrupulously and later verified.
Finally, it is crucial that there be an independent testing and certification authority, and that it be in possession of all source code, compilers and firmware, to verify that the equipment works properly, and to guard against vendor backdoors and default admin passwords, etc.
Simple protocols such as these would render most attacks after certification quite difficult, requiring the vendor, service personnel, and/or election officials and poll workers to cooperate. An attacker would have to work unobserved, or while observed only by co-conspirators. Technically speaking, an attack is not terribly difficult; but simple, commonsense security protocols and auditing are all that's needed to detect tampering and to make an attack very inconvenient.
As for a recount, this might be done using an internal hard drive as a backup medium instead of paper receipts. So long as the machines are tested thoroughly by an independent agency, certified and sealed, and so long as proper security protocols are observed, and the checksums are right and the seals are intact, there is no reason to doubt the hard drive backup if a memory module should fail. It's unlikely, though hardly impossible, that both would fail; but a paper printout provides no advantage in guarding against a recount failure, and introduces many disadvantages.
The whole enchilada
The elections database is another problem area where vendors and election officials alike have failed to institute adequate security protocols. And this problem is the greater concern. With DRE terminals, if security protocols fail or are violated, the damage will likely be limited to a handful of machines. But a malicious attack against a database could potentially upset millions of votes.
Again, security is primarily a matter of common sense. As with the terminals, it is crucial that an independent testing authority be in possession of all database and server source code, to ensure that the system is designed with proper security features and robust access controls, and to ensure that there are no vendor back doors or default admin passwords.
The database system should be configured to accept connections only from specific devices, or, if TCP/IP is used, specific IP addresses. All data exchanged must be encrypted. It should use proper access controls and cryptographically robust authentication methods: these vary considerably according to the design of the system so we won't cover them, but a database can be designed and configured for good security, just like any other system. Most importantly, all database activity should be logged, and the access logs and system logs should be audited before an election is certified.
An important issue is trust. Someone has got to administer the database, and this person can do a great deal of damage, either intentionally or accidentally, that might be difficult to detect. Thus it's important to limit access strictly, in order to keep the number of potential suspects to a minimum. It would be a good idea for there to be such a thing as a certified elections database administrator (DBA), a person who can demonstrate adequate knowledge of the system, adequate knowledge of security, and who hasn't got a criminal background involving, say, financial crimes or fraud. The 'independent certification authority' that we also need and haven't got could be given the responsibility of certifying elections DBAs, perhaps with a rigorous written examination and a background check.
There is enough political momentum behind touch screen voting to force it on pretty much all of us in the near future. It can't be stopped, so there have got to be standards. At present, there aren't any. The vendors can do whatever they can get away with. The chief problems are the lack of an independent, national certification authority, and the practice of allowing vendors, election officials, and contract service personnel to muck about with the systems after certification.
Below is a checklist of what needs to be done to make electronic voting fair, reliable, and secure:
- A truly independent national certification authority, in possession of the complete source code for all approved software, firmware, compilers, etc., must be established. This authority would be responsible for establishing the necessary security standards, and verifying compliance.
- No software or firmware for which the certification authority lacks full source code may be certified. All certified software must be cryptographically signed by the authority. Checksums must be verified on election day to expose software or firmware tampering. Any discrepancy, however minor, renders a machine or a database system unusable.
- Terminals must not be capable of accepting any sort of remote connection.
- There must be fragile seals, difficult to counterfeit and issued by an independent authority, put in place after testing and certification, to expose hardware tampering. Any failure, however minor, renders a machine unusable. The certification authority must establish protocols for quarantining and auditing a suspect or malfunctioning machine.
- Terminals should have an internal hard disk drive for tabulating votes, cryptographically protected and designed independent of the memory system, to serve as a backup device for recounts. The terminals must be capable of extensive access and system logging, and logs must be audited when a machine is suspect or malfunctions. A random sample of machines should also be audited thoroughly after every election.
- Data transferred from one device or component to another device or component, or over a network connection, must be protected cryptographically.
- There must be no vendor backdoors or default admin passwords to any component or device.
- There must be robust access controls for the database, full access and system logging and log auditing, supervised by an authority independent of the vendors and their service contractors. No election must be certified until auditing is complete.
- There must not be any unsupervised or unauthorized access to the machines or the database after certification. Evidence of unsupervised or unauthorized access renders a system unusable, unless it can be fully re-tested and re-certified before the election.
- If supervised access is necessary for maintenance or repairs, any machine or system affected must be re-tested, re-certified, and re-sealed, and all checksums must be verified. Machines may not be serviced during an election; they should be quarantined and later audited.
- Any alterations to hardware or software, however minor, after certification, render a machine or a database unusable until full re-testing and re-certification are carried out.
- Any breaches of physical security protocols or access protocols, however minor, after certification, render a machine or a database unusable until full re-testing and re-certification are carried out.
Quality elections don't come cheap
It isn't necessary for the vendors to re-design their equipment radically. Indeed, all that's needed is for the public to demand that they do what they do, only the right way. "Good enough" simply isn't good enough; the system has got to be right.
Basic security and common sense are all that's required. The DRE systems offer many real advantages in terms of preventing overvoting, minimizing undervoting, clearly recording voter intent, and offering handicapped access. They can improve the accuracy of election results dramatically, and extend voter franchise, so long as they're built right, certified right, and secured properly.
At the moment they're not, but they can be.
Doing it right will not be difficult, though it will be expensive, and the vendors will whine at demands that they make their systems reasonably secure. However, we shouldn't balk at a system that's expensive and good, considering what's at stake here. At the moment, the systems are expensive and lousy, which forms the basis of the vendors' profits. Under a proper regulatory regime, they will have to earn their money; they will have to work for it. They won't like it very much, but they'll get over it in time.
Surely the public deserves to vote on equipment that's at least as reliable as a video poker machine. ®
Thomas C Greene is the author of Computer Security for the Home and Small Office, a comprehensive guide to system hardening, malware protection, online anonymity, encryption, and data hygiene for Windows and Linux.
E-voting security: looking good on paper?
Dutch e-voting software goes open source
E-voting promises US election tragicomedy
California preps e-voting ban bill
Ireland to scrap e-voting plan
California set to reject Diebold e-voting machines
UK not ready for e-voting
Campaign calls for safe e-voting
Sponsored: Network DDoS protection