Bei grossen Gesetzen wie OR und ZGB kann dies bis zu 30 Sekunden dauern

Ordonnance de la ChF
sur le vote électronique
(OVotE)

du 25 mai 2022 (Etat le 1 juillet 2022)er

La Chancellerie fédérale suisse (ChF),

vu les art. 27e, al. 1bis, 27g, al. 2, 27i, al. 3, et 27l, al. 3 et 4,
de l’ordonnance du 24 mai 1978 sur les droits politiques (ODP)1,

arrête:

Annexe

(art. 2, al. 1, let. k, et 2, 9, 10, al. 1 et 2, et 16, al. 1)

1

Art. 1 Objet  

La présente or­don­nance fixe les con­di­tions ré­gis­sant l’oc­troi de l’agré­ment pour les es­sais de vote élec­tro­nique.

Art. 2 Définitions  

1 On en­tend par:

a.
sys­tème: ter­me générique qui re­couvre le lo­gi­ciel et les in­fra­struc­tures util­isés pour réal­iser un scru­tin élec­tro­nique;
b.
sys­tème en ligne: partie du sys­tème qui est util­isée pour véri­fi­er le droit de vote, pour en­voy­er le suf­frage chif­fré et pour con­serv­er le suf­frage chif­fré;
c.
partie fiable du sys­tème: partie du sys­tème com­pren­ant un ou plusieurs groupes de com­posants de con­trôle; la fiab­il­ité de cette partie du sys­tème ré­sulte de ce qu’il est pos­sible de détecter les abus même si un seul des com­posants de con­trôle d’un groupe fonc­tionne cor­recte­ment;
d.
com­posants de con­trôle: com­posants du sys­tème in­dépend­ants qui diffèrent les uns des autres dans leur con­cep­tion, sont ex­ploités par des per­sonnes différentes et sont sé­cur­isés par des mesur­es spé­ci­fiques;
e.
ex­ploit­ant du sys­tème: autor­ité ou en­tre­prise privée qui, agis­sant sur in­struc­tions du can­ton, ex­ploite le sys­tème en ligne lors de la tenue d’un scru­tin et as­sure sa main­ten­ance;
f.
ex­ploit­a­tion: toutes ac­tions à ca­ra­ctère tech­nique, ad­min­is­trat­if ou jur­idique ain­si que les activ­ités di­ri­geantes menées par un can­ton, un ex­ploit­ant du sys­tème ou une im­primer­ie qui sont né­ces­saires pour la réal­isa­tion d’un scru­tin élec­tro­nique, y com­pris la main­ten­ance;
g.
unités d’ex­ploit­a­tion: unités re­spons­ables de l’ex­ploit­a­tion, comme une chan­celler­ie d’État, un ex­ploit­ant d’un sys­tème ou une im­primer­ie;
h.
véri­fic­ateurs: per­sonnes qui, sur man­dat du can­ton, s’as­surent du bon déroul­e­ment du scru­tin;
i.
in­fra­struc­ture: matéri­el in­form­atique, lo­gi­ciels de com­posants tiers au sens de l’art. 11, al. 2, let. a, élé­ments de réseau, lo­c­aux, ser­vices et moy­ens d’ex­ploit­a­tion de toute nature des unités d’ex­ploit­a­tion, qui sont né­ces­saires à une ex­ploit­a­tion sûre du vote élec­tro­nique;
j.
lo­gi­ciel: pleine im­plé­ment­a­tion à partir du pro­to­cole cryp­to­graph­ique né­ces­saire à la véri­fi­ab­il­ité com­plète du pro­ces­sus de vote élec­tro­nique telle qu’elle a été mise en œuvre par le dévelop­peur du sys­tème;
k.
pro­to­cole cryp­to­graph­ique: pro­to­cole doté de fonc­tions de sé­cur­ité cryp­to­graph­iques des­tiné à as­surer la con­form­ité aux ex­i­gences visées à l’an­nexe, ch. 2; le pro­to­cole cryp­to­graph­ique est im­planté au niveau du mod­èle et ne con­tient donc pas d’in­struc­tions d’im­plé­ment­a­tion dir­ect­es, mais unique­ment des fonc­tions de sé­cur­ité ab­straites;
l.
plate-forme util­isateur: ap­par­eil mul­ti­fonc­tion­nel pro­gram­mable relié à In­ter­net et qui per­met de voter, tel qu’un or­din­ateur stand­ard, un or­di­phone ou une tab­lette tact­ile;
m.
suf­frage en­re­gis­tré: suf­frage dont la partie fiable du sys­tème a reçu con­firm­a­tion de son ca­ra­ctère défin­i­tif;
n.
suf­frage partiel:
1.
dans le cadre d’une vota­tion: suf­frage émis re­l­at­ive­ment à un pro­jet, à un contre-pro­jet ou à une ques­tion sub­sidi­aire,
2.
dans le cadre d’une élec­tion: suf­frage émis en faveur d’une liste ou d’un can­did­at;
o.
suf­frage émis con­formé­ment à la procé­dure prévue par le sys­tème: suf­frage qui ré­pond aux quatre con­di­tions suivantes:
1.
il est con­forme aux règles ap­plic­ables au re­m­plis­sage d’un bul­let­in de vote,
2.
il a été émis de man­ière défin­it­ive,
3.
les don­nées per­tin­entes d’au­then­ti­fic­a­tion cli­ent et le mes­sage d’au­then­ti­fic­a­tion qui en ré­sulte cor­res­pond­ent aux don­nées d’au­then­ti­fic­a­tion serveur qui ont été définies et en­voyées à l’élec­teur en amont du scru­tin,
4.
il a été émis au moy­en de don­nées d’au­then­ti­fic­a­tion cli­ent qui n’ont pas déjà été util­isées pour émettre un suf­frage que la partie fiable du sys­tème en ligne aurait en­re­gis­tré précé­dem­ment;
p.
don­née d’au­then­ti­fic­a­tion cli­ent: in­form­a­tion mise à la dis­pos­i­tion de l’élec­teur, comme un NIP, et dont ce­lui-ci, le cas échéant con­jointe­ment avec d’autres don­nées d’au­then­ti­fic­a­tion cli­ent, a be­soin pour voter;
q.
don­née d’au­then­ti­fic­a­tion serveur: in­form­a­tion qui, le cas échéant con­jointe­ment avec d’autres don­nées d’au­then­ti­fic­a­tion serveur, est né­ces­saire pour au­then­ti­fi­er l’émetteur d’un suf­frage en sa qual­ité d’élec­teur au moy­en de mes­sages d’au­then­ti­fic­a­tion;
r.
mes­sages d’au­then­ti­fic­a­tion: en­semble des in­form­a­tions qu’une plate-forme util­isateur en­voie au sys­tème en ligne après in­tro­duc­tion des don­nées d’au­then­ti­fic­a­tion cli­ent pour que l’in­fra­struc­ture au­then­ti­fie l’émetteur d’un suf­frage en sa qual­ité d’élec­teur;
s.
cer­ti­ficat: doc­u­ment qui at­teste qu’un élé­ment con­trôlé est con­forme à un cadre de référence ou à une norme;
t.
cer­ti­ficat élec­tro­nique: en­semble de don­nées qui at­teste de cer­taines ca­ra­ctéristiques de per­sonnes ou d’ob­jets et dont l’au­then­ti­cité et l’in­té­grité peuvent être véri­fiées par des procédés cryp­to­graph­iques; le cer­ti­ficatélec­tro­nique est prin­cip­ale­ment util­isé pour iden­ti­fi­er et au­then­ti­fi­er le tit­u­laire et pour chif­frer les trans­mis­sions;

u. ac­tions et opéra­tions cri­tiques: activ­ités au cours de­squelles des don­nées cri­tiques sont traitées;

v.
don­nées cri­tiques: don­nées dont l’in­té­grité ou la con­fid­en­ti­al­ité sont déter­min­antes pour le re­spect des ex­i­gences du pro­to­cole cryp­to­graph­ique.

2 Sont ap­plic­ables au sur­plus les défin­i­tions qui fig­urent au ch. 1 de l’an­nexe.

Art. 3 Conditions à remplir pour obtenir l’agrément en vue de la tenue d’un scrutin électronique  

L’agré­ment doit être de­mandé pour chaque scru­tin élec­tro­nique; il est ac­cordé si les con­di­tions suivantes sont re­m­plies:

a.
le sys­tème est con­çu et ex­ploité de façon à garantir un scru­tin élec­tro­nique véri­fi­able, sûr et fiable;
b.
le sys­tème est fa­cile à util­iser par les élec­teurs; il tient compte autant que pos­sible des be­soins par­ticuli­ers de chacun;
c.
le sys­tème et les pro­ces­sus d’ex­ploit­a­tion sont con­çus et doc­u­mentés de façon à ce qu’il soit pos­sible de véri­fi­er et de com­pren­dre dans le dé­tail leurs as­pects tech­niques et or­gan­isa­tion­nels;
d.
le pub­lic a ac­cès à des in­form­a­tions ad­aptées sur le fonc­tion­nement du sys­tème et sur ses pro­ces­sus d’ex­ploit­a­tion, et des mesur­es sont prises pour in­citer les per­sonnes dis­posant des con­nais­sances né­ces­saires à par­ti­ciper à l’améli­or­a­tion du sys­tème.
Art. 4 Appréciation des risques  

1 Le can­ton dé­montre au moy­en d’une ap­pré­ci­ation des risques que les risques pour la sé­cur­ité sont suf­f­is­am­ment faibles dans le do­maine qui relève de sa com­pétence. Il tient compte de la con­fi­ance et de l’ac­cept­a­tion du pub­lic à l’égard du vote élec­tro­nique.

2 Il ex­am­ine s’il lui est pos­sible d’ap­pré­ci­er les risques dans les do­maines qui relèvent de ses prestataires ou si ceux-ci doivent le faire eux-mêmes. Le cas échéant, il leur de­mande de procéder à une telle ap­pré­ci­ation et de la lui re­mettre.

3 Les risques sont ap­pré­ciés sous l’angle des ob­jec­tifs de sé­cur­ité suivants:

a.
l’ex­actitude des ré­sultats est garantie;
b.
le secret du vote est garanti et il est im­possible d’ét­ab­lir des ré­sultats partiels an­ti­cipés;
c.
le vote élec­tro­nique est ac­cess­ible et opéra­tion­nel;
d.
les in­form­a­tions per­son­nelles des élec­teurs sont protégées;
e.
les in­form­a­tions des­tinées aux élec­teurs sont protégées contre les ma­nip­u­la­tions;
f.
il est im­possible de faire un us­age ab­usif des preuves re­l­at­ives au com­porte­ment de vote.

4 Chaque risque doit être iden­ti­fié et décrit claire­ment au moy­en de la doc­u­ment­a­tion du sys­tème et de son ex­ploit­a­tion, sous l’angle des as­pects suivants:

a.
ob­jec­tifs de sé­cur­ité;
b.
don­nées éven­tuelle­ment liées aux ob­jec­tifs de sé­cur­ité;
c.
men­aces;
d.
vul­nér­ab­il­ités.
Art. 5 Exigences applicables à la vérifiabilité complète  

1 Toute ma­nip­u­la­tion de nature à fausser les ré­sultats doit pouvoir être détectée sans qu’il soit porté at­teinte au secret du vote (véri­fi­ab­il­ité com­plète). Tel est réputé être le cas lor­sque sont re­m­plies les ex­i­gences ap­plic­ables et à la véri­fi­ab­il­ité in­di­vidu­elle et à la véri­fi­ab­il­ité uni­verselle.

2 La véri­fi­ab­il­ité in­di­vidu­elle est sou­mise aux ex­i­gences suivantes:

a.
tout votant dis­pose de la pos­sib­il­ité de détecter si le suf­frage qu’il a émis, tel qu’il l’a saisi sur la plate-forme util­isateur, a été ma­nip­ulé ou in­ter­cepté sur la plate-forme util­isateur ou pendant la trans­mis­sion; tout votant reçoit à cet ef­fet la preuve que la partie fiable du sys­tème (art. 8) a en­re­gis­tré son suf­frage tel qu’il l’a saisi sur la plate-forme util­isateur, et que ce suf­frage a été émis con­formé­ment à la procé­dure prévue par le sys­tème; la preuve at­teste, pour chaque suf­frage partiel, que l’en­re­gis­trement a été ef­fec­tué cor­recte­ment;
b.
tout élec­teur qui n’a pas voté par voie élec­tro­nique peut de­mander, une fois fer­mé le canal de vote élec­tro­nique et av­ant l’échéance des délais de re­cours légaux, la preuve que la partie fiable du sys­tème n’a pas en­re­gis­tré de suf­frage émis au moy­en de ses pro­pres don­nées d’au­then­ti­fic­a­tion cli­ent.

3 La véri­fi­ab­il­ité uni­verselle est sou­mise aux ex­i­gences suivantes:

a.
les véri­fic­ateurs reçoivent la preuve que les ré­sultats ont été ét­ab­lis cor­recte­ment; cette preuve at­teste que ceux-ci ont été ét­ab­lis en pren­ant en compte:
1.
tous les suf­frages qui ont été émis con­formé­ment à la procé­dure prévue par le sys­tème et qui ont été en­re­gis­trés par la partie fiable du sys­tème,
2.
unique­ment les suf­frages qui ont été émis con­formé­ment à la procé­dure prévue par le sys­tème,
3.
tous les suf­frages partiels cor­res­pond­ant à la preuve générée dans le cadre de la véri­fi­ab­il­ité in­di­vidu­elle;
b.
les véri­fic­ateurs doivent évalu­er cette preuve au cours d’un pro­ces­sus ob­serv­able; ils mettent en œuvre à cet ef­fet des dis­pos­i­tifs tech­niques in­dépend­ants et sé­parés du reste du sys­tème.
Art. 6 Caractère concluant des preuves  

Le ca­ra­ctère con­clu­ant des preuves visées à l’art. 5 dépend de la fiab­il­ité:

a.
de la partie fiable du sys­tème, pour les preuves visées à l’art. 5, al. 2 et 3;
b.
de la procé­dure util­isée pour générer et im­primer le matéri­el de vote, pour les preuves visées à l’art. 5, al. 2, et
c.
des dis­pos­i­tifs tech­niques que les véri­fic­ateurs mettent en œuvre aux fins de con­trôle, pour les preuves visées à l’art. 5, al. 3.
Art. 7 Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés  

Sont déter­min­antes pour garantir le secret du vote et l’im­possib­il­ité d’ét­ab­lir des ré­sultats partiels an­ti­cipés au sein de l’in­fra­struc­ture:

a.
la fiab­il­ité de la partie fiable du sys­tème;
b.
la fiab­il­ité de la procé­dure util­isée pour générer et im­primer le matéri­el de vote.
Art. 8 Exigences applicables à la partie fiable du système  

1 La partie fiable du sys­tème com­prend un ou plusieurs groupes de com­posants de con­trôle.

2 Les preuves sont con­clu­antes (art. 6) et le secret du vote est garanti (art. 7) même si, dans chaque groupe, il n’y a qu’un seul com­posant de con­trôle à fonc­tion­ner cor­recte­ment.

3 Pour que la fiab­il­ité de la partie fiable du sys­tème soit garantie, il faut que les com­posants de con­trôle diffèrent les uns des autres dans leur con­cep­tion et que leur ex­ploit­a­tion et leur sur­veil­lance soi­ent in­dépend­antes.

Art. 9 Mesures supplémentaires visant à réduire les risques  

Si les risques ne sont pas suf­f­is­am­ment faibles mal­gré les mesur­es prises, il con­vi­ent de pren­dre des mesur­es sup­plé­mentaires afin de les ré­duire. Cette règle s’ap­plique même lor­sque toutes les ex­i­gences prévues dans l’an­nexe ont déjà été mises en œuvre.

Art. 10 Exigences applicables au contrôle  

1 Des or­ganes in­dépend­ants man­datés par la ChF véri­fi­ent la con­form­ité:

a.
du pro­to­cole cryp­to­graph­ique (an­nexe, ch. 26.1);
b.
du lo­gi­ciel du sys­tème (an­nexe, ch. 26.2);
c.
de la sé­cur­ité de l’in­fra­struc­ture et de l’ex­ploit­a­tion (an­nexe, ch. 26.3);
d.
de la pro­tec­tion contre les tent­at­ives d’in­tru­sion dans l’in­fra­struc­ture (an­nexe, ch. 26.4).

2 Le can­ton s’as­sure que l’ex­ploit­ant du sys­tème dis­pose d’un sys­tème de man­age­ment de la sé­cur­ité de l’in­form­a­tion (SM­SI) et que ce­lui-ci est audité par des or­ganes in­dépend­ants (an­nexe, ch. 26.5). Le SM­SI porte au moins sur les pro­ces­sus et les élé­ments de l’in­fra­struc­ture de l’ex­ploit­ant du sys­tème qui sont per­tin­ents pour at­teindre les ob­jec­tifs de sé­cur­ité.

3 Le can­ton s’as­sure que la ChF et les or­ganes in­dépend­ants qu’elle a man­datés ont ac­cès au sys­tème et à tous les doc­u­ments né­ces­saires de façon à pouvoir procéder aux con­trôles visés à l’al. 1.

4 Les autor­ités re­spons­ables des con­trôles en vertu des al. 1 et 2 pub­li­ent les pièces jus­ti­fic­at­ives et les cer­ti­ficats. Ils pub­li­ent en outre tous doc­u­ments per­tin­ents pour la com­préhen­sion de ces derniers. Ne doivent pas ob­lig­atoire­ment être pub­liés les doc­u­ments ou parties de doc­u­ments qui échap­pent à l’ob­lig­a­tion de pub­lic­a­tion parce que des mo­tifs par­ticuli­ers le jus­ti­fi­ent, not­am­ment tirés de la lé­gis­la­tion sur la pro­tec­tion des don­nées ou de la lé­gis­la­tion sur la trans­par­ence.

Art. 11 Publication du code source et de la documentation du système et de son exploitation  

1 Le can­ton veille à ce que soi­ent pub­liés les élé­ments suivants:

a.
le code source du lo­gi­ciel du sys­tème, y com­pris les fichiers con­ten­ant les para­mètres per­tin­ents;
b.
une pièce jus­ti­fic­at­ive at­test­ant que les pro­grammes lis­ibles par ma­chine ont été créés au moy­en du code source du lo­gi­ciel tel qu’il a été pub­lié;
c.
la doc­u­ment­a­tion du lo­gi­ciel;
d.
la doc­u­ment­a­tion du pro­ces­sus de dévelop­pe­ment;
e.
les guides et autres doc­u­ment­a­tions com­plé­mentaires, afin que les per­sonnes dis­posant des con­nais­sances né­ces­saires puis­sent com­piler, faire fonc­tion­ner et ana­lys­er le sys­tème dans leur propre in­fra­struc­ture au moy­en du code source;
f.
les spé­ci­fic­a­tions tech­niques des prin­ci­paux com­posants du sys­tème;
g.
la doc­u­ment­a­tion des pro­ces­sus d’ex­ploit­a­tion, de main­ten­ance et de sé­cur­ité du sys­tème;
h.
les in­form­a­tions et de­scrip­tifs con­cernant les failles iden­ti­fiées.

2 Ne doivent pas ob­lig­atoire­ment être pub­liés:

a.
le code source de com­posants tiers tels que des sys­tèmes d’ex­ploit­a­tion, des bases de don­nées, des serveurs web et des serveurs d’ap­plic­a­tion, des sys­tèmes de ges­tion des droits, des pare-feu et des routeurs, pour autant que ces com­posants soi­ent util­isés à grande échelle et qu’ils soi­ent mis à jour en per­man­ence;
b.
le code source des por­tails de cy­berad­min­is­tra­tion qui sont reliés au sys­tème;
c.
les doc­u­ments ou parties de doc­u­ments qui échap­pent à l’ob­lig­a­tion de pub­lic­a­tion parce que des mo­tifs par­ticuli­ers le jus­ti­fi­ent, not­am­ment tirés de la lé­gis­la­tion sur la pro­tec­tion des don­nées ou de la lé­gis­la­tion sur la trans­par­ence.
Art. 12 Modalités de publication  

1 Les élé­ments à pub­li­er con­formé­ment à l’art. 11 doivent être pré­parés et doc­u­mentés de façon à fa­ci­liter autant que pos­sible leur lec­ture et leur ana­lyse.

2 Pour per­mettre au pub­lic d’ap­pré­ci­er les élé­ments à pub­li­er, il est fait en sorte que ceux-ci:

a.
soi­ent ac­cess­ibles en ligne fa­cile­ment, gra­tu­ite­ment et sans ob­lig­a­tion d’en­re­gis­trement, et
b.
soi­ent dispon­ibles suf­f­is­am­ment longtemps av­ant l’util­isa­tion prévue du sys­tème.

3 Toute per­sonne a le droit d’ex­am­iner, de mod­i­fi­er, de com­piler et d’ex­écuter le code source à des fins idéales et de lui con­sacrer des études. Elle peut pub­li­er des études et des con­stata­tions sur les failles. Elle a égale­ment le droit d’échanger avec d’autres per­sonnes pour recherch­er des failles et de citer tout ou partie des in­form­a­tions pub­liées.

4 Le pro­priétaire du code source peut:

a.
autor­iser l’util­isa­tion du code source à d’autres fins;
b.
sou­mettre à des con­di­tions par­ticulières la fourniture d’in­dic­a­tions sur les moy­ens d’améliorer le sys­tème; il peut ain­si in­viter à sig­naler toute faille au plus vite et à ob­serv­er un cer­tain délai pour les pub­lic­a­tions con­sac­rées à des failles sup­posées.

5 S’il sou­met le code source et la doc­u­ment­a­tion à des con­di­tions d’util­isa­tion ou s’il pré­voit des con­di­tions au sens de l’al. 4, let. b, il ne peut pour­suivre leur vi­ol­a­tion civile­ment ou pénale­ment que si le code source est util­isé en tout ou partie à des fins com­mer­ciales ou pro­duct­ives. Les con­di­tions pré­citées doivent pré­ciser ce point.

Art. 13 Participation du public  

1 Le can­ton désigne un ser­vice auquel le pub­lic peut fournir des in­dic­a­tions sur les moy­ens d’améliorer le sys­tème, not­am­ment:

a.
des in­dic­a­tions con­cernant des er­reurs dans les élé­ments qui doivent être pub­liés en vertu de l’art. 11;
b.
des in­dic­a­tions re­posant sur des tent­at­ives d’in­tru­sion dans le sys­tème en ligne ef­fec­tuées dans le cadre de tests pub­lics.

2 Le ser­vice visé à l’al. 1 évalue les in­dic­a­tions reçues et in­forme les per­sonnes qui les ont fournies des con­clu­sions qu’il en a tirées et des mesur­es qui pour­ront être prises à partir de ces in­dic­a­tions. Ces in­form­a­tions sont pub­liées.

3 Le can­ton veille à ce que les in­dic­a­tions qui touchent à la sé­cur­ité et qui per­mettent d’améliorer le sys­tème soi­ent rémun­érées de man­ière équit­able.

Art. 14 Responsabilité et compétences à l’égard du bon déroulement du scrutin électronique  

1 Le can­ton as­sume la re­sponsab­il­ité générale du bon déroul­e­ment du scru­tin élec­tro­nique.

2 Il ex­écute lui-même les tâches prin­cip­ales. Il peut déléguer à des en­tités ex­térieures le dévelop­pe­ment du lo­gi­ciel util­isé, les tâches liées à l’ex­ploit­a­tion et la com­mu­nic­a­tion sur le fonc­tion­nement du sys­tème.

3 Il désigne un ser­vice com­pétent au niveau can­ton­al qui as­sume la re­sponsab­il­ité générale du scru­tin et veille not­am­ment à la bonne ex­écu­tion des tâches suivantes:

a.
ét­ab­lir une dir­ect­ive glob­ale sur la sé­cur­ité de l’in­form­a­tion;
b.
ét­ab­lir une dir­ect­ive sur la clas­si­fic­a­tion et le traite­ment de l’in­form­a­tion pour les res­sources in­form­a­tion­nelles iden­ti­fiées;
c.
ét­ab­lir une dir­ect­ive sur la ges­tion du risque;
d.
définir et mettre en œuvre les mesur­es per­met­tant d’as­surer la con­form­ité aux dir­ect­ives visées aux let. a à c;
e.
man­dater l’ex­ploit­ant d’un sys­tème et définir les ex­i­gences ap­plic­ables à sa sur­veil­lance et à son con­trôle;
f.
fix­er les délais ap­plic­ables à l’ex­écu­tion d’ac­tions et d’opéra­tions cri­tiques;
g.
sur­veiller et véri­fi­er les travaux ef­fec­tués par l’ex­ploit­ant du sys­tème;
h.
ac­com­pag­n­er et in­stru­ire les véri­fic­ateurs;
i.
évalu­er et com­mu­niquer l’ex­actitude des ré­sultats du scru­tin sur la base des preuves visées à l’art. 5 et d’autres in­dic­ateurs.

4 Pendant la tenue d’un scru­tin, les unités d’ex­ploit­a­tion ré­pond­ent devant le can­ton du bon fonc­tion­nement du vote élec­tro­nique et de la bonne ges­tion de ses as­pects tech­niques.

5 Les véri­fic­ateurs com­pétents selon le droit can­ton­al ré­pond­ent du bon fonc­tion­nement de leurs dis­pos­i­tifs tech­niques.

Art. 15 Documents à joindre aux demandes  

1 Aux de­mandes présentées en vertu de l’art. 27e ODP dev­ront être joints les in­form­a­tions con­cernant l’util­isa­tion prévue du sys­tème de vote élec­tro­nique et les doc­u­ments qui at­testent que les ex­i­gences lé­gales sont re­m­plies. Il s’agit not­am­ment des doc­u­ments suivants:

a.
les ap­pré­ci­ations des risques les plus ré­cen­tes au sens de l’art. 4, y com­pris les élé­ments né­ces­saires à leur com­préhen­sion;
b.
les cer­ti­ficats, y com­pris leurs an­nexes, qui ont été ét­ab­lis dans le cadre de l’art. 10, al. 2, et les in­form­a­tions at­test­ant de leur pub­lic­a­tion con­formé­ment à l’art. 10, al. 4;
c.
les in­form­a­tions con­cernant la pub­lic­a­tion des élé­ments visés à l’art. 11 et les in­dic­a­tions fournies par le pub­lic en vertu de l’art. 13;
d.
les pro­to­coles des tests qui ont été ef­fec­tués par le can­ton, et les in­dic­a­tions sug­gérant l’ex­ist­ence de failles af­fect­ant le sys­tème;
e.
les rais­ons pour lesquelles cer­taines ex­i­gences n’ont pas été re­m­plies et les mesur­es de re­m­place­ment prévues, con­formé­ment à l’art. 16, al. 2.

2 Lor­sque la ChF a déjà en sa pos­ses­sion les doc­u­ments visés à l’al. 1 et qu’ils sont en­core val­ides, il pourra suf­fire d’y ren­voy­er.

Art. 16 Autres dispositions  

1 Les ex­i­gences tech­niques et ad­min­is­trat­ives à re­m­p­lir pour or­gan­iser un scru­tin élec­tro­nique sont dé­taillées dans l’an­nexe.

2 La ChF peut ex­cep­tion­nelle­ment dis­penser un can­ton de re­m­p­lir cer­taines ex­i­gences s’il re­specte les trois con­di­tions suivantes:

a.
il sig­nale comme tell­es dans la de­mande les ex­i­gences qu’il n’a pas re­m­plies;
b.
il ex­pose de man­ière plaus­ible les rais­ons pour lesquelles il n’a pas re­m­pli ces ex­i­gences;
c.
il décrit les mesur­es de re­m­place­ment qu’il pren­dra et, s’agis­sant de l’ap­pré­ci­ation des risques, in­dique les rais­ons pour lesquelles il con­sidère que ceux-ci sont suf­f­is­am­ment faibles.
Art. 17 Abrogation d’un autre acte  

L’or­don­nance de la ChF du 13 décembre 2013 sur le vote élec­tro­nique2 est ab­ro­gée.

Art. 18 Entrée en vigueur  

La présente or­don­nance entre en vi­gueur le 1er juil­let 2022.

Exigences techniques et administratives applicables au vote électronique

1. Définitions

En complément de l’art. 2, on entend par:

1.1
garantie du secret du vote: situation qui prévaut lorsque aucune personne et aucun composant n’a accès aux données suivantes:
1.1.1.
suffrages émis ou données permettant de déduire le contenu de suffrages émis,
1.1.2.
données permettant d’identifier le votant (données concernant les électeurs), et
1.1.3.
données permettant d’attribuer les données concernant les électeurs aux suffrages émis;
1.2
impossibilité d’établir des résultats partiels anticipés: situation qui prévaut lorsque aucune personne et aucun composant n’a accès de manière anticipée aux suffrages émis ou à des données permettant de déduire les suffrages émis;
1.3
référence de vérification: informations fournies avec le matériel de vote qui doivent permettre aux électeurs de vérifier conformément à l’art. 5, al. 2, en rel. avec le ch. 2.5 de l’annexe, que leur suffrage a été émis correctement (par ex. une liste contenant un code pour chaque réponse possible);
1.4
attaquant externe: personne ou groupe de personnes externe à la conception et à l’exploitation du système et disposant de ressources et de compétences techniques moyennes et qui mène une attaque; ses motivations peuvent comprendre l’activisme ou l’appât du gain;
1.5
attaquant interne: personne ou groupe de personnes impliqués dans la conception ou l’exploitation du système et qui mène une attaque; ses motivations peuvent comprendre l’activisme, l’appât du gain ou la volonté de nuire à son employeur;
1.6
organisation hostile: groupe de personnes disposant de moyens étendus et menant une attaque, qu’il soit soutenu par un État ou non; ses compétences, ou du moins celles de ses membres, sont élevées; elle peut avoir pour motivations la collecte de données à des fins de profilage, la perturbation d’un scrutin ou l’altération de ses résultats;
1.7
attaquant: personne, groupe de personnes ou organisation au sens des ch. 1.4 à 1.6;
1.8
urne électronique: zone de stockage dans laquelle les suffrages émis sont conservés jusqu’au déchiffrement et au dépouillement;
1.9
journal système: journal créé par les éléments de l’infrastructure et destiné à permettre la surveillance du fonctionnement du système et l’analyse des incidents.

2. Exigences applicables au protocole cryptographique pour la vérifiabilité complète (art. 5)

2.1
Participants du système

Le protocole cryptographique doit régler les tâches des participants abstraits suivants:

électeur / votant
plate-forme utilisateur
composant de configuration
système non fiable (composants quelconques, à l’exclusion des autres composants énumérés sous le présent chiffre; système NF)
composant d’impression
un ou plusieurs groupes de composants de contrôle
vérificateurs
dispositif technique des vérificateurs
2.2
Canaux de communication

Le protocole cryptographique peut prévoir les canaux de communication suivants pour l’échange de messages entre les participants du système:

électeur / votant ↔ plate-forme utilisateur
plate-forme utilisateur ↔ système NF
composant de configuration ↔ système NF
composant de contrôle ↔ système NF
système NF → composant d’impression
système NF → dispositif technique des vérificateurs
composant d’impression → électeur / votant
composant de configuration → dispositif technique des vérificateurs
vérificateurs ↔ dispositif technique des vérificateurs
canaux bidirectionnels pour la communication entre les composants de contrôle
2.3
Attaquant
2.3.1
Le protocole cryptographique doit protéger contre un attaquant qui tente d’influer abusivement sur les suffrages et sur le résultat, de compromettre le secret du vote ou d’établir des résultats partiels de manière anticipée (ch. 2.5 à 2.8).
2.3.2
Il doit reposer sur l’hypothèse qu’un attaquant possède les capacités suivantes:
Il peut prendre sous son contrôle tous les participants non fiables du système (voir ch. 2.4) de façon à les amener à partager avec lui toutes les données secrètes et à agir selon toutes ses instructions.
Il peut lire ou supprimer tous les messages qui sont échangés sur des canaux non fiables et envoyer des messages à loisir.
2.4
Participants du système et canaux de communication fiables et non fiables
2.4.1
Les participants du système et les canaux de communication sont considérés soit comme «fiables» soit comme «non fiables». Les hypothèses de confiance licites pour les différents participants du système sont réglées au ch. 2.9.
2.4.2
Les participants du système et les canaux de communication fiables sont considérés comme protégés contre un attaquant. Les hypothèses suivantes, notamment, peuvent s’appliquer au protocole cryptographique:
Les participants fiables du système conservent de façon sécurisée les données confidentielles et n’effectuent que les opérations prescrites dans le protocole cryptographique.
Les canaux de communication fiables conservent de façon sécurisée les messages transmis et les protègent contre toute manipulation.
2.5
Exigence applicable au protocole cryptographique: vérifiabilité individuelle

L’électeur reçoit des preuves au sens de l’art. 5, al. 2, en rel. avec l’art. 6, let. a et b, qui attestent qu’un attaquant:

n’a modifié ou fait disparaître aucun suffrage partiel de l’électeur jusqu’à son enregistrement en tant que suffrage émis conformément à la procédure prévue par le système;
n’a pas abusivement émis au nom de l’électeur de suffrage ayant ensuite été enregistré et comptabilisé en tant que suffrage émis conformément à la procédure prévue par le système.
2.6
Exigence applicable au protocole cryptographique: vérifiabilité universelle

Les vérificateurs reçoivent des preuves au sens de l’art. 5, al. 3, let. a, en rel. avec l’art. 6, let. a et c, qui attestent qu’un attaquant:

n’a modifié ou fait disparaître aucun suffrage partiel jusqu’au calcul des résultats, après que les suffrages correspondants ont été enregistrés comme ayant été émis conformément à la procédure prévue par le système;
n’a ajouté ni suffrage ni suffrage partiel non émis conformément à la procédure prévue par le système, qui ont été pris en compte dans le calcul des résultats.
2.7
Exigences applicables au protocole cryptographique: secret du vote et impossibilité d’établir des résultats partiels anticipés
2.7.1
Un attaquant ne doit pouvoir ni compromettre le secret du vote ni établir des résultats partiels de manière anticipée sans devoir en plus prendre sous son contrôle les électeurs ou leurs plates-formes utilisateur.
2.7.2
Il n’est pas obligatoire d’empêcher les attaques qui limitent le nombre des suffrages dépouillés de telle manière que tous les suffrages partiels soient les mêmes pour une question soumise au vote, une liste ou un candidat.
2.7.3
Un attaquant ne doit pas pouvoir prendre sous son contrôle de manière inaperçue les plates-formes utilisateur en manipulant sur le serveur le logiciel pour les plates-formes utilisateur. Le votant doit à cet égard avoir la possibilité de vérifier si sa plate-forme utilisateur a reçu du serveur le logiciel correct avec les paramètres corrects, notamment la clef publique destiné à chiffrer le suffrage.
2.8
Exigence applicable au protocole cryptographique: authentification efficace

Un attaquant ne doit pouvoir émettre de suffrage conformément à la procédure prévue par le système sans prendre sous son contrôle les électeurs correspondants.

2.9
Liste des participants fiables et non fiables du système
2.9.1
Concernant le caractère concluant des preuves au sens du ch. 2.5
2.9.1.1
Les participants du système suivants sont considérés comme non fiables:
plate-forme utilisateur
système NF
trois des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lesquels
un pourcentage significatif des électeurs
les vérificateurs
les dispositifs techniques des vérificateurs
2.9.1.2
Les participants du système suivants peuvent être considérés comme fiables:
composant de configuration
composant d’impression
un des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lequel
2.9.2
Concernant le caractère concluant des preuves au sens du ch. 2.6
2.9.2.1
Les participants du système suivants sont considérés comme non fiables:
plate-forme utilisateur
système NF
trois des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lesquels
un pourcentage significatif des électeurs
composant de configuration
composant d’impression
2.9.2.2
Les participants du système suivants peuvent être considérés comme fiables:
un des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lequel
un vérificateur d’un groupe, sans qu’il soit nécessaire de déterminer lequel
un dispositif technique d’un vérificateur fiable, sans qu’il soit nécessaire de déterminer lequel
2.9.3
Concernant le secret du vote et l’impossibilité d’établir des résultats partiels anticipés au sens du ch. 2.7
2.9.3.1
Les participants du système suivants sont considérés comme non fiables:
système NF
trois des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lesquels
un pourcentage significatif des électeurs
les vérificateurs
les dispositifs techniques des vérificateurs
2.9.3.2
Les participants du système suivants peuvent être considérés comme fiables:
composant de configuration
composant d’impression
plate-forme utilisateur
un des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lequel
2.9.3.3
Si un groupe entier de composants de contrôle est mis en œuvre par un exploitant du système privé, aucun de ces composants ne peut être considéré comme fiable.
2.9.4.
Concernant l’efficacité de l’authentification au sens du ch. 2.8
2.9.4.1
Les participants du système suivants sont considérés comme non fiables:
système NF
trois des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lesquels
un pourcentage significatif des électeurs
les vérificateurs
les dispositifs techniques des vérificateurs
plate-forme utilisateur
2.9.4.2
Les participants du système suivants peuvent être considérés comme fiables:
composant de configuration
composant d’impression
un des quatre composants de contrôle par groupe, sans qu’il soit nécessaire de déterminer lequel
2.10
Liste des canaux de communication fiables et non fiables
2.10.1
Les canaux de communication suivants sont considérés comme non fiables:
plate-forme utilisateur ↔ système NF
composant de configuration ↔ système NF
composant de contrôle ↔ système NF
système NF → composant d’impression
système NF → dispositif technique des vérificateurs
canaux bidirectionnels pour la communication entre les composants de contrôle
2.10.2
Les canaux de communication suivants peuvent être considérés comme fiables:
électeur / votant ↔ plate-forme utilisateur
dispositif technique des vérificateurs ↔ vérificateurs
composant de configuration → dispositif technique des vérificateurs
composant d’impression → électeur / votant
2.11
Exigences supplémentaires applicables au caractère concluant des preuves
2.11.1
La probabilité qu’un attaquant puisse falsifier une preuve au sens du ch. 2.5 en modifiant un suffrage partiel, en faisant disparaître un suffrage partiel ou en émettant un suffrage au nom d’un tiers, ne peut dépasser 0,1 %.
2.11.2
La probabilité qu’un attaquant puisse falsifier une preuve au sens du ch. 2.6 en modifiant ou en faisant disparaître un suffrage émis conformément à la procédure prévue par le système ou en ajoutant un suffrage non émis conformément à cette procédure de façon que le résultat établi s’écarte de 0,1 % du résultat correct ne peut dépasser 1 % par projet, choix de liste ou choix d’un candidat sur une liste.
2.11.3
Si la probabilité qu’un attaquant puisse falsifier une preuve au sens du ch. 2.6 n’est pas négligeable au sens cryptographique3, la probabilité qu’il réussisse doit pouvoir être réduite à loisir au moyen de plusieurs décomptes, les vérificateurs devant recevoir pour chaque décompte une preuve supplémentaire et indépendante au sens du ch. 2.6.
2.12
Exigences fonctionnelles applicables au processus de vote ayant des incidences sur le protocole cryptographique
2.12.1
Les données d’authentification qui sont attribuées à un électeur ne permettent d’émettre qu’un seul suffrage.
2.12.2
Le votant saisit son suffrage dans la plate-forme utilisateur.
2.12.3
Le votant peut modifier et vérifier au moyen d’une vue d’ensemble son suffrage jusqu’à ce qu’il décide de l’émettre.
2.12.4
Une fois que le votant a eu la possibilité de vérifier son suffrage au moyen de la vue d’ensemble, il indique dans la plate-forme utilisateur qu’il souhaite émettre son suffrage tel qu’il l’a saisi.
2.12.5
Les preuves que le suffrage a été correctement émis au sens du ch. 2.5 doivent se structurer en au moins deux preuves partielles séquentielles. Chacune des indications présentées comme une preuve partielle doit constituer une véritable contribution au caractère concluant des preuves au sens du ch. 2.5.
2.12.6
La plate-forme utilisateur indique au votant la première preuve partielle après que celui-ci a saisi dans la plate-forme utilisateur son intention d’émettre son suffrage.
2.12.7
La plate-forme utilisateur n’indique au votant la seconde preuve partielle qu’une fois que celui-ci a confirmé au moyen d’une saisie dans la plate-forme utilisateur que la preuve partielle précédente était correcte.
2.12.8
En confirmant que l’avant-dernière preuve partielle était correcte, le votant déclare vouloir émettre son suffrage de manière définitive.
2.12.9
Dès qu’il a reçu confirmation que le votant veut émettre son suffrage de manière définitive, le groupe de composants de contrôle enregistre le suffrage comme ayant été émis conformément à la procédure prévue par le système.
2.12.10
Lorsque le votant a vérifié la dernière preuve partielle et si le résultat est positif, l’opération de vote est terminée. La dernière preuve partielle doit être particulièrement facile à vérifier, cette vérification consistant autant que possible dans l’affichage correct d’un code unique ou de toute autre indication simple.
2.12.11
Si des données de vote sont importées, un composant de configuration ou un composant d’impression ne peut plus à partir de ce moment être considéré comme fiable.
2.13
Exigences applicables à la définition et à la description du protocole cryptographique
2.13.1
On utilisera lorsque cela sera possible des éléments qui sont largement utilisés dans le monde et qui ont été vérifiés de manière approfondie par des personnes compétentes. De même, on pourra faire appel à titre de comparaison à des standards, des projets de référence et des publications scientifiques. Tout écart par rapport à la norme ou toute incertitude seront traités à part dans le cadre de l’appréciation des risques visés à l’art. 4.
2.13.2
Les instructions doivent être suffisamment précises: chacune d’elles devra limiter les possibilités de mise en œuvre de telle sorte que chaque mise en œuvre autorisée par l’instruction correspondante soit également conforme aux exigences applicables au protocole cryptographique.
2.13.3
Les canaux fiables peuvent être utilisés pour la distribution de certificats électroniques entre les participants au système. Le ch. 3.8 s’applique.
2.14
Preuves de conformité aux exigences applicables au protocole cryptographique
2.14.1
Une preuve de conformité symbolique et une preuve de conformité cryptographique doivent attester que le protocole cryptographique respecte les exigences visées aux ch. 2.1 à 2.12.
2.14.2
Ces preuves de conformité doivent se référer directement à la description du protocole qui sert de base pour le développement du système.
2.14.3
En ce qui concerne les éléments de base cryptographiques, les preuves de conformité peuvent être administrées dans le cadre d’hypothèses et de constructions de sécurité généralement admises (comme le modèle de l’oracle aléatoire, l’hypothèse décisionnelle de Diffie-Hellman ou l’heuristique de Fiat-Shamir).

3 Correspond à peu près à la probabilité de décrypter, sans connaître la clef, une valeur ayant été chiffrée avec un algorithme réputé sûr et un paramétrage correspondant.

3. Exigences applicables aux composants fiables au sens du ch. 2 et à leur exploitation

3.1
L’exploitation du composant de configuration et d’au moins un composant de contrôle du groupe contenant une partie de la clef destinée à déchiffrer les suffrages doit relever directement du canton et intervenir dans son infrastructure. Toute sous-traitance à l’exploitant d’un système privé est interdite.
3.2
On veillera à utiliser une entropie suffisante pour le choix de valeurs aléatoires concernant, notamment, les composants de configuration et les composants de contrôle.
3.3
Les vérificateurs doivent contrôler au moins une fois les preuves au sens du ch. 2.6 et utiliser à cet effet un dispositif technique au sens du ch. 2.
3.4
Les exigences d’exploitation pour les composants de configuration visés au ch. 3 s’appliquent également aux dispositifs techniques des vérificateurs. Ceux-ci peuvent prévoir des dérogations dans le cadre de leurs compétences telles qu’elles sont définies par le droit cantonal.
3.5
À l’exception des composants mentionnés aux ch. 3.1 et 3.3, le canton peut déléguer l’exploitation de n’importe quelle partie du système, y compris les composants de contrôle et le composant d’impression, à des prestataires de services privés. Un exploitant privé du composant d’impression ne peut effectuer que les tâches opérationnelles qui constituent une condition préalable à la préparation, au conditionnement et à la livraison.
3.6
Les composants fiables (composants de configuration, composants d’impression, dispositifs techniques des vérificateurs et composants de contrôle) doivent être mis en place, mis à jour, configurés et sécurisés dans un processus observable.
3.7
Avant d’installer un logiciel, il faut vérifier pour tous les programmes au moyen d’une source fiable officielle si la version des fichiers est bien la version correcte et non modifiée.
3.8
Lorsque sont installés des certificats électroniques provenant d’autres participants au système, l’authenticité doit être garantie. Il y a lieu à cet effet de prévoir un processus manuel, avec des personnes qui transfèrent les certificats électroniques d’une machine à l’autre via un support de données physique au sens du ch. 3.13.
3.9
La date de mise à jour de l’ensemble des logiciels des composants fiables doit être choisie de manière que les avantages attendus l’emportent sur les risques potentiels.
3.10
Les composants de configuration, les composants d’impression et les dispositifs techniques des vérificateurs qui sont impliqués d’une manière ou d’une autre dans le traitement des données critiques doivent être surveillés physiquement selon le principe du double contrôle pendant toute la durée du calcul et jusqu’à la suppression de toute donnée critique ou jusqu’au stockage sécurisé de ces composants et dispositifs. Ils peuvent être interconnectés tout au plus par des câbles physiques visibles, afin qu’il soit autant que possible visible jusqu’à la destruction des données confidentielles qu’aucune autre machine ne peut y accéder.
3.11
Les composants fiables ne doivent pas être connectés à Internet pour installer ou mettre à jour des logiciels.
3.12
En principe, les données critiques doivent être détruites après usage. S’il existe de bonnes raisons à cela, un stockage sécurisé du support de données est également autorisé comme solution alternative.
3.13
Les supports destinés à l’échange ou à la conservation de données, tels que les clefs USB, doivent être retirés après le téléchargement des données vers le composant fiable et ne peuvent être réutilisés avant la destruction des données que si le composant fiable était vierge de données critiques avant le téléchargement.
Avant toute utilisation, les supports d’échange de données doivent être reformatés, et toutes les données détruites, au moyen d’un composant exploité conformément aux exigences applicables aux composants fiables.
3.14
Aucun accès logique ou physique à des composants fiables ou à des supports contenant des données critiques ne doit être possible sans qu’une autre personne en soit informée, par ex. en prévoyant que cet accès ne soit possible qu’avec son concours (double contrôle strict).
3.15
Un accès non autorisé réussi à un composant de contrôle ne doit pas, autant que possible, conférer un avantage dans la tentative d’accéder discrètement à un autre composant de contrôle. En plus des autres exigences prévues au ch. 3, on appliquera les exigences suivantes:
Si une personne dispose d’un accès physique ou logique à un composant de contrôle, elle ne doit avoir accès à aucun autre composant de contrôle.
Le matériel, les systèmes d’exploitation et les systèmes de surveillance des composants de contrôle doivent autant que possible être différents.
Les composants de contrôle doivent être connectés à plusieurs réseaux locaux différents.
Un composant de contrôle doit être matérialisé par un appareil physique. Une virtualisation réalisée au moyen de plusieurs appareils physiques n’est pas admise.
3.16
Les composants de contrôle doivent être conçus pour détecter les accès non autorisés et alerter les personnes responsables. Les personnes responsables doivent prévoir des mesures de surveillance externe, telles que la surveillance et l’enregistrement inviolable du trafic réseau ou la surveillance physique au moyen de caméras placées sous leur contrôle. Les personnes responsables doivent être considérées comme particulièrement loyales et dignes de confiance.
3.17
Les composants fiables ne doivent effectuer que les opérations prévues.
3.18
Le logiciel du dispositif technique des vérificateurs doit provenir d’un autre développeur de système que celui qui a développé la plupart des logiciels des autres composants du système. La publication du logiciel du dispositif technique sous une licence répondant aux critères des logiciels libres4 peut justifier une exception. Si les vérificateurs utilisent plusieurs dispositifs techniques, cette disposition vaut pour au moins l’un des dispositifs.
3.19
Toutes les procédures impliquant des composants fiables doivent être documentées par écrit et d’une manière facile à comprendre pour les personnes concernées.
3.20
Tout accès et toute utilisation d’un composant fiable ou d’un support de données contenant des données critiques doivent être consignés.

4 Voir la définition dans le guide intitulé «Praxis-Leitfaden Open Source Software in der Bundesverwaltung» (en langue allemande), version 1.0 du 19.12.2019, chap. 1; disponible auprès de: Chancellerie fédérale suisse, CH-3003 Berne; www.bk.admin.ch > Transformation numérique et gouvernance de l’informatique > Architecture de la Confédération > Open Source Software (OSS).

4. Procédure de vote

4.1
Le votant déclare avoir pris connaissance des règles du vote électronique et de la responsabilité qui lui incombe.
4.2
Avant de voter, le votant est informé qu’il prend part au scrutin de la même manière que s’il votait par correspondance ou à l’urne. Le votant ne peut émettre son suffrage qu’une fois qu’il a confirmé qu’il en a été informé.
4.3
Lors du vote, le votant est prié de vérifier les preuves au sens du ch. 2.5 au moyen de la référence de vérification et de signaler au canton tout doute qu’il pourrait avoir sur leur exactitude.
4.4
Tant qu’il n’a pas émis définitivement son suffrage par la voie électronique, l’électeur peut voter via un canal de vote classique.
4.5
Le système client tel qu’il se présente à l’électeur n’influence pas la prise de décision de ce dernier.
4.6
La navigation n’encourage pas un vote hâtif ou irréfléchi.
4.7
Le système ne propose pas au votant une fonction lui permettant d’imprimer ou de sauvegarder son suffrage.
4.8
Une fois le vote terminé, le votant ne reçoit aucune information sur le contenu du suffrage chiffré qu’il a émis.
4.9
En ce qui concerne les électeurs qui ne sont pas en mesure de voter parce que des tiers ont utilisé indûment leur matériel de vote pour émettre un suffrage, les cantons peuvent les autoriser à voter malgré tout en déclarant nul le suffrage indûment émis. Le secret du vote au sens du ch. 2.7 doit être garanti.
4.10
En ce qui concerne les électeurs souffrant d’un handicap, il peut être prévu des facilités pour la vérification des preuves. Dans ce cas uniquement, il peut être dérogé aux exigences prévues au ch. 2.9.1.
4.11
Tant que le système n’a pas enregistré de confirmation du vote définitif, un électeur peut voter au moyen d’un canal de vote classique.
4.12
L’utilisation d’une méthode d’authentification indépendante du vote électronique est autorisée. Les effets sur l’intégrité de la vérification de la qualité d’électeur et la garantie du secret du vote doivent être examinés en détail dans le cadre de l’appréciation des risques.

5. Préparation du scrutin

5.1
Si les données du registre des électeurs sont importées depuis un système tiers qui n’est pas sous le contrôle du canton, les données doivent être chiffrées et signées. La signature doit être vérifiée à leur réception. Pour la livraison à l’imprimeur, les dispositions du ch. 7 priment.
5.2
Les données nécessaires à la vérification des preuves conformément au ch. 2.6 sont remises aux vérificateurs.

6. Exigences applicables aux cartes de légitimation

6.1
Les cartes de légitimation doivent être conçues dans la mesure du possible de manière à permettre aux électeurs handicapés d’utiliser facilement le vote électronique.
6.2
Il n’est possible d’utiliser des éléments de sécurité sur la carte de légitimation (par ex. un champ à gratter) que s’il a été attesté que les informations dissimulées sont bien protégées contre toute lecture non autorisée.
6.3
S’il n’est pas utilisé d’éléments de sécurité pour protéger les informations confidentielles sur la carte de légitimation, il faut mettre en place des processus organisationnels pour en garantir la sécurité.

7. Exigences applicables aux imprimeries

7.1
Les fichiers d’impression destinés à la production des cartes de légitimation sont envoyés sous forme chiffrée et signée. Il est également possible de remettre personnellement à l’imprimeur un support de données contenant ces fichiers. En ce cas, le support de données est remis à l’imprimeur par deux personnes qui l’ont surveillé ensemble pendant le transport et jusqu’à la remise (double contrôle).
7.2
Le chiffrement doit répondre aux exigences de la norme eCH 00145, chap. 7.5. En cas de chiffrement symétrique, l’élément secret permettant le déchiffrement est envoyé aux responsables de l’imprimerie via un canal secondaire sécurisé.
7.3
Les responsables de l’imprimerie qui reçoivent le support de données signent un accusé de réception.
7.4
Le support de données contenant les données d’impression, le composant sur lequel les données critiques sont déchiffrées et tous les composants qui traitent les données critiques sont soumis aux dispositions du ch. 3 relatives au composant d’impression.
7.5
Les responsables de l’imprimerie effectuent un contrôle de la quantité de matériel.
7.6
Après avoir imprimé les cartes de légitimation, l’imprimerie détruit les données reçues.
7.7
Si l’imprimerie se charge également de la mise sous pli et de l’expédition des cartes de légitimation, celles-ci doivent être mises sous pli avec le matériel de vote immédiatement après l’impression.
7.8
Le canal entre les imprimeries et les électeurs ne peut être considéré comme fiable que si les organes compétents en vertu du droit cantonal remettent le matériel de vote sous pli aux électeurs par voie postale ou s’assurent qu’il soit remis en mains propres.

5 eCH-0014: «Normes et architectures pour les applications de cyberadministration en Suisse (SAGA.ch) », version 9.0 du 09.12.2019; disponible gratuitement auprès de: Association eCH, Mainaustrasse 30, Postfach, 8034 Zürich, www.ech.ch.

8. Information et assistance

8.1
Le service compétent au niveau cantonal élabore une stratégie pour informer les citoyens sur le vote électronique.
8.2
Cette stratégie garantit que les informations sont autorisées par les organes compétents.
8.3
Sont publiés sur Internet des conseils et des guides sur la manière de voter, ainsi que des informations sur les responsabilités qui incombent aux électeurs. Ils préviennent tout vote hâtif ou irréfléchi.
8.4
La vérifiabilité, les autres mesures de sécurité et les procédures à suivre en cas d’anomalie sont expliquées aux électeurs de manière aisément compréhensible.
8.5
Les électeurs sont informés de ce à quoi ils doivent faire attention pour pouvoir voter en toute sécurité.
8.6
Il est expliqué aux électeurs comment supprimer après le vote leur suffrage dans tous les espaces mémoire de la plate-forme utilisateur sur laquelle ils ont saisi leur vote.
8.7
Les électeurs peuvent demander une assistance en matière de vote électronique.
8.8
Les électeurs sont invités à signaler au service compétent au niveau cantonal les preuves au sens du ch. 2.5, comme les codes de vérification, qui sont affichées de manière incorrecte, ou les autres vérifications dont les résultats sont négatifs. Cette invitation est également diffusée avec le matériel de vote.
8.9
Les électeurs sont invités à conserver de façon sécurisée le matériel de vote contenant les éléments de sécurité visés au sens du ch. 2.5, jusqu’à ce qu’ils aient émis leur vote de manière définitive ou que le scrutin soit clos.
8.10
Les électeurs reçoivent les informations nécessaires pour vérifier l’authenticité du site Internet utilisé pour voter, du serveur ainsi que du logiciel. La pertinence d’une vérification réussie doit être étayée par l’utilisation de moyens cryptographiques conformes aux meilleures pratiques.
8.11
Les informations essentielles pour garantir un vote sécurisé sont envoyées avec le matériel de vote. Il est expliqué aux électeurs qu’en cas de doute, ils doivent se référer aux informations qui sont fournies avec le matériel de vote et non à celles qui s’affichent sur la plate-forme utilisateur.
8.12
Il est expliqué aux électeurs par quels moyens le secret du vote est assuré.
8.13
Toute faille identifiée et les mesures qu’elle appelle sont communiquées de manière transparente.
8.14
Les vérificateurs doivent être informés et formés de manière adéquate sur les processus dont dépendent l’exactitude du résultat, la garantie du secret du vote et l’impossibilité d’établir des résultats partiels anticipés (par ex. la génération des clefs, l’impression du matériel de vote, le déchiffrement et le dépouillement). Ils sont capables de comprendre les points essentiels des processus et leur signification.

9. Ouverture et fermeture du canal de vote électronique

Le canal de vote électronique n’est disponible que pendant la période autorisée.

10. Contrôle de conformité et enregistrement des suffrages définitifs

Un suffrage qui n’a pas été émis conformément à la procédure prévue par le système n’est pas enregistré dans l’urne électronique.

11. Dépouillement de l’urne électronique

11.1
Le déchiffrement et le dépouillement des suffrages ne peuvent commencer avant le dimanche de l’élection ou de la votation.
11.2
Le canton effectue le déchiffrement et le dépouillement dans sa propre infrastructure.
11.3
Le canton veille à ce que le déchiffrement et le dépouillement des suffrages donnent lieu à procès-verbal. Le service compétent au niveau cantonal approuve ce procès-verbal.
11.4
Depuis le déchiffrement des suffrages jusqu’à la transmission du résultat du scrutin, tout accès au système ou à l’un de ses composants est effectué par au moins deux personnes; il est consigné par écrit et doit pouvoir être contrôlé par les vérificateurs.
11.5
Si les données de résultats sont envoyées à un système tiers qui n’est pas sous le contrôle du canton, ces données sont chiffrées et signées.
11.6
Le système permet d’utiliser la carte de légitimation pour déterminer si une personne a émis un suffrage par voie électronique.
11.7
Les vérificateurs sont présents pendant le déchiffrement et le dépouillement. Les cantons peuvent permettre des travaux de contrôle à distance.
11.8
Les composants utilisés pour le dépouillement des suffrages sont soumis aux mêmes exigences que celles qui s’appliquent aux composants de configuration au sens du ch. 3 s’ils ne sont pas fiables au sens du ch. 2.4.
11.9
Les vérificateurs exercent leurs responsabilités conformément au droit cantonal lorsqu’ils procèdent à la vérification des preuves au sens du ch. 2.6.
11.10
Le service compétent au niveau cantonal soumet aux vérificateurs tous les indicateurs pertinents pour l’exactitude du résultat. Outre les preuves au sens du ch. 2.6, il s’agit notamment du nombre et du type d’anomalies signalées au canton par les électeurs.
11.11
Le canton anticipe les anomalies éventuelles et élabore, en concertation avec les acteurs concernés, un plan d’urgence précisant la conduite à tenir. Il veille à la transparence vis-à-vis du public.
11.12
Dans la mesure où elles sont disponibles et où la base de données le permet, des méthodes statistiques seront utilisées pour établir la plausibilité des résultats.

12. Données confidentielles

12.1
Il est fait en sorte que ni les collaborateurs ni les personnes extérieures n’aient connaissance de données permettant d’établir un lien entre l’identité du votant et le suffrage qu’il a émis.
12.2
Il est fait en sorte que ni les collaborateurs ni les personnes extérieures n’aient connaissance avant le déchiffrement des suffrages de données permettant d’établir des résultats partiels de manière anticipée.
12.3
Le canton ne peut pas transmettre à des entreprises privées la part de la clef de déchiffrement des suffrages qu’il détient en vertu du ch. 3.1 sur le composant de contrôle qu’il exploite.
12.4
Le canton traite les résultats du scrutin de manière confidentielle depuis le moment où les suffrages sont déchiffrés jusqu’à celui de la publication.
12.5
Le canton fait en sorte que soient traitées de manière confidentielle les données qui permettent de déterminer si un électeur a voté par voie électronique.
12.6
Le canton traite les différents suffrages de manière confidentielle après le dépouillement.
12.7
Le canton veille à ce que les résultats des votations et des élections organisées dans les circonscriptions de petite taille soient traités de manière confidentielle.
12.8
Après la validation sont détruites selon un processus préétabli et documenté, toutes les données qui ont été créées au cours du scrutin électronique, qui concernent les différents suffrages enregistrés et qui sont classées comme confidentielles.

13. Menaces

13.1
Les menaces énumérées aux ch. 13.3 à 13.40 sont des menaces d’ordre général et constituent un socle qu’il y a lieu de compléter. Elles se rapportent aux objectifs de sécurité et doivent être prises en compte dans le cadre de l’identification des risques. Selon les vulnérabilités du système qui seront détectées et compte tenu des appréciations des risques des différents services, il y aura lieu de préciser et de compléter cette liste au vu de la constellation en présence et des menaces effectives.
13.2
Sont réputées menaces potentielles:
les menaces accidentelles ou délibérées émanant d’acteurs humains internes ou externes utilisant des moyens électroniques ou physiques;
les menaces résultant d’un dysfonctionnement du système ou des éléments de support du système.

Description

Objectif de sécurité concerné
(au sens de l’art. 4, al. 3)

13.3

Un logiciel malveillant modifie le suffrage sur la plate-forme de l’utilisateur.

Exactitude des résultats

13.4

Un attaquant externe détourne le suffrage au moyen d’un empoisonnement du cache DNS6.

Exactitude des résultats

13.5

Un attaquant externe modifie le suffrage au moyen de la technique de «l’homme du milieu», ou «MITM»7.

Exactitude des résultats

13.6

Un attaquant externe envoie au moyen d’une attaque MITM des données corrompues qui sont nécessaires pour émettre le suffrage et qui proviennent du système en ligne (par ex. un fichier Javascript).

Exactitude des résultats

13.7

Un attaquant interne manipule le logiciel, qui n’enregistre alors plus les suffrages.

Exactitude des résultats

13.8

Un attaquant interne modifie, supprime ou multiplie les suffrages.

Exactitude des résultats

13.9

Un attaquant interne ajoute des suffrages dans l’urne électronique.

Exactitude des résultats

13.10

Une organisation hostile pénètre dans le système pour fausser le résultat.

Exactitude des résultats

13.11

Un attaquant interne copie du matériel de vote et l’utilise.

Exactitude des résultats

13.12

Un attaquant externe utilise des méthodes relevant de l’ingénierie sociale pour détourner l’attention du votant des mesures de sécurité (vérifiabilité individuelle).

Exactitude des résultats

13.13

Un attaquant externe pénètre électroniquement, physiquement ou au moyen de procédés d’ingénierie sociale dans l’infrastructure du canton et manipule les composants de configuration ou s’empare de données de sécurité.

Exactitude des résultats

13.14

Un attaquant externe pénètre électroniquement, physiquement ou au moyen de procédés d’ingénierie sociale dans l’infrastructure de l’imprimerie et s’empare des codes des cartes de légitimation.

Exactitude des résultats

13.15

Un attaquant externe pénètre électroniquement, physiquement ou au moyen de procédés d’ingénierie sociale dans l’infrastructure de La Poste et s’empare de cartes de légitimation.

Exactitude des résultats

13.16

Une erreur se produit dans la vérifiabilité individuelle.

Exactitude des résultats

13.17

Une erreur se produit dans la vérifiabilité universelle.

Exactitude des résultats

13.18

Un dispositif technique des vérificateurs comporte une erreur.

Exactitude des résultats

13.19

Une «porte dérobée»8 est introduite dans le système via une dépendance logicielle et est mise à profit par un attaquant externe pour accéder au système.

Exactitude des résultats, garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés, accessibilité et capacité opérationnelle du vote électronique, protection contre les manipulations des informations destinées aux électeurs, pas d’usage abusif des preuves relatives au comportement de vote

13.20

Un logiciel malveillant installé sur la plate-forme utilisateur envoie le suffrage à une organisation hostile.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.21

Le suffrage est détourné au moyen d’un empoisonnement du cache DNS.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.22

Un attaquant externe lit le suffrage au moyen d’une attaque MITM.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.23

Un attaquant interne utilise la clef et déchiffre des suffrages non anonymisés.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.24

Le secret du vote est violé lors de la vérification de l’exactitude du traitement et du dépouillement.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.25

Un attaquant interne lit des suffrages de manière anticipée sans devoir les déchiffrer.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.26

Une organisation hostile pénètre dans le système pour violer le secret du vote ou pour établir des résultats partiels de manière anticipée.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.27

Une erreur dans le processus de chiffrement rend celui-ci inopérant ou réduit son efficacité.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.28

Un attaquant interne manipule le logiciel et celui-ci divulgue les suffrages.

Garantie du secret du vote et impossibilité d’établir des résultats partiels anticipés

13.29

Un logiciel malveillant installé sur l’ordinateur de l’électeur empêche ce dernier de voter.

Accessibilité et capacité opérationnelle du canal de vote

13.30

Une organisation hostile mène une attaque du type «déni de service» (DOS)9.

Accessibilité et capacité opérationnelle du canal de vote

13.31

Un attaquant interne configure mal le système; le dépouillement ne peut pas se faire.

Accessibilité et capacité opérationnelle du canal de vote

13.32

Un attaquant interne falsifie les preuves cryptographiques de la vérifiabilité universelle.

Accessibilité et capacité opérationnelle du canal de vote

13.33

Une défaillance technique du système fait que le système n’est pas disponible au moment du dépouillement.

Accessibilité et capacité opérationnelle du canal de vote

13.34

Un dispositif technique des vérificateurs ne fonctionne pas au moment du dépouillement.

Accessibilité et capacité opérationnelle du canal de vote

13.35

Une organisation hostile pénètre dans le système pour en perturber l’exploitation, pour manipuler les informations destinées aux électeurs ou pour obtenir des preuves relatives au comportement de vote des électeurs.

Accessibilité et capacité opérationnelle du canal de vote, protection contre les manipulations des informations destinées aux électeurs, pas d’usage abusif des preuves relatives au comportement de vote

13.36

Un attaquant interne vole les données concernant les adresses des électeurs.

Protection des informations personnelles concernant les électeurs

13.37

Un logiciel malveillant influence des électeurs pendant qu’ils se forgent une opinion.

Protection contre les manipulations des informations destinées aux électeurs

13.38

Un attaquant interne manipule le site Internet d’information ou le portail de vote et sème la confusion dans l’esprit des électeurs.

Protection contre les manipulations des informations destinées aux électeurs

13.39

Un attaquant interne prescrit à des électeurs si et comment ils doivent voter. Après le déchiffrement, il trouve dans l’infrastructure des pièces justificatives prouvant que les électeurs se sont tenus aux instructions.

Pas d’usage abusif des preuves relatives au comportement de vote

13.40

Un attaquant externe prescrit à des électeurs si et comment ils doivent voter et leur demande une pièce justificative prouvant qu’ils se sont tenus aux instructions.

Pas d’usage abusif des preuves relatives au comportement de vote

6 L’«empoisonnement du cache DNS » (Domain name server spoofing) est une attaque au cours de laquelle le lien entre un nom d’hôte et l’adresse IP correspondante est faussé.

7 L’«homme du milieu » désigne l’attaquant dans une attaque de type man in the middle (MITM). L’attaque MITM est une forme d’attaque qui trouve son application dans les réseaux informatiques. L’attaquant s’immisce physiquement ou logiquement entre les deux partenaires d’une communication et prend totalement le contrôle du trafic de données entre eux ou entre plusieurs périphériques réseau. Il peut consulter les informations à loisir et même les manipuler.

8 Dans un logiciel, une «porte dérobée » (backdoor) est une fonctionnalité inconnue de l’utilisateur légitime, qui donne un accès secret au logiciel.

9 Un «déni de service» (denial of service, DOS) correspond à l’impossibilité d’accéder, lors d’un traitement numérique de données, à un service qui devrait en principe être disponible.

14. Détection et annonce d’incidents et de vulnérabilités en matière de sécurité; gestion des incidents en matière de sécurité et des améliorations

14.1
Un système de monitoring de l’infrastructure détecte les incidents qui pourraient menacer la sécurité du système, y compris sa disponibilité, et alerte le personnel compétent. Le personnel en question gère les incidents selon des procédures prédéfinies. Des scénarios de crise et des plans de sauvetage servent de directives (ils comprennent un plan qui garantit que les activités en rapport avec le scrutin peuvent être poursuivies) et sont utilisés au besoin.
Les erreurs d’écriture lors de l’enregistrement d’un suffrage dans les composants de contrôle et dans l’urne sont détectées. Des informations supplémentaires en rapport avec l’erreur doivent être disponibles afin de permettre de détecter et de corriger l’erreur. Les incidents constatés doivent être signalés au service compétent au niveau cantonal.
14.2
Des procès-verbaux dont la collecte, la transmission et le stockage résistent aux manipulations sont établis dans l’infrastructure (journaux système). Ils sont cohérents entre eux et permettent de retracer les événements pertinents dans le cadre de l’examen de manipulations ou d’erreurs supposées. Ils servent à cet égard de preuve de la prise en compte complète, non falsifiée et exclusive de l’intégralité des suffrages émis conformément à la procédure prévue par le système ainsi que de preuve de la garantie du secret du vote et de l’impossibilité d’établir des résultats partiels anticipés.
Le contenu des procès-verbaux couvre au moins les événements suivants:
démarrage et arrêt des processus de journalisation, d’identification et d’authentification
démarrage, redémarrage et fin de la phase de vote
démarrage du dépouillement comprenant l’établissement des résultats
réalisation d’éventuels autotests et résultats de ces derniers
dysfonctionnements qui ont été identifiés dans les éléments de l’infrastructure informatique et qui compromettent la capacité opérationnelle
Il documente par ailleurs la date et l’heure, le type d’événement, l’auteur potentiel et le résultat, en termes d’échec ou de réussite.
Les journaux système sont mis à la disposition du service compétent au niveau cantonal sous une forme qui lui permette d’en interpréter les informations.
14.3
Le monitoring et l’établissement des procès-verbaux sont soumis à un processus d’amélioration continue. Ce processus inclut un dialogue ouvert entre les parties prenantes et une évaluation objective régulière de l’efficacité des instruments et des processus mis en œuvre. Les résultats des évaluations sont pris en compte dans ce cadre.
14.4
Le monitoring et la collecte des journaux système ne compromettent en aucun cas l’efficacité des mesures destinées à garantir le secret du vote.
14.5
Il est garanti que les suffrages et les données qui prouvent le bon fonctionnement de la procédure de dépouillement des suffrages sont, en cas de panne, enregistrés dans l’infrastructure sans subir d’altérations.
14.6
Après une panne du système ou une défaillance des moyens de communication ou d’enregistrement, le système passe dans un mode «reprise sur panne» qui donne la possibilité de retourner à un mode de fonctionnement sûr. En particulier, les procédures de vote qui ont débuté sont interrompues. Le votant ne peut reprendre la procédure de vote que lorsque le système est de nouveau dans un mode de fonctionnement sûr.
14.7
Il est possible, au moyen de données d’authentification, d’envoyer des suffrages de contrôle qui ne sont attribués à aucun électeur. Le contenu de ces suffrages de contrôle est consigné dans un procès-verbal. Les suffrages de contrôle dépouillés sont comparés avec ceux qui sont consignés dans les procès-verbaux.
Il est garanti non seulement que les suffrages de contrôle seront traités dans toute la mesure du possible de manière similaire aux suffrages émis conformément à la procédure prévue par le système, mais aussi qu’ils ne seront pas comptabilisés.
14.8
La disponibilité de l’infrastructure est contrôlée et consignée dans un procès-verbal à des intervalles déterminés.
14.9
Toutes les parties du système de vote sont régulièrement mises à jour moyennant un processus préétabli et documenté afin que les vulnérabilités identifiées soient éliminées.
14.10
Les mesures qui servent à la surveillance et à l’établissement des procès-verbaux de l’utilisation du système et des activités des administrateurs, ainsi qu’à l’établissement des procès-verbaux des dysfonctionnements, sont décrites de manière détaillée, mises en œuvre, suivies et vérifiées.

15. Utilisation de mesures cryptographiques et gestion des clefs

15.1
Les certificats électroniques sont gérés selon les meilleures pratiques.
15.2
Des mesures cryptographiques efficaces correspondant à l’état de la technique garantissent l’intégrité des données sous-tendant l’exactitude des résultats et la confidentialité des données critiques, y compris des données d’identification et d’authentification concernant les autorités.
15.3
Dans l’infrastructure, des mesures cryptographiques efficaces correspondant à l’état de la technique garantissent la confidentialité des données critiques. Ces données sont toujours enregistrées sur des supports sous une forme chiffrée.
15.4
Des éléments de base cryptographiques sont utilisés uniquement quand la longueur des clefs et les algorithmes correspondent aux normes courantes (par ex. NIST, ECRYPT, SCSE). La signature électronique satisfait aux exigences d’une signature électronique avancée au sens de la loi du 18 mars 2016 sur la signature électronique (SCSE)10. La vérification de la signature se fait au moyen d’un certificat électronique délivré par un fournisseur de services de certification reconnu au sens de la SCSE.

16. Échange d’informations électronique et physique sûr

16.1
Tous les composants de l’infrastructure sont exploités dans une zone réseau séparée. Cette zone est protégée par rapport au reste du réseau au moyen d’un contrôle de routage adéquat.
16.2
Le vote électronique est de manière générale clairement séparé de l’ensemble des autres applications.

17. Tests du système

17.1
Les fonctions pertinentes pour la sécurité du système (fonctions de sécurité) sont testées. Les tests sont documentés au moyen de plans de test et au moyen des résultats attendus et des résultats effectifs des tests.
Le plan de test:
détermine les tests qui doivent être exécutés;
décrit les scénarios de chaque test, y compris les éventuelles dépendances par rapport aux résultats d’autres tests.
Les résultats attendus doivent montrer les résultats escomptés d’une exécution réussie des tests.
Les résultats effectifs doivent correspondre aux résultats attendus.
17.2
Une analyse de la couverture des tests est réalisée. Elle démontre:
que les tests définis dans la documentation de test et les spécifications fonctionnelles des interfaces correspondent;
que toutes les interfaces ont été complètement testées.
17.3
Une analyse de la profondeur des tests est réalisée. Elle démontre:
que les tests définis dans la documentation de test et les sous-systèmes relatifs aux fonctions de sécurité et aux modules ayant un rôle dans la garantie de la sécurité correspondent;
que tous les sous-systèmes relatifs aux fonctions de sécurité figurant dans les spécifications ont été testés;
que tous les modules ayant un rôle dans la garantie de la sécurité ont été testés.

18. Organisation de la sécurité des informations

18.1
Tous les rôles et toutes les responsabilités concernant l’exploitation du système sont précisément définis, attribués et communiqués.
18.2
La configuration initiale de l’infrastructure, qu’il s’agisse du matériel, du logiciel ou des droits d’accès, et toute modification doivent avoir été approuvées au préalable.
18.3
Les risques liés à des tiers (mandataires tels que fournisseurs et prestataires) sont identifiés et réduits autant que nécessaire moyennant la conclusion de conventions contractuelles adéquates. Le respect de ces conventions est surveillé et vérifié de manière appropriée pendant leur durée de validité.

19. Gestion des ressources matérielles ou immatérielles

19.1
Toutes les ressources matérielles ou immatérielles qui correspondent à un actif au sens de la norme ISO/IEC 27001:2013, Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information – Exigences11 et qui sont pertinentes pour le vote électronique (organisation dans son ensemble, en particulier les processus organisationnels et les informations traitées dans le cadre de ces processus; les supports de données; les installations de traitement des données de l’infrastructure; les locaux de l’infrastructure) sont répertoriées dans un inventaire. Une liste recensant le personnel doit être dressée. L’inventaire et la liste du personnel sont tenus à jour. Chaque ressource matérielle ou immatérielle est attribuée à une personne qui en prend la responsabilité.
19.2
L’utilisation licite de ressources matérielles ou immatérielles est définie.
19.3
Des directives régissant la classification des informations sont édictées et communiquées.
19.4
Des procédures régissant le marquage et la gestion des informations sont définies.

11 Le texte peut être consulté ou obtenu contre paiement auprès de: Secrétariat central de l’Organisation internationale de normalisation (ISO), Chemin de Blandonnet 8, CP 401, 1214Vernier, www.iso.org.

20. Fiabilité du personnel

20.1
Pour garantir la fiabilité du personnel avant, pendant et après la période d’engagement ou en cas de changement de rôle, des directives et des procédures adéquates sont élaborées et diffusées.
20.2
Les décideurs du personnel assument l’entière responsabilité de la garantie de la fiabilité du personnel.
20.3
L’ensemble du personnel possède une sensibilité marquée en matière de sécurité des informations. À cette fin est mis en place et lancé un programme de formation et d’entraînement qui soit adapté aux tâches.

21. Sécurité physique et sécurité liée à l’environnement

21.1
Les périmètres de sécurité des différents locaux de l’infrastructure sont clairement définis.
21.2
Des autorisations d’accès sont définies, créées et contrôlées de manière adéquate pour l’accès physique aux différents locaux de l’infrastructure.
21.3
Pour garantir la sécurité des appareils à l’intérieur et à l’extérieur des locaux de l’infrastructure, des directives et des procédures adéquates sont définies et leur respect est surveillé et vérifié.
21.4
Toutes les données sont traitées, notamment conservées, exclusivement en Suisse.

22. Gestion de la communication et de l’exploitation

22.1
Les obligations et les domaines de responsabilité sont répartis de telle sorte que les risques émanant du personnel qui sont liés à l’exploitation et à la communication soient réduits de façon à ce qu’ils ne constituent plus que des risques résiduels compatibles avec les critères de tolérance aux risques.
22.2
Des mesures de protection appropriées sont prises contre les logiciels malveillants.
22.3
Un plan détaillé pour la sécurisation des données est établi et mis en œuvre. Le bon fonctionnement de la sécurisation des données est vérifié à intervalles réguliers.
22.4
Des mesures adéquates sont définies et mises en œuvre pour assurer la protection du réseau contre les menaces qui ont été identifiées dans l’appréciation des risques visée à l’art. 4 en rel. avec le ch. 13, ainsi que la sécurité des services du réseau.
22.5
Les procédures relatives à l’utilisation de supports de données amovibles et à l’élimination de supports de données sont réglées en détail.

23. Attribution, gestion et retrait des droits d’accès

23.1
Pendant le scrutin, il est garanti que toute modification des droits d’accès apportée ultérieurement ne pourra être effectuée qu’en accord avec le service compétent au niveau cantonal.
23.2
L’accès à l’infrastructure et au logiciel est réglé et documenté en détail sur la base d’une appréciation des risques. Le principe du double contrôle s’applique dans les domaines présentant des risques élevés et pour toutes les opérations manuelles en rapport avec l’urne (par ex. ouverture du canal de vote, fermeture du canal de vote et début du dépouillement).
Les opérations manuelles en rapport avec l’urne électronique (par ex. ouverture du canal de vote, fermeture du canal de vote et début du dépouillement) sont authentifiées explicitement.
23.3
Il est impossible, à moins de disposer d’une autorisation en ce sens, de modifier des informations sur le portail du vote électronique ou sur des sites d’information concernant le vote électronique.
23.4
Pendant le scrutin, aucune intervention étrangère ne peut avoir lieu dans l’infrastructure.
23.5
Il est garanti qu’aucun des éléments des données d’authentification client ne pourra être systématiquement intercepté, modifié ou détourné au moment de la remise. L’authentification se fait au moyen de mesures et de technologies permettant de réduire suffisamment le risque d’abus systématique par des tiers.

24. Développement et maintenance de systèmes d’information

24.1
Développement
24.1.1
Il est défini un modèle de cycle de vie. Celui-ci:
est utilisé pour le développement et la maintenance du logiciel;
prévoit les contrôles nécessaires dans le développement et la maintenance du logiciel;
est documenté.
24.1.2
Une liste des outils de développement utilisés et de leurs options de configuration sélectionnées pour la mise en œuvre de chaque outil est établie.
24.1.3
La documentation de chaque outil de développement:
contient une définition de l’outil;
définit toutes les conventions et directives utilisées dans la mise en œuvre de l’outil;
définit sans ambiguïté la signification de toutes les options de configuration pour l’utilisation de l’outil.
24.1.4
Les standards d’implémentation sont définis et appliqués.
24.1.5
Le logiciel est spécifié et implémenté de telle sorte que les fonctions de sécurité ne puissent pas être contournées.
24.1.6
Les fonctions de sécurité sont spécifiées et implémentées de telle sorte qu’elles soient protégées contre les manipulations.
24.1.7
L’architecture de sécurité du logiciel est documentée. La documentation:
possède un niveau de détail correspondant à la description des fonctions de sécurité;
décrit les domaines de sécurité qui reposent sur les fonctions de sécurité;
décrit la manière dont les procédures d’initialisation sont sécurisées;
démontre que les exigences fixées aux ch. 24.1.5 et 24.1.6 sont remplies.
24.1.8
Les spécifications fonctionnelles sont documentées. La documentation:
représente l’entier du logiciel;
décrit l’objectif et le mode d’utilisation de toutes les interfaces;
identifie et décrit tous les paramètres associés aux interfaces;
décrit toutes les actions associées aux interfaces;
décrit tous les messages d’erreur directs pouvant résulter de l’appel de chaque interface.
24.1.9
La traçabilité entre les spécifications fonctionnelles et les exigences de sécurité est garantie et va jusqu’au niveau des interfaces.
24.1.10
Toutes les fonctions de sécurité sont implémentées dans le code source.
24.1.11
La traçabilité entre l’entier du code source et les spécifications des fonctions de sécurité doit être garantie, et leur correspondance est manifeste.
24.1.12
Les fonctions de sécurité sont conçues et implémentées de telle sorte qu’elles soient bien structurées. La structure interne est décrite et comprend une justification:
qui indique les caractéristiques utilisées pour évaluer les notions de «bien structuré» et de «complexe»;
qui démontre que toutes les fonctions de sécurité sont bien structurées et qu’elles ne sont pas trop complexes.
24.1.13
Les spécifications:
décrivent la structure du logiciel en termes de sous-systèmes;
décrivent les fonctions de sécurité en tant que modules, l’objectif de chaque module et les relations que chaque module a avec les autres modules; la description des modules ayant un rôle dans le renforcement de la sécurité comprend en plus les interfaces disponibles, les valeurs de retour de ces interfaces et les interfaces des autres modules utilisés pour interagir avec eux;
décrivent tous les sous-systèmes relatifs aux fonctions de sécurité, y compris les interactions qu’ils peuvent avoir entre eux;
démontrent par une représentation claire des sous-systèmes associés aux fonctions de sécurité que toutes les interfaces sont conformes au comportement décrit dans la spécification; la représentation doit comporter un niveau de détail allant au moins jusqu’aux modules.
24.1.14
Le logiciel est muni d’une référence univoque.
24.1.15
La documentation de la gestion de la configuration:
décrit la manière dont les éléments de configuration sont identifiés;
contient un plan de gestion de la configuration qui décrit comment le système de gestion de la configuration est utilisé dans le cadre du développement du logiciel et quelles sont les procédures appliquées pour la reprise de modifications ou de nouveaux éléments;
démontre que les procédures de reprise des modifications dans un élément de configuration prévoient un contrôle adéquat de ces dernières pour tous les éléments de configuration.
24.1.16
Le système de gestion de la configuration:
identifie chacun des éléments de configuration de manière univoque;
fournit des mesures automatisées de sorte que seules les modifications autorisées soient apportées aux éléments de configuration;
soutient le développement du logiciel par des procédures automatisées;
garantit que la personne chargée d’accepter l’élément de configuration n’est pas celle qui l’a développé;
identifie les éléments de configuration qui composent les fonctions de sécurité;
soutient par des moyens automatisés le contrôle de tous les changements apportés au logiciel, y compris en consignant le nom de l’auteur de la modification ainsi que la date et l’heure de cette dernière;
fournit une procédure automatisée pour l’identification de tous les éléments de configuration concernés par la modification d’un élément de configuration déterminé;
est capable d’identifier la version du code source sur la base de laquelle le logiciel est généré.
24.1.17
Tous les éléments de configuration sont répertoriés dans le système de gestion de la configuration.
24.1.18
Le système de gestion de la configuration est utilisé conformément au plan de gestion de la configuration.
24.1.19
Il est établi une liste de configuration contenant les éléments ci-après:
le logiciel proprement dit;
les preuves des contrôles nécessaires au respect de la sécurité;
les parties qui composent le logiciel;
le code source;
l’historique des changements12;
les rapports relatifs aux failles de sécurité et à l’état d’avancement des mesures prises pour y remédier.
Le développeur de chaque élément pertinent pour les fonctions de sécurité est mentionné. Chaque élément est identifié de manière univoque.
24.1.20
La documentation de la sécurité du développement du logiciel:
décrit les mesures de sécurité physiques, procédurales, relatives au personnel et autres qui sont nécessaires pour protéger le logiciel et l’intégrité de sa conception et de son implémentation dans leur environnement de développement;
démontre que les mesures de sécurité assurent le niveau de protection nécessaire au maintien de l’intégrité du logiciel.
24.2
Exploitation
24.2.1
Il est établi un guide opérationnel. Pour chaque rôle utilisateur, celui-ci:
décrit les fonctions auxquelles l’utilisateur a accès et les autorisations qui doivent être contrôlées dans un environnement sécurisé, y compris les avertissements en la matière;
décrit comment utiliser les interfaces disponibles de manière sécurisée;
décrit les fonctions et interfaces disponibles, en particulier tous les paramètres de sécurité qui se trouvent sous le contrôle de l’utilisateur, en indiquant les valeurs pertinentes pour la sécurité;
présente de façon précise chaque type d’événement de sécurité en rapport avec les fonctions accessibles à l’utilisateur qui doivent être exécutées, y compris les modifications des caractéristiques de sécurité des éléments sous le contrôle des fonctions de sécurité;
décrit les mesures de sécurité à mettre en œuvre pour atteindre les objectifs de sécurité opérationnels.
24.2.2
Le guide opérationnel identifie tous les modes d’exploitation possibles du logiciel, y compris la reprise de l’exploitation après la découverte d’erreurs et la description des conséquences et implications de ces erreurs pour le maintien d’une exploitation sûre.
24.2.3
Le guide opérationnel est précis et adéquat.
24.3
Compilation et déploiement fiables et vérifiables
24.3.1
La procédure de préparation décrit toutes les étapes nécessaires:
à une réception sûre des composants du système dans le respect de la procédure de livraison;
à une préparation sûre de l’environnement d’exploitation dans le respect des objectifs de sécurités opérationnels;
à une installation sûre du logiciel dans l’environnement d’exploitation.
24.3.2
La livraison du logiciel ou de parties du système est documentée et comprend toutes les procédures qui sont nécessaires au maintien de la sécurité lors de la livraison du logiciel.
24.3.3
Il est réalisé une compilation fiable et vérifiable au moyen de mesures de sécurité adéquates pour garantir que le code exécutable est une représentation vérifiable et fidèle du code source qui a été soumis à un contrôle public et à des audits indépendants. Cette compilation permet d’établir une chaîne de preuves pour la vérification du logiciel, et démontre en particulier:
que l’environnement de compilation est tel que décrit sur la plate-forme publique (ensemble des outils avec leur version, système d’exploitation et configurations éventuelles); les divergences qui pourraient exister sont documentées et justifiées;
que le logiciel a été compilé selon les instructions disponibles sur la plate-forme publique; si un défaut est détecté dans les instructions au moment de la compilation, il doit être consigné, et la documentation adaptée par la suite;
que le code source soumis au contrôle public et audité est bien celui utilisé pour la compilation;
qu’aucun autre élément que ceux prévus dans les instructions n’a été introduit;
que toutes les signatures cryptographiques des dépendances ont été vérifiées sur la base d’une référence établie, publique et fiable;
qu’une analyse des vulnérabilités concernant les dépendances a été conduite et, si des vulnérabilités pertinentes pour le logiciel existent, qu’elles ne le rendent pas vulnérable aux attaques;
que les éventuels paramètres qui ont été introduits ne rendent pas le système vulnérable.
24.3.4
Il est réalisé un déploiement fiable et vérifiable au moyen de mesures de sécurité adéquates, qui garantit:
1.
que le code déployé en production soit une représentation vérifiable et fidèle du code source qui a été soumis à un contrôle public et à des audits indépendants, et
2.
que l’environnement de production soit conforme à celui qui a été soumis au contrôle public et aux audits indépendants.
Le déploiement permet d’établir une chaîne de preuves pour la vérification du logiciel. Il démontre en particulier:
que l’environnement de production est conforme à celui qui a été soumis au contrôle public et aux audits indépendants; les éventuelles divergences (version du firmware, fichiers de configuration, etc.) sont documentées et justifiées;
que le logiciel déployé dans l’environnement de production est bien celui qui a été produit au cours de la procédure de compilation fiable et vérifiable;
que les éventuels paramètres qui ont été introduits ne rendent pas le système vulnérable.
24.3.5
La qualité des preuves de la compilation fiable et vérifiable et du déploiement fiable et vérifiable doit être attestée par la présence d’au moins deux témoins issus d’organisations différentes ou par des procédés techniques propres à établir la vérité en fonction de l’état des connaissances scientifiques et de l’expériences acquise.
24.3.6
La chaîne de preuves de la compilation fiable et vérifiable et du déploiement fiable et vérifiable est rendue publique.
24.4
Correction systématique des failles
24.4.1
Il est défini des procédures de correction des failles. Ces procédures:
comprennent une documentation, en particulier en ce qui concerne la traçabilité des failles pour chaque version du logiciel et les méthodes utilisées pour fournir aux utilisateurs du système des informations sur les failles, les corrections et les mesures correctives possibles;
exigent une description de la nature et des effets de chaque faille de sécurité ainsi que des informations sur l’état des travaux visant à trouver un correctif et sur les mesures correctives qui ont été arrêtées;
décrivent les moyens par lesquels les utilisateurs du système peuvent porter à la connaissance du développeur du logiciel des rapports et des requêtes concernant des failles supposées affecter le logiciel;
comprennent une procédure exigeant une réponse rapide et l’envoi automatique de rapports sur les failles de sécurité et les correctifs en la matière aux utilisateurs du système enregistrés qui pourraient être affectés par la faille de sécurité.
24.4.2
Il est défini une procédure de traitement des failles signalées. Cette procédure:
garantit que toute faille signalée et confirmée sera corrigée et que les procédures de correction seront communiquées aux utilisateurs du système;
prévoit des mesures garantissant que toute correction de failles de sécurité n’entraînera pas de nouvelles failles.
24.4.3
Il est défini des directives régissant le signalement et le traitement des failles. Ces directives:
fournissent aux utilisateurs du système des instructions sur la manière de signaler au développeur toute faille de sécurité supposée;
fournissent aux utilisateurs du système des instructions sur la manière de s’enregistrer auprès du développeur pour recevoir les rapports sur les faille de sécurité et les correctifs;
indiquent les services à contacter pour l’envoi des rapports et des demandes de renseignements sur les problèmes de sécurité concernant le logiciel.
24.5
Assurance qualité

Il est vérifié régulièrement et objectivement que les processus exécutés et les produits associés correspondent à la description des processus, des normes et des procédures qui doivent être mis en œuvre. Les divergences font l’objet d’un suivi jusqu’à leur élimination.

12 L’historique des changements (Commit History) consiste en une liste ordonnée de toutes les modifications apportées à un référentiel, avec pour chaque modification le motif qui la justifie.

25. Qualité du code source et de la documentation

Le code source et la documentation répondent au moins aux critères suivants:

25.1
Traçabilité
25.1.1
Définition: propriété du logiciel qui fournit un fil conducteur depuis les exigences jusqu’à la mise en œuvre.
25.1.2
Toutes les exigences applicables au protocole cryptographique sont traçables pour l’ensemble des résultats des opérations de travail liés au processus de développement du logiciel.
25.1.3
Le lien entre les exigences juridiques et le protocole cryptographique, les spécifications et la documentation de l’architecture est décrit.
25.2
Complétude
25.2.1
Définition: propriété du logiciel qui permet la mise en œuvre complète des fonctions requises.
25.2.2
Le logiciel ne contient pas de références ambigües (entrée, fonction, sortie). Le même terme est utilisé partout où un même élément est référencé.
25.2.3
Toutes les données référencées et toutes les fonctions utilisées sont définies dans les spécifications.
25.2.4
Toutes les fonctions définies dans les spécifications sont utilisées.
25.2.5
Toutes les variantes possibles sont définies dans les spécifications pour chaque élément de décision (par ex. exécution conditionnelle).
25.2.6
Tous les paramètres sont définis dans les spécifications et validés (pas de passage implicite de paramètres).
25.2.7
Toutes les erreurs graves qui ont été signalées sont corrigées avant le passage à l’étape suivante du cycle de développement.
25.2.8
Le protocole cryptographique, la spécification, l’architecture et le code source sont alignés.
25.3
Cohérence
25.3.1
Définition: propriété du logiciel qui fournit des techniques et une notation uniformes dans la conception et la mise en œuvre.
25.3.2
Les représentations figurant dans la documentation suivent une convention établie par le développeur du logiciel.
25.3.3
Les fonctions et les variables suivent une convention de nommage établie par le développeur du logiciel.
25.3.4
Le traitement des entrées et des sorties des fonctions suit une convention établie par le développeur du logiciel.
25.3.5
Le traitement des erreurs suit une convention établie par le développeur du logiciel.
25.3.6
Les types de variables utilisés sont cohérents.
25.4
Uniformité de la communication
25.4.1
Définition: propriété du logiciel qui permet l’utilisation de protocoles et de routines d’interface standardisés.
25.4.2
Les règles régissant la communication avec d’autres systèmes sont définies.
25.4.3
La communication repose sur des méthodes standardisées.
25.5
Uniformité des données
25.5.1
Définition: propriété du logiciel qui permet d’utiliser une représentation standardisée des données.
25.5.2
La représentation standardisée des données pour la communication avec d’autres systèmes est définie de manière formelle.
25.5.3
Des normes de conversion entre les différentes représentations sont définies.
25.5.4
Les fonctions de conversion sont centralisées dans un seul module.
25.6
Facilité d’apprentissage
25.6.1
Définition: propriété du logiciel qui permet à l’utilisateur de se familiariser facilement avec son fonctionnement.
25.6.2
Les personnes qui exploitent et utilisent le système sont formées et reçoivent la documentation nécessaire.
25.6.3
La formation comprend la possibilité de s’entraîner sur un système prévu à cet effet.
25.6.4
Des aides techniques sont facilement accessibles.
25.7
Opérabilité
25.7.1
Définition: propriété du logiciel qui facilite les interactions entre les utilisateurs et le système.
25.7.2
Le logiciel est convivial. La navigation se fait selon des schémas connus.
25.7.3
La partie client du système, telle qu’elle se présente à l’électeur, est conforme à la norme d’accessibilité eCH-005913, à l’exception des exigences de la norme relatives aux formes alternatives de communication prévues au chapitre 2.4. Les cantons veillent à ce que cela soit attesté par un service techniquement compétent.
25.8
Tolérance aux erreurs
25.8.1
Définition: propriété du logiciel qui permet la continuité des opérations dans des conditions exceptionnelles.
25.8.2
Les erreurs sont détectées et traitées de sorte que le programme puisse continuer de fonctionner sans interruption.
25.8.3
Le traitement des erreurs, y compris l’enregistrement dans le procès-verbal, est fait au niveau le plus pertinent pour la continuité des opérations. Une erreur qui ne peut être traitée à un niveau donné est transférée au niveau supérieur.
25.8.4
Des conditions de validité sont définies pour les paramètres d’entrée.
25.8.5
Tous les paramètres d’entrée sont vérifiés avant le début de l’exécution.
25.9
Modularité
25.9.1
Définition: propriété du logiciel qui fournit une structure comprenant des modules hautement indépendants.
25.9.2
Chaque module possède une responsabilité bien définie.
25.9.3
La responsabilité d’un module doit être restreinte et ciblée. Les responsabilités de deux modules ne doivent pas se chevaucher.
25.9.4
Les modules ne partagent pas de données par le biais d’une mémoire volatile commune (par ex. variable globale).
25.10
Simplicité
25.10.1
Définition: propriété du logiciel qui permet la mise en œuvre des fonctions de la manière la plus compréhensible possible. En général, il s’agit d’éviter les pratiques qui augmentent la complexité.
25.10.2
Une approche top-down (structure hiérarchique) est adoptée dans la conception.
25.10.3
La conception ne prévoit pas de fonction dupliquée entre les modules.
25.10.4
La conception ne prévoit pas de données de portée globale, c.-à-d. de données pouvant être utilisées partout sans être passées en paramètres.
25.10.5
Les combinaisons booléennes complexes sont évitées autant que possible dans le code source.
25.10.6
Les variables ne sont pas réutilisées pour d’autres usages que ceux prévus initialement dans le code source.
25.10.7
Le nombre d’imbrications est limité autant que possible dans le code source.
25.10.8
La complexité cyclomatique et cognitive est limitée autant que possible dans le code source.
25.11
Concision
25.11.1
Définition: propriété du logiciel qui permet la mise en œuvre dans le code source d’une fonction avec le moins possible d’instructions.
25.11.2
Le code source ne contient pas de code mort.
25.11.3
Le code source ne contient pas de variables inutiles.
25.11.4
Le code source ne devrait pas contenir de duplications.
25.12
Intelligibilité
25.12.1
Définition: propriété du logiciel qui permet aux destinataires d’en déterminer les objectifs, les hypothèses, les contraintes, les entrées, les sorties, les composants et le statut.
25.12.2
Les classes, les fonctions et les étapes de traitement complexes sont commentées dans le code source selon une convention établie par le développeur du logiciel.
25.12.3
Les variables et les fonctions ont des noms évocateurs.
25.12.4
Le code source comprend une instruction par ligne, sauf si une répartition sur plusieurs lignes permet d’améliorer la lisibilité. On évitera de saisir plusieurs instructions sur une seule ligne.
25.13
Instrumentation
25.13.1
Définition: propriété du logiciel qui permet d’en mesurer l’utilisation ou d’identifier des erreurs.
25.13.2
Les tests unitaires14 couvrent tous les chemins possibles et les limites entre valeurs autorisées et valeurs non autorisées des paramètres d’entrée.
25.13.3
Les tests d’intégration couvrent tous les modules.
25.13.4
Les scénarios de test système couvrent tous les modules.
25.13.5
Les erreurs et les informations nécessaires sont consignées dans des fichiers journaux.

13 eCH-0059: Accessibility Standard, version 3.0 du 25.06.2020; disponible gratuitement auprès de: association eCH, Mainaustrasse 30, Postfach, 8034 Zürich, www.ech.ch.

14 Un test unitaire consiste pour le programmeur à tester un module, indépendamment du reste du programme, afin de s’assurer qu’il répond aux spécifications fonctionnelles et qu’il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle pour les applications critiques.

26. Critères de contrôle pour les systèmes et leur exploitation

26.1
Contrôle du protocole cryptographique (art. 10, al. 1, let. a)
26.1.1
Objet: Il est examiné:
si les exigences figurant à l’art. 5 en rel. avec les art. 6 à 8 et avec le ch. 2 de l’annexe sont remplies; cette évaluation doit se faire notamment à l’aide des preuves de conformité cryptographiques et symboliques;
si le protocole cryptographique repose sur des protocoles et des éléments existants qui ont fait leurs preuves et dans quelle mesure;
si des approfondissements et des améliorations peuvent contribuer à renforcer la sécurité, et lesquels.
26.1.2
Compétences: Le contrôle est effectué par des experts en cryptographie. Il est commandé par la ChF, qui vérifie qu’il est exécuté dans le respect du mandat.
26.1.3
Date du contrôle:
Un contrôle complet est effectué avant la première mise en service.
Le contrôle est répété après deux ou trois ans.
Le protocole cryptographique est soumis à un nouveau contrôle:
à chaque fois qu’il est modifié, ou
lorsque la recherche fait émerger de nouvelles connaissances pertinentes relatives à la sécurité des éléments cryptographiques utilisés ou à la menace.
26.2
Contrôle du logiciel du système (art. 10, al. 1, let. b)
26.2.1
Objet: Il est examiné:
si le protocole cryptographique contrôlé en vertu du ch. 26.1 est mis en œuvre; la mise en œuvre correcte des fonctions des composants fiables sera soumise à un contrôle particulièrement approfondi;
si le logiciel du système remplit les exigences de la présente ordonnance et contribue à la réalisation des objectifs fixés;
si la partie du système, telle qu’elle se présente à l’électeur, est conforme à la norme eCH-0059 comme le prévoit le ch. 25.7.3; la vérification peut s’appuyer sur un certificat valide ou sur un rapport d’audit ayant été établi par une institution reconnue par la ChF et attestant de la conformité avec ladite norme.
26.2.2
Compétences: Le contrôle doit être effectué par des experts en cryptographie et en développement de logiciels. Il est commandé par la ChF.
26.2.3
Date du contrôle:
Un contrôle complet est effectué avant la première mise en service.
Le contrôle est répété après deux ou trois ans.
Le logiciel du système est soumis à un nouveau contrôle à chaque modification majeure est opérée, notamment:
après toute modification du protocole cryptographique;
après toute modification, dans le code source, des fonctions dont la fiabilité est déterminante pour le caractère concluant des preuves prévues dans le cadre de la vérifiabilité;
lorsque la recherche fait émerger de nouvelles connaissances pertinentes relatives à la sécurité des éléments cryptographiques utilisés ou à la menace;
lorsqu’il est renoncé à recourir à des mécanismes garantissant le fonctionnement sûr de composants fiables au sens du ch. 2, ou que des modifications majeures sont apportées à ces mécanismes.
26.3
Contrôle de la sécurité de l’infrastructure et de l’exploitation (art. 10, al. 1, let. c)
26.3.1
Objet: Il est examiné:
si le système et son exploitation par le canton, par l’exploitant du système et par l’imprimerie répondent aux exigences de la présente ordonnance et contribuent de façon appropriée à la réalisation des objectifs fixés;
si les composants de base, comme le logiciel qui concourt à l’utilisation sûre et indépendante des composants de contrôle, les systèmes d’exploitation utilisés ou les serveurs utilisés correspondent aux meilleurs standards reconnus.
26.3.2
Compétences: Le contrôle est effectué par des experts en cryptographie et en exploitation de systèmes hautement sécurisés. Il est commandé par la ChF.
26.3.3
Date du contrôle:
Un contrôle complet est effectué avant la première mise en service.
Le contrôle est répété après deux ou trois ans.
Un nouveau contrôle est effectué chaque fois qu’une modification majeure est opérée, notamment:
après une modification du protocole cryptographique;
lorsqu’il est renoncé à recourir à des mécanismes garantissant le fonctionnement sûr de composants fiables au sens du ch. 2, ou que des modifications majeures sont apportées à ces mécanismes;
en cas de modification majeure des processus ou de l’infrastructure.
Si des nouvelles versions de composants de base sont utilisés (nouveau serveur, patchs pour le système d’exploitation ou pour le logiciel qui concourt à l’utilisation sûre et indépendante de composants fiables au sens du ch. 2), il n’est pas nécessaire d’effectuer un nouveau contrôle pour autant que les composants de base correspondent toujours aux meilleurs standards reconnus.
26.4
Contrôle de la protection contre les tentatives d’intrusion dans l’infrastructure (art. 10, al. 1, let. d)
26.4.1
Objet: Il est examiné si des experts mandatés par la ChF parviennent dans le cadre de la participation à un test à pénétrer dans l’infrastructure du système en ligne et ainsi à se ménager l’accès à des données importantes ou à prendre le contrôle de fonctions importantes.
Les tests sont réalisés sur la base de vulnérabilités potentielles découvertes à la suite d’une analyse méthodique des documents qui ont été publiés, en vertu notamment de l’art. 11.
26.4.2
Compétences: Le contrôle est effectué par des experts en sécurité. Il est commandé par la ChF.
26.4.3
Date du contrôle:
Un contrôle complet est effectué avant la première mise en service.
Le contrôle est répété après deux ou trois ans.
Le contrôle est effectué à chaque modification majeure de l’infrastructure.
Le contrôle est effectué en cas d’émergence de nouvelles connaissances pertinentes relatives à la sécurité des moyens d’exploitation utilisés ou à la menace.
26.5
Contrôle du système de management de la sécurité de l’information (art. 10, al. 2)
26.5.1
Objet: Il est examiné si le SMSI de l’exploitant du système est conforme à la norme ISO/IEC 27001:2013, Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information – Exigences. Le champ d’application du SMSI englobe toutes les unités organisationnelles de l’exploitant du système qui sont responsables du système sur les plans juridique, administratif et opérationnel.
26.5.2
Compétences: L’organisme de certification est accrédité par le Service d’accréditation suisse (SAS) pour pouvoir effectuer des audits au sens de la norme ISO/IEC 27001:2013, Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information – Exigences. Le contrôle est commandé par le canton ou par l’exploitant du système; le canton veille à ce qu’il soit effectué.
26.5.3
Durée de validité d’une pièce justificative: Les audits de renouvellement sont effectués aux intervalles prescrits par la norme ISO/IEC 27001:2013, Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information – Exigences. Un certificat valide et la déclaration d’applicabilité (Statement of Applicability) sont présentés à chaque utilisation. Si une nouvelle version de la norme ISO/IEC 27001:2013, Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information – Exigences est publiée, la preuve que le SMSI dispose d’une certification valide conforme à la nouvelle version doit être apportée au plus tard à l’échéance du délai transitoire. Le champ d’application du SMSI ne peut être restreint à la faveur de cette nouvelle certification.

Diese Seite ist durch reCAPTCHA geschützt und die Google Datenschutzrichtlinie und Nutzungsbedingungen gelten.

Feedback
Laden