Ordinanza della CaF
concernente il voto elettronico
(OVE)

(art. 2 cpv. 1 lett. k e 2, 9, 10 cpv. 1 e 2 nonché 16 cpv. 1)

Oltre alle definizioni di cui all’articolo 2, si intende per:

1.1.

tutela del segreto del voto: situazione in cui nessuna persona o componente dispone dei seguenti dati:

1.1.1

voti espressi o dati che permettono di risalire al contenuto dei voti espressi,

1.1.2

dati che permettono di identificare i votanti (dati sugli aventi diritto di voto), e

1.1.3

dati che permettono di associare i dati sugli aventi diritto di voto ai voti espressi;

1.2

esclusione di risultati parziali anticipati: situazione in cui nessuna persona o componente dispone in anticipo dei voti espressi o di dati che permettono di risalire ai voti espressi;

1.3

riferimento di verifica: un documento, inviato assieme al materiale di voto, che permette agli aventi diritto di voto di verificare, secondo l’articolo 5 capoverso 2 in combinato disposto con il numero 2.5 dell’allegato, se il loro voto è stato espresso correttamente (p. es. un elenco in cui a ogni possibilità di risposta è associato un codice);

1.4

aggressore esterno: una persona o un gruppo di persone che non si occupa dello sviluppo e dell’esercizio del sistema, che dispone di risorse e conoscenze specialistiche medie e da cui parte un’aggressione; le sue motivazioni possono comprendere l’attivismo e il profitto finanziario;

1.5

aggressore interno: una persona o un gruppo di persone che partecipa allo sviluppo o all’esercizio del sistema e da cui parte un’aggressione; le sue motivazioni possono comprendere l’attivismo, il profitto finanziario e l’intenzione di danneggiare il proprio datore di lavoro;

1.6

organizzazione nemica:un gruppo di persone che dispone di ampie risorse e di conoscenze specialistiche al di sopra della media e da cui parte un’aggressione; può anche essere sostenuta da uno Stato; tra le sue motivazioni possono esservi l’ottenimento di dati per la profilazione e l’intenzione di disturbare uno scrutinio o di influenzarne i risultati;

1.7

aggressore: una persona, un gruppo di persone o un’organizzazione di cui ai numeri 1.4–1.6;

1.8

urna elettronica:un’area dati in cui i voti espressi possono essere memorizzati fino alla decrittazione e allo spoglio;

1.9

protocollo del sistema: protocollo realizzato dagli elementi dell’infrastruttura per sorvegliare l’esercizio del sistema e indagare sugli incidenti.

2.1

Partecipanti al sistema

Il protocollo crittografico disciplina i compiti dei seguenti partecipanti astratti al sistema:

−

avente diritto di voto / votante

−

piattaforma utente

−

componente di setup

−

sistema non affidabile (qualsiasi componente diversa dalle componenti elencate in questo numero; sistema NA)

−

componente di stampa

−

uno o più gruppi di componenti di controllo

−

verificatori

−

ausilio tecnico dei verificatori

2.2

Canali di comunicazione

Il protocollo crittografico può prevedere i seguenti canali di comunicazione per lo scambio di messaggi tra i partecipanti al sistema:

−

avente diritto di voto / votante ↔ piattaforma utente

−

piattaforma utente ↔ sistema NA

−

componente di setup ↔ sistema NA

−

componente di controllo ↔ sistema NA

−

sistema NA → componente di stampa

−

sistema NA → ausilio tecnico dei verificatori

−

componente di stampa → avente diritto di voto / votante

−

componente di setup → ausilio tecnico dei verificatori

−

verificatori ↔ ausilio tecnico dei verificatori

−

canali bidirezionali per la comunicazione tra le componenti di controllo

2.3

Aggressore

2.3.1

Il protocollo crittografico deve proteggere da un aggressore che tenti di influenzare abusivamente i voti e il risultato, di violare il segreto del voto o di rilevare anticipatamente risultati parziali (n. 2.5–2.8).

2.3.2

Occorre presumere che un aggressore disponga delle seguenti capacità:

−

è in grado di controllare tutti i partecipanti non affidabili al sistema (cfr. n. 2.4) in modo tale che condividano con esso tutti i dati segreti e agiscano illimitatamente secondo le sue istruzioni;

−

è in grado di leggere e sopprimere tutti i messaggi scambiati mediante canali non affidabili e di inserirvi a sua volta messaggi a piacere.

2.4

Partecipanti al sistema e canali di comunicazione affidabili e non affidabili

2.4.1

I partecipanti al sistema e i canali di comunicazione sono considerati «affidabili» o «non affidabili». Le ipotesi di affidabilità ammesse per i singoli partecipanti al sistema sono disciplinate al numero 2.9.

2.4.2

I partecipanti al sistema e i canali di comunicazione affidabili sono considerati protetti contro gli aggressori. Per il protocollo crittografico si possono assumere segnatamente le seguenti ipotesi:

−

I partecipanti al sistema affidabili tengono sotto chiave i dati confidenziali e svolgono esclusivamente le operazioni prescritte dal protocollo crittografico.

−

I canali di comunicazione affidabilitengono sotto chiave i messaggi trasmessi e li proteggono da manipolazioni.

2.5

Requisiti posti al protocollo crittografico: verificabilità individuale

Gli aventi diritto di voto ricevono note di conferma secondo l’articolo 5 capoverso 2 in combinato disposto con l’articolo 6 lettere a e b che confermano che un aggressore:

−

prima della registrazione come voto espresso conformemente al sistema, non ha modificato o sottratto alcun voto parziale dell’avente diritto di voto;

−

non ha espresso abusivamente a nome dell’avente diritto alcun voto successivamente registrato e conteggiato quale voto espresso conformemente al sistema.

2.6

Requisiti posti al protocollo crittografico: verificabilità universale

I verificatori ricevono note di conferma secondo l’articolo 5 capoverso 3 lettera a in combinato disposto con l’articolo 6 lettere a e c che confermano che un aggressore:

−

dopo che i voti sono stati registrati quali voti espressi conformemente al sistema, non ha modificato o sottratto alcun voto parziale fino al calcolo del risultato;

−

non ha inserito alcun voto o voto parziale non espresso conformemente al sistema che sia stato considerato nel calcolare il risultato.

2.7

Requisiti posti al protocollo crittografico: tutela del segreto del voto ed esclusione di risultati parziali anticipati

2.7.1

Deve essere garantito che un aggressore non possa né violare il segreto del voto né rilevare anticipatamente risultati parziali senza porre inoltre sotto il proprio controllo gli aventi diritto di voto o le loro piattaforme utente.

2.7.2

Non vi è alcun obbligo di impedire aggressioni mediante le quali il numero dei voti conteggiati è limitato in modo tale che tutti i voti parziali per un oggetto in votazione, una lista o un candidato siano dello stesso tenore.

2.7.3

Deve essere garantito che un aggressore non possa porre di nascosto sotto il proprio controllo le piattaforme utente manipolando sul server il software per le piattaforme utente. I votanti devono avere la possibilità di verificare se la loro piattaforma utente ha ricevuto dal server il software corretto con i parametri corretti, in particolare con la chiave pubblica per crittare il voto.

2.8

Requisiti posti al protocollo crittografico: autenticazione efficace

Deve essere garantito che un aggressore non possaesprimere un voto conformemente al sistema senza porre sotto il proprio controllo i corrispondenti aventi diritto di voto.

2.9

Elenco dei partecipanti al sistema affidabili e non affidabili

2.9.1

Per la validità delle note di conferma secondo il numero 2.5

2.9.1.1

I seguenti partecipanti al sistema sono considerati non affidabili:

−

piattaforma utente

−

sistema NA

−

tre delle quattro componenti di controllo per ciascun gruppo, fermo restando che le tre componenti non vanno designate

−

una quota significativa di aventi diritto di voto

−

verificatori

−

ausili tecnici dei verificatori

2.9.1.2

I seguenti partecipanti al sistema possono essere considerati affidabili:

−

componente di setup

−

componente di stampa

−

una delle quattro componenti di controllo per ciascun gruppo, fermo restando che la componente non va designata

2.9.2

Per la validità delle note di conferma secondo il numero 2.6

2.9.2.1

I seguenti partecipanti al sistema sono considerati non affidabili:

−

piattaforma utente

−

sistema NA

−

tre delle quattro componenti di controllo per ciascun gruppo, fermo restando che le tre componenti non vanno designate

−

una quota significativa di aventi diritto di voto

−

componente di setup

−

componente di stampa

2.9.2.2

I seguenti partecipanti al sistema possono essere considerati affidabili:

−

una delle quattro componenti di controllo per ciascun gruppo, fermo restando che la componente non va designata

−

un verificatore di un gruppo, fermo restando che il verificatore non va designato

−

un ausilio tecnico di un verificatore affidabile, fermo restando che l’ausilio tecnico non va designato

2.9.3

Per la tutela del segreto del voto e l’esclusione di risultati parziali anticipati secondo il numero 2.7

2.9.3.1

I seguenti partecipanti al sistema sono considerati non affidabili:

−

sistema NA

−

tre delle quattro componenti di controllo per ciascun gruppo, fermo restando che le tre componenti non vanno designate

−

una quota significativa di aventi diritto di voto

−

verificatori

−

ausili tecnici dei verificatori

2.9.3.2

I seguenti partecipanti al sistema possono essere considerati affidabili:

−

componente di setup

−

componente di stampa

−

piattaforma utente

−

una delle quattro componenti di controllo per ciascun gruppo, fermo restando che la componente non va designata

2.9.3.3

Se un gruppo completo di componenti di controllo viene impiegato presso un gestore privato del sistema, nessuna di tali componenti di controllo è considerata affidabile.

2.9.4

Per l’efficacia dell’autenticazione secondo il numero 2.8

2.9.4.1

I seguenti partecipanti al sistema sono considerati non affidabili:

−

sistema NA

−

tre delle quattro componenti di controllo per ciascun gruppo, fermo restando che le tre componenti non vanno designate

−

una quota significativa di aventi diritto di voto

−

verificatori

−

ausili tecnici dei verificatori

−

piattaforma utente

2.9.4.2

I seguenti partecipanti al sistema possono essere considerati affidabili:

−

componente di setup

−

componente di stampa

−

una delle quattro componenti di controllo per ciascun gruppo, fermo restando che la componente non va designata

2.10

Elenco dei canali di comunicazione affidabili e non affidabili

2.10.1

I seguenti canali di comunicazione sono considerati non affidabili:

−

piattaforma utente ↔ sistema NA

−

componente di setup ↔ sistema NA

−

componente di controllo ↔ sistema NA

−

sistema NA → componente di stampa

−

sistema NA → ausilio tecnico dei verificatori

−

canali bidirezionali per la comunicazione tra le componenti di controllo

2.10.2

I seguenti canali di comunicazione possono essere considerati affidabili:

−

avente diritto di voto / votante ↔ piattaforma utente

−

ausilio tecnico dei verificatori ↔ verificatori

−

componente di setup → ausilio tecnico dei verificatori

−

componente di stampa → avente diritto di voto / votante

2.11

Requisiti supplementari posti alla validità delle note di conferma

2.11.1

La probabilità che un aggressore possa falsificare una nota di conferma secondo il numero 2.5 quando modifica un voto parziale, sottrae un voto parziale o esprime un voto a nome d’altri può essere al massimo dello 0,1 per cento.

2.11.2

La probabilità che un aggressore possa falsificare una nota di conferma secondo il numero 2.6 quando fa in modo, modificando e sottraendo voti espressi conformemente al sistema e inserendo voti non espressi conformemente al sistema, che il risultato calcolato diverga dello 0,1 per cento dal risultato corretto può essere al massimo dell’1 per cento per ogni oggetto in votazione, elezione di lista o elezione di candidati.

2.11.3

Se la probabilità che un aggressore possa falsificare una nota di conferma secondo il numero 2.6 non è trascurabile in senso crittografico³, la probabilità di successo deve poter essere ridotta a piacere mediante uno spoglio ripetuto e facendo in modo che i verificatori ricevano per ogni spoglio una nota di conferma secondo il numero 2.6 supplementare e indipendente.

2.12

Requisiti funzionali posti al processo dell’espressione del voto con ripercussioni sul protocollo crittografico

2.12.1

Con le caratteristiche di autenticazione attribuite a un avente diritto di voto può essere espresso un solo voto.

2.12.2

Il votante immette il proprio voto nella piattaforma utente.

2.12.3

Fino al momento in cui dichiara la volontà di esprimere il proprio voto, il votante può modificarlo e verificarlo mediante una panoramica.

2.12.4

Dopo aver avuto la possibilità di verificare il voto mediante la panoramica, il votante dichiara sulla piattaforma utente di voler esprimere il voto nella forma immessa.

2.12.5

Le note di conferma per la corretta espressione del voto secondo il numero 2.5 devono essere strutturate in almeno due note di conferma parziali e sequenziali. Ogni visualizzazione rappresentata quale nota di conferma parziale deve rappresentare un autentico contributo alla validità della nota di conferma secondo il numero 2.5.

2.12.6

La piattaforma utente visualizza al votante la prima nota di conferma parziale dopo che esso ha dichiarato sulla piattaforma utente di voler esprimere il voto.

2.12.7

La piattaforma utente visualizza al votante la successiva nota di conferma parziale soltanto dopo che esso ha confermato, mediante una dichiarazione sulla piattaforma utente, la correttezza della nota di conferma parziale precedente.

2.12.8

Confermando la correttezza della penultima nota di conferma parziale, il votante dichiara la volontà di esprimere il voto definitivamente.

2.12.9

Il gruppo di componenti di controllo registra il voto come espresso conformemente al sistema se ha ricevuto la conferma che il votante vuole esprimere il voto definitivamente.

2.12.10

Se il votante ha verificato l’ultima nota di conferma parziale con esito positivo, l’espressione del voto è conclusa. L’ultima nota di conferma parziale deve poter essere verificata in modo particolarmente facile limitando possibilmente la verifica alla corretta visualizzazione di un unico codice o a un’altra visualizzazione semplice.

2.12.11

A partire dal momento in cui si importano dati sul voto, una componente di setup o una componente di stampa non è più considerata affidabile.

2.13

Requisiti posti alla definizione e alla descrizione del protocollo crittografico

2.13.1

Se possibile si usano elementi crittografici diffusi a livello mondiale e verificati approfonditamente da persone competenti. A titolo di orientamento si può ricorrere a standard, progetti di riferimento e pubblicazioni scientifiche. Le deroghe e i casi dubbi vanno trattati separatamente nel quadro dell’analisi dei rischi di cui all’articolo 4.

2.13.2

Le istruzioni operative devono essere sufficientemente specificate: le singole istruzioni operative devono limitare le possibilità attuative in misura tale che ogni attuazione consentita dall’istruzione sia pure conforme all’adempimento dei requisiti posti al protocollo crittografico.

2.13.3

I canali affidabili possono essere utilizzati per la distribuzione di certificati elettronici tra i partecipanti al sistema. Si applica il numero 3.8.

2.14

Note di conformità sull’adempimento dei requisiti posti al protocollo crittografico

2.14.1

Una nota di conformità simbolica e una nota di conformità crittografica devono attestare che il protocollo crittografico adempie i requisiti di cui ai numeri 2.1–2.12.

2.14.2

Le note di conformità devono riferirsi direttamente alla descrizione del protocollo che serve da base per lo sviluppo del sistema.

2.14.3

Riguardo alle componenti di base crittografiche, le note di conformità possono essere designate quali ipotesi e costruzioni di sicurezza generalmente riconosciute (p. es. «random oracle model», «decisional Diffie-Hellman assumption», «Fiat-Shamir heuristic»).

3.1

L’esercizio della componente di setup e di almeno una componente di controllo del gruppo che comprende una parte della chiave per la decrittazione dei voti rientra nella competenza diretta del Cantone e deve svolgersi nella sua infrastruttura. Lo scorporo a un gestore privato del sistema non è ammesso.

3.2

Per la scelta di valori aleatori segnatamente per le componenti di setup e le componenti di controllo deve essere garantito l’impiego di una sufficiente entropia.

3.3

I verificatori devono verificare almeno una volta le note di conferma secondo il numero 2.6 e utilizzare a tale scopo un ausilio tecnico secondo il numero 2.

3.4

I requisiti d’esercizio posti alle componenti di setup secondo il numero 3 valgono anche per gli ausili tecnici dei verificatori. Nei limiti della loro responsabilità, stabilita dal diritto cantonale, i verificatori possono prevedere deroghe.

3.5

Eccezion fatta per le componenti menzionate ai numeri 3.1 e 3.3, il Cantone può delegare l’esercizio di qualsiasi parte del sistema, comprese le componenti di controllo e la componente di stampa, a fornitori di servizi privati. Un gestore privato della componente di stampa può svolgere esclusivamente compiti d’esercizio che costituiscono una premessa per la preparazione, l’imballaggio e l’invio.

3.6

Le componenti affidabili (componenti di setup, componenti di stampa, ausili tecnici dei verificatori e componenti di controllo) vanno realizzate, aggiornate, configurate e assicurate in un processo osservabile.

3.7

Prima dell’installazione di un software occorre verificare per tutti i programmi, mediante una base ufficiale affidabile, se i file corrispondono alla versione corretta e autentica.

3.8

Nell’installazione di certificati elettronici di altri partecipanti al sistema l’autenticità deve essere garantita. A tal proposito occorre predisporre un processo manuale secondo cui le persone portano i certificati elettronici da una macchina all’altra mediante un supporto di dati fisico secondo il numero 3.13.

3.9

Il momento dell’aggiornamento di tutto il software delle componenti affidabili va scelto in modo tale che i vantaggi attesi dall’aggiornamento prevalgano sui possibili pericoli.

3.10

Le componenti di setup, le componenti di stampa e gli ausili tecnici dei verificatori che, in qualsivoglia forma, partecipano al trattamento di dati critici devono essere sorvegliati fisicamente, secondo il principio del doppio controllo, durante l’intero periodo di calcolo e fino alla cancellazione di eventuali dati critici o alla conservazione sicura. Possono essere collegati tra di loro tutt’al più mediante cavi fisici, affinché, per quanto possibile, sia evidente che nessun altro macchinario possa accedervi fino alla distruzione dei dati confidenziali.

3.11

Per l’installazione o l’aggiornamento del software le componenti affidabili non devono essere collegate a Internet.

3.12

In linea di principio i dati critici devono essere distrutti dopo il loro utilizzo. In alternativa, se vi sono motivi validi, è ammessa una conservazione sicura del supporto di dati.

3.13

I supporti di dati per lo scambio o la conservazione dei dati, ad esempio le chiavette USB, devono essere rimossi dopo il caricamento dei dati nella componente affidabile e possono essere riutilizzati prima della distruzione dei dati soltanto se prima del caricamento dei dati non si trovavano dati critici sulla componente affidabile.

Prima del loro utilizzo, i supporti di dati per lo scambio dei dati devono essere riformattati con l’aiuto di una componente gestita conformemente ai requisiti posti alle componenti affidabili; eventuali dati presenti sul supporto devono essere distrutti.

3.14

Non deve essere possibile alcun accesso logico o fisico a componenti affidabili o a supporti di dati contenenti dati critici senza che un’altra persona se ne accorga; ad esempio, un’altra persona deve partecipare alla concessione dell’accesso (applicazione rigorosa del principio del doppio controllo).

3.15

Un accesso non autorizzato ma andato a buon fine a una componente di controllo non deve possibilmente procurare alcun vantaggio nel tentativo di accedere di nascosto a un’altra componente di controllo. Oltre agli altri requisiti di cui al numero 3, vanno adempiuti a tale scopo i seguenti requisiti:

−

una persona che ha un accesso fisico o logico a una componente di controllo non deve avere accesso a un’altra componente di controllo;

−

l’hardware, i sistemi operativi e i sistemi di sorveglianza delle componenti di controllo devono per quanto possibile differenziarsi;

−

le componenti di controllo devono essere collegate a reti locali differenti;

−

una componente di controllo deve essere realizzata mediate un apparecchio fisico. Non è ammessa la virtualizzazione mediante più apparecchi fisici.

3.16

Le componenti di controllo devono essere tali da riconoscere gli accessi non autorizzati e allarmare le persone responsabili. Queste ultime devono prevedere misure di sorveglianza esterne quali la sorveglianza e un protocollo resistente alle manipolazioni del traffico di rete o la sorveglianza fisica con telecamere sottoposte al loro controllo. Le persone responsabili devono essere considerate particolarmente affidabili e degne di fiducia.

3.17

Le componenti affidabili possono eseguire esclusivamente le operazioni previste.

3.18

Il software dell’ausilio tecnico dei verificatori deve essere acquistato presso uno sviluppatore di sistema diverso da quello che ha sviluppato la maggior parte del software degli altri elementi del sistema. La pubblicazione del software dell’ausilio tecnico al beneficio di una licenza che adempie i criteri applicabili ai programmi Open Source⁴ può motivare un’eccezione. Se i verificatori impiegano più ausili tecnici, la presente disposizione si applica ad almeno uno degli ausili tecnici.

3.19

Per tutti i processi legati all’utilizzazione di componenti affidabili deve essere elaborata una documentazione scritta e facilmente comprensibile per le persone interessate.

3.20

Di ogni accesso e utilizzazione di una componente affidabile o di un supporto di dati contenente dati critici deve essere realizzato un protocollo.

4.1

I votanti dichiarano di aver preso atto delle regole del voto elettronico e della propria responsabilità.

4.2

Prima di esprimere il voto i votanti sono resi attenti sul fatto che, trasmettendo i loro voti elettronici, partecipano allo scrutinio come se esprimessero il voto per corrispondenza o di persona all’urna. I votanti possono esprimere il proprio voto soltanto dopo aver confermato che hanno preso atto di quanto precede.

4.3

Al momento di esprimere il voto i votanti sono invitati a verificare le note di conferma secondo il numero 2.5 mediante il riferimento di autenticazione e di segnalare al Cantone eventuali dubbi sulla loro correttezza.

4.4

Prima dell’espressione definitiva del voto elettronico gli aventi diritto possono ancora esprimere il proprio voto attraverso un canale di voto convenzionale.

4.5

Il sistema client quale si presenta ai votanti non influenza le loro scelte.

4.6

Le istruzioni fornite agli utenti non inducono a votare in modo precipitoso o senza riflettere.

4.7

Il sistema non offre ai votanti alcuna funzione che permetta di stampare o memorizzare il proprio voto.

4.8

Dopo l’espressione del voto, ai votanti non è visualizzata alcuna informazione sul voto crittato da loro espresso.

4.9

Nel caso degli aventi diritto di voto che non possono esprimere un voto perché terzi lo esprimono utilizzando abusivamente il loro materiale di voto, i Cantoni possono ancora permettere l’espressione del voto dichiarando nullo il voto espresso abusivamente. La tutela del voto secondo il numero 2.7 va tutelata.

4.10

Si possono prevedere agevolazioni per permettere agli aventi diritto di voto disabili di verificare la nota di conferma. Soltanto in un simile caso è possibile derogare ai requisiti di cui al numero 2.9.1.

4.11

Fintanto che il sistema non ha registrato alcuna conferma dell’espressione definitiva del voto elettronico, gli aventi diritto possono ancora esprimere il proprio voto attraverso un canale di voto convenzionale.

4.12

È permesso utilizzare un mezzo di autenticazione indipendente dal voto elettronico. Nell’ambito dell’analisi dei rischi occorre valutare approfonditamente le ripercussioni sull’integrità della verifica del diritto di voto e la tutela del segreto del voto.

5.1

Se dati riguardanti il catalogo elettorale vengono importati da un sistema terzo che non è sotto il controllo del Cantone, i dati devono essere crittati e firmati. La firma deve essere verificata al momento del ricevimento di tali dati. Per l’invio alla tipografia prevalgono le disposizioni di cui al numero 7.

5.2

I dati necessari per la verifica delle note di conferma secondo il numero 2.6 vengono consegnati ai verificatori.

6.1

Le carte di legittimazione di voto devono per quanto possibile essere concepite in modo tale da garantire agli aventi diritto di voto disabili un accesso senza barriere al voto elettronico.

6.2

Gli elementi di sicurezza presenti sulla carta di legittimazione di voto (p. es. campo con patina da grattare) possono essere utilizzati soltanto se è dimostrato che l’informazione coperta è ben protetta contro la lettura non autorizzata.

6.3

Se si rinuncia all’utilizzazione di elementi di sicurezza volti a proteggere le informazioni confidenziali presenti sulla carta di legittimazione di voto, devono essere disponibili processi organizzativi che garantiscano la sicurezza.

7.1

I dati di stampa per la produzione delle carte di legittimazione di voto sono inviati in forma crittata e con la firma. In alternativa è anche possibile consegnare personalmente un supporto dati contenente i dati di stampa. In tal caso il supporto dati è trasportato e consegnato alla tipografia da due persone che assieme lo sorvegliano (principio del doppio controllo).

7.2

Il crittaggio deve soddisfare i requisiti dello standard eCH-0014⁵, capitolo 7.5. In caso di crittografia simmetrica l’elemento segreto necessario per la decrittazione viene inviato ai responsabili della tipografia usando una via parallela sicura.

7.3

I responsabili della tipografia che prendono in consegna il supporto di dati firmano una ricevuta.

7.4

Ai supporti di dati contenenti i dati di stampa, alle componenti su cui vengono decrittati i dati critici e a tutte le componenti che trattano i dati critici si applicano le disposizioni di cui al numero 3 concernenti la componente di stampa.

7.5

I responsabili della tipografia eseguono un controllo delle quantità di materiale.

7.6

Dopo la stampa delle carte di legittimazione di voto la tipografia distrugge i dati ricevuti.

7.7

Se la tipografia si occupa anche dell’imballaggio e dell’invio delle carte di legittimazione di voto, queste ultime vanno imballate assieme al materiale di voto immediatamente dopo la stampa.

7.8

Il canale tra la tipografia e gli aventi diritto di voto può essere considerato affidabile soltanto se gli organi competenti secondo il diritto cantonale inviano per corrispondenza il materiale di voto imballato agli aventi diritto di voto oppure se assicurano la consegna di persona.

8.1

L’organo responsabile a livello cantonale elabora un piano per informare i cittadini sul voto elettronico.

8.2

Il piano garantisce che le informazioni siano autorizzate dagli organi competenti.

8.3

Su Internet sono disponibili consigli e istruzioni sull’espressione del voto e informazioni riguardanti la responsabilità degli aventi diritto di voto. Si evita così che essi agiscano in modo precipitoso o senza riflettere.

8.4

Agli aventi diritto di voto sono illustrate in maniera accessibile la verificabilità, altre misure di sicurezza e il modo di procedere previsto in caso di anomalie.

8.5

Agli aventi diritto di voto vengono illustrati gli aspetti a cui devono prestare attenzione affinché possano esprimere il loro voto in tutta sicurezza.

8.6

Agli aventi diritto di voto viene spiegato in che modo si può cancellare il voto, una volta espresso, da tutte le memorie della piattaforma utente che essi hanno utilizzato per votare.

8.7

In caso di domande sul voto elettronico gli aventi diritto di voto possono chiedere assistenza.

8.8

Gli aventi diritto di voto sono invitati a segnalare all’organo responsabile a livello cantonale le note di conferma secondo il numero 2.5 visualizzate in modo errato, come il codice di verifica, e altre verifiche dall’esito negativo. Questo invito è diffuso anche contestualmente all’invio del materiale di voto.

8.9

Gli aventi diritto di voto sono invitati a tenere sotto chiave il materiale di voto con gli elementi di sicurezza forniti in adempimento del numero 2.5 fino all’espressione definitiva del voto o alla conclusione dello scrutinio.

8.10

Gli aventi diritto di voto ricevono le indicazioni necessarie per controllare l’autenticità del sito Internet utilizzato per esprimere il voto, del server e del software. L’attendibilità di un controllo efficace deve essere supportata dall’impiego di mezzi crittografici in conformità con le migliori prassi.

8.11

Le informazioni essenziali per l’espressione sicura del voto vengono inviate assieme al materiale di voto. Agli aventi diritto di voto viene spiegato che in caso di dubbio devono attenersi alle informazioni contenute nel materiale di voto e non alle informazioni visualizzate sulla piattaforma utente.

8.12

Agli aventi diritto di voto viene spiegato con quali provvedimenti è garantita la tutela del segreto del voto.

8.13

Le lacune note e la relativa necessità di agire vengono comunicate in modo trasparente.

8.14

I verificatori vengono informati e istruiti adeguatamente riguardo ai processi cui sono soggetti la correttezza del risultato, la tutela del segreto del voto e l’esclusione di risultati parziali anticipati (p. es. generazione di chiavi, stampa del materiale di voto, decrittazione e spoglio). Essi sono in grado di capire i punti centrali dei processi e il loro significato.

Il canale di voto elettronico è a disposizione soltanto nel periodo ammesso.

Un voto espresso in modo non conforme al sistema non è depositato nell’urna elettronica.

11.1

La decrittazione dei voti e il loro spoglio possono avere inizio al più presto la domenica della votazione o dell’elezione.

11.2

Il Cantone esegue la decrittazione e lo spoglio nella propria infrastruttura.

11.3

Il Cantone provvede alla stesura di un protocollo sulla procedura di decrittazione dei voti e sul loro spoglio. L’organo responsabile a livello cantonale approva il protocollo.

11.4

Dalla decrittazione dei voti fino alla trasmissione del risultato dello scrutinio ogni accesso al sistema o a una delle sue componenti è effettuato da almeno due persone congiuntamente; esso è registrato per scritto e deve poter essere controllato dai verificatori.

11.5

Se i dati riguardanti il risultato vengono trasmessi a un sistema terzo che non è sotto il controllo del Cantone, i dati vengono crittati e firmati.

11.6

Il sistema permette di constatare, per mezzo della carta di legittimazione di voto, se qualcuno ha espresso un voto elettronico.

11.7

La decrittazione e lo spoglio dei voti si svolgono in presenza di verificatori. I Cantoni possono in aggiunta consentire lavori di verifica da remoto.

11.8

Alle componenti utilizzate per lo spoglio dei voti che non sono affidabili secondo il numero 2.4 sono posti gli stessi requisiti validi per le componenti di setup secondo il numero 3.

11.9

Nel verificare le note di conferma secondo il numero 2.6 i verificatori si assumono la loro responsabilità definita dal diritto cantonale.

11.10

L’organo responsabile a livello cantonale sottopone ai verificatori tutti gli indicatori rilevanti per la correttezza del risultato. Oltre alle note di conferma secondo il numero 2.6, vi figurano in particolare il numero e il tipo di anomalie che gli aventi diritto di voto hanno segnalato al Cantone.

11.11

Il Cantone anticipa eventuali anomalie e a tale scopo elabora, d’intesa con gli organi interessati, un piano d’emergenza che stabilisce il modo di procedere nei casi specifici. Garantisce la trasparenza nei confronti del pubblico.

11.12

Se sono disponibili e sempre che la base di dati lo consenta, per accertare la plausibilità del risultato vanno impiegati metodi statistici.

12.1

Occorre assicurare che né collaboratori né persone esterne conoscano dati che permettono di stabilire un legame fra l’identità di un votante e il voto che ha espresso.

12.2

Occorre assicurare che prima della decrittazione dei voti né collaboratori né persone esterne conoscano dati che permettono di rilevare anticipatamente risultati parziali.

12.3

Il Cantone non deve inoltrare a imprese private la sua parte della chiave per la decrittazione dei voti di cui dispone, secondo il numero 3.1, sulla componente di controllo da esso gestita.

12.4

Il Cantone tratta in modo confidenziale i risultati dello scrutinio fra il momento della decrittazione dei voti e il momento della loro pubblicazione.

12.5

Il Cantone provvede affinché i dati che permettono di constatare che gli aventi diritto di voto hanno votato per via elettronica siano trattati in modo confidenziale.

12.6

Il Cantone tratta in modo confidenziale i singoli voti dopo lo spoglio.

12.7

Il Cantone provvede affinché i risultati della votazione o dell’elezione di circondari elettorali più piccoli siano trattati in modo confidenziale.

12.8

Dopo l’omologazione vengono distrutti, secondo una procedura prestabilita e documentata, tutti i dati creati nell’ambito dello scrutinio elettronico, relazionati con i singoli voti immessi e classificati come confidenziali.

13.1

Le minacce elencate ai numeri 13.3–13.40 sono di natura generale e costituiscono una base da integrare. Esse si riferiscono agli obiettivi di sicurezza e vanno considerate nell’ambito dell’identificazione dei rischi. A seconda dei punti deboli accertati nel sistema, nelle analisi dei rischi dei diversi organi l’elenco va concretizzato e integrato in funzione della costellazione concreta e a dipendenza della minaccia specifica.

13.2

Sono considerate possibili minacce:

−

le minacce, provocate inavvertitamente o intenzionalmente, che partono da attori interni o esterni che impiegano mezzi elettronici o fisici;

−

le minacce riconducibili a una disfunzione del sistema o degli elementi che lo supportano.

14.1

Un sistema di monitoraggio dell’infrastruttura riconosce gli incidenti che potrebbero mettere in pericolo la sicurezza, inclusa la disponibilità, del sistema e allarma il personale preposto, che li gestisce in conformità con procedure predefinite. Scenari di crisi e piani di salvataggio servono da linea direttrice (ivi compreso un piano che garantisca lo svolgimento delle attività relative agli scrutini) e si applicano in caso di necessità.

Errori nella registrazione del voto nelle componenti di controllo e nell’urna devono essere riconosciuti. Ulteriori informazioni relative all’errore devono essere disponibili, in modo da riconoscere ed eliminare la causa. Gli incidenti constatati devono essere notificati all’organo responsabile a livello cantonale.

14.2

Sull’infrastruttura sono redatti protocolli la cui raccolta, trasmissione e memorizzazione sono resistenti alle manipolazioni (protocolli del sistema). I protocolli sono coerenti fra loro e permettono il tracciamento degli eventi pertinenti nell’ambito dell’investigazione di presunte manipolazioni o di errori. Essi servono da attestati per la presa in considerazione completa, non falsificata ed esclusiva di voti espressi conformemente al sistema, nonché per la tutela del segreto del voto e l’esclusione di risultati parziali anticipati.

Il contenuto dei protocolli comprende almeno gli eventi seguenti:

−

avvio e conclusione dei processi di audit, di identificazione e di autenticazione

−

avvio, riavvio e conclusione della fase di voto o elezione

−

avvio dello spoglio con accertamento del risultato

−

esecuzione e risultati di eventuali autotest

−

disfunzioni constatate negli elementi dell’infrastruttura informatica che compromettono la capacità operativa

Di ogni evento viene documentata la data e l’ora, il tipo di evento, il possibile autore e il risultato, in termini di successo o di insuccesso.

I protocolli del sistema vengono messi a disposizione dell’organo responsabile a livello cantonale in una forma che gli permetta di interpretarne le informazioni.

14.3

Il monitoraggio e la redazione dei protocolli del sistema sottostanno a un continuo processo di miglioramento. Tale processo comprende un dialogo aperto fra gli attori coinvolti nonché una valutazione obiettiva periodica dell’efficacia degli strumenti e dei processi adottati. I risultati di queste valutazioni sono tenuti in considerazione.

14.4

Il monitoraggio e la redazione dei protocolli del sistema non compromettono in alcun modo l’efficacia delle misure adottate per tutelare il segreto del voto.

14.5

È garantito che, in caso di guasto, i voti e i dati a comprova di un funzionamento ineccepibile della procedura di spoglio dei voti vengono memorizzati in modo integro sull’infrastruttura.

14.6

Dopo un guasto al sistema o un’interruzione dei supporti di comunicazione o di memorizzazione, il sistema è posto in una modalità di manutenzione in cui esiste la possibilità di ritornare a uno stato sicuro. Le procedure di voto già avviate vengono interrotte. Il votante può riprendere a votare soltanto quando il sistema è tornato a uno stato sicuro.

14.7

Con l’ausilio di caratteristiche di autenticazione è possibile esprimere voti di controllo non attribuiti ad alcun avente diritto di voto. Il contenuto di questi voti di controllo è iscritto in un protocollo. Il conteggio dei voti di controllo viene confrontato con i protocolli.

È garantito che i voti di controllo sono trattati quanto più possibile alla stregua di voti espressi conformemente al sistema; nel contempo è garantito che non vengono conteggiati.

14.8

La disponibilità dell’infrastruttura viene verificata e iscritta in un protocollo a intervalli di tempo prestabiliti.

14.9

Mediante un processo predefinito e documentato, tutte le parti del sistema vengono regolarmente aggiornate, in modo da eliminare punti deboli di cui si è venuti a conoscenza.

14.10

Le misure di monitoraggio e di protocollo relative all’utilizzo del sistema, alle attività degli amministratori e ai guasti vengono descritte in dettaglio, attuate, sorvegliate e verificate.

15.1

I certificati elettronici sono amministrati secondo le migliori prassi.

15.2

Per assicurare l’integrità delle serie di dati su cui si basano la correttezza del risultato nonché la segretezza di dati critici, inclusi i dati di identificazione e di autenticazione delle autorità, sono impiegate misure crittografiche efficaci, conformi allo stato della tecnica.

15.3

Per assicurare la segretezza di dati critici sono impiegate nell’infrastruttura misure crittografiche efficaci, conformi allo stato della tecnica. Questi dati vengono sempre memorizzati sui supporti di dati in modo crittato.

15.4

Le componenti di base crittografiche vengono utilizzate solamente se le lunghezze delle chiavi e gli algoritmi sono conformi agli standard correnti (p. es. NIST, ECRYPT, FiEle). La firma elettronica soddisfa i requisiti posti a una firma elettronica avanzata ai sensi della legge del 18 marzo 2016¹⁰ sulla firma elettronica (FiEle). La verifica della firma avviene mediante un certificato elettronico rilasciato da un prestatore di servizi di certificazione riconosciuto ai sensi della FiEle.

16.1

Tutte le componenti dell’infrastruttura sono gestite in una zona di rete separata. La zona viene protetta mediante un adeguato controllo dell’instra­damento.

16.2

Il voto elettronico è di principio chiaramente separato da tutte le altre applicazioni.

17.1

Le funzioni rilevanti per la sicurezza del sistema (funzioni di sicurezza) vengono testate. I test vengono documentati con piani di test e con i risultati attesi dai test e i risultati effettivi.

Il piano di test:

−

stabilisce quali sono i test da eseguire;

−

descrive gli scenari di ciascun test, comprese eventuali dipendenze dai risultati di altri test.

I risultati attesi devono indicare i risultati che ci si attende da una esecuzione riuscita dei test.

I risultati effettivi devono essere coerenti con i risultati attesi.

17.2

Viene eseguita un’analisi della copertura dei test. Essa comprende la prova che:

−

i test definiti nella documentazione di test sono coerenti con le specifiche funzionali delle interfacce;

−

tutte le interfacce sono state completamente testate.

17.3

Viene eseguita un’analisi della profondità dei test. Essa comprende la prova che:

−

i test definiti nella documentazione di test sono coerenti con i sottosistemi relativi alle funzioni di sicurezza e ai moduli che hanno un ruolo nel garantire la sicurezza;

−

tutti i sottosistemi relativi alle funzioni di sicurezza identificate nelle specifiche sono stati testati;

−

tutti moduli che hanno un ruolo nel garantire la sicurezza sono stati testati.

18.1

Tutti i ruoli e tutte le responsabilità per l’esercizio del sistema sono definiti con precisione, attribuiti e comunicati.

18.2

La configurazione iniziale dell’infrastruttura, per quanto riguarda l’hardware, il software e i diritti d’accesso, e ogni modifica devono essere autorizzate.

18.3

I rischi connessi con terzi (mandatari come fornitori e prestatori di servizi) sono identificati e ridotti nella misura del necessario per il tramite di adeguati accordi contrattuali. Il rispetto degli accordi viene sorvegliato e verificato adeguatamente durante la loro validità.

19.1

Tutte le risorse immateriali e materiali ai sensi della nozione di asset contenuta nella norma ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements¹¹, rilevanti per il voto elettronico (organizzazione globale, in particolare i processi organizzativi e le informazioni in quanto tali che vi sono trattate, i supporti di dati, le installazioni per il trattamento delle informazioni dell’infrastruttura e i locali dell’infrastruttura) vengono rilevati in un inventario. È allestito un elenco del personale. L’inventario e l’elenco del personale devono essere tenuti aggiornati. Ad ogni risorsa immateriale e materiale è attribuita una persona che ne assume la responsabilità.

19.2

Viene definito l’uso ammesso di risorse immateriali e materiali.

19.3

Per le informazioni sono emanate e comunicate linee direttrici in materia di classificazione.

19.4

Per la caratterizzazione e l’utilizzazione di informazioni sono approntate delle procedure.

20.1

Per garantire l’affidabilità del personale prima, durante e dopo la sua assunzione o in caso di cambiamenti di ruolo sono approntate e comunicate direttive e procedure adeguate.

20.2

I responsabili del personale si assumono la piena responsabilità delle misure volte a garantire l’affidabilità del personale.

20.3

Il personale dispone di una spiccata sensibilità in materia di sicurezza dell’informazione. A questo scopo è approntato e gestito un programma di formazione e di esercitazione conforme ai compiti da svolgere.

21.1

I perimetri di sicurezza dei diversi locali dell’infrastruttura sono definiti in modo chiaro.

21.2

Per l’accesso fisico ai diversi locali dell’infrastruttura le autorizzazioni d’accesso sono definite, introdotte e controllate adeguatamente.

21.3

Per garantire la sicurezza degli apparecchi dentro e fuori i locali dell’infrastruttura sono definite direttive e procedure adeguate, di cui viene sorvegliato e verificato il rispetto.

21.4

Tutti i dati sono trattati, e in particolare conservati, esclusivamente in Svizzera.

22.1

Gli obblighi e gli ambiti di responsabilità sono suddivisi in modo tale che i rischi imputabili alle persone correlati con l’esercizio e la comunicazione siano ridotti a rischi residui compatibili con i criteri di accettazione del rischio.

22.2

Per proteggersi da software nocivi vengono adottate misure adeguate.

22.3

È allestito e attuato un piano dettagliato per la sicurezza dei dati. Il corretto funzionamento della sicurezza dei dati è verificato periodicamente.

22.4

Sono definite e attuate misure adeguate per la protezione della rete da minacce evidenziate dall’analisi dei rischi secondo l’articolo 4 in combinato disposto con il numero 13 e per la sicurezza dei servizi di rete.

22.5

Le procedure per gestire i supporti amovibili di dati e per smaltire i supporti di dati sono disciplinate in modo dettagliato.

23.1

È garantito che durante lo scrutinio ogni modifica successiva dei diritti di accesso e d’intervento avvenga esclusivamente con il consenso dell’organo responsabile a livello cantonale.

23.2

L’accesso all’infrastruttura e al software e ogni intervento sugli stessi sono disciplinati e documentati in dettaglio in base a un’analisi dei rischi. Nei settori ad alto rischio e per tutte le operazioni manuali relative alle urne elettroniche (p. es. apertura del canale di voto, chiusura del canale di voto, avvio dello spoglio) si applica il principio del doppio controllo.

Le operazioni manuali relative alle urne elettroniche (p. es. apertura del canale di voto, chiusura del canale di voto, avvio dello spoglio) sono autenticate in modo esplicito.

23.3

È garantito che non si possano modificare senza autorizzazione informazioni sul sito del voto elettronico né le pagine informative sul voto elettronico.

23.4

Durante lo scrutinio è escluso qualsivoglia intervento sull’in­fra­struttura che non riguardi il voto elettronico.

23.5

È assicurato che nessuno degli elementi dei dati di autenticazione client possa essere sistematicamente intercettato, modificato o deviato. Per l’autenticazione sono attuate misure e impiegate tecnologie che riducano sufficientemente al minimo il rischio di abuso sistematico da parte di terzi.

24.1

Sviluppo

24.1.1

Viene definito un modello di ciclo di vita. Tale modello:

−

viene utilizzato per lo sviluppo e la manutenzione del software;

−

prevede i controlli necessari nello sviluppo e nella manutenzione del software;

−

viene documentato.

24.1.2

Viene allestito un elenco degli strumenti di sviluppo utilizzati e delle opzioni di configurazione selezionate per l’impiego dei singoli strumenti di sviluppo.

24.1.3

La documentazione degli strumenti di sviluppo comprende:

−

una definizione di ciascuno strumento di sviluppo;

−

una descrizione di tutte le convenzioni e direttive utilizzate nell’implementazione dello strumento di sviluppo;

−

una descrizione univoca del significato di tutte le opzioni di configurazione utilizzate per l’applicazione dello strumento di sviluppo.

24.1.4

Si stabilisce quali sono gli standard di implementazione applicati.

24.1.5

Il software è specificato e implementato in modo tale che le funzioni di sicurezza non possano essere aggirate.

24.1.6

Le funzioni di sicurezza sono specificate e implementate in modo tale che siano protette dalle manipolazioni.

24.1.7

L’architettura di sicurezza del software è documentata. La documentazione:

–

attesta un grado di dettaglio corrispondente alla descrizione delle funzioni di sicurezza;

–

descrive i settori della sicurezza cui si indirizzano le funzioni di sicurezza;

–

descrive in che modo i processi di inizializzazione vengono garantiti;

–

comprova l’adempimento dei requisiti di cui a numeri 24.1.5 e 24.1.6.

24.1.8

Le specifiche funzionali sono documentate. La documentazione:

–

rappresenta l’intero software;

–

descrive lo scopo e l’utilizzo di tutte le interfacce;

–

identifica e descrive tutti i parametri associati alle interfacce;

–

descrive tutte le azioni associate alle interfacce;

–

descrive tutti i messaggi di errore diretti che potrebbero risultare dal richiamo delle singole interfacce.

24.1.9

La tracciabilità fra le specifiche funzionali e i requisiti di sicurezza è garantita fino al livello delle interfacce.

24.1.10

Tutte le funzioni di sicurezza sono implementate nel codice sorgente.

24.1.11

La tracciabilità fra l’intero codice sorgente e le specifiche delle funzioni di sicurezza è garantita e la loro corrispondenza è evidente.

24.1.12

Le funzioni di sicurezza sono concepite e implementate in modo che siano ben strutturate. La struttura interna viene descritta e comprende una motivazione che:

–

indica le caratteristiche che sono state utilizzate per valutare le nozioni di «ben strutturato» e di «complesso»;

–

indica che tutte le funzioni di sicurezza sono ben strutturate e non sono troppo complesse.

24.1.13

Le specifiche comprendono i seguenti elementi:

–

una descrizione della struttura del software nella forma di sottosistemi;

–

una descrizione delle funzioni di sicurezza nella loro qualità di moduli e, per ogni modulo, il rispettivo obiettivo e una descrizione di come esso sia in relazione con gli altri moduli; la descrizione dei moduli rilevanti per la sicurezza comprende anche le interfacce disponibili, i valori restituiti di queste interfacce e le interfacce degli altri moduli utilizzate per interagire con esse;

–

una descrizione di tutti i sottosistemi in relazione alle funzioni di sicurezza, comprese le possibili reciproche interazioni;

–

un’illustrazione chiara dei sottosistemi connessi alle funzioni di sicurezza che comprova che tutte le interfacce corrispondono al comportamento descritto nella specifica; l’illustrazione deve presentare un grado di dettaglio che si estende almeno fino ai moduli.

24.1.14

Il software è provvisto di una caratterizzazione univoca.

24.1.15

La documentazione relativa alla gestione della configurazione comprende i seguenti elementi:

–

una descrizione del modo in cui gli elementi di configurazione sono identificati;

–

un piano di gestione della configurazione che descrive in che modo il sistema di gestione della configurazione è utilizzato nello sviluppo del software e quali sono le procedure applicate per l’accettazione di modifiche o di nuovi elementi;

–

la prova che le procedure di accettazione prevedono un’adeguata verifica delle modifiche per tutti gli elementi di configurazione.

24.1.16

Il sistema di gestione della configurazione:

–

identifica in modo univoco tutti gli elementi di configurazione;

–

appronta misure automatizzate per fare in modo che agli elementi di configurazione vengano apportate soltanto modifiche autorizzate;

–

sostiene lo sviluppo del software attraverso procedure automatizzate;

–

garantisce che la persona che ha la responsabilità di accettare l’elemento di configurazione non è la stessa che lo ha sviluppato;

–

identifica gli elementi di configurazione di cui si compongono le funzioni di sicurezza;

–

sostiene con procedure automatizzate la verifica di tutte le modifiche apportate al software, compresi il protocollo dell’autore nonché la data e l’ora della modifica;

–

appronta una procedura automatizzata per l’identificazione di tutti gli elementi di configurazione interessati dalla modifica di uno specifico elemento di configurazione;

–

è in grado di identificare la versione del codice sorgente sulla base del quale è generato il software.

24.1.17

Tutti gli elementi di configurazione sono inventariati nel sistema di gestione della configurazione.

24.1.18

Il sistema di gestione della configurazione viene utilizzato in conformità con il piano di gestione della configurazione.

24.1.19

È allestito un elenco di configurazione contenente i seguenti elementi:

–

il software;

–

le prove che i controlli richiesti per il rispetto della sicurezza sono stati eseguiti;

–

le parti di cui si compone il software;

–

il codice sorgente;

–

la commit history¹²;

–

i rapporti sulle lacune nella sicurezza e sul loro stato di risoluzione.

Per ogni elemento rilevante per le funzioni di sicurezza si menziona lo sviluppatore. Ciascun elemento è identificato in modo univoco.

24.1.20

La documentazione concernente la sicurezza dello sviluppo del software comprende i seguenti aspetti:

–

la descrizione delle misure di sicurezza fisiche, procedurali, in materia di personale e altre che sono necessarie per la protezione e l’integrità della configurazione e dell’implementazione del software nel suo ambiente di sviluppo;

–

la prova che le misure di sicurezza offrono il livello di protezione necessario a garantire l’integrità del software.

24.2

Esercizio

24.2.1

È allestito un manuale d’esercizio. Per ogni ruolo utente, esso contiene i seguenti aspetti:

–

una descrizione delle funzioni accessibili all’utente e delle autorizzazioni che devono essere controllate in un ambiente sicuro, compresi i relativi avvertimenti;

–

una descrizione di come le interfacce disponibili possono essere utilizzate in modo sicuro;

–

una descrizione delle funzioni e delle interfacce disponibili, in particolare di tutti i parametri di sicurezza posti sotto il controllo dell’utente, con l’indicazione dei valori rilevanti per la sicurezza;

–

una presentazione accurata di tutti i tipi di eventi di sicurezza legati alle funzioni accessibili all’utente che devono essere eseguite, compresi gli adeguamenti delle caratteristiche di sicurezza apportati ad elementi posti sotto il controllo delle funzioni di sicurezza;

–

una descrizione delle misure di sicurezza che devono essere attuate per conseguire gli obiettivi di sicurezza d’esercizio.

24.2.2

Il manuale d’esercizio indica tutti i possibili modi d’esercizio del software, comprese la ripresa dell’esercizio dopo la scoperta di errori nonché una descrizione delle conseguenze e delle implicazioni derivanti da tali errori per il mantenimento di un esercizio sicuro.

24.2.3

Il manuale d’esercizio è preciso e adeguato allo scopo.

24.3

Compilazione e deployment affidabili e verificabili

24.3.1

Il processo di preparazione descrive tutti i passi necessari per:

–

un’accettazione sicura delle componenti del sistema conformemente alle procedure di fornitura;

–

una preparazione sicura dell’ambiente d’esercizio conformemente agli obiettivi di sicurezza d’esercizio;

–

un’istallazione sicura del software nell’ambiente d’esercizio.

24.3.2

La fornitura del software o di parti del sistema è documentata e comprende tutti i processi necessari al mantenimento della sicurezza in occasione della fornitura del software.

24.3.3

È eseguita una compilazione affidabile e verificabile con adeguate misure di sicurezza che garantisce che il codice eseguibile sia una rappresentazione verificabile e fedele del codice sorgente che è stato sottoposto a un controllo pubblico e a verifiche indipendenti. La compilazione permette di stabilire una catena di conferme per la verifica del software e comprende in particolare:

–

la prova che l’ambiente di compilazione è impostato come quello descritto sulla piattaforma pubblica (insieme degli strumenti con la loro rispettiva versione, sistema d’esercizio ed eventuali configurazioni); eventuali divergenze devono essere documentate e motivate;

–

la prova che il software è stato compilato conformemente alle istruzioni disponibili sulla piattaforma pubblica; se al momento della compilazione viene ravvisata una lacuna nelle istruzioni, essa va iscritta in un protocollo e la documentazione deve essere successivamente adeguata;

–

la prova che il codice sorgente sottoposto al controllo pubblico e verificato è effettivamente quello che è stato utilizzato per la compilazione;

–

la prova che non è stato introdotto alcun elemento diverso da quelli previsti nelle istruzioni;

–

la prova che tutte le firme crittografiche delle dipendenze sono state verificate rispetto a un riferimento comprovato, pubblico e affidabile;

–

la prova che è stata condotta un’analisi dei punti deboli delle dipendenze e, nel caso in cui esistano punti deboli rilevanti per il software, che esse non rendano il software vulnerabile agli attacchi;

–

la prova che gli eventuali parametri introdotti non rendono il sistema vulnerabile agli attacchi.

24.3.4

È eseguito un deployment affidabile e verificabile con adeguate misure di sicurezza, in modo da garantire che:

1.

il codice utilizzato in produzione sia una rappresentazione verificabile e fedele del codice sorgente che è stato sottoposto a un controllo pubblico e a verifiche indipendenti; e

2.

l’ambiente di produzione sia conforme con quello che è stato sottoposto a un controllo pubblico e a verifiche indipendenti.

Il deployment permette di stabilire una catena di conferme per la verifica del software e comprende in particolare:

–

la prova che l’ambiente di produzione è conforme con quello che è stato sottoposto a un controllo pubblico e a verifiche indipendenti; eventuali divergenze (versione di firmware, file di configurazione, ecc.) devono essere documentate e motivate;

–

la prova che il software utilizzato nell’ambiente di produzione è effettivamente quello che è stato allestito nella procedura di compilazione affidabile e verificabile;

–

la prova che gli eventuali parametri introdotti non rendono il sistema più vulnerabile agli attacchi.

24.3.5

La qualità delle prove della compilazione affidabile e verificabile e del deployment affidabile e verificabile è attestata dalla presenza di almeno due testimoni appartenenti a istituzioni diverse o attraverso procedure tecniche volte a stabilire la verità secondo lo stato delle conoscenze scientifiche e l’esperienza.

24.3.6

La catena di conferme della compilazione affidabile e verificabile e del deployment affidabile e verificabile è resa accessibile al pubblico.

24.4

Eliminazione sistematica delle lacune

24.4.1

Vengono definiti processi per l’eliminazione delle lacune. I processi comprendono:

–

una documentazione di questi processi, in particolare per quanto riguarda la tracciabilità delle lacune per ciascuna delle versioni del software, nonché dei metodi utilizzati affinché gli utenti del sistema dispongano delle informazioni concernenti le lacune, le correzioni e le possibili misure correttive;

–

l’obbligo di descrivere il genere e le conseguenze di tutte le lacune nella sicurezza, le informazioni sullo stato dei lavori volti a trovare una soluzione e le misure correttive decise;

–

una descrizione degli strumenti che permettono agli utenti del sistema di comunicare agli sviluppatori del software rapporti e richieste riguardanti presunte lacune nel software;

–

una procedura che esiga una reazione in tempi brevi e l’invio automatico di rapporti sulle lacune della sicurezza e i relativi correttivi agli utenti del sistema registrati che potrebbero essere toccati dalla lacuna.

24.4.2

È definito un processo per il trattamento delle lacune segnalate:

–

questo processo garantisce che tutte le lacune notificate e confermate sono state eliminate e che le relative procedure sono state comunicate agli utenti del sistema;

–

esso prevede delle disposizioni che garantiscono che l’eliminazione di una lacuna nella sicurezza non introduce nuove lacune nella sicurezza.

24.4.3

Vengono definite direttive per la segnalazione e l’eliminazione delle lacune. Esse comprendono:

–

una descrizione del modo in cui gli utenti del sistema possono segnalare allo sviluppatore presunte lacune nella sicurezza;

–

una descrizione del modo in cui gli utenti del sistema possono registrarsi presso lo sviluppatore, in modo da ricevere rapporti sulle lacune della sicurezza e sui relativi correttivi;

–

l’indicazione di specifici servizi di contatto per tutti i rapporti e le richieste di informazioni su questioni di sicurezza riguardanti il software.

24.5

Garanzia della qualità

Periodicamente si verifica in modo obiettivo se i processi eseguiti e i prodotti di lavoro ad essi associati corrispondono alla descrizione dei processi, delle norme e delle procedure che devono essere applicati. Eventuali non conformità sono seguite fino a quando non sono state risolte.

Il codice sorgente e la documentazione soddisfano almeno i seguenti criteri di qualità:

25.1

Comprensibilità

25.1.1

Per comprensibilità si intende il rigore logico che va dai requisiti all’implementazione.

25.1.2

Tutti i requisiti posti al protocollo crittografico sono comprensibili per tutti i risultati di lavoro legati al processo di sviluppo del software.

25.1.3

Il legame fra i requisiti legali e il protocollo crittografico, le specifiche e la documentazione dell’architettura è fatto oggetto di una descrizione.

25.2

Completezza

25.2.1

Per completezza si intende l’attuazione completa delle funzioni richieste.

25.2.2

Il software non contiene indicazioni ambigue (input, funzione, output). A ciascun elemento si fa riferimento sempre con lo stesso nome.

25.2.3

Tutti i dati referenziati e tutte le funzioni utilizzate sono definiti nelle specifiche.

25.2.4

Sono utilizzate tutte le funzioni definite nelle specifiche.

25.2.5

Per ogni punto oggetto di decisione (p. es. esecuzione condizionata), le possibili alternative sono definite nelle specifiche.

25.2.6

Tutti i parametri sono definiti nelle specifiche e convalidati (nessuna attribuzione implicita di parametri).

25.2.7

Tutti gli errori gravi che vengono segnalati sono eliminati prima di passare alla tappa successiva del ciclo di sviluppo.

25.2.8

Il protocollo crittografico, la specifica, il design e il codice sorgente sono armonizzati fra loro.

25.3

Coerenza

25.3.1

Per coerenza si intende la proprietà del software di utilizzare procedure e notazioni uniformi nella concezione e nell’implementazione.

25.3.2

Le rappresentazioni nella documentazione seguono una convenzione stabilita dallo sviluppatore del software.

25.3.3

Le funzioni e le variabili seguono una convenzione d’attribuzione dei nomi stabilita dallo sviluppatore del software.

25.3.4

Input e output di funzioni sono trattati in base a una convenzione stabilita dallo sviluppatore del software.

25.3.5

Gli errori sono trattati in base a una convenzione stabilita dallo sviluppatore del software.

25.3.6

I tipi di variabili utilizzati sono coerenti.

25.4

Uniformità della comunicazione

25.4.1

Per uniformità della comunicazione si intende l’utilizzazione di protocolli standardizzati e routine d’interfaccia.

25.4.2

Sono definite regole per la comunicazione con altri sistemi.

25.4.3

La comunicazione si basa su metodi di comunicazione standardizzati.

25.5

Uniformità dei dati

25.5.1

Per uniformità dei dati si intende la proprietà del software di utilizzare una rappresentazione standardizzata dei dati.

25.5.2

La rappresentazione standardizzata dei dati per la comunicazione con altri sistemi viene definita in modo formale.

25.5.3

Per la conversione fra le diverse rappresentazioni vengono definiti degli standard.

25.5.4

Le funzioni di conversione dovrebbero essere centralizzate in un unico modulo.

25.6

Apprendibilità

25.6.1

Per apprendibilità si intende la proprietà del software di permettere agli utenti di familiarizzarsi facilmente con il suo funzionamento.

25.6.2

Le persone che gestiscono e utilizzano il sistema sono formate e ricevono la documentazione necessaria.

25.6.3

La formazione comprende la possibilità di esercitarsi su un sistema previsto appositamente.

25.6.4

Gli strumenti di aiuto sono facilmente accessibili.

25.7

Operabilità

25.7.1

Per operabilità si intende la proprietà del software di agevolare l’interazione con il sistema.

25.7.2

Il software è di facile utilizzo. La navigazione si rifà agli schemi generalmente in uso.

25.7.3

Il sistema client quale si presenta ai votanti è conforme, ad eccezione dei requisiti posti a forme di comunicazione alternative nel capitolo 2.4, alla norma di accessibilità eCH-0059¹³. I Cantoni provvedono affinché questo sia attestato da un servizio specializzato in materia.

25.8

Tolleranza agli errori

25.8.1

La tolleranza agli errori permette la prosecuzione dell’esercizio in condizioni eccezionali.

25.8.2

Gli errori sono rilevati e trattati affinché il programma possa continuare a funzionare senza interruzioni.

25.8.3

Il trattamento degli errori, inclusa la registrazione nel protocollo, avviene al livello più pertinente per la prosecuzione dell’esercizio. Un errore che non può essere trattato a un dato livello è trasferito al livello immediatamente superiore.

25.8.4

Per i parametri di entrata sono definite condizioni di validità.

25.8.5

Tutti i parametri di entrata sono verificati prima che inizi il trattamento.

25.9

Modularità

25.9.1

Per modularità si intende la proprietà del software di fornire una struttura di moduli altamente indipendenti.

25.9.2

Il compito dei singoli moduli è definito in modo chiaro.

25.9.3

Il compito dei singoli moduli dovrebbe essere ristretto e mirato. Gli obiettivi di due moduli non dovrebbero accavallarsi.

25.9.4

I moduli non condividono dati attraverso una memoria volatile comune (p. es. variabile globale).

25.10

Semplicità

25.10.1

Per semplicità si intende l’implementazione delle funzioni nel modo più comprensibile possibile. In generale, si tratta di evitare le pratiche che aumentano la complessità.

25.10.2

Nella concezione è applicato un approccio top-down (struttura gerarchica).

25.10.3

La concezione non prevede alcuna duplicazione di funzioni fra i moduli.

25.10.4

La concezione non prevede dati globali, ossia dati che possono essere utilizzati da tutti senza essere passati quali parametri.

25.10.5

Nel codice sorgente sono evitate per quanto possibile complicate combinazioni booleane.

25.10.6

Nel codice sorgente nessuna variabile viene riutilizzata per scopi diversi da quelli inizialmente previsti.

25.10.7

Nel codice sorgente il numero di imbricazioni è il più possibile limitato.

25.10.8

La complessità ciclomatica e cognitiva nel codice sorgente è il più possibile limitata.

25.11

Concisione

25.11.1

Per concisione si intende la situazione in cui una funzione può essere implementata nel codice sorgente con un minimo di istruzioni.

25.11.2

Il software non contiene alcun codice morto («dead code») nel codice sorgente.

25.11.3

Il codice sorgente non contiene alcuna variabile inutile.

25.11.4

Il codice sorgente non dovrebbe contenere alcuna ripetizione.

25.12

Intelligibilità

25.12.1

Per intelligibilità si intende la capacità del destinatario di riconoscere gli obiettivi, le ipotesi, le limitazioni, gli input e gli output, le componenti e lo stato del software.

25.12.2

Nel codice sorgente le classi, le funzioni e i passi di elaborazione complessi vengono commentati secondo una convenzione stabilita dallo sviluppatore software.

25.12.3

Le variabili e le funzioni sono designate con nomi significativi.

25.12.4

Un’istruzione dovrebbe comprendere un’unica linea, a meno che la leggibilità sia migliore con la ripartizione su più linee. È da evitare la presenza di più istruzioni su una linea sola.

25.13

Strumentazione

25.13.1

Per strumentazione si intende la proprietà del software di permettere di misurare la sua utilizzazione o di identificare gli errori.

25.13.2

I test unitari¹⁴ coprono tutti i percorsi possibili e i limiti tra valori ammessi e non ammessi dei parametri d’entrata.

25.13.3

I test d’integrazione coprono tutti i moduli.

25.13.4

Gli scenari di test del software coprono tutti i moduli.

25.13.5

Gli errori e le informazioni necessarie sono protocollati nei log.

26.1

Verifica del protocollo crittografico (art. 10 cpv. 1 lett. a)

26.1.1

Oggetto: si verifica:

–

se i requisiti elencati nell’articolo 5 in combinato disposto con gli articoli 6–8 e il numero 2 dell’allegato sono adempiuti; questa valutazione avviene in particolare sulla base di note di conformità crittografiche e simboliche;

–

se e fino a che punto il protocollo crittografico si basa su protocolli ed elementi esistenti e comprovati;

–

quali approfondimenti e miglioramenti potrebbero contribuire a rafforzare la sicurezza.

26.1.2

Competenze: la verifica viene svolta da esperti in crittografia. La Cancelleria federale commissiona la verifica e controlla che sia svolta conformemente al mandato.

26.1.3

Momento della verifica:

–

una verifica completa avviene precedentemente alla prima messa in esercizio;

–

la verifica viene di nuovo eseguita dopo 2–3 anni;

–

la verifica avviene di nuovo in occasione di ogni modifica del protocollo crittografico e in seguito all’acquisizione di nuove significative conoscenze della ricerca relative alla sicurezza degli elementi crittografici impiegati e alla situazione di minaccia.

26.2

Verifica del software del sistema (art. 10 cpv. 1 lett. b)

26.2.1

Oggetto: si verifica:

–

se il protocollo crittografico verificato secondo il numero 26.1 è attuato; la corretta attuazione di funzioni di componenti affidabili è verificata in modo particolarmente accurato;

–

se il software del sistema adempie i requisiti della presente ordinanza, e sostiene adeguatamente gli obiettivi predefiniti;

–

se il sistema client quale si presenta ai votanti è conforme alla norma eCH-0059 secondo il numero 25.7.3; la verifica può basarsi su un certificato valido emesso o un rapporto d’esame allestito da un’istituzione riconosciuta dalla Cancelleria federale che attesta la conformità con la norma.

26.2.2

Competenze: la verifica viene svolta da esperti in crittografia e nello sviluppo di software. La verifica viene commissionata dalla Cancelleria federale.

26.2.3

Momento della verifica:

–

una verifica completa avviene precedentemente alla prima messa in esercizio;

–

la verifica viene di nuovo eseguita dopo 2–3 anni;

–

la verifica avviene di nuovo in occasione di ogni modifica significativa, in particolare:

–

dopo ogni modifica del protocollo crittografico,

–

a ogni modifica, apportata al codice sorgente, delle funzioni la cui affidabilità è determinante per la validità delle note di conferma previste nell’ambito della verificabilità,

–

in caso di acquisizione di nuovi significativi dati della ricerca riguardanti la sicurezza degli elementi crittografici utilizzati e le situazioni di minaccia,

–

in caso di rinuncia o di adeguamenti significativi a meccanismi che servono all’impiego sicuro di componenti affidabili secondo il numero 2.

26.3

Verifica della sicurezza dell’infrastruttura e dell’esercizio (art. 10 cpv. 1 lett. c)

26.3.1

Oggetto: si verifica se:

–

il sistema e il suo esercizio presso il Cantone, il gestore del sistema e la tipografia adempiono i requisiti della presente ordinanza e sostengono adeguatamente gli obiettivi predefiniti;

–

le componenti di base, quali i software volti ad assicurare un impiego sicuro e indipendente di componenti di controllo, i sistemi operativi o i server impiegati dimostrano di soddisfare i migliori standard.

26.3.2

Competenze: la verifica viene svolta da esperti in crittografia e nell’esercizio di sistemi altamente sicuri. La verifica viene commissionata dalla Cancelleria federale.

26.3.3

Momento della verifica:

–

una verifica completa viene svolta precedentemente alla prima messa in esercizio;

–

la verifica viene di nuovo eseguita dopo 2–3 anni;

–

la verifica viene eseguita di nuovo in caso di modifiche significative, in particolare:

–

dopo una modifica del protocollo crittografico,

–

in caso di rinuncia o di adeguamenti significativi a meccanismi che servono all’impiego sicuro di componenti affidabili secondo il numero 2,

–

in caso di un adeguamento significativo dei processi o dell’infrastruttura;

–

se vengono impiegate nuove versioni di componenti di base (nuovi server, patch riguardanti il sistema operativo o software che servono all’impiego sicuro e indipendente di componenti secondo il numero 2), non deve esser svolto alcun nuovo controllo se è ancora possibile dimostrare che le componenti corrispondono ai migliori standard.

26.4

Verifica della protezione da tentativi di introdursi nell’infrastruttura (art. 10 cpv. 1 lett. d)

26.4.1

Oggetto: si verifica se gli esperti incaricati dalla Cancelleria federale riescono, nell’ambito di un test, a introdursi nell’infrastruttura del sistema on line e ad avere accesso a dati importanti o ad assumere il controllo su funzioni importanti.

I test sono effettuati sulla base delle potenziali vulnerabilità, individuate a seguito di un’analisi metodica della documentazione disponibile al pubblico, in particolare conformemente all’articolo 11.

26.4.2

Competenze: la verifica viene svolta da esperti in sicurezza. Essa viene commissionata dalla Cancelleria federale.

26.4.3

Momento della verifica:

–

una verifica completa avviene precedentemente alla prima messa in esercizio;

–

la verifica viene di nuovo eseguita dopo 2–3 anni;

–

la verifica viene eseguita di nuovo in caso di ogni modifica significativa dell’infrastruttura.

–

la verifica ha luogo in caso di acquisizione di nuove significative informazioni riguardanti la sicurezza degli strumenti utilizzati e le situazioni di minaccia.

26.5

Verifica del sistema di gestione di sicurezza dell’informazione (art. 10 cpv. 2)

26.5.1

Oggetto: si verifica se l’ISMS del gestore del sistema è conforme alla norma ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements. Il campo di applicazione dell’ISMS comprende tutte le unità organizzative del gestore del sistema responsabili sotto il profilo giuridico, amministrativo e operativo per il sistema.

26.5.2

Competenze: l’organismo di certificazione è accreditato dal Servizio di accreditamento svizzero per eseguire audit ai sensi della norma ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements. La verifica è commissionata dal Cantone o dal gestore del sistema; il Cantone provvede allo svolgimento della verifica.

26.5.3

Durata di validità di un attestato: gli audit di ripetizione sono svolti negli intervalli stabiliti dalla norma ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements. A ogni impiego è presentato un certificato valido e il relativo «Statement of Applicability». Se viene pubblicata una nuova versione dello standard ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements, al più tardi dopo la scadenza del termine transitorio deve essere presentata la prova di una certificazione valida dell’ISMS secondo la nuova versione. Il campo di applicazione dell’ISMS non può essere ristretto a favore di questa nuova certificazione.