Policy for the Swiss Post E-Voting public bug bounty programme

Latest News:
2024-07-04 Update: The public intrusion test on e-voting this year has ended. We want to thank everyone, who participated!

2024-06-12 Seize the opportunity: The public intrusion test has once again started and will run until the 3th July. Explore and directly test the live infrastructure through the web interface. Details can be found in “C.4 Web application & infrastructure” Also, don’t miss out our new bounty grid, which increased and is active starting today.

2024-02-22 Update: We published a new major release of our e-voting system. Take a look at our repository!"

2023-07-31 Update: The public penetration test on e-voting this year has ended. We want to thank everyone, who participated!

2023-07-08 Don’t miss out: The public penetration test on e-voting will run until 31 July on "pit.evoting.ch". The scope is detailed below under “C.4 Web application & infrastructure (intrusion test)” Take your chance to check out and test the live infastructure directly through the webinterface!

2023-05-25 Update: We published a new release with new source code components and actualized our E2E environment. Take a look at our repository and stay up to date by signing up for our infomail.

2022-12-16 Update: We published a new release and actualized our E2E environment. Take a look at our repository and stay up to date by signing up for our infomail.

A. Introduction

A.1 About the Programme and this Policy

This bug bounty programme is a permanent and public programme that is a dedicated part of the Swiss Post e-voting community programme (hereinafter ECP): https://evoting-community.post.ch/

The goal of this programme is to continuously improve the security of the Swiss Post e-voting system.

By participating for the ECP public bug bounty, you agree to comply with this Policy and with the Code of Conduct for the ECP (hereinafter CoC). In case of conflict between this Policy and the CoC, the Policy has priority. If you do not accept this policy and the CoC, please do not participate in the ECP public bug bounty.

Please read carefully the programme policy, especially the indications regarding the different scopes of this programme and the corresponding reporting requirements. Please also follow our Code of Conduct.

A.2 About Swiss Post

Swiss Post’s services make everyday life easier for people in Switzerland – in both the physical and digital worlds. When it comes to e-voting, Swiss Post is digitizing what it does best: the secure transport of confidential information.

In order to meet highest quality standards, we are constantly mitigating security issues on multiple levels.
We appreciate any contribution that helps to improve the security of our systems and we will pay a fair reward for it.

A.3 About the Swiss Post E-Voting system

The developers, cryptographic experts and other specialists from Swiss Post are continuously improving the future e-voting system with universal verifiability. For information about the stage of development and our solution visit https://evoting-community.post.ch

In 2019, Swiss Post disclosed the source code of an earlier version of its e-voting system. Since then, we have continued to develop the system while improving the accompanying documentation and auditability. The feedback from those who took part provided us with a key basis for designing the current disclosure process, in particular with regard to the options for cooperating with interested parties. We have updated the process accordingly: the system is disclosed iteratively and transparently. Active dialogue with experts is a core component of the disclosure process, which forms part of the e-voting community programme.

A.4 Source code and other programme material

The source code, specifications, documentation and additional material for this programme are available in the public repositories under https://gitlab.com/swisspost-evoting

These repositories will provide you with the possibility of compiling the source code and running the whole Swiss Post E-Voting system in Docker on your local machine or in your lab to simulate an election event.

We will update the repositories frequently - make sure to stay on the latest version of the source code and other programme material when carrying out your research.

B. General Programme Rules

Participants are permitted to perform any tests and investigations on the systems as long as they act in good faith and as long as they respect the scopes and rules described below.

B.1 Eligibility and Coordinated Vulnerability Disclosure policy

We are happy to thank everyone who submits valid reports. This helps us to improve the security of the Swiss Post E-Voting system. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability is found in the latest version of the source code & documentation at the time of your report.
• The vulnerability must be a qualifying vulnerability (see below)
• Any vulnerability found must be reported as soon as possible after discovery through yeswehack.com.
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary (refer to the reporting requirements of the corresponding scope).
• You must avoid tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about requests per second).
• You must comply with the Coordinated Vulnerability Disclosure policy (see below).

Our security analysts examine reports about vulnerabilities. During our analysis, we will consider a worst case scenario and keep that in mind when defining the reward we are paying.

Any vulnerability disclosure follows the Coordinated Vulnerability Disclosure policy defined in the Code of Conduct.

Our aim is to provide the highest possible level of transparency. Therefore, all accepted findings are also published on our Gitlab. This includes the summary of the report, as well as comments. The reporter of the findings will be credited if the reporter agrees to its publication. If you want to stay anonymous or use an alias, please let us know in the report.

B.2 Legal safe harbour: consequences of complying with these programme rules

Swiss Post interprets activities by participants in public intrusion tests that comply with the programme rules as authorized access under the Swiss Penal Code and other anti-hacking and anti-circumvention laws. This includes Swiss Penal Code Articles 143, 143bis and 144bis. Swiss Post will only file a complaint about a violation of the programme rules if the code or the other materials or parts thereof are used commercially or productively. If legal action is initiated by a third party against a participant and the participant has complied with the programme rules as outlined in this document, Swiss Post will take the necessary measures to make it known to the authorities that such participant's actions have been conducted in compliance with this policy.

Any non-compliance with the programme rules may result in exclusion from the e-voting community programme.

C. Scopes & Peculiarities

This programme aims at hardening the e-Voting system in depths. For this reason, not only the web application and its infrastructure will be considered part of the scope, but also its source code, the cryptographic protocols in use as well as the specification and documentation.

To cover each and every aspect, you have access to the following elements to complete your research and testing:

• Application source code
• Protocol of the Swiss Post Voting System
• System Specification and documentation

In addition, periodical public intrusion tests lasting about 4 weeks each temporarily complements the e-voting community bug bounty programme. In 2024, the tests will start on 12 June 2024 and end on 3 June 2024.

We appreciate any contribution that helps to improve the security of our systems and we will pay a fair reward for it.

C.1 Scenarios with special bounties

There are some specific scenarios we are particularly interested in, for which we offer special bounties (reward grid +++). Those Bounties apply to all scopes and will be paid out instead of the CVSS based reward (not additional). During our analysis, we will consider a worst case scenario and keep that in mind when defining the reward we are paying:

• Manipulation that goes undetected by the voter and the system (70'000 - 230'000 EUR):
  • Manipulation of individual votes (without being detected by the proofs and logs generated by the e-voting protocol)
  • Manipulation of the tallying process (manipulating the results) without voters and auditors detecting it
• Manipulation that goes undetected by the voter but not by the system (50'000 - 70'000 EUR):
  • Manipulation of individual votes while maintaining universal verifiability mechanism (detected by trusted auditor)
  • Modifying the results of the election without being detected by a voter
• Voting privacy outside the voting client (40'000 - 50'000 EUR):
  • The privacy of a vote is broken (what he or she voted) on the server
• Vote corruption (30'000 - 40'000 EUR):
  • A vote is stored in the ballot box and that vote cannot be decrypted
  • A vote is stored in the ballot box in a way that gives the voter an unfair advantage

Any scenario described has to be achieved with respect to the trust assumptions of the Federal Chancellery Ordinance on Electronic Voting (VEleS) in order to qualify for a reward. For a summary of the assumptions see Chapter 1-2 of the Protocol of the Swiss Post Voting System.

C.2 Application source code

C.2.1 OBJECTIVES

• Identification of exploitable/demonstrable vulnerabilities in the e-voting system
• Identification of security issues without current evidence of exploitability in the e-voting system:
  • e.g. Unsecure functions in use, ...
• Identification of bad deviations from the System Specification which could lead to exploitation
• To be eligible for a reward, findings must have a measurable (or at least hypothetical and documented) impact on the e-voting system and its Confidentiality/Integrity/Availability and not be part of the ‘non-qualifying vulnerabilities’ (see list below)

C.2.2 REPORTING REQUIREMENTS

Please make sure to complete your report with the following details:

• Source code references:
  • implicated file(s)
  • implicated line(s) of code
  • any other information that might help us identify the vulnerable parts
• External references:
  • Academic references on the matter
  • Technical studies on the matter
  • Conference papers
  • Any other information that might help us understand the vulnerability
• Attack scenarios with their potential impact

C.2.3 REWARD POLICY

All qualifying vulnerabilities reported on the ‘Application source code’ scope will be analysed by our security team. Following this analysis, the impact of the vulnerability will be assessed and definitively scored using CVSS 3.1 or the scenarios with special bounties.
Based on the final scoring of the reported vulnerability, the bounty will be calculated in regard of the applicable reward grid (++ or +++).

C.3 Protocol, System Specification and documentation

C.3.1 OBJECTIVES

• Identification of security issues without current evidence of exploitability in the available e-voting system
  • e.g. implementation errors that prove to lead to exploitation independently of the current or future implementation
  • e.g. identification of deprecated protocols that prove to lead to exploitation independently of the current or future implementation
• Identification of bad deviations from the cryptographic proof, which prove to lead to exploitation independently of the current or future implementation
• To be eligible for a reward, findings must have a measurable (or at least hypothetical and documented) impact on the e-voting system and its Confidentiality/Integrity/Availability and not be part of the ‘non-qualifying vulnerabilities’ (see list below)

C.3.2 REPORTING REQUIREMENTS

Please make sure to complete your report with the following details:

• References to the documentation and the source code:
  • implicated protocols/algorithms
  • implicated pages/paragraphs
  • implicated line(s) of code (when relevant)
  • any other information that might help us identify the vulnerable parts
• External references:
  • Academic references on the matter
  • Technical studies on the matter
  • Conference papers
  • Any other information that might help us understand the vulnerability
• Attack scenarios with their potential impact

C.3.3 REWARD POLICY

All qualifying vulnerabilities reported on the ‘Protocol, System Specification and documentation’ scope will be analysed by our security team. Following this analysis, the impact of the vulnerability will be assessed and definitively scored using CVSS 3.1 or the scenarios with special bounties.
Based on the final scoring of the reported vulnerability, the bounty will be calculated in regard of the applicable reward grid (++ or +++).

C.4 Peculiarities

• We reserve the right to use a "OneFixOneReward" rule, i.e., if two or more endpoints/forms use the same code base and a single fix can be deployed to fix all the ensuing flaws, only one report will be considered as eligible for a reward and other reports will be closed as informative. However, all reports will be reviewed edge by edge.