Universidade Nova de Lisboa Faculdade de Ciências e Tecnologia
Departamento de Informática
Dissertação de Mestrado em Engenharia Informática 2º Semestre, 2008/2009
Verificação de protocolos de e-voting
Aluno nº29721 Maria de Fátima Rodrigues Reis
Orientador
Prof. Doutora Carla Ferreira
Dissertação apresentada na Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa para obtenção do grau de Mestre em Engenharia Informática.
2 Nº do aluno: 29721
Nome: Maria de Fátima Rodrigues Reis
Título da dissertação: Verificação de protocolos de e-voting
Palavras-Chave:
Verificação por modelos Votação electrónica Sistemas distribuídos Segurança
3
Resumo
Os sistemas de votação electrónica, designados também por e-voting, são sistemas
informáticos que permitem aos eleitores não só registarem-se para poder exercer o seu direito de voto, como também expressarem-no de forma electrónica e com o consequente apuramento por parte das autoridades competentes do resultado das eleições. Dada a sua relevância a todos os níveis da sociedade é crucial que todos os elementos envolvidos num sistema de votação electrónica tenham confiança no sistema utilizado. No final devem ter a certeza que o sistema proporcionou um bom escrutínio e que reflecte exactamente o que era esperado dele. Para tal, é necessário que se adoptem as medidas que permitem assegurar a segurança a diversos níveis, nomeadamente: privacidade, democracia, possibilidade de verificação e precisão, entre outras.
Através da verificação formal de protocolos e utilizando ferramentas de verificação de modelos, pode-se caminhar para atingir a confiança necessária neste tipo de sistemas. Estas ferramentas permitem a modelação e validação de propriedades de um protocolo, avaliando a sua correcção e identificando problemas na sua especificação.
Pretende-se contribuir para que o sistema de votação electrónica passe a ser uma realidade e assim facilitando o papel de todos os intervenientes nos processos eleitorais. Os sistemas de votação electrónica, poderão ajudar no combate à abstenção, proporcionar melhor acesso a deficientes motores e melhorar privacidade para invisuais.
4
Abstract
Electronic voting systems, also called e-voting systems, are electronic systems that enable voters to register and cast their vote. At the end of the election tallying authoritites are able to count and publish election results. E-voting systems are highly relevant to the society in general. For this reason, it is crucial that all intervenients trust the e-voting system. They must be sure that the system provided a reliable poll, which reflects what was expected from it. In order to achieve those features we will need to adopt the necessary measures to enable security at all levels, namely: privacy, democracy, verification, and precision, among others.
By using formal protocol verification through model checking tools, it is possible to contribute to reach the aimed trust on e-voting systems. These tools enable protocol modeling and properties verification by evaluating its accuracy and help identifying problems in its specification.
We aim to contribute to the electronic voting system becoming a reality and thus facilitating the role of all players in the electoral process. E-voting systems will help in abstention reduction and to improve voting access to physically and visually impaired people.
5
Prefácio
O presente documento reúne o trabalho de investigação, desenvolvimento, apresentação e conclusões referente à “Dissertação de Mestrado em Engenharia Informática” da Faculdade de Ciências e Tecnologias da Universidade Nova de Lisboa.
Os meus agradecimentos à professora orientadora Carla Ferreira, pela sua disponibilidade, paciência, acessibilidade e principalmente contributos ao nível de motivação e condução no trabalho realizado.
Obrigada à minha amiga, Eunice Silva e aos meus colegas de trabalho Fiona Joosab e João Azinhais, pelas valiosas contribuições nas revisões do texto.
Um reconhecimento muito especial para todos os familiares e amigos que durante o tempo de trabalho nesta dissertação me apoiaram e deram força para que conseguisse atingir este objectivo.
Dedico este trabalho aos meus afilhados, Carla Reis e Ricardo Reis, para que sejam sempre persistentes, superem as dificuldades e não desistam.
6
Índice de Matérias
1 Introdução... 11
2 Protocolos votação electrónica e suas características ... 15
2.1 Intervenientes do processo de votação ... 15
2.2 Fases do processo de votação ... 16
2.3 Propriedades de um sistema de votação... 18
2.4 REVS – Robust Electronic Voting System ... 20
3 Verificação ... 27
3.1 SPIN ... 35
3.2 UPPAAL ... 41
4 Verificação de protocolos de votação electrónica com SPIN ... 47
4.1 Modelação ... 49
4.1.1 Opções tomadas ... 49
4.1.2 Representação do protocolo e principais estruturas utilizadas ... 50
4.1.3 Descrição dos Processos ... 53
4.2 Simulação ... 57
4.3 Verificação de propriedades genéricas ... 63
4.4 Verificação de propriedades de votação electrónica ... 65
4.4.1 Privacidade ... 68
4.4.2 Democracia ... 68
4.4.3 Precisão ... 69
4.4.4 Fiabilidade ... 69
4.4.5 REVS – Assinaturas para o voto ser válido ... 69
4.4.6 REVS – Eleitor termina processo de votação ... 69
7
4.4.8 REVS - Ordem dos votos ... 70
4.4.9 Apenas verificável em SPIN – Linear Temporal Logic ... 71
5 Verificação de protocolos de votação electrónica com UPPAAL ... 72
5.1 Modelação ... 76
5.1.1 Opções tomadas ... 76
5.1.2 Representação do protocolo e principais estruturas utilizadas ... 77
5.1.3 Descrição dos Processos ... 81
5.2 Simulação ... 86
5.3 Verificação de propriedades genéricas ... 87
5.4 Verificação de propriedades de sistemas de votação electrónica ... 88
5.4.1 Privacidade ... 88
5.4.2 Democracia ... 89
5.4.3 Precisão ... 89
5.4.4 Fiabilidade ... 89
5.4.5 REVS – Assinaturas para o voto ser válido ... 89
5.4.6 REVS – Eleitor termina processo de votação ... 90
5.4.7 REVS – Eleitor pode não terminar processo de votação ... 90
5.4.8 REVS e UPPAAL – Ordem dos votos com tempo ... 90
5.4.9 REVS – Lógica Temporal Ramificada ... 91
6 Comparação de SPIN e UPPAAL na verificação de protocolos de votação electrónica .. 93
7 Intrusos ... 96
8 Conclusões e trabalho futuro ... 99
Referências ... 101
A. Modelo SPIN ... 104
A.1. Propriedades SPIN ... 107
B. Modelo UPPAAL - XML ... 118
B.1. Propriedades UPPAAL ... 124
C. Modelo SPIN – Intruso ... 125
8
Índice de Figuras
Figura 2.1 Processo Genérico de votação electrónica [6] ... 17
Figura 2.2 Arquitectura REVS ... 23
Figura 3.1 A verificação de propriedades em SPIN ... 36
Figura 3.2 Invariância ... 39
Figura 3.3 Resposta ... 39
Figura 3.4 Precedência ... 40
Figura 3.5 Objectivo ... 40
Figura 3.4 Verificação de propriedades em UPPAAL ... 42
Figura 3.5 E<> p – Existe eventualmente p ... 43
Figura 3.6 E[] p – p existe globalmente... 43
Figura 3.7 A[] p ... 44
Figura 3.8 A<> p – “Sempre eventualmente p” ... 44
Figura 3.9 q->p – “q leva sempre a p” ... 45
Figura 4.1 Comunicação entre os tipos de objectos em SPIN ... 48
Figura 4.2 Validação de sintaxe em SPIN ... 58
Figura 4.3 Validação de redundâncias no modelo ... 58
Figura 4.4 Janela de simulação do SPIN ... 59
Figura 4.5 Resultado de uma simulação ... 59
Figura 4.6 Valores das variáveis e canais numa simulação ... 60
Figura 4.7 Visualização gráfica da simulação aleatória 1 ... 61
Figura 4.8 Visualização gráfica da simulação aleatória 2 ... 62
Figura 4.9 Opções de verificação ... 63
Figura 4.10 Resultado de uma verificação ... 64
Figura 4.11 Output de uma verificação de propriedade ... 66
Figura 5.1 Subsistemas do UPPAAL ... 72
Figura 5.2 Configuração de um arco na modelação de um processo ... 73
9
Figura 5.4 Processo ModuloVoto ... 82
Figura 5.5 Processo Distribuidor ... 83
Figura 5.6 Processo Administrador ... 84
Figura 5.7 Processo Anonimizador ... 84
Figura 5.8 Processo Totalizador ... 85
Figura 5.9 Processo Temporizador ... 86
Figura 5.10 Janela de simulação do SPIN ... 86
10
Índice de Quadros
Tabela 3-1 Resumo de trabalhos em verificação ... 29
Tabela 4-2 SPIN - Processos do modelo e suas instanciações de execução ... 50
Tabela 5-2 UPPAAL - Processos do modelo e suas instanciações de execução ... 77
Tabela 6-1 Comparação das ferramentas SPIN e UPPAAL... 94
11
1
Introdução
A comunidade científica tem desenvolvido um vasto trabalho na área de segurança de protocolos de votação electrónica no sentido de mostrar de que forma estes podem ser utilizados. Deste modo contribui para que os mesmos possam ser usados com todas as garantias dos sistemas de votação não electrónicos, ou seja, convencionais.
Quando é utilizado voto em papel, o eleitor pode facilmente perceber e ficar confortável com o facto de o seu voto ser correctamente efectuado. Ao chegar à mesa de eleição, o eleitor é identificado, recebe um boletim de voto para efectuar a sua escolha e deposita o mesmo já preenchido com o resultado da sua escolha na urna, na presença das autoridades eleitorais que fiscalizam o acto. O eleitor confirma que já votou através de assinatura para que não possa votar novamente. No final do período de votação as urnas são abertas na presença das autoridades competentes e os votos são contados. Estes já não têm qualquer ligação ao eleitor que os efectuou. A contagem é feita na presença de entidades reconhecidas pela comissão eleitoral que assegura a idoneidade do processo. Após essa fase todos os resultados das contagens são combinados e os resultados da eleição oficialmente apresentados. O eleitor tem a certeza que votou em privacidade e que ninguém irá poder votar utilizando a sua identidade ou associar um dos votos nas urnas ao seu próprio voto. Para além do processo descrito, existem sempre outras organizações responsáveis por monitorizar e avaliar se o acto eleitoral decorreu de acordo com as regras.
12
reflicta exactamente a realidade em termos, por exemplo, de número de eleitores, número de votos, integridade dos mesmos e garantia de privacidade.
Neste contexto, a garantia de propriedades como democracia e privacidade são essenciais à utilização de um sistema de votação electrónica. Ataques a protocolos de segurança são difíceis de prevenir tendo em conta o ambiente distribuído onde estes sistemas operam e a grande variedade de ataques a que estes protocolos estão sujeitos. A análise e verificação formal disponibilizam uma abordagem rigorosa que complementa a execução de testes. Esta não é suficiente por si só para determinar que um sistema é fiável, mas contribui para tal e é portanto uma vertente que deve ser explorada.
Neste âmbito, foi efectuado o levantamento detalhado de um dos protocolos existentes que implementa um processo de votação electrónica, o REVS (Robust Electronic Voting System) [1]. O REVS foi escolhido por ser um protocolo desenhado para ser utilizado através da Internet, indo assim de encontro à melhoria de acessibilidade aos cidadãos para a realização dos seus deveres cívicos. Por outro lado, o REVS é baseado noutros protocolos já existentes, como por exemplo o protocolo com múltiplos administradores desenvolvido por DuRette’s [2]. O protocolo com múltiplos administradores era por sua vez uma melhoria proposta para o sistema EVOX por Herschberg [3]. O protocolo REVS melhora assim algumas vertentes, como por exemplo a disponibilidade e tolerância a falhas, proporcionando assim uma solução mais fiável.
Identificaram-se ainda as propriedades implementadas pelo REVS e algumas das formas de verificação das mesmas, nomeadamente através das ferramentas para modelação e verificação de protocolos SPIN (Simple Promela Interpreter) [4] e UPPAAL (UPPSALA e AALBORG) [5]. Foi ainda efectuado um estudo comparativo das propriedades verificadas nas duas ferramentas estudadas.
A verificação formal é uma técnica complementar aos testes e à simulação que permite aferir a correcção de um sistema ou protocolo, ou seja, garantir que ele está conforme as especificações de desenho e propriedades definidas. Através da verificação poder-se-á garantir, por exemplo, que de acordo com a especificação, um voto inválido não será contado pelo sistema de escrutínio [6].
13
verificação, permitindo validar se os requisitos definidos na especificação são cumpridos.
A verificação não é a única forma de garantir a fiabilidade de um sistema. É apenas uma das formas de contribuir para esse objectivo. São alvos de verificação, por exemplo, que o sistema de voto:
É consistente;
Está de acordo com as normas;
Utiliza técnicas de confiança e boas práticas; Escolhe as funções correctas e da forma correcta;
Está de acordo com os requisitos de correcção e de completude, entre outros, para todos os passos da votação.
O presente trabalho foca-se essencialmente neste último ponto utilizando para tal as ferramentas de verificação estudadas, nomeadamente o SPIN [4] e o UPPAL [5].
Ambas permitem modelar os requisitos de um protocolo através de linguagens e estruturas próprias que permitem uma abstracção em relação aos detalhes de uma especificação. Permitem ainda efectuar a verificação de sintaxe dos sistemas descritos no modelo, a simulação da sua execução e a verificação de propriedades.
Efectuou-se um estudo generalizado do processo de votação convencional e electrónico e utilizou-se o protocolo REVS, que implementa um sistema de votação electrónica, como olução base para estudo.
O presente documento apresenta nas secções seguintes uma descrição mais generalizada dos protocolos de votação electrónica e suas características, nomeadamente:
Intervenientes
Fases do processo de votação
Propriedades de um sistema de votação
14
15
2
Protocolos votação electrónica e suas características
Votação electrónica refere-se, de uma forma generalizada, à possibilidade dos indivíduos votarem electronicamente numa eleição.
O processo de votação convencional baseado em papel e nas entidades reconhecidas e autorizadas para executar, monitorizar e garantir uma votação é aceite pela comunidade. Um protocolo de votação electrónica deve assegurar que todas as fases do processo de votação são atingidas e concluídas devidamente, garantindo assim a fiabilidade do processo de votação. Muita da desconfiança em relação a estes sistemas assenta sobretudo na não garantia de fiabilidade no processo de votação.
De seguida apresenta-se os intervenientes e fases de um sistema de votação electrónica que implementam os processos de uma votação convencional [6].
2.1
Intervenientes do processo de votação
Eleitor
Tem o direito de voto e vota na eleição.
Entidades de registo
16 Entidades de cálculo
Reúnem os votos efectuados pelos eleitores e calculam o resultado das eleições.
2.2
Fases do processo de votação
Existem seis fases que indicam como é que cada uma destas entidades interage entre si. Estas fases descrevem de uma forma genérica o processo eleitoral [1, 6].
Pré-registo/Registo
Esta fase precede o acto eleitoral. Os eleitores que querem votar inscrevem-se perante as entidades de registo para que a lista de eleitores fique disponível antes do acto eleitoral. Os boletins de voto são preparados para que estejam finalizados no momento da eleição. Nem todos os protocolos de votação electrónica implementam esta fase.
Validação de autenticação e autorização
No dia da eleição, os eleitores registados requerem um boletim de voto e autorização para votar às entidades de registo. As entidades de registo verificam as credenciais de acesso do eleitor e caso este esteja registado, é aceite para o acto eleitoral.
Votar
O eleitor exerce o seu direito de voto. O eleitor apenas pode votar uma vez por eleição.
Verificação
É verificada a validade dos votos para que apenas os votos válidos sejam contados na fase final de apuramento de contagem de votos.
Cálculo
17 Reclamações
Após o acto eleitoral, qualquer entidade pode reclamar eventuais más práticas que deverão ser averiguadas e validadas antes da publicação e homologação dos resultados finais da votação.
Nem todos os protocolos de votação electrónica observam as fases apresentadas. Por exemplo, o REVS não considera a fase de Reclamações apesar de disponibilizar uma forma de um eleitor saber se o seu voto foi ou não contado e dessa forma permitir que o eleitor faça uma reclamação e que a mesma seja verificada.
A imagem seguinte representa de uma forma genérica a interacção entre os intervenientes num processo de votação [6] proposto por Cetinkaya [7], Cranor [8] e Fujioka [26].
Figura 2.1 Processo Genérico de votação electrónica [6]
Em primeiro lugar e previamente à eleição, os eleitores registam-se perante as autoridades competentes.
De seguida, já no período definido para a eleição, cada eleitor contacta as autoridades perante as quais se registou, autentica-se e é-lhe dada autorização para votar. Após escolha da sua opção de voto, o eleitor submete o seu voto.
Após o término do período da eleição, as entidades de contagem apuram o resultado da votação e publicam os resultados.
Registo
Autorização e Autenticação
Votação
Contagem Eleitor
Autoridades de contagem
18
2.3
Propriedades de um sistema de votação
De seguida apresentam-se as propriedades básicas de segurança que um sistema de votação electrónica deverá assegurar propostas por Cranor e Cytron [8]. Cada propriedade foi dividida em vários requisitos, referidos por Cetinkaya [10], Cranor [8] e Fujioka [9], seguindo uma estrutura similar aos trabalhos [1, 6, 11].
Democracia
A democracia é caracterizada por dois requisitos:
Elegibilidade - Apenas os eleitores elegíveis votam no escrutínio.
Unicidade – Os eleitores elegíveis apenas podem votar uma única vez.
Privacidade
A privacidade pode ser caracterizada por três requisitos:
Anonimato - Não deve ser possível estabelecer uma ligação entre o eleitor e o seu voto,
quer pelas entidades eleitorais, como por quaisquer outras entidades. Esta propriedade deverá ser assegurada durante o processo eleitoral e por um período longo após as eleições de modo a garantir a não coercibilidade.
Não Coercibilidade - Assegura que ninguém pode ser forçado a votar de determinada
forma. Os eleitores devem votar de modo totalmente livre.
Ausência de Recibo de Voto - Nenhum eleitor pode provar que votou de determinada
forma. Esta característica evita possíveis burlas que envolvam compra ou venda de votos.
Verificação de voto
19 Precisão
A precisão pode ser caracterizada por dois requisitos:
Precisão - Um voto tem que reflectir a escolha do eleitor e não pode em ponto algum do
sistema ser adulterado. Se um voto for inválido, este não deverá ser incluído no escrutínio final. Qualquer ataque aos votos deverá ser identificado e invalidado. Se um voto for efectuado com sucesso pelo eleitor e for válido, este terá que ser obrigatoriamente contado no escrutínio final.
Unicidade - Apenas pode ser contada um voto por eleitor.
Apresentam-se de seguida ainda outras propriedades que deverão ser asseguradas para garantir a fiabilidade do sistema.
Justiça
Não deve ser possível consultar ou publicar contagens parciais no decorrer do processo eleitoral para assegurar que todos os candidatos estão em igualdade de circunstâncias.
Transparência
Deve ser disponibilizada informação sobre o processo eleitoral para que os eleitores estejam informados do acto eleitoral. A segurança e fiabilidade do sistema de votação electrónica não podem depender exclusivamente da privacidade da rede, visto esta não poder ser assegurada.
Robustez
Ninguém poderá influenciar qualquer parte do sistema de voto. A robustez deverá ser assegurada a diversos níveis, tais como:
Não permitir que as autoridades atribuam permissões de voto a quem não as tem;
Não permitir que indivíduos votem sob outra identidade;
20
Garantir que todos os eleitores têm acesso ao sistema durante o período do acto eleitoral;
O processo de voto deve poder ser interrompido e depois retomado pelo eleitor.
A resistência à fraude é normalmente medida como o número de elementos que são necessários para conspirar para introduzir outros votos ou evitar que eleitores votem. Nem todas as características apontadas são verificadas por todos os protocolos de votação electrónica.
Algumas das propriedades apresentadas são contraditórias e esse é um dos problemas dos sistemas de votação electrónica. Por exemplo, o eleitor deverá poder no final de uma votação verificar que o seu voto foi contado. Essa possibilidade poderá também permitir-lhe provar em quem votou e como tal poderá ser uma porta aberta para a coercibilidade, precisamente por poder associar o eleitor ao voto final.
De seguida apresenta-se o Protocolo REVS e identificam-se as suas propriedades.
2.4
REVS
–
Robust Electronic Voting System
Este sistema de voto electrónico foi concebido para funcionar em ambientes distribuídos e não tolerantes a falhas, como por exemplo a Internet.
O sistema REVS foi desenhado para ser robusto e assegura muitas das características dos sistemas de voto electrónico referidas no capítulo anterior, mesmo quando ocorrem falhas nas máquinas envolvidas ou nas comunicações.
21
Administradores para poder obter todas as assinaturas necessárias para um voto ser válido.
O sistema de voto electrónico REVS [6, 12] é baseado em blind signature 1 [13],
permitindo um bom comportamento num ambiente distribuído, como por exemplo a Internet. É baseado no trabalho de DuRette’s [2], que melhorou o sistema EVOX de Herschberg [3]. DuRette concebeu uma versão melhorada do EVOX a fim de eliminar entidades que pudessem sozinhas corromper a eleição, como, por exemplo o Administrador. Além disso através da arquitectura de múltiplos servidores para as mesmas funções, o REVS não é sensível a falhas de comunicação entre estes. Melhorou também alguns pontos de autenticação de utilizadores.
Fujioka, Okamoto e Otha propuseram um protocolo de blind signature conhecido como
FOO [9], que é referência em protocolos deste tipo. Por sua vez, Cranor e Cytron [8] com o Sensus e Herschberg com o EVOX, propuseram os seus protocolos de votação electrónica baseados no FOO. No entanto, nenhum dos dois protocolos controlam o poder de um Administrador. Em 1999, DuRette propôs o protocolo EVOX Managed Administrator. Este é uma evolução do EVOX, reduzindo o poder do Administrador e que o REVS também utiliza introduzindo tolerância a falhas e disponibilidade.
O REVS inclui os seguintes tipos de servidores e a comunicação entre os mesmos é toda efectuada utilizando sessões seguras via SSL (Secure Socket Layer) sendo portanto conhecida a chave pública de todos os servidores que fazem parte do sistema.
Módulo de Voto
Éuma aplicação cliente que o eleitor utiliza para votar. Através dela o eleitor pode obter a eleição, o boletim de voto para a mesma e validar ou submeter o seu voto. Esta aplicação é disponibilizada pelo Comissário Eleitoral e assinada pelo mesmo.
Comissário Eleitoral
O supervisor da eleição recebe reclamações de qualquer eleitor ou servidor eleitoral. Poderá promover investigações se houver suspeitas de fraude do acto eleitoral.
1
22
É também responsável por preparar a eleição, gerar e manter as chaves privadas da eleição, responder a questões e definir a configuração operacional da eleição. Esta é constituída, por exemplo, pelos endereços e chaves públicas dos servidores do tipo Administrador, número de assinaturas requeridas para um voto ser válido, etc.
Distribuidor de Votos
Responsável pela distribuição dos elementos da eleição. Toda a informação disseminada pelo distribuidor de votos deve ser assinada pelo Comissário Eleitoral em quem todos os eleitores confiam. Este módulo é bastante exigente em termos de troca de informação e poderá ser replicado em vários servidores para garantir tempos de resposta adequados durante o acto eleitoral.
Administrador
Tem a responsabilidade de validar o boletim de voto de um eleitor. Para ser válido e contado na contagem final, o voto tem que estar assinado por um conjunto de Administradores distinto e superior a metade do número total de Administradores. Deste modo um eleitor não pode ter dois votos válidos. Um eleitor utiliza um conjunto Utilizador/Palavra-Chave diferente para cada Administrador e contacta o servidor. O voto que é assinado pelo Administrador está ocultado através de “blind signature” pelo que o Administrador não pode ver o voto do Eleitor, sendo assegurada a privacidade.
Anonimizador
23
Totalizador
Verifica a validade dos votos recebidos através da confirmação da presença de todas as assinaturas necessárias, retira duplicações caso existam e conta os votos válidos. As duplicações podem ocorrer porque o próprio protocolo não permite a confirmação de recepção do voto, permite que um mesmo eleitor submeta diversas vezes o mesmo voto para anonimizadores diferentes ou até para o mesmo. Os totalizadores apenas podem analisar os votos no final do acto eleitoral, após o Comissário eleitoral publicar a chave privada da eleição.
Os eleitores enviam os seus votos finais para os contadores através dos anonimizadores, encriptados com a chave pública da eleição, não permitindo que os anonimizadores e totalizadores tenham acesso aos votos durante a votação. Só no final da eleição e quando a chave privada é publicada conseguem ter acesso aos mesmos.
O REVS permite vários anonimizadores e vários contadores, resultando uma arquitectura com no single point of failure2.
Como os eleitores podem enviar os votos através de vários anonimizadores, os totalizadores terão que eliminar os votos duplicados antes de efectuar a contagem final.
Figura 2.2 Arquitectura REVS
Este protocolo pressupõe que os eleitores já se encontram registados para o acto eleitoral, função que é assegurada pelo Comissário Eleitoral. Segue as etapas apresentadas a seguir, as três primeiras referentes ao ponto de vista do eleitor e a última relativa ao processo de votação em geral [6, 12].
2 no single point of failure significa que o sistema é tolerante a falhas e que se uma parte do sistema falha, há outra que assegura a mesma função.
Distribuidores Administradores Anonimizadores Totalizadores
24 1. Distribuição de boletins de voto
a. O Módulo do Eleitor contacta um módulo Distribuidor de Voto para obter as eleições em que poderá participar.
b. O Distribuidor de Voto devolve a lista de eleições em que o eleitor pode participar.
c. De seguida, o Módulo do Eleitor contacta um módulo Distribuidor de Voto para obter uma eleição para participar.
d. O Distribuidor de Voto devolve o boletim de voto, a chave pública da eleição e outros elementos específicos da eleição, tais como identificação dos servidores de chaves e respectivas localizações.
As informações anteriores devem ser validadas e assinadas pelo Comissário Eleitoral. A própria aplicação cliente que o eleitor utiliza foi assinada pelo Comissário Eleitoral com a sua chave privada sendo a chave pública conhecida de todos os eleitores.
2. Assinatura do voto
Após o Eleitor expressar a sua intenção de voto, o Módulo de Voto confirma o voto com uma random bit string3 através de um bit commitment4. O voto é anonimizado com
um random blind factor5 e enviado para o Administrador, para assinatura. O Módulo de
voto guarda a selecção do voto, a random bit string e o random blind factor. A
mensagem é enviada do Módulo de Voto para um número de Administradores superior a metade do total de Administradores. A mensagem é autenticada com o código de Utilizador/Palavra-Chave para cada administrador de modo a garantir a autenticação do eleitor. Cada Administrador, ao receber um pedido autenticado de assinatura, verifica se já assinou algum pedido para o eleitor em questão. Se não assinou, assina o voto com a sua chave privada e guarda essa assinatura, Se já assinou, retorna ao eleitor a informação prévia já assinada, ou seja, o voto do eleitor assinado com a chave do Administrador.
Após recepção da assinatura, o Módulo de Voto remove o random blind factor e
verifica a sua correcção utilizando para tal a chave pública do Administrador.
3 R
andom bit string é um número aleatório utilizado para cifrar uma mensagem utilizando um algoritmo de cifração.
4 B
it commitment é um método que permite utilizar um valor mantendo-o invisível e inacessível para terceiros.
5 R
25
O processo é repetido até que seja atingido um número t de assinaturas de
Administradores. O número t deve sempre ser superior ou igual a N/2 onde N é o
número total de Administradores. Desta forma evita-se que um eleitor tenha mais do que um voto válido.
Os administradores recebem um voto que foi anonimizado pelo que não conseguem saber o conteúdo do mesmo, logo a privacidade é assegurada. Por outro lado se o eleitor repetir a operação, ele receberá a assinatura que já tinha sido devolvida na primeira vez que tinha requisitado a assinatura ao Administrador em questão.
3. Submissão do voto
O Módulo de Voto junta o voto encriptado com o bit commitment, as assinaturas
recebidas dos administradores e o próprio bit commitment que permitirá ter acesso ao
voto no final do escrutínio e encripta tudo com a chave pública da eleição. Depois envia tudo para o Totalizador, através do Anonimizador. O eleitor pode enviar o seu voto para vários Totalizadores e tantas vezes quantas ache necessário para que o seu voto seja contado. O Anonimizador não tem acesso ao pacote que contém o voto encriptado, o bit commitment e as assinaturas dos administradores, porque o pacote vai encriptado com a
chave pública da eleição. A chave privada da eleição que permitiria acesso a essa informação só será disponibilizada no final da eleição.
4. Cálculo final da votação
Após o término da eleição, os Totalizadores fazem a contagem de todos os pacotes submetidos na votação e publicam os resultados. A contagem dos votos é efectuada da seguinte forma:
Decifra cada pacote recebido com a chave pública da eleição;
Verifica que cada pacote tem as assinaturas requeridas pelos administradores; Remove os votos repetidos, ou seja os que têm o mesmo bit commitment;
Conta os votos que passaram os passos anteriores;
Se existirem vários Totalizadores, um deles é o master que vai juntar os valores
26
Os Totalizadores devem publicar os pacotes submetidos e recebidos, enquanto os Administradores publicam os boletins anonimizados. Deste modo poderão ser verificadas se as assinaturas dos votos são ou não válidas e se coincidem com as que foram efectuadas pelos respectivos administradores. Após isto, o eleitor com a informação de voto que submeteu pode verificar se o seu voto foi contado ou não utilizando para isso o bit commitment. Se verificar que o seu voto não consta na lista de
votos contados, pode reclamar junto das entidades eleitorais.
27
3
Verificação
A verificação formal é o acto de provar a correcção de um sistema, de acordo com uma especificação formal ou propriedade, utilizando métodos formais. Estes podem ser linguagens matemáticas, técnicas e ferramentas para especificar e verificar esses sistemas. Apesar de a utilização de métodos formais não garantir a correcção de um sistema, poderá permitir identificar incorrecções, ambiguidades e identificação incompleta de requisitos [15].
Ferramentas de verificação
Através das ferramentas de verificação pode concluir-se a consistência lógica das regras de um protocolo e aferir a correcção dos requisitos. Estas utilizam técnicas de verificação de modelos que exploram todos os possíveis estados do modelo. Deste modo poderá ser provado que o mesmo satisfaz as propriedades especificadas [16]. Como as sequências de eventos nem sempre são previsíveis em ambientes distribuídos, as ferramentas de verificação de protocolos permitem percorrer todos os estados de um modelo, de uma forma exaustiva e tirar conclusões a partir daí. No entanto, para que tal seja possível, é necessário que seja efectuada uma abstracção focada apenas no essencial que se pretende verificar. Caso isso não aconteça, facilmente o espaço disponível de memória poderá ser esgotado pela verificação do modelo, na geração de todos os estados possíveis do mesmo.
28
Verificação de protocolos
Foram encontrados no decorrer desta investigação alguns trabalhos realizados na área de verificação de protocolos de votação electrónica. Uns utilizando ferramentas de verificação baseadas em modelos tais como PaMoChSA em [18], onde são efectuadas as
verificações respectivamente da não possibilidade de introdução de votos não válidos baseados na abstenção. Outros trabalhos referem as propriedades dos protocolos de votação electrónica mas utilizam linguagens formais tais como event-B em [19] onde é
analisado o armazenamento dos votos num sistema de votos electrónico, applied pi-calculus em [20] onde são analisadas propriedades de privacidade destes sistemas, em
[21] onde são verificadas propriedades Justiça, Elegibilidade, e Privacidade e em [22] onde é verificada a Resistência à Coação e Ausência de Recibo de Voto. Estes trabalhos são importantes do ponto de vista da análise que é efectuada às propriedades estudadas e que complementa as características de cada uma delas e o que deverá ser esperado delas quando se verifica um modelo de um protocolo de votação electrónica.
Por outro lado existem alguns trabalhos que utilizam ferramentas de verificação baseadas em modelos com o SPIN, com o UPPAAL ou com ambos, sendo neste último caso efectuada uma comparação entre alguns aspectos de ambas as ferramentas. No entanto são trabalhos realizados noutras áreas que não protocolos de votação electrónica. Destacam-se, por exemplo, [23] onde é efectuada a simulação e verificação do protocolo “Collision Avoidance Protocol” com o SPIN e UPPAAL; [24] onde é utilizada apenas a ferramenta SPIN para verificação do protocolo “NetBill Protocol”; [25, 26] onde é utilizado o UPPAAL para verificação respectivamente do protocolo “Zeroconf” e “Distributed real-time network protocol RTnet”; [27] onde é verificado com UPPAAL o desenho de um sistema distribuído de elevadores. Além dos trabalhos aqui referidos nomeadamente para as ferramentas SPIN e UPPALL, existem muitos outros não referidos aqui.
Os trabalhos indicados revelaram-se importantes na medida em que exemplificam ou comparam as ferramentas escolhidas para verificação no decorrer deste trabalho.
29
Nome Tipo Área de
verificação
Propriedades verificadas Referência
PaMoChSA Ferramenta Votação
electrónica
Impossibilidade de inclusão de votos não válidos baseados em abstenção. [18] event-B Linguagem Formal Votação electrónica
Armazenamento de votos num sistema de votação electrónica
[19]
pi-calculus Linguagem
Formal
Votação electrónica
Privacidade [20]
pi-calculus Linguagem
Formal
Votação electrónica
Justiça, Elegibilidade, e
Privacidade
[21]
pi-calculus Linguagem
Formal
Votação electrónica
Resistência à Coação e Ausência de Recibo de Voto
[22]
SPIN e
UPPAAL
Ferramenta Outros
protocolos
Propriedades do protocolo
“Collision Avoidance Protocol”
[23]
SPIN Ferramenta Outros
protocolos
Propriedades do protocolo
“NetBill Protocol”
[24]
UPPAAL Ferramenta Outros
protocolos
Propriedades do protocolo
“Zeroconf”
[25]
UPPAAL Ferramenta Outros
protocolos
Propriedades do protocolo
“Distributed real-time network
protocol RTnet”
[26]
UPPAAL Ferramenta Outros
protocolos
Verificação de uma solução de um sistema de elevadores de veículos.
[27]
SPIN e
UPPAAL
Ferramenta Votação
electrónica
Propriedades genéricas de
modelos e de votação
electrónica, estas últimas referente ao protocolo REVS.
Documento corrente
Tabela 3-1 Resumo de trabalhos em verificação
SPIN E UPPAAL
30
que não é suportado pelo SPIN. O SPIN suporta apenas uma relação temporal entre os eventos e pode saber-se que um ocorre a seguir a outro. Por outro lado, o UPPAAL permite por exemplo saber que existe um tempo específico entre dois eventos.
Ambas as linguagens apresentam a possibilidade de desenhar modelos, efectuar simulações e verificações.
Em termos de utilização as ferramentas apresentam capacidades distintas. O SPIN é menos visual do que o UPPAAL. Com o SPIN cria-se uma especificação de um modelo em modo texto e só com a simulação ou verificação é possível ter uma representação gráfica. Por outro lado, com o UPPAAL pode definir-se o modelo do sistema de um modo gráfico.
A representação gráfica facilita a visualização das interacções entre os elementos do modelo e permite efectuar simulações do modelo acompanhando as transições também de modo gráfico.
Os modelos descrevem os comportamentos do sistema a analisar. Depois, para efectuar uma verificação, as propriedades são descritas de forma rigorosa usando lógica temporal. Em seguida, de forma automatizada é verificado para todos os estados do modelo se a propriedade a verificar é válida ou não. A verificação de uma propriedade tem três possíveis resultados: válida, não válida ou sem resultados.
31
Linear Temporal Logic e Computar Tree Logic
Na verificação de modelos é utilizada uma linguagem de formalização para especificar propriedades. O SPIN e o UPPAAL disponibilizam uma linguagem de especificação de propriedades. A verificação dessas propriedades em SPIN é especificada utilizando Linear Temporal Logic (LTL) e no UPPAAL utilizando Computar Tree Logic (CTL) [16].
A lógica temporal é baseada na lógica proposicional, mas alargada para modalidades temporais que permitem avaliar o comportamento de sistemas. Através da lógica temporal é possível definir, por exemplo, que alguma coisa acontecerá eventualmente no futuro. A natureza das lógicas temporais pode ser linear ou ramificada. A linear é a
LTL, utilizada no SPIN e a ramificada é a CTL que é utilizada no UPPAAL. O que as distingue, de uma forma mais generalizada, é que na linear em cada momento existe apenas um sucessor no tempo mas no CTL existe um ramo em que o tempo pode dividir-se em vários caminhos alternativos. A interpretação LTL é baseada em caminhos, ou seja sequências de estados que vão do presente até ao futuro. Por sua vez os caminhos podem ser ramificações que geram alternativas de caminhos. A CTL é baseada em ramos e apenas baseados em estados do futuro. Enquanto com o LTL se parte de um estado inicial e se verifica o que pretendemos que aconteça no futuro, ou seja, refere-se ao caminho, no CTL refere-se aos estados de um ramo algures no futuro. Com CTL podem-se verificar propriedades que não são possíveis de verificar com LTL e vice-versa.
Um exemplo de propriedades verificáveis em CTL e não verificáveis em LTL são as propriedades relativas a reinicialização, ou seja, para todos os estados existe pelo menos uma sequência que permite voltar ao estado inicial. Por outro lado em LTL pode-se ter
justiça (fairness) na verificação, ou seja saber se qualquer execução cíclica percorre, ou
não determinados estados infinitamente.
Existem vantagens e desvantagens nas utilizações destes tipos de lógicas. Mas tipicamente não permitem verificar o mesmo tipo de propriedades. Existem, no entanto, propriedades que podem ser verificadas por ambas as lógicas.
A definição de um protocolo inclui os seguintes elementos:
32
3. Vocabulário das mensagens utilizadas no protocolo. 4. Método de codificação das mensagens.
5. As regras para a troca de mensagens.
Neste trabalho, na modelação vamos focar-nos no aspecto descrito no ponto 5, abstraindo-nos dos restantes aspectos. Desta forma, os modelos SPIN e UPPAAL irão descrever parcialmente o protocolo REVS. Essa descrição parcial do protocolo define as interacções entre os vários processos do sistema de votação electrónica. As razões que se prendem com esta abstracção estão relacionadas com uma das limitações das ferramentas de verificação de modelos que é o facto de necessitarem de muita memória para representar os estados possíveis dos modelos.
O computador utilizado neste trabalho tem 3GB de memória física tendo que ser controlado o número de processos de modo a poder efectuar verificações sem problemas. No entanto as reduções não foram em termos dos processos principais mas sim em termos do número de instâncias de cada processo para conseguir obter resultados satisfatórios.
A verificação será depois efectuada sobre a modelação indicada.
Análise dos REVS
Nesta secção faremos uma análise do protocolo REVS tendo já como ponto de vista a implementação do modelo em SPIN e UPPAAL. Detalhar-se-á para cada uma das ferramentas o necessário que apenas seja referente a cada uma delas.
Analisando o protocolo REVS, consideram-se as trocas de mensagens tal como é a seguir indicado:
1 - Mensagens relativas à distribuição de boletins de eleição e de voto entre o Módulo de Voto e o Distribuidor de Voto
33
Nestas mensagens o eleitor é identificado perante o Distribuidor de Voto. É assumido que o eleitor já está previamente registado no sistema. O eleitor envia os seus pedidos para um dos Distribuidores de Voto disponíveis no sistema.
2 – Mensagens relativas ao pedido e envio de assinatura de voto entre o Módulo de Voto e os Administradores
PedidoAssinaturaVoto a cada Administrador EnvioAssinaturaVoto de cada Administrador
Para cada Administrador o eleitor contacta administradores diferentes até ter um número de assinaturas suficientes para poder submeter o seu voto e o mesmo ser válido em termos do número de assinaturas.
3 – Mensagens relativas à submissão de voto entre o Módulo de Voto e o Anonimizador EnvioVotoAnonimizador
EnvioVotoTotalizador
Apenas a mensagem enviada ao Anonimizador é enviada pelo eleitor. A mensagem enviada ao Totalizador é enviada pelo Anonimizador, após mascarar a mensagem recebida e com eventual atraso, para que a ordem da submissão do voto não seja a mesma da recepção no Anonimizador.
4 – Mensagens entre o Módulo de Voto e o Totalizador para a contagem e validação de voto
PedidoConsultaVoto EnvioConsultaVoto PedidoRe-submissãoVoto
34
onde ela ocorresse, significaria que o voto seria então contado posteriormente, à semelhança do que já acontece no modelo proposto.
As mensagens indicadas são trocadas entre os processos do sistema de votação. Consoante as mensagens enviadas ou recebidas por cada processo este vai alterando o seu conjunto de estados, sendo importante a ordem em que as mensagens são enviadas, recebidas ou tratadas por cada processo. No decorrer do trabalho, obtiveram-se frequentemente situações de deadlock nas simulações porque mensagens esperadas ou
não eram recebidas ou eram recebidas na ordem incorrecta fazendo com que os processos não prosseguissem a execução esperada.
Após o estudo prévio da ferramenta e do protocolo realizado na primeira fase deste trabalho, definiu-se nesta fase um modelo mais alargado em que o Módulo de Voto permite simular diversos eleitores, vários processos Distribuidor, Administrador, Anonimizador e Totalizador. Não foi modelada a fase inicial de pré-registo dos eleitores, assumindo-se que estes já se encontrariam registados. Não foi modelada a fase final em que o eleitor verifica que o seu voto foi contado no escrutínio final. De qualquer forma, existe informação no modelo que permitirá tirar algumas conclusões sobre este assunto.
De uma forma genérica teremos:
Cada eleitor pede o boletim de eleição a um dos Distribuidores;
Cada um dos Distribuidores envia o boletim de eleição para o eleitor que o solicitou;
Cada eleitor pede o boletim de voto ao Distribuidor que contactou inicialmente; Cada um dos distribuidores envia o boletim de voto para o eleitor que o
solicitou;
Cada eleitor pede as diversas assinaturas de voto aos Administradores disponíveis até obter um número necessário de assinaturas para tornar o seu voto válido quando recebido;
Cada Administrador envia a assinatura de voto a cada eleitor que a solicite; Uma vez recebidas todas as assinaturas necessárias, o eleitor submete o seu
35
O Anonimizador atrasa o voto recebido, oculta-o e reenvia-o para o Totalizador; Após o término da eleição é calculado o escrutínio.
3.1
SPIN
SPIN é uma ferramenta que suporta a verificação de sistemas distribuídos desenvolvida pelos laboratórios Bell, no grupo de métodos formais de verificação. Ou seja, permite verificar a correcção das interacções entre sistemas distribuídos, nomeadamente em ambientes complexos com uma multiplicidade de estados e transições possíveis. O SPIN está focado na comunicação entre os processos e nos problemas de sincronização entre processos de um sistema distribuído [4, 17].
Os sistemas distribuídos são normalmente de grandes dimensões e comportam uma grande diversidade de informação que muitas vezes não é necessária para a verificação formal. O que é essencial na verificação é a comunicação entre processos e o acesso concorrente aos recursos. Assim, a primeira etapa para a verificação formal de um protocolo é desenvolver uma especificação que retire o que é supérfluo. O modelo do sistema deve focar apenas os aspectos relevantes para a verificação.
Após a especificação do modelo, o SPIN permite verificar a sua consistência lógica, a
existência de livelocks6, deadlocks7, estados não esperados e pontos de controlo
incompletos que podem resultar em terminações abruptas que implicam que o protocolo não cumpra aquilo a que se propõe.
O SPIN suporta uma linguagem de alto nível para especificar sistemas, denominada PROMELA (PROTOCOL/PROCESS META LANGUAGE). PROMELA é uma linguagem não determinística. Possui primitivas para especificar comunicação assíncrona de mensagens com um número de parâmetros variável, utilizando um buffer.
Por outro lado, permite também a especificação de mensagens síncronas.
Utilizando o SPIN, especifica-se um modelo do sistema e os requisitos de correcção para essa especificação, tendo em atenção dois princípios básicos:
O modelo é fechado O modelo é de estado finito 6
Live lock acontece quando um determinado processo não progride, apesar da alteração do seus estados.
Pode ser consequência de uma recuperação de dead lock se dois processos retomarem em simultâneo.
7
36
Um sistema é fechado se nenhuma parte do mesmo fica por definir, ou seja, se tudo o que é necessário estiver definido.
Um sistema é de estado finito se tem um número finito de estados potenciais. Um estado de um sistema é o conjunto de todos os seus valores e pontos de controlo. Se isto acontecer, todos os estados poderão ser percorridos e verificados em conformidade com a especificação.
Uma das vantagens do SPIN é o facto de a ferramenta verificar automaticamente propriedades do sistema. Isto faz com que seja assegurado que tudo o que foi especificado é satisfeito pelo modelo. Esta técnica de validação por modelos é muito vantajosa uma vez que faz uma validação exaustiva de todos os estados, o que é praticamente impossível noutras situações de debug. Apresenta a desvantagem de ser
necessária uma boa especificação, com um bom nível de abstracção, pois caso contrário facilmente se tem problemas de memória ao efectuar uma verificação. O SPIN efectua a verificação de propriedades baseado na lógica temporal LTL (ver secção 3).
Figura 3.1 A verificação de propriedades em SPIN
Quando é efectuada uma verificação de uma propriedade que não é válida, permite guardar essa execução para utilizar, por exemplo, em modo de debug e permite
corrigir/validar o modelo/propriedade.
Na criação do modelo de um sistema, representa-se o seu comportamento num ambiente distribuído com foco no desenho do mesmo. Ao modelo definido designamos modelo de validação. De forma a poder efectuar a validação de um modelo é necessário poder
Modelo Promela
Propriedades de correcção, em LTL
Simulação interactiva e aleatória do Simulação guiada
Código do verificador de modelos
Execuções de erro Contra-exemplos às propriedades de correcção Compilador
de C
Executável do verificador de
37
dizer com precisão o que significa um desenho estar correcto. Alguns dos critérios a que um modelo correcto deve atender são:
- ausência de deadlocks
- ausência de livelocks
- ausência de terminações abruptas
No entanto estas características apesar de serem importantes não são suficientes para provar que o modelo está correcto.
Há outras propriedades inerentes aos protocolos que deverão ser alvo de prova. No caso deste trabalho serão as propriedades referentes aos sistemas de votação electrónica. No entanto, a fim de ser possível verificá-las será necessário reduzir a complexidade do modelo focando a sua especificação no que pretendemos verificar do protocolo. Para tal utiliza-se uma linguagem para especificar os requisitos de correcção que permita analisar o modelo.
De forma a reduzir a complexidade do modelo devemos escolher cuidadosamente o conjunto de critérios de correcção que se pretende exprimir. O método para essa escolha não abrange todas as situações possíveis. Vários níveis de complexidade são suportados. A verificação de deadlocks é computacionalmente mais simples e existem diversos
algoritmos que facilmente detectam esta propriedade nos sistemas.
Outros tipos de requisitos, tais como ausência de livelocks são especificados de outra
forma e têm um peso computacional mais elevado. Quanto mais sofisticados forem os requisitos a verificar, mais recursos utilizará a verificação automática.
Em Promela podemos especificar as propriedades referidas acima. Para verificar um modelo, devemos especificar critérios de correcção, como afirmação (claim) sobre o
seu comportamento.
Podemos ter dois tipos de afirmações: inevitável ou impossível.
Como o número de comportamentos possíveis de um modelo Promela é finito, uma
afirmação de qualquer tipo define uma afirmação complementar e equivalente à
primeira.
38
O comportamento de um modelo é definido como o conjunto de todas as sequências de execução do mesmo. Uma sequência de execução é um conjunto finito de estados. Um estado é definido pela especificação de todas as variáveis globais e locais e todos os pontos de controlo de um processo, bem como ainda o conteúdo de todos os canais de mensagens. Um modelo pode ser colocado num determinado estado através da atribuição de valores a variáveis, pontos de controlo e fluxo de canais.
Um conjunto de estados em Promela é válido se satisfaz duas condições:
O primeiro estado da sequência, isto é, o estado de ordem 1, é o estado inicial do sistema M com todas as variáveis inicializadas a zero, todos os canais de mensagens vazios, apenas com o processo init activo e no seu estado inicial.
Se M é colocado no estado com ordem i, então existe pelo menos uma sequência
de execução que o transforma no estado com número ordinal i+1.
Existem dois tipos de sequências de execução:
Sequências de terminação que ocorrem quando um estado não se verifica mais do que uma vez numa sequência de execução. O modelo M não contém instruções executáveis quando colocado no último estado da sequência.
Sequência cíclica em que todos os estados, excepto o último, são distintos e o último estado da sequência é igual a um dos estados anteriores.
Execuções cíclicas definem potencialmente execuções infinitas. Todas as sequências de terminação e cíclicas podem ser geradas executando um modelo Promela. Ao conjunto de todos os estados incluídos no comportamento do modelo chama-se conjunto dos estados atingíveis do modelo.
39
com asserções (assert). No entanto, se é necessário mais do que uma proposição,
poderão ser necessários critérios de ordem indicando, por exemplo, quais as propriedades que devem aguardar para obter a veracidade de uma outra.
Afirmações
temporais
Nesta formalização especifica-se uma ordem das proposições. Numa afirmação temporal, uma ordem sequencial de duas proposições indica uma sequência imediata. Os tipos de requisitos de correcção que são efectuados são diferentes para sequências de terminação e sequências cíclicas. Um requisito importante para as sequências de terminação é a ausência de deadlock. Nem todas as sequências de terminação
correspondem no entanto a deadlocks. Teremos então de indicar quais as propriedades
dos estados finais de modo a indicar os que são considerados deadlocks. Para as
sequências cíclicas devemos indicar condições relativas a ausência de livelocks.
O SPIN permite verificar os seguintes tipos de propriedades:
Invariância
[] p
Durante uma execução, todos os estados satisfazem p.
Figura 3.2 Invariância
Resposta
p -> <> q
Todo o estado que satisfaz p será seguido eventualmente por um que satisfaz q.
Figura 3.3 Resposta
P P P P P P P P
40
Precedência
p -> (q U r)
Todo o estado que satisfaz p é seguido por uma sequência de estados que satisfaz q e
essa sequência é terminada por um estado que satisfaz r.
Figura 3.4 Precedência
Objectivo
p -> <> (q || r)
Toda a sequência que satisfaz p é precedida por uma sequência de estados que satisfaz q ou r.
Figura 3.5 Objectivo
Deadlock
O modelo do sistema está num estado global onde nenhuma transição é possível.
Afirmações violadas
Apresenta a possibilidade de fazer afirmações sobre o modelo e verificar se são verdadeiras ou falsas. Em SPIN é utilizado o assert.
Código não executado
Apresenta a possibilidade de verificação que permite validar se existe código não atingido ou seja código que nunca é executado.
A Secção 4 detalha a modelação do protocolo REVS em SPIN, onde serão validadas as propriedades básicas de um modelo e os princípios atrás descritos, bem como propriedades específicas inerentes aos sistemas de votação electrónica.
P
41
3.2
UPPAAL
É uma ferramenta integrada para modelação, validação e verificação de sistemas em tempo real. É desenvolvida através de cooperação entre o Departamento de Tecnologias da Informação da Universidade de UPPSALA, na Suécia, e o Departamento de Ciências da Computação da Universidade de AALBORG, na Dinamarca.
O modelo de um sistema é definido como um autómato, que utiliza tipos de dados determinísticos e comunica através de estruturas de dados partilhadas e canais de comunicação. A ferramenta UPPAAL é adequada para sistemas em tempo real ou para protocolos de comunicação, ou seja, aqueles em que o momento em que os eventos ocorrem é relevante [5, 28, 29].
Nos sistemas em tempo real, a sua correcção depende não só da ordem de execução mas também do momento de execução. A importância de um serviço ser disponibilizado no momento certo é em muitos dos sistemas de uma relevância extrema. Os sistemas de votação electrónica não são excepção; por exemplo, é muito importante que as fases do protocolo se interliguem adequadamente, de forma a garantir um sistema de votação robusto e fiável.
O UPPAAL inclui uma linguagem de modelação, um simulador e um verificador automático de modelos. Através da linguagem pode desenhar-se o modelo do sistema. O simulador permite a análise das diversas execuções dinâmicas do sistema modelado. O verificador de modelos permite uma verificação exaustiva e dinâmica do comportamento do sistema. No entanto, para que isso seja possível, as especificações deverão ser correctamente formuladas numa linguagem que seja reconhecida pela ferramenta. No caso do UPPAAL é utilizada uma versão simplificada do CTL (ver secção 3).
O UPPAAL utiliza uma arquitectura cliente-servidor subdividindo-se numa interface gráfica para modelação e simulação de sistemas e num sistema de verificação automática.
42 As declarações globais e locais; Os templates dos autómatos;
A definição do sistema.
O simulador é uma ferramenta que possibilita a validação de todas as execuções dinâmicas durante a modelação. Poderá também ser utilizado para visualizar pormenores de execuções do verificador. Por exemplo ao verificar uma propriedade que falha, poderá ser guardada a execução da simulação que origina essa falha de propriedade a assim pode-se efectuar o debug e corrigir o modelo.
O UPPAAL disponibiliza ainda um editor onde se pode fazer a especificação de requisitos de propriedades para utilizar no verificador de modelos.
Figura 3.4 Verificação de propriedades em UPPAAL
Após a criação do modelo um UPPAAL é necessário indicar como verificar as propriedades pretendidas.
O UPPAAL permite verificar quatro tipos de propriedades:
Acessibilidade
Uma determinada condição é verificada em algum ponto do modelo. Graficamente poderemos representar tal como na figura seguinte:
Modelo Formal
Consultas
Verificador
de Modelos SIM
ou
NÃO (contra-exemplo)
43
Figura 3.5 E<> p – Existe eventualmente p
Existe um caminho de execução em que p ocorre em algum estado desse caminho.
Segurança
Uma determinada condição é verdadeira em todos os estados, num caminho de execução. Esta propriedade está representada graficamente nas figuras seguintes:
Figura 3.6 E[] p – p existe globalmente
Existe um caminho de execução onde p é verificado para todos os estados no caminho.
44
Figura 3.7 A[] p
Liveness
Uma determinada condição é verificada eventualmente algures no modelo.
Figura 3.8 A<> p –“Sempre eventualmente p”
A figura anterior mostra que para todos os caminhos de execução, p é verdadeiro, pelo
menos para um estado do modelo.
A figura seguinte mostra uma situação em que um caminho de execução que inicie com um estado onde q se verifique alcança posteriormente um estado onde p se verifica
45
Figura 3.9 q->p –“q leva sempre a p”
Deadlock
Indica se é possível deadlock ou não no modelo.
Por exemplo, podem-se definir as seguintes propriedades a serem verificadas:
E<> deadlock indica “Existe deadlock”
A[] not deadlock indica “Não existe deadlock”
Nas expressões utilizadas para a verificação em UPPAAL o primeiro elemento, refere-se a uma quantificação em relação aos caminhos possíveis do modelo: “A” reprerefere-senta todos os caminhos e “E” algum caminho. O segundo elemento representa uma quantificação mas em relação aos estados dos caminhos considerados; “[]” representa todos os estados e “<>” representa algum estado.
À semelhança do que acontece em SPIN, nem sempre um deadlock representa um erro
no modelo do sistema. Pode ser suficiente mostrar que o deadlock ocorre apenas quando
é esperado. Este tipo de verificação será mostrado no decorrer do trabalho realizado. Semanticamente, em UPPAAL a verificação é efectuada da seguinte forma:
O UPPAAL usa um sistema temporal de transições (S, s0,) representando uma rede
de autómatos temporais. S representa o conjunto de todos os estados, s0 o estado inicial
46
estado inicial. Ou seja, variáveis no seu estado inicial, relógios iguais a zero. Os dois tipos de transições possíveis são: transições de acção e transições de espera.
Quando é efectuada uma avaliação, se uma expressão for inválida, a mesma é abortada. Numa transição de espera, a mudança de um estado para o outro é efectuada por passagem de tempo. É esta uma das características em que o UPPAAL difere do SPIN. Numa transição de acção, a mesma ocorre por sincronização dos nós e pode ser de três tipos: transição interna que é aquela se ocorre dentro dum processo, sincronização binária que é aquela que ocorre entre dois processos ou sincronização em broadcast que
47
4
Verificação de protocolos de votação electrónica com SPIN
O SPIN é uma ferramenta utilizada na verificação automática de sistemas distribuídos. Esta ferramenta apresenta uma interface gráfica que permite de uma forma intuitiva especificar e validar o modelo do sistema em estudo.
O SPIN permite efectuar uma simulação do modelo utilizando vários parâmetros, por exemplo, indicando valores que se vão repercutir na representação gráfica da simulação: espaçamentos e legendas a apresentar; escolha da visualização dos valores das variáveis locais, globais e canais de comunicação existentes.
Por outro lado, a simulação pode ser automática e aleatória, permitindo fazer debug do
modelo. Neste tipo de simulação todas as decisões não determinísticas são resolvidas aleatoriamente. Pode efectuar-se simulações aleatórias baseadas num valor (seed) que,
se for mantido, permite reproduzir sempre a mesma execução. Neste documento será apresentado um exemplo desta opção.
É possível também efectuar simulações nas quais se pode forçar uma determinada execução. Neste caso, para todos os pontos de escolha não determinística é requerida a intervenção do utilizador para a escolha de um dos ramos.
Além das opções anteriores, pode ainda efectuar-se uma simulação guiada. Esta opção permite seguir um erro que se tenha obtido previamente. Se a simulação tiver muitos passos, é possível omitir vários passos e avançar para passos posteriores.
48
Define-se um modelo de um sistema utilizando três tipos de objectos:
Processos;
Canais de mensagens; Variáveis de estado.
Figura 4.1 Comunicação entre os tipos de objectos em SPIN
Todos os processos são por defeito objectos globais e os canais ou variáveis podem ser locais ou globais.
A estrutura de um modelo em SPIN é muito idêntica à da linguagem C.
Os processos são definidos através de declarações proctype onde é definido o seu
comportamento. Para os instanciar e executar é utilizado o processo init que é
equivalente ao main da linguagem C. Este processo pode inicializar variáveis globais,
criar canais de mensagens e instanciar processos.
Para a verificação, o SPIN tem um componente gestor de fórmulas LTL que permite expressar um comportamento positivo ou negativo consoante o pretendido. Uma propriedade positiva é negada automaticamente pelo SPIN para ser convertida numa cláusula never que representa a respectiva propriedade negativa. Esta propriedade
representa o comportamento que não se pretende e que se afirma nunca ocorrer. Dados Globais
Dados Locais Processo 1 Processo 0
Dados Locais
Canais de
![Figura 2.1 Processo Genérico de votação electrónica [6]](https://thumb-eu.123doks.com/thumbv2/123dok_br/16515517.735203/17.893.138.770.479.794/figura-processo-genérico-de-votação-electrónica.webp)
![Referências técnicas para atuação de psicólogas(os) em Programas de Atenção à Mulher em situação de Violência [2013] - CREPOP CREPOP](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)