Sistema di e-voting per l’INFN

Presentazione sul tema: "Sistema di e-voting per l’INFN"— Transcript della presentazione:

1 Sistema di e-voting per l’INFN
DRESS Sistema di e-voting per l’INFN Ramon Orru’ Dael Maselli Michele Tota

2 Il problema L’INFN necessita di un sistema di voto elettronico:
Riduzione degli spostamenti Riduzione delle spese Riduzione dell’effort necessario alla definizione di un’elezione Pricincipali caratteristiche richieste: Sicurezza Ridondanza e resistenza ai guasti Anonimato Gestione procedura di voto “in-house” Perchè utilizzare un sistema di evoting all’INFN? Coercizione è più frequente con i sistemi tradizionali: il superiore può dire “Hai votato?”, “Adesso vieni con me a votare”, “Ti ho visto che sei andato a votare”, in questo modo non può sapere se abbiamo votato o meno, perchè possiamo farlo tranquillamente dal pc di casa. Per noi sono importanti le caratteristiche nella lista in basso. La Biodola, Maggio 2016 Workshop CCR

3 REVS Accuratezza Il voto non può essere alterato
Un voto invalido non viene conteggiato Democrazia Solo elettori designati possono votare Ogni elettore vota una volta sola Privacy Impossibile risalire all’elettore Impossibile mostrare il proprio voto Verificabilità Elettori verificano la correttezza Resistenza alla corruzione (Collusion) Impossibile cospirare per alterare un’elezione Disponibilità Comportamento uniforme Accessibilità per l’intera elezione Riprendibilità (Resumability) Il voto può essere interrotto e ripreso Nello studio dei vari sistemi di evoting preesistenti si fa riferimento ad un insieme di proprietà, che sono imprescindibili, ogni sistema di evoting dovrebbe possederle Privacy: evita la possibilità di coercizione, impossibile dimostrare se si è votato e chi. Verificabilità: impensabile ottenerla nel voto tradizionale (non è possibile verificare il proprio voto) La Biodola, Maggio 2016 Workshop CCR

4 Core : attività svolte (prev.)
Riscrittura e riorganizzazione completa dei server (conservata la parte crittografica) Implementazione dello scambio di messaggi (RMI over SSL). Implementazione sotto-sistema di log multilevel. Implementazione sistema configurazione (*.properties). Daemonizzazione processi server. Riscrittura e riorganizzazione delle entità di dominio. Riscrittura astrazioni Data Source layer (DAO patterns). Implementazione DAO MySQL. Documento analisi dei requisiti (parziale). Definizione ERD. Repo Git (da rendere accessibili pubblicamente). Server Interfaccia amministrativa Interfaccia utente Documentazione Mavenizzazione per tutti i progetti (4). Script per sysadmin operation. Avviata interazione con team Sistema Informativo per integrazione GoDiVa. La Biodola, Maggio 2016 Workshop CCR

5 Core : attività svolte (new)
Aggiornamento data model. Distinzione amministratore/votante rispetto all'elezione. Amministratori multipli elezione. Autenticazione AAI. Aggiornamento DAO Implementazione connection pooling DB. Riscrittura funzioni crittografiche. Mantenuta utility per blind signature originale. Ridefinita lunghezza chiavi cifratura (asimmetriche/simmetriche) AES-256: necessità di sostituire security policy JVM per leggi export US. Paranoid authentication. Implementazione modulo server. Implementazione modulo webapp. Primo incontro con stakeholder per la definizione del comportamento atteso La Biodola, Maggio 2016 Workshop CCR

6 Core : prossimi passi Autorizzazione AAI-GODiVA.
Opzioni sulle caratteristiche dell'elezione. Voto unico (non sovrascrivibile). Raccolta ulteriori requisiti (stakeholder specifici). Test & Debug. Proposta schema di deployment (HEEELP!). Completare design e casi d’uso. La Biodola, Maggio 2016 Workshop CCR

7 Infrastructure deployment
Infrastruttura minima: Backend Administrator (5) Distributor (2) Anonymizer (2) Counter (2) Frontend Commissioner (2) Voter (2) Regole per una distribuzione ideale: Administrator non accoppiabile con altri server Anonymizer non accoppiabile con il Counter La Biodola, Maggio 2016 Workshop CCR

8 Paranoid Auth ADM ADM ADM ADM ADM ADM ADM ADM
DISTRIBUTOR ADMINISTRATOR ANONYMIZER COUNTER AAI AUTH COMMISSIONER VOTER Alcuni dei componenti del sistema (quelli in alto) possono (devono) essere replicati, possibilmente a livello geografico, per garantire tolleranza ai guasti, sicurezza e alta disponibilità dei servizi, ma sopratutto il corretto funzionamento dello schema di REVS. Il Commissioner(COM) è in qualche modo il reponsabile dell’elezione: crea la copia di chiavi RSA dell’elezione, e mantiene segreta la chiave privata definisce e firma la scheda di voto distribuisce le configurazioni operative dell’elezione gestisce gli eventuali reclami Il Distributor(D) è il componente che si occupa di diffondere le informazioni necessarie al voto, è l’elemento con il più alto carico in termini di trasferimento dati L’Administrator(ADM) è la parte che si preoccupa di validare il voto, importante è il fatto che secondo lo schema di REVS N/2 +1 administrator devono validare lo stesso voto, per evitare che un insieme di nodi cospiratori possano compromettere il voto. Per convalidare il voto viene usato un meccanismo di blind signatures, ovvero il voter(V) sottomette una “busta chiusa contente la scheda di voto e un foglio di carta copiativa, l’administrator firma la busta, il voter poi estrae dalla busta la scheda che risulta firmato”, ovviamente è solo un’analogia, lo schema di blind signature è basato su chiavi asimetriche RSA. Una volta che il Voter(V) ha compilato la scheda di voto, la sottomissione (“imbucare la scheda”) avviene presso l’Anonymizer(A), che provvede poi a propagare il voto al Counter(C), che colleziona tutte le schede. Nel propagare l’informazione, l’Anonymizer introduce sia un ritardo temporale, che una modifica nell’ordine delle sottomissioni, al fine di evitare analisi temporali per individuare il votante. Il Counter(C) è il componente che raccoglie i voti, e quando l’elezione termina, utilizza la chiave privata dell’elezione, rilasciata a questo punto dal Commisioner(COM), per “aprire” le schede di voto e conteggiare i voti. Il Voter(V), a questo punto, può confrontare i risultati ottenuti con le informazioni in proprio possesso per verificare che il proprio voto sia stato conteggiato correttamente. - USER BROWSER La Biodola, Maggio 2016 Workshop CCR

9 Interfacce utente: attività svolte (prev.)
Adattato il codice per l’utilizzo su un application server Automazione dei meccanismi che consentono la configurazione e gestione dei server che andranno a costituire l'infrastruttura del sistema Automazione del flusso di generazione dell’elezione, comprensivo: della generazione e lo scambio delle informazioni crittografiche (legate alla creazione di una nuova elezione) scambio di tutte le informazioni necessarie con i server Automatizzato il processo di generazione dei report al termine di un'elezione (ovvero lo spoglio elettorale). Implementazione temporanea della gestione degli utenti Meccanismo di autenticazione provvisorio Visualizzazione delle informazioni relative alle elezioni disponibili Presentazione della scheda elettorale dell'elezione per cui si è scelto di votare Sottomissione della scheda votata ai server preposti La Biodola, Maggio 2016 Workshop CCR

10 Interfaccia utente: attività svolte
Creazione di un’elezione suddivisa in 4 passi: Definizione delle informazioni generali sull’elezione Caricamento dell’elettorato tramite file CSV Caricamento degli amministratori dell’elezione tramite CSV Definizione dei server che verranno coinvolti durante l’elezione Definizione della scheda elettorale 4 tipologie di quesiti: Chiusa (singola e multipla) Aperta (singola e multipla) Scheda elettorale in JSON Riepilogo di tutte le informazioni inserite prima di salvare l’elezione La Biodola, Maggio 2016 Workshop CCR

11 Interfaccia utente: attività svolte
Autenticazione attraverso diversi metodi Paranoid Authentication abbinato ad INFN-AAI PBKDF2 (Password Hashing) Generazione permalink per consentire la visualizzazione dei risultati di un’elezione terminata Cancellazione di un’elezione La Biodola, Maggio 2016 Workshop CCR

12 Interfaccia utente: attività da svolgere
Completamento della gestione degli errori ed eccezioni Completamento della modifica di un’elezione Test e debug La Biodola, Maggio 2016 Workshop CCR

13 Interfacce grafiche: attività svolte e da svolgere
Le funzionalità del voter e del commissioner sono fruibili tramite pagine web (Servlet + JSP + CSS + JS) Grafica material design Accessibilità responsive Documentazione sull’utilizzo (inline-help e wiki) La Biodola, Maggio 2016 Workshop CCR

14 Votazione di test Votazione per il poster più interessante ed innovativo (certificato self-signed) Orario di votazione: inizio ore 19:30 di martedì 17 maggio fine ore 19:30 di mercoledì 18 maggio La Biodola, Maggio 2016 Workshop CCR

15 Grazie per l’attenzione
DRESS Grazie per l’attenzione Ramon Orru’ Dael Maselli Michele Tota