trabalho final de curso leic 2005/2006 luís costa, 51041 nuno santos, 51048

1

Instituto de Engenharia de Sistemas e Computadores Investigação e Desenvolvimento em Lisboa

Grupo de Sistemas Distribuídos

Trabalho Final de CursoLEIC 2005/2006

Luís Costa, 51041Nuno Santos, 51048

OrientadorProf. Doutor Paulo Ferreira

Co-OrientadorMestre Rui Joaquim


2Grupo de Sistemas Distribuídos

Agenda

1. Introdução– Motivação e Objectivos– Requisitos– Dificuldades

2. MobileREVS– Arquitectura– Protocolo– Segurança– Implementação

3. Avaliação

4. Conclusão

3



1Introdução



Motivação e Objectivos

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

1



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



Dificuldades

• 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

1

7



2MobileREVS



Arquitectura

• 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.

2

Servlet

REVSServer

HTTP/HTTPS

RMI

RMI

Distribuidoresde Boletins

Comissário

Administradores Anonimizadores Contadores

Módulo Eleitor



Protocolo 2• 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.



SegurançaMecanismos existentes

• 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 smart cards– Optional Package SATSA do J2ME– Bouncy Castle (Light Edition)

• Biblioteca criptográfica especialmente desenvolvida para dispositivos com recursos limitados

2



SegurançaComparação das soluções

• Funcionalidades criptográficas oferecidas por cada solução:

Operações elementares Assinaturas

3DES RSA SHA-1 Digitais Cegas

Módulo Crypto

dos smart cards *

SATSA Bouncy Castle

(Light Edition) **

Apenas para alguns smart cards

Embora não estejam incluídas de raiz na biblioteca Bouncy Castle (Light Edition) já existeuma implementação de assinaturas cegas

**

*

2



SegurançaConclusões

• 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

2



ImplementaçãoDecisões

• 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

2



ImplementaçãoFuncionalidades

• 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

2

15



3Avaliação



Memória 3Memória volátil consumida



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

Desempenho

18



4Conclusão



Principais conclusões

• 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

4



Trabalho futuro

• 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

4

21



Demonstração




Questões?

trabalho final de curso leic 2005/2006 luís costa, 51041 nuno santos, 51048

Documents