#Hackers can change election result ?
& Other News
• Why Electronic Voting is a BAD Idea - Computerphile By BradyHaran
• Senator Caiado says printed vote can restore credibility to Brazilian Democracy
• The Return of Software Vulnerabilities in the Brazilian Voting Machine By Prof. AranhaLatin America has the biggest skills gap in the world. Here’s how to bridge it (World Economic Forum)
SEE ALSO: https://youtu.be/wOsNfSw8boo
SOURCE/LINK: https://www.youtube.com/watch?v=w3_0x6oaDmI
Why Electronic Voting is a BAD Idea - Computerphile
1.224.725 visualizações
31 mil 1,3 mil Compartilhar
Computerphile
Publicado em 18 de dez de 2014
Voting is centuries old, why can't we move with the times and use our phones, tablets and computers? Tom Scott lays out why e-voting is such a bad idea. More from Tom Scott: http://www.youtube.com/user/enyay and
https://twitter.com/tomscott http://www.facebook.com/computerphile https://twitter.com/computer_phile This video was filmed and edited by Sean Riley. Computer Science at the University of Nottingham: http://bit.ly/nottscomputer Computerphile is a sister project to Brady Haran's Numberphile. See the full list of Brady's video projects at: http://bit.ly/bradychannels
Autores de legendas (Alemão)
TheBlackIPs Angel Cleva Steampilot
Autores de legendas (Holandês)
nannoe Jelle Hulter Hidde Vente
Autores de legendas (Português)
Js Lucas Silva João Paulo Santos Sena Pedro Santos
Autores de legendas (Italiano)
RedellaStrada47 Mr Flask
Autores de legendas (Português (Brasil))
Lucas Berg Matheus Torezani Marco Cordeiro
Autor de legendas (Hebraico)
SirZarm𐌈:
Autores de legendas (Húngaro)
Tamás Zarnócz Tamás Józsi
Categoria
Educação
Licença
Licença padrão do YouTube
4.177 comentários
==//==
E-voting is a terrible idea
00:00
After Hurricane Sandy in 2012, election officials in some parts of America decided that they'd
00:05
allow emergency e-voting from home. You'd download a ballot paper, you'd fill it out,
00:10
and then you would email or fax it back to them. And yes, some people still fax.
00:15
This was a terrible idea, and here's why.
00:21
Physical voting is centuries old. In that time, pretty much every conceivable method
00:25
of fraud has been tried, and has since been defended against. Because of that, attacks
00:29
on physical voting don't scale well. It takes so much effort, so many people and it only
00:34
takes one person to leak your conspiracy and the whole thing falls apart.
00:37
Electronic voting, though? You can attack with one person. It can take about the same
00:41
effort to change one vote as it does to change a million. And it can be done without even
00:45
setting foot in the country whose elections you're trying to rig.
00:49
There are two key parts of an election. Anonymity, and trust. First of all, anonymity. You cannot
00:54
let anyone pay, bribe, or threaten in order to change someone's vote. If you put any identifying
01:00
mark on your paper ballot, if you sign it, if you write your name on it, if you do anything
01:04
that could, in theory, be used to check how you voted, your vote is thrown out and ignored,
01:09
just so no-one can be forced or bribed to vote a certain way.
01:12
And yet, because you marked your vote, and you put it into a sealed box, and that box
01:16
was only unsealed when it was surrounded by everyone with a stake in the election, you
01:20
know that your vote has still been counted, even though you'll never see it again.
01:25
That's the other key: trust. You never, ever, ever, trust any one individual. Ideally, you
01:31
don't trust any two, or three. People can be bribed, can be threatened, can be incompetent.
01:35
I mean, hell, people have been all three of those things. But like I said: the more physical
01:41
votes you want to change, the more people it takes and the less possible your attack
01:45
gets. Everyone can see what's happening and keep an eye on each other, particularly if
01:50
they don't trust the other side.
01:55
So let's talk about voting machines.
01:59
Problem 1: Auditing the software and hardware
02:01
In theory, you could have open source software that everyone has checked and everyone is
02:06
happy with and that's been used for years. In theory. Never mind that you only actually
02:10
do a full-scale test of this software every few years when there's actually an election,
02:14
let's say theoretically it can be done.
02:16
But how do you make sure that software is what's actually loaded on that voting machine
02:22
in front of you on the day of the election?
02:23
And I know that immediately, someone is going to want to comment about checksums or crypto.
02:28
Which is great, except now you have to trust the software that's checking that hash. Or
02:32
more likely, the one person that's checking it for you. You've just moved the problem.
02:36
And if you're thinking "I could verify that", then turn your brain the other way, and think
02:41
"how could I break that?" because there are trillions of dollars -- that's not an exaggeration
02:46
-- riding on the result of big elections, and that's an incredible motivation. If you're
02:51
coming up with sneaky ways to get around it... believe me, so are lots of other people.
02:55
It might be one angry techie, but it might be an entire political party, or the huge
02:59
corporations who want one party to win, or entire nation states who want one party to
03:04
win.
03:05
And all that is assuming you're even allowed to verify the software that's running, which
03:09
you never are, because plugging unknown USB sticks into a voting machine is a bad idea.
03:14
Not that that stops people plugging unknown USB sticks into a voting machine. It has literally
03:18
happened. Let's remember, these machines have to be left in a room with the voter and no-one
03:24
else in order for them to cast their vote anonymously. Oh, by the way, the machines
03:28
are frequently programmed by sticking a USB into each of them in turn, so if you compromise
03:32
the first one, jackpot.
03:34
In practice, you don't have open source software, you have proprietary, unaudited software which
03:38
you just have to trust. This is real, by the way, around the world, there are some elections
03:42
that run on this. And remember what I said? This is an election. You don't trust.
03:46
And maybe you're thinking, you could have an audit trail, you could have a paper backup
03:50
that the machine prints out as you vote. In which case, congratulations, you've just invented
03:55
the world's most expensive pencil. One of the reasons Britain gives people pencils for
04:00
voting, by the way, is because we're worried that pens might be switched by any voter to
04:04
contain disappearing ink. Erasing pencil ballots? Takes time, and if you can do that, you can
04:12
just throw them away. Disappearing ink? It might be an urban legend, but it might actually
04:15
be a plausible attack vector. This is the level of paranoia we need to work at here.
04:19
And don't think you can get away with all this by using a pile of paper ballots and
04:23
just counting them electronically, either: an electronic counting machine is still a
04:27
black box that a pile of ballots goes into and a mysterious number comes out of. They've
04:31
got exactly the same problems.
04:34
Problem 2: Votes In Transit
04:37
There are three ways of moving the magic electronic ballot numbers from the voting machines to
04:42
the final count.
04:43
You could treat the machine like a regular ballot box, you seal it in a plastic bag,
04:47
move the physical machine with two people in the vehicle to the count, and then unseal
04:51
it there. No-one does this.
04:53
You could copy the result onto a handy USB stick and move that instead. Do I need to
04:58
run through how easily... no. Okay.
05:01
Or, and this is what usually happens, you could tell the voting machine to upload the
05:05
results over the internet, optionally through a third central server, and potentially not
05:09
over a secure connection, and probably without any checksums or tests. [exasperating]
05:16
Problem 3: Central Count Program
05:19
And right at the end, there's the program that takes all these numbers, all these votes,
05:23
and produces a final count. Now you've got all the same problems you have with the individual
05:28
voting machines, except now only a few people can even see that machine, and it's been hidden
05:33
away in a private warehouse somewhere for the last few years. Good luck verifying that.
05:38
And all this -- all this -- is before we even talk about online voting.
05:43
I could talk about all the ways which you could hijack ballots, block an email address
05:48
-- because after Hurricane Sandy, the ballots were sent by email -- or any of the ways you
05:53
could do a man-in-the-middle attack on that. All possible.
05:56
And those are just if it's a well designed system.
06:00
There are reports of actual live elections where there were cross-site scripting attacks
06:04
in the e-voting page, where they'd misspelled one party's name, and where they'd put the
06:07
wrong party's logo next to a candidate. Sorry, did I say elections? I meant election. That
06:12
was all the same election, it was in Hampshire in 2007.
06:16
But never mind all that.
06:18
Depending on which security company you believe, somewhere around 5% and 50% of desktop computers
06:25
are infected with something. And that's just the scammers trying to set up botnets and
06:29
minor extortions using private computers. If you want to affect a load of votes, try
06:33
infecting the computers at the public library. But never mind all that.
06:36
We've seen what big scary countries and big scary corporations can do when they put their
06:41
mind to it. Given that someone designed an immensely complicated worm that spread around
06:46
the world just to break some Iranian centrifuges, imagine what someone could do if they wanted
06:52
to throw an online election.
06:53
Remember, again, when you hear "just trust us", or "just trust me", or "it's a computer,
06:57
it doesn't go wrong" in an election, something has already gone disastrously wrong.
07:03
Imagine all this electronic voting, only without computers. Would you be happy walking up to
07:07
someone anonymous in a ballot box, or worse, calling a number on your phone, just telling
07:11
them your vote -- but they promise to keep it secret -- and at the end of the election
07:15
all those people, who have been sitting on their own, phone up one other person in private
07:19
and tell their results, and then that final person -- who promises to count it all up
07:23
accurately -- announces who's won? Because that's essentially what electronic voting
07:27
is. It is a terrible idea, and if a government ever promises to use it, hope they don't manage
07:34
it before you get a chance to vote
07:36
them out.
==//==
SEE ALSO: https://youtu.be/wOsNfSw8boo
SOURCE / LINK: https://goias24horas.com.br/71132-caiado-diz-que-voto-impresso-can-resgatar-credibilidad-de-democracia/
Senator Caiado says printed vote can restore credibility to Brazilian Democracy
March 13, 2018
Senator Ronaldo Caiado (Brazilian Democrats Party DEM) said Tuesday that the impression of voting for voter's conference could rescue "public confidence" in the electoral process. In an audience with the Secretary of Information Technology of the Superior Electoral Court (TSE), Giuseppe Janino, Caiado highlighted the importance of giving "total transparency" in these elections. "It is the feeling of confidence of the population that is at stake," he said.
The DEM leader in the Senate said there was no doubt about the effectiveness of the voting machine, but to reject a measure that would bring more credibility would only aggravate the high rates of non-attendance that the senator says are approaching 35 percent. "We are dealing with something greater than a technical issue," emphasized Caiado.
The senator also commented on the Superior Electoral Court (TSE's) allegations that it was impracticable to implement the process, that it would require $ 2 billion in expenses. According to him, the amount is equivalent to what was spent on the renovation of the “Mané Garrincha” stadium in Brasilia for the 2014 World Cup. "The voter's assurance that the electoral process is reliable is worth much more than one reform of a stadium and the population is looking forward for it.
SEE ALSO: https://youtu.be/wOsNfSw8boo
Posted in National
Share
Tweet
==//==
SOURCE/LINK: https://www.weforum.org/agenda/2018/03/latin-america-has-the-biggest-skills-gap-in-the-world-here-s-how-to-bridge-it
Latin America has the biggest skills gap in the world. Here’s how to bridge it
• Agenda
• Initiatives
• Reports
• Events
• About
• TopLink
•
• Regional Agenda
• Education and Skills
• Latin America
Latin America has the biggest skills gap in the world. Here’s how to bridge it
Upskilling and reskilling programmes are spreading across Latin America.
Image: REUTERS/Cheryl Ravelo/Files
13 Mar 2018
1. Monica Flores President, Latin America, ManpowerGroup
2. Angel Melguizo Chief Economist, Latin American Unit, OECD Development Centre, Organisation for Economic Co-operation and Development (OECD)
Latest Articles
This is the biggest threat to Latin America’s digital transformation
Jordi Botifoll 13 Mar 2018
Meet IBM's Simon, the world's first smartphone
Rob Smith 13 Mar 2018
Tax rules are changing around the world. This is what you need to know
Simone Musa 13 Mar 2018
More on the agenda
Explore context
Education and Skills
Explore the latest strategic trends, research and analysis
This article is part of the World Economic Forum on Latin America
In these times of heated economic debate, improving skills is one of the rare consensuses worldwide. Globalization and technological progress has made productivity more dependent on a broad, complex and difficult-to-achieve set of skills.
In Latin America, the lack of an adequate pool of skilled workers is making it harder to overcome the middle-income trap. This contrasts with the experience in most European and Asian economies, which have achieved sustained increases in income per capita by improving the stock and quality of education and skills, and developing an innovation-friendly environment.
Investing in skills would also help address inequality, since large differences in productivity go hand-in-hand with large differences in wages. Without this investment, the winners – that is, the most innovative firms and their high-skilled staff – will continue to take all.
What do we know about skills in Latin America?
Over four in 10 firms in Latin America say they have difficulty finding workers with the right skills, according to ManpowerGroup surveys. Companies in Argentina are worst hit, with 59% struggling to hire staff with the right skills; in Colombia that figure is 50%, and Peru 49%. For more than a decade now – that is, during the economic boom of the 2000s, the slowdown since 2012, the recession of 2015-2016, and the present recovery – Latin America has ranked as the region with the widest skills gap in the world.
What works to fill the gap?
What should be done? Education curricula and skills-enhancing programmes should provide technical training, as well as foundational skills. These are critical throughout people’s lives, helping to switch jobs (if wanted) and adapt to changing external conditions. There should be a combination of classroom and workplace learning, of both soft and technical skills, complemented by job search services.
Re-skilling and upskilling is the new name of the game. It is the skills of today’s workforce that will drive the economy for the next two decades. For that goal, collecting information on the skills individuals possess and the skills businesses need is a must.
How should this be done? This requires the involvement of employers at all stages: collecting information for the design, implementation and evaluation of training; designing programmes; and co-funding initiatives. It must be implemented under a whole-of-government approach that involves education, employment, innovation, planning and finance ministers.
Image: ManpowerGroup, 2016/2017 Talent Shortage Survey
Good practices in Latin America
Admittedly, these recommendations are easier said than done. But, let’s not fall into the traditional Latin American fracasomania, or addiction to failure. Some training programmes for youth in Argentina (Jóvenes con Más y Mejor Trabajo), Colombia (Jóvenes en Acción) or Brazil and Peru (ProJoven) tick almost all the boxes, and their impact evaluations show good results on employability, reliability and earnings.
The involvement of the private sector is also growing. Take Mexico, where upskilling and reskilling programmes are spreading. In one initiative women in marketing, sales and customer services saw their wages multiplied by five times. In the car and machinery industries, which are traditionally affected by skills shortages, training programmes are being developed following the pioneering example of Volkswagen’s training institute. And public institutions in Mexico and Peru are taking steps towards co-ordination and a whole-of-government approach to skills strategies.
Looking forward? Better data for better action
Predictions for the labour market over the long-term are increasingly extreme: technology eating our jobs, robots replacing drivers, the threat of a world without work. As skill needs change ever faster, some statistics suggest employers do not always know which skills they require even 18 months from now, not just over the long-term.
That is why we need to invest in capacities to anticipate skill needs, detect future skills mismatches, and build the processes to ensure that this information is effectively used in decision making. Unfortunately, this field is even more complex and little studied, so there are few good practices.
For this reason, ManpowerGroup Latin America and the OECD Development Centre, with ANDI for Colombia, recently launched an online survey to get detailed information on the skills gap in Latin America.
Information is directly gathered from companies, by country, by company size, and by activity (agriculture, trade, communications and transport, construction, manufacturing, mining and extractives, and services). This point is crucial for the debate about a post-manufacturing economy that we will be holding at the World Economic Forum on Latin America in São Paulo this week.
Latin American companies are highlighting an even more acute skills gap than previously thought. Three in four companies (from a sample of more than 1,200 companies across Latin America) say they have problems filling vacancies, despite the availability of candidates. Interestingly enough, this shortage is bigger among large companies (of more than 250 employees), where it affects four in five.
The skills gap affects both manufacturing and services, which are key in the agenda of upgrading and diversifying Latin America’s economy, as shown in previous studies. Looking at the results by industry, four in five companies in mining and extractives, manufacturing, and in services, report skills gaps.
When companies talk about a skills gap, they are often referring to soft skills. Among the top seven ‘missing skills’, emotional intelligence, communication skills and critical thinking are mentioned three times more frequently than IT skills, and two times more frequently than financial knowledge. Speaking English ranks in the middle.
Skills is the new currency, let’s invest
Today’s economy requires increasingly complex skills. Formal education systems are struggling to provide timely solutions. This detachment between formal education and business skill demands is especially severe on soft skills, which are not usually included in formal education curricula.
The good news is that most governments, companies and citizens in Latin America and worldwide are increasingly aware of this priority. Skills have become the global currency of 21st Century economies to spur growth and reduce inequalities. Forget about bitcoin, let’s all invest in skills.
Share
Escrito por
Monica Flores, President, Latin America, ManpowerGroup
Angel Melguizo, Chief Economist, Latin American Unit, OECD Development Centre, Organisation for Economic Co-operation and Development (OECD)
The views expressed in this article are those of the author alone and not the World Economic Forum.
Subscribe for updates
A weekly update of what’s on the Global Agenda
Featured: Education and Skills View all
Latin America has the biggest skills gap in the world. Here’s how to bridge it
Monica Flores and Angel Melguizo 13 Mar 2018
These are the top universities by subject in Latin America
Rob Smith 12 Mar 2018
5 things parents can do to help develop STEM skills
Kym Simoncini · The Conversation 12 Mar 2018
Lego is making plant-based plastic pieces
Brian Spaen · Green Matters 06 Mar 2018
If you want your child to get a good job, let them play more
Jenny Anderson · Quartz 05 Mar 2018
The best time of day to learn a new language is just before you go to bed
Burr Settles and Masato Hagiwara · Quartz 28 Feb 2018
Being a great boss comes down to knowing when to use two distinct skills
Robin Camarote · Business Insider 27 Feb 2018
Subscribe for updates
A weekly update of what’s on the Global Agenda
Follow Us
About
Our Mission
Leadership and Governance
Center for the Fourth Industrial Revolution
Our Members and Partners
The Fourth Industrial Revolution
Communities
History
Klaus Schwab
Our Impact
Pictures
Media
A Global Platform for Geostrategic Collaboration
Mapping Global Transformations
Contact Us
Careers
Open Forum
Code of Conduct
World Economic Forum LLC
Privacy and Terms of Use
日本事務所
Sustainability
Media
News
Accreditation
Subscribe to our news
Members & Partners
Member login to TopLink
Strategic Partners' area
Partner Institutes' area
Global sites
Center for the Fourth Industrial Revolution
Open Forum
Global Shapers
Schwab Foundation for Social Entrepreneurship
EN ES FR 中文 日本語
© 2018 World Economic Forum
Privacy Policy & Terms of Service
==//==
SOURCE/LINK: https://www.researchgate.net/publication/323470546_The_Return_of_Software_Vulnerabilities_in_the_Brazilian_Voting_Machine
(In)security of e-voting in Brazil
Diego F. Aranha, UNICAMP
dfaranha@ic.unicamp.br
@dfaranha
http://www.ic.unicamp.br/~dfaranha
Veja tudo>
18 Referências
Faça o download do texto completo PDF
O Retorno de Vulnerabilidades de Software na Urna Eletrônica Brasileira
Pré-impressão (PDF disponível) · Março de 2018 com 17.623 Leituras
DOI: 10.13140 / RG.2.2.16240.97287
•
• Diego F. Aranha
• 12.56
• Universidade de Campinas
• Pedro Yóssis Silva Barbosa
• Universidade Federal de Campina Grande (UFCG)
• Thiago Nunes Coelho Cardoso
• Universidade Federal de Minas Gerais
• Paulo Matias
◦ 8.4
◦ Universidade Federal de São Carlos
Abstrato
Este artigo apresenta uma análise de segurança detalhada e atualizada do software de votação utilizado nas eleições brasileiras. Baseia-se nos resultados obtidos pelos autores em um recente desafio de hacking organizado pelo Tribunal Superior Eleitoral (SEC), a autoridade eleitoral nacional. Durante o evento, várias vulnerabilidades graves foram detectadas no software de votação, que quando combinado comprometeu as principais propriedades de segurança do equipamento, a saber, segredo da cédula e integridade do software. O armazenamento inseguro de chaves criptográficas, codificadas diretamente no código-fonte e compartilhado entre todas as máquinas, permitiu a inspeção completa de conteúdo dos cartões de memória de instalação do software, após o que foram detectadas duas bibliotecas compartilhadas que faltam assinaturas de autenticação. O código de injeção nessas bibliotecas abriu a possibilidade de executar código arbitrário no equipamento, violando a integridade do software em execução. Nosso progresso é descrito cronologicamente, para ilustrar dificuldades e limitações na metodologia de teste escolhida pela autoridade eleitoral e para informar como as equipes que participam de desafios futuros podem otimizar seu desempenho. Rastreamos o histórico das vulnerabilidades para uma análise de segurança anterior, fornecendo algumas perspectivas sobre como o sistema evoluiu nos últimos 5 anos. Tanto quanto sabemos, este foi o compromisso mais profundo de um sistema oficial de votação em larga escala já realizado em condições tão severas.
Descubra a pesquisa mundial
• 14+ milhões de membros
• 100 milhões de publicações
• 700k + projetos de pesquisa
Entre de graça
Arquivo (PDF)
Disponível a partir de: Diego F. Aranha, 11 de março de 2018
Faça o download do texto completo PDF
Outras fontes de texto completo
O Retorno de Vulnerabilidades de Software na Máquina de Votação Brasileira
Diego F. Aranha
Universidade de Campinas
Pedro Y'
Ossis Silva Barbosa
Universidade Federal de Campina Grande
Thiago Nunes Coelho Cardoso
Hekima
Caio L¨
o Ara'
ujo
Universidade Federal de Pernambuco
Paulo Matias
Universidade Federal de S~
ao Carlos
Abstrato
Este artigo apresenta uma segurança detalhada e atualizada
análise do software de votação utilizado na eleição brasileira.
ções. Baseia-se nos resultados obtidos pelos autores em
um recente desafio de hacking organizado pelo Superior
Tribunal eleitoral (SEC), a autoridade eleitoral nacional.
Durante o evento, várias vulnerabilidades graves foram
detectado no software de votação, que quando combinado
comprometeu as principais propriedades de segurança dos equipamentos
o segredo da cédula e a integridade do software. o
armazenamento inseguro de chaves criptográficas, di-
Diretamente no código fonte e compartilhado entre todas as máquinas, al-
Inspeção completa de conteúdo completo da instalação do software
cartões de memória, após o que faltam duas bibliotecas compartilhadas
assinaturas de autenticação foram detectadas. Código de injeção
nessas bibliotecas abriu a possibilidade de executar arbi-
código geral no equipamento, violando a integridade do
executando o software. Nosso progresso é descrito cronologicamente
portanto, para ilustrar dificuldades e limitações no teste -
metodologia escolhida pela autoridade eleitoral, e
para informar como as equipes participam de desafios futuros
podem otimizar seu desempenho. Rastreamos a história de
as vulnerabilidades a um anterior análise de segurança, pro-
fornecendo alguma perspectiva sobre como o sistema evoluiu
nos últimos 5 anos. Tanto quanto sabemos, este foi o
o compromisso mais aprofundado de uma votação oficial de grande escala -
sistema já executado sob tão severamente restrito
condições.
1. Introdução
O Brasil é uma das maiores democracias do mundo, com
um esperado 144 milhões de eleitores no próximo 2018
eleições gerais1. As eleições são realizadas a cada 2 anos
no mês de outubro, alternando entre municipalidades
1 Baseado em estatísticas de 2016 (em português): http: //www.tse.
jus.br/eleitor-e- eleicoes / estatisticas / eleicoes /
Eleicoes-anteriores / estatisticas- eleitorais-2016
eleições (membros do conselho da cidade e prefeitos), e
Eleições gerais (membros da câmara baixa, senadores,
governadores e o presidente).
Máquinas de votação eletrônicas de Recodificação Direta (DRE)
foram introduzidas pela primeira vez no país em 1996, depois do fre-
relatórios de fraude durante o transporte e tabulação de
votações em papel e eleições tornaram-se totalmente eletrônicas
ano 2000. Os registros de documentos verificados pelo eleitor foram brie fly
experimentado em 2002, mas considerado muito caro e
pesado pela autoridade eleitoral. Desde então, mul-
As contas tiple foram introduzidas no Congre Brasileiro
==//==
SOURCE/LINK: https://youtu.be/8fDfvwpDor4
Especialista revela toda podridão do voto eletrônico
See all ›
18 References
Download full-text PDF
The Return of Software Vulnerabilities in the Brazilian Voting Machine
Preprint (PDF Available) · March 2018 with 17,623 Reads
DOI: 10.13140/RG.2.2.16240.97287
•
• Diego F. Aranha
• 12.56
• University of Campinas
• Pedro Yóssis Silva Barbosa
• Universidade Federal de Campina Grande (UFCG)
• Thiago Nunes Coelho Cardoso
• Federal University of Minas Gerais
• Paulo Matias
◦ 8.4
◦ 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
• 14+ million members
• 100+ million publications
• 700k+ research projects
Join for free
File (PDF)
Available from: Diego F. Aranha, Mar 11, 2018
Download full-text PDF
Other full-text sources
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 transaction 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). In order to check if this was indeed
an attack vector, we replaced the opcodes of the func-
tions in the mentioned libraries by the opcodes of an
exit system call. The installation process worked as
expected, storing the two compromised files in the vot-
ing machine. During the boot, the system successfully
called the syscall, halting the process. 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 kernel initial-
ization. Using the write syscall outputting to stdout,
we printed the text “FRAUD!” in the terminal. 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
9BusyBox: https://busybox.net
10
promising idea, but since our attack vector was already
relocated in memory, we needed to either implement an
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 us-
ing its idle space for storing cryptographic keys. Because
any voting machine 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 further that overall security of the system is dic-
tated by the oldest model in operation, in this case the
2007 one without 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, 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 a 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
again recommend the DRV file to be eliminated, and the
law to be changed.
11Sapparot-2: http://www.literatecode.com/sapparot2
14
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 requirements and cost of the 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 of 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
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
15
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.
[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
16
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. , HAL DE RMA N, 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
• A. De Miranda
• F.B. Scarel
View
• Studying the Nedap/Groenendaal ES3B voting computer: a computer security perspective
Article
• Jan 2007
• Rop Gonggrijp
• Willem-Jan Hengeveld
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
Technical Report
NIZKCTF: A Non-Interactive Zero-Knowledge Capture the Flag Platform
August 2017
Capture the Flag (CTF) competitions are educational and professional tools for the cybersecurity community. Unfortunately, CTF platforms suffer from the same security issues as other software components, what may give advantage to competitors who target the actual platform instead of the challenges. While it is arguable that successful attacks against the platform demonstrate relevant skills,... [Show full abstract]
Read more
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
Data
Software vulnerabilities in the Brazilian voting machine (slides for RWC 2016)
January 2016
Read more
Presentation
(In)security of e-voting in Brazil (ekoparty 13)
September 2017
This talk presents a security analysis of the Brazilian voting machine software based on our participation in official restricted tests organized in 2012 by the national electoral authority. During the event, vulnerabilities in the software were detected and explored, with significant impact on ballot secrecy and integrity. We present scenarios where these vulnerabilities allow electoral fraud... [Show full abstract]
Read more
Discover more
Data provided are for informational purposes only. Although carefully collected, accuracy cannot be guaranteed. Publisher conditions are provided by RoMEO. Differing provisions from the publisher's actual policy or licence agreement may be applicable.
This publication is from a journal that may support self archiving.
Learn more
Last Updated: 11 Mar 18
© 2008-2018 ResearchGate GmbH. All rights reserved.About us · Help Center · Careers · Developers · News · Privacy · Terms · Copyright · Impressum | Advertising · Recruiting
•
•
or
Discover by subject area
Join for free
Log in
• People who read this publication also read:
• Technical Report: NIZKCTF: A Non-Interactive Zero-Knowledge Capture the Flag Platform
Full-text · Aug 2017
Article: Crowdsourced integrity verification of election results: An experience from Brazilian elections
Full-text · Mar 2016 · annals of telecommunicatio...
Data: Software vulnerabilities in the Brazilian voting machine (slides for RWC 2016)
Full-text · Jan 2016
Presentation: (In)security of e-voting in Brazil (ekoparty 13)
Full-text · Sep 2017
==//==
SOURCE/LINK: https://www.youtube.com/watch?v=w3_0x6oaDmI
Votação eletrônica é uma ideia terrível.
1.224.725 visualizações
31 mil 1,3 mil Compartilhar
Computerphile
Publicado em 18 de dez de 2014
00:00
Depois do furacão Sandy em 2012, agentes eleitorais em algumas partes do EUA decidiram que eles iriam
00:05
permitir eleições eletrônicas emergenciais realizadas dentro de casa. Você baixa a cédula de voto, faz sua votação nela,
00:10
e depois a envia de volta por e-mail ou fax. E sim, algumas pessoas ainda usam fax.
00:15
Isso foi uma ideia terrível, e aqui esta o motivo.
00:21
O voto físico é feito a séculos. Naquela época, a maioria dos métodos concebíveis
00:25
de fraude já haviam sido tentados, e desde então superados. Por causa disso, ataques
00:29
em votos físicos não possuem boa escalabilidade. É necessário muito esforço, muitas pessoas,
00:34
e basta uma pessoa vazar a sua tentativa e o esquema todo cai por terra.
00:37
Votações eletrônicas? Elas podem ser atacadas por apenas uma pessoa.
00:41
O esforço para mudar um voto ou um milhão é o mesmo. E tudo isso pode ser feito
00:45
sem mesmo colocar os pés no país cujas eleições você está tentando fraudar.
00:49
Existem dois conceitos-chaves em uma eleição: Anonimidade e confiança. Primeiramente anonimidade. Não se pode
00:54
pagar, subornar ou ameaçar alguém com o objetivo de mudar seu voto. Se você colocar qualquer marca
01:00
de identificação na sua cédula de papel, se você assinar, escrever seu nome nela, colocar um número, qualquer coisa
01:04
que pode, em teoria, ser usada para verificar em quem você votou, seu voto é anulado
01:09
para que ninguém seja forçado ou subornado à votar de uma certa forma.
01:12
E mesmo assim, como você marcou a sua cédula, a colocou em uma caixa selada, e o lacre daquela caixa
01:16
só foi quebrado quando a caixa estava cercada por vários fiscais, você
01:20
sabe que o seu voto foi contado, mesmo que você nunca mais veja o papel.
01:25
Este é o outro conceito-chave: confiança. Você nunca, nunca, deve confiar em qualquer indivíduo. Na verdade, você
01:31
não confia em ninguém. Pessoas podem ser subornadas, ameaçadas, podem ser incompetentes.
01:35
Algumas podem até ter todas essas caracteristicas. Mas como eu disse: quanto mais votos físicos
01:41
você queira mudar, mais pessoas são necessárias e menos provável é o ataque.
01:45
Todos podem ver o que está acontecendo e fiscalizar uns aos outros, particularmente se
01:50
eles não confiam nas pessoas do outro lado.
01:55
Então, vamos conversar sobre urnas eletrônicas.
01:59
Problema 1: Auditoria de software e hardware.
02:01
Em teoria, pode-se usar software livre, que todos tenham analisado e todos estejam
02:06
contentes e que tem sido usado por anos. Em teoria. Não se preocupe com o fato de que o software
02:10
só é testado de tempos em tempos, quando acontece uma eleição.
02:14
Digamos que, teoricamente, isso pode ser feito.
02:16
Mas como ter certeza de que esse software testado é o que está rodando na
02:22
urna eletrônica, na sua frente, no dia da eleição?
02:23
Eu sei que alguém vai comentar sobre assinatura digital ou criptografia.
02:28
O que é ótimo, exceto que agora você precisa confiar no software que está verificando essa assinatura.
02:32
Ou mais provável, confiar na pessoa que está checando para você. Você apenas transferiu o problema.
02:36
E se você está pensando agora "Ah, tudo bem, eu mesmo posso verificar", então pense de outra forma, e imagine
02:41
"como eu poderia fraudar isto?" porque há trilhões de dólares -- isso não é um exagero
02:46
-- em jogo, no resultado de grandes eleições, e isso é uma motivação incrível. Se você conseguir pensar
02:51
em métodos para fraudar as eleições... acredite, muitas pessoas também já pensaram.
02:55
Pode ser um cara de TI com raiva, mas também pode ser um partido político inteiro, ou grandes
02:59
corporações que querem que um partido vença, ou nações que desejam que um partido
03:04
vença.
03:05
E tudo isso, assumindo que você tenha alguma chance de poder verificar o software que está rodando,
03:09
coisa que nunca acontece, pois inserir dispositivos USB desconhecidos em urnas eletrônicas é uma má ideia.
03:14
Não que isso impeça as pessoas de plugar dispositivos USB desconhecidos em urnas eletrônicas. Isso literalmente
03:18
já aconteceu. Vamos lembrar que estas urnas devem ser deixadas sozinhas com o eleitor e ninguém mais,
03:24
para que o voto ocorra de forma anônima. Ah, e por sinal, as urnas são programadas
03:28
justamente inserindo um dispositivo USB nelas, então se você comprometer o dispositivo usado
03:32
para programar, bingo.
03:34
Na prática, não temos software livre, temos software proprietário, não auditado, em que você
03:38
apenas deve confiar. Isso é real, ao redor do mundo, existem algumas eleições
03:42
que funcionam assim. E lembra o que eu falei? Isso é uma eleição. Você não deve confiar.
03:46
E talvez você esteja pensando, pode-se auditar o processo todo, ou pode-se fazer um backup em papel
03:50
que a urna imprime quando você vota. Neste caso, parabéns, você acabou de inventar
03:55
o lápis mais caro do mundo. Uma das razões pelas quais os britânicos recebem lápis para
04:00
votar, é a preocupação de que qualquer eleitor possa trocar a tinta das canetas
04:04
por tinta que desaparece. Apagar os votos a lápis leva tempo, e se você tiver essa chance
04:12
será fácil simplesmente jogar o voto fora. Pode até ser uma lenda urbana, mas pode ser realmente uma
04:15
forma plausível de ataque. Este é o nível de paranóia que devemos considerar.
04:19
E se você pensa que pode simplesmente usar cédulas de papel
04:23
e contá-las eletrônicamente então: uma máquina de contagem eletrônica ainda é
04:27
uma caixa preta onde uma pilha de cédulas entra e um número misterioso sai. Essas máquinas
04:31
possuem exatamente os mesmos defeitos.
04:34
Problema 2: Transporte dos votos.
04:37
Existem três formas para mover os números mágicos das urnas eletrônicas para
04:42
a contagem final.
04:43
Você pode tratar a urna como uma caixa de cédulas normal, selá-la em uma bolsa de plástico
04:47
transportar a urna com duas pessoas dentro de um veículo até o local de contagem, e então quebrar o selo.
04:51
Ninguém faz isso.
04:53
Você pode copiar o resultado em um dispositivo USB e transportá-lo.
04:58
Preciso falar sobre o quão fácil seria... não. Okay.
05:01
Ou o que geralmente acontece, você pode fazer com que a urna faça upload dos
05:05
resultados através da internet, para um servidor de terceiros, que pode não estar usando
05:09
nenhum tipo de segurança, sem verificação de conteúdo ou nenhum tipo de teste. [Irritado]
05:16
Problema 3: Programa de contagem.
05:19
E no final, um programa recebe todos esses números, todos esses votos,
05:23
e produz uma contagem final. Agora você tem todos os problemas que existem individualmente
05:28
com cada urna eletrônica, exceto que agora apenas um pequeno número de pessoas pode chegar perto desse computador, pois ele está
05:33
escondido em algum galpão privado em algum lugar pelos últimos anos. Boa sorte tentando auditar isso.
05:38
E tudo isso -- tudo isso -- sem nem falar sobre votação online.
05:43
Você pode falar sobre todas as formas que você pode adulterar as cédulas, comprometer computadores, bloquear endereços de email.
05:48
Porque depois do furacão Sandy, as cédulas eram enviadas por email! De qualquer forma, pode se fazer
05:53
um ataque do tipo homem-no-meio. Tudo é possível, tudo perfeitamente possível.
05:56
E tudo isso se tivermos sistemas bem projetados.
06:00
Existem relatos de eleições reais, onde aconteceram ataques do tipo cross-site scripting
06:04
na página de votação eletrônica, onde colocaram errado o nome de um partido, ou colocaram
06:07
a logo do partido errado perto de um candidato. Perdão, eu disse eleições? Eu quis dizer eleição.
06:12
Isso foi tudo foi em uma única eleição, em Hampshire 2007.
06:16
Mas nada disso importa.
06:18
Dependendo em que empresa de segurança você acredita, entre 5 e 50% dos computadores pessoais no mundo
06:25
estão infectados com algo. E isso são apenas pessoas maliciosas tentando roubar informações ou
06:29
pequenas extorções usando computadores privados. Se você deseja afetar um conjunto de votos, basta
06:33
infectar computadores públicos. Mas isso também não importa.
06:36
Pois nós já vimos o que grandes e assustadores países e empresas podem fazer quando
06:41
se esforçam. Dado que alguém - "alguém" - desenvolve um virus imensamente complicado que se espalha
06:46
pelo mundo apenas para quebras centrífugas iranianas, imagine o que alguém poderia fazer se quisesse
06:52
prejudicar uma eleição online.
06:53
Lembre-se, quando você ouvir "Apenas confie em nós" ou "Apenas confie em mim", ou "é um computador,
06:57
ele não erra" em uma eleição, algo já está desastrosamente errado.
07:03
Imagine todos estes votos eletrônicos, mas sem computadores. Você estaria contente em caminhar até
07:07
alguém estranho em uma caixa de cédulas, ou pior, ligar para alguém de seu telefone, apenas dizendo
07:11
a esta pessoa seu voto -- mas eles prometem manter o segredo -- e no final da eleição
07:15
todas estas pessoas que estavam no telefone, ligam para outra pessoa de forma privada
07:19
e dizem seus resultados, e então esta pessoa final -- que prometeu contar todos
07:23
os votos precisamente -- anuncia quem venceu? Porque é exatamente isso o que acontece em uma votação eletrônica.
07:27
É uma ideia terrível, e se um governo prometer adotar isso,
07:34
torça para que eles não consigam antes que você tenha uma chance de tirá-los do poder.
07:36
Próximo
Reprodução automática
10:13
The Problem with Time & Timezones - Computerphile
Computerphile
1,5 mi visualizações
5:48
Mac or PC? - Computerphile
Computerphile
474 mil visualizações
13:29
Man in the Middle Attacks & Superfish - Computerphile
Computerphile
396 mil visualizações
9:24
How NOT to Store Passwords! - Computerphile
Computerphile
1,3 mi visualizações
8:45
Chip & PIN Fraud Explained - Computerphile
Computerphile
578 mil visualizações
7:57
Why are the Boeing 737NG engines FLAT?
Mentour Pilot
1 mi visualizações
3:49
Gender Neutral Pronouns: They're Here, Get Used To Them
Tom Scott
897 mil visualizações
10:23
Emoji and the Levitating Businessman - Computerphile
Computerphile
422 mil visualizações
10:50
Why C is so Influential - Computerphile
Computerphile
298 mil visualizações
10:47
Top 20 Facts That Will Make You Say "I Had No Idea"
Be Amazed
8,2 mil visualizações
Novo
14:19
Onion Routing - Computerphile
Computerphile
309 mil visualizações
5:59
Illegal Numbers - Numberphile
Numberphile
2,5 mi visualizações
9:55
58 and other Confusing Numbers - Numberphile
Numberphile
1 mi visualizações
9:50
The Attack That Could Disrupt The Whole Internet - Computerphile
Computerphile
858 mil visualizações
8:25
Slow Loris Attack - Computerphile
Computerphile
310 mil visualizações
9:48
Where HTML beats C? - Computerphile
Computerphile
270 mil visualizações
15:19
Wana Decrypt0r (Wanacry Ransomware) - Computerphile
Computerphile
736 mil visualizações
8:18
Internationalis(z)ing Code - Computerphile
Computerphile
421 mil visualizações
9:16
Floating Point Numbers - Computerphile
Computerphile
758 mil visualizações
11:13
Why does the Boeing 737 not have any landing-gear doors?
Mentour Pilot
659 mil visualizações
Adicionar um comentário público...
Shane Killian 2 anos atrás
"The people who cast the votes decide nothing. The people who count the votes decide everything." —Joseph Stalin
853
Joshua Chhakchhuak 1 ano atrás
this whole time i thought it was a tom scott vid
396
Daniel Dankers 2 anos atrás
just use strawpoll for it geez
2,1 mil
RealityFacade 1 ano atrás
"congratulations, you've just invented the world's most expensive pencil"
889
erplunkboy 1 ano atrás
ALL of these problems are present in Brazilian elections. ALL OF THEM.
221
Wikiramblings 2 anos atrás
3:12 The animation can't get the USB stick the right way round first time!
1,7 mil
Sean M 1 ano atrás
2 years later and I’m still re-watching this video.
454
Tal Dru 2 anos atrás
someone had to do it: 1. 00:00 - 00:20 is 09:50 AM 2. 00:20 - 01:24 is 10:05 AM 3. 01:24 - 01:55 is 10:35 AM 4. 01:56 - 03:22 is 10:05 AM 5. 03:23 - 05:09 is 10:10 AM 6. 05:10 - 05:18 is 10:25 AM 7. 05:19 - 05:42 is 10:15 AM 8. 05:43 - 05:56 is 10:40 AM 9. 05:57 - 07:24 is 10:15 AM 10. 07:25 - 07:49 is 10:40 AM 11. 07:50 - 07:52 is 09:15 AM 12. 07:52 - 07:52 is 10:45 AM the recording went by this order: started filming at 09:15AM (11), first take 9:50AM (1), second take 10:05AM (2, 4), third take 10:10AM (5), fourth take 10:15AM (7, 9), fifth take 10:25AM (6), sixth take 10:35AM (3), seventh take 10:40AM (8, 10), last take 10:45AM (12) but, sadly, I couldn't figure out how many times Tom got to repeat it because he was very frustrated thank you big-ben, god bless the queen
300
Eskapis 1 ano atrás
I like how at 3:14 he plugs in the usb stick the wrong way first :D
252
Sebastian Haugeto 6 meses atrás
You obviously don't know about identity and security based on blockchain
16
Simon 2 anos atrás
Looking at the Big Ben, it took them 50 minutes to record this video. Haha
1,6 mil
toby1248 2 anos atrás
Pedant reporting in. They were there from about 9:45 to 10:40am, so something like 6-10 total takes. Also it was filmed between 2-6 december 2014 based on the weather and tide conditions
19
Tony Hong 1 ano atrás
I noticed that little joke about the USB drive in the video
138
marcelo vinicius 1 ano atrás
I'm from Brazil, for years we have the electronic voting system, and mind you, all of it is true!
427
Kale 1 ano atrás
You didn't mention DDoS attacks too. The Australian census was done via online this year and was targeted by DDoS attackers.
92
Buildings1772 6 meses atrás
uhhh Block chain voting...
8
Antonio 1 ano atrás
use decentralized blockchain technology for voting
57
GoldenSandslash15 1 ano atrás
I'm a poll worker for Orange County, California. We have had electronic voting machines for years now, and people are always welcome to use them. However, we ALWAYS offer an old-fashioned paper ballot to any voter who requests one. You do not have to use the machines if you don't want to. Additionally, our machines are not connected to the Internet. Every individual machine is transported to the vote-counting site by hand.
38
Brian Pollard 1 ano atrás
Bring a USB killer to a voting booth and shutdown the machine
28
Michael Scott 3 anos atrás
I just realized that the video starts with "<computerfile>", and ends with "</computerfile>"! :O
1,6 mil
==//==
SOURCE/LINK: https://youtu.be/wOsNfSw8boo
Caiado imprensa TSE no Senado em audiência sobre voto impresso
2.379 visualizações
==//==
SOURCE/LINK:https://goias24horas.com.br/71132-caiado-diz-que-voto-impresso-pode-resgatar-credibilidade-da-democracia/
Caiado diz que voto impresso pode resgatar credibilidade da democracia
13 de Março de 2018
O senador Ronaldo Caiado (DEM) afirmou nesta terça que a impressão do voto para conferência do eleitor pode resgatar a “confiança da população” no processo eleitoral. Em audiência na Comissão de Constituição e Justiça (CCJ) com o secretário de Tecnologia da Informação do Tribunal Superior Eleitoral (TSE), Giuseppe Janino, Caiado destacou a importância de dar “transparência total” nessas eleições. “É o sentimento de confiança da população que está em jogo”, disse.
O líder do DEM no Senado disse não haver dúvidas sobre a eficácia da urna eletrônica, mas rejeitar uma medida que traga mais credibilidade só iria agravar as altas taxas de não comparecimento que, segundo o senador, se aproximam de 35%. “Estamos tratando de algo maior do que uma questão técnica”, apelou Caiado.
O senador também comentou as alegações do TSE de ser inviável a implantação do processo, pois seriam necessários R$ 2 bilhões para as despesas. Segundo ele, o valor equivale ao que foi gasto com a reforma do estádio Mané Garrincha, em Brasília, para realização da Copa do Mundo de 2014. “A garantia ao eleitor de que o processo eleitoral é confiável tem um valor muito maior do que uma reforma de um estádio e a população anseia por isso”, afirmou
Postado em Nacional
Compartilhe
Tweetar
==//==
SOURCE/LINK: https://youtu.be/8fDfvwpDor4
Especialista revela toda podridão do voto eletrônico
Verdade Política
286 mil
21.924 visualizações
Publicado em 6 de mar de 2018
O Dr. Diego de Freitas Aranha, do Departamento de Ciência da Computação da UnB, especialista nas áreas de criptografia e segurança de computadores, descreveu com detalhe todas as fragilidades das urnas eletrônicas.
• Categoria
◦ Pessoas e blogs
• Licença
◦ Licença padrão do YouTube
Comentários • 155
Adicionar um comentário público...
Monsenhor Castro5 dias atrás
Mas tá na cara que essa urna eletrônica serve tão somente e muito bem ao comunismo , implantado no Brasil a partir de 1985. Acorda povo ! Pergunta para o Trump se ele quer lá?
67
Plaucio Pucci5 dias atrás
Gostaria de saber porque nenhum movimento do Brasil enfrenta a verdadeira luta pelo voto impresso nem mesmo o seu Criador Será que tem algo por trás de tudo isso
14
yuri NASCIMENTO5 dias atrás
Só pelo fato de apuração da votação ser secreto isso já configura fraude!
119
JOÃO BUDNI5 dias atrás
PARABÉNS DIEGO DE FREITAS ARANHA, SUA ANÁLISE TÉCNICA FOI FUNDAMENTAL PARA QUEM PRESA PELA TRANSPARÊNCIA E SERIEDADE QUE DEVE NORTEAR O TSE E TREs. UMA ALTERNATIVA MUITO DE BOM SENSO ACOLHIDA, É QUE SE NÃO HOUVER TEMPO PARA IMPLANTAR O VOTO IMPRESSO EM TODAS URNAS ELETRÔNICAS, DEVE DESATIVAR AS URNAS SEM IMPRESSÃO DE VOTO E INSERIR A CÉDULA DE PAPEL (COMO SE FAZIA ANTES DAS URNAS ELETRÔNICAS).
35
P Barros5 dias atrás
Ou seja, estamos sendo enganados desde quando essa urna foi implementada
24
Josy Araujo5 dias atrás
O voto eletrônico é que é fraude
Jose Smith5 dias atrás
QUEBRAREMOS AS URNAS ELETRÔNICAS
24
Thiago Rodrigues5 dias atrás
O que o professor falou é muito importante! Precisamos de transparência, pois as eleições não podem ser decididas com margem para dúvidas. Que o Senhor abençoe nosso país!
16
Carlos Marcio Calasans Dos Anjos Marcio5 dias atrás
Se não for feito algo o comunismo tomara conta do país e fradaram as eleições 2018 Mas Deus no comando #Bolsonaro2018
Verdade Bom Senso5 dias atrás
Considerações: 1 - TODA URNA ELETRÔNICA TEM IMPRESSORA TÉRMICA E DEZENAS DE METROS DE PAPEL EM BOBINA; 2 - NADA TE GARANTE QUE O TEU VOTO VAI SER COMPUTADO PRO CARA DA FOTO; 3 - COMO O MESÁRIO DIGITA TEU TÍTULO DE ELEITOR E LIBERA A MÁQUINA PRA VC VOTAR, ELES PODEM DESCOBRIR EM QUEM CADA UM VOTOU; 4 - CÉDULA DE PAPEL, CANETA E URNA DE VERDADE SÃO UM SISTEMA MAIS HONESTO E CONFIÁVEL; 5 - NÃO HÁ A MENOR NECESSIDADE DE SE DESCOBRIR OS ELEITOS NA MESMA NOITE DA ELEIÇÃO, VISTO QUE ELES SÓ VÃO ASSUMIR DOIS MESES DEPOIS.
Inacio Silva Claudinho5 dias atrás
Num país podre nao sabemos qual seria pior. As urnas eletronicas ja foram descobertas aqui e nos países comunistas
Ant.Marcos 48 Marcos5 dias atrás
É por isso que o PT tava dominando tudo. raça ordinária.
Murilo Tri5 dias atrás
Grande Diego Aranha, um ótimo professor da UNICAMP
25
Alexandre Sena5 dias atrás
os politicos corrupto não querei voto impresso por que?não querei perde os dinheiro público federal........
18
wagner Santos5 dias atrás
vao para o inferno urna eletronica e leve a esquerda com vc ...bolsonaro 2018
13
Dyone Sousa5 dias atrás (editado)
TODOS JÁ SABEMOS QUE BOLSONARO SEGUNDO A VONTADE DE DEUS SERÁ PRESIDENTE .
Goiânia5 dias atrás
Voto em cédulas JÁ!
18
Walberlan Santos5 dias atrás
É Brasil, difícil chamar isso de república.
11
Hiram Girao5 dias atrás
TRANSPARÊNCIA NÃO TÊM PREÇO....OU MELHOR, NINGUÉM PECA POR EXCESSO DE INFORMAÇÃO!
mario mendes5 dias atrás
Democracia com essas Urnas Eletrônicas totalmente sujeitas a FRAUDES! é fazer o povo do Brasil de palhaço! Sou a favor de 100% das Urnas Eletrônicas com votos impressos!
7
Reprodução automática
Próximo
• Bia Kicis detona procurador que defendeu urnas eletrônicas na CCJ Verdade Política 26.039 visualizações
◦ Novo
12:40
• Procurador se enrola e leva uma "surra" no senado Verdade Política 21.206 visualizações
◦ Novo
8:44
• A FRAUDE ELEITORAL EM 2014. EXPLICADO COMO FIZERAM A FRAUDE. Klinger 56.379 visualizações
18:54
• Patriota enterra urna eletrônica na mesma cova de Gilmar Mendes Verdade Política 38.792 visualizações
• Novo
9:40
• Capitão da PM de Ceará tira a máscara de Ciro Gomes Força Brasileira 36.736 visualizações
• Novo
7:29
• Procurador da Justiça CALA os defensores de CRIMINOSOS Verdade Política 21.767 visualizações
• Novo
12:09
• Procurador desmascara fraude nas urnas ao vivo no Senado ShowTube BR 83.138 visualizações
• Novo
9:47
• Urna Eletrônica foi criada para manter a esquerda no poder - Levy Fidelix Verdade Política 10.834 visualizações
24:41
• Generais dão aula de ORDEM a jornalistas INDISCIPLINADOS Verdade Política 690.590 visualizações
8:24
• Pondé acaba com as COTAS e a falácia da "dívida cultural" Verdade Política 24.248 visualizações
• Novo
7:54
• Acompanhe a TENSA votação do voto impresso Verdade Política 85.865 visualizações
21:27
• Pondé colocando a esquerda em seu lugar Verdade Política Recomendado
5:26
• BOLSONARO DISPARADO PARA A PRESIDÊNCIA E SENADO Bolsonaro TV 79.674 visualizações
• Novo
19:41
• Urgente! Bolsonaro pode suspender Rede Globo por 24 horas através de uma representação no TSE Canal Patriotas 55.114 visualizações
• Novo
30:57
• Caiado desce a MARRETA no debate sobre LEGALIZAÇÃO de jogos de AZAR Verdade Política 12.301 visualizações
• Novo
9:57
• Acabando com o discurso do "GOLPE" Verdade Política 67.513 visualizações
4:34
• Medeiros ironiza Fábio Assunção em aula sobre Segurança Pública Verdade Política 31.397 visualizações
• Novo
8:07
• Procurador do MS arrasa com argumentos contra o voto impresso Beatriz kicis de sordi 11.946 visualizações
• Novo
9:42
• A revoltante realidade onde menores infratores são inimputáveis Verdade Política 4.454 visualizações
• Novo
8:08
• APOSENTADORIA DE LULA NO INSS EM DETALHES ShowTube BR 285.665 visualizações
• Novo
3:54
•
• Histórico
• Sobre
• Imprensa
• Direitos autorais
• Criadores de conteúdo
• Publicidade
• Desenvolvedores
• +YouTube
• Termos
• Privacidade
• Política e Segurança
• Enviar feedback
• Testar os novos recursos
• © 2018 YouTube, LLC
THE END
No comments:
Post a Comment