Crittografia e sicurezza informatica. Sistema di voto elettronico

Transcript

1 Crittografia e sicurezza informatica Sistema di voto elettronico Deliano Perfetti Gabriele Paone Anno 2003

2 1 indice 1. Specifiche 2 2. Scelte progettuali 2 Schema Server Authority Server di Voto Client di Voto Controllo del voto Analisi dei messaggi scambiati Caratteristiche di programmazione

3 2 specifiche Si richiede un sistema-software per votare elettronicamente che: 1) effettui voto sicuro; 2) permetta a ciascun utente di verificare il suo voto garantendo l anonimato; 3) il voto sia dato ad un referendum (si, no, scheda bianca); 4) il sistema raccolga voti e pubblichi alla fine della votazione una tabella che riporti tutti i voti dati; scenario Il sistema è composto da un client e 3 server : Client di Voto effettua la votazione; Server Authority ha il compito di autenticare l utente e passargli il ticket per effettuare la votaz.; Server di Voto verificare il voto e aggiornare il Database dei votanti; Server Web presentare i risultati su Web; PREMESSE (semplificazioni): 1. Il Client ha la chiave privata installata sul sistema (ma in realtà dovrebbe risiedere su SmartCard); 2. Il Client possiede le chiavi pubbliche del Server Authority e del Server di Voto; 3. Lo scambio dei messaggi è temporizzato, oltre il timeout viene abortita la connessione; 4. Il Certificato è semplificato, costituito solo da : la chiave pubblica (KU) + il digest ( KU ) firmato dalla CA con la sua chiave privata; 5. La CA (Certification Authority) è una classe che implementa 2 funzioni: Creare i certificati delle chiavi pubbliche degli utenti; Verificare la validità di un certificato mediante la chiave pubblica della CA;

4 3 L idea è di fare uso di uno pseudo-kerberos, cioè utilizzare 2 server per separare l autenticazione dalla votazione. La struttura macroscopica è la seguente: (ogni numero rappresenta una fase) 2a. verifica certificato cliente 1. richiesta referendum 2. autenticazione a 3 vie Client di Voto Server Authority CA 4. consegna dei ticket 5. votazione 7. votazione avvenuta 3. richiesta e consegna del ticket per il voto 6. aggiorna la lista votanti Server di Voto / Server sottorete schermata Il Server Authority si occupa prima di autenticare l utente poi di passargli 2 ticket: un Ticket_CA per dimostrare l avvenuta autenticazione (client authority ) un Ticket_CV per effettuare la votazione ( client vote )

5 4 Si è scelto di separare in 2 server questo processo in modo da nascondere l identità dell utente al Server di Voto che si occuperà quindi di reperire le informazioni solo riguardo al voto. L utente in possesso dei 2 ticket può effettuare finalmente la votazione. Il voto viene crittografato utilizzando una chiave di sessione KS ed un terzo ticket: Ticket_CA crittografato con la chiave pubblica del SA in modo da non essere visibile al Server di Voto il quale utilizzerà questo ticket per segnalare al SA l avvenuta votazione. In definitiva il SV non conosce chi ha votato ma cosa ha votato, mentre il SA non conosce cosa ma chi. Se la votazione è andata a buon fine, l utente verrà cancellato dal DataBase del SA e dal DB del SV in modo da impedire una ripetizione della votazione. La segnalazione del successo/insuccesso nella votazione viene fatta attraverso un messaggio dal SV all utente anch esso crittografato con la chiave di sessione KS in modo da e- scludere anche lo spoofing del ok / ko. CONTROLLO DEL VOTO Alla fine della votazione l utente deve poter controllare l avvenuta votazione e riconoscersi in tale. Il Server di Voto calcola il digest di 5 parametri (Marca) : 1. Chiave Pubblica dell utente 2. Il Voto 3. Testo del Referendum 4. ID_client ( un numero casuale assegnato al client ) 5. Cod_ser : codice seriale della scheda elettorale e lo pubblica su Internet affianco al voto utilizzando un server Web. L utente, dopo aver votato, si collega al server Web e controlla che il suo voto confrontando il digest che si è calcolato in locale con quello su Internet. Per aumentare la sicurezza abbiamo creato anche un secondo digest chiamato IAMD. Lo IAMD è un controllo ulteriore basato sull idea della Doppia firma del protocollo SET. IAMD verrà pubblicato sulla pagina Web, accanto alla MARCA corrispondente, utilizzato per riscontrare il voto. ID_Client Cod_ser H H H IAMD

6 5 Caratteristiche crittografiche: Il sistema utilizza crittografia a chiave segreta, a chiave pubblica, certificazione X.509 e SHA512; utilizza Nonce a 32 bit e chiavi di sessione a 128 bit; è resistente ad attacchi di tipo man in the middle e replay ; Analisi dei messaggi scambiati: Fase 1 : richiesta testo referendum (firmato) <testo> KP A [ SHA512( <testo> ) ] Fase 2 : autenticazione a 3 vie KU A [( t 1 C, N 1, UserID C,Psw C,Cert C ) sign_data] - verifica certificato cliente mediante una funzione verifycertificate( Cert C, KU CA ) KU C [( t 1 A, N 2, N 1 +1) sign_data] KU A [( t 2 C, N 2 +1, K CA ) sign_data] Fase 3 : richiesta ticket per il voto SA->SV SV->SA KU SV [( t 3 A, KU C ) sign_data] KU A [( t 4 SV, KU C [ N, Cod_Seriale, KS CV ] ) sign_data] Fase 4 : consegna del ticket Ticket_CV : Cod.Seriale scheda elett. + chiave di sessione + sfida SA->CV KU CA [( t 5 A, <N 3, ID Client >, Ticket_CV ) sign_data] Ticket_CA : Numero Random assegnato all utente + sfida

7 6 Fase 5 : votazione KU V [ N+1 KS CV sign_data] KS CV [( t C 6, voto, Cod_seriale, < KU A [ N 3+1, ID Client ] > ) sign_data ] Ticket_CA : Numero Random assegnato all utente + risposta alla sfida Fase 6 : aggiornamento lista votanti < Ticket_CA > KU V [ t A 7, Ok sign_data] Fase 7 : votazione avvenuta con successo KS CV [ Ok sign_data] Caratteristiche di programmazione: il software è scritto in linguaggio Java. Zona De-militarizzata: Server Authority in ascolto sulla porta 30000; Server di Voto in ascolto sulla porta 30003; Server Web in ascolto sulla porta 80; Sottorete schermata: Server Authority in ascolto sulla porta Server di Voto in ascolto sulla porta 30002

8 7 Caratteristiche di Programmazione Si è creata una libreria TesinaLib.java con le seguenti classi : Classe CA Message KeyGenSim KeySimEncrypt KeySimDecrypt File2Buffer ResumeKeySim ResumeSeed DigestSHA512 SecretKeyGen HMAC ResumeSecretKey Byte2hex GenKeyPairRSA ResumeKeyPairRSA ResumePublicRSA EncryptRSA DecryptRSA DiffieHellman Nonce Timestamp Descrizione Creazione e verifica dei certificati Crea, cripta, decripta, genera la segnature, verifica la segnature dei messaggi Genera chiave simmetrica a 128 bit (AES) Cripta messaggio con AES / CBC Decripta messaggio con AES / CBC Trasforma formato file in byte[] Carica una chiave simmetrica AES Carica l IV per l AES Crea il digest Crea una chiave segreta per un HMAC (specificare l algoritmo) Crea MAC di un oggetto (specificare l algoritmo) Carica chiave segreta per un HMAC Converte una buffer di byte in formato hex Genera una coppia di chiavi pubblica/privata RSA Carica chiave pubblica / privata RSA Carica chiave pubblica RSA Cripta un oggetto con la chiave pubblica o firma un oggetto con la chiave privata Decripta con la chiave privata o verifica la firma digitale di un oggetto Scambio di chiave segreta 512 bit Crea nonce / Risponde alla sfida Crea timestamp / Verifica i timestamp

9 8 una libreria ServerLib.java per i server con le seguenti classi : Classe TerminateServer ServerWeb ServerAutorizzazione ServerVoto ServerVotAut ServerAutVot Descrizione Blocca tutti i server allo scadere del tempo previsto Server in ascolto sulla porta 80 che trasmette i risultati in tempo reale SA su porta (gestisce le transazione dei clienti tramite il Thread CittadinoAutorizzazione ) SV su porta (gestisce le transazione dei clienti tramite il Thread CittadinoVoto ) porta 30002, transazione tra SV e SA ( SV gestisce la transazione con SA tramite il Thread TransactionVotAut ) porta 30001, transazione tra SA e SV ( SV gestisce la transazione con SA tramite il Thread TransactionAutVot )