This is an HTML version of an attachment to the Freedom of Information request 'Vote Secrecy in 2020 Election'.

 
Business Requirements Specification 
 
  
ICT business system upgrade  
– eVACS® 
 
 
 
Elections ACT 
2018-19 
 
 
 
 

 
 
1.  INTRODUCTION 

1.1. 
Definitions 
5 
1.2. 
Purpose 
5 
1.3. 
Business problem 
5 
1.4. 
Key stakeholders 
6 
1.5. 
Project scope – inclusions 
6 
1.6. 
Project scope – exclusions 
6 
2.  OVERVIEW 

2.1. 
Perspective 
7 
2.2. 
Types of users 
7 
2.3. 
Operating environment 
8 
2.4. 
Constraints 
9 
2.4.1.  Time frame constraints 

2.5. 
Assumptions 
9 
3.  REQUIREMENTS 
10 
3.1. 
Current practice / scenarios 
10 
3.1.1.  Setup module: 
10 
3.1.2.  Voting module: 
10 
3.1.3.  Data entry module: 
11 
3.1.4.  Counting module: 
12 
3.1.5.  Reporting module: 
12 
3.2. 
Business requirements 
13 
3.3. 
Ongoing Maintenance/Agreement Plan 
27 
3.4. 
Manuals 
28 
3.5. 
Backup & Recovery Requirements 
29 
Requirements Acceptance Certificate 
30 
 
 
 
 
 
 
 
 
 
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
3 May 2019  
 
 
 
 
 
 
 
 
 
 
Page 2 of 30 

 
 
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
3 May 2019  
 
 
 
 
 
 
 
 
 
 
Page 3 of 30 



 
1. Introduction 
1.1. Definitions 
Current system: 
The June 2014 version of eVACS®, the Electronic Voting and Counting 
System originally built by Software Improvements for use by Elections ACT 
at the 2001 ACT Legislative Assembly Election. Fol owing upgrades for all 
subsequent elections, the current system was used by Elections ACT at the 
2016 ACT Legislative Assembly election 
Elections ACT: 
The ACT Electoral Commission 
IRAP: 
Information Security Registered Assessors Program. An Australian Signals 
Directorate initiative to assess the implementation, appropriateness and 
effectiveness of a system’s security controls. 
The system: 
eVACS® 
Vendor:  
 
Software Improvements Pty Ltd 
 
1.2. Purpose 
The purpose of this document is to outline to the vendor of eVACS®, Software Improvements Pty 
Ltd, the requirements for upgrade of eVACS® from the current system, deployed for the 2016 ACT 
election, to a system with improved security and functionality, ready for deployment at the 2020 
ACT election. This document follows the successful business case to ACT Treasury for funding 
announced in the 2018-19 budget. 
See: G:\EC\3.2FinancialManagement\3.2.1BudgetAndEstimates\2018-19\2018-19 Budget\Budget 
bids\EVACS upgrade - Capital budget bid\Business case\ACT Electoral Commission ICT Business 
Case 2018-19 - FINAL.pdf 
 
1.3. Business problem 
Following recommendations made by the ACT Auditor-General in relation to the 2016 ACT election, 
RSM Australia was commissioned to review electronic voting in the ACT. Their report advised that 
eVACS® requires major modernisation of the underlying technologies and hardware to address risks 
identified by the review. These include: a vulnerable operating system, together with the absence of 
modern data management and security protocols, such as database level encryption, which improve 
robustness and security within any ICT business system; a 2001 originating system which cannot meet 
the compatibility requirements of modern hardware, especially by 2020; and a shortage of software 
developers and support personnel skil ed in maintaining a system developed in outdated and vulnerable 
technologies.  
The risks identified are critical when considered in reference to an ICT business system fundamental to 
the integrity of an election process and crucial to the successful delivery of an ACT Legislative 
Assembly election. 
Addressing concerns raised by MLAs, centred around the perceived antiquity of the system, emanating 
from the use of keypads for navigation, this project includes the introduction of touchscreen functionality 
to the eVACS® system. 
Telephone voting functionality is also being introduced to address submissions to the Select Committee 
Inquiry into 2016 ACT Election and the Electoral Act by representatives from the blind and vision-
impaired community. 
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
3 May 2019  
 
 
 
 
 
 
 
 
 
 
Page 5 of 30 

















 
Software Improvements is to deliver an electronic voting solution for electronic votes 
taken at pol ing places or via telephone voting (see requirement 41) that completely 
prohibits the possibility that:  
•  an elector can be matched to their voting preferences; and 
•  an elector’s voting preferences can be deleted or altered in any way.  
 
4.   
Create a HAZOPS document. 
In order to minimise the potential for fraud and vote manipulation it is important to 
identify potential hazards and risks and then determine the consequences and 
probability of those identified hazards/risks occurring. It is then important to devise 
ways and means to reduce the consequences or probability of occurrence down to a 
level acceptable to the Electoral Commission. 
 
Elections ACT would like Software Improvements to work with known experts in this 
area to create a HAZOPS document, or something similar, as a means to identify 
potential real and perceived electoral integrity issues and outline the safety-guards in 
place to minimise the risk of occurrence. 
This document is likely to be used when communicating the effective mitigation 
practices in place when faced with outside queries over the system’s integrity. 
 
5.   
Passwords throughout the system should  It should not be possible to create a password in the system that does not conform to 
only be able to be set if they meet ACT 
ACT Government and ASD password security standards. Below is the standard taken 
Government password security 
from the SSICT document: 
requirements. 
 Strong passwords that meet the standard required contain at least three character sets 
comprising any three of the fol owing:  
•  upper and lower case characters, e.g. a-z, A-Z 
•  have digits and punctuation characters as wel  as letters, e.g. 0-9, 
!@#$%^&*()_+|~-=\`{}[]:";'<> ? , . /  
•  are at least ten alphanumeric characters long for standard users, and a minimum 
of 12 characters for users with privileged access accounts  
 
6.   
The entire software code shall be written  Migrate the current functionality and operating process ‘like-for-like’, from ‘C’ language 
in a modern language that can provide a 
to ‘Ada’. 
safer and more secure environment. 
 
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
30 April 2019  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Page 14 of 30 

 
 
 
7.   
Ensure that an elector and their 
The RSM Review identified that there is stil  potential to link an elector’s identity to a 
preferences cannot be matched through 
vote by using timestamps within eVACS®. As such, the Review recommended updating 
the use of timestamp data. 
the underlying algorithm to further minimise this risk of tracing an individual’s voting 
 
preferences.  
 
 
This could be achieved by shuffling the votes (see requirement 8) to de-link the 
timestamp from the first scan of the QR Code or removing the capture of timestamp 
data entirely. 
 
The solution should ensure that the elector’s identity cannot in any way be linked to 
their vote. 
 
8.   
Shuffle the votes when stored 
The current eVACS system stores the votes within the pol ing place server in 
 
consecutive order. In theory this raises the possibility of matching an elector’s 
preferences with the order in which they cast their ballot within the pol ing place. 
 
To eliminate this possibility the vote order should be randomly shuffled within the vote 
storing module. 
 
9.   
Ful y encrypt the voting process  
RSM review identified that the current solution, which transmits raw voting data 
 
between the vote being cast and stored on the pol ing place server, could be viewed as 
a risk to vote integrity.  
 
eVACS should protect each individual vote throughout the voting process so that it 
cannot be manipulated at any point and the integrity of the vote cannot be questioned. 
 
Some comments from SSICT and ASD in relation to protecting the vote include: 
 
  Each individual vote, once it has been cast, is encrypted should use ASD-approved 
cryptographic algorithms and transport the encrypted package using only ASD-
approved cryptographic protocols. 
 
  SSICT asks ‘Wil  the vote be encrypted by the device or wil  the transmission of data 
be encrypted?’  
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
30 April 2019  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Page 15 of 30 

 
 
  ASD suggested that ‘transport layer encryption may be sufficient instead of 
message level encryption, and both transport and message level encryption can 
work together. If message level encryption is used, consider how encryption keys 
wil  be managed.’ 
 
Based on these comments from each stakeholder, Elections ACT seeks the most 
appropriate means in which to achieve the improved vote integrity. 
 
10.  
Update the methodology used to ensure 
When daily vote data is copied onto CD-ROMs, a unique code (a hash) is created and 
authenticity of exported data 
recorded. On arrival back at Election HQ the unique code is used to verify that the data 
 
on the disk has not been tampered with and is an exact copy of the votes recorded on 
the pol ing place server. 
 
The mechanism to create this unique code is based on a methodology (MD5) which is 
obsolete and no longer considered secure.  
 
The mechanism to authenticate the data exported from pol ing place servers for import 
into the election server should be updated to meet contemporary best practice and the 
industry standard. 
 
ASD recommends that the ‘Information Security Manual’ on encryption and hashing be 
consulted in order to update the methodology used to reduce the risk of tampering. 
https://www.acsc.gov.au/infosec/ism/ 
 
11.  
Mandate the entry of ‘hash code’ on the 
When daily vote data is copied onto CD-ROMs, a unique code (a hash) is created and 
election server 
recorded. On arrival back at Election HQ the unique code is used to verify that the data 
on the disk has not been tampered with and is an exact copy of the votes recorded on 
the pol ing place server. (See requirement 10 for the requirement to change how the 
code is generated). 
 
The Auditor General’s performance report found that eVACS could be improved through 
enforcement of the entering of a unique code before data is transferred from the pol ing 
place server to the Election (counting) server. 
 
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
30 April 2019  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Page 16 of 30 



























 
 Requirements Acceptance Certificate 
Accepted by Elections ACT: 
 
Damian Cantwel  AM 
ACT Electoral Commissioner 
Signed: 
 
Date: 
 
 
Accepted by Software Improvements: 
 
Dr Carol Boughton 
Managing Director  
Signed: 
 
Date: 
 
Comments: 
 
 
 
 
 
 
Business Requirements Specification for eVACS® upgrade 2018-19 v1.0 
30 April 2019  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Page 30 of 30