#Software Vulnerabilities in the Brazilian Voting Machine & Scientific Paper The Return of Software Vulnerabilities in the Brazilian Voting Machine

SOURCE/VIDEO LINK: https://youtu.be/RWP1uUaRaMc

56/5000

Software Vulnerabilities in the Brazilian Voting Machine

545 visualizações

33 2

Compartilhar 

Diego Aranha 

Publicado em 29 de ago de 2015

Invited talk at the USENIX 2012 Electronic Voting Workshop/Workshop on Trustworthy Elections

Categoria 

Pessoas e blogs 

1 comentário 

==//==

SOURCE/LINK: 

https://www.researchgate.net/profile/Diego_Aranha/publication/323470546_The_Return_of_Software_Vulnerabilities_in_the_Brazilian_Voting_Machine/links/5ab19f26458515ecebece6d3/The-Return-of-Software-Vulnerabilities-in-the-Brazilian-Voting-Machine.pdf?origin=publication_detail

See all ›

18 References

See all ›

1 Figure

Download full-text PDF

70/5000

The Return of Software Vulnerabilities in the Brazilian Voting Machine

Preprint (PDF Available)  · March 2018 with 23,426 Reads

DOI: 10.13140/RG.2.2.16240.97287 

Diego F. Aranha

    • A. De Miranda

    • F.B. Scarel

View

    • Pairing-Friendly Elliptic Curves of Prime Order

Conference Paper

Full-text available

    • Aug 2005

    • Paulo S. L. M. Barreto

    • 

    • Michael Naehrig

View

    • High-speed high-security signatures.

Article

Full-text available

    • Jan 2011

    • Daniel J. Bernstein

    • 

    • Niels Duif

    • Tanja Lange

    • Peter Schwabe

    • Bo-Yin Yang

View

    • Ar: una mala elección

    • Jan 2015

    • F Oro

    • I A B Chaparro

    • E Lerner

    • S D Ortega

    • A Rizzo

    • J Russ

    • F Smaldone

    • J And

    • N Vot

AMATO, F., ORO, I. A. B., CHAPARRO, E., LERNER, S. D., ORTEGA, A., RIZZO, J., RUSS, F., SMALDONE, J., AND WAISMAN, N. Vot.Ar: una mala elección. https://ivan. barreraoro.com.ar/vot-ar-una-mala-eleccion/, 2015.

    • Siphash: A fast shortinput PRF

    • Lecture Notes in Computer Science

    • 489-508

    • J And

    • D J Bernstein

AUMASSON, J., AND BERNSTEIN, D. J. Siphash: A fast shortinput PRF. In INDOCRYPT (2012), vol. 7668 of Lecture Notes in Computer Science, Springer, pp. 489-508.

    • Report on the Special Audit in the 2014 Voting System

    • Jan 2014

    • Brazilian Social Democracy Party-Psdb

BRAZILIAN SOCIAL DEMOCRACY PARTY-PSDB. Report on the Special Audit in the 2014 Voting System. Available at http://www.brunazo.eng.br/voto-e/arquivos/ RelatorioAuditoriaEleicao2014-PSDB.pdf, 2014.

    • Studying the Nedap/Groenendaal ES3B voting computer: a computer security perspective

Article

    • Jan 2007

    • Rop Gonggrijp

    • Willem-Jan Hengeveld

View

    • Security Analysis of India’s Electronic Voting Machines

Conference Paper

    • Sep 2010

    • Scott Wolchok

    • Eric Wustrow

    • J. Alex Halderman

    • Hari K. Prasad

    • Rop Gonggrijp

View

    • Short Signatures Without Random Oracles and the SDH Assumption in Bilinear Groups

Article

    • Apr 2008

    • J CRYPTOL

    • 

    • Dan Boneh

    • Xavier Boyen

View

    • 

Recommendations

Discover more publications, questions and projects in Voting

Project

Electronic voting

    • 

    • Diego F. Aranha

    • A.L.O. Paraense

    • Helder Ribeiro

    • [...]

    • Caio Lüders

Perform security analysis of real voting systems and propose security and transparency improvements. 

View project

Project

Privacy-preserving computing

    • 

    • Diego F. Aranha

    • Pedro Alves

    • Amanda Resende

Design efficient methods, protocols and implementations for computing over encrypted data. 

View project

Project

Cryptographic engineering

    • 

    • Diego F. Aranha

    • Private Profile

    • Jefferson E. Ricardini

    • [...]

    • Darrel Hankerson

Develop efficient and secure implementations of cryptography. 

View project

Project

Physical Unclonable Functions (PUFs)

    • 

    • Diego F. Aranha

    • Guido Araujo

    • Mario Lucio Côrtes

    • [...]

    • 

    • Rodrigo Surita

Develop PUF candidates and PUF-based cryptographic protocols for solving computer security problems. 

View project

Article

Crowdsourced integrity verification of election results: An experience from Brazilian elections

March 2016 · annals of telecommunications - annales des télécommunications

In this work, we describe an experiment for evaluating the integrity of election results, and improving transparency and voter participation in electronic elections. The idea was based on two aspects: distributed collection of poll tape pictures, taken by voters using mobile devices; and crowdsourced comparison of these pictures with the partial electronic results published by the electoral... [Show full abstract]

Read more

Preprint

Execução de código arbitrário na urna eletrônica brasileira

July 2018

Múltiplas vulnerabilidades graves foram detectadas nos últimos Testes Públicos de Segurança da urna eletrônica brasileira. Quando combinadas, comprometeram sigilo do voto e integridade do software, as principais propriedades de segurança do sistema. O armazenamento inseguro de chaves criptográficas, inseridas diretamente no código-fonte e compartilhadas entre todas as urnas, permitiu inspeção... [Show full abstract]

Read more

Preprint

NIZKCTF: A Non-Interactive Zero-Knowledge Capture the Flag Platform

March 2018

Capture the Flag (CTF) competitions are increasingly important for the Brazilian cybersecurity community as education and professional tools. Unfortunately, CTF platforms may suffer from security issues, giving an unfair advantage to competitors. To mitigate this, we propose NIZKCTF, the first open-audit CTF platform based on non-interactive zero-knowledge proofs. 

Read more

Data

Software vulnerabilities in the Brazilian voting machine (slides for RWC 2016)

January 2016

Read more

Discover more

Last Updated: 01 Aug 18

About

News

Company

Careers

Support

Help center

FAQ

Business solutions

Recruiting

Advertising

© ResearchGate 2018. All rights reserved.

    • Imprint

    • Terms

    • Privacy

    • 

    • 

or

Discover by subject area

Join for free

Log in

    • 13.42

    • Aarhus University

Pedro Yóssis Silva Barbosa

    • 5.14

    • Universidade Federal de Campina Grande (UFCG)

Thiago Nunes Coelho Cardoso

    • 4.67

    • Federal University of Minas Gerais

Paulo Matias

    • 8.48

    • Universidade Federal de São Carlos

Abstract

This paper presents a detailed and up-to-date security analysis of the voting software used in Brazilian elections. It is based on results obtained by the authors in a recent hacking challenge organized by the Superior Electoral Court (SEC), the national electoral authority. During the event, multiple serious vulnerabilities were detected in the voting software, which when combined compromised the main security properties of the equipment , namely ballot secrecy and software integrity. The insecure storage of cryptographic keys, hard-coded directly in source code and shared among all machines, allowed full content inspection of the software installation memory cards, after which two shared libraries missing authentication signatures were detected. Injecting code in those libraries opened the possibility of executing arbitrary code in the equipment, violating the integrity of the running software. Our progress is described chronologically , to illustrate difficulties and limitations in the testing methodology chosen by the electoral authority, and to inform how teams participating in future challenges can optimize their performance. We trace the history of the vulnerabilities to a previous security analysis, providing some perspective about how the system evolved in the past 5 years. As far as we know, this was the most in-depth compromise of an official large-scale voting system ever performed under such severely restricted conditions.

Discover the world's research

    • 15+ million members

    • 118+ million publications

    • 700k+ research projects

Join for free

Figures

Layout for the room where the TPS wa… 

File (PDF)

Available from: Diego F. Aranha, Mar 20, 2018 

Download full-text PDF

The Return of Software Vulnerabilities in the Brazilian Voting Machine

Diego F. Aranha

University of Campinas

Pedro Y´

ossis Silva Barbosa

Federal University of Campina Grande

Thiago Nunes Coelho Cardoso

Hekima

Caio L¨

uders de Ara´

ujo

Federal University of Pernambuco

Paulo Matias

Federal University of S˜

ao Carlos

Abstract

This paper presents a detailed and up-to-date security

analysis of the voting software used in Brazilian elec-

tions. It is based on results obtained by the authors in

a recent hacking challenge organized by the Superior

Electoral Court (SEC), the national electoral authority.

During the event, multiple serious vulnerabilities were

detected in the voting software, which when combined

compromised the main security properties of the equip-

ment, namely ballot secrecy and software integrity. The

insecure storage of cryptographic keys, hard-coded di-

rectly in source code and shared among all machines, al-

lowed full content inspection of the software installation

memory cards, after which two shared libraries missing

authentication signatures were detected. Injecting code

in those libraries opened the possibility of executing arbi-

trary code in the equipment, violating the integrity of the

running software. Our progress is described chronolog-

ically, to illustrate difficulties and limitations in the test-

ing methodology chosen by the electoral authority, and

to inform how teams participating in future challenges

can optimize their performance. We trace the history of

the vulnerabilities to a previous security analysis, pro-

viding some perspective about how the system evolved

in the past 5 years. As far as we know, this was the

most in-depth compromise of an official large-scale vot-

ing system ever performed under such severely restricted

conditions.

1 Introduction

Brazil is one of the largest democracies in the world, with

an expected 144 million voters in the upcoming 2018

general elections1. Elections are conducted every 2 years

in the month of October, alternating between municipal

1Based on 2016 statistics (in Portuguese): http://www.tse.

jus.br/eleitor-e- eleicoes/estatisticas/eleicoes/

eleicoes-anteriores/estatisticas- eleitorais-2016

elections (members of the city council and mayors), and

general elections (members of the lower house, senators,

governors and the president).

Direct Recoding Electronic (DRE) voting machines

were first introduced in the country in 1996, after fre-

quent reports of fraud during transport and tabulation of

paper ballots, and elections became fully electronic in

the year 2000. Voter-verified paper records were briefly

experimented with in 2002, but deemed too costly and

cumbersome by the electoral authority. Since then, mul-

tiple bills were introduced in Brazilian Congress to rein-

troduce paper records, the last one demanding deploy-

ment this year, with an ongoing debate about how the

law should be interpreted and what is the mandated cov-

erage in number of polling places [15].

As a response to the frequent calls for increased trans-

parency, the Superior Electoral Court (SEC) started orga-

nizing hacking challenges in 2009, officially called Pub-

lic Security Tests of the Electronic Voting System. These

are restricted events, where pre-approved external and in-

dependent researchers can examine the security mecha-

nisms implemented within the system, find vulnerabil-

ities and provide suggestions for improvement. After

the first hacking challenges conducted in 2009 and 2012,

the event became mandatory and now happens from 6

months to one year before the elections [24].

Under a turbulent and polarized political environment,

frequently contaminated by corruption scandals, the de-

bate around the security and transparency of Brazilian

machines is growing in popularity. Access to voting

equipment by researchers is still notably restricted, with

the hacking challenges thus presenting a unique oppor-

tunity to perform independent security analysis. The

first such analysis was performed in 2012, and a full re-

port was published afterwards by Aranha et al. [2]. In

the occasion, the authors were able to mount an attack

against ballot secrecy based on insecure random number

generation, and also document many other security is-

sues with the system. As the main concerns, the authors

1

detected insecure storage and massive sharing of cryp-

tographic keys, insufficient integrity verification, and a

faulty software development process conducted under an

inadequate adversarial model.

Our contributions. We continue and update the ef-

forts regarding the analysis of Brazilian voting machine

software and its security, by presenting our findings col-

lected in the 2017 edition of the hacking challenge. In

summary, we were able to:

(i) Recover the symmetric cryptographic key protect-

ing the memory cards that install software before

the elections, allowing decryption and full inspec-

tion of their contents. Because this symmetric key

is shared among all machines, recovering it in a real

election would have nationwide impact.

(ii) Find two software libraries missing digital signa-

tures for authentication or any kind of integrity

check, allowing direct injection of arbitrary code in

their functions. Consequently, it was possible to in-

directly modify the programs linked against them,

such as the official voting application.

(iii) Exploit the code injection capabilities to break bal-

lot secrecy for selected votes, by manipulating cryp-

tographic keys generated on-the-fly; to receive com-

mands from a regular keyboard; and to manipulate

logging records generated by the voting software.

(iv) More importantly, inject code to manipulate the

strings presented by the software to the voter in real

time and advertise a hypothetical candidate or polit-

ical party.

The code injection capabilities were later extended to

manipulate the outcome of a simulated election, since all

requirements to do so were satisfied by the vulnerabilities

detected at that point. Substantial progress was made to-

ward this goal by erasing all votes in an electronic ballot,

which triggered an empty ballot consistency error in the

voting software. The attack was then adapted to manipu-

late votes stored in memory, but the event was interrupted

before we could validate a supposedly correct version of

the payload in the real hardware.

Paper outline. The remaining sections are organized

as follows. In Section 2, we describe the standard Brazil-

ian election procedure, the software ecosystem and some

of its the security mechanisms. In Section 3, we summa-

rize the history and discuss the format, limitations and

results in previous hacking challenges of the Brazilian

voting machines. Section 4 continues by reporting about

our day-to-day progress when participating in the 2017

hacking challenge. Section 5 reviews related work and

analyzes our findings in context, tracing a historical per-

spective with relation to other security analysis of the

same system. Section 6 finishes the paper.

2 Background

A surprising characteristic of Brazilian elections is that

the entire election administration is under control of a

single institution. The Superior Electoral Court (SEC)

is responsible for performing voter registration, design-

ing election procedures, recruiting election officials, or-

ganizing the logistics on election day, deciding and im-

plementing what election technology will be used, and

any other remaining operational tasks. As part of the ju-

dicial branch of government, the SEC also resolves all

legal disputes regarding elections. It is presided by a

Supreme Court judge, who accumulates a seat to report

on electoral issues involving constitutional matters.

Brazil witnessed rampant fraud on paper ballot elec-

tions during the transition to a democracy in the 80s,

motivating the electoral authority to consider the deploy-

ment of electronic devices for collecting votes. In 1982,

the SEC started the move to digital by employing elec-

tronic transmission of election results. A few years later,

voter registration data was migrated to digital storage

and, in 1991, the first personal computers were used as

voting equipment in small referendums.

The first DRE voting machines were introduced in

1996 at small scale, in only 56 municipalities. The ma-

chines were manufactured by Unisys and equipped with

an Intel 80386 processor. In terms of software, the ma-

chines employed a DOS-compatible operating system

called VirtuOS manufactured by the Brazilian company

Microbase. Later models were subsequently introduced

almost every other year and manufacturing was trans-

ferred at some point to Procomp, the Brazilian subsidiary

of Diebold Incorporated.

The later models maintained the same initial design

and interface, but adopted more recent hardware compo-

nents and software. For example, machines from 2002 to

2006 were deployed with the Microsoft Windows Com-

pact Edition operating system and newer models exclu-

sively run the GNU/Linux operating system. The latest

model, introduced in 2015, includes a Hardware Secu-

rity Module (HSM) of sorts (called MSD – Master Secu-

rity Device) for computing critical cryptographic opera-

tions, storing cryptographic keys and verifying software

integrity during the boot process. Software-wise, initial

versions of the voting software were also produced by

Diebold-Procomp, but the SEC took ownership of the

software development process in 2006. The team re-

sponsible for software development consists in a mix of

in-house and contracted developers. In 2008, the SEC

started enrolling voters for biometric identification using

fingerprints and the effort recently reached half of the

voting population.

2

2.1 Voting equipment

The Brazilian voting machine, or “urna eletrˆ

onica” in

Portuguese, consists of a classical DRE device without

any type of voter-verified paper record. The machine is

composed of an election official terminal, used to authen-

ticate electors by their registration number or fingerprint,

and a voter terminal where votes are cast via a keyboard

reminiscent of a modern telephone. The full machine is

shown in Figure 1. Candidates and their political parties

are selected by typing the corresponding numbers in the

voter terminal. It is also possible to either cast a blank

vote, change or confirm a vote by pressing the colored

buttons (from left to right, respectively).

The two terminals are connected by a long cable, a

questionable design aspect in terms of ballot secrecy.

The cable provides access to the voter data stored by

the voter terminal. This means that the voting machine

simultaneously observes voter identification information

and the votes being cast. Besides the keyboards for in-

put, communication to and from the voting machine is

possible via memory cards and a small printer. Mem-

ory components include internal and external flash cards

responsible for storing the operating system, the compo-

nents of the voting machine software, and data related to

candidates and voters. During an election, the files stor-

ing the current state are redundantly stored in both the

internal and external memories, so they can be recovered

in case either is permanently damaged.

External flash cards are inserted in a slot in the back of

the machine. A software installation card, called an in-

stall card (or “flash de carga”), is used to transfer official

voting machine software to the internal memory before

the elections. Another flash memory card, called voting

card (or “flash de votac¸ ˜

ao”), is inserted during elections

in the same external slot for providing voter and candi-

date registration numbers. There is another slot in the

back of the machine to attach a USB stick called Memory

of Results (or MR – “Mem´

oria de Resultados”). The MR

stores election results and other data that is made pub-

licly available later. These external interfaces are pro-

tected by tamper-evident seals signed by electoral judges

in a public ceremony.

2.2 Official voting procedures

Elections using the Brazilian voting machine follow pro-

cedures typical of DRE-based elections and a very sim-

ilar workflow. The preparation steps performed before

elections can be found below:

(i) Development of software components: contrary to

other countries, election software is continuously

maintained and updated by the SEC. Inspectors

from political parties and other institutions can ex-

amine the source code under a Non-Disclose Agree-

ment (NDA) in the SEC headquarters for a few

months before the elections and provide suggestions

for improvement.

(ii) Distribution of software components: a specific ver-

sion of the software is frozen and compiled in a

public ceremony, to be later transmitted electroni-

cally to the local branches of the SEC a few days

before the election. Hence each new election runs

on a more recent version of the codebase. Upon re-

ceipt of the official voting machine software, staff

in the local branches generate the install cards us-

ing Desktop computers. These memory cards are

then transported across the states to multiple places

where voting machines are stored in-between elec-

tions. Each card installs up to 50 voting machines.

(iii) Installation of voting machine software through in-

stall cards: voting software is installed in the ma-

chines through the flash memory cards using a soft-

ware module called SCUE2. The machine boots

from the install card and the system self-checks the

integrity of its own files before they are copied to the

internal memory. Afterwards, the machine can then

be initialized from internal memory, and a hardware

test is performed on first boot.

(iv) Distribution of the voting machines: uniquely iden-

tified voting machines are assigned to the corre-

sponding polling places. Each assignment is dig-

itally signed using a pairing-based Boneh-Boyen

short signature scheme [7], instantiated with a

160-bit Barreto-Naehrig curve [5], and the result-

ing signature is used as witness, called correspon-

dence code (or “resumo da correspondˆ

encia”). A

database containing the assignments is published af-

terwards.

In the election day, a uniform procedure is executed

across all polling stations, simplified below for clarity:

1. Voting machine prints the zero tape (or “zer´

esima”)

between 7AM and 8AM. This is an official public

document supposedly attesting that no votes were

computed for any candidates before the start of the

elections.

2. The election official opens the voting session at

8AM by typing a command in the election official

terminal.

3. The voters provide identification information and

are authorized to cast votes in the machines.

2From the Portuguese “Sistema de Carga da Urna Eletrˆ

onica”, or

Voting Machine Installation Software.

3

Figure 1: The two terminals of the Brazilian DRE voting machine. In the left, the election official terminal has a

fingerprint recognition device visible in the top; while the voter terminal is on the right. The cable connecting the two

allows software executed in the election official terminal to authenticate voter data (registration number or fingerprint)

stored in the voter terminal.

4. The election official closes the voting session at

5PM, local time, if no additional voters remain in

the queue.

5. The voting machine prints the poll tape (or “Bo-

letim de Urna”), containing per-machine totals for

each candidate. Copies of this physical document

are signed by election officials, distributed among

inspectors from the political parties and should be

fixed on an accessible location in the polling place.

6. The voting machine records electronic versions of

the authenticated public products of the election.

They consist of a digital version of the poll tape

containing the partial results; a chronological record

of events registered by the machine (LOG); and the

Digital Record of the Vote (DRV), an electronic

shuffled list of the actual votes. These files are dig-

itally signed and stored in the MR.

7. The election official violates the seal and retrieves

the MR containing the public products.

8. The election official boots a networked Desktop

computer in the polling place using JE Connect, a

dedicated LiveUSB containing a GNU/Linux distri-

bution. This system establishes a secure connec-

tion with the election authority infrastructure using

a Virtual Private Network (VPN).

9. The election official attaches the MR to this com-

puter and transmits the public products of the elec-

tion to the centralized tabulation system.

10. The central tabulator combines all the partial results

and the official result of the election is declared.

The whole process of transmission and tabulation usu-

ally takes a few hours. After three days, digital ver-

sions of the poll tapes received by the tabulation system

are made available in the SEC website for independent

checking, and other election products can be obtained by

the political parties through a formal process. Malicious

manipulation of the tabulation phase can only be detected

by manual comparison of printed and digital versions of

the poll tapes.

2.3 The software ecosystem

The whole software codebase has a complexity in the or-

der of tens of millions of lines of code, including all of

its components. The version made available in the latest

hacking challenge was tagged with the string The Hour

of the Star” (or “A Hora da Estrela”) in homage to a

novel authored by Brazilian writer Clarice Lispector.

The voting machine software source code alone has

more than ten million lines [8] and is organized as a cus-

tomized GNU/Linux distribution (UENUX) for the In-

tel 32-bit architecture. Besides the typical userland li-

braries, it includes the official voting application (VOTA

– “Votac¸ ˜

ao Oficial”), the voting machine software in-

stallation system (SCUE – “Sistema de Carga da Urna

Eletrˆ

onica”), a forensic tool to recover damaged data

(RED – “Recuperador de Dados”), a system for man-

ually typing partial results in case a voting machine mal-

functions (SA – “Sistema de Apurac¸ ˜

ao”), and an appli-

cation manager (GAP – “Gerenciador de Aplicativos”).

Low-level software includes a customized bootloader

4

(based on Syslinux3), kernel and drivers. The bootloader

boots from a nonstandard offset and the BIOS is modi-

fied to take this into account. Among the customizations

in the GNU/Linux kernel there is the inclusion of device

drivers and modification of some standard security mech-

anisms. The codebase is currently shifting from the 2.6

to the 3.18 branch of the kernel.

Encryption. There are several security mechanisms

implemented in the voting machine software, where the

main security goal is to enforce integrity checking and

authentication of the hardware and software. This is at-

tempted by combining multiple layers of encryption, to

prevent inspection and extraction of sensitive informa-

tion by outsiders, and several authentication primitives.

As examples of low-level mechanisms, the bootloader

contains an AES-256 encryption key to decrypt the ker-

nel image in the ECB mode of operation during initial-

ization of the system. The kernel has keys embedded

to encrypt/decrypt individual files in a MINIX file sys-

tem under the AES-XTS mode; and to implement an

encrypted repository of cryptographic keys in AES-256,

CBC mode. The latter set of keys, here called authenti-

cation keys include private keys to digitally sign the pub-

lic products of an election, public keys and certificates

for signature verification, and secret keys to authenticate

poll tapes using SipHash [4]. Figure 2 presents how the

encryption layers are organized, with modules in the top

containing the keys to decrypt modules immediately be-

low.

Bootloader

Kernel

file system authentication

keys

Figure 2: Chained layers of encryption in the install card.

Arrows denote possession of encryption keys to decrypt

the next layer.

Authentication. In terms of authentication, the BIOS,

bootloader and kernel images are digitally signed using

ECDSA, instantiated with the NIST P-521 curve. Figure

3 presents the voting machine chain of trust. The chain

starts with the MSD, and each component authenticates

the next in sequence until userland applications are suc-

cessfully loaded and executed.

Kernel modules, executable binaries and shared li-

braries are digitally signed with RSA-4096 and the sig-

3Syslinux bootloader: http://www.syslinux.org

MSD

BIOS

Bootloader

Kernel

initje scue other executables

detached signatures (.vst)

Figure 3: Voting machine chain of trust, starting with the

MSD. Arrows denote signature verification. Detached

signatures for installation files are verified by the SCUE

module.

natures appended to the corresponding files. The public

key for verification is embedded in the kernel and used

by the loader to prevent tampering with these files. All

files in the install and voting cards, and the public files

resulting at the end of an election are digitally signed,

with signatures computed by the MSD. These detached

signatures are stored in VST files, this time using an El-

gamal signature scheme instantiated with the NIST P-

256 elliptic curve. This module was designed and im-

plemented by technicians from the cryptography sec-

tor (CEPESC – “Centro de Pesquisa e Desenvolvimento

para a Seguranc¸a das Comunicac¸ ˜

oes”) of the Brazilian

Intelligence Agency (ABIN – “Agˆ

encia Brasileira de In-

teligˆ

encia”). The poll tapes have QR codes encoding

partial results in a machine-readable format, to facilitate

automated comparisons with published results [3], and

these are digitally signed using Ed25519 [6].

Random numbers. Many of the deployed crypto-

graphic algorithms for encryption and authentication re-

quire random numbers, and there are multiple algorithms

across the codebase. The Elgamal signatures computed

by the MSD rely on the xorshift family [21] of pseudo-

random number generators (PRNG). The mechanism

for shuffling votes inside the DRV file is implemented

through a combination of two other generators: reading

directly from /dev/urandom or from a customized user-

land PRNG based on a 32-bit variant of the 64-bit version

of an obscure algorithm called Sapparot-2 [20].

Additional software components are InfoArquivos

and RecArquivos, parts of the system for transmission

of results and tabulation; and GEDAI (or “Gerenci-

ador de Dados, Aplicativos e Interface com a Urna

Eletrˆ

onica”), a software subsystem to manage and gener-

ate install/voting cards and empty MR sticks in the Win-

dows platform. It is worthy noting that the machines run-

ning GEDAI execute an operating-system-level suite of

security software in an attempt to prevent tampering dur-

5

ing the generation of install cards. This suite is called

SIS (or “Subsistema de Instalac¸ ˜

ao e Seguranc¸a”) and is

provided by the Brazilian company Modulo Security.

3 The hacking challenges

The Public Security Tests of the Brazilian voting system,

or TPS – “Testes P´

ublicos de Seguranc¸a” in Portuguese,

allow independent experts to evaluate the security mech-

anisms implemented in the voting system. Experts at-

tempt to violate the classical security goals of any vot-

ing system, namely ballot secrecy and integrity, and are

asked to later suggest proper improvements to restore the

security of the affected mechanisms. The format and

scope of the event evolved with time, and the challenges

recently became mandatory as an official event in the

election calendar.

3.1 History

In the first edition of the TPS, organized in 2009, re-

searchers did not have access to the source code of the

voting machine software and the chosen model was a

competition with money prizes. As a result, the winning

strategy by Sergio Freitas da Silva was a black-box at-

tack against ballot secrecy using a radio receiver to cap-

ture keyboard emanations [11]. Afterwards, the electoral

authority reportedly shielded the keyboard as mitigation.

In 2012, independent experts had the first opportunity

to examine voting machine software source code with-

out NDA restrictions. The format of the challenge was

slightly tweaked and monetary awards were discontin-

ued. The reduced limitations were enough to bring out

the first vulnerability reports concerning the software. In

particular, the winning attack strategy was an accurate

in-order recovery of the votes cast, successfully mounted

in a realistically-sized simulated election. The attack

was based only on public data published in the DRV

file and superficial knowledge about how the votes were

stored in a hash table. The main attack vector was a

vulnerability in the vote shuffling code involving a call

to srand(time(0)) with a subsequent printing of the

timestamp in the zero tape. With knowledge of the times-

tamp and the order of voters in the voting queue, it would

be possible to break ballot secrecy for an entire polling

station. Alternately, by obtaining the time an important

vote was cast (by a judge or some other authority), it

would be possible to discover the position of the voter

in the queue using the LOG file and break ballot secrecy

for the selected voter. Other detected design flaws in-

clude massive sharing of cryptographic keys, insecure

storage of secret key material and inadequate choice of

algorithms. Aranha et al. [2] provide a detailed first-hand

account of the event, vulnerabilities and aftermath.

The challenges resumed only in 2016, when the NDA

introduced in that edition ended up alienating a large por-

tion of the local technical community. This edition saw

the first successful attack against the integrity of results,

presented again by Sergio Silva [13]. He demonstrated

how checksums implemented in the poll tapes did not

provide authentication, allowing anyone with knowledge

of the underlying algorithm to compute correct check-

sums for fake results. The manipulated results could then

be transmitted to the central tabulator using a subsys-

tem used to transmit results whenever the voting machine

malfunctions.

After substantial pressure from the technical commu-

nity, the NDA was considerably relaxed in the subse-

quent year, to allow participants to publicly discuss their

findings after coordinated disclosure of any vulnerabili-

ties detected during the event. The scope was also ex-

tended to include software components from the tabula-

tion system, the MSD firmware and the GEDAI system

for generating install cards. Although it has been pro-

gressively deployed in the past ten years, the fingerprint

identification system is still considered out of scope.

3.2 The 2017 edition

This work reports our findings collected during last

year’s edition of the TPS. It was comprised of five main

phases: registration and pre-approval, code inspection,

submission of testing plans, the actual trials, and the re-

porting of results. Rules were described in an official

call for participation published in the SEC website [14].

Multiple committees were involved in the organization,

the main ones were the organizing committee composed

of SEC staff, and an independent overseeing committee

who monitored progress of the participants.

During the registration phase, between August 10 and

September 10, individual researchers and teams up to

five members submitted their identification information

and institutions they officially represented. Although the

SEC states that any Brazilian citizen over 18 years is eli-

gible, there is a screening process in place: only after the

SEC verifies the documents and pre-approves the appli-

cants, they become able to inspect source code.

The code inspection phase started with an opening talk

by the SEC staff describing the rules of the challenge

and an overview of the system and its implemented secu-

rity mechanisms. Teams with pre-approved registration

whose members signed the NDA were allowed to spend

four days at the SEC headquarters in Bras´

ılia, between

October 3 and 6, inspecting the source code. Participants

were allowed to use only computers and tools provided

by SEC and take notes on paper. A metal detector pre-

vented entrance of memory devices for copying the code-

base, but there was no rigorous control about what pieces

6

of paper entered or left the inspection environment. The

inspection computers were offline, but connected com-

puters were available in a different section of the room

for Internet access. Figure 4 presents a layout of the

room and its main sections. The rules explicitly stated

that researchers would not have access to cryptographic

keys [14].

In the next phase, each individual or team had to sub-

mit at least one testing plan to be formally approved as

a participant. A testing plan must explain the intended

attack in some detail, what portion of the attack surface

of the system was targeted, the possible outcome in case

of success, and the potential impact in the electoral pro-

cess. All attacks described in a testing plan must be

within the scope defined by the organization. The SEC

then decided what testing plans were compatible with the

rules, selecting which teams were allowed to take part

in the event, with a maximum of 25 participants. There

were tie-breaking criteria for when the capacity would be

reached, such as prioritizing teams who did not ask for

travel expenses to be covered. The authors did not ask

for a stipend to maintain financial independence and in-

crease likelihood of selection. At the end, after merging

participants from different groups, a total of 16 partic-

ipants were finally approved, consisting of 4 individual

researchers and 3 teams (labeled Group 1 – the authors,

3 and 4).

Group 1

Group 4

Internet-connected computers

code inspection

computers

Metal detector

Group 3

SEC staff

Figure 4: Layout for the room where the TPS was con-

ducted, highlighting the areas for Internet access, code

review and the stands where groups worked in the trials.

Group 4 was formed by merging Group 2 with individual

participants from the Brazilian Federal Police.

During the trials, teams had five days to execute the

previously submitted plans, between November 27 and

December 1, from 9AM to 6PM. The first day was re-

served for preparing the environment and tools. The

other four remaining days were used for executing the

testing plans against the system, again using SEC com-

puters. The execution of each step of the plans was

closely followed by SEC personnel, and every action

and result were recorded in a log. If a team decided

that some aspect of a testing plan had to be changed,

a modification had to be submitted and approval ob-

tained by the overseeing committee. In the beginning

of this stage, access to paper became tightly controlled

and numbered sheets were distributed to all participants.

All pages were checked at the end of each day to prevent

code portions from being exfiltrated through paper. Ad-

ditionally, leaving the code inspection area to the stands

or Internet-connected computers with notes containing

pieces of source code was not allowed.

The whole process was painfully bureaucratic and

many forms had to be filled and signed by the team leader

along the way: submission of modifications or entirely

new testing plans for approval; software requisition, to

ask software to be installed in the testing machines; au-

thorization for external materials to enter the testing envi-

ronment; authorization for installing software brought by

the participants; official inquiry to the organization com-

mittees, to ask technical questions and clarify operational

issues; notification of vulnerabilities and mitigation; and

experimental conclusions in the last day. For each new

request, a sequential number had to be obtained and re-

served in a centralized control sheet before submission.

After the public security tests were finished, two re-

ports were published. The first one, written by the over-

seeing committee, contains the results obtained by indi-

vidual teams and suggestions for improving the public

test as a whole [10]. The second report was written by

SEC staff and discusses the vulnerabilities found by re-

searchers and the measures taken by the SEC for mitiga-

tion [16].

4 Chronology

This section presents our day-to-day progress when par-

ticipating in the TPS, from before the event (code inspec-

tion and preparation of the testing plans) to the actual

trials (the five days of testing).

4.1 Code Inspection

In accordance with the event schedule, we were able

to inspect the source code of the voting system. In-

spection was performed in the computers provided by

the SEC, with Ubuntu 14.04 and some software already

7

pre-installed, such as the Eclipse development environ-

ment, a Python interpreter and the standard command

line tools. We were not able to enter or leave the code in-

spection area with any electronic material nor any digital

storage media (not even read-only media). For example,

we could not bring the source code of a vanilla Linux

kernel to check for differences with the SEC custom ker-

nel. We were not able to install other software in these

machines, like more powerful text editors such as vim4,

a C compiler, neither any of our preferred tools.

The main tools we used for searching vulnerabilities

were the grep5command and the nano6text editor. We

quickly realized that some symbols and files were miss-

ing, such as the bootloader source code. We were sur-

prised to find out that the SEC staff restricted access

to cryptographic keys by attempting to remove all key

material from the source code, thus presenting a modi-

fied and incomplete codebase to the participants.

Using grep, we found many potential vulnerabilities.

An important one was related to the file system encryp-

tion scheme used for the install cards. It employed an

encryption scheme based on 256-bit AES-XTS, but the

keys were hard-coded into the kernel. To encrypt, AES-

XTS uses two keys, as presented in Figure 5. Below

we describe each of the variables observed during the

inspection of the encryption scheme:

•key1: First part of the AES-XTS key. It is 256 bits

long and its value was hard-coded into the kernel.

•key2: Second part of the AES-XTS key. It is also

256 bits long and was computed in accordance to

Listing 1, where the get byte(n)function returns the

n-th byte from the first partition of the install card.

•i: The initialization vector. During the code inspec-

tion, we noticed that iwas chosen as the inode num-

ber of the file being encrypted in the file system.

•αis the primitive element of GF(2128 ), where GF

denotes Galois Field.

•Pj: The j-th block of plaintext. All blocks except

possibly the last one have a length of 128 bits.

•Cj: The j-th 128-bit block of ciphertext.

The SEC implementation of AES-XTS deviates from

the standard one in that it computes αjmod256 instead

of αj. This actually weakens the algorithm, since in-

ternal state is now restarted at every 4096-byte block.

As we were unable to find any technical justification for

this change, we suspect it was an attempt at obfuscation.

4Vim – the ubiquitous text editor: http://www.vim.org

5GNU Grep: https://www.gnu.org/software/grep

6GNU Nano text editor: https://www.nano-editor.org

AES

Encrypt

AES

Encrypt

Figure 5: Install card file system encryption scheme

based on AES-XTS (adapted from [22]).

Listing 1 Obtaining key2used to encrypt/decrypt the in-

stall cards using AES-XTS.

function GE T KE Y2

key2← {}

o f f set1←512 +7

o f f set2←512 +128

b←get byte(o f f set1)

for n←0to 32 do

key2[n]←get byte(o f f set2+n)⊕b

return key2

The decryption uses the same block scheme presented in

Figure 5. The only difference is that the ciphertext now

serves as input (in place of Pj), and the plaintext is ob-

tained as output (in place of Cj).

Despite cryptographic keys being removed by the SEC

staff, the file system encryption key key1was still visible

in the 3.18 branch of the kernel due to an operational flaw

during the sanitization of the codebase. At this point,

we also knew it was possible to extract key1by reverse

engineering the kernel (after it is decrypted by the boot-

loader).

4.2 Submitted testing plans

We submitted and had approved four test plans ranging

from retrieving cryptographic keys to using extraneous

USB devices for manipulating the voting system. Each

one is described in detail in the next subsections, and they

illustrate how large is the attack surface of the system.

Extraction of cryptographic keys. During the code

inspection phase, multiple references to cryptographic

keys were found in the source code, although most of the

particular files containing the definitions were removed

8

from the available source. Because cryptographic keys

are shared among all DRE machines, obtaining the key

from a single card means that all DREs could be com-

promised.

This test plan consisted of, through reverse engineer-

ing, trying to extract the cryptographic keys using only

the install card used for distributing and installing the

voting software. The keys could later be used to decrypt

sensitive files or authenticate files containing fake results.

Breach of ballot secrecy. In a previous challenge,

Aranha et al. found a vulnerability that allowed to vi-

olate ballot secrecy for entire polling places or selected

voters [2]. This was possible because the pseudo-random

number generator used for shuffling votes in the DRV

was seeded with a timestamp, a predictable value. This

value, easily obtained from the zero tapes, allowed the

reversal of the shuffling algorithm and the obtaining of

the votes in the same order that they were cast. After the

2012 edition of the hacking challenges, the SEC report-

edly replaced the shuffling mechanism with a new one.

This testing plan consisted of checking if this vulnera-

bility was indeed fixed and that the DRV pseudo-random

number generator was improved to protect ballot secrecy.

Insertion of malicious USB devices. The DRE has

two USB ports in the main voter terminal and another

one in the election official terminal. All of those are con-

nected to the same bus shared by internal USB devices,

including the MSD. The MSD is actually an ARM7 mi-

crocontroller exposed to the system as an USB Human

Interface Device (HID). Both the firmware and the de-

vice drivers for the MSD are custom-made for the DRE.

Although the device drivers implement a challenge-

response protocol aiming to authenticate the presence of

the HSM, we found during code inspection that the pars-

ing code in the driver apparently lacked bounds check-

ing and did not appear to be carefully designed to avoid

buffer overflows.

This testing plan consisted of using programmable

USB devices, like Raspberry Pi Zero and FaceDancer,

to impersonate the MSD. By fuzzing its communication

protocol, potential code execution vulnerabilities [23]

could be found.

Remote code execution on the web platform. The

web platform of the tabulation system was part of the

scope of the tests for the first time. The platform is com-

prised of two main components: RecArquivos, the appli-

cation which receives and processes the digital version

of the poll tapes produced by the voting machines, and

InfoArquivos, the application which monitors the tab-

ulation status. Access to the web platform is allowed

only through a VPN, however the VPN credentials could

probably be extracted from the JE Connect LiveUSB de-

signed by the SEC to set up the VPN connection from

inside insecure networks.

Both web applications are hosted in JBoss 6, an ap-

plication server for which multiple vulnerabilities have

been disclosed [17]. The SEC did not reveal which re-

lease of JBoss 6 was running on their servers, so we

planned to scan for these vulnerabilities in order to check

whether the servers had the latest patches applied. We

also intended to check the web applications source code

for other potential Remote Code Execution vulnerabili-

ties. Compromising those servers could allow for tam-

pering with tabulation results. Although results could

probably be corrected afterwards by checking the paper

version of poll tapes, the attack would potentially slow

down and undermine trust in the electoral process.

4.3 Day 1: Assembling the work environ-

ment

In the beginning of the first day, November 28, we spent

a few hours filling paperwork and some time recogniz-

ing the testing environment and the equipment available.

The routine of filling forms, realizing that we missed

some important package or dependency, and asking for

authorization of new incoming software would repeat in

the following days. We quickly realized that the single

computer provided by the SEC would not be sufficient

for the whole team to work and asked for more com-

puters running Ubuntu. This was another opportunity to

review the source code, since it had been a few weeks

since the end of the code inspection phase. We decided

to switch all machines to Kali Linux7and took notes on

what to bring on the next day in terms of software and

equipment.

We also made progress decrypting the install cards.

Because we were not absolutely certain that the value

of key1found in the source code was correct, we quickly

wrote a small Python decryption script in the code in-

spection computers invoking command-line OpenSSL8

to decrypt each individual block. Due to the unavailabil-

ity of real install cards at that point and a C compiler in

the code inspection computers, we tested the program on

an encrypted stub file we found in the codebase. The

program was painfully slow due to the constant spawn

of child processes, but sufficient to validate our hypoth-

esis. Handling padding was a nuisance, because addi-

tional bytes were added to fill the last block and written

to the file system, but the reported file sizes did not take

those into account.

7Kali Linux – Penetration Testing and Ethical Hacking Linux Dis-

tribution: https://www.kali.org

8OpenSSL Cryptography and SSL/TLS Toolkit: https://www.

openssl.org

9

4.4 Day 2: Decrypting install cards

With new computers, we started the day by installing

Kali Linux in all machines, a very time-consuming pro-

cess which took the whole day. In parallel, we continued

to explore the testing environment. We also received a

somewhat distracting visit of international observers in-

vited by the SEC to follow the challenge.

Our first attempt was to plug a regular keyboard from

the regular computers in one of the USB ports of the

voting machine. With this, we could observe that the

keys pressed were echoed in the screen during the boot

process, and therefore, we concluded that the machine

had hardware and driver components that enabled the

usage of regular USB keyboards. However, using se-

quence keys like <Ctrl> + <Alt> + <F1> and others,

we were not able to drop in a terminal. We then started

following our testing plans.

For the first one, named “Extraction of cryptographic

keys”, the idea was to try to decrypt the real install cards

with the key1value found during the code inspection

stage. If that went wrong, we would try to get the cor-

rect key1value through reverse engineering of the boot-

loader and kernel image. We generated an install card

using the provided GEDAI machine and reimplemented

the AES-XTS decryption program, memorizing and typ-

ing down the decryption key a few bytes at a time. We

ended up rewriting the whole program by adapting code

from another AES-XTS implementation [25] to increase

performance.

In our first decryption attempt, we chose to decrypt

an Extensible Linking Format (ELF) file called initje,

a modified version of the Unix init daemon, because

we knew how the header format (also known as magic

number) looked like. In this first attempt, the decryp-

tion was successful, i.e., we obtained a file with \x7fELF

as the initial bytes. After that, we wrote a script to de-

crypt/encrypt files in the install card, and proceeded to

inspect them looking for additional vulnerabilities to es-

calate access.

4.5 Day 3: Executing our code

During the third day, we better analyzed the chain of trust

established by the DRE voting machine. Basically, sub-

systems verify signatures of subsystems running next, as

shown in Figure 3. The process starts with the verifica-

tion of the BIOS signature by the MSD and ends with

the validation of single files using a detached signature

file with extension VST.

VST files contain file paths along with their signatures

in a custom binary format, described in ASN.1 syntax.

During the installation and initialization of the voting

machine, the files with entries in the VST are checked

and the signatures validated. We observed that extrane-

ous files could be added to the install card without trig-

gering any security alert.

By inspecting the VST files we noticed that two

shared libraries used by the voting system did not

have corresponding detached signatures. These were

used for logging (libapilog.so) and HMAC-based

Extract-and-Expand Key Derivation Functions (HKDF)

(libhkdf.so). We checked that this was indeed an at-

tack vector by first replacing the opcodes of the functions

in the two libraries by an exit system call, observing the

installation was interrupted as expected. This possibility

of arbitrary code execution was the main attack vector

used throughout the rest of the challenge.

During the rest of the day, other tests were made so

the SEC staff could validate and register our findings.

We observed which infected function was the first one

to be called, and in one of the attacks, a custom text

was printed in the terminal presented during the sys-

tem initialization. Using the write syscall outputting

to stdout, we printed the text “FRAUD!” in the termi-

nal. Extending the attack, a simple read-echo loop was

created in order to show the possibility of using a regular

USB keyboard, writing into the stdout messages read

from stdin.

At the end of the second day, our team decided to

abandon the other testing plans to focus on the recently

acquired capabilities obtained after the decryption of in-

stall cards. Because the first testing plan was already

considered successful, we submitted two more, called Vi-

olation of ballot secrecy for selected votes and Arbitrary

code execution in the DRE voting machine, which were

an escalation from the success in the first one.

4.6 Day 4: Manipulating logging, violating

ballot secrecy for selected voters

After exploring the possibility of running arbitrary code

and using a regular USB keyboard in the DRE voting

machine, the next attack was to include a full-featured

shell like BusyBox9in order to make it easier to de-

bug the running system and prototype new attacks. The

first attempt was adding the binary into the install card,

which allowed storing non-signed files, and executing it

through the execve syscall. This attack was unsuccess-

ful because, before executing a binary, the kernel checks

for a signature appended in the end of the file. Since the

BusyBox binary was not signed, the kernel disallowed

the execution. The second attempt was to embed the shell

inside one of the non-signed shared libraries. This was a

promising idea, but since our attack vector was already

relocated in memory, we needed to either implement an

9BusyBox: https://busybox.net

10

ELF loader or modify the whole binary to be position-

independent code. Because of the time constraints and

limited tooling, we did not pursue this idea further.

To illustrate other possibilities of exploiting our code

injection, we performed more attacks to the DRE ma-

chine. In the first one, the constant string INFO of the

logging library was replaced by the XXXX string, show-

ing the possibility of modifying events in the LOG. We

verified the success of the attack by simulating an en-

tire election and observing the modifications in the cor-

responding file stored in the MR.

In another attack, we infected the HKDF library to

force the derived cryptographic keys to be known values.

The HKDF algorithm was used as the key derivation al-

gorithm for encrypting the DRV. This file contains every

vote cast in the voting machine and is randomly shuffled

in order to avoid the identification of votes based on se-

quential observations. We replaced the opcodes of the

key generation function with the opcodes of the follow-

ing instructions: xor eax, eax; ret. This code just

returns the function without any errors. Since the func-

tion was supposed to store the generated key in a C++

vector passed as argument, this code is equivalent to just

returning a zeroed key, since the std::vector construc-

tor initializes the content with zeros when only the count

argument is supplied.

With the library always producing a zeroed key, the

DRV file could be trivially decrypted. During the elec-

tion, a temporary version of this file is stored both in in-

ternal memory and the voting card. Since the voting card

can be manually removed from the voting machine with-

out serious consequences, this file could be copied and

decrypted, with differences computed at every vote, thus

allowing for the violation of ballot secrecy. We demon-

strated this attack to the SEC staff in the context of at-

tacking selected votes (by judges, politicians or other fig-

ures of authority), since extracting cards during the elec-

tion might raise suspicion. The attack against ballot se-

crecy could have been further improved by injecting code

which automates the manual activities and stores the dif-

ferences in chronological order inside the voting card.

With the intent of compromising the memory space of

the voting application itself (VOTA), we tried to stati-

cally analyze its binary using a disassembler, in order to

look for addresses of interesting code excerpts or global

variables in the compiled application. However, the bi-

nary was packed with UPX10 and could not be unpacked

by the standard UPX command line tool. Thus, we de-

cided to bring the UPX source code on the next day to

facilitate debugging of the unpacking issues.

10UPX: the Ultimate Packer for eXecutables – https://upx.

github.io

4.7 Day 5: Tampering with screen contents

and votes

In the morning, we received a formal visit of the presi-

dent of the SEC and were asked to give a live demonstra-

tion to the overseeing committee of progress so far. The

increased media coverage was distracting and greatly im-

paired our team’s ability to concentrate on the work. De-

spite that, we proceeded to debug the binary unpacking

issue found in the previous day, and it turned out to be

a simple matter of UPX getting confused by the digital

signature appended to executables. Removing the sig-

nature allowed us to normally unpack binaries using the

standard UPX tool.

With the unpacked VOTA application binary at hand,

we noted that it lacked common exploit mitigation tech-

niques, because it was not in a Position Independent

Executable (PIE) format. This simplified our work for

exploitation because targeted contents were in fixed ad-

dresses, eliminating the need to compute addresses from

the process memory mappings. However, both of the un-

signed libraries which could be used as attack vectors

were linked against multiple executables, whereas we

wanted to compromise just the VOTA application. We

chose to insert our payloads in the HKDF library, which

was linked to only two of the executables – SCUE and

VOTA. In order to check whether the library code was

running inside the memory space of VOTA, we read a 32-

bit word from some address which exists both in SCUE

and VOTA but contains different values in each appli-

cation. If it detected our code was not running inside

VOTA, it would just jump and skip the payload.

In order to verify whether we would be able to use the

mprotect syscall to change the permissions of read-only

memory pages, we wrote a payload to modify VOTA’s

version string, located in its .rodata section. The orig-

inal string was “The Hour of the Star”, but we modified

to “The Hour of the Threat” (in Portuguese, “A Hora da

Treta”). The test was successful and the new string could

be found in the installation log and inside the Memory of

Results (MR).

To escalate this simple payload to a useful and vis-

ible attack, we decided to modify a string in the voter

screen, which is clearly visible during the voter’s interac-

tion with the equipment. The selected string was “YOUR

VOTE GOES TO” (in Portuguese, “SEU VOTO PARA”).

A reproduction of the DRE screen after this attack is

shown in Figure 6(b) – at the top left corner, a message

appears asking the voter to cast a vote for candidate num-

ber “99”.

Once the ability to modify any desired memory page

was demonstrated, we proceeded to improve the HDKF

library infection technique. Until this moment, we sim-

ply overwrote the hkdf() library function which actu-

11

(a)

(b)

Figure 6: Reproduction of the in-memory modification of one of the strings contained in the VOTA application. (a)

Original DRE. (b) Compromised DRE – the voting software now advertises the choice of a hypothetical candidate.

ally computes a key. Because of this, our payloads al-

ways caused the DRV key to be zeroed, similar to the

attack against ballot secrecy described in Section 4.6.

Although an apparently corrupt DRV file would hardly

raise any suspicions, since the DRV file is only inspected

when an audit is performed, we implemented a method to

avoid this drawback by preserving HKDF functionality.

As illustrated in Figure 7, we replaced the SHA-224

implementation (which was present in the library but

not used by any of the applications) with our payload.

Then, we overwrote just an excerpt of the hkdf() code

with instructions for redirecting the execution flow to

the SHA224Init function, which address we compute

into the eax register taking into account that, unlike the

main executable, the library contains Position Indepen-

dent Code (PIC) and is loaded at a random address. Af-

ter running the payload, the SHA224Init function re-

stores eax to its original value, runs a copy of the origi-

nal excerpt moved from hkdf(), and returns. Since the

ret instruction pops the stack, an excerpt containing in-

structions that manipulate the stack would present issues,

however we fortunately did not face this problem.

add eax, SHA224Init - A

call eax

A:

; payload added here

sub eax, SHA224Init - A

ret

code

moved

hkdf:

SHA224Init:

push ebp

mov ebp, esp

; [...]

call __x86.get_pc_thunk.ax

; [...]

pre-existing

code

Figure 7: A simple library code infection technique we

employed to furtively compromise libhkdf.so.

Continuing to analyze the VOTA binary with a

disassembler, we found a method called AddVote

(in Portuguese, “AdicionaVoto ”) with signature

void(uint8 t office, int type, std::string

&vote). This method was called only when the vote to

be cast was already rendered on the screen and the voter

pressed the DRE’s confirm button. In other words, it was

possible to modify its behavior to change votes before

storing them, without the voter ever noticing anything

abnormal.

To compromise AddVote(), we wrote a Python script

to generate a payload to infect the method with the code

presented in Listing 2. This code loads in eax a ref-

erence to the std::string which holds the vote, then

loads to edi a pointer to the string’s characters, and fi-

nally writes a ‘9’ character to two subsequent memory

addresses (starting at edi).

Listing 2 Code injected in the AddVote method to ma-

nipulate votes in favor of candidate number “99”.

mov eax, [ebp+0x14]; std::string&

mov edi, [eax]; char*

mov al,'9'

stosb

stosb

Nevertheless, when we tested that payload in the DRE,

it caused a segmentation fault just before the VOTA ap-

plication was expected to appear in screen. Since that

meant the AddVote() method was never actually called,

we quickly found the mistake. To overwrite AddVote(),

our Python script was issuing lodsb/w/d instructions

instead of stosb/w/d. As esi contained zero (we cor-

rectly loaded the address to edi), this caused a null

pointer dereference.

Testing a new payload in the DRE took more than 30

minutes due to the sanity self-checks required by the in-

stallation process. Therefore we decided a member of

our team would test a simpler payload, which just re-

placed the AddVote() method with the ret instruction

12

opcode, while another member would simulate the com-

plete payload in the computer, to ensure no more typos

were present before loading it into the DRE.

Since the simple payload prevented votes from being

stored in the electronic ballot (a std::vector contain-

ing votes for all the election offices), we observed the

following behavior when it was loaded in the DRE: the

voter could type and confirm votes for all the offices,

however just after pressing the confirm button for the last

office, a consistency check triggered an alert message in

the DRE screen stating that the ballot was empty.

Although the complete payload worked correctly

when simulated in the computer without requiring any

further bug fixes, the tests were interrupted on time at

6PM and we were not allowed to proceed testing it on

the DRE voting machine.

5 Discussion

DRE voting machines are largely criticized in academic

literature, mainly due to its design and implementation

flaws, and because these electronic voting systems do

not allow for external audits/recounts in case the election

outcome is disputed. Models manufactured by Diebold

were especially subject of multiple security analysis [9].

The impact of the vulnerabilities discovered ranged from

manipulation of election results to viral infection of vot-

ing equipment. Most of the problems were a direct result

of insecure engineering practices and the enormous com-

plexity of the voting software, comprising around a mil-

lion lines of source code. Other works focused on com-

parably simpler voting systems found similar problems,

such as the software attacks on Dutch Nedap DRE ma-

chines by Gonggrijp and Hengeveld [18], and hardware

attacks against the Indian EVMs discussed by Halder-

man et al. [26]. Paper records are not a panacea either,

and hybrid systems with electronic and physical records,

such as the one used in parts of Argentina, were also

found vulnerable to realistic attacks when analyzed by

academics [1].

Most of the publicly available literature regarding the

Brazilian system has scope limited to official voting pro-

cedures, election legislation and informal analysis. The

Brazilian Computer Society (the national equivalent of

the Association for Computer Machinery – ACM) com-

missioned a report in 2012 which found important con-

cerns about the security and transparency guarantees of

Brazilian electronic elections [19]. The report suggests

many improvements to the election workflow, but no de-

tailed software vulnerabilities were discussed, although

the authors had the opportunity to observe some software

development inside the SEC.

Until recently, only inspectors from political parties

had the clearance to examine the voting software source

code during a time period before the elections. For this,

they must sign an NDA which prevents any public disclo-

sure of the problems observed in the code. These limita-

tions explain the lack of rich literature about the security

features of Brazilian DRE machines.

The report published by Aranha et al. after the 2012

edition of the TPS [2] was the first technical document

containing a detailed analysis of the security mechanisms

implemented in the voting system. However, the report

focuses more on the vulnerabilities of the ballot shuffling

mechanism and how the researchers were able to exploit

them under the restrictions of the hacking challenge, al-

though some discussion is dedicated to point out the in-

secure storage of cryptographic keys and inherent lim-

itations of the software integrity checking mechanism.

Our work should help filling this gap and to accurately

update the state of Brazilian voting technology to the in-

ternational technical community. We split the discussion

in the software integrity and ballot secrecy properties and

finish arguing how our results invalidate official security

claims published by the SEC.

5.1 Software integrity

Decrypting the install cards was all that was needed to

discover two shared libraries without detached signa-

tures, and thus amenable for arbitrary code injection at-

tacks. Circumventing the encryption mechanism thus

gave disproportionate capabilities to an attacker, an un-

expected effect. Although we obtained the encryption

key directly from the source code, which greatly accel-

erated our progress, we claim that an external attacker

would also be able to recover the encryption key embed-

ded in the bootloader and proceed with decrypting the

kernel image. On possession of a decrypted kernel im-

age, the attacker would become capable of both decrypt-

ing the install cards and removing the second encryp-

tion layer protecting the application-level authentication

keys. The latter provides a huge amount of power to the

adversary, who becomes capable of forging files and cor-

responding digital signatures protecting poll tapes, soft-

ware components, the LOG and the DRV. Interestingly,

in the last day of the hacking challenges, Group 4, com-

posed of forensic experts from the Brazilian Federal Po-

lice, was able to recover the kernel image in plaintext

through reverse engineering by moving the bootloader to

a standard address and running it inside a virtual machine

emulator.

We thus conclude that the integrity of software, and

consequently the results, depends ultimately on the se-

crecy of a symmetric key embedded into the bootloader.

This key is trivially accessible by the whole voting soft-

ware development team, and is visible to external attack-

ers because it is stored in plaintext inside the install cards.

13

In fact, this mechanism does not amount to encryption

per se, but only to a much weaker form of obfuscation. In

retrospect, these vulnerabilities are not exactly new. The

report by Aranha et al. [2] already pointed out how the

file system encryption keys were insecurely stored in the

source code in the 2012 version of the voting software.

At that time, the same key and initialization vector (IV)

were shared among all voting machines, for encrypting

files using AES-256 in CBC mode. The only improve-

ments we observed in the 2017 version were switching

to variable IVs and adopting the XTS mode.

The two shared libraries without detached signatures

were not signed because generating the list of files to

be signed is apparently not an automated process. In

their report, the SEC development team states that the

libraries still had kernel-level RSA signatures appended

to the files, but a bug in the verification code (and its

unit test) prevented the manipulation to be detected [16].

This suggests a development process in need of urgent

revision of its critical procedures.

The staff also states that cryptographic keys for en-

crypting the file system will not be hard-coded anymore

in future versions of the software, but computed on-the-

fly with help of the BIOS [16], increasing the level of

obfuscation. This design choice was justified by the

SEC with observing that not all voting machines have

the MSD device available, which limits the possibility of

using its idle space for storing cryptographic keys. Be-

cause of the imposed requirements that any voting ma-

chine must be able to replace any other voting machine

on election day, it is considered risky to have different

versions of the software in operation. This suggests fur-

ther that overall security of the system is dictated by the

oldest model in operation, in this case the 2007 one with-

out the MSD.

We recommend the SEC to revise its development pro-

cess, adopting best practices by automating critical pro-

cedures and implementing negative testing countermea-

sures. The list of files to be signed should not be gener-

ated by manually hard-coding file names in a script, and

testing of signature verification should not only be eval-

uated under ideal circumstances (correct key and mes-

sage). We further recommend the install card encryption

keys (and other cryptographic keys) to be segregated in

the minimal unit possible (polling place, neighborhood

or city), to reduce overall impact in case one of these

keys leak. In the longer term, a key distribution architec-

ture should be implemented and all cryptographic keys

should be moved inside the MSD security perimeter.

5.2 Ballot secrecy

The DRV file stores a table separated into sections, where

each section is devoted to a different race. This table

shuffles the votes cast by the voters to disassociate the

order of the voters and their votes. It was introduced by

law to replace the paper trail after failure of implement-

ing paper records in 2002. As claimed by the SEC, it

supposedly permits independent verification of election

results [12], but the file is produced by the same software

which tallies the votes. Any successful attack against the

tallying software can also compromise the integrity of

the DRV. For this reason, Aranha et al. [2] concludes that

the DRV file does not serve any security purpose besides

violating ballot secrecy if designed or implemented in-

securely. For this reason, preventing attacks against the

DRV relies on the implementation of a secure random

number generation algorithm.

There are multiple such algorithms being used across

the code base to satisfy the randomness needs of the

plethora of cryptographic primitives for encryption and

authentication deployed in the voting software. The El-

gamal signatures computed by the MSD rely on the weak

xorshift family [21] of pseudo-random number gener-

ators (PRNG). The mechanism for shuffling votes inside

the DRV file, a critical component for ballot secrecy, was

implemented through a combination of two other gener-

ators: reading directly from /dev/urandom or from a

customized PRNG based on a 32-bit variant of the 64-bit

version of the obscure Sapparot-2 algorithm [20]. The

generator alternates between the two algorithms in case

any of them fails. In its original version, the Sapparot-2

algorithm is clearly not suited for cryptographic applica-

tions, as explicitly advertised by the author 11.

Although a significant improvement over the

previous shuffling mechanism implemented with

srand()/rand(), the modifications we observed

are clearly not sufficient. Even if the new version of

the implemented mechanism appears much harder to

exploit due to frequent mixing of operating system

entropy in the internal state, the inadequate choice

of algorithms after five years of development looks

surprising. The replacement algorithm was not vetted

by the cryptographic community and does not satisfy

minimal security requirements for such a critical file.

The recommendations in the previous report were not

fully adopted, since the file layout still lacks defense-

in-depth protections by removing unused slots in the

DRV table and the PRNG remains nonstandard [2].

We reinforce the same recommendations, assuming

that the DRV must still be produced to satisfy legal

requirements: (i) remove unused slots corresponding to

absentees to prevent exhaustive search in the seed space;

(ii) adopt stronger standardized PRNG algorithms or

read from /dev/urandom directly, if collected entropy

is of enough quality. In the longer term, we further and

11Sapparot-2: http://www.literatecode.com/sapparot2

14

again recommend the DRV file to be eliminated, and the

law to be changed.

5.3 Security claims

There is no document formalizing the threat model or se-

curity goals considered by the SEC during the develop-

ment of the electronic voting system. This complicates

security analysis, since the adversary becomes a mov-

ing target, conveniently changing depending on the at-

tack under discussion. Fortunately, the SEC published a

Q&A document defending some of the security mecha-

nisms [12], in response to the results obtained by Aranha

et al. [2]. This document is a very useful resource to

understand the rationale behind some of the design de-

cisions. As with any paperless DRE system, all security

properties ultimately depend on integrity of the voting

software and hardware, and their resistance against tam-

pering. Our results in this paper contradict several of

the claims in that document, as we elaborate below. The

original writing is in Portuguese, but we attempt to pro-

vide translations as close as possible.

The second question in page 10 states the security goal

concerning software integrity:

It is not possible to execute unauthorized ap-

plications in the voting machine. Along the

same way, it is also not possible to modify an

application in the machine.

Our attacks were able to include additional files and

modify two shared libraries in the install card, with the

software installation process being completed without

any hassle. The software installed in the machines pre-

served the intended modifications and its execution later

violated the integrity of running software.

Pages 12-14 give details about the adversarial model:

The voting machine is not vulnerable against

external attackers. (...) This is guaranteed by

several security mechanisms, based on digi-

tal signatures and encryption, which create a

chain of trust between hardware and software

and prevent any violation of the voting ma-

chine.

DRE voting machines are notably insecure against ma-

licious insiders with control over the voting software.

Our successful attack also demonstrates how an external

attacker in control of install cards can manipulate voting

software before it is installed in the machines. Because

each card installs software in up to 50 voting machines,

this approach has an amplification effect, reducing the

logistic obstacles and cost of a large-scale attack.

Page 22 establishes security goals for the LOG file:

The log file is another transparency and audit-

ing mechanism made available by the SEC.

The fact that the shared library handling log events

lacked digital signatures completely removes the possi-

bility of using the LOG as an auditing mechanism, be-

cause the generated events may be under adversarial con-

trol. An attacker would then be able to erase specific

events or manipulate performance metrics, such as the

false positive rate reported for the fingerprint identifi-

cation system. This is naturally true of any electronic

record, and explains why purely electronic voting sys-

tems are inherently insecure and opaque.

The last question clarifies the expected security prop-

erties of the file system encryption, here transcribed in

more detail:

The objective of the file system encryption is

to impose an additional barrier to an external

attacker with little or no knowledge about the

software organization in the voting machine.

This way, a possible attacker would find obsta-

cles to start analyzing the memory card con-

tents.

There is a single secret key used for encrypt-

ing file systems in all memory cards. If this key

were not unique, it would be impossible to re-

place a malfunctioning machine with another

one, and any auditing in the voting machines

would be compromised. However, stating that

possessing the encryption key makes possible

to generate cards “with different content” is

incorrect.

It is important to note that the file system en-

cryption is not the sole mechanism support-

ing software security in the voting machine.

All files which require integrity and authen-

ticity are digitally signed. This is the case,

for example, of the voting machine applica-

tions and election metadata, and the poll tapes,

DRV, among others. Files requiring secrecy

are also encrypted. In all these cases, other

keys are employed. These signature and en-

cryption mechanisms prevent the memory con-

tents from being manipulated.

The file system encryption is thus claimed to be one

of many security barriers against external attackers. It is

designed as a first obstacle to attackers without much in-

formation about the system, having other cryptographic

mechanisms as stronger defenses against more sophisti-

cated attackers. While the former is technically correct,

since the file system encryption is actually just obfus-

cation, we observed that capturing the encryption keys

15

provided a disproportionate power to the attacker, who

becomes able to choose or reveal more important cryp-

tographic keys. This happened because decryption al-

lowed us to fully inspect the contents of the install card

and detect serious vulnerabilities in the integrity check-

ing mechanism, violating the software integrity claims

and the main security properties of the system as direct

consequence.

6 Conclusion and perspectives

We thank the SEC for the opportunity to contribute with

improving the security of the Brazilian voting machines

and give brief suggestions about how to improve effec-

tiveness of the hacking challenges: minimize the bureau-

cracy and staff intervention during the event; improve

agility of internal processes to authorize entry of docu-

ments and software packages in the testing environment;

enlarge the scope by including the fingerprint identifica-

tion system and parts of transmission/tabulation infras-

tructure; increase the duration of the event and reduce the

dependence on secret source code by making it widely

available. In particular, we ask readers to not extrapolate

the time consumed by our team during the challenges

as an estimate of the time required to mount an attack

against real elections, as the number and impact of artifi-

cial restrictions was substantial.

We conclude by stating that the Brazilian voting ma-

chine software still does not satisfy minimal security and

transparency requirements and is very far from the matu-

rity expected from a 20-year mission-critical system. We

recommend the SEC to carefully revise their develop-

ment practices and consider adopting voter-verified pa-

per trails in the system to provide stronger guarantees

of its correct functioning on election day. We hope that

our findings contribute to the ongoing debate in Brazil

concerning the adopting of paper records as a way to im-

prove security and transparency of the voting system.

Availability

The code written during the hacking challenge and ad-

ditional files can be found in the repository available at

https://github.com/epicleet/tps2017

References

[1] AM ATO, F., OR O, I. A. B., CHAPA RRO , E., L ER NER , S. D .,

ORTE GA, A ., RIZZ O, J., RUS S, F., S MALDONE, J., AND

WAISM AN , N . Vot.Ar: una mala elecci´

on. https://ivan.

barreraoro.com.ar/vot-ar- una-mala- eleccion/, 2015.

[2] ARANHA, D. F., KA RAM , M. M., M IR ANDA , A. , AND

SCAREL, F. Software vulnerabilities in the Brazilian voting ma-

chine. IGI Global, 2014, pp. 149–175.

[3] ARANHA, D. F., RIBE IRO , H., A ND PARAENSE, A . L. O.

Crowdsourced integrity verification of election results - An expe-

rience from Brazilian elections. Annales des T ´

el´

ecommunications

71, 7-8 (2016), 287–297.

[4] AUMASSON, J., AND BE RN STE IN, D. J. Siphash: A fast short-

input PRF. In INDOCRYPT (2012), vol. 7668 of Lecture Notes

in Computer Science, Springer, pp. 489–508.

[5] BAR RET O, P. S. L. M ., AND NAEHRIG, M. Pairing-friendly el-

liptic curves of prime order. In Proceedings of the 12th Interna-

tional Conference on Selected Areas in Cryptography (Kingston,

ON, Canada, Aug. 2005), SAC’05, pp. 319–331.

[6] BE RNS TE IN, D . J., D UIF, N., LA NG E, T., SCHWAB E, P., A ND

YANG, B. High-speed high-security signatures. In CHES (2011),

vol. 6917 of Lecture Notes in Computer Science, Springer,

pp. 124–142.

[7] BO NEH , D., AND BOY EN , X. Short Signatures Without Random

Oracles and the SDH Assumption in Bilinear Groups. Journal of

Cryptology 21, 2 (Feb. 2008), 149–177.

[8] BRAZILIAN SOCIAL DE MOC RAC Y PARTY – PSDB. Re-

port on the Special Audit in the 2014 Voting System. Avail-

able at http://www.brunazo.eng.br/voto-e/arquivos/

RelatorioAuditoriaEleicao2014-PSDB.pdf, 2014.

[9] CALANDRINO, J. A., FELDMAN, A. J ., J . A. HALDERMAN,

D. W., A ND H. YU, W. P. Z. Source Code Review of the

Diebold Voting System. Available at https://jhalderm.com/

pub/papers/diebold-ttbr07.pdf, 2007.

[10] COMMITTEE, T. O. Report of the Overseeing Committee

of the Public Security Tests, 2017 edition (In Portuguese).

http://www.tse.jus.br/hotsites/teste-publico-

seguranca-2017/arquivos/tps2017- relatorio-

comissao-avaliadora.pdf, 2017.

[11] CO URT, S. E. Execution of Testing Plan (In Portuguese).

https://web.archive.org/web/20160107163923/http:

//www.tse.gov.br/internet/eleicoes/arquivos/

Teste_Sergio_Freitas.pdf, 2009.

[12] CO URT, S. E. Frequently Asked Questions (FAQ) about

the Brazilian voting system, 2nd edition (In Portuguese).

http://www.justicaeleitoral.jus.br/arquivos/tse-

perguntas-mais- frequentes-sistema- eletronico-de-

votacao, 2014.

[13] CO URT, S. E. Public Security Tests of the Brazil-

ian Voting System: Compendium (In Portuguese.

http://www.tse.jus.br/hotsites/catalogo-publicacoes/pdf/teste-

publico-de-seguranca-2016-compendio.pdf, 2016.

[14] CO URT, S. E. Call for participation in the Public Security Tests.

http://www.tse.jus.br/hotsites/teste-publico-

seguranca-2017/arquivos/TPS- testes-publicos-

seguranca-edital.pdf, 2017.

[15] CO URT, S. E. Draft of resolution concerning the elec-

toral procedures for implementing a paper trail in the

2018. http://www.justicaeleitoral.jus.br/arquivos/

tse-audiencias- publicas-voto- impresso, 2017.

[16] CO URT, S . E. Vulnerabilities and suggestions for improvement

to the voting machine ecosystem observed in the Public Secu-

rity Tests, 2017 edition (In Portuguese). http://www.tse.

jus.br/hotsites/teste-publico- seguranca-2017/

arquivos/tps2017-relatorio- tecnico.pdf, 2017.

[17] DATABAS E, N. V. JBoss Vulnerabilities. Available

at https://nvd.nist.gov/products/cpe/search/

results?keyword=jboss&status=FINAL&orderBy=

CPEURI&namingFormat=2.3, 2018.

16

[18] GONGGRIJP, R., A ND HEN GE VEL D, W. Studying the

nedap/groenendaal ES3B voting computer: A computer security

perspective. In EVT (2007), USENIX Association.

[19] J. VAN D E GRAA F, R. F. C. Electoral technology and the

voting machine – report of the Brazilian Computer Society (in

Portuguese). Available at http://www.sbc.org.br/index.

php?option=com_jdownloads&Itemid=195&task=view.

download&catid=77&cid=107, 2002.

[20] LE VIN , I. O. Sapparot-2: Fast Pseudo-Random Number Genera-

tor. http://www.literatecode.com/get/sapparot2.pdf,

2005.

[21] MA RSAG LI A, G. Xorshift RNGs. Journal of Statistical Software,

Articles 8, 14 (2003), 1–6.

[22] STAL LI NGS , W. Cryptography and Network Security: Principles

and Practice 7th edition. Pearson, 2016.

[23] STEINMETZ, F. USB – an attack surface of emerging im-

portance. Bachelor’s thesis, Technische Universit¨

at Hamburg,

2015. Available at https://tubdok.tub.tuhh.de/handle/

11420/1286.

[24] SUPERIOR EL ECT ORA L COU RT OF BRAZIL. Resolu-

tion number 23,444 (in Portuguese). Available at http:

//www.tse.jus.br/legislacao/codigo-eleitoral/

normas-editadas- pelo-tse/resolucao- no-23- 444-

de-30- de-abril- de-2015- 2013-brasilia- 2013-df,

2015.

[25] TEUWEN, P. python-cryptoplus, AES-XTS python implemen-

tation. Available at https://github.com/doegox/python-

cryptoplus, 2017.

[26] WOL CH OK, S ., WUST ROW, E. , HALDERMAN, J. A ., P RASAD,

H. K., KA NK IPATI, A., SAKHAMURI, S . K., YAGATI, V., AN D

GONGGRIJP, R. Security analysis of India’s electronic voting

machines. In ACM Conference on Computer and Communica-

tions Security (2010), ACM, pp. 1–14.

17

    • Crowdsourced integrity verification of election results: An experience from Brazilian elections

      Article

      Full-text available

        ◦ Mar 2016

        ◦ 

    • Diego F Aranha

    • Helder Ribeiro

    • André Luis Ogando Paraense

View

    • Software vulnerabilities in the Brazilian voting machine

Chapter

Full-text available

    • Jan 2014

    • 

    • D F Aranha

    • M M Karam

      

==//==

SOURCE/LINK: https://youtu.be/Iz0lXS38WN4

Software Vulnerabilities in the Brazilian Voting Machine

545 visualizações

332COMPARTILHAR

Diego Aranha

Publicado em 29 de ago de 2015

INSCRITO 1,5 MIL

Invited talk at the USENIX 2012 Electronic Voting Workshop/Workshop on Trustworthy Elections

Categoria

Pessoas e blogs

MOSTRAR MENOS

1 comentário

CLASSIFICAR POR

==//==

SOURCE/LINK: https://www.unicamp.br/unicamp/noticias/2018/04/10/pesquisadores-avaliam-limitacoes-de-seguranca-das-urnas-eletronicas

Pular para o conteúdo principal 

Main superior

    • ÁREA DE SAÚDE 

    • FACULDADES E INSTITUTOS 

    • INGRESSO 

    • INFORMAÇÕES PARA... 

Menu Superior Direito

    • En 

    • Loca 

    • Face 

    • Twit 

    • A Universidade 

            ▪ 

            ▪ 

        ◦ 

    • Ensino 

            ▪ 

            ▪ 

        ◦ 

    • Pesquisa 

        ◦ 

    • Relações com a Sociedade 

        ◦ 

    • Mídia & Comunicação 

        ◦ 

Pesquisadores avaliam limitações de segurança das urnas eletrônicas 

10, abr - 2018 | 13:00 

Comunidade interna 

Autor

Valério Paiva

Fotos

Antoninho Perri

Marcelo Carvalho - Agência Brasil

Edição de imagem

Paulo Cavalheri

A segurança nos sistema eleitoral brasileiro e as eventuais falhas que podem acontecer nas urnas eletrônicas foram assuntos debatidos na palestra "(In)segurança do voto eletrônico no Brasil, 5 anos depois", ministrada na última sexta-feira (6) pelo professor Diego de Freitas Aranha, do Departamento de Teoria da Computação do Instituto de Computação (IC), no auditório da unidade. Aranha participou de equipes distintas que atuaram em duas edições do Teste Público de Segurança do Sistema Eletrônico de Votação, organizados pelo Tribunal Superior Eleitoral (TSE) em 2012 e 2017. Nos dois eventos, foi constatada a existência de vulnerabilidades nas urnas eletrônicas do TSE.

Diego de Freitas Aranha, do Instituto de Computação 

Na primeira edição do teste, Diego Aranha atuou na equipe de pesquisadores e funcionários da Universidade de Brasília (UnB), onde era professor. Já em 2017 participou coordenando uma equipe de professores e estudantes de instituições como a Unicamp, Universidade Federal de Campina Grande, Universidade Federal de São Carlos e Universidade Federal de Pernambuco. O grupo de pesquisadores, que trabalhava com habilidades diversas e sob restrições indicadas pelos técnicos do TSE, explorou as diferentes possibilidades de vulnerabilidade do sistema sob diversos tipos de ataques.

Durante sua apresentação no IC, Diego Aranha relatou o trabalho realizado pelas equipes durante os testes de seguranças das urnas eletrônicas, e as falhas que foram encontradas. "Nestas duas edições dos testes encontramos múltiplas vulnerabilidades nos sistemas. Isso nos permitiu explorar e violar as principais propriedades de segurança do equipamento, que são o sigilo do voto e a integralidade do software de votação para que não se comporte de maneira honesta durante a eleição”, explica Diego Aranha.

Público acompanha a palestra sobre segurança das urnas eletrônicas

Diego Aranha também contou sobre as diferenças de leitura entre os pesquisadores e os membros do TSE, que levou a existir alguns atritos. “A relação com a Justiça Eleitoral nem sempre é tranquila, pois muitas vezes eles não encaram de maneira construtiva a crítica técnica de mecanismos de segurança como eles são projetados e implementados no sistema. Acabam fazendo uma política de contenção de danos que não transmite com precisão o que foi obtido nos testes”.

Após a identificação das falhas, o grupo de pesquisadores levantou sugestões para o aperfeiçoamento dos softwares e equipamentos. Entre as propostas apresentadas estão a necessidade de introdução do registro físico do voto verificado pelo eleitor, para uso de auditoria como maneira de minimizar problemas caso alguma das vulnerabilidades fossem exploradas.

Urna eletrônica usada nas eleições brasileiras

Segundo Diego Aranha, outros países utilizam sistemas de votação eletrônicos, mas o Brasil é o único que persiste usando sistemas apenas baseados em máquinas de votar, sem registro físico produzido de cada voto individualizado. “Países que adotaram votações baseadas em máquinas em certo momento perceberam que eles não conseguiriam proteger os softwares, até porque quem produz os programas pode ser a origem da fraude. Por isso adotaram mecanismos para que o eleitor possa utilizar para aferir que o equipamento se comporte de maneira honesta durante a eleição”.

Outros pontos que podem ser aperfeiçoados são mudanças arquiteturais no sistema para ampliar a segurança dos mecanismos, garantindo mais segurança e proteção do sigilo do voto.

IC

Mais acessadas

#existepesquisanobr: uma avalanche de ciência nas timelines

Indignado, pesquisador da Unicamp cria hastag e provoca debate nas redes sociais

Nota de repúdio aos atos de vandalismo no IEL e IG

Estudantes estrangeiros são recebidos na Unicamp para o segundo semestre de 2018

Cecília Baranauskas assume conselho de instituto da Unesco

Professora do Instituto de Computação da Unicamp integrará conselho diretor do Instituto para Tecnologias da Informação na Educação

Supermedicalização e entendimento sobre a doença foram debatidos em simpósio de saúde mental

Comunidade Interna 

Nota de repúdio aos atos de vandalismo no IEL e IG

Secretaria Geral recebe inscrições de candidatos para representação de servidores técnico-administrativos junto ao Consu

Estudantes estrangeiros são recebidos na Unicamp para o segundo semestre de 2018

Atualidades 

Laboratório do Caism fará monitoramento externo da qualidade do papanicolaou do Estado de São Paulo

Hospital foi credenciado pelo Ministério da Saúde e será o maior auditor do Estado de São Paulo

Cecília Baranauskas assume conselho de instituto da Unesco

Professora do Instituto de Computação da Unicamp integrará conselho diretor do Instituto para Tecnologias da Informação na Educação

#existepesquisanobr: uma avalanche de ciência nas timelines

Indignado, pesquisador da Unicamp cria hastag e provoca debate nas redes sociais

Cultura & Sociedade 

Curso livre “O Cinema e a Criação de Ugo Giorgetti” recebe inscrições

De 15 de agosto a 7 de novembro, o diretor e roteirista vai oferecer um curso semanal e gratuito na Unicamp

Curso Exato comemora dez anos de apoio aos estudantes do Ensino Médio

Projeto de extensão reúne estudantes e docentes voluntários para darem aulas de física, matemática, química e português sem qualquer custo

Sinfônica da Unicamp se apresentará em Campos do Jordão

É a primeira vez que a orquestra participará do Festival de Inverno, considerado o maior evento de música clássica do Brasil

Acesso Rápido

    • Agenda 

    • Clipping 

    • Jornal da Unicamp 

    • Notícias 

    • Teses 

    • Banco de Imagens 

    • Busca Portal e Jornal da Unicamp 

    • Ouvidoria 

    • Reitoria 

    • Unicamp Responde 

    • Bibliotecas 

    • Mídias Sociais 

    • Portal da Transparência Estadual 

  Localização e Contato

    • Cidade Universitária "Zeferino Vaz"

CEP 13083-970 | Campinas-SP 

    • portal@unicamp.br 

    • 19 3521-2121 

 

Serviços web

   Webmail

Redes Wi-Fi

Contate o Portal da Unicamp

 

 

 

 

© Desde1994 | UNIVERSIDADE ESTADUAL DE CAMPINAS

THE END