Federal Chancellery Ordinance
on Electronic Voting
(OEV, VEleS)

1. Definitions

In addition to Article 2, the following expressions mean:

• 1.1 voting secrecy is a situation in which no person or component has the following data:

  • 1.1.1 votes cast or data indicating the content of votes cast,

  • 1.1.2 data allowing the persons voting to be identified (data on voters), and

  • 1.1.3 data allowing the data on voters to be matched with the votes cast;

• 1.2 the exclusion of premature partial results is a situation in which no person or component has the votes cast or data indicating the votes cast prematurely;

• 1.3 the verification reference is data sent with the voting papers to enable voters to check whether their vote has been cast correctly, in accordance with Article 5 paragraph 2 in conjunction with Number 2.5 of the Annex (e.g. a list showing a code for each voting option);

• 1.4 an external attacker is a person or group of persons who is not familiar with how the system has been developed or how it operates, who has average resources and expertise, from whom an attack originates; their motives may include political activism and financial gain;

• 1.5 an internal attacker is a person or group of persons involved in the development or operation of the system from whom an attack originates; their motives may include political activism, financial gain, or the intention to harm their employer;

• 1.6 a hostile organisation is a group of individuals with substantial resources and above-average expertise that is the source of an attack; it may also be supported by a state; its motives may be to obtain data for profiling purposes, to disrupt a ballot or to influence the results of the ballot;

• 1.7 an attacker is a person, group of persons or organisation as defined in Numbers 1.4-1.6;

• 1.8 an electronic ballot box is storage space in which the votes cast can be stored until they are decrypted and counted;

• 1.9 a system log is a log established from the infrastructure components to monitor the system and investigate incidents.

2. Cryptographic protocol requirements for complete verifiability (Art. 5)

• 2.1 System participants

The cryptographic protocol regulates the tasks of the following abstract system participants:

• – voter / person voting

• – user device

• – set-up component

• – untrustworthy system (any component excluding the other components listed in this Number; UT system)

• – print component

• – one or more groups of control components

• – auditors

• – auditors’ technical aids

• 2.2 Communication channels

The cryptographic protocol may provide the following communication channels to enable system participants to exchange messages:

• – voter / person voting ↔ user device

• – user device ↔ UT system

• – set-up component ↔ UT system

• – control component ↔ UT system

• – UT system → print component

• – UT system → auditors’ technical aid

• – print component → voter / person voting

• – set-up component → auditors’ technical aid

• – auditors ↔ auditors’ technical aid

• – bi-directional channels for communication between control components

• 2.3 Attackers

• 2.3.1 The cryptographic protocol must provide protection against an attacker attempting to tamper with the votes and the result, to breach voting secrecy or to obtain premature partial results (Nos 2.5–2.8).

• 2.3.2 The assumption must be made that an attacker has the following abilities:

  • – He can take control of all untrustworthy system participants (cf. No 2.4), so that they share all the secret data with him and act without restriction according to his instructions.

  • – He can read or prevent delivery of all messages that are exchanged on untrustworthy channels and feed in his own messages as he pleases.

• 2.4 Trustworthy and untrustworthy system participants and communication channels

• 2.4.1 System participants and communication channels are considered either to be «trustworthy» or «untrustworthy». The permitted trust assumptions for individual system participants are governed by Number 2.9.

• 2.4.2 Trustworthy system participants and communication channels are regarded as protected against attackers. For the cryptographic protocol, the following assumptions may be made:

  • – Trustworthy system participants keep private data secure and only carry out operations defined by the cryptographic protocol.

  • – Trustworthy communication channels keep transmitted messages private and protect them from manipulation.

• 2.5 Requirement for the cryptographic protocol: individual verifiability

The voter is given proofs in accordance with Article 5 paragraph 2 in conjunction with Article 6 letters a and b to confirm that no attacker:

• – has altered any partial vote before the vote has been registered as cast in conformity with the system;

• – has maliciously cast a vote on the voter’s behalf which has subsequently been registered as a vote cast in conformity with the system and counted.

• 2.6 Requirement for the cryptographic protocol: universal verifiability

The auditors receive a proof in accordance with Article 5 paragraph 3 letter a in conjunction with Article 6 letters a and c to confirm that no attacker:

• – after the votes were registered as cast in conformity with the system, has altered or misappropriated any partial votes before the result was determined;

• – has inserted any votes or partial votes not cast in conformity with the system which were taken into account in determining the result.

• 2.7 Requirements for the cryptographic protocol: preserving voting secrecy and excluding premature partial results

• 2.7.1 It must be ensured that no attacker is able to breach voting secrecy or establish premature partial results unless he can control the voters or their user devices.

• 2.7.2 There is no obligation to prevent attacks that limit the number of tallied votes to the degree that all partial votes for a question, list or candidate are the same.

• 2.7.3 It must be ensured that no attacker can take control of user devices unnoticed by manipulating the user device software on the server. The person voting must be able to verify that the server has provided his or her user device with the correct software with the correct parameters, in particular the public key for encrypting the vote.

• 2.8 Requirement for the cryptographic protocol: effective authentication

3. Requirements for trustworthy components in accordance with Number 2 and for their operation

• 3.1 The operation of the set-up component and at least one control component in the group which contains part of the key for decrypting the votes is the direct responsibility of the canton and must take place within its infrastructure. Outsourcing to a private system operator is not permitted.

• 3.2 Sufficient entropy must be ensured when selecting random values, in particular for set-up components and control components.

• 3.3 Auditors must verify the proofs referred to in Number 2.6 at least once and must use a technical aid referred to in Number 2 for this purpose.

• 3.4 The operational requirements for set-up components in accordance with Number 3 also apply to technical aids used by the auditors. Within the scope of their responsibility under cantonal law, the auditors may provide for derogations.

• 3.5 With the exception of the components mentioned under Numbers 3.1 and 3.3, the canton may delegate the operation of any part of the system, including the control components and the print component, to private service providers. A private operator of the print component may only perform operational tasks that are required for preparation, packaging and delivery.

• 3.6 Trustworthy components (set-up components, print components, auditors’ technical aids and control components) must be set up, updated, configured and secured in an observable process.

• 3.7 Before installing software, all programs must be checked using an official and trustworthy reference to ensure that the files are the correct and unaltered version.

• 3.8 When other system participants’ electronic certificates are installed, their authenticity must be ensured. To that end, there should be a manual process in which people transfer the electronic certificates from one machine to another via a physical data carrier in accordance with 3.13.

• 3.9 The timing for updating all software of trustworthy components must be such that the expected benefits outweigh the potential hazards.

• 3.10 Set-up components, print components and auditors’ technical aids that are involved in any way in the processing of critical data must be physically monitored during the entire computing time by two persons and until any critical data have been deleted or securely stored. At most, they may be interconnected by visible physical cables so that it is as evident as possible that no other machines can access them until the confidential data is destroyed.

• 3.11 Trustworthy components may not be connected to the internet when installing or updating software.

• 3.12 In principle, critical data must be destroyed after use. If there are good reasons, secure storage of the data carrier is also permitted as an alternative.

• 3.13 Data exchange or storage media, such as USB flash drives, must be removed after the data has been uploaded to the trustworthy components and may only be reused before the data is destroyed if there was no critical data on the trustworthy component before the data was uploaded.

• Data exchange or storage media must be reformatted and any data on them must be destroyed before they are used with the aid of a component operated in accordance with the requirements for trustworthy components.

• 3.14 Logical or physical access to trustworthy components or data carriers containing critical data must be impossible without another person becoming aware of it, for example by having to assist in granting access (strict two person principle).

• 3.15 Success in gaining unauthorised access to a control component should not as far as possible give any advantage in an attempt to access another control component unnoticed. In addition to the requirements set out in Number 3, the following requirements apply in this respect:

  • – If a person has physical or logical access to a control component, that person may not have access to any other control component.

  • – The hardware, the operating systems and the monitoring systems for the control components should be as distinct as possible from each other.

  • – The control components should be connected to different local networks.

  • – A control component must take the form of a physical device. Virtualisation across multiple physical devices is not permitted.

• 3.16 Control components must be designed to recognise unpermitted instances of access and to alert the persons responsible. The persons responsible should arrange external monitoring measures, such as the monitoring and the manipulation-resistant logging of network traffic or physical monitoring with cameras that are under their control. The persons responsible must be considered to be particularly trustworthy and reliable.

• 3.17 Trustworthy components may perform only the intended operations.

• 3.18 The software for the auditors’ technical aids must be obtained from a different system developer from the one who developed the main part of the software for the other system components. The publication of the software for the technical aid under a licence that meets the criteria for open source software⁴ may justify an exception. If auditors use several technical aids, this provision applies to at least one of the technical aids.

• 3.19 All procedures for dealing with trustworthy components must be documented in writing and in a manner that is easily understood by the persons concerned.

• 3.20 Any access to and use of a trusted component or data carrier containing critical data must be logged.

4. Voting process

• 4.1 The person voting must declare that he or she is aware of the rules on electronic voting and of his or her own responsibilities.

• 4.2 Before casting a vote, the person voting is notified that he or she is taking part in a ballot in the same way as voting by post or voting in person at the ballot box. The person voting may only cast his or her vote after confirming that he or she has taken note of this.

• 4.3 When voting, the person voting is requested to check the proofs in accordance with Number 2.5 against the verification reference and to report any doubts as to its correctness to the canton.

• 4.4 At any time before casting an electronic vote definitively, the voter may still choose to cast his or her vote via a conventional voting channel.

• 4.5 The client-side system as it appears to the person voting does not influence the person voting in his or her decision on how to vote.

• 4.6 The user guidance must not lead persons voting to cast hasty or ill-considered votes.

• 4.7 The system does not offer the person voting any functionality allowing them to print out or store their vote.

• 4.8 The person voting is not shown any information after the voting process is completed about the content of the vote that has been encrypted and cast.

• 4.9 A voter who is unable to cast a vote because third parties have cast a vote using his or her voting papers unlawfully may still be allowed by the canton to vote provided the canton declares the unlawfully cast vote null and void. Voting secrecy in accordance with Number 2.7 must be preserved.

• 4.10 Voters with disabilities may be provided with a simplified procedure for checking the proofs. Only in such a case are derogations from the requirements set out in Number 2.9.1 permitted.

• 4.11 As long as the system has not registered confirmation of a definitive electronic vote, the voter may still choose to cast his or her vote via a conventional voting channel.

• 4.12 The use of a means of authentication independent of electronic voting is permitted. Effects on the integrity of the verification of the right to vote and the preservation of voting secrecy must be examined in detail as part of the risk assessment.

5. Preparations for the ballot

• 5.1 If the electoral register data is imported from a third-party system that is outside the canton’s control, the data must be encrypted and signed. The signature must be verified on receipt of the data. For delivery to the printing office, the provisions of Number 7 take precedence.

• 5.2 The data required to examine the proofs in accordance with Number 2.6 must be handed over to the auditors.

6. Requirements for polling cards

• 6.1 If possible, the polling cards shall be designed so as to allow voters with a disability barrier-free access to electronic voting.

• 6.2 Security elements on the polling card (e.g scratch codes) may only be used if there is a confirmation that the concealed information is well protected against unauthorised reading.

• 6.3 If it is decided not to use security elements to protect confidential information on the voting card, organisational procedures must be in place to ensure security.

7. Requirements for printing offices

• 7.1 The printing data used to produce the polling cards are transmitted encrypted and signed. Alternatively, a data carrier containing this data may be delivered in person. In this case, the data carrier must be transported and delivered to the printing office by two persons, who must both stay with the data carrier until it is delivered.

• 7.2 The encryption must meet the requirements of eCH standard 0014⁵, Chapter 7.5. If encryption is symmetric, the secret decryption key is sent to the persons responsible at the printing office via a secure secondary channel.

• 7.3 The person responsible at the printing office who receives the data carrier must sign an acknowledgement of receipt.

• 7.4 For the data carrier containing the print data, the component on which the critical data is decrypted and all components that process the critical data, the provisions for the print component as set out in Number 3 apply.

• 7.5 The persons responsible at the printing office carry out a material quantity check.

• 7.6 After printing the polling cards, the printing office must destroy the data received.

• 7.7 If the printing office also carries out the packaging and dispatch of the polling cards, these must be packaged together with the voting papers immediately after printing.

• 7.8 The channel between the printing office and the voters may only be considered trustworthy if the bodies responsible under cantonal law deliver the packaged voting papers to the voters by post or ensure that it is handed over in person.

8. Information and instructions

• 8.1 The body responsible at cantonal level must issue guidelines on providing information to citizens about electronic voting.

• 8.2 The guidelines ensure that the information is authorised by the responsible bodies.

• 8.3 Tips and instructions on vote casting are given on the internet along with information on voters’ responsibilities. This should counter over-hasty or ill-considered vote casting behaviour.

• 8.4 Verifiability, further security measures and the procedure in the event of anomalies are explained to voters in an accessible manner.

• 8.5 Voters are told what they have to pay attention to in order to cast their vote securely.

• 8.6 Voters are given instructions on how to delete their vote from all the memories on the device used for entering the vote.

• 8.7 Voters may request support if they have questions about electronic voting.

• 8.8 Voters are requested to report incorrectly displayed proofs in accordance with Number 2.5 such as verification codes or other verification steps with negative results to the body responsible at cantonal level. This request is also made in the instructions sent out with the voting papers.

• 8.9 Voters are requested to keep the voting papers with the security elements in fulfilment of Number 2.5 securely until they cast their final vote or until the voting process is concluded.

• 8.10 Voters are given the information required to check the authenticity of the website and the server used for voting. The informative value of a successful check must be supported by the use of cryptographic resources according to the best practices.

• 8.11 The information essential for secure voting is sent with the voting papers. Voters are told that if in doubt, they should comply with the information in the voting papers rather than the information displayed on the user device.

• 8.12 The measures taken to preserve voting secrecy are explained to voters.

• 8.13 Known flaws and the need for action associated with them are communicated transparently.

• 8.14 The auditors should be suitably informed about and trained in the processes that determine the accuracy of the result, the preservation of voting secrecy and the exclusion of premature partial results (for example key generation, printing the voting papers, decryption and tallying). They must be able to understand the essential aspects of the processes and their significance.

9. Opening and closing the electronic voting channel

10. Conformity check and storing finalised votes

11. Tallying votes in the electronic ballot box

• 11.1 The decryption of the votes and the tallying may not begin before Polling Sunday.

• 11.2 The canton carries out the decryption and tallying within its own infrastructure.

• 11.3 The canton must ensure that the decryption of votes and their tallying is documented. The minutes are released by the body responsible at cantonal level.

• 11.4 From the decryption of votes to the transmission of the result of the ballot, any access to the system or to any of its components must be made jointly by at least two persons; it must be recorded in writing and it must be possible for the auditors to check it.

• 11.5 If the result data is transmitted to a third-party system that is outside the canton’s control, the data must be encrypted and signed.

• 11.6 The system allows the polling card to be used to determine whether someone has cast an electronic vote.

• 11.7 Auditors must be present during decryption and tallying. The cantons may permit additional remote auditing work.

• 11.8 If components used to tally votes are not trustworthy in accordance with Number 2.4, the same requirements apply to these components as to set-up components under Number 3.

• 11.9 The auditors exercise their responsibility in accordance with cantonal law when examining the proofs in accordance with Number 2.6.

• 11.10 The body responsible at cantonal level submits all relevant indicators of the correctness of the result to the auditors. This includes, in addition to the proofs in accordance with Number 2.6, in particular the number and nature of anomalies reported to the canton by voters.

• 11.11 The canton anticipates any anomalies and, in consultation with the bodies concerned, draws up an emergency plan specifying the appropriate course of action. It creates transparency towards the public.

• 11.12 Statistical methods must be used to check the plausibility of the result, provided they are available and there is sufficient data.

12. Confidential data

• 12.1 It is guaranteed that neither employees nor externals hold data that allow a connection to be made between the identity of persons voting and the votes they have cast.

• 12.2 It is guaranteed that neither employees nor externals hold data before the decryption of the votes that allow the premature determination of partial results.

• 12.3 The canton may not pass on to private companies its part of the key for decrypting the votes which it has on the control component that it operates in accordance with Number 3.1.

• 12.4 The canton must treat the results of the ballot as confidential between the time the votes are decrypted and the time of publication.

• 12.5 The canton must ensure that data that indicate whether a voter has voted electronically are treated as confidential.

• 12.6 The canton must treat the individual votes as confidential after they have been tallied.

• 12.7 The canton must ensure that vote and election results in small constituencies are treated as confidential.

• 12.8 Following validation and in accordance with a predetermined and documented process, all data created as part of the electronic ballot that relate to the individual votes received and that are classified as confidential must be destroyed.

13. Threats

• 13.1 The threats listed in Numbers 13.3-13.40 are of a general nature and form a basis; this must be added to. They relate to the security objectives and must be taken into account when identifying risks. Depending on the system vulnerabilities identified, when the various bodies carry out their risk assessments, the list should be updated with full details based on the actual circumstances and depending on the specific threat.

• 13.2 The following are considered to be potential threats:

  • – inadvertent or intended electronic or physical threats from internal or external actors;

  • – threats resulting from a malfunction of the system or system-supporting elements.

14. Identifying and reporting security events and vulnerabilities; dealing with security events and making security improvements

• 14.1 An infrastructure monitoring system detects incidents that could endanger the security, including availability, of the system and alerts the responsible personnel. The personnel deal with incidents according to a predetermined procedure. Crisis scenarios and rescue plans serve as guidelines (and include a plan that guarantees that voting-related activities can continue) and are applied as required.

• Errors in the registration of votes in the control components and in the ballot box must be detected. Further information relating to the error must be available in order to identify and eliminate the cause. Any incidents detected must be reported to the body responsible at cantonal level.

• 14.2 Records are created on the infrastructure whose recording, transmission and storage are resistant to manipulation (system logs). The records are consistent with each other and allow the relevant events to be traced when investigating suspected manipulation or errors. They serve as evidence of the complete, unfalsified and exclusive tallying of votes cast in conformity with the system, of preservation of voting secrecy and of the exclusion of premature partial results.

• The content of the records covers at least the following events:

  • – start and end of the audit, identification and authentication processes

  • – start, restart and end of the voting or election phase

  • – start of the tallying with the determination of the results

  • – conduct and results of any self-tests

  • – malfunctions identified in elements of the IT infrastructure that affect the ability to operate

• The date and time of each event, the type of event, the possible originator and the result in terms of failure or success are documented.

• The system logs are made available to the body responsible at cantonal level in such a way that it can interpret the information.

• 14.3 The monitoring and recording of system logs are subject to a continuous improvement process. The improvement process involves an open dialogue between those involved and a regular and objective assessment of the effectiveness of the instruments and processes used. The results of these evaluations will be taken into account.

• 14.4 The monitoring and recording of system logs in no way detracts from the effectiveness of the measures taken to preserve voting secrecy.

• 14.5 It must be guaranteed that in the event of a malfunction, the votes and the data that prove the smooth operation of the vote tallying are stored safely in the infrastructure.

• 14.6 After a breakdown in the system or a failure of communication or storage media, the system enters a recovery mode in which it is possible to return to a safe state. Voting processes that have been started are interrupted. The person voting cannot resume voting until the system is returned to a safe state.

• 14.7 It is possible to cast control votes using authentication credentials that are not assigned to any voter. The content of these control votes is recorded. The tallying of the control votes is compared with the records.

• It must be ensured that the control votes are dealt with in as similar a way possible as votes cast in conformity with the system, while at the same time ensuring that they are not counted.

• 14.8 Infrastructure availability must be checked and recorded at selected intervals.

• 14.9 All parts of the voting system must be regularly updated in a predetermined and documented process in order to eliminate weaknesses that have become known.

• 14.10 The measures for monitoring and keeping records of system usage, the activities of administrators and of malfunction records must be described in detail, implemented, monitored and reviewed.

15. Use of cryptographic measures and key management

• 15.1 Electronic certificates must be managed according to the best practices.

• 15.2 In order to guarantee the integrity of data records that substantiate the accuracy of the result and ensure that critical data, including the authorities’ identification and authentication data, are kept secret, effective cryptographic measures that correspond to the state of the art must be used.

• 15.3 To ensure that critical data are kept secret, effective cryptographic measures are used in the infrastructure that correspond to the state of the art. Such data is always stored encrypted on data carriers.

• 15.4 Basic cryptographic components may only be used if the key lengths and algorithms correspond to the current standards (e.g. NIST, ECRYPT, ESigA). The electronic signature meets the requirements of an advanced electronic signature in accordance with the Federal Act of 18 March 2016¹⁰ on Electronic Signatures (ESigA). The signature must be verified by means of an electronic certificate that has been issued by a recognised supplier of certificate services under the ESigA.

16. Secure electronic and physical exchange of information

• 16.1 All infrastructure components must be operated in a separate network zone. This network zone must be protected in relation to other networks by an appropriate routing control.

• 16.2 As a principle, electronic voting should be clearly separated from all other applications.

17. System tests

• 17.1 The functions relevant to the security of the system (security functions) are tested. The tests are documented with test plans, and expected and actual test results.

• The test plan:

  • – specifies the tests to be performed;

  • – describes the scenarios for each test, including any dependencies on the results of other tests.

• The expected results must show the results that are expected if the test is successfully executed.

• The actual results must be consistent with expected results.

• 17.2 An analysis must be made of the test coverage. This includes evidence that:

  • – the tests defined in the test documentation match the functional specifications of the interfaces;

  • – all interfaces have been fully tested.

• 17.3 An analysis must be made of the depth of testing. This includes evidence that:

  • – the tests defined in the test documentation match the subsystems related to security functions and modules that play a role in ensuring security;

  • – all subsystems related to the security functions mentioned in the specifications have been tested;

  • – all modules that play a role in ensuring security have been tested.

18. Organisation of information security

• 18.1 All roles and responsibilities for the operation of the system must be precisely defined, assigned and communicated.

• 18.2 The initial configuration of the infrastructure, whether with regard to hardware, software or access rights, and any modification must be approved beforehand.

• 18.3 The risks in connection with third parties (contractors such as suppliers and service providers) must be identified and if necessary reduced by means of suitable contractual agreements. Compliance with the agreements must be appropriately monitored and reviewed throughout their term.

19. Management of intangible and tangible resources

• 19.1 All intangible and tangible resources in the sense of the term asset in the standard ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements¹¹, relevant in the context of electronic voting (organisation as a whole, in particular the organisational processes and the information processed in these processes, data carriers, facilities for processing information of the infrastructure and premises of the infrastructure) are recorded in an inventory. A list must be kept of human resources. The inventory and human resources list must be kept up to date. Each intangible and tangible resource is assigned a person who takes responsibility for it.

• 19.2 The acceptable use of intangible and tangible resources must be defined.

• 19.3 Classification guidelines for information must be issued and communicated.

• 19.4 Procedures must be devised for the labelling and handling of information.

20. Trustworthiness of human resources

• 20.1 Suitable policies and procedures must be devised and promulgated in order to guarantee the trustworthiness of human resources before, during and after termination of employment or in the case of a change of activity.

• 20.2 Heads of human resources must accept full responsibility for guaranteeing the trustworthiness of human resources.

• 20.3 All human resources must be acutely aware of the significance of information security. To this end, an education and training programme that is tailored to the tasks concerned must be devised and operated.

21. Physical and environment security

• 21.1 The security perimeters of the various premises of the infrastructure are clearly defined.

• 21.2 For physical entry to these various infrastructure premises, entry controls must be defined, implemented and appropriately checked.

• 21.3 To guarantee the security of devices within and outside the infrastructure premises, appropriate policies and procedures must be defined and compliance therewith monitored and reviewed.

• 21.4 All data must be processed and in particular stored exclusively in Switzerland.

22. Management of communication and operations

• 22.1 Obligations and areas of responsibility must be apportioned so that the risks originating from human resources relating to operations and communications are reduced to residual risks that are compatible with the risk acceptance criteria.

• 22.2 Appropriate measures must be taken to protect against malware.

• 22.3 A detailed plan for data backup must be prepared and implemented. The data backup must be regularly reviewed to check that it is functioning correctly.

• 22.4 Appropriate measures must be defined and implemented to protect the network from the threats listed in the risk assessment in accordance with Article 4 and in connection with Number 13 and for the security of network services.

• 22.5 The procedures for using removable data carriers and for disposing of data carriers must be regulated in detail.

23. Allocation, administration and withdrawal of access and admission authorisations

• 23.1 It must be ensured that, during the ballot, any subsequent change in physical and logical access rights takes place only with the consent of the body responsible at cantonal level.

• 23.2 Access to infrastructure and software must be regulated and documented in detail on the basis of a risk assessment. In high-risk areas and for all manual operations in connection with the electronic ballot box (e.g. opening the voting channel, closing the voting channel, starting tallying), operations must be conducted by at least two persons.

• Manual operations in connection with the electronic ballot box (e.g. opening the voting channel, closing the voting channel, starting tallying) must be expressly authenticated.

• 23.3 It must be guaranteed that information on the voting portal and related information pages cannot be changed without authorisation.

• 23.4 During the ballot, access of any nature to the infrastructure that is of no relevance to the ballot must be prevented.

• 23.5 It must be ensured that none of the elements of the client-sided authentication credentials can be systematically intercepted, changed or redirected during transmission. For authentication, measures and technologies must be used that sufficiently minimise the risk of systematic abuse by third parties.

24. Development and maintenance of information systems

• 24.1 Development

• 24.1.1 A life cycle model is defined. The life cycle model:

  • – is used for the development and maintenance of the software;

  • – provides for the necessary controls during the development and maintenance of the software;

  • – is documented.

• 24.1.2 A list must be made of the development tools used and configuration options chosen for the use of each development tool.

• 24.1.3 The documentation for the development tools includes:

  • – a definition of the development tool;

  • – a description of all conventions and directives used in the implementation of the development tool;

  • – a clear description of the significance of all configuration options for using the development tool.

• 24.1.4 The implementation standards to be applied must be specified.

• 24.1.5 The software must be specified and implemented in such a way that the security functions cannot be bypassed.

• 24.1.6 The security functions must be specified and implemented in such a way that they are protected against manipulation.

• 24.1.7 The security architecture of the software must be documented. The documentation:

  • – has a level of detail that corresponds to the description of the security functions;

  • – describes the security domains to which the security functions apply;

  • – describes how the initialisation processes are secured;

  • – demonstrates compliance with Numbers 24.1.5 and 24.1.6.

• 24.1.8 The functional specifications are documented. The documentation:

  • – maps the entire software;

  • – describes the purpose and application of all interfaces;

  • – identifies and describes all parameters associated with the interfaces;

  • – describes all actions associated with interfaces;

  • – describes all direct error messages that can result from calling the individual interfaces.

• 24.1.9 Traceability between functional specifications and security requirements is guaranteed to interface level.

• 24.1.10 All security functions are implemented in the source code.

• 24.1.11 Traceability between the entire source code and the specifications of the security functions is ensured and their correspondence is evident.

• 24.1.12 The security functions are designed and implemented in such a way that they are well structured. The internal structure is described and includes a rationale that:

  • – specifies the criteria used to assess «well-structured» and «complex»;

  • – shows that all security functions are well structured and not too complex.

• 24.1.13 The specifications include the following aspects:

  • – a description of the structure of the software in terms of subsystems;

  • – a description of the security functions as modules and, for each module, the objective and a description of how the module relates to the other modules; the description of the security enforcing modules must also include the available interfaces, the return values of those interfaces and the interfaces of the other modules that they use to interact with them;

  • – a description of all subsystems related to the security functions, including the possible interactions between them;

  • – a clear presentation of the subsystems associated with security functions to demonstrate that all interfaces conform to the behaviour described in the specification; the presentation must have a level of detail at least as far as the modules.

• 24.1.14 The software is provided with a unique identification.

• 24.1.15 The configuration management documentation includes:

  • – a description of how configuration items are identified;

  • – a configuration management plan describing how the configuration management system will be used in the development of the software and the procedures that will be followed for the adoption of changes or new elements;

  • – evidence that the procedures for adoption provide for adequate review of changes for all configuration items.

• 24.1.16 The configuration management system:

  • – uniquely identifies all configuration items;

  • – provides automated measures to ensure that only authorised changes are made to configuration items;

  • – supports the development of the software through automated procedures;

  • – ensures that the person responsible for accepting the configuration item is not the same person who developed it;

  • – identifies the configuration items that make up the security functions;

  • – supports verification of all changes to the software using automated procedures, including logging of the author and the date and time of the change;

  • – provides an automated method for identifying any configuration items that are affected by a change to a particular configuration item;

  • – can identify the version of the source code on the basis of which the software is generated.

• 24.1.17 All configuration items are inventoried in the configuration management system.

• 24.1.18 The configuration management system is used in accordance with the configuration management plan.

• 24.1.19 A configuration list is created that contains the following items:

  • – the software;

  • – evidence of the checks required to ensure security compliance;

  • – the parts that make up the software;

  • – the source code;

  • – the commit history¹²;

  • – reports on security flaws and on the status of their correction.

• For each element relevant to security functions, the developer is named. Each element is uniquely identified.

• 24.1.20 Software development security documentation includes:

  • – a description of the physical, procedural, personnel, and other security measures necessary to protect and ensure the integrity of the design and implementation of the software in its development environment;

  • – evidence that the security measures provide the necessary level of protection to preserve the integrity of the software.

• 24.2 Operation

• 24.2.1 An operating manual is created that includes the following for each user role:

  • – a description of the functions that the user can access and the permissions that must be controlled in a secure environment, including appropriate warnings;

  • – a description of how the available interfaces can be used in a secure manner;

  • – a description of the available functions and interfaces, in particular all security parameters under the control of the user, highlighting the values relevant to security;

  • – a precise description of all types of security events related to the user-accessible functions to be performed, including adjustments to the security properties of elements under the control of the security functions;

  • – a description of the security measures to be implemented in order to achieve the operational security objectives.

• 24.2.2 The operating manual must identify all possible modes of operation of the software, including the resumption of operation after the detection of errors and the description of the consequences and effects of errors on the maintenance of secure operation.

• 24.2.3 The operating manual must be precise and fit for purpose.

• 24.3 Reliable and verifiable compilation and deployment

• 24.3.1 The preparation process describes all the steps necessary for:

  • – the secure acceptance of the system components in accordance with the delivery procedure;

  • – the secure preparation of the operating environment in accordance with the operational security objectives;

  • – the secure installation of the software in the operating environment.

• 24.3.2 The delivery of the software or parts of the system must be documented and include all processes required to maintain security in the delivery of the software.

• 24.3.3 A reliable and verifiable compilation with appropriate security measures must be carried out to ensure that the executable code is a verifiable and faithful representation of the source code which has been subjected to public scrutiny and independent examinations. The compilation allows a chain of proofs to be created for the verification of the software and includes in particular:

  • – evidence that the compilation environment is designed as described on the public platform (all tools with the respective version, operating system and any configurations); any derogations must be documented and justified;

  • – evidence that the software has been compiled in accordance with the instructions available on the public platform; if an error in the instructions is found during compilation, this must be recorded and the documentation must subsequently be corrected;

  • – evidence that the source code submitted for public scrutiny and examined is in fact the source code used for compilation;

  • – evidence that no elements other than those provided for in the instructions have been introduced;

  • – evidence that the cryptographic signature of all dependencies has been verified against a proven, public, and trusted reference;

  • – evidence that a dependency vulnerability analysis has been performed and that, if vulnerabilities relevant to the software exist, they do not render the software vulnerable to attack;

  • – evidence that the parameters introduced, if any, do not render the system vulnerable.

• 24.3.4 A reliable and verifiable deployment with appropriate security measures must be carried out to ensure that:

  1. the code used in production is a verifiable and faithful representation of the source code which has been subjected to public scrutiny and independent examinations; and

  2. the production environment conforms to that which has been subjected to public scrutiny and independent examinations.

• The deployment allows a chain of proofs to be created for the verification of the software and includes in particular:

  • – evidence that the production environment is the same as that which has been subjected to public scrutiny and independent examinations; any discrepancies (firmware version, configuration files, etc.) must be documented and justified;

  • – evidence that the software deployed in the production environment is in fact that which was created using a reliable and verifiable compilation process;

  • – evidence that the parameters introduced, if any, do not render the system vulnerable.

• 24.3.5 The quality of the evidence of reliable and verifiable compilation and reliable and verifiable deployment must be confirmed by the presence of at least two witnesses from different institutions or by technical procedures to establish the truth of the evidence in the light of current academic knowledge and experience.

• 24.3.6 The chain of evidence of reliable and verifiable compilation and deployment is made publicly available.

• 24.4 Systematic correction of flaws

• 24.4.1 Processes are defined for the correction of flaws. The processes include:

  • – documentation of specific aspects, in particular with regard to the traceability of flaws for all versions of the software, and of the methods used to ensure that system users have information on flaws, corrections and possible corrective actions;

  • – the obligation to describe the nature and impact of all security flaws, information on the status of work to find a solution and the corrective measures adopted;

  • – a description of how system users can make reports and enquiries about suspected flaws in the software known to the software developers;

  • – a procedure requiring a timely response and automatic dispatch of security flaw reports and appropriate corrective actions to registered system users who may be affected by the flaw.

• 24.4.2 A process is defined for handling reported flaws:

  • – This process ensures that all reported and confirmed flaws are corrected and that the procedures for correction are communicated to system users.

  • – It provides for arrangements to ensure that the correction of security flaws does not give rise to new security flaws.

• 24.4.3 Policies must be defined for the reporting and correction of flaws. These include:

  • – instructions on how system users can report suspected security flaws to the developer;

  • – instructions on how system users can register with the developer to receive reports of security flaws and the corrections;

  • – details of specific contact points for all reports and inquiries on security issues concerning the software.

• 24.5 Quality Assurance

25. Quality of the source code and documentation

The source code and documentation must as a minimum meet the following quality criteria:

• 25.1 Traceability

• 25.1.1 Traceability is understood as those attributes of the software that provide a thread from the requirements to the implementation.

• 25.1.2 All cryptographic protocol requirements across all work products associated with the software development process must be traceable.

• 25.1.3 A description must be provided of the link between the legal requirements and the cryptographic protocol, the specifications and the documentation of the architecture.

• 25.2 Completeness

• 25.2.1 Completeness is understood as those attributes of the software that provide full implementation of the required functions.

• 25.2.2 The software must not contain ambiguous references (input, function, output). If the same element is referenced, the same term is always used.

• 25.2.3 All data referenced and all functions used are defined in the specifications.

• 25.2.4 All functions defined in the specifications are used.

• 25.2.5 For each decision point (e.g. conditional execution), the possible alternatives are defined in the specifications.

• 25.2.6 All parameters are defined and validated in the specifications (no implicit parameter passing).

• 25.2.7 All serious reported flaws must be fixed before proceeding to the next step in the development cycle.

• 25.2.8 The cryptographic protocol, specification, design and source code are aligned.

• 25.3 Consistency

• 25.3.1 Consistency is understood as those attributes of the software that provide uniform techniques and notations in design and implementation.

• 25.3.2 The descriptions in the documentation correspond to a convention created by the software developer.

• 25.3.3 The functions and the variables correspond to a naming convention created by the software developer.

• 25.3.4 Input and output of functions are handled according to a convention created by the software developer.

• 25.3.5 Errors are handled according to a convention created by the software developer.

• 25.3.6 The variable types used are consistent.

• 25.4 Commonality of communication

• 25.4.1 Commonality of communication is understood as those attributes of the software that facilitate the use of standardised protocols and interface routines.

• 25.4.2 The rules for communication with other systems are defined.

• 25.4.3 Communication is based on standardised communication methods.

• 25.5 Commonality of data

• 25.5.1 Commonality of data is understood as those attributes of the software that facilitate the use of standardised presentation of the data representation.

• 25.5.2 The standard method of representing data for communication with other systems must be formally defined.

• 25.5.3 Standards must be defined for converting from one representation to another.

• 25.5.4 The conversion functions should be centralised in one module.

• 25.6 Learnability

• 25.6.1 Learnability is understood as those attributes of the software that enable users to learn how to use the software.

• 25.6.2 Persons who operate and use the system must be trained and provided with the necessary documentation.

• 25.6.3 Training includes the opportunity to train on a system designed for training purposes.

• 25.6.4 Help on using the system must be readily available.

• 25.7 Usability

• 25.7.1 Usability is understood as those attributes of the software that enable users to interact with the system.

• 25.7.2 The software must be user-friendly. The user guidance is based on generally familiar schemes.

• 25.7.3 The client-side system as it appears to the person voting complies with Accessibility Standard eCH-0059¹³, with the exception of the requirements for alternative communication forms in Chapter 2.4 of the standard. The cantons shall ensure that compliance is confirmed by a specialist entity.

• 25.8 Error tolerance

• 25.8.1 Error tolerance is understood as the attributes of the software that provide continuity of operation under exceptional conditions.

• 25.8.2 Errors are detected and dealt with to enable the program to continue to run without interruption.

• 25.8.3 Error handling, including logging, is performed at the level most relevant to continued operation. An error that cannot be processed at one level is transferred to the next higher level.

• 25.8.4 Validity conditions are defined for the input parameters.

• 25.8.5 All input parameters are checked before execution starts.

• 25.9 Modularity

• 25.9.1 Modularity is understood as those attributes of the software that provide a structure of highly independent modules.

• 25.9.2 The task of each module is clearly defined.

• 25.9.3 The task of each module should be limited and focused. The tasks of two modules should not overlap.

• 25.9.4 The modules do not share data via a common volatile memory (e.g. global variable).

• 25.10 Simplicity

• 25.10.1 Simplicity is understood as those attributes of the software that implement functions in the most understandable way, which generally means avoiding practices that increase complexity.

• 25.10.2 A top-down approach (hierarchical structure) is chosen in the design.

• 25.10.3 The design does allow the duplication of functions between modules.

• 25.10.4 The design does not provide for global data, that is, data that can be used by everyone without being cleared as a parameter.

• 25.10.5 Complicated Boolean combinations in the source code must be avoided as far as possible.

• 25.10.6 No variables may be reused in the source code for purposes other than those originally intended.

• 25.10.7 In the source code, the number of nestings is limited as much as possible.

• 25.10.8 In the source code, cyclomatic and cognitive complexity is limited as much as possible.

• 25.11 Conciseness

• 25.11.1 Conciseness is understood as those attributes of the software that provide for implementation of a function with a minimum of instructions in the source code.

• 25.11.2 The software does not contain any superfluous passages in the source code (so-called «dead code»).

• 25.11.3 The source code does not contain any superfluous variables.

• 25.11.4 The source code should not contain any repetitions.

• 25.12 Self-descriptiveness

• 25.12.1 Self-descriptiveness is understood as those attributes of the software that create a situation in which addressees can identify the objectives, assumptions, constraints, inputs and outputs, components and status of the software.

• 25.12.2 Classes, functions and complex processing steps are commented on in the source code according to a convention defined by the software developer.

• 25.12.3 Variables and functions are given meaningful names.

• 25.12.4 A statement should only comprise one single line, unless readability is improved by the use of two or more lines. Multiple statements per line should be avoided.

• 25.13 Instrumentation

• 25.13.1 Instrumentation is understood as the attributes of the software that allow its use to be measured or errors to be identified.

• 25.13.2 The unit tests¹⁴ cover all possible paths and limits of the permitted and unpermitted values of the input parameters.

• 25.13.3 The integration tests cover all modules.

• 25.13.4 The software tests cover all modules.

• 25.13.5 Errors and necessary information are recorded in logs.

26. Examination criteria for the systems and their operation

• 26.1 Examination of the cryptographic protocol (Art. 10 para. 1 let. a)

• 26.1.1 Subject: the following are examined:

  • – whether the requirements set out in Article 5 in conjunction with Articles 6–8 and Number 2 of the Annex are met; this assessment is made in particular on the basis of the cryptographic and symbolic proofs of conformity;

  • – whether and to what extent the cryptographic protocol is based on existing and proven protocols and building blocks;

  • – which improvements could contribute to a strengthening of security.

• 26.1.2 Responsibilities: the examination is carried out by experts in cryptography. The Federal Chancellery commissions the examination and monitors its conduct in accordance with the mandate.

• 26.1.3 Time of examination:

  • – A complete examination must be carried out before the system is used for the first time.

  • – The examination is repeated after two to three years.

  • – The cryptographic protocol must be examined again whenever it is modified and in the event of relevant new research findings concerning the security of cryptographic elements used and the threat situation.

• 26.2 Examination of the system software (Art. 10 para. 1 let. b)

• 26.2.1 Subject: the following are examined:

  • – whether the cryptographic protocol tested in accordance with Number 26.1 has been implemented; the correct implementation of functions of trusted components must be checked in particular detail;

  • – whether the system software meets the requirements of this Ordinance and adequately supports the specified objectives;

  • – whether the client-side system as it appears to the person voting conforms to the eCH-0059 standard in accordance with Number 25.7.3; the examination may be based on a valid certificate or a valid examination report issued by an institution recognised by the Federal Chancellery confirming conformity with the standard.

• 26.2.2 Responsibilities: the examination is carried out by experts in cryptography and in software development. The examination is commissioned by the Federal Chancellery.

• 26.2.3 Time of examination:

  • – A complete examination must be carried out before the system is used for the first time.

  • – The examination is repeated after two to three years.

  • – The examination is repeated for each significant modification, in particular:

    • – following each modification to the cryptographic protocol;

    • – in the event of any modification to the source code of functions whose trustworthiness is essential to the soundness of the proofs provided for in relation to verifiability;

    • – in the event of relevant new research findings concerning the security of cryptographic elements used and the threat situation;

    • – if it is decided to dispense with mechanisms that aid the secure use of trustworthy components in accordance with Number 2 or if such mechanisms are fundamentally modified.

• 26.3 Examination of the security of infrastructure and operation (Art. 10 para. 1 let. c)

• 26.3.1 Subject: the following are examined:

  • – whether the system and its operation at the canton, the system operator and the printing office meet the requirements of this Ordinance and adequately support the specified objectives;

  • – whether the basic components, such as the software that aids the secure and independent use of control components, the operating systems used or the server used meet the best standards.

• 26.3.2 Responsibilities: the examination is carried out by experts on cryptography and in operating highly secure systems. The examination is commissioned by the Federal Chancellery.

• 26.3.3 Time of examination:

  • – A complete examination is carried out before the system is used for the first time.

  • – The examination is repeated after two to three years.

  • – The examination is repeated for each fundamental modification, in particular:

    • – following a modification to the cryptographic protocol;

    • – if it is decided to dispense with mechanisms that aid the secure use of trustworthy components in accordance with Number 2 or if such mechanisms are fundamentally modified;

    • – in the event of a fundamental modification to processes or infrastructure.

  • – If new versions of basic components (new servers, patches for operating systems or software that aid the secure and independent use of trustworthy components accordance with Number 2) are used, no new checks are required provided the basic components are still proven to comply with the best standards.

• 26.4 Examination of protection against attempts to infiltrate the infrastructure (Art. 10 para. 1 let. d)

• 26.4.1 Subject: it is examined whether experts commissioned by the Federal Chancellery succeed in infiltrating the infrastructure of the online system and gaining access to important data or taking control of important functions during a test.

• The tests must be carried out on the basis of potential vulnerabilities identified following a methodological analysis of publicly available documentation, in particular that specified in Article 11.

• 26.4.2 Responsibilities: the examination is carried out by security experts. The examination is commissioned by the Federal Chancellery.

• 26.4.3 Time of examination:

  • – A complete examination is carried out before the system is used for the first time.

  • – The examination is repeated after two to three years.

  • – The examination is repeated for each fundamental modification to the infrastructure.

  • – The examination must take place in the event of relevant new findings concerning the security of the equipment used and the threat situation.

• 26.5 Audit of the information security management system (Article 10 para. 2)

• 26.5.1 Objective: to assess whether the system operator’s ISMS is compliant with ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements. The scope of the ISMS includes all the system operator’s organisational units that are legally, administratively and operationally responsible for the system.

• 26.5.2 Responsibilities: the certification body is accredited by the Swiss Accreditation Service to perform audits according to the standard ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements. The audit is commissioned by the canton or the system operator; the canton ensures that the audit is carried out.

• 26.5.3 Term of validity of a document: Re-audits must be carried out at the intervals specified by ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements. A valid certificate and the corresponding «Statement of Applicability» is available each time the system is used. If a new version of Standard ISO/IEC 27001:2013, Information technology – Security techniques – Information security management systems – Requirements, is published, valid certification of the ISMS under the new version must be proven at the latest on expiry of the transition period. The scope of the ISMS may not be reduced thereby.