Innovative Minds - On Point - One Group  

ISP Blog

07
Nov
2016

Voter Privacy vs. the Security of the Electronic Voting System

By:

As technology continues to permeate every facet of life, individuals are continuously faced with decisions that test the balance between convenience and privacy. One of those emerging decisions affects a cornerstone of democracy: voting. Voter privacy is of utmost concern when considering the voting systems that are used; especially in the United States where we utilize secret ballots. The benefit of the secret ballot is that it ensures that there is no undue pressure once the voter is voting and that there can be no retaliation against the voter for the vote they cast. As a fundamental principle, it is essential to ensure that no one can link the actual vote that is cast to the voter, but in practice this causes unique concerns that require addressing to implement an internet voting system.

Still a new technology, internet voting, and its functional implementation faces substantial barriers. Denial of service, advanced persistent threats, malware, insider attacks, compromised credentials, all of these threats faced by voting systems are not unique, they are threats encountered in all information systems. What is unique is that while many companies assume a certain amount of loss from fraud as part of doing business on-line, for voting systems, this is not an acceptable assumption. Vulnerabilities exposed in electronic systems can compromise democracy and wield considerable political power. Therefore, these threats need to be adequately addressed while still maintaining the privacy of the voter to ensure the confidentiality, integrity, and availability of the voting system.

The risks to internet voting include all of the dangers typically associated with on-line transactions. For those planning on voting by internet, a denial-of-service attack could be the difference between the opportunity to vote or not voting in the election. Likewise, a successful shell-injection attack, insider attack, client side injection, improper session handling, poor authentication and authorization, etc. leaves internet voting vulnerable to a loss of confidentiality or the essence of the secret ballot. These attacks could also lead to a loss of integrity with votes being changed or additional votes being added; for instance, false votes cast for individuals who registered themselves, but did not actually login to vote.

There are, of course, ways to mitigate these risks, but no system will be without vulnerabilities and thus there is an inherent risk to moving towards internet voting. Internet voting, though, is not a thing of the future as there are several countries and U.S. states that have begun to adopt internet voting. One such attempt came from D.C., the pilot test of Internet voting was deployed for public testing that was scheduled to run from September 28 through October 6, 2010 with the midterm election beginning October 11 or 12. The test was a spectacular failure of the internet voting system, and the results showed that the organization designing and operating the system was not security aware. [1]

By October 1 of the test period, the system had been broken into by a University of Michigan team, which among other attacks installed the University of Michigan fight song following a 15-second pause after users submitted their ballots. It only took the team 36 hours from the start of the test to take over the system by exploiting a shell-injection vulnerability. The attackers remained in control of the system for two business days before the Board of Elections and Ethics (BOEE) eventually halted the test on October 1.

Among the attacks the Michigan team was able to perpetrate, they had also changed ballots cast prior to their intrusion, rigged the system to alter subsequently cast ballots, and could violate voters’ secret ballot rights. The team was also able to gain control over the pilot projects network infrastructure as they used the default master password from the owner’s manuals, which had not been changed, for the routers and switches. This allowed the team to gain control of the infrastructure and obtain an alternative way to steal votes in a real election. A pair of security cameras in the BOEE data center were connected to the point system and were unprotected, as such the team was able to literally watch the system operators as well.

The team also found evidence of attempted break-ins that appeared to be from China and Iran. Since the attempts included trying to guess the network logins, the Michigan team changed the defaults (user: admin, password: admin).

The pilot project and subsequent open test of this project shows how easy it would be in a real election to gain control over the system if proper controls are not in place. The system was not properly audited or tested prior to the open test just before the voting period, nor was the system designed with the same security measures that many security organizations employ. For instance, the very fact that the network logins were never changed from the defaults shows that there was a complete lack of security considerations in the system.

Mitigating these risks requires a system that is thoroughly tested and meets internationally accepted standards, such as NIST Special Publication 800-53 rev. 4. Defining a set of critical controls that must be implemented will mitigate the risks involved with moving to on-line voting. These systems can be made to be secure, but the security must be carefully implemented by security professionals. There are already Federal Regulations that address the need for security in information systems and Federal Programs aimed at improving security in systems. The Federal Risk and Authorization Management Program (FedRAMP)[2], for example, addresses security for the cloud and provides a set of baseline requirements that systems must meet if they want to operate in the Federal marketspace.

The concern for voter privacy is still a challenge, even for secure systems. That’s because most audit techniques involve going through logs and determining who performed which tasks. In the case of voting, that would mean keeping detailed logs that include who specifically voted for which candidates. While this is ideal for a more secure application, it is far from ideal when considered against the need to have a secret ballot. Therefore, along with securing the system, it must also be designed to allow for anonymous votes.

Fortunately, there are already proposed solutions to this problem. One solution is that once the server receives a vote, it stores it securely until the time when all votes are counted and it stores sequentially in the order that they are cast. Whenever a vote is cast by the voter, the vote is encrypted with the public key of the electoral committee. Similarly, the votes can be decrypted with the Corresponding private key. So long as the votes are not decrypted prior to shuffling them, the privacy of the voters would be maintained. [3]

By following the best practices and designing systems that meet minimum baseline requirements that have already been established and proven to be effective, the security of on-line voting can be maintained. Internet voting may very well prove to be the future of democracy, but as evidenced by the DC example, it is not there yet. Internet voting solutions must be subject to public scrutiny and address the inherent security issues that threaten voter privacy and the integrity of the voting system if it will ever stand a chance at success.

Works Cited:

[1] B. Simons and D. Jones, “Internet Voting in the U.S.,” Communications of the ACM, vol. 55, no. 10, pp. 68-77, October 2012.
[2] www.FedRAMP.gov
[3] v. Kalaichelvi and R. Chandrasekaran, “Security Analysis and Issues in an Internet Voting: A Review,” International Journal of Advanced Research in Computer Science, vol. 2, no. 6, pp. 249-250, November – December 2011.

Samantha Dizor Carter

Samantha Dizor Carter is the FedRAMP Manager with MindPoint Group.She has over 11 years of auditing experience and over 4 years of risk management, security assessment of Third-Party Assessment Organizations (3PAOs) for GSA Federal Risk and Authorization Management Program (FedRAMP).Ms. Carter spearheaded MindPoint Group’s accreditation as a FedRAMP 3PAO, including an initial assessment with no findings.As FedRAMP Manager she has led multiple FedRAMP assessments including PowerTrain’s initial assessment and most recently Deloitte’s continuous monitoring assessment.
Categories: Application Security, Breach, Cyber Security, Encryption, Information Leakage, ISP Blog, National Security, Privacy and tagged ,
Share: