Voto elettronico mediante blockchain: problemi e possibili soluzioni

Blockchain sta diventando sempre più una buzzword per applicazioni che spaziano dalla finanza, alla logistica e la cyber security. Distinguere le potenzialità della tecnologia dalle semplici illusioni è però critico quando si propone di utilizzarla per il voto elettronico.

Può essere opportuno analizzare vantaggi e svantaggi di soluzioni digitali per un problema critico come la gestione di una elezione unicamente mediante strumenti informatici [1, 4, 11]. Una premessa fondamentale è che anche il sistema di voto su carta che molti ritengono superiore, offriva inizialmente un livello di sicurezza basso ed è stato migliorato in corso d’opera [15].

Il voto elettronico: problemi e possibili soluzioni

Le soluzioni possibili per il voto elettronico vanno dalla digitalizzazione dei vari supporti cartacei, dai registri dei votanti alle schede, fino alla completa abolizione dei seggi sostituiti da un sito per il voto. Ad esempio, tra molte polemiche e timori, la Svizzera intende costruire un sistema di voto elettronico che permetta ai cittadini di votare via Internet dovunque si trovino ed utilizzando un qualunque dispositivo.

Attualmente, i vari cantoni utilizzano due sistemi di voto. Uno è stato sviluppato nel cantone di Ginevra ed uno in quello di Neuchâtel da SwissPost. La soluzione svizzera prevede che il votante si colleghi ad un apposito sito mediante computer o smartphone, si autentichi e quindi formuli il proprio voto [18]. Il voto viene criptato e memorizzato in un’urna elettronica. I voti verranno decifrati e contati al termine della elezione mediante una chiave elettronica che è suddivisa tra i membri della commissione elettorale.

I principali problemi tecnologici di questa soluzione sono legati ad eventuali vulnerabilità nel sito di voto, ad attacchi di tipo DDOS al sito ed a malware esistente sul computer utilizzato per votare che potrebbe interferire con le votazioni. Infine, questo sistema trascura totalmente il problema della confidenzialità del voto. La possibilità di votare ovunque ed in qualunque momento semplifica drammaticamente il voto di scambio perché permette ad organizzazioni criminali di costringere le persone a votare in presenza di altre per verificare il loro voto.

L’invito ad attaccare il sito per verificarne la robustezza va vista più come un approccio di marketing che come una valutazione scientifica. Anche tralasciando tutte le potenziali inconsistenze di una valutazione mediante penetration test, è chiaro che le vere minacce a questo sistema non riveleranno certamente eventuali vulnerabilità o debolezze alle poste svizzere.

A parziale conferma, l’unica vulnerabilità attualmente resa pubblica riguarda l’algoritmo di permutazione dei voti utilizzato per impedire la correlazione dei voti ricevuti e dei tempi a cui le persone hanno votato. Il sistema adottato dalle poste svizzere non permette di verificare che venga effettivamente eseguita una permutazione senza, ad esempio, inserire voti non espressi per sostituire quelli espressi. Questa vulnerabilità non può però, contrariamente a quanto apparso sulla stampa, essere utilizzata da remoto ma richiede un accesso fisico ai sistemi utilizzati.

Quindi, al limite, permette alle poste o al governo svizzero di manipolare il risultato elettorale.

I-vote, il sistema di voto via internet utilizzato in Estonia [19], mantiene alcune caratteristiche del sistema svizzero ma considera anche la possibile coercizione. Infatti, il sistema permette ad una persona di votare più volte e tiene conto solo dell’ultimo voto espresso. Ciò permette a chi è stato forzato a votare di ripetere il voto e sostituire quello forzato. Il sistema non permette ancora di votare tramite smartphone.

Ogni soluzione di e-vote deve affrontare, tra gli altri, i seguenti problemi

1. La sicurezza del dispositivo che viene usato per esprimere il voto
2. La sicurezza del sistema usato per ricevere e memorizzare il voto
3. Come garantire al votante che il suo voto ha contribuito al risultato
4. Come permettere un audit delle votazioni

Fig. 1. I primi venti paesi europei per migrazione

E’ del tutto ovvio che la semplice digitalizzazione delle votazioni evita l’uso di materiale cartaceo ma preserva i seggi che garantiscono la confidenzialità del voto. La versione digitale usa solo stazioni di voto predefinite e questo semplifica la soluzione dei primi due problemi. Ogni soluzione che permetta di votare “anytime, anywhere” deve non solo garantire la sicurezza del dispositivo di voto ma anche offrire soluzioni al problema della coercizione del voto. La garanzia che un voto abbia contribuito al risultato finale è basata sulla comunicazione al votante di una stringa pseudocasuale e sulla pubblicazione, dopo lo scrutinio, delle stringhe associate ai voti scrutinati. Infine, il problema dell’audit del voto. E’ chiaro che l’esistenza di materiale cartaceo, quindi fisico, aumenta la complessità di manipolare in maniera non rilevabile il materiale stesso. Un problema simile è sorto quando i cronotachigrafi digitali hanno sostituito quelli che utilizzavano dischi di carta.

Nel seguito per semplicità considereremo unicamente una soluzione di voto paper free ma che preservi seggi elettorali e postazioni di voto controllabili. Assumeremo anche che le varie comunicazioni tra i vari moduli che compongono il sistema siano opportunamente criptate in modo da proteggere la confidenzialità e l’integrità delle informazioni trasmesse.

E’ chiaro comunque che in un mondo dove le migrazioni sono sempre crescenti, il voto “anytime, anywhere” diventerà una richiesta sempre più frequente anche in paesi di antica democrazia. Per convincersene basta analizzare, ad esempio, la fig. 1 che illustra le percentuali di immigrazione ed emigrazione nei paesi europei in basi a dati ONU del 2015 o ricordare che ci sono più di venti milioni di cittadini dell’ EU che vivono in un altro paese dell’EU.

Blockchain, ledger e consenso

Prima di discutere i potenziali vantaggi di una soluzione basata su blockchain è opportuno premettere alcune considerazioni sulla tecnologia e sulle specifiche soluzioni. Una prima considerazione, a prima vista banale ma spesso dimenticata, è che nessuno Stato, nessuna Regione o Cantone può accettare che le sue elezioni siano sotto il controllo di un insieme di persone sconosciute.

Questo elimina immediatamente tutte quelle soluzioni che propongono di inserire i voti, criptati o no, sulla blockchain di una qualche moneta elettronica. Ad esempio, una qualunque soluzione che usi la blockchain di Bitcoin 13, ha tempi di voto e di calcolo dei risultati non certi che dipendono dal comportamento e dalle convenienze di un insieme di miner. Inoltre, uno Stato potrebbe interferire con un altro semplicemente utilizzando parte delle sue risorse ICT per ritardare le votazioni semplicemente producendo nuovi blocchi da inserire nella blockchain. Infine, anche i più strenui sostenitori di e-vote mediante blockchain ammettono che il consumo di energia richiesto da una votazione nazionale sarebbe del tutto improponibile.

Le considerazioni precedenti permettono di adottare unicamente soluzioni in cui tutti i vari gestori della blockchain che decidono le informazioni da inserire sono noti a priori ed autenticati. Inoltre, ogni gestore può conoscere identità e chiavi degli altri gestori. Queste informazioni possono essere condivise in fase di configurazione. Molti ritengono che questo violi la tecnologia blockchain originaria, ma è chiaro che soluzioni diverse non siano in generale accettabili. Il passo successivo è scegliere l’algoritmo di mining dei gestori della blockchain o meglio, per essere più generali ed astratti, visto che abbiamo ormai abbandonato la blockchain di una qualche cripto moneta, l’algoritmo di consenso del distributed ledger [4, 5, 6, 8, 10, 14].

Questa scelta è fortemente correlata all’architettura complessiva del sistema. Consideriamo, ad esempio, una soluzione che memorizzi nel distributed ledger i vari voti espressi, ovviamente criptati, mentre le votazioni hanno luogo e prima di calcolare i risultati finali.  In questo caso è possibile che alcuni dei sistemi che memorizzano le copie che costituiscono il distributed ledger siano stati attaccati in un qualche momento ed abbiamo un comportamento malevolo. In questa architettura e sotto l’ipotesi che alcune copie del ledger siano sotto il controllo di un avversario, una soluzione possibile è quella di scegliere un algoritmo di consenso basato su votazione e che permetta ai gestori non malevoli di convergere velocemente sulla stessa soluzione, i.e. sullo stesso blocco da inserire nel distributed ledger.

Il consenso è raggiunto quando un numero adeguato di gestori, il quorum, concorda sul risultato. E’ interessante notare come valutazioni preliminari [2] evidenzino come le possibili prestazioni siano relativamente indipendenti dal valore di quorum scelto e siano invece più sensibili alla frequenza con cui gestori malevoli tentano di inserire informazioni nel ledger. In generale, non possono essere adottati algoritmi in cui si voti non sul dato da inserire ma sul gestore che può scegliere il dato da inserire. L’elezione, anche temporanea, di un gestore malizioso può generare inconsistenze nella votazione. Per evitare che i vari gestori malevoli influenzino le votazioni, tutti i gestori devono aver visibilità di tutti i voti emessi e il numero di gestori maliziosi deve essere inferiore ad una soglia che dipende dall’algoritmo di consenso scelto.

Possibile scenario in Italia

Tipicamente, se al più un quinto dei gestori è malizioso, l’algoritmo di consenso produce dei risultati corretti ovvero che dipendono unicamente dai gestori non maliziosi. Immaginiamo, ad esempio, che in Italia si utilizzi un’architettura del sistema di voto che preveda un gestore, e quindi una copia del ledger, per ogni regione. Supponiamo anche che i vari gestori ricevano periodicamente dati quali i voti emessi, numero dei votanti ed i certificati dei votanti e che eseguano un algoritmo di consenso per decidere il record da inserire nel ledger che incapsula le informazioni non ancora memorizzate nel ledger. In un sistema come quello schematizzato, in generale sono necessarie almeno 6 regioni i cui ledger siano maliziosi per poter manipolare il risultato delle elezioni. Per valutare la probabilità di un simile scenario, che non possiamo escludere a priori, occorre anche considerare che, come già ricordato, i vari gestori dei ledger sono noti a priori e configurati in modo da produrre lo stesso risultato a partire dagli stessi input.

Di conseguenza, ogni discrepanza tra i vari gestori del distributed ledger può essere dovuta unicamente ad un guasto o ad un comportamento malizioso generato a seguito di una intrusione. In questo contesto, l’algoritmo di consenso diventa quindi anche un potente meccanismo di rilevazione di guasti o intrusioni. In generale, anche se si scopre che un gestore è malizioso non è comunque possibile ripristinare un comportamento consistente del gestore. Questo ripristino è invece possibile nel sistema considerato. Ovviamente la scelta di un gestore, e quindi di una copia del ledger, per regione è solo una delle possibili soluzioni. Il numero di copie è a priori limitato solo dalla banda di trasmissione disponibile per le interazioni tra le varie copie. Aumentando il numero di copie aumenta anche il numero di gestori maliziosi che può essere tollerato.

Un ulteriore problema dovuto a gestori maliziosi è quello della perdita di voti espressi. Questo può accadere se le varie postazioni di voto trasmettono i voti espressi in un certo intervallo di tempo ad un solo gestore. Per evitare che il gestore manipoli in modo nascosto i voti ricevuti, è necessario che più gestori ricevano gli stessi voti. Ad esempio, se l’algoritmo di consenso può tollerare fino a m gestori maliziosi, allora ogni postazione dovrà trasmettere i propri voti ad almeno m+1 gestori per garantire che almeno un gestore onesto riceva i propri voti. Questo numero può essere più severo in base allo specifico algoritmo di consenso adottato. Ovviamente, questo vincolo ha significative ripercussioni sulla banda di trasmissione che deve essere disponibile. Comunque, una qualche forma di ridondanza sia sulle comunicazioni che sul calcolo è inevitabile nel momento in cui si voglia costruire un sistema resiliente ad attacchi maliziosi ed a guasti [3, 12] .

Audit delle elezioni

Uno dei vantaggi di una soluzione che memorizzi le informazioni su voti e votanti in un ledger è il numero non banale di controlli di audit che le proprietà di integrità di questa struttura permettono di immaginare e che la rendono un audit trail quasi per definizione. Questi controlli sono molto più potenti di quelli possibili in un sito web che conti i voti espressi mano a mano che li riceve o che, come il sistema sviluppato dalle poste svizzere, li depositi in un’urna elettronica per decifrarli e contarli successivamente.

Ad esempio, l’applicazione utilizzata può criptare il voto non appena esso è stato formulato, generare un tag univoco per il votante e trasmettere il voto criptato, il tag e l’identità del votante all’interfaccia locale del distributed ledger. Questa interfaccia raccoglie le informazioni sulla votazione da trasmettere ai vari gestori. I gestori possono organizzare le informazioni in uno o più ledger per essere analizzate successivamente. In generale, l’uso di ledger distinti, ad esempio per votanti, voti espressi e tag, permette di condurre analisi diverse e verificare in modo disgiunto proprietà di interesse delle elezioni. L’ovvio costo è quello di eseguire più algoritmi di consenso, problema che però può essere ridotto memorizzando in distributed ledger diversi le informazioni su cui i gestori hanno raggiunto un consenso. La quantità ed il tipo delle informazioni da memorizzare nel distributed ledger cambiano in funzione dell’audit che si vuole condurre ed anche delle statistiche che interessa calcolare. Ovviamente, nell’era dei big data le potenzialità analitiche e predittive degli algoritmi diventano sempre più sofisticate e quindi è opportuno limitare le possibili analisi sui vari ledger durante le votazioni per non influenzare il voto. Questo ha ripercussioni anche sull’algoritmo di cifratura dei voti. Infatti, alcuni algoritmi omomorfi permettono di dedurre anche risultati parziali cosa che in generale, dovrebbe essere evitata. E’ bene sottolineare comunque che la creazione di un ledger che riassuma i dati dei singoli seggi permetta di aumentare notevolmente la sicurezza del processo elettorale e di evitare manipolazioni o truffe durante gli scrutini.

Ovviamente, lo scrutinio finale dovrà considerare tutte le copie del distributed ledger e validare i risultati dello scrutinio confrontando i risultati parziali prodotti a partire dalla singola copia. Questo ovviamente non implica che ogni gestore del distributed ledger debba ricalcolare i dati, è possibile usare anche un numero minore di esecutori che operino ognuno su un sottoinsieme delle copie. Una volta inserite le informazioni nel distributed ledger, ogni manipolazione diventa estremamente complessa e richiede collusioni di un numero di persone ed organizzazioni molto elevato.

Audit e privacy

Un punto rilevante è quello di non permettere la correlazione tra voti emessi e votanti. Ad esempio, questo richiede che ogni interfaccia locale permuti voti, tag ed identità dei votanti in modo da ostacolare la correlazione. Può anche essere possibile che una interfaccia trasmetta unicamente il numero dei votanti ma non voti ed identità se, nell’intervallo prescelto il numero dei votanti non ha superato una soglia che garantisca un adeguato livello di anonimizzazione del voto. Queste semplici considerazioni evidenziano, in modo non sorprendente, il ruolo fondamentale dell’interfaccia locale verso il ledger. Cosi come una qualunque moneta elettronica è estremamente fragile rispetto ad attacchi al portafoglio del singolo utilizzatore, cosi un qualunque sistema di voto è fragile rispetto al sistema usato per formulare il voto. Questa è una delle ragioni per cui la soluzione di voto “anytime, anywhere” è così complessa. Anche assumendo integro il software che viene installato su un dispositivo dell’elettore, nulla si può sapere sulla sicurezza ed integrità delle macchine virtuali sottostanti. Meltdown e spectre ci ricordano come sia possibile accedere ad informazioni sfruttando non vulnerabilità della macchina virtuale che stiamo utilizzando ma quelle di macchine sottostanti. Esistono comunque tecniche di introspezione che permettono di calcolare da remoto e memorizzare nel ledger non solo informazioni sui voti formulati ma anche fingerprinting o hash del codice delle applicazioni e dei sistemi operativi utilizzati dal singolo seggio. Questo è ovviamente possibile solo nel caso di un numero comunque limitato di postazioni e non si applica quindi a soluzioni di tipo BYOD.

Conclusioni

Ogni possibile conclusione su un problema complesso e sfaccettato come quello considerato è necessariamente parziale e temporanea. La nostra analisi, molto preliminare, ha però dimostrato come il meccanismo di copie multiple protette permetta di definire meccanismi di controllo dell’integrità e di rilevazione di intrusioni potenti e con un costo ed una complessità ridotte. Ovviamente, attacchi locali alla singola stazione di voto o al singolo seggio che sfruttino collusioni o complicità locali sono sempre possibili ma richiedono un controllo del singolo seggio talmente esteso da indicare che nello scenario considerato i problemi da affrontare per garantire un voto libero non sono sicuramente tra quelli che la tecnologia può risolvere.

_________________________________________________________________

BIBLIOGRAFIA

1. F.Baiardi, A. Falleni, R. Granchi et al. SEAS, a secure e-voting protocol: Design and implementation, Computers & Security, Volume 24, Issue 8, 2005, Pages 642-652, ISSN 0167-4048, https://doi.org/10.1016/j.cose.2005.07.008.
2. F.Balzano, Discovering and Securely Storing a Network Topology, Laurea Magistrale in Informatica e Networking, Università di Pisa, 2019
3. D J. Bodeau, D. Graubart, J. Picciotto, R. McQuaid,, Cyber Resiliency Engineering Framework, Technical rep. R110237, Sept. 2011, MITRE Corporation
4. F.Cipressi, E-voting on blockchain: a SWOT analysis, Tesi di Laurea Magistrale in Informatica, Università di Pisa, 2018
5. B. Chase and E. MacBrough, “Analysis of the XRP Ledger Consensus Protocol”, 2018
6. M. J. Fischer, N. A. Lynch and M.S. Paterson, “Impossibility of Distributed Consensus with One Faulty Process”, Jornal of the ACM, vol. 32, 1985, pp. 374-382
7. Gov. Office for Science, Uk, “Distributed Ledger Technology: beyond block chain: A report by the UK Government Chief Scientific Adviser”, 2016.
8. Y. Gilad, R. Hemo, S. Micali, G. Vlachos and N. Zeldovich, “Algorand: Scaling Byzantine Agreements for Cryptocurrencies”, IACR Cryptology ePrint Archive, 2017
9. R. Haenni, “Swiss Post Public Intrusion Test. Undetectable Attack Against Vote Integrity and Secrecy”. Bern University of Applied Sciences, Marzo 2019
10. S. Joao, A. Bessani, and M. Vukolic. “A byzantine fault-tolerant ordering service for the hyperledger fabric blockchain platform”, 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2018.
11. N. Kshetri and J. Voas, “Blockchain-Enabled E-Voting,” in IEEE Software, vol. 35, no. 4, pp. 95-99, July/August 2018 doi: 10.1109/MS.2018.2801546
12. I. Linkov , D. A. Eisenberg, K. Plourde, T. P. Seager, J. Allen, A. Kott , “Resilience metrics for cyber systems”, Environment Systems and Decisions, Dec. 2013, Vol. 33, Issue 4, pp 471–476.
13. S. Nakamoto, “Bitcoin: a Peer-to-Peer Electronic Cash System”, 2008
14. D. Schwartz, N. Youngs and A. Britto, “The Ripple Protocol Consensus Algorithm”, 2014.
15. J. Willemson, “Bits or paper: Which should get to carry your vote?”. Journal of information security and applications, 38, 124-131, 2018.
16. K. Wüst and A. Gervais, “Do you Need a Blockchain?”, 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), Zug, 2018, pp. 45-54. doi: 10.1109/CVCBT.2018.00011
17. Z. Zheng, et al. “Blockchain challenges and opportunities: A survey.” International Journal of Web and Grid Services 14.4 (2018): 352-375.
18. https://www.evoting-blog.ch/en/pages/2019/public-hacker-test-on-swiss-post-s-e-voting-system
19. https://e-estonia.com/solutions/e-governance/i-voting