A Security Audit of the Random-Sample Elections SystemImplementation

Christopher D. Nguyen, University of Maryland, Baltimore County – cn1@umbc.eduUrooj Aqeel, University of Maryland, Baltimore County – uroo1@umbc.eduIrwin Reyes, John Hopkins University Applied Physics Laboratory – Irwin.Reyes@jhuapl.edu

Date of Submission: May 13, 2014

Contents

Executive Summary 4

1 Introduction 51.1 Random-Sample Elections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Scope and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Summary of Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7 About the Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Project Methodology 82.1 Project Review Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Adversarial Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Source Code Audit 103.1 Structure of the Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Introduction to the Random-Sample Election Implementation . . . . . . . . . . . . 103.3 A Brief Introduction to the Django Framework . . . . . . . . . . . . . . . . . . . 103.4 General Impressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5 Election Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5.2 Source Code Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.6 Audit Bulletin Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6.2 Source Code Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6.3 Source Code Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.6.4 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.7 Voter Bulletin Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7.2 Source Code Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7.3 Source Code Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7.4 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Recommendations 174.1 Adopt a Secure Software Development Process . . . . . . . . . . . . . . . . . . . 174.2 Specific Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Conclusion 195.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

References 20

Acknowledgments 21

A Review of E-Voting Systems 22A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22A.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2

A.2.1 Requirements for Voting Systems . . . . . . . . . . . . . . . . . . . . . . 22A.2.2 Security Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23A.2.3 Source Code Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23A.2.4 Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24A.2.5 Web Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . 24

A.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24A.3.1 Internet Voting Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 25A.3.2 Trust Establishment in Internet Voting Systems . . . . . . . . . . . . . . . 25A.3.3 Security Auditing of Internet Voting Implementations . . . . . . . . . . . . 26

A.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

B Acronyms and Abbreviations 28

3

Executive SummaryWe conducted a security audit of the Random-Sample Elections (RSE) system implementation toestablish an initial level of confidence and trust in the implementation and provide guidelines forfuture deployments. The scope of this audit included the Election Authority, the Audit BulletinBoard, and the Voter Bulletin Board; it did not include the Random Beacon. We identified threeprocess-related concerns, which we believe are critical. Since the development team does notcurrently employ one, we recommend the adoption of a secure software engineering process. Withrespect to the code, we recommend the developers integrate adequate logging and error-handlingand apply a coding standard to its code base. We discovered two critical vulnerabilities anddeveloped attack scenarios for each. The vulnerabilities include arbitrary file upload to the securebulletin boards and a vote casting denial-of-service attack against legitimate voters.

4

1. INTRODUCTIONWe conducted a security audit of the Random-Sample Elections [Chaum 2014] (RSE) systemimplementation developed by the RSE Research Board and development team. Our goal is todetermine whether the RSE system implementation is trustworthy based on a source code audit andvulnerability assessment.

1.1. Random-Sample ElectionsRandom-Sample Elections is a new end-to-end high-assurance (E2E) voting system. The foun-dation of the system is a well-known principle of statistics: an election run with a small randomsample of the electorate will almost certainly result in the same outcome as a traditional masselection.

The intention of RSE is to be another tool in the democracy toolbox. The RSE system brings withit a broad positive impact:

— increased voter confidence in election outcomes;— reduction of “improper influence” (e.g., vote buying and coercion) through the use of fake ballots;— reduction of voter fraud by having voter selection driven randomly as opposed to being voter-

driven;— bringing direct democracy in large voting populations where only representative forms of govern-

ment have been practical for most issues through the use of low-cost small sample elections;— increasing the utility of a vote by using smaller samples; and— increased voter turnout and voters efforts to inform themselves as an effect of increased vote

utility.

All of these qualities have the combined effect of increasing voter confidence in their owngovernance, which leads to higher participation. Together these create a self-reinforcing cycle.

The RSE Research Board developed an implementation of the RSE system, which is the subjectof this report. The system comprises four components: an Election Authority (EA), an AuditBulletin Board (ABB), a Voter Bulletin Board (VBB), and a public verifiable random bit sourcecalled the Random Beacon. These components work together, but are independent. The currentsystem has been implemented in C and Python [Foundation 2014]. At this time, the source codeand documentation are not public, but will be before public-use.

1.2. MotivationVoter confidence and acceptance of an election system depend on the systems and implementa-tions security guarantees of availability, voter privacy, and outcome integrity. While an electionsystem may be secure in design, an improper implementation can undermine the systems securityguarantees. This applies to the RSE system and implementation as well. A pragmatic voter bydefault should consider the implementation as untrusted. We can establish initial trust in theimplementation through an independent formal security audit of the implementation.

1.3. ObjectivesThis project aims to establish a formal security audit process for rooting initial trust in the RSEsystem implementation. This will enable the RSE development team and future auditors to takeadvantage of our work. This will consequently increase voter confidence in the RSE systemimplementation.

5

1.4. Scope and LimitationsIn this section, we define the project scope. We identify tasks as being included, excluded, orincidental. Incidental tasks are those that are not specifically included in scope, but neither are theyprecluded.

The scope of this review is narrow. It includes a source code audit of the EA, ABB, and VBBand a non-live penetration test of the ABB and VBB. We exclude the Random Beacon from scopeas it exists independently of the RSE system and its output is completely auditable.

We prioritized the components based on their function and the information each stores.

(1) The ABB and VBB are the highest priority because they store information linking the voters,the ballots, and the votes.

(2) The EA has second priority since it is the control component.(3) The Random Beacon is the lowest priority because its information is easy to audit and it is the

easiest component to exchange.

Framework vulnerability discovery is incidental in the course of this project.

The purpose of this review is to examine the system implementation. We assume the votingprotocol is secure. While this excludes analysis of the voting protocol from the project scope, weconsider the voting protocol implementation – including component communications – to be withinscope.

The implementation is currently in a prototype state. Consequently, we exclude the followingroutine tasks from the project scope:

— a review of the election system configuration; and— a comprehensive risk assessment of the overall software system.

1.5. Structure of the ReportThe report is divided into five chapters and an appendix.

(1) This chapter provides a high-level overview of the RSE system, the motivation for theimplementation audit, goals, project scope, and limitations.

(2) Chapter 2 provides our approach to this project, which includes methodology and any toolsused.

(3) Chapter 3 describes the RSE implementation architecture and the implementation’s softwaredependencies. This chapter includes the source code audit and findings.

(4) Chapter 4 details our recommendations to address the issues uncovered during the securityaudit.

(5) Chapter 5 concludes the report with an interpretation of our findings and explains subsequentwork to follow this report.

(6) Appendix A contains a review of existing remote voting systems and security audits of thosesystems.

6

1.6. Summary of FindingsThis report contains over 10 specific observations that could impact security. The most seriousattack involves transfer of malicious code from an attacker to an end-user’s system. The attackercan chain this attack with the vote code denial-of-service attack described in Section 3. Insecureconfiguration enables an attacker to modify the secure bulletin boards’ update logs. Overall, theRSE system implementation could be better. We consider the implementation’s complexity to below and anticipate it will increase as code is added and the system redesigned. Without sufficientdocumentation, security flaws will become harder to find.

1.7. About the AuditorsChristopher D. Nguyen. Mr. Nguyen has a Master of Science degree in Computer Scienceand Bachelor of Science degrees in Computer Science and Mathematics from UMBC. He has8 years of professional software engineering experience with a focus on software and systemsecurity. He has led 4 projects with teams of up to 6 members. Mr. Nguyen currently con-tributes to the Random-Sample Election implementation, specifically the verifiable randomnesscomponent.

Urooj Aqeel. Ms. Urooj Aqeel is pursuing her Bachelor of Science in Bioinformatics with aminor in Computer Science from UMBC. She has experience writing code in Java, Python, andPerl. She also has experience in data-analysis using MATLAB, R, and SAS. For this project,Ms. Urooj served as a collaborator, researcher, and analyst.

Irwin Reyes. Mr. Reyes has a Master of Science in Systems Engineering and a Bachelorof Science in Computer Engineering from the University of Virginia, with a research focuson modeling and simulation software and their use in systems analysis. He has 3 years ofprofessional software engineering experience in industry, currently working on systems modelsof various Navy platforms at the Johns Hopkins University Applied Physics Laboratory. Mr.Reyes contributed to this research effort as a developer and analyst.

7

2. PROJECT METHODOLOGYWe approached the source code audit from two perspectives: a project review perspective and anadversarial perspective. The primary purpose of the project review is to determine whether thedevelopment team is correctly applying industry-recommended secure system implementationprinciples. A secondary purpose is to discover potential vulnerabilities. To guide the project review,we followed standard checkpoints in the first four phases of the software engineering life-cycle:requirements, high-level and low-level design, implementation (code), and testing. The purpose ofthe adversarial perspective is to qualify the actual security of the implementation by discoveringreal vulnerabilities and developing proof-of-concepts that exploit these vulnerabilities. We appliedknown black hat security methods in our attempts to exploit the system implementation.

2.1. Project Review PerspectiveTo support the project review perspective, we performed the following tasks.

(1) Reviewed project documentation for users, developers, and auditors.(2) Performed a code review focusing on adherence to language standards and project coding stan-

dards.(3) Performed a secure coding review focusing on common problems identified by HP Enterprise

Security [Fortify Software 2014] and OWASP [Project 2014].(4) Analyzed the results of the previous activities and produced recommendations.

In reviewing the project documentation, we sought to answer the following questions.

— Does the implementation have formal documentation for software requirements, high-level andlow-level design including interface descriptions, code documentation, and test plans?

— Do the software requirements fully address the functional requirements and security requirementsof the RSE system?

— Does the implementation adopt a modular design with well-specified module interfaces?— Does each requirement trace to a specific test in the plan?

Though this is a subjective question, we also assessed and opined on the implementation design.Together, project documentation and code reviews enable auditor to assess the functional correct-ness of the software.

It is possible for software to be functionally correct, but insecure. In extreme cases for example,the system requirements can fail to mention security. Secure coding reviews enhance the normalcode review by restricting scope to focus only on security-related issues. In our secure coding re-view, we addressed several common root causes of vulnerabilities.

— Input validation along both trust boundaries and module boundaries.— Improper coupling of software modules or API abuse.— Improper error handling.— Improperly implemented security features (e.g., authentication and cryptography).— Concurrency violations.— Code quality including coding style, redundant code, dead code, memory misuse, resource mis-

management, invalid references, portability flaws, undefined behavior, and signedness and typemismatches.

2.2. Adversarial PerspectiveIn approaching the adversarial perspective, we attempted to exploit the system. We consideredtwo types of attackers: an external user and a compromised RSE component. The goal of theseadversaries is to compromise the information managed by one of the uncompromised RSEcomponents. Since the RSE system will eventually be open-source, we assumed the adversary has

8

access to the source code. Though an unusual assumption, we restricted the adversary’s attackvectors to the RSE software proper and assume the host system and third-party software functionas intended.

Acting as the adversary, we applied an information flow tracking method between the data andstorage locations of interest and the software component trust boundaries. We consider this methodas having the following steps.

(1) Assume the software component under inspection is trusted and consider all external softwarecomponents as untrusted.

(2) Identify information and storage locations of interest. These are data or contain data the adver-sary seeks to disclose and/or modify.

(3) Identify operations that access information or storage locations of interest.(4) Identify operations that modify information of interest.(5) Trace the program execution from the information and storage locations of interest through the

access and modification operations to input/output boundary of the software component underinspection.

We were able to perform this manually due to the simplicity of the program logic.

2.3. ToolsIt is typical to apply static analysis tools after making an initial assessment based on manualinspection. Static analysis tools based on formal methods typically include model checking andinformation flow analysis at a minimum. The automated information flow analysis reduces the levelof effort needed to apply information flow tracking to higher-complexity programs.

We did not apply static analysis tools to the software under inspection. The Election Authority iswritten in C. Though several static analysis tools exist for C programs, we decided automated toolswere not necessary based on the initial assessment. The Audit Bulletin Board and Voter BulletinBoards are written in Python [Foundation 2014] and built upon the Django framework [Django2014]. At the time this report was written, the only reliable static analysis tool for Python programsis Pylint [Pylint 2014]. Pylint does not currently support Django applications.

9

3. SOURCE CODE AUDIT3.1. Structure of the AuditThe system source code audit consists of two parts. The first part is an introduction to the RSEimplementation where we describe the system architecture and how the components interact andcommunicate. The second part addresses each system component separately guided by the processdescribed in Section 2.

Our findings are current with the following code repository revisions:

— Election Authority: 2014-03-24 (93a49fa76d);— Audit Bulletin Board: 2014-03-27 (12e8a15c0d); and— Voter Bulletin Board: 2014-03-27 (34982b306c).

This version of the Election Authority depends on the OpenSSL library. This version of the AuditBulletin Board and Voter Bulletin Board depends on version 1.6.3+ of the Django framework forPython 2.7. The UpDownloader support utility depends on version 2.0.1+ of the requests module.We reiterate these dependencies are incidentally within scope of this audit.

3.2. Introduction to the Random-Sample Election ImplementationThe RSE implementation is a system with four components: the Election Authority (EA), theAudit Bulletin Board (ABB), the Voter Bulletin Board (VBB), and the public verifiable random bitsource (Random Beacon). The implementation features a modular design where each componentis independent. The election definition determines which component implementations are usedwith each election. This means component implementations are interchangeable provided theimplementation conforms to the component interface. Components can participate in multipleelections concurrently based on the election definition.

With respect to component interactions, the EA is the only active component whereas theother components are passive. The EA drives the system by pulling/pushing information from/tothe ABB and the VBB and by drawing random bits from the Random Beacon. The componentsuse specially formatted comma-separated value (CSV) files and archive files to communicateinformation between each other.

The components communicate over encrypted channels, with the implementation under reviewusing SSL. The system achieves data and communications integrity through digital signatures andwide public access to the bulletin boards. Combined with the independence of the bulletin boardsfrom the EA, this provides two system security properties.

Separation of Duties:. The duties of the bulletin boards and EAs are not only logically sepa-rated as described in Chaum [Chaum 2014], but physically separated.Data Integrity:. Even a corrupt EA implementation cannot modify the data nor votes unde-tected as it lacks physical access to the bulletin board databases.

The EA is an application written in C. The ABB and VBB are Django applications written inPython. Though not under analysis, the Random Beacon in use is also a Django application writtenin Python.

3.3. A Brief Introduction to the Django FrameworkReaders familiar with the Django framework may skip this section. The Django framework providesmany development and security features. Most applications use the following subset of developmentfeatures:

10

— object-relational mapping (ORM) engine,— administrator control panel,— web form serialization and validation,— template language,— REST framework,— URL dispatcher, and— unit test framework.

The first six features together form an instance of the model-view-controller (MVC) design pattern.The framework also provides protection against cross-site scripting (XSS), cross-site requestforgery (CSRF), SQL injection, transport layer security, and user/permission management.

The ORM uses Python classes to model relational database tables and Python objects to modeltable records and interact with the database. The ORM supports and enforces familiar relationaldatabase constructs such as primary keys, foreign keys, constraints, and indices. The ORM modelis stored in the application’s models.py file. The administrator control panel (admin.py andforms.py) exposes a customizable web-enabled view of the database with configurable read-onlyand write privileges.

The control and view logic is stored in the views.py file. Users interact with the applicationvia a RESTful interface (i.e., parameterized URLs). The URL dispatcher parses the URL and routesthe request to the proper functionality. The view in-turn provides output to the user.

Through its design, the Django framework coerces application developers to use a prescribedsource code organization strategy and creates a uniform appearance across Django applications.This can mislead source code auditors into mistaking a prototype-grade application as production-grade.

3.4. General ImpressionsBased on its current state, the software is still in a prototype state. We believe extensive workwill be necessary to bring the implementation software to a production-ready state. Priority itemsinclude formal documentation, automated verification suites, and code refactoring.

3.4.1. DocumentationEach component in the RSE system includes three varieties of documentation: user documentation,developer documentation, and auditor documentation.

The developer documentation is generated from tagged comments in the source code. With thecurrent revision, the documentation is a work in progress. The software currently lacks typicalsoftware engineering artifacts such as requirements specifications, design documentation, datadefinition and interface documentation, and test plans.

The project hosts the auditor documentation in an invite-only online wiki. The intent of theauditor documentation is to assist in the development of auditing software. The documentationincludes details on how each component communicates with the rest of the system. An assessmentof the auditor documentation content is beyond the scope of this project.

11

3.5. Election AuthorityThe EA component software drives the entire election process. It performs the following tasks in nospecific order:

— Creates the election definition and communicates it to the ABB and VBB.— Commits to the pre-draw tables and post-draw tables and communicates them to the ABB.— Transmits the vote codes to the VBB.— Pulls the random bits from the random beacon during the initial and final draws and communi-

cates these bits to the ABB.— Instructs the VBB to start and stop accepting votes from voters.— Pulls the votes from the VBB and transmits the tally to the ABB.

3.5.1. DocumentationThe user documentation is stored in an online wiki. It is incomplete in that it explains how touse the system to run a pre-configured election. It does not explain voter roster setup nor electionconfiguration.

The EA lacks the software engineering artifacts previously mentioned. However, though notexplicitly documented, the EA follows a procedural design paradigm based on the RSE pro-posal [Chaum 2014]. There is low-level documentation for each source file and 24 out of the 45functions defined. Table I lists the functions currently without low-level documentation. The codeincludes brief inline comments.

Table I. List of Election Authority functions without low-level documenta-tion.

ElectionAuthority.c publishPublicEntropy1publishPublicEntropy2

Entropy.c Entropy setupPublicEntropyEntropy closePublicEntropyEntropy setupPublicEntropyNew

Tables.c readRosterallocateTablesfreeTablesfillCommitDatafillTablesAfillTablesBfillTableThirdsumgetVbbAndFillTablescomputeTallypublishAbbPrepareApublishAbbPrepareBpublishAbbFinalizecomputePartitionpublishAbbAuditpublishVbbVotecodeprintBallotForms

3.5.2. Source Code QualityThe EA source is moderately complex at approximately 4,000 lines spread across ten C files. TheEA source code carries several indicators of prototype quality code.

— The code relies on magic constants and hard-coded values to operate. Examples includes thevoter roster size, the number of ballot choices, the data file names, buffer sizes, and table columnidentifiers.

12

— The software lacks of proper error handling and logging facilities.— The software invokes shell scripts without verifying the scripts’ integrity prior to execution.— The code is not written to be modular (e.g., cryptography modules and entropy modules). Fur-

thermore, interface documentation is absent.— The low-level documentation is only half completed at this time.

We feel the comments within the source code do not communicate the intent of the code well.Since the EA lacks a requirements specification to communicate this intent, we are unable tovalidate the EA implementation. Furthermore, due to the complexity of the code and the EA’sfunctionality, we are unable to draw a conclusion regarding the actual security of the EA’s imple-mentation. However, given the previously mentioned issues, we consider the EA implementation tobe potentially insecure and hence untrustworthy at this time.

3.6. Audit Bulletin BoardThe ABB software is built on top of the Django framework. The EA can upload election informationto the ABB. Auditors can view and download the auditing views allowed by RSE protocol.

3.6.1. DocumentationThe ABB currently does not have user documentation for the application itself. It does not comewith configuration instructions for running an election.

The ABB comes with a Python script utility to facilitate communication from the EA to theABB. The README file accompanying the utility describes utility usage instructions. We considerthis to be developer documentation since the EA software invokes the script utility and not theend-user.

3.6.2. Source Code QualityThe ABB source is of low complexity at approximately 800 lines spread across five files. Thesource is of low complexity because much of the structure is automatically generated by the Djangoframework. Ignoring the code organization enforced by the Django framework, we consider theABB to be prototype-grade due to several indicators in the control and view logic.

— High-level functions do not properly separate concerns (e.g., perform both reads and writes, butnot in the same invocation).

— High-level functionality does not abstract low-level functionality into functions and procedures.— High-level functions are lengthy and insufficient line breaks and white-space to help distinguish

separate code blocks decreases readability.— The code relies on magic constants and hard-coded values to operate. This includes table sizes,

operation names, and file names.— The software lacks of proper error handling and logging facilities.— The software has sparse developer documentation.

We conjecture many of these issues were influenced by the Django design paradigm. The design ofthe URL dispatcher appears to have driven the implementation rather than the functionality.

The commenting style focuses on how individual lines or code blocks work, but not on the intentof the code. When combined with lengthy functions and short non-descriptive variable naming,the ABB code is hard to follow. Furthermore, since the ABB currently lacks a requirementsspecification, the intent of the code is not clear either.

13

3.6.3. Source Code ContentAt this time, the deployment configuration is set to debug mode. We expect release deploymentswill have debug features disabled and hosted on properly configured production web servers insteadof the Django development server.

The administrator interface to the ABB exposes no database fields as read-only and exposes somefields as writable. The exposed modifiable fields include

— table column key plaintext, commitments, and decommitments;— data plaintext and ciphertext;— the random bit sequences;— the information update log; and— election question and time-frame information.

The RSE protocol provides integrity guarantees to some of these fields (e.g., table commitments)and corruption of these fields is an inconvenience at worst. Other fields (e.g., information updatelog) not explicitly described by the RSE protocol are sensitive to modification. As one example, anadversary could rewrite the election audit trail.

The URL dispatcher setup for the ABB is strict. We found no errors in its design and implemen-tation.

The control and view logic defines three operations: data export, a user view, and data upload.The data export functionality creates an archive containing a data dump of the specified election.The user view presents the same data as the data export, but formatted with the user experience inmind. We found no security concerns with respect to these two operations.

The ABB receives a pre-defined zip archive as part of its data upload functionality. The ABBwill record any zip archive matching this structure in its update information log even if the ABBultimately rejects processing the contents. Since the ABB performs no further verification, it ispossible for an adversary to store malicious code on the ABB and transfer it to a user during thedata export operation.

The upload functionality has a CSRF exemption. The purpose of the exemption is to allowthe Django framework to execute code that is incompatible with CSRF protection. However, theDjango manual recommends re-enabling CSRF protection upon execution of the incompatible code.The ABB upload functionality does not invoke incompatible code and the exemption is unnecessary.

Though not a vulnerability, we noted the Ctuple class defined in the ABB view file uses adeprecated form of class declaration.

3.6.4. AssessmentAt this time, the ABB does not implement the signature scheme necessary to ensure data integrity.As this was known, we do not consider it for this assessment. The ABB properly exports itsdata, but does not securely import data. It performs insufficient input validation, which allows anadversary to store and transfer malicious code. While it is possible to enforce data validation usingthe Django ORM, the ABB fails to take advantage of it. Hence for now, we consider the ABB to beuntrusted.

14

3.7. Voter Bulletin BoardThe VBB software is built on the Django framework. The EA can upload/download ballots betweenitself and the VBB. The EA also can command the VBB to start/stop an election. Voters can submitand confirm their vote using the VBB.

3.7.1. DocumentationThe VBB currently does not have user documentation for the application itself. It does not comewith configuration instructions for running an election. The VBB comes with the same Pythonscript utility and documentation provided with the ABB.

3.7.2. Source Code QualityThe VBB source is of low complexity at approximately 660 lines spread across six files. The sourceis of low complexity because much of the structure is automatically generated by the Django frame-work. Ignoring the code organization enforced by the Django framework, we consider the VBB tobe prototype-grade due to several indicators in the control and view logic.

— High-level functions do not properly separate concerns (e.g., perform both reads and writes, butnot in the same invocation).

— High-level functionality does not abstract low-level functionality into functions and procedures.— High-level functions are lengthy and insufficient line breaks and white-space to help distinguish

separate code blocks decreases readability.— The code relies on magic constants and hard-coded values to operate. This includes table sizes,

operation names, and file names.— The software lacks of proper error handling and logging facilities.— The software has sparse developer documentation.

We conjecture many of these issues were influenced by the Django design paradigm. The design ofthe URL dispatcher appears to have driven the implementation rather than the functionality.

The commenting style focuses on how individual lines or code blocks work, but not the intent ofthe code. The VBB code is hard to follow for the same reasons as the ABB. Due the limited scopeof the VBB’s functionality, however, the intent of the code is easier to ascertain.

3.7.3. Source Code ContentAt this time, the deployment configuration is set to debug mode. We expect release deploymentswill have debug features disabled and hosted on properly configured production web servers insteadof the Django development server.

The administrator interface to the VBB exposes no database fields as read-only and exposes somefields as writable. The exposed modifiable fields include

— ballot serial numbers and vote codes;— vote records and tallies;— ballots marked for election audits;— the information update log; and— election question and time-frame information.

Like the ABB, modifications to these fields can range from inconvenience to catastrophic.

15

The URL dispatcher setup for the VBB is strict. We found no errors in its design and implemen-tation.

The control and view logic defines three operations: data export, a user view, and data upload.The data export functionality creates an archive containing a signed data dump of the specifiedelection’s ballots, vote codes, and votes. The user view performs four functions: vote submission,vote submission validation, ballot check confirmation, and a formatted view of the export data. Wefound no security concerns with respect to the data export and read-only view functionalities.

The vote submission correctly accepts and validates the vote codes prior to casting the vote. TheVBB employs a ballot confirmation check to deter brute-forcing the serial numbers and vote codes,however there are two flaws. First, the VBB does not log brute-force attempts, which preventsidentification of attacks. Second, the VBB does not ensure the user passes the ballot check prior tocasting the vote. Since the VBB does not permit ballots to be voted twice, an adversary can preventa voter from casting their ballot. Due to ballot confirmation check, an audit can reveal the impropervote with high certainty but not the identity of the adversary.

The VBB receives a pre-defined zip archive as part of its data upload functionality. The VBB’supload functionality contains the same arbitrary storage and transfer flaw as the ABB.

The upload functionality also has a CSRF exemption. As with the ABB, the VBB uploadfunctionality does not invoke incompatible code and the exemption is unnecessary.

3.7.4. AssessmentAt this time, the VBB does not implement the signature scheme necessary to ensure data integrity.As this was known, we do not consider it for this assessment. The VBB properly exports itsdata, but does not securely import data. It performs insufficient input validation, which allows anadversary to store and transfer malicious code. While it is possible to enforce data validation usingthe Django ORM, the VBB fails to take advantage of it. Hence for now, we consider the VBB to beuntrusted.

16

4. RECOMMENDATIONSIn Section 3, we identified several bugs. Some of these bugs are benign, but for others we proposedpotential vulnerabilities and attacks. In this section, we aggregate the issues and provide specificrecommendations to address them. A pervasive theme through these recommendations is adoptionof a secure software engineering process as a preventative measure.

4.1. Adopt a Secure Software Development ProcessMany of the issues identified stem from insufficient specification of software requirements andlow source code quality. To properly validate the system software, we recommend production of arequirements specification, a test plan and test cases to validate the requirements, and a traceabilitymatrix to ensure requirement has a test associated with it. Tests may exist as documentation and/orautomated test scripts.

To ensure high quality software, prior to coding, we recommend developing a solid modulardesign held together with documented interfaces. Furthermore, the design should be peer reviewed.For coding and implementation, we have four high-level recommendations:

— Use high-level programming languages for as much code as possible. Only performance-sensitivecode should employ a low-level programming language such as C.

— Employ a documented coding standard for all software development. Strict adherence not onlyincreases readability and maintainability, but encourages developers to reflect on their code andmakes it easier to identify bugs during development.

— Write informative comments that explain the intent of the developer, instead of comments thatdescribe what individual lines of code do. As an example, an informative comment might de-scribe how an entire algorithm works, whereas the procedure may contain descriptive commentsreferencing algorithm steps. Informative comments typically link back to the design.

— Use descriptive variables names. Much of the code uses short generic (usually single-character)variable names. Use of short variable names usually results in descriptive comments, which de-velopers should avoid.

— Employ a code review process to ensure that any changes have a second opinion. This shouldinclude a manual review as well as automated regression tests to ensure intentional and uninten-tional changes to the software’s behavior are acknowledged.

The documentation we described will assist future software reviews and audits.

4.2. Specific Security RecommendationsData consistency and validation are necessary properties of voting systems and the ABB and VBBattempt to ensure these properties explicitly through code, which is error-prone. Database systemsprovide mechanisms for formally expressing consistency and validation constraints. The Djangoframework exposes these mechanisms through the ORM engine. We recommend the ABB andVBB take advantage of the ORM engine to enforce data consistency and validation and verify thespecifications are sufficient through unit tests.

The Django administration interface provides web-enabled access to the database and itsrecords. Though the interface is configurable to limit the fields displayed and the ability to modifyrecords, the ABB and VBB currently exposes almost all fields as writable. We recommend harden-ing of the administrator interface design and disabling the administrator interface for production use.

The ABB and VBB stores and processes any file that passes its archive structure checks withoutfurther validation. As the ABB and VBB file formats are designed to be strict, yet human-readable,

17

we recommend adding additional file validation checks.

The ABB and VBB upload functionality are vulnerable to CSRF attacks. Although the uploadfeature uses alternative authentication (i.e., digital signatures), reducing the scope of the exemptionadds assurance and protects future modifications to the upload functionality. We recommendsplitting the upload functionality into two part: one with the CSRF exemption and the rest withCSRF protection enabled.

The VBB is vulnerable to a denial-of-service against voters because the VBB casts votes prior tovalidating the confirmation check, which is simple to remedy. Though not a fix, the VBB can deteradversaries from brute-forcing the vote codes by instituting a lock-out policy and/or performingadditional logging. The former is undesirable because an adversary could prevent legitimate votersfrom accessing the system entirely. We recommend only implementing the logging.

The RSE system implementation maintains insufficient logs. We recommend the EA maintainthree types of logs:

— Operational logs to record the progress of each component as it executes elections.— System error logs to log implementations errors that may occur during each election.— Security log to store suspected attack information, including when an EA enters an invalid pass-

word.

Developers should be cautious when implementing logging. Through aggregation, logged informa-tion can violate privacy requirements. Furthermore, proper logging usually is accompanied withproper error handling, which we mentioned in Section 3.

The EA invokes external scripts and executables as part of its operation. We recommend two fixesbe applied to the EA source code:

— ensure external programs are invoked through absolute paths to prevent environment manipula-tion, and

— ensure the EA verifies the integrity of the external programs prior to invocation.

18

5. CONCLUSIONThis audit identified several weaknesses in the software development process and implementation,documented potential vulnerabilities, and drafted hypothetical attacks for these vulnerabilities. Wefound the EA, ABB, and VBB each contained insecure code and/or vulnerabilities. While this maybe a side-effect of our finding that the code is research-grade, we consider each component of theimplementation to be insecure.

Many of the issues discovered are preventable through the adoption of a secure softwareengineering process covering requirements, design, testing, and peer review and the adoptionof a documented coding standard. Since the code is research-grade, we believe a rewrite of theimplementation using a secure development process would be more effective than attempts to patchthe existing code base. The specific recommendations listed in Section 4 therefore should serve asa guide for future development.

5.1. Future WorkAlthough this report explains potential attack scenarios, live exploits were not developed as part ofthis project. Live exploits are interesting because from a security perspective they are successfulattacks, but under an engineering perspective they are failed tests. Future work should includeimplementing the attacks described in this report and transforming the live exploits into test cases.

The software under inspection is still under development. We imagine this audit’s resultswill become obsolete shortly following submission to the RSE Research Board. We predict thecode base will change substantially between this version and the production-ready version. Werecommend another audit be performed prior to the release of the production-ready version.

It is our belief that the RSE system is a provably secure end-to-end voting system and we wouldtrust the outcome of an election run with it. However, an incorrect implementation underminesthe guarantees of the system. Though the implementation as it exists today is not ready for realelection, we believe the implementation will eventually reach that point.

19

REFERENCESBen Adida. 2008. Helios: Web-based Open-audit Voting. In Proceedings of the 17th Conference on Security Symposium

(SS’08). USENIX Association, Berkeley, CA, USA, 335–348. http://dl.acm.org/citation.cfm?id=1496711.1496734Ben Adida, Olivier de Marneffe, and Olivier Pereira. 2014. Helios Source Code. (March 2014). https://github.com/benadida/

helios-serverRoss J. Anderson. 2008. System Evaluation and Assurance (2 ed.). Wiley Publishing, Chapter 26.Tor E. Bjorstad. 2013. Source Code Audit of Norwegian Electronic Voting System. Technical Report. Mnemonic, Oslo, Nor-

way. http://www.regjeringen.no/upload/KRD/Prosjekter/e-valg/kildekode/eValg Rapport Kildekodegjennomgang.pdfB. Carlsson and D. Baca. 2005. Software security analysis - execution phase audit. In Software

Engineering and Advanced Applications, 2005. 31st EUROMICRO Conference on. 240–247.DOI:http://dx.doi.org/10.1109/EUROMICRO.2005.53

David Chaum. 2014. Random-Sample Elections: Far Lower Cost, Better Quality and More Democratic. (March 2014).http://rs-elections.com/Random-SampleElections.pdf

David Chaum, Richard Carback, Jeremy Clark, Aleksander Essex, Stefan Popoveniuc, Ronald L. Rivest, Peter Y. A. Ryan,Emily Shen, and Alan T. Sherman. 2008. Scantegrity II: End-to-end Verifiability for Optical Scan Election SystemsUsing Invisible Ink Confirmation Codes. In Proceedings of the Conference on Electronic Voting Technology (EVT’08).USENIX Association, Berkeley, CA, USA, Article 14, 13 pages. http://dl.acm.org/citation.cfm?id=1496739.1496753

Brian Chess and Gary McGraw. 2004. Static Analysis for Security. IEEE Security & Privacy 2, 6 (2004), 76–79.DOI:http://dx.doi.org/10.1109/MSP.2004.111

Jeremy Clark and Urs Hengartner. 2012. Selections: Internet Voting with Over-the-shoulder Coercion-resistance. In Pro-ceedings of the 15th International Conference on Financial Cryptography and Data Security (FC’11). Springer-Verlag,Berlin, Heidelberg, 47–61. DOI:http://dx.doi.org/10.1007/978-3-642-27576-0 4

The Estonian Electronic Voting Committee. 2014. Estonian E-Voting Source Code. (March 2014). https://github.com/vvk-ehk/evalimine

Common Criteria Recognition Arrangement 2014. Common Criteria v3.1. Release 4. (March 2014). http://www.commoncriteriaportal.org/cc/

Django 2014. Django. (March 2014). https://djangoproject.comM. Dowd, J. McDonald, and J. Schuh. 2007. C Language Issues. Addison Wesley Professional, Chapter 6.lfar Erlingsson. 2007. Low-Level Software Security: Attacks and Defenses. In Foundations of Security Analysis and Design

IV, Alessandro Aldini and Roberto Gorrieri (Eds.). Lecture Notes in Computer Science, Vol. 4677. Springer BerlinHeidelberg, 92–134. DOI:http://dx.doi.org/10.1007/978-3-540-74810-6 4

Saghar Estehghari and Yvo Desmedt. 2010. Exploiting the Client Vulnerabilities in Internet E-voting Systems: Hack-ing Helios 2.0 As an Example. In Proceedings of the 2010 International Conference on Electronic Voting Tech-nology/Workshop on Trustworthy Elections (EVT/WOTE’10). USENIX Association, Berkeley, CA, USA, 1–9. http://dl.acm.org/citation.cfm?id=1924892.1924899

Cyrus Farivar. 2014. Estonia Publishes its E-Voting Source Code on GitHub. (March 2014). http://arstechnica.com/tech-policy/2013/07/estonia-publishes-its-e-voting-source-code-on-github/

Russell A. Fink, Alan T. Sherman, and Richard Carback. 2009. TPM Meets DRE: Reducing the Trust Basefor Electronic Voting Using Trusted Platform Modules. Trans. Info. For. Sec. 4, 4 (Dec. 2009), 628–637.DOI:http://dx.doi.org/10.1109/TIFS.2009.2034900

Fortify Software 2013. Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors. (2013). http://www.hpenterprisesecurity.com/vulncat/en/docs/Fortify TaxonomyofSoftwareSecurityErrors.pdf

Fortify Software 2014. A Taxonomy of Coding Errors That Affect Security, Fortify Software. (2014). http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html

Python Software Foundation. 2014. Python Language Reference, version 2.7. (March 2014). http://www.python.orgKristian Gjsteen. 2012. The Norwegian Internet Voting Protocol. In E-Voting and Identity, Aggelos Kiayias and

Helger Lipmaa (Eds.). Lecture Notes in Computer Science, Vol. 7187. Springer Berlin Heidelberg, 1–18.DOI:http://dx.doi.org/10.1007/978-3-642-32747-6 1

Sven Heiberg, Peeter Laud, and Jan Willemson. 2012. The Application of I-Voting for Estonian Parliamentary Elections of2011. In E-Voting and Identity, Aggelos Kiayias and Helger Lipmaa (Eds.). Lecture Notes in Computer Science, Vol.7187. Springer Berlin Heidelberg, 208–223. DOI:http://dx.doi.org/10.1007/978-3-642-32747-6 13

Mario Heiderich, Tilman Frosch, Marcus Niemietz, and Jorg Schwenk. 2012. The Bug That Made Me Pres-ident a Browser- and Web-security Case Study on Helios Voting. In Proceedings of the Third In-ternational Conference on E-Voting and Identity (VoteID’11). Springer-Verlag, Berlin, Heidelberg, 89–103.DOI:http://dx.doi.org/10.1007/978-3-642-32747-6 6

Helios 2014. Helios Documentation. (March 2014). http://documentation.heliosvoting.org/Java Programming Language 2014. Java Programming Language. (March 2014). http://www.oracle.com/java/

20

Douglas W. Jones and Barbara Simons. 2012. Center for the Study of Language and Information, Stanford, CA, USA,Chapter 1.

Miroslaw Kutylowski and Filip Zagorski. 2010. Towards Trustworthy Elections. Springer-Verlag, Berlin, Heidelberg, Chap-ter Scratch, Click & Vote: E2e Voting over the Internet, 343–356. http://dl.acm.org/citation.cfm?id=2167913.2167934

Metasploit 2014. metasploit. (March 2014). http://www.metasploit.com/Norway Ministry of Local Governance and Regional Development 2014. Norwegian E-vote Trial Web-

site. (March 2014). http://www.regjeringen.no/nb/dep/kmd/prosjekter/e-valg-2011-prosjektet/kildekode/tekniske-dokumenter-om-e-valglosningen.html

The Norwegian Ministry of Local Government, Regional Development, and Scytl Secure Electronic Voting SA. 2014. HeliosSource Code. (March 2014). https://sourcecode.valg.no/websvn/listing.php?repname=Internettstemmegivning

Thea Peacock, Peter Y. A. Ryan, Steve Schneider, and Zhe Xia. 2013. Verifiable Voting Systems. In Computer and Infor-mation Security Handbook, Second Edition (2nd ed.), John R. Vacca (Ed.). Morgan Kaufmann Publishers Inc., SanFrancisco, CA, USA, Chapter 69.

OWASP Code Review Project. 2014. OWASP Code Review Guide v1.1. (March 2014). https://www.owasp.org/index.php/OWASP Code Review Guide Table of Contents

Pylint 2014. Pylint – code analysis for Python. (March 2014). http://www.pylint.orgMarco Ramilli and Marco Prandini. 2010. An Integrated Application of Security Testing Methodologies to e-voting Systems.

In Electronic Participation, Efthimios Tambouris, Ann Macintosh, and Olivier Glassey (Eds.). Lecture Notes in Com-puter Science, Vol. 6229. Springer Berlin Heidelberg, 225–236. DOI:http://dx.doi.org/10.1007/978-3-642-15158-3 19

Scytl Secure Electronic Voting SA. 2013. Audit Technical Report – Sctyl Clarifications. Technical Report. Scytl Secure Elec-tronic Voting SA, Barcelona, Spain. http://www.regjeringen.no/pages/13809588/Norway2013-AuditingReportReview.pdf

Suzanna Schmeelk, Bill Mills, and Leif Hedstrom. 2012. Standardizing Source Code Security Auditing. International Jour-nal of Software Engineering and Applications (2012).

G. Schryen and E. Rich. 2009. Security in Large-Scale Internet Elections: A Retrospective Analysis of Elections in Estonia,The Netherlands, and Switzerland. Information Forensics and Security, IEEE Transactions on 4, 4 (Dec 2009), 729–744.DOI:http://dx.doi.org/10.1109/TIFS.2009.2033230

Barbara Simons and Douglas W. Jones. 2012. Internet Voting in the U.S. Commun. ACM 55, 10 (Oct. 2012), 68–77.DOI:http://dx.doi.org/10.1145/2347736.2347754

Spring Project 2014. Spring Project. (March 2014). http://www.spring.ioOliver Spycher, Melanie Volkamer, and Reto Koenig. 2012. Transparency and Technical Measures to Establish Trust in Nor-

wegian Internet Voting. In E-Voting and Identity, Aggelos Kiayias and Helger Lipmaa (Eds.). Lecture Notes in ComputerScience, Vol. 7187. Springer Berlin Heidelberg, 19–35. DOI:http://dx.doi.org/10.1007/978-3-642-32747-6 2

Cynthia Sturton, Susmit Jha, Sanjit A. Seshia, and David Wagner. 2009. On Voting Machine Design for Verification andTestability. In Proceedings of the 16th ACM Conference on Computer and Communications Security (CCS ’09). ACM,New York, NY, USA, 463–476. DOI:http://dx.doi.org/10.1145/1653662.1653719

The PHP Group 2014. PHP: Hypertext Processor. (March 2014). http://www.php.netJohn R. Vacca. 2013. Computer and Information Security Handbook, Second Edition (2nd ed.). Morgan Kaufmann Publishers

Inc., San Francisco, CA, USA.Priit Vinkel. 2012. Internet Voting in Estonia. In Information Security Technology for Applications, Peeter

Laud (Ed.). Lecture Notes in Computer Science, Vol. 7161. Springer Berlin Heidelberg, 4–12.DOI:http://dx.doi.org/10.1007/978-3-642-29615-4 2

Melanie Volkamer, Oliver Spycher, and Eric Dubuis. 2011. Measures to Establish Trust in Internet Voting. In Proceedings ofthe 5th International Conference on Theory and Practice of Electronic Governance (ICEGOV ’11). ACM, New York,NY, USA, 1–10. DOI:http://dx.doi.org/10.1145/2072069.2072071

Filip Zagorski, Richard T. Carback, David Chaum, Jeremy Clark, Aleksander Essex, and Poorvi L. Vora. 2013. Remotegrity:Design and Use of an End-to-end Verifiable Remote Voting System. In Proceedings of the 11th International Con-ference on Applied Cryptography and Network Security (ACNS’13). Springer-Verlag, Berlin, Heidelberg, 441–457.DOI:http://dx.doi.org/10.1007/978-3-642-38980-1 28

Acknowledgments

ACKNOWLEDGMENTS

The authors would like to thank the Random-Sample Elections Research Board for providing their support including an-swering questions and providing a demonstration of the system implementation.

21

APPENDIXA. REVIEW OF E-VOTING SYSTEMSA.1. IntroductionRandom-Sample Elections (RSE) [Chaum 2014] is a new high-assurance end-to-end voting system.It is an additional tool in the democracy toolbox based on a well-known principle of statistics: anelection conducted with an appropriately sized random subset of the voting population will almostcertainly result in the same outcome as a traditional mass election. Voter confidence and acceptanceof an election system depend highly on the systems and implementations security guarantees.Hence, we believe organizations and governments will want RSE to meet the rigorous standards ofexisting systems before being used in binding elections.

Binding elections impose strict and seemingly conflicting security requirements on informationsystems used in their execution. In the following example mentioned in Jones and Simons [Jonesand Simons 2012], we describe two requirements that appear to be at odds. Voter confidentiality(i.e., the secret ballot) protects individual voters from coercion by separating information regardinga ballot’s contents from the identity of the voter who cast the ballot. Voter verifiability enablesindividual voters to check whether their vote was counted as the voter intended. The idea thata voter can verify their vote was counted without provably divulging the vote to another partyinitially appears contradictory. The existence of end-to-end voter verifiable (E2E) voting systemsdemonstrate these requirements are compatible [Peacock et al. 2013].

Although E2E voting systems are designed with security in mind, it is necessary to scrutinizetheir implementations to establish confidence that they function as designed. Additionally, the re-sulting tradeoffs must be understood and acceptable. Evaluating the security properties of a practicalE2E voting system necessitates a structured approach that defines the following: the scope of thesystem; a security assurance target (i.e., the likelihood that a system will fail in a particular fail-ure event); what failure states will be examined; how those states may be invoked or tested; andwhat evidence needs to be gathered to support whether or not the system meets the desired level ofassurance [Anderson 2008].

A.2. BackgroundIn this section we cover security audit processes and methods with respect to the unique require-ments placed on electronic voting systems such as RSE. To perform a successful audit of thesystem, we first need to understand these requirements. We then explore techniques relating to twosecurity audit processes: source code auditing and penetration testing.

A.2.1. Requirements for Voting SystemsBinding elections impose strict security and privacy requirements on systems used for them. Pea-cock, et al. [Peacock et al. 2013] and Jones and Simons [Jones and Simons 2012] describe severalrequirements, which we organize here.

(1) Voter Confidentiality(a) Ballot secrecy: Only the voter should know how he/she voted.(b) Receipt-freeness: A voter should not be able to prove her vote. This prevents vote buying.(c) Coercion resistance: A voting system is coercion resistant if the voter can vote the way she

wishes to, even while appearing to cooperate with the coercer.(2) Election Integrity

(a) Legitimacy: Only registered voters may vote.(b) Eligibility: A voter may vote at most once and all votes cast are genuine.(c) Individual verifiability: The voter should be able to check that his/her vote is accurately

recorded for tabulation.

22

(d) Universal verifiability: The final tally should be verifiable by any third party.(e) Accuracy (Integrity): The announced tally should reflect the true count of all legitimate,

cast votes.(3) System Availability

(a) Robustness: The system should be able to deliver the correct result even in the event ofcertain, suitably defined, levels of failure or corruption.

(b) Availability: Users should be able to access all features of a fully-functioning system duringthe election.

A.2.2. Security AuditingA security audit is a documented process for locating, verifying, recording, and resolving systemvulnerabilities. Several formal processes and standards exist. Some well-known international stan-dards include the Trusted Computer System Evaluation Criteria (Orange Book) and its replacement,the Common Criteria [Common Criteria Recognition Arrangement 2014]. These standards, likemany others, are general guidelines, abstract in their specification. They require adaptation to aparticular security audit instance.

Schmeelk, et al. [Schmeelk et al. 2012] consider security audits as having two phases: manualanalysis and automated analysis using auditing tools. The manual phase consists of four steps:

(1) background information collection;(2) defining the purpose and goals of the audit;(3) analysis of quantitative and qualitative code characteristics; and(4) exploration of attack surfaces.

Auditing tools can flag some potential vulnerabilities, but they must be tools designed to target thelanguage under analysis. The automated phase consists of four steps.

(1) Formal methods: mathematical techniques for verifying a program satisfies its formal specifi-cation.

(2) Non-formal methods: non-mathematical techniques for analyzing program syntax and seman-tics.

(3) Exploitation: penetration testing and other forms of “black hat” and “gray hat” auditing.(4) Fault management: processes for documenting and resolving discovered vulnerabilities.

A.2.3. Source Code AuditingSource code auditing is a standard procedure in performing system security audits. The goal isto eliminate errors in translating system design to system implementation. Experienced and/orsecurity-minded developers perform source code audits because they acknowledge that eventhey could introduce subtle errors and vulnerabilities into the implementation. These errorsoften arise from the idiosyncrasies of each programming language and the software develop-ment practices used. Auditors should be proficient in the programming languages the software iswritten. We focus our discussion on the languages the RSE implementation is written: C and Python.

The C language exposes low-level system operations and leaves memory management to theprogrammer. The power of C’s low-level access together with increasing software complexitymake developing software in C especially error-prone; even the most vigilant and experiencedsoftware engineers will inevitably introduce security flaws into the program. Consequences of theseflaws include enabling adversaries to execute arbitrary code, to expose sensitive data, and to causeprogram instability [Dowd et al. 2007; Erlingsson 2007].

Due to its ubiquity, C has received much attention from the security community such as Dowd,et al. [Dowd et al. 2007] and Erlingsson [Erlingsson 2007]. Many works on the subject overlapwhen describing common issues when developing software in C: improper bounds checking,

23

improper type conversions, signed/unsigned arithmetic, use of predictable statically-defined blocksof memory, etc. Fortify Software (now HP Enterprise Security) [Fortify Software 2013; 2014]provides a comprehensive listing of common errors including their descriptions, effects, andmitigations.

In contrast to C, Python [Foundation 2014] provides high-level programming abstractionsand hides many of the dangers of C (e.g., direct memory access and management). Its robustexception handling capabilities allow the language to halt the program where a C program wouldotherwise continue to execute. However robust Python’s native features may be though, they donot eliminate all opportunities for programmers to inadvertently introduce security bugs. FortifySoftware [Fortify Software 2013; 2014] provides a comprehensive listing of these errors for Pythonas well.

Static analysis tools can automate parts of the source code auditing process. These tools offer twoadvantages: they decrease the amount of time spent on manual auditing and they enable inexperi-enced programmers and auditors to identify vulnerabilities they might otherwise miss. Carlsson andBaca [Carlsson and Baca 2005] discuss common flaws these tools can identify: buffer overflows,misplaced trust, race condition, and poor random number generators.

A.2.4. Penetration TestingMany vulnerabilities originate in systems where program logic and data reside in the same memoryspace. Maliciously crafted user input enables an attack to inject arbitrary code into the runningprogram. Data stored in statically-defined blocks of memory when modified by an attacker can leadto incorrect execution of decision logic (e.g., bypassing authorization checks).

Unlike source code auditing, which is a form of static analysis, penetration testing is a form ofdynamic analysis. Penetration testing attempts to exploit the running application – often remotely.Metasploit [Metasploit 2014] is a penetration testing framework that enables automation of tests.

A.2.5. Web Application SecurityInternet web protocols add an additional layer of complexity, which an adversary can exploit. Sincethe RSE implementation is a web application, it is necessary to address the topic of web applicationsecurity. OWASP is a world-recognized community dedicated to securing web applications.

The OWASP threat model [Project 2014] encompasses six attributes: threat agents, attacksurfaces, possible attacks, required security controls, potential technical impacts, and importantbusiness impacts. OWASP provides a taxonomy of vulnerabilities specific to web applicationsas well as a code review guide [Project 2014]. We note that due to the dynamic nature of webprogramming, these guides lack specificity to a particular programming language.

A.3. Related WorkThe RSE system implementation is an example of a remote voting system. E2E voting systemsmay be supervised, remote, or hybrid systems [Peacock et al. 2013]. Often associated with thesupervised model are traditional elections, where a voter typically casts their vote in a centersupervised by an election authority. Often associated with the remote model are Internet polls andmailed absentee voting. The RSE system is being developed as an Internet web application, whichplaces it under the remote model.

24

A.3.1. Internet Voting SystemsSeveral Internet voting schemes have come before the RSE system. The first web-based open-auditvoting system was Helios [Adida 2008] (2008). It uses existing cryptographic voting protocolsto ensure election integrity. However, its use of honest-verifier zero knowledge proof requires thevoters equipment be trusted. If the voters equipment is compromised, it does not guarantee voterprivacy. The Scratch, Click & Vote system [Kutylowski and Zagorski 2010] (2010) improves onInternet voting by removing the trust assumption from the voters equipment. Selections [Clark andHengartner 2012] (2012) adds over-the-shoulder coercion-resistance. Remotegrity [Zagorski et al.2013] (2013) provides the capability to detect unauthorized modifications to cast ballots by eithercorrupt voting equipment or the election authority while protecting voter privacy.

The RSE system [Chaum 2014] is being developed under the remote model as an Internet webapplication. The primary motivator is that a random sample of a large electorate will often resultin a set of voters who are geographically distributed. In addition to the security properties ofthe previously listed systems, RSE uses fake ballots to deter against improper influence such asvote-buying.

A.3.2. Trust Establishment in Internet Voting SystemsLittle research has been done on trust establishment in Internet voting systems. Volkamer, etal. [Volkamer et al. 2011] have identified seven areas addressing this topic:

(1) transparency;(2) system evaluation against international standards;(3) separation of duties (system components and responsibilities);(4) verifiability;(5) vote updating;(6) test elections; and(7) allowing independent implementations of voting client software.

Many of these areas are of a political and sociological nature. We are concerned with systemtransparency and evaluation.

Security proofs of the systems protocols instill trust in the systems design and promote trans-parency. All systems we mentioned previously have proofs for their security claims.

Instilling trust in the implementation of these systems is more challenging. Formal methods allowverification of implementations bound to a specification, but we are unaware of any Internet votingsystem implementations having used this technique. Trusted platform modules (TPMs) have alsobeen used to root trust in voting machines.

In voting, TPMs can ensure the correct software is running on voting machines [Fink et al. 2009],however it cannot verify the functional correctness of the software implementation. It is challengingto verify functional correctness without resorting to formal methods. The question of functional cor-rectness becomes more complex when third-party software is part of the system, which may containtheir own vulnerabilities. Internet voting systems often are built on top of third-party frameworks oruse third-party software:

(1) Helios runs on the Django framework and is written in Python [Adida et al. 2014; Django 2014;Foundation 2014];

(2) Remotegrity runs on and is written in PHP [The PHP Group 2014];(3) Norwegian voting software runs on the Spring Framework and is written in Java [of Local Gov-

ernment et al. 2014; Spring Project 2014; Java Programming Language 2014]; and

25

(4) for each of the aforementioned systems, the voters client interface runs out of a third-partysoftware.

We feel it is a futile effort to answer the functional correctness question of an implementation inthis environment. However, we can identify and mitigate much of the risk through security auditsof the system implementation.

Though not as important, we note TPMs raise a usability issue. Mandatory TPM usagemay be reasonable when the system is controlled by the Election Authority. In the case of In-ternet voting, the client system is controlled by the voter – who may or may not be technically savvy.

A.3.3. Security Auditing of Internet Voting ImplementationsThe method we will use to establish initial trust in the RSE implementation is the security audit.This addresses system transparency and evaluation pillars noted in Volkamer. Frameworks forconducting security audits on electronic voting systems already exist (e.g., Ramilli’s frame-work [Ramilli and Prandini 2010]). However, general frameworks tend to be vague and abstract.Ramilli’s framework suffers from these same drawbacks. Despite this, Ramilli does not suggestconcrete procedures as part of his framework.

The Internet voting systems we described earlier appear to lack implementation evaluations andpublished source code audits. This is less than transparent and usually is indicative of an insecureimplementation. There may be other signs of secure processes, however. For example, even thoughHelios has several published attacks against it, the Helios team has been responsive in publishingmitigations for these vulnerabilities [Helios 2014; Estehghari and Desmedt 2010; Heiderich et al.2012].

Fortunately, it appears Internet voting systems employed in binding elections have undergonesecurity evaluations and source code audits. Estonia and Norway implemented their own systemsbased on peer-reviewed voting protocols [Heiberg et al. 2012; Gjsteen 2012].

A security audit of the Estonian system [Vinkel 2012] determined there is an assumption oftrust in voters client [Heiberg et al. 2012]. This is further supported by the Estonian govern-ment’s decision to release their server-side software source code [Committee 2014], but not theirclient-side code [Farivar 2014]. We note this is less transparent than what is ideal. By releasingthe client software a week before the election, the Estonian government hopes malicious entitieswill not have enough time to reverse engineer and exploit the client until after the election.Beside being a form of security through obscurity, which has been shown to be ineffective, thisassumption may be a gross underestimation of an adversary’s capabilities. While the system hasundergone a security evaluation, we feel the lacking transparency is indicative of lacking confidence.

The Norwegian government has been more transparent regarding their system. They released thesystem’s source code in its entirety for anyone to study [of Local Government et al. 2014]. TheNorwegian government also commissioned an independent security audit [Bjorstad 2013] detailingthe vulnerabilities of the system, which included notes regarding misuses of cryptography and keygeneration. The audit report concluded the insecurity of the implementation. The company thatengineered the system published their own report in response. They acknowledged the existence ofthe vulnerabilities, but denied the significance of the findings [SA 2013].

Schryen and Rich [Schryen and Rich 2009] compared the security of the system used in Norway,the Netherlands, and Switzerland. Their conclusions regarding the Norwegian system echoedthe conclusions of the Norwegian government. It appears to date there are no completely secure

26

Internet voting systems.

A.4. ConclusionIn conducting a security audit of the RSE implementation, we can leverage existing knowledgeand standards on source code auditing, penetration, and hardening to create a formal processfor our audit. Fortify Software [Fortify Software 2014] and OWASP provide useful taxonomies,indices, and guides relating to source code auditing and penetration testing of both the manualand automated varieties. Our auditing and testing process will incorporate manual and automatedprocesses built around the vulnerabilities outlined by OWASP and Fortify Software.

Under normal circumstances, there is a code freeze during audits to limit the scope and increasequality of the audit. In our case, we will be performing our audit alongside the development ofthe system due to the immaturity of the code base, but otherwise our audit will be procedurallysimilar to existing audits. Our goals are unique in that no formal security audit has been done ofRSE, and few audits have been conducted on Internet voting systems in general. The two audits ofopen-source Internet voting systems revealed several exploits but the results were not taken intoconsideration. We hope that by working alongside the development team, any exploits we find willin fact be addressed in future builds.

27

B. ACRONYMS AND ABBREVIATIONS

Acronym / Abbreviation DefinitionABB Audit bulletin boardCSRF Cross-site request forgeryCSV Comma-separated valueE2E End-to-end high assuranceEA Election authorityMVC Model-view-controllerORM Object-relational mappingREST Representational state transferRSE Random-sample electionSQL Structured query languageSSL Secure socket layerTPM Trusted platform moduleURL Uniform resource locatorVBB Voter bulletin boardXSS Cross-site scripting

28