Trabalho Final de Curso LEIC 2005/2006 Luís Costa, 51041 Nuno Santos, 51048

1. Trabalho Final de CursoLEIC 2005/2006Luís Costa, 51041Nuno Santos, 51048 Orientador Prof. Doutor Paulo Ferreira Co-Orientador Mestre Rui Joaquim

2. Agenda • Introdução • Motivação e Objectivos • Requisitos • Dificuldades • MobileREVS • Arquitectura • Protocolo • Segurança • Implementação • Avaliação • Conclusão

3. 1 Introdução

4. Motivação e Objectivos 1 Motivação • Os sistemas de votação electrónica estão cada vez mais em voga • Os telemóveis são dispositivos de uso corrente entre a população • As tecnologias móveis permitem oferecer maior comodidade aos utilizadores, evitando a sua deslocação a locais específicos para votar Objectivos • Desenvolver uma aplicação para telemóveis que dê suporte a um sistema de voto electrónico (REVS) • Portabilidade, devendo ser possível instalar a aplicação em qualquer telemóvel que suporte aplicações Java • Boa usabilidade para facilitar o processo de votação

5. Requisitos 1 • Providenciar as propriedades do REVS • Correcção, Democracia, Privacidade e Verificabilidade • Produzir um sistema robusto • Disponibilidade • Capacidade de continuação diferida • Resistência ao conluio • Suportar a mobilidade dos eleitores • Considerações relativas às limitações e contexto das plataformas • Desempenho • Memória ocupada • Consumo de energia • Custos associados

6. Dificuldades 1 • Aplicação distribuída que troca dados sensíveis por canais inseguros • Bibliotecas criptográficas oferecidas pelas plataformas são escassas e não permitem garantir as propriedades desejadas para o sistema • Operações na rede são lentas, assim como nos dispositivos móveis • Nalguns dispositivos móveis a memória ainda é um recurso bastante limitado

7. 2 MobileREVS

8. Arquitectura 2 Comissário • Comissário – é o módulo usado para preparar a eleição: registar os eleitores e definir as configurações operacionais. • Distribuidores de Boletins – são responsáveis pela distribuição dos dados definidos pelo Comissário da eleição: boletins e configurações operacionais. • Administradores – são as entidades responsáveis pela validação dos votos. • Anonimizadores – estes módulos têm a responsabilidade de providenciar o anonimato, não permitindo que os Contadores associem um boletim de voto a um eleitor. • Contadores – verificam a validade de cada boletim certificando-se que estão presentes todas as assinaturas requeridas dos Administradores. • Módulo Eleitor – é o módulo usado pelo eleitor para participar na eleição. Distribuidores de Boletins Anonimizadores Contadores Administradores HTTP/HTTPS RMI RMI Módulo Eleitor

9. Distribuição – o eleitor contacta o Distribuidor de Boletins, fornece o seu número de eleitor, e recebe a lista de eleições em que pode participar. Posteriormente, requer um boletim indicando a eleição escolhida. Assinatura – após expressar o seu voto este é cegado e enviado aos Administradores para o assinarem. Os Administradores impedem que cada eleitor vote várias vezes com diferentes escolhas. Submissão – é criado um pacote com os dados a submeter e enviado aos Anonimizadores. Estes garantem que os Contadores não possam associar um voto a um eleitor. Cada eleitor pode submeter o seu voto as vezes que entender. Protocolo 2

10. SegurançaMecanismos existentes 2 • De modo a garantir os requisitos de segurança do sistema é necessário recorrer a técnicas criptográficas • Possíveis soluções • Funções criptográficas do módulo Crypto dos smartcards • OptionalPackage SATSA do J2ME • Bouncy Castle(Light Edition) • Biblioteca criptográfica especialmente desenvolvida para dispositivos com recursos limitados

11. SegurançaComparação das soluções 2 • Funcionalidades criptográficas oferecidas por cada solução: * Apenas para alguns smart cards Embora não estejam incluídas de raiz na biblioteca Bouncy Castle (Light Edition) já existe uma implementação de assinaturas cegas **

12. SegurançaConclusões 2  • Bouncy Castle (Light Edition) • Oferece todos os mecanismos de segurança necessários (portabilidade) • Não há aproveitamento das funcionalidades de segurança oferecidas pelos smart cards • Aumento do espaço da aplicação em relação às restantes soluções • Optional Package SATSA • Possibilita comunicação com o cartão, sendo uma mais valia para guardar dados sensíveis e para a utilização das suas funcionalidades criptográficas • A aplicação não sofre acréscimo de espaço, visto que a SATSA faz parte da implementação do J2ME... • …mas a sua presença está condicionada pela opção dos fabricantes e não é usual nos dias de hoje • Módulo Crypto dos smart cards • Não foi possível determinar quais os cartões utilizados pelas operadoras de telecomunicações portuguesas e, consequentemente, o modo de acesso às funções criptográficas desses cartões

13. ImplementaçãoDecisões 2 • J2ME • CLDC 1.0 e MIDP 2.0 • Características habituais dos telemóveis de hoje em dia • Comunicação • HTTP/HTTPS sobre GPRS/UMTS • RMI presente apenas como Optional Package • Armazenamento • Record Management Store (memória interna do telemóvel) • Outros desenvolvimentos • Adição de autenticação aos Distribuidores de Boletins • REVS Ballot Editor

14. ImplementaçãoFuncionalidades 2 • Suporte multi-utilizador • Suporte a diferentes tipos de questões • De resposta simples e múltipla, com possibilidade para respostas abertas • Continuação diferida do processo de votação • Através do armazenamento dos votos • Para facilitar o processo de votação (usabilidade): • Optimização do processo de acordo com uma pré-configuração • Pré-visualização e confirmação das respostas • Relatório de votação • Consulta da informação das eleições participadas

15. 3 Avaliação

16. Memória 3 Memória volátil consumida

17. Desempenho e comunicação 3 Comunicações (dados trocados) Desempenho

18. 4 Conclusão

19. Principais conclusões 4 • Foi possível criar uma aplicação para votação electrónica segura • Apesar das restrições impostas pelos telemóveis • Garantindo as propriedades pretendidas para este sistema • Alternativa viável • Face às plataformas presenciais • Mobilidade, permitindo votar a partir de qualquer lugar • Combate à abstenção • Face a sistemas semelhantes • A grande maioria ainda se baseia em SMS e interfaces de texto associadas, pouco amigáveis para o utilizador

20. Trabalho futuro 4 • Implementação de outras releases do MobileREVS • Optional Package FileConnection • Optional Package SATSA • Interfaces utilizador específicas para diferentes telemóveis • Estudos e alternativas • Servidor de entrada para o MobileREVS • Integração do REVS Ballot Editor no Comissário

21. Demonstração

22. Grupo de Sistemas Distribuídos Questões?