Enquadramento
Num processo de votação electrónica via Internet é fundamental que o votante tenha garantias de correcção dos sistemas que usa. A correcção pode envolver duas facetas completamente distintas:
- tolerância a falhas de componentes do sistema (máquinas ou redes) e;
- tolerância a tentativas de subversão da votação por entidades reguladoras do sistema de votação (servidores eleitorais).
Objectivos
Este projecto teve como objectivo desenvolver uma solução para assegurar a comunicação entre o votante e os diversos serviços de apoio ao processo eleitoral através de IP multicast. Para isso foi necessário repensar todo o protocolo de troca de mensagens existente actualmente e suportado por unicast.
A plataforma actual do REVS está desenvolvida em Java.
A plataforma actual do REVS está desenvolvida em Java.
Trabalho Realizado
O projecto foi realizado em três fases:
1. Estudo do protocolo de votação electrónica do REVS.
2. Alteração do protocolo de votação tendo em conta uma interacção com IP multicast.
3. Realização e teste num ambiente piloto.
1. Estudo do protocolo de votação electrónica do REVS.
2. Alteração do protocolo de votação tendo em conta uma interacção com IP multicast.
3. Realização e teste num ambiente piloto.
Protocolo REVS
O protocolo REVS é dividido em três fases:
Distribuição do boletim de voto: O eleitor contacta o Distributor para que ele possa obter um boletim de voto. O Distributor retorna o voto solicitado, a chave pública da eleição e a configuração operacional da eleição, tudo assinado pelo Commissioner de eleição.
Assinatura do boletim de voto: O eleitor obtém em seguida uma autorização de voto de pelo menos t de N Administrators (t > N/2).
Submissão de voto: O eleitor submete o voto para os Counters, através de diversos Anonymizers.
Toda a comunicação entre o módulo votante e os servidores, ou entre os servidores é feita recorrendo ao Remote Method Invocation – RMI do Java, i.e., comunicações unicast sobre TCP/IP.
Distribuição do boletim de voto: O eleitor contacta o Distributor para que ele possa obter um boletim de voto. O Distributor retorna o voto solicitado, a chave pública da eleição e a configuração operacional da eleição, tudo assinado pelo Commissioner de eleição.
Assinatura do boletim de voto: O eleitor obtém em seguida uma autorização de voto de pelo menos t de N Administrators (t > N/2).
Submissão de voto: O eleitor submete o voto para os Counters, através de diversos Anonymizers.
Toda a comunicação entre o módulo votante e os servidores, ou entre os servidores é feita recorrendo ao Remote Method Invocation – RMI do Java, i.e., comunicações unicast sobre TCP/IP.
Resultados
A alteração do protocolo de votação tendo em conta uma interacção com IP multicast levou ao estudo de vários modelos de comunicação em grupo para substituir o RMI. Desse estudo elegeu-se o JGroups.
Foi necessário dividir o módulo votante nas componente de votação denominada VoterEng e de comunicação denominada VoterCom.
Criou-se um módulo de comunicação que é instanciado para cada servidor e que intermedeia o servidor com o VoterCom, denominado ServerCom.
Por fim, substituíram-se as várias interacções em unicast para IP multicast através do toolkit para comunicações fiáveis em multicast JGroups.
Foi necessário dividir o módulo votante nas componente de votação denominada VoterEng e de comunicação denominada VoterCom.
Criou-se um módulo de comunicação que é instanciado para cada servidor e que intermedeia o servidor com o VoterCom, denominado ServerCom.
Por fim, substituíram-se as várias interacções em unicast para IP multicast através do toolkit para comunicações fiáveis em multicast JGroups.
JGroups
Framework para Comunicação Confiável em Grupo, permite comunicação peer-to-peer entre nós de um cluster.
Implementado através de uma pilha protocolar flexível, apresenta entre outros, serviços de transporte, fiabilidade, detecção de falhas e gestão de membros.
A aplicação pode comunicar directamente com o canal, classe que implementa um endereço comum, o que permite aos membros comunicarem entre si.
Framework para Comunicação Confiável em Grupo, permite comunicação peer-to-peer entre nós de um cluster.
Implementado através de uma pilha protocolar flexível, apresenta entre outros, serviços de transporte, fiabilidade, detecção de falhas e gestão de membros.
A aplicação pode comunicar directamente com o canal, classe que implementa um endereço comum, o que permite aos membros comunicarem entre si.
Conclusão
Existem vários modelos de comunicação em grupo que servem de alternativa ao RMI com diferentes aproximações ao problema; conforme os objectivos definidos, as características de cada modelo podem ser vantajosas ou desvantajosas.
A alteração do protocolo de votação para IP multicast entre o VoterCom e o ServerCom com o JGroups foi testado com sucesso, com os servidores a correm em numa máquina Linux e o módulo votante em Windows.
O JGroups não dispõe de um módulo com semântica cliente-servidor em multicast, estando orientado ao processamento em clusters.
A alteração do protocolo de votação para IP multicast entre o VoterCom e o ServerCom com o JGroups foi testado com sucesso, com os servidores a correm em numa máquina Linux e o módulo votante em Windows.
O JGroups não dispõe de um módulo com semântica cliente-servidor em multicast, estando orientado ao processamento em clusters.
