Unisyn OpenElect Security
The OpenElect Voting System is on its own closed and self-contained network, with no access to external networks (public or private), with its own (nonproprietary) security measures. The system has several levels of security at both the operating system (OS) and application levels. The EMS system runs on a custom Linux CentOS build that is tailored for maximum efficiency and security. The system is a multiple user operating system with varying levels of application access.
Access is dependent on the user login. Users that have access to only one application will automatically be launched into that application with no access to the desktop after login. Users with access to multiple applications will be presented with shortcut icons on a desktop after login.
The operating system users are distinct from the application users. Only users with the proper access rights to the operating system can work with files, directories and application software. All OS passwords must be changed every six months. Logging occurs at the database transaction level, application level and at the OS level to present a complete picture of all activities on the system based on both OS and application users.
The OVO (ballot scanning device) is a standalone system and has no network connections. This prevents any external access to the system. Additionally, the application resides on an encrypted partition. The unit has a customized BIOS that prevents resetting of the BIOS security by “Jumping” the BIOS.
The OVO is a single user system that automatically launches the client application and provides complete focus to it. These systems disallow any user interactivity during the boot process, disables all keyboard shortcuts and X Windows is configured to block all console access.
Authentication
There are several layers of authentication implemented by the system, some are optional as configured by the County, some are mandatory and some are transparent to the operator. By layers, we mean that there are several authentication steps to ensure the system is ready to function on the Election Day.
The first validation is the validation of the binaries, where the system ensures that the digital signatures for the compiled binaries (executable code) are correct and unchanged, ensuring that the installed software is the certified software. The second validation is that of the election data itself, again verifying the signature and checksum to validate that the data is unchanged and originated from a trusted source. Once the data is validated, the systems will startup, requiring validation of both the election date and a valid password to begin a voting session.
Tampering Protection
On startup, the system verifies the digital signature of the binaries to ensure that they were compiled by a Unisyn source. Subsequently the election definitions and associated files are validated to have originated from the customer via digital signature.
Once this baseline is met, the system can start. On every cast, the vote files are verified via machine digital signature as not being tampered with. The electronic ballot is written to three (3) separate media, signed and verified once again.
Encryption Key Protection
Each in-precinct unit (OVO/OVI/FVT) has a unique asymmetric machine keyset, as well as being provided with a customer specific public key. The public keys for all valid machines are uploaded to the Election Manager module. When the election is exported, it is signed by the customer private key, and the data is encrypted with a dynamically generated key. This key is in turn encrypted with the machine public key, if the machine is assigned to that election.
On startup, all systems will first use the customer public key to validate the digital signature to ensure the election data came from a trusted source and is unchanged. The system then uses its private key (which never leaves the device) to extract the election key and get decrypt the election definition. In other words, an election cannot be loaded on an unauthorized machine, nor can a machine use data from an untrusted source.
Why Linux
The base Linux CentOS is configured to meet the NIST (National Institute of Standards and Technology) SCAP (Security Content Automation Protocol). These configurations include, but are not limited to: intrusion detection, comprehensive logging on all transactions (outside of Unisyn applications) and connection port management. Additionally, the system does not allow “root” access from a remote session. All of these settings are automatic as part of the default installation provided from Unisyn. More information can be found here: https://scap.nist.gov/revision/
Unfortunately, with Windows the configurations are not as restrictive on user access, which creates a higher potential for security threats.
The Linux operating system is appropriate for the hardware that it is installed on and no significant updates are required. Especially as the certification includes the OS, which is unlike a Windows OS, which requires multiple updates.
In the event that a patch needs to be applied, (i.e. security) Unisyn will provide a certified procedure.
An Additional Layer of Security (2.0.A)
With the certification of OpenElect 2.0.A, the software and election metadata will only be transferred via removable media instead of via the software/election network. Where internal networking is required or necessary, Unisyn has added an additional layer of security, via the OpenVPN protocol. OpenVPN uses validated cryptographic modules on any component transmitting data over a closed network.