Content uploaded by Diego F. Aranha
Author content
All content in this area was uploaded by Diego F. Aranha on Sep 07, 2018
Content may be subject to copyright.
Content uploaded by Paulo Matias
Author content
All content in this area was uploaded by Paulo Matias on Jul 12, 2018
Content may be subject to copyright.
Execuc¸ ˜
ao de c´
odigo arbitr´
ario na urna eletrˆ
onica brasileira
Diego F. Aranha, Pedro Barbosa, Thiago N. C. Cardoso, Caio L¨
uders, Paulo Matias
Unicamp, UFCG, Hekima, UFPE, UFSCar
Abstract.
Multiple serious vulnerabilities were detected during the last Public
Security Tests of the Brazilian voting system. When combined, they allowed to
compromise the main security properties of the system, 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 having complete control over the machine. As
far as we know, this was the most in-depth exploitation of an official large-scale
voting system ever performed during severely restricted tests.
Resumo.
M
´
ultiplas vulnerabilidades graves foram detectadas nos
´
ultimos Testes
P
´
ublicos de Seguran
c¸
a da urna eletr
ˆ
onica brasileira. Quando combinadas,
comprometeram o sigilo do voto e a integridade do software, as principais
propriedades de seguran
c¸
a do sistema. O armazenamento inseguro de chaves
criptogr
´
aficas, inseridas diretamente no c
´
odigo-fonte e compartilhadas entre
todas as urnas, permitiu a inspe
c¸ ˜
ao das m
´
ıdias de instala
c¸ ˜
ao de software, em que
duas bibliotecas compartilhadas sem assinaturas foram encontradas. A inje
c¸ ˜
ao
de c
´
odigo nessas bibliotecas abriu a possibilidade de ter total controle sobre a
urna. At
´
e onde sabemos, esta foi a explora
c¸ ˜
ao mais profunda de um sistema de
vota
c¸ ˜
ao utilizado em larga escala realizada durante testes severamente restritos.
1. Introduc¸ ˜
ao
O Brasil
´
e uma das maiores democracias do mundo, em que mais de 144 milh
˜
oes de
eleitores votar
˜
ao eletronicamente nas pr
´
oximas elei
c¸ ˜
oes gerais. As urnas eletr
ˆ
onicas foram
introduzidas no pa
´
ıs em 1996, ap
´
os relatos frequentes de fraude durante o transporte e
contagem de c
´
edulas eleitorais. As elei
c¸ ˜
oes tornaram-se inteiramente eletr
ˆ
onicas no ano
2000, rapidamente seguidas em 2002 pela primeira experi
ˆ
encia com uma trilha f
´
ısica de
auditoria: o chamado voto impresso, que terminou descontinuado ap
´
os alega
c¸ ˜
oes de alto
custo e complexidade log
´
ıstica. Desde ent
˜
ao, m
´
ultiplas tentativas de reintroduzir o recurso
falharam, sendo a mais recente suspensa pelo Supremo Tribunal Federal.
Como resposta aos pedidos frequentes por maior transpar
ˆ
encia, o Tribunal Superior
Eleitoral (TSE) come
c¸
ou a organizar Testes P
´
ublicos de Seguran
c¸
a (TPS) em 2009. Nesses
eventos, investigadores independentes pr
´
e-aprovados podem examinar os mecanismos de
seguran
c¸
a implementados no sistema por alguns dias, encontrar vulnerabilidades e sugerir
corre
c¸ ˜
oes. Ap
´
os as primeiras edi
c¸ ˜
oes em 2009 e 2012, o evento tornou-se mandat
´
orio no
calend
´
ario eleitoral e agora acontece geralmente no ano anterior
`
as elei
c¸ ˜
oes. Mesmo com
acesso limitado
`
as urnas eletr
ˆ
onicas, os TPS t
ˆ
em se mostrado uma alternativa
´
util para
realizar an
´
alises independentes de seguran
c¸
a. A primeira com acesso ao c
´
odigo-fonte do
sistema foi realizada em 2012 [
Aranha et al. 2014
], quando a equipe vencedora foi capaz
de montar um ataque contra o sigilo do voto baseado na gera
c¸˜
ao insegura de n
´
umeros
aleat
´
orios; e documentar outros problemas de seguran
c¸
a no software de vota
c¸˜
ao, como o
armazenamento e compartilhamento inseguro de chaves criptogr
´
aficas e a verifica
c¸˜
ao insu-
ficiente de integridade, resultados de um processo inseguro de desenvolvimento conduzido
sob modelo de advers´
ario inadequado.
Contribuic¸ ˜
oes
. Este trabalho continua e atualiza os esfor
c¸
os de an
´
alise de
seguran
c¸
a da urna eletr
ˆ
onica, baseado nos resultados obtidos na edi
c¸˜
ao de 2017 dos
TPS. Em resumo, foi poss´
ıvel:
(i)
Recuperar a chave criptogr
´
afica sim
´
etrica que protege as m
´
ıdias de instala
c¸˜
ao
de software, permitindo a leitura de seu conte
´
udo
`
as claras. Como a chave
´
e
compartilhada entre todas as urnas, sua recupera
c¸˜
ao em uma elei
c¸˜
ao real poderia
ter impacto nacional.
(ii)
Detectar duas bibliotecas compartilhadas sem verifica
c¸˜
ao de integridade, permi-
tindo inje
c¸˜
ao direta de c
´
odigo arbitr
´
ario em suas fun
c¸ ˜
oes para manipular seu
comportamento e dos programas ligados, como o aplicativo oficial de votac¸ ˜
ao.
(iii)
Explorar a capacidade de inje
c¸˜
ao de c
´
odigo para violar o sigilo do voto de elei-
tores espec
´
ıficos a partir da manipula
c¸˜
ao de chaves criptogr
´
aficas geradas dina-
micamente; emitir comandos a partir de um teclado comum acoplado
`
a urna; e
manipular o registro cronol´
ogico de eventos gerados pelo software de votac¸ ˜
ao.
(iv)
Injetar c
´
odigo para manipular dinamicamente mensagens exibidas na interface
gr
´
afica, para orientar o eleitor a votar em certos candidatos ou partidos hipot
´
eticos.
A capacidade de injetar c
´
odigo foi ainda estendida para manipular o resultado de
uma elei
c¸˜
ao simulada, pois todos os requisitos estavam presentes. Foi obtido progresso
substancial nessa dire
c¸˜
ao, demonstrando-se que era poss
´
ıvel impedir o armazenamento
dos votos na c
´
edula armazenada em mem
´
oria, o que disparou um erro de consist
ˆ
encia no
software. O ataque foi ent˜
ao adaptado para manipular os votos antes de armazen´
a-los em
mem
´
oria, mas o evento foi encerrado antes que a vers
˜
ao definitiva do ataque pudesse ser
executada no equipamento.
Organizac¸ ˜
ao
. A Se
c¸˜
ao 2 apresenta o sistema de vota
c¸˜
ao eletr
ˆ
onica brasileiro e
a Se
c¸˜
ao 3 resume resultados de an
´
alises de seguran
c¸
a anteriores. A Se
c¸˜
ao 4 descreve a
prepara
c¸˜
ao da equipe e observa
c¸ ˜
oes coletadas durante a inspe
c¸˜
ao de c
´
odigo para formular
os planos de teste. A Se
c¸˜
ao 5 detalha a execu
c¸˜
ao dos planos de teste e achados correspon-
dentes. A Se
c¸˜
ao 6 discute os resultados considerando alega
c¸ ˜
oes oficiais do TSE e a
´
ultima
sec¸˜
ao finaliza o artigo com conclus˜
oes e perspectivas futuras.
2. Vis˜
ao geral do sistema
As urnas eletr
ˆ
onicas foram introduzidas nas elei
c¸ ˜
oes de 1996 em 56 munic
´
ıpios. As pri-
meiras m
´
aquinas foram fabricadas pela Unisys e equipadas com processadores Intel 80386.
Em termos de software, empregavam um sistema operacional nacional compat
´
ıvel com o
DOS chamado VirtuOS. Modelos posteriores mantiveram a mesma apar
ˆ
encia e interface,
mas adotaram outros componentes de software, como o sistema operacional Windows CE,
com aplicativos desenvolvidos pela empresa Procomp, subsidi
´
aria brasileira da Diebold.
Posteriormente, o sistema operacional GNU/Linux foi adotado e o desenvolvimento passou
a ser responsabilidade do TSE. Os modelos mais recentes da urna eletr
ˆ
onica, introduzidos
em 2009 e 2015, incluem um m
´
odulo de seguran
c¸
a em hardware (chamado MSD – Master
Security Device) para realizar tarefas cr
´
ıticas de seguran
c¸
a, como armazenar chaves crip-
togr
´
aficas e verificar a integridade do software durante a inicializa
c¸˜
ao. Em 2008, o Tribunal
iniciou o cadastramento biom´
etrico, atingindo recentemente metade da populac¸˜
ao.
2.1. Equipamento
A urna eletr
ˆ
onica (Figura 1) realiza a grava
c¸˜
ao digital direta do voto, sendo classificada
como DRE (Direct Recording Electronic), ou seja, n
˜
ao h
´
a a presen
c¸
a de qualquer tipo de
registro f
´
ısico do voto confer
´
ıvel pelo eleitor. A m
´
aquina
´
e composta por um terminal
do mes
´
ario, utilizado para digitar comandos, t
´
ıtulos de eleitor ou coletar biometria; e
outro terminal utilizado pelo eleitor para votar. Ambos os terminais s
˜
ao conectados por
um cabo f
´
ısico, uma decis
˜
ao de projeto question
´
avel do ponto de vista do sigilo do voto,
j
´
a que o terminal do eleitor possui acesso tanto
`
a identidade como
`
as escolhas de cada
eleitor [
van de Graaf and Cust´
odio 2002
]. Al
´
em dos teclados de entrada, a comunica
c¸˜
ao
com a urna
´
e poss
´
ıvel a partir de cart
˜
oes de mem
´
oria respons
´
aveis por instalar o sistema
operacional e componentes de software (flash de carga – FC) na mem
´
oria interna da
urna; e por armazenar os metadados de candidatos e eleitores (flash de vota
c¸˜
ao – FV).
Durante uma elei
c¸˜
ao, os arquivos s
˜
ao armazenados de forma redundante tanto na mem
´
oria
interna quanto na FV. H
´
a uma porta USB na parte traseira da urna para se inserir um
dispositivo chamado Mem
´
oria de Resultados (MR), que armazena resultados e demais
arquivos p
´
ublicos da elei
c¸˜
ao. O acesso a todas as interfaces externas
´
e protegido por lacres
assinados por um juiz em cerimˆ
onia oficial.
Figura 1. A urna eletr ˆ
onica brasileira e seus dois terminais.
2.2. Procedimento oficial
Na fase de desenvolvimento, o software
´
e atualizado e inspecionado por institui
c¸ ˜
oes
autorizadas, sob Termo de Sigilo, at
´
e poucos meses antes das elei
c¸ ˜
oes. Uma vers
˜
ao do
software
´
e compilada na cerim
ˆ
onia oficial de lacra
c¸˜
ao e distribu
´
ıda para os Tribunais
Regionais Eleitorais (TREs), onde termina armazenada nas FCs geradas pelo sistema
GEDAI-UE (Gerenciador de Dados, Aplicativos e Interface com a Urna Eletr
ˆ
onica). Esses
cart
˜
oes de mem
´
oria, por sua vez, s
˜
ao transportados at
´
e as urnas para instalar o software
oficial alguns dias antes das elei
c¸ ˜
oes. Segundo informa
c¸˜
ao do TSE, cada FC instala at
´
e
50 urnas eletr
ˆ
onicas distintas. Ao contr
´
ario de outros pa
´
ıses, a log
´
ıstica de distribui
c¸˜
ao
permite atualizar o software a cada eleic¸˜
ao.
O processo de instala
c¸˜
ao do software da FC na urna eletr
ˆ
onica
´
e implementado
pelo m
´
odulo SCUE (Sistema de Carga da Urna Eletr
ˆ
onica), armazenado na pr
´
opria FC
e utilizado para copiar os arquivos para a mem
´
oria interna ap
´
os auto-verifica
c¸˜
ao de inte-
gridade. Ap
´
os a carga, a m
´
aquina j
´
a pode ser inicializada pela primeira vez diretamente
da mem
´
oria interna, quando esta executa tamb
´
em um teste de hardware. A atribui
c¸˜
ao de
uma urna eletr
ˆ
onica para uma sess
˜
ao eleitoral
´
e autenticada por uma assinatura digital
curta e o resultado
´
e chamado Resumo de Correspond
ˆ
encia. Uma base de dados con-
tendo as atribui
c¸ ˜
oes
´
e publicada posteriormente. No dia da elei
c¸˜
ao, executa-se o mesmo
procedimento em todas as sec¸ ˜
oes eleitorais:
1.
Entre 7h e 8h da manh
˜
a, imprime-se a zer
´
esima, documento oficial que suposta-
mente atesta que nenhum voto foi previamente computado para qualquer candidato;
2. O mes´
ario respons´
avel abre a votac¸˜
ao `
as 8h;
3. Os eleitores utilizam a urna eletrˆ
onica para inserir suas escolhas;
4. O mes´
ario respons´
avel encerra a votac¸˜
ao `
as 17h;
5.
Emitem-se vias do Boletim de Urna (BU) em papel, contendo a totaliza
c¸˜
ao parcial
dos candidatos. C
´
opias do documento f
´
ısico s
˜
ao assinadas, distribu
´
ıdas e fixadas
em lugar vis´
ıvel da sec¸˜
ao eleitoral;
6.
Gravam-se os chamados produtos p
´
ublicos de vota
c¸˜
ao, cujos principais componen-
tes s
˜
ao a vers
˜
ao digital do BU para totaliza
c¸˜
ao, o registro cronol
´
ogico de eventos
(LOG) e o Registro Digital do Voto (RDV). Este
´
ultimo consiste em uma lista fora
de ordem dos votos recebidos pela urna. Esses arquivos s
˜
ao assinados digitalmente
e armazenados na MR.
7. O mes´
ario rompe o lacre e retira a MR contendo os produtos p´
ublicos da eleic¸˜
ao;
8.
Os produtos p
´
ublicos armazenados na MR s
˜
ao transmitidos para o totalizador a
partir de uma rede privada, em um computador inicializado com um LiveUSB
dedicado produzido pela Justic¸a Eleitoral e denominado JE Connect.
O papel do totalizador consiste em combinar todas as parciais no resultado decla-
rado como oficial, etapa que dura poucas horas. Ap
´
os 3 dias, vers
˜
oes digitais dos BUs
recebidas pelo totalizador s
˜
ao disponibilizadas pelo TSE para compara
c¸˜
ao com vers
˜
oes em
papel impressas no dia da eleic¸˜
ao.
2.3. Ecossistema de software
A base de c
´
odigo disponibilizada no TPS 2017, marcada com a identifica
c¸˜
ao “A Hora
da Estrela”, possui uma complexidade da ordem de 40 milh
˜
oes de linhas de c
´
odigo, se
inclu
´
ıdos todos os componentes dispon
´
ıveis para inspe
c¸˜
ao. O subconjunto correspon-
dente apenas
`
a urna eletr
ˆ
onica possui 24 milh
˜
oes de linhas, compondo uma distribui
c¸˜
ao
GNU/Linux personalizada (UENUX) para a arquitetura Intel de 32 bits. Al
´
em das bibliote-
cas t
´
ıpicas em espa
c¸
o de usu
´
ario, est
˜
ao presentes o aplicativo oficial de vota
c¸˜
ao (VOTA),
o sistema de carga (SCUE), um Recuperador de Dados (RED), o Sistema de Apura
c¸˜
ao
(SA) para inser
c¸˜
ao de resultados parciais em caso de conting
ˆ
encia, e o Gerenciador de
Aplicativos (GAP). Os componentes de baixo n
´
ıvel incluem um bootloader baseado no
Syslinux
1
e um kernel Linux, ambos personalizados. O bootloader
´
e disparado pela BIOS
a partir de um endere
c¸
o n
˜
ao padronizado e adaptado para decifrar o kernel. O kernel inclui
suporte a dispositivos e mecanismos de seguran
c¸
a personalizados. Na ocasi
¨
ao, a base de
c
´
odigo estava migrando o kernel da vers
˜
ao 2.6 para 3.18, ambas dispon
´
ıveis para inspe
c¸˜
ao.
Cifrac¸ ˜
ao.
A urna eletr
ˆ
onica implementa v
´
arios mecanismos com o objetivo de
preservar a integridade do software. Para isso, combina m
´
ultiplas camadas de cifra
c¸˜
ao,
visando dificultar a inspe
c¸˜
ao e a extra
c¸˜
ao de informa
c¸˜
ao sens
´
ıvel por atacantes externos,
1Syslinux bootloader: http://www.syslinux.org
Bootloader
Kernel
sistema de
arquivos
chaves de
autenticação
(a) Cifra
c¸˜
ao encadeada em camadas na FC. As
setas denotam posse de chaves criptogr
´
aficas
para decifrar o pr´
oximo n´
ıvel.
separadas
(b) Cadeia de confian
c¸
a da urna eletr
ˆ
onica. As
assinaturas separadas s
˜
ao armazenadas em ar-
quivos com extens
˜
ao VST e verificadas pelo
SCUE durante a carga.
Figura 2. Cifrac¸ ˜
ao e autenticac¸ ˜
ao na urna eletr ˆ
onica.
tanto da FC quanto na mem
´
oria interna. Como exemplo de mecanismo de baixo n
´
ıvel, o
bootloader cont
´
em uma chave AES-256 para decifrar a imagem do kernel sob o modo de
opera
c¸˜
ao ECB durante a inicializa
c¸˜
ao do sistema. O kernel possui chaves embutidas para
cifrar/decifrar arquivos individuais em um sistema de arquivos MINIX sob o modo AES-
XTS; e para implementar um reposit
´
orio de chaves criptogr
´
aficas cifradas sob AES-256
em modo CBC. A Figura 2(a) apresenta as v
´
arias camadas de cifra
c¸˜
ao, com m
´
odulos em
n´
ıveis superiores sendo respons´
aveis por decifrar os m´
odulos imediatamente inferiores.
Autenticac¸ ˜
ao.
O reposit
´
orio de chaves mantido pelo kernel armazena chaves de
autentica
c¸ ˜
ao, que consistem em chaves privadas para assinar resultados de elei
c¸˜
ao, chaves
p
´
ublicas e certificados para verifica
c¸˜
ao de assinaturas. BIOS, bootloader ekernel recebem
assinaturas digitais ECDSA instanciadas com a curva NIST P-521. A Figura 2(b) apresenta
a cadeia de confian
c¸
a, que come
c¸
a no MSD e continua com cada componente autenticando
o seguinte at
´
e que as aplica
c¸ ˜
oes de usu
´
ario sejam carregadas e executadas. M
´
odulos de
kernel, bin´
arios execut´
aveis e bibliotecas compartilhadas s˜
ao assinadas digitalmente com
o algoritmo RSA e verificadas com uma chave p
´
ublica de 4096 bits embutida no kernel.
Al
´
em disso, os produtos p
´
ublicos de elei
c¸˜
ao e todos os arquivos armazenados na FC e na FV
recebem assinaturas digitais separadas, produzidas com o algoritmo Elgamal instanciado
com a curva NIST P-256, e armazenadas com sintaxe ASN.1 em arquivos com extens
˜
ao
VST. Desde 2016, os BUs incluem autenticadores calculados com o algoritmo SipHash e
um c
´
odigo QR assinado com o algoritmo EdDSA contendo os totais em formato amig
´
avel
para leitura e comparac¸˜
ao com as parciais divulgadas pelo TSE [Aranha et al. 2016].
Gerac¸ ˜
ao de n´
umeros aleat´
orios.
Muitos dos algoritmos criptogr
´
aficos utilizados
para cifra
c¸˜
ao e autentica
c¸˜
ao necessitam de entropia, e h
´
a m
´
ultiplos algoritmos espalhados
na base de c
´
odigo. As assinaturas Elgamal calculadas pelo MSD utilizam a fam
´
ılia
xorshift
de geradores [
Marsaglia 2003
]. O mecanismo de embaralhamento de votos
no RDV
´
e implementado pela combina
c¸˜
ao de dois outros geradores: coleta de entropia
do sistema operacional por meio do arquivo
/dev/urandom
, ou alternadamente de um
gerador personalizado cujo algoritmo
´
e uma variante de 32 bits da vers
˜
ao de 64 bits de um
algoritmo obscuro chamado Sapparot-2 [Levin 2005].
3. Trabalhos relacionados
M
´
aquinas de votar do tipo DRE s
˜
ao largamente criticadas na literatura cient
´
ıfica, prin-
cipalmente por suas falhas de projeto e implementa
c¸˜
ao, impossibilidade de auditoria
independente de software [
Rivest 2008
] e vulnerabilidade contra ataques internos. Mo-
delos fabricados pela Diebold foram sujeitos a m
´
ultiplas an
´
alises de seguran
c¸
a com
resultados desastrosos [
Calandrino et al. 2007
] e vulnerabilidades desde a manipula
c¸˜
ao
de resultados eleitorais at
´
e a infec
c¸˜
ao por malware de outros equipamentos. A maio-
ria dos problemas parece ter sido resultado de pr
´
aticas inseguras de desenvolvimento e
complexidade do software de vota
c¸˜
ao. Outros trabalhos analisaram sistemas comparati-
vamente mais simples de vota
c¸˜
ao e encontraram problemas similares, como os ataques
`
as m
´
aquinas holandesas Nedap [
Gonggrijp and Hengeveld 2007
], e ataques em hardware
`
as m
´
aquinas EVM utilizadas na
´
India [
Wolchok et al. 2010
]. O registro f
´
ısico dos votos
tamb
´
em n
˜
ao
´
e panaceia: especialistas independentes j
´
a descobriram vulnerabilidades em
sistemas h
´
ıbridos com registro eletr
ˆ
onico e impresso, como os utilizados em partes da
Argentina [Amato et al. 2015].
No caso do Brasil, os TPS t
ˆ
em sido a melhor oportunidade para especialistas
independentes avaliarem a seguran
c¸
a dos mecanismos implementados no sistema de
vota
c¸˜
ao. O objetivo dos especialistas
´
e violar as propriedades cl
´
assicas de seguran
c¸
a de
qualquer sistema de vota
c¸˜
ao, como sigilo do voto e integridade de resultados, e sugerir
aprimoramentos para restaurar a seguran
c¸
a dos mecanismos afetados. O formato e escopo
dos testes evoluiu com o tempo, e o evento recentemente tornou-se uma etapa oficial no
calend
´
ario eleitoral. Na primeira edi
c¸˜
ao dos TPS, uma competi
c¸˜
ao organizada em 2009,
pesquisadores n
˜
ao tiveram acesso ao c
´
odigo-fonte do sistema. Como resultado, a estrat
´
egia
vencedora consistiu em quebrar o sigilo do voto pela captura de frequ
ˆ
encias de r
´
adio
emitidas pelo teclado da urna [
TSE 2009
]. Posteriormente, o TSE alegou ter blindado o
teclado contra esse tipo de ataque.
Em 2012, especialistas independentes tiveram a primeira oportunidade de examinar
o c
´
odigo-fonte do sistema sem Termo de Sigilo, o que foi suficiente para se descobrir as
primeiras vulnerabilidades de software. A estrat
´
egia vencedora foi a recupera
c¸˜
ao em ordem
de uma quantidade realista de votos coletados por uma urna eletr
ˆ
onica durante uma elei
c¸˜
ao
simulada. O ataque foi baseado apenas em informa
c¸˜
ao p
´
ublica armazenada no RDV e
conhecimento superficial sobre como os votos eram armazenados no arquivo. A principal
vulnerabilidade foi uma chamada a
srand(time(0))
no c
´
odigo de embaralhamento de
votos, seguida pela impress
˜
ao do instante de tempo na zer
´
esima. Com o conhecimento da
ordem de vota
c¸˜
ao, torna-se poss
´
ıvel violar o sigilo do voto de uma se
c¸˜
ao eleitoral inteira;
ou revelar o voto de uma autoridade importante cujo instante de tempo de vota
c¸˜
ao seja
conhecido, dado que o arquivo de LOG p
´
ublico armazena os instantes de vota
c¸˜
ao em ordem.
Outras falhas de projeto incluem compartilhamento massivo de chaves criptogr
´
aficas,
armazenamento inseguro de material secreto e escolha inadequada de algoritmos. O
relat´
orio da equipe vencedora [Aranha et al. 2014] descreve a experiˆ
encia em detalhes.
Ap
´
os um hiato em 2014, os TPS tiveram continuidade apenas em 2016, com a
introdu
c¸˜
ao de um Termo de Sigilo e extens
˜
ao do escopo para incluir o subsistema GEDAI-
UE e parte do sistema de transmiss
˜
ao. Nessa edi
c¸˜
ao, apresentou-se o primeiro ataque
bem-sucedido
`
a integridade de resultados, pela forja de c
´
odigos de verifica
c¸˜
ao de BUs
validados pelo Sistema de Apura
c¸˜
ao em caso de conting
ˆ
encia [
TSE 2016
]. Ap
´
os press
˜
ao
substancial da comunidade t
´
ecnica, o Termo de Sigilo foi relaxado no ano subsequente,
permitindo a participa
c¸˜
ao de mais especialistas; e o escopo foi estendido para incluir o
firmware do MSD. O sistema de identificac¸˜
ao biom´
etrica continua fora de escopo.
4. Planejamento
A edi
c¸˜
ao de 2017 dos testes foi composta por cinco fases: registro e aprova
c¸˜
ao dos partici-
pantes, inspe
c¸˜
ao de c
´
odigo, submiss
˜
ao de planos de teste, execu
c¸˜
ao dos testes, e divulga
c¸˜
ao
dos resultados. As regras para participa
c¸˜
ao foram descritas em uma chamada p
´
ublica
oficial. Durante a fase de registro, entre Agosto e Setembro, pesquisadores individuais e
times de at
´
e cinco membros submeteram suas informa
c¸ ˜
oes de registro para sele
c¸˜
ao pela
comiss˜
ao organizadora.
4.1. Inspec¸ ˜
ao de c´
odigo
A inspe
c¸˜
ao de c
´
odigo foi realizada em computadores com Ubuntu 14.04 providos pelo
TSE. N
˜
ao havia acesso
`
a Internet e n
˜
ao foi permitido entrar ou sair do ambiente de
inspe
c¸˜
ao com material eletr
ˆ
onico. Consequentemente, n
˜
ao foi permitido instalar software
de prefer
ˆ
encia dos investigadores, por exemplo um editor de texto poderoso como o
vim
,
ou um compilador C. As principais ferramentas utilizadas para buscar vulnerabilidades
foram o comando
grep
e o editor de texto
nano
. Rapidamente percebeu-se que faltavam
alguns arquivos e conte
´
udos de vari
´
aveis. Surpreendentemente, o TSE restringiu acesso
`
as chaves criptogr
´
aficas (removendo trechos do c
´
odigo-fonte), apresentando assim uma
vers˜
ao modificada e incompleta da base de c´
odigo para os participantes.
V
´
arias vulnerabilidades em potencial foram encontradas utilizando
grep
. Uma
importante estava relacionada com a cifra
c¸˜
ao do sistema de arquivos da FC, baseada em
AES-XTS de 256 bits e com a chaves armazenadas no FC. Para cifrar, o AES-XTS utiliza
duas chaves, como apresentado na Figura 3. Abaixo cada uma das vari
´
aveis observadas
durante a inspec¸˜
ao de c´
odigo s˜
ao descritas:
•key1
: Primeira parte da chave do AES-XTS, de 256 bits, cujo valor estava embutido
no kernel.
•key2
: Segunda parte da chave do AES-XTS, tamb
´
em de 256 bits, computada de
acordo com o Algoritmo 1, no qual a fun
c¸˜
ao GE T BYTE
(n)
retorna o
n
-
´
esimo byte
da partic¸˜
ao da FC.
•i
: Vetor de inicializa
c¸˜
ao. Durante a inspe
c¸˜
ao de c
´
odigo, observou-se que
i
corres-
pondia ao n´
umero do inode do arquivo a ser cifrado/decifrado.
•α
: Elemento primitivo do corpo finito
GF (2128)
. A vers
˜
ao implementada pelo TSE
desvia da especificac¸˜
ao e reinicia o valor αja cada 256 blocos.
•Pj
: O
j
-
´
esimo bloco de texto claro. Todos os blocos, exceto possivelmente o
´
ultimo, possuem 128 bits.
•Cj: O j-´
esimo bloco de conte´
udo cifrado, de 128 bits.
A decifra
c¸˜
ao usa o mesmo esquema da Figura 3, exceto que o conte
´
udo cifrado
serve como entrada (no lugar de
Pj
) e o texto claro
´
e obtido como sa
´
ıda (
Cj
). Apesar
do TSE ter removido as chaves criptogr
´
aficas para a fase inspe
c¸˜
ao de c
´
odigo, a chave de
cifra
c¸˜
ao do sistema de arquivos
key1
permaneceu presente na
´
arvore mais recente (vers
˜
ao
3.18) do kernel. Esse fato ocorreu devido a falha operacional da equipe t
´
ecnica do TSE.
No entanto, sabia-se que tamb
´
em era poss
´
ıvel obter a chave
key1
atrav
´
es de engenharia
reversa do kernel ap´
os este ser decifrado pelo bootloader.
AES
Encrypt
AES
Encrypt
Figura 3. Cifrac¸ ˜
ao da FC, ba-
seada no algoritmo AES-XTS.
function GE T KEY
key2← {}
offset1←512 + 7
offset2←512 + 128
b←GE T BYTE(offset1)
for n←0to 32 do
key2[n]←GET BYTE(offset2+n)⊕b
return key2
Algoritmo 1. Obtenc¸ ˜
ao da chave AES-
XTS key2da FC.
4.2. Planos de teste
Para avaliar a seguran
c¸
a da urna, foi adotado o paradigma GQM (Goal, Question, Met-
ric) [
Basili 1992
], uma forma de definir e avaliar os objetivos atrav
´
es de m
´
etricas. GQM
define um modelo de medi
c¸˜
ao em tr
ˆ
es n
´
ıveis: conceitual (Objetivos), operacional (Quest
˜
oes
de Pesquisa) e quantitativo (M
´
etricas). Um objetivo especificado com GQM possui os
seguintes atributos: prop
´
osito, objeto de estudo, foco, parte interessada e contexto. Um
objetivo GQM que expressa os interesses durante os TPS
´
e o seguinte: O prop
´
osito do
estudo foi
avaliar a seguranc¸a
do
sistema eletrˆ
onico de votac¸ ˜
ao
quando este
est´
a em uso
pelos eleitores no contexto de uma eleic¸˜
ao.
Naturalmente, todos os ataques precisavam encaixar-se no escopo definido para
o TPS. A equipe submeteu quatro planos de teste, todos aprovados pelo TSE e listados
abaixo na forma de Quest˜
oes de Pesquisa (QPs).
QP1: ´
E poss´
ıvel extrair chaves criptogr´
aficas da FC?
Como n
˜
ao se sabia se a
chave
key1
encontrada durante a inspe
c¸˜
ao de c
´
odigo era verdadeira, este plano consistia
em realizar engenharia reversa para extrair chaves criptogr´
aficas.
QP2: ´
E poss´
ıvel violar o sigilo do voto explorando o gerador de n´
umeros
pseudo-aleat´
orios?
Este plano de teste consistia em verificar se a vulnerabilidade no
sigilo do voto descoberta nos TPS 2012 foi de fato corrigida.
QP3: ´
E poss´
ıvel inserir um dispositivo USB malicioso na urna?
A urna possui
duas entradas USB no terminal do eleitor e duas no terminal do mes
´
ario. Este plano de
teste consistia em usar dispositivos USB program
´
aveis, como o Raspberry Pi Zero e o
FaceDancer, para tentar personificar o MSD.
QP4: ´
E poss´
ıvel executar c´
odigo remoto na plataforma web de totalizac¸ ˜
ao?
O
acesso
`
a plataforma web
´
e permitido apenas atrav
´
es de uma VPN (Virtual Private Network).
No entanto, as credenciais da VPN provavelmente podem ser extra
´
ıdas do JE Connect.
Explorar uma vulnerabilidade no servidor web poderia permitir a falsifica
c¸˜
ao dos resultados
de totalizac¸˜
ao.
Para cada QP, a m
´
etrica considerada foi a quantidade de vulnerabilidades exploradas
e demonstradas ao TSE. Assim, uma explora
c¸˜
ao bem-sucedida j
´
a seria o suficiente para
suportar a referida QP de forma positiva.
5. Execuc¸ ˜
ao
De posse da chave criptogr
´
afica
key1
capturada do c
´
odigo-fonte e da posi
c¸˜
ao fixa para a
chave
key2
, um programa para decifrar FCs foi inicialmente implementado em Python nas
m
´
aquinas de inspe
c¸˜
ao de c
´
odigo. Como n
˜
ao havia compilador no ambiente de inspe
c¸˜
ao, o
utilit
´
ario de linha de comando do OpenSSL foi chamado para decifrar cada bloco individual.
O programa foi testado e funcionou corretamente em um prot
´
otipo do sistema de arquivos.
Essa abordagem terminou ineficiente para arquivos grandes, devido
`
a quantidade de
processos disparados, o que motivou a escrita de um novo programa nos computadores
de teste, desta vez utilizando o m
´
odulo pycrypto
2
. Dada a limita
c¸˜
ao no uso de papel para
anota
c¸ ˜
oes, a chave criptogr
´
afica foi memorizada um byte por vez para ser transportada do
ambiente de inspec¸˜
ao de c´
odigo at´
e a bancada de testes.
Decifrac¸ ˜
ao da FC.
A inspe
c¸˜
ao do conte
´
udo decifrado da FC permitiu analisar
com cuidado a cadeia de confian
c¸
a da urna eletr
ˆ
onica. Como descrito na Figura 2(b),
o processo tem in
´
ıcio na verifica
c¸˜
ao da assinatura da BIOS pelo MSD e termina com
a valida
c¸˜
ao de arquivos individuais a partir de assinaturas separadas armazenadas nos
arquivos de extens
˜
ao VST. Durante a inicializa
c¸˜
ao e a instala
c¸˜
ao do software, os arquivos
e assinaturas s
˜
ao verificadas. O entendimento da cadeia de confian
c¸
a motivou a busca de
vulnerabilidades adicionais nesse mecanismo. Assim, submeteu-se mais um plano de teste,
apresentado a seguir em forma de Quest˜
ao de Pesquisa:
QP5: ´
E poss´
ıvel executar c´
odigo arbitr´
ario na urna eletrˆ
onica?
Se existisse
alguma vulnerabilidade na cadeia de confian
c¸
a, talvez fosse poss
´
ıvel violar a integridade
do software e consequentemente executar c
´
odigo arbitr
´
ario. Tal ataque permitiria a um
atacante ter total controle sobre a urna (inclusive, para adulterar os votos dos eleitores).
A primeira tentativa da equipe foi a inclus
˜
ao de arquivos sem assinatura digital na
FC, que n
˜
ao provocou interfer
ˆ
encia no processo de carga. O exame cuidadoso dos arquivos
VST revelou que duas bibliotecas compartilhadas utilizadas pelo sistema de vota
c¸˜
ao n
˜
ao
possu
´
ıam assinaturas. Estas bibliotecas eram utilizadas para manter o registro cronol
´
ogico
de eventos (
libapilog.so
) e gerar chaves criptogr
´
aficas para o RDV utilizando uma
fun
c¸˜
ao de deriva
c¸˜
ao de chaves HKDF baseada no algoritmo HMAC (
libhkdf.so
). Ao
introduzir c
´
odigo estranho nessas bibliotecas para realizar uma chamada de sistema para
imprimir a mensagem “
FRAUDE!
”, ficou evidente que a equipe tinha capacidade para
execu
c¸˜
ao arbitr
´
aria de c
´
odigo, vetor de ataque principal utilizado no restante dos TPS.
Uma vez que o tempo para o TPS era bastante restrito, a equipe n
˜
ao investigou as Quest
˜
oes
de Pesquisa QP2,QP3 eQP4, mas focou nas mais promissoras: QP1 eQP5.
Manipulac¸ ˜
ao do LOG
. A capacidade de injetar c
´
odigo arbitr
´
ario foi ent
˜
ao exer-
citada de m
´
ultiplas formas, a primeira delas pela introdu
c¸˜
ao de c
´
odigo para imprimir a
entrada de um teclado USB acoplado
`
a urna. Em seguida, a mensagem
INFO
utilizada
para marcar eventos informativos no LOG foi alterada para a cadeia
XXXX
no arquivo
libapilog.so
, ilustrando a possibilidade de modificar-se arbitrariamente o registro
cronol
´
ogico de eventos. Como esperado, uma elei
c¸˜
ao simulada preservou a altera
c¸˜
ao e a
adulterac¸˜
ao foi confirmada pelo exame do arquivo LOG armazenado na MR.
Quebra do sigilo do voto
. Em outro ataque, adulterou-se a biblioteca
libhkdf.so
para inserir um retorno antecipado, for
c¸
ando a chave derivada dinami-
2Ferramentas criptogr´
aficas em Python: https://github.com/dlitz/pycrypto
(a)
(b)
Figura 4. Reproduc¸ ˜
ao da modificac¸ ˜
ao dinˆ
amica em uma das mensagens contidas
no aplicativo VOTA. (a) Interface original. (b) Interface comprometida – o software
de votac¸ ˜
ao agora faz propaganda para um candidato hipot´
etico.
camente para cifrar o RDV a assumir o valor zero. Como o RDV armazena cada voto
depositado na urna eletr
ˆ
onica fora de ordem, o exame do arquivo antes e depois de voto
por um eleitor espec
´
ıfico revela as escolhas daquele eleitor. Com a biblioteca sempre
calculando uma chave zerada, o arquivo RDV p
ˆ
ode ser trivialmente decifrado. Este ataque
foi demonstrado no contexto de um mes
´
ario malicioso que extrai a FV durante a elei
c¸˜
ao,
mas
´
e evidente que o controle sobre o software permite injetar c
´
odigo que armazene os
votos em ordem.
Interferˆ
encia sobre a interface gr´
afica
. Para comprometer o espa
c¸
o de mem
´
oria
do aplicativo oficial de vota
c¸˜
ao (VOTA), a equipe analisou o bin
´
ario desmontado, buscando
endere
c¸
os de trechos de c
´
odigo interessantes ou vari
´
aveis globais. O bin
´
ario estava com-
pactado com UPX
3
em um formato fora do padr
˜
ao, o que consumiu tempo adicional. Uma
vez descompactado o bin
´
ario, percebeu-se que n
˜
ao havia contramedidas para explora
c¸˜
ao de
c
´
odigo, pois o bin
´
ario n
˜
ao estava em formato independente de posi
c¸˜
ao. Isso simplificou em
muito a explora
c¸˜
ao, pois todos os endere
c¸
os eram fixos. O c
´
odigo de ataque foi introduzido
na biblioteca HKDF.
O ataque prosseguiu com a introdu
c¸˜
ao da chamada de sistema
mprotect
para
alterar permiss
˜
oes de p
´
aginas somente leitura, o que permitiu alterar a vers
˜
ao do software
de vota
c¸˜
ao (localizada na se
c¸˜
ao
.rodata
) para “A Hora da Treta”, vis
´
ıvel nos arquivos
armazenados na MR ap
´
os uma elei
c¸˜
ao simulada. Para tornar o ataque ainda mais evidente,
a pr
´
oxima mensagem a ser alterada foi “SEU VOTO PARA”, conforme reprodu
c¸˜
ao na
Figura 4(b), de forma a instruir os eleitores a votarem no candidato de n´
umero 99.
Interferˆ
encia sobre os votos
. A an
´
alise do aplicativo VOTA prosseguiu at
´
e que o
m
´
etodo
AdicionaVoto
foi encontrado. Esse m
´
etodo
´
e chamado apenas quando o voto
depositado j
´
a foi exibido na tela e confirmado pelo eleitor, de forma que interferir com seu
funcionamento n
˜
ao deveria produzir qualquer evid
ˆ
encia para o eleitor. Para comprometer
o m
´
etodo, um programa em Python foi escrito para infectar o m
´
etodo com o c
´
odigo
apresentado abaixo. Esse trecho de c
´
odigo carrega no registrador
eax
uma refer
ˆ
encia
`
a
vari
´
avel string que cont
´
em o voto armazenado e carrega no registrador
edi
um ponteiro
para os caracteres, finalmente escrevendo um caractere 9no enderec¸o subsequente.
mov eax, [ebp+0x14]; std::string&
mov edi, [eax]; char*
mov al,'9'
stosb
stosb
3UPX: Ultimate Packer for eXecutables – https://upx.github.io
Testar cada nova vers
˜
ao do ataque na urna eletr
ˆ
onica tomava entre 30 e 40 minutos,
devido ao procedimento de auto-teste exigido pela carga de uma nova vers
˜
ao do software.
Por esse motivo, uma vers
˜
ao mais simples do ataque foi testada para abortar de maneira
antecipada o m
´
etodo
AdicionaVoto
enquanto a explora
c¸˜
ao mais sofisticada era testada
por simula
c¸˜
ao. Como o ataque mais simples prevenia que votos fossem armazenados
na urna, o software de vota
c¸˜
ao comportou-se como esperado e disparou um erro de
consist
ˆ
encia apontando que a c
´
edula em mem
´
oria estava vazia – nenhum voto digitado
pelo eleitor foi armazenado. Os testes foram ent
˜
ao interrompidos pontualmente
`
as 18h do
´
ultimo dia, antes que o ataque mais sofisticado pudesse ser testado no equipamento real.
6. Discuss˜
ao
No
´
ultimo dia dos TPS, um grupo de peritos criminais da Pol
´
ıcia Federal foi capaz de fazer
engenharia reversa e recuperar a imagem do kernel
`
as claras ap
´
os fixar o bootloader em um
endere
c¸
o padr
˜
ao, quando carregado em uma m
´
aquina virtual. Inspecionando a mem
´
oria,
eles obtiveram a mesma chave criptogr
´
afica do AES-XTS que havia sido encontrada
durante a inspe
c¸˜
ao de c
´
odigo. Desta forma, h
´
a suporte
`
a Quest
˜
ao de Pesquisa
QP1
:
Foi poss´
ıvel extrair chaves criptogr´
aficas da FC
. Esse fato confirma que os ataques
subsequentes n˜
ao possu´
ıam premissas, e que o acesso ao c´
odigo-fonte era desnecess´
ario.
A conclus
˜
ao
´
e que a integridade do software e dos resultados depende do sigilo da
chave sim
´
etrica armazenada no bootloader. Al
´
em de ser trivial para o time de desenvolvi-
mento acess
´
a-la, essa chave tamb
´
em pode ser obtida por um atacante externo, uma vez
que
´
e armazenada em texto claro nos cart
˜
oes de instala
c¸˜
ao. O fato
´
e que, este mecanismo
sequer pode ser considerado cifra
c¸˜
ao, mas sim uma forma bem mais fraca de ofusca
c¸˜
ao.
Essas vulnerabilidades n
˜
ao s
˜
ao algo novo: o relat
´
orio dos TPS 2012 [
Aranha et al. 2014
]
j´
a havia indicado a fragilidade das chaves armazenadas de forma insegura no software de
vota
c¸˜
ao. Naquela vers
˜
ao, a mesma chave e vetor de inicializa
c¸˜
ao (IV) eram compartilhados
por todas as m
´
aquinas de vota
c¸˜
ao para cifrar arquivos utilizando AES-256 no modo CBC.
A´
unica melhoria observada em 2017 foi a adoc¸˜
ao de IVs vari´
aveis e do modo XTS.
Ap
´
os decifrar as FCs, constatou-se que duas bibliotecas compartilhadas n
˜
ao
possu
´
ıam assinaturas digitais. Dessa forma, eram vulner
´
aveis
`
a inje
c¸˜
ao de c
´
odigo ar-
bitr
´
ario, o que forneceu capacidades desproporcionais a um atacante. Assim, tamb
´
em h
´
a
suporte
`
a Quest
˜
ao de Pesquisa
QP5
:
Foi poss´
ıvel executar c´
odigo arbitr´
ario na urna
eletrˆ
onica
. Como apresentado anteriormente, foram v
´
arias as demonstra
c¸ ˜
oes de que os
ataques obtinham total controle sobre o software da urna eletr
ˆ
onica. As duas bibliotecas
compartilhadas n
˜
ao tiveram suas assinaturas separadas calculadas devido
`
a lista de arquivos
para verifica
c¸˜
ao n
˜
ao ser gerada por um processo automatizado. Em seu relat
´
orio, a equipe
de desenvolvimento do TSE afirma que, al
´
em das assinaturas separadas, as bibliotecas
continham assinaturas RSA internas para confer
ˆ
encia pelo kernel. Apesar disso, um erro
no c
´
odigo de verifica
c¸˜
ao (e em seu teste unit
´
ario), preveniram que a manipula
c¸˜
ao das
bibliotecas fosse detectada [TSE 2018].
O relat
´
orio dos TPS 2012 j
´
a havia defendido a tese de que o RDV n
˜
ao serve
a qualquer prop
´
osito de seguran
c¸
a e apenas fragiliza o sigilo do voto. Qualquer ata-
que bem sucedido ao software de vota
c¸˜
ao pode tamb
´
em comprometer a integridade
do RDV [
Aranha et al. 2014
]. A preven
c¸˜
ao de ataques ao RDV em si depende da
implementa
c¸˜
ao de um gerador de n
´
umeros aleat
´
orios seguro. Apesar de melhorias significa-
tivas terem sido implementadas em rela
c¸˜
ao ao gerador observado em 2012, as modifica
c¸ ˜
oes
podem n
˜
ao ser suficientes. O gerador
xorshift
e o algoritmo Sapparot-2 n
˜
ao s
˜
ao ade-
quados para aplicac¸ ˜
oes criptogr´
aficas, fato explicitado pelos seus pr´
oprios autores.
Contramedidas.
A equipe t
´
ecnica do TSE publicou recentemente um relat
´
orio
detalhando as contramedidas implementadas em resposta
`
as vulnerabilidades encontradas
pelos investigadores [
TSE 2018
], das quais vale destacar o armazenamento de chaves
criptogr´
aficas e fortalecimento dos mecanismos de verificac¸˜
ao de integridade.
A equipe do TSE afirmou que as chaves de cifra
c¸˜
ao n
˜
ao ser
˜
ao mais definidas no
c
´
odigo-fonte nas pr
´
oximas vers
˜
oes do software. Essas chaves ser
˜
ao calculadas em tempo
de execu
c¸˜
ao com ajuda da BIOS, aumentando a complexidade da ofusca
c¸˜
ao [
TSE 2018
].
Essa decis
˜
ao de implementa
c¸˜
ao foi justificada pelo fato de nem todas as urnas terem o
dispositivo MSD dispon
´
ıvel, o que limita a possibilidade do seu uso para armazenamento
das chaves. Devido
`
a restri
c¸˜
ao de que qualquer m
´
aquina deve ser capaz de substituir
qualquer outra no dia da elei
c¸˜
ao, o TSE considera um risco a exist
ˆ
encia de duas vers
˜
oes
distintas do software em opera
c¸˜
ao. Isso sugere que a seguran
c¸
a do sistema
´
e ditada pelo
modelo mais antigo em operac¸˜
ao, neste caso a urna de 2007 sem a presenc¸a do MSD.
Recomendac¸ ˜
oes.
As chaves de cifra
c¸˜
ao utilizadas na FC (bem como outras chaves
criptogr
´
aficas) deveriam ser segregadas
`
a menor unidade poss
´
ıvel (se
c¸˜
ao eleitoral, local
de vota
c¸˜
ao ou cidade), para reduzir o impacto em caso de vazamento. No m
´
edio prazo,
recomenda-se projetar uma arquitetura de distribui
c¸˜
ao de chaves para mover todas as
chaves criptogr´
aficas para dentro do per´
ımetro de seguranc¸a do MSD.
Os procedimentos de verifica
c¸˜
ao de integridade podem ser aprimorados pela ado
c¸˜
ao
de boas pr
´
aticas, ainda que o recurso seja de efic
´
acia intrinsecamente limitada, por exemplo
com a automatiza
c¸˜
ao de processos cr
´
ıticos e implementa
c¸˜
ao de testes, inclusive para os
casos negativos (exercitando a falha dos mecanismos de prote
c¸˜
ao). A lista de arquivos que
devem ser assinados n
˜
ao deveria ser gerada manualmente e a verifica
c¸˜
ao de assinaturas
deve ser testada em cen´
arios diferentes do ideal (chave e mensagens corretas).
Para incremento no sigilo do voto, recomenda-se: (i) remover do RDV campos n
˜
ao
utilizados por eleitores faltantes para prevenir uma busca exaustiva nas sementes poss
´
ıveis;
(ii) adotar algoritmos mais fortes e padronizados ou ler do
/dev/urandom
diretamente,
caso a entropia coletada tenha qualidade suficiente. A longo prazo, recomenda-se a
eliminac¸˜
ao do arquivo RDV, com alterac¸ ˜
ao na lei que obriga sua existˆ
encia.
Alegac¸ ˜
oes oficiais invalidadas
. N
˜
ao h
´
a documento formalizando o modelo ad-
versarial ou propriedades de seguran
c¸
a consideradas pelo TSE durante o projeto e desen-
volvimento do sistema eletr
ˆ
onico de vota
c¸˜
ao. Isso complica an
´
alises de seguran
c¸
a, dado
que o advers
´
ario torna-se um alvo m
´
ovel, mudando convenientemente dependendo do
ataque. Felizmente, o TSE publicou um documento com respostas a perguntas frequentes
que defende alguns dos mecanismos de seguran
c¸
a e estabelece algumas propriedades
esperadas [TSE 2014]. Os resultados aqui descritos contradizem v ´
arias dessas alegac¸ ˜
oes:
•
Na p
´
agina 10, “N
˜
ao
´
e poss
´
ıvel executar aplicativos n
˜
ao autorizados na urna
eletr
ˆ
onica. Da mesma forma, tamb
´
em n
˜
ao
´
e poss
´
ıvel modificar nenhum aplica-
tivo da urna.” Os ataques foram capazes de incluir e modificar duas bibliotecas
compartilhadas na FC, cuja execuc¸˜
ao posterior violou a integridade do software.
•
Entre as p
´
aginas 12 e 14, “A urna eletr
ˆ
onica n
˜
ao
´
e vulner
´
avel a ataques externos.
(...) Isso
´
e garantido pelos diversos mecanismos de seguran
c¸
a, baseados em
assinatura digital e criptografia, que criam uma cadeia de confian
c¸
a entre hardware
esoftware e impedem qualquer viola
c¸ ˜
ao da urna eletr
ˆ
onica.” M
´
aquinas DRE
s
˜
ao sabidamente inseguras contra ataques internos com controle sobre o software,
mas foi demonstrado como um atacante externo com acesso
`
a FC tamb
´
em pode
manipular o software antes da elei
c¸˜
ao. Como cada FC instala at
´
e 50 urnas, h
´
a um
fator de amplifica
c¸˜
ao que reduz obst
´
aculos e o custo de um ataque em larga escala.
•
Na p
´
agina 22, “O arquivo de log
´
e mais um mecanismo de transpar
ˆ
encia e auditoria
disponibilizado pela Justi
c¸
a Eleitoral.” O arquivo de LOG est
´
a sujeito
`
a adultera
c¸˜
ao
caso o software esteja sob controle do atacante, logo o LOG n
˜
ao serve como
ferramenta de auditoria do software de votac¸˜
ao.
•
Na p
´
agina 33, “(...) afirmar que a partir da posse da chave do sistema de arquivos
´
e poss
´
ıvel gerar m
´
ıdias ’de diferente teor’
´
e incorreto. (...) Na verdade, todos os
arquivos que requerem integridade e autenticidade s
˜
ao assinados digitalmente.”
Como demonstrado, de posse da chave de cifra
c¸˜
ao da m
´
ıdia, foi poss
´
ıvel alterar
duas bibliotecas compartilhadas importadas por outros programas. Esses arquivos
modificados foram reinseridos na FC gerando um novo cart
˜
ao de instala
c¸˜
ao v
´
alido.
O TSE alega que a cifra
c¸˜
ao do sistema de arquivos
´
e uma das v
´
arias barreiras
de seguran
c¸
a contra ataques externos. Esta seria, portanto, projetada para servir como
primeiro obst
´
aculo contra advers
´
arios mal informados, ao passo que outros mecanismos
criptogr
´
aficos proveriam defesas contra advers
´
arios mais sofisticados. Embora a primeira
alega
c¸˜
ao seja tecnicamente v
´
alida, uma vez que a cifra
c¸˜
ao do sistema de arquivos n
˜
ao
passa de uma ofusca
c¸˜
ao, observou-se que capturar as chaves de cifra
c¸˜
ao forneceu poder
desproporcional ao advers
´
ario, que se torna capaz de escolher ou revelar outras chaves
mais importantes. Isso aconteceu porque a decifra
c¸˜
ao permitiu inspecionar o conte
´
udo
da FC e detectar vulnerabilidades graves nos mecanismos de verifica
c¸˜
ao de integridade,
consequentemente violando as principais propriedades de seguranc¸a do sistema.
7. Conclus˜
oes
Os TPS oferecem uma oportunidade importante para se colaborar com o incremento de
seguran
c¸
a do sistema eletr
ˆ
onico de vota
c¸˜
ao, mas algumas altera
c¸ ˜
oes poderiam torn
´
a-los
mais efetivos: minimizar a burocracia e interven
c¸ ˜
oes durante os testes; aumentar agilidade
dos procedimentos internos de autoriza
c¸˜
ao; ampliar o escopo para incluir identifica
c¸˜
ao
biom
´
etrica e partes da infraestrutura de transmiss
˜
ao e totaliza
c¸˜
ao; ampliar a dura
c¸˜
ao do
evento; tornar o c
´
odigo-fonte amplamente dispon
´
ıvel. Em particular, vale observar que
o tempo consumido para montar os ataques aqui descritos n
˜
ao
´
e representativo para uma
tentativa real de fraude, em que as condic¸˜
oes de trabalho s˜
ao muito diferentes.
Osoftware de vota
c¸˜
ao da urna eletr
ˆ
onica brasileira ainda n
˜
ao satisfaz requisitos
m
´
ınimos de seguran
c¸
a e transpar
ˆ
encia e est
´
a muito aqu
´
em da maturidade esperada de
um sistema cr
´
ıtico em produ
c¸˜
ao h
´
a mais de 20 anos. Recomenda-se ao TSE revisar
cuidadosamente suas pr
´
aticas de desenvolvimento e considerar novamente a ado
c¸˜
ao do
voto impresso para fornecer garantias fortes do funcionamento correto do sistema no dia
da elei
c¸ ˜
oes, acompanhando a experi
ˆ
encia de outros pa
´
ıses. Espera-se que os resultados
aqui descritos contribuam com o debate no pa
´
ıs a respeito da introdu
c¸˜
ao de um registro
f
´
ısico de votos individuais como uma forma de aprimorar seguran
c¸
a e transpar
ˆ
encia do
sistema de votac¸˜
ao.
Referˆ
encias
Amato, F., Oro, I. A. B., Chaparro, E., Lerner, S. D., Ortega, A., Rizzo, J., Russ, F.,
Smaldone, J., and Waisman, N. (2015). Vot.Ar: una mala elecci
´
on.
https://ivan.
barreraoro.com.ar/vot-ar-una-mala-eleccion/.
Aranha, D. F., Karam, M. M., Miranda, A., and Scarel, F. (2014). Software vulnerabilities
in the Brazilian voting machine, pages 149–175. IGI Global.
Aranha, D. F., Ribeiro, H., and Paraense, A. L. O. (2016). Crowdsourced integrity
verification of election results - An experience from Brazilian elections. Annales des
T´
el´
ecommunications, 71(7-8):287–297.
Basili, V. R. (1992). Software modeling and measurement: The goal/question/metric
paradigm. Technical report, University of Maryland at College Park, MD, USA.
Calandrino, J. A., Feldman, A. J., J. A. Halderman, D. W., and H. Yu, W. P. Z. (2007).
Source Code Review of the Diebold Voting System. Available at
https://jhalderm.
com/pub/papers/diebold-ttbr07.pdf.
Gonggrijp, R. and Hengeveld, W. (2007). Studying the Nedap/Groenendaal ES3B voting
computer: A computer security perspective. In EVT. USENIX Association.
Levin, I. O. (2005). Sapparot-2: Fast Pseudo-Random Number Generator.
http://www.
literatecode.com/sapparot2.
Marsaglia, G. (2003). Xorshift RNGs. Journal of Statistical Software, Articles, 8(14):1–6.
Rivest, R. L. (2008). On the notion of ‘software independence’ in voting systems. Philo-
sophical Transactions of the Royal Society of London A: Mathematical, Physical and
Engineering Sciences, 366(1881):3759–3767.
TSE (2009). Acompanhamento da execu
c¸˜
ao do Plano de Teste.
https:
//web.archive.org/web/20160107163923/http://www.tse.gov.br/
internet/eleicoes/arquivos/Teste_Sergio_Freitas.pdf.
TSE (2014). Sistema Eletr
ˆ
onico de Vota
c¸˜
ao. Perguntas Mais Frequen-
tes. 2
ª
Edi
c¸˜
ao.
http://www.justicaeleitoral.jus.br/arquivos/
tse-perguntas-mais-frequentes-sistema-eletronico-de-votacao.
TSE (2016). Teste P
´
ublico de Seguran
c¸
a do Sistema Eletr
ˆ
onico de Vota
c¸˜
ao:
Comp
ˆ
endio.
http://www.tse.jus.br/hotsites/catalogo-publicacoes/
pdf/teste-publico-de-seguranca-2016-compendio.pdf.
TSE (2018). Respostas
`
as vulnerabilidades e sugest
˜
oes de melhorias encontradas
no teste p
´
ublico de seguran
c¸
a 2017.
http://www.justicaeleitoral.jus.br/
arquivos/relatorio-tecnico-tps-2017-1527192798117.
van de Graaf, J. and Cust
´
odio, R. F. (2002). Tecnologia Eleitoral e a Urna Eletro-
nica – Relat
´
orio SBC 2002.
http://www.sbc.org.br/index.php?option=com_
jdownloads&Itemid=195&task=view.download&catid=77&cid=107.
Wolchok, S., Wustrow, E., Halderman, J. A., Prasad, H. K., Kankipati, A., Sakhamuri,
S. K., Yagati, V., and Gonggrijp, R. (2010). Security analysis of India’s electronic
voting machines. In ACM Conference on Computer and Communications Security,
pages 1–14. ACM.
