3.2 Lax Operational Security
Since the I-voting system treats parts of the server infras-
tructure as implicitly trusted, the processes used to install
and configure those servers are crucial for the security of
the election. We witnessed numerous serious lapses in opera-
tional security both during our on-site observations and in
the official videos released by the Internet Voting Committee.
Pre-election setup
Several problems can be seen in the
official videos of the pre-election setup process, which takes
place in the National Electoral Committee’s offices in Tallinn.
The videos show election workers downloading software
for use in the setup process from a public website over an
unsecured HTTP connection (Figure 6). A network-based
man-in-the-middle attacker could compromise these applica-
tions and introduce malware into the configuration process.
In other instances. workers unintentionally typed pass-
words and national ID card PINs in view of the camera
(Figures 7 and 8). These included the root passwords for the
election servers. Similar problems occurred during daily main-
tenance operations in the data center. Physical keys to the
server room and rack were revealed to observers; these keys
could potentially be duplicated using known techniques [45].
The most alarming operational security weakness during
pre-election setup was workers using an “unclean” personal
computer to prepare election client software for distribution
to the public. As seen in Figure 5, the desktop has shortcuts
for an online gambling site and a BitTorrent client, suggesting
that this was not a specially secured official machine. If
the computer used to prepare the client was infected with
malware, malicious code could have spread to voters’ PCs.
Daily maintenance
We observed further operational
security weaknesses during daily maintenance procedures
that took place during the voting period. The I-voting
servers are hosted at a government data center in Tallinn,
and workers go there to perform operations at the server
consoles. While there were security video cameras at the data
center, there appeared to be no 24/7 security personnel nor
any definitive information on who monitored the cameras.
Standard practice during daily maintenance is for workers
to log in to the election servers under the
root
account
and perform operations at the shell. Logging in as
root
is contrary to security best practice, as it simplifies many
attacks, disables user-based privilege separation for operator
functions, and increases the risk of human error.
Unencrypted daily backups were casually transported in
workers’ personal backpacks. DVDs holding updated voter
lists from the population register were handled in a similarly
casual way after having been created, we were told, by a
member of staff at their own computer. We did not observe
any audit trail or checks on the provenance of these DVDs,
which were used daily at the heart of the I-voting system.
Tabulation
The tabulation process at the end of the
election was also concerning. After the votes were decrypted
on the counting server, an unknown technical glitch prevented
workers from writing the official counts and log files to DVD.
Instead, officials decided to use a worker’s personal USB
stick to transfer the files to an Internet-connected Windows
laptop, where the results were officially signed. This USB
stick had been previously used and contained other files, as
shown in Figure 10. This occurred despite protest from an
audience member and deviated significantly from the written
procedure, adding multiple potential attack vectors. Malware
present on the laptop or USB stick could have altered the
unsigned results, or malware on the USB stick could have
been transferred to the trusted counting server.
These instances illustrate a pattern of operational secu-
rity lapses on the part of the workers who operated the
I-voting system. This is particularly alarming given the high
degree of trust the I-voting system design requires of the
election servers, client software, and the election workers
themselves.
3.3 Insufficient Transparency
The election officials have implemented a number of trans-
parency measures, including allowing in-person public ob-
servation, publishing videos of operator tasks, and releasing
large parts of the server source code. While these measures
appear to be well intended, they are incomplete and insuffi-
cient to fully establish the integrity of election results.
One limitation is that these measures cannot show whether
malicious actions were performed on the servers or hard disks
before recording and observation commenced. In practice,
they also do not capture everything going on in the facilities.
On many occasions, there were multiple machines or screens
in use simultaneously but only a single camera.
Although we attempted to follow these simultaneous op-
erations during our in-person observations, on occasion the
operators appeared to be deliberately evading us. For in-
stance, on Monday, October 14, we were physically present in
the server room when one of the servers produced abnormal
output, which appeared to be a failure of the update oper-
ation. The official video recording was following the other
display, and the operator, upon seeing the error message,
quickly flushed it from the screen. In another instance when
an error appeared on the server console, an election worker
quickly cleared the display and then asked us to rotate out
of the room and let other observers in, allowing him a block
of observation-free time.
An auditor from a major international consulting firm had
been hired by the Internet Voting Committee, and his report
also documents procedural and operational shortcomings [56].
However, the auditor’s role was chiefly to observe, and he
was not provided with the access needed to confirm secure
operation of the system.
Election officials have made large parts of the server soft-
ware open source [30]. This is a positive measure as it allows
independent review and assessment— indeed, our study made
extensive use of the code. However, security-critical pieces of
code are missing from the published sources, including the
entire client application and code that is executed on every
server machine (see Section 4.1).
Officials told us that the client source is not released (and
furthermore, the client binary is obfuscated) because they
are concerned that attackers might modify it and distribute
a trojan lookalike. Creating client-side malware is feasible
without the source, as we show in Section 5.1. At the same
time, keeping source code secret prevents the public from
understanding what they are being asked to run on their com-
puters, and it increases the risk that any centrally introduced
malicious changes to the client will go undetected.
As these transparency measures are practiced today, the
videos, public observation, and open-source components risk
providing a false sense of security. It is possible for the sys-
tems to be corrupted prior to videotaping, for media used to
update servers to be maliciously modified, or for unpublished