Proverum: A Hybrid Public Veriﬁability
and Decentralized Identity Management
Christian Killer, Lucas Thorbecke, Bruno Rodrigues,
Eder Scheid, Muriel Franco, and Burkhard Stiller
Communication Systems Group CSG, Department of Informatics IfI,
Universit¨at Z¨urich UZH, Binzm¨uhlestrasse 14, CH—8050 Z¨urich, Switzerland
Abstract. Trust in electoral processes is fundamental for democracies.
Further, the identity management of citizen data is crucial, because ﬁ-
nal tallies cannot be guaranteed without the assurance that every ﬁnal
vote was cast by an eligible voter. In order to establish a basis for a
hybrid public veriﬁability of voting, this work (i) introduces Proverum,
an approach combining a private environment based on private permis-
sioned Distributed Ledgers with a public environment based on public
Blockchains, (ii) describes the application of the Proverum architecture
to the Swiss Remote Postal Voting system, mitigating threats present
in the current system, and (iii) addresses successfully the decentralized
identity management in a federalistic state.
Keywords: Hybrid Public Veriﬁability, Decentralized Identity Management,
Remote Postal Voting
Trust in the integrity of voting processes or ﬁnal tallies is crucial for democracies.
One key property to achieve this is veriﬁability, a fundamental building block for
transparency, and establish trust in voting processes . E.g., public veriﬁability
allows anyone to verify the accuracy of the voting process and the ﬁnal tally
independently. Veriﬁability for voting is achieved by deploying Public Bulletin
Boards (PBB), which store ballots and veriﬁable logs. Since PBBs are append-
only data structures and publicly shared, anyone can verify information on them.
Often veriﬁability mechanisms are based on applied cryptography and pro-
tocols, which are not easily understood by the public. Therefore, administrative
veriﬁability plays a crucial role. From an election’s administrative perspective,
administrative veriﬁability is usually accomplished in analog processes with pa-
per audit trails enabling manual recounts. Such mechanisms rely on redundancy
(e.g., the four-eye principle) to mitigate collusion and minimize trust placed in
single entities. Therefore,  argues whether the combination of public and ad-
ministrative veriﬁability can reach publicly veriﬁable voting. The integrity of an
election can only be assured, when authorized voters can cast valid ballots.
arXiv:2008.09841v1 [cs.CR] 22 Aug 2020
2 C. Killer et al.
In the context of electronic voting, the property of eligibility veriﬁability de-
notes that anyone can check that each ballot published on a PBB was cast by a
registered, eligible voter and at most one vote is tallied per voter . Unforge-
ability states that only eligible voters can construct authorized ballots . These
properties achieve more robust privacy and veriﬁability mechanisms for existing
voting processes. In order to achieve unforgeability and eligibility veriﬁability si-
multaneously, it is necessary to deploy a suitable Identity Management (IdM),
which assures the integrity of the citizen and electorate data. Thus, achieving a
notion of public veriﬁability is impossible without a reliable IdM.
From a governmental perspective, the integrity of citizen identity data is cru-
cial for formal processes, not only voting. Keeping citizen registries updated and
providing identity-dependent processes (e.g., the creation of Electoral Registers
(ER)) are fundamental in a federalistic system, where authorities (e.g., Cantons
in Switzerland) remain control over their data and infrastructure. Deploying a
secure IdM in a federalistic state prefers a decentralized approach while enabling
the secure management and a privacy-preserving exchange of identity data.
Therefore, IdM of citizens is fundamental for any government, and electronic
means provide more eﬃcient solutions to manage citizen data. E.g., Estonia pro-
vides a physical smart card, which can be used by Estonian citizens to authenti-
cate themselves online and sign legally-binding documents . The development
of Electronic Identity (eID) solutions was launched or is being developed specif-
ically for Switzerland . Even though these proprietary solutions are legally
obliged to grant users control over their personal data, the centralized and opaque
nature of deployments indicates otherwise. In turn, novel approaches toward a
Self-Sovereign Identity (SSI) appeared with the promise of empowering users
with control over their data. SSI solutions gained a suitable platform for eﬃcient
SSI solutions  due to public Blockchains (BC), which oﬀer an alternative to
remedy ownership and access control issues. Users can manage credentials stored
on the BC, while also improving transparency, security, veriﬁability, and interop-
erability around the processes of IdM as a whole. Thus, simpliﬁed management of
trusted identity information is reached, enabling government agencies to access,
share, and use sensitive data, while maintaining integrity.
Thus, this work here proposes the Proverum architecture to address the lack
of public veriﬁability in voting processes and introduces a new deﬁnition of Hy-
brid Public Veriﬁability (Hybrid PV). Proverum combines a public and private
environment, allowing for tamper-proof audit trails, published by peers operated
by authorized entities and independently veriﬁable by anyone. The private envi-
ronment serves as a private permissioned distributed network formed by author-
ities. The public environment’s deployment depends on the speciﬁc requirements
of public veriﬁability being designed by either (i) publishing to a public BC, (ii)
deploying a public permissioned BC, or (iii) granting partial read access to a
subset of the private environment. Proverum deﬁnes a practically feasible ap-
proach oﬀering Hybrid PV for voting, allowing the public to verify data within
a public environment, while maintaining a privacy-preserving, veriﬁable audit-
trail within the private environment. While the Proverum architecture can be
Hybrid Public Veriﬁability and Decentralized Identity Management 3
applied beyond voting, e.g., for electoral processes or a sharing of information
in the health-care sector (e.g., reporting veriﬁable infection numbers of a pan-
demic disease outbreak), this paper’s focus is on applying Proverum to the Swiss
Remote Postal Voting (RPV) system. The current prototype focuses on the im-
plementation of a private environment, modeling diﬀerent Swiss municipalities.
The source code is available in .
The remainder of this paper is organized as follows. Relevant background and
related work is presented in Section 2. While Section 3 provides all Proverum
design aspects, Section 4 details the prototype, following with Section 5 on dif-
ferent use cases. Section 6 renders a detailed evaluation, while ﬁnally Section 7
draws major conclusions.
2 Background and Related Work
Following the outline of relevant background on Blockchains (BC) and Dis-
tributed Ledgers (DL), the same is provided for Identity Management (IdM)
and the overview on the Swiss Remote Postal Voting (RPV) approach.
2.1 Blockchains and Distributed Ledgers
A BC is an immutable backward linked-list, formed by blocks of transactions,
which are maintained within a distributed network, governed by peers following
a consensus mechanism. Four main development types of BCs are classiﬁed in
Figure 1. Each quadrant contains a deployment type: the x-axis represents write
permissions and the y-axis read permissions. All permissioned BCs are better
labelled DL, since they show one or more restrictive characteristics.
Public Permissionless BCs are the most prevalent deployment type, and
most cryptocurrencies are implemented as such. Typically, these BCs serve as a
tamper-proof and transparent platform for trustless exchanges, eliminating the
need for a Trusted Third Party (TTP) as an intermediary . As outlined by
Bitcoin, these deployments are open to (i) all participants regarding a read and
a write access and (ii) the participation in the consensus mechanism .
Public Permissioned DLs oﬀer a public read access, however, write permis-
sions are restricted to a set of authorities. These DLs are suitable for a setting
of multiple trusted authorities wanting to publish publicly veriﬁable data, ac-
cessible to anyone (e.g., publishing hashes of, or encrypted votes in a Remote
Electronic Voting (REV) system ).
Private Permissioned DLs are often used in enterprise settings, where a con-
sortium consisting of entities identiﬁed collaborate. Also, a private DL can be
used to establish transparency and veriﬁability among participants of a given
process, while enabling the granular conﬁguration of access control over data
and allowing more performant consensus mechanisms to be deployed.
Permissioned DL deployments basically introduce TTPs again. Prominent
projects include Hyperledger Fabric (HLF)  or Corda , which allow for a
modular conﬁguration of roles, access control, and data exchange channels.
4 C. Killer et al.
Fig. 1: BC and DL Deployment Types, based on 
While  provides a BC and DL overview, speciﬁcally HLF and Corda as
permissioned DLs are similar regarding the usage of certiﬁcate standards for
IdM and diﬀerent with respect to consensus mechanisms and underlying data
structures. On one hand, HLF arranges all transactions in a DL. On the other
hand, Corda sees all transactions as private. Each individual state is tracked
under the supervision of a trusted, neutral third party notary, which orders and
tracks these states to guarantee their validity and avoid double-spending.
Typically, in paper-based voting systems (e.g., the Swiss RPV systems), the
voter cannot verify that her vote was correctly included in the ﬁnal tally. She
would have to trace the ballot through the process of placing it into the ballot
box (or post box), emptying the box, anonymizing the ballots, and tallying the
votes, which is unrealistic for a large number of voters. Therefore, veriﬁability
in voting systems is not a binary concept . Veriﬁability notions depend on
the sets of stakeholders, mechanisms, and assumptions in place, and therefore
the following deﬁnitions serve as a reference for those contributions made in this
work. For a systematic overview, please refer to .
Deﬁnition 1 Individual Veriﬁability (IV)
A voting system has the IV property if a voter can verify that her ballot is in the
recorded set of ballots and contains her intended vote .
Deﬁnition 2 Universal Veriﬁability (UV)
A voting system has the UV property if anyone can verify that the voting re-
sult was tallied correctly, meaning that all valid ballots were included with their
intended vote .
Deﬁnition 3 End-to-End Veriﬁability (E2E-V)
E2E-V is thmd similarly to IV and UV, but divided into three more speciﬁc
properties. See  for an in-depth deﬁnition.
1. Cast-as-Intended veriﬁability requires that a voter can verify that her ballot
contains the intended vote. For example, this is not obvious if votes are
encrypted before sending them.
2. Recorded-as-Cast veriﬁability demands that a voter can verify that the voting
system received and stored her ballot correctly. E.g., in case of a public list
of votes, the voter can consult the list and check, if it contains her vote.
Hybrid Public Veriﬁability and Decentralized Identity Management 5
3. Counted-as-Recorded veriﬁability says that anyone can verify the correctness
of the voting result, meaning that it includes all the recorded and valid ballots.
E2E-V and the combination of IV and UV cover similar aspects. In research,
usually either E2E-V or the combination of IV and UV is applied, but not both
simultaneously. IV and Cast-as-Intended veriﬁability (CaIV) address the prob-
lem of a non-trusted voter platform in REV. CaIV needs to be addressed, if the
voter’s platform cannot be controlled and trusted, which is typically the case,
if the voter is able to cast an electronic ballot remotely. IV and CaIV together
assure that the voter can detect that her vote was compromised, most probably
by malicious code on the voting device . While IV, UV, and E2E-V are of
central importance for REV schemes, they are hard to prove in combination,
but even harder to be deployed within an operational and practical RPV sys-
tem. Therefore, the following notions of veriﬁability are necessary, when existing
systems are evaluated, such as the Swiss RPV system.
Deﬁnition 4 Eligibility Veriﬁability
A voting system has the eligibility veriﬁability property if anyone can verify that
the voting result only contains votes from eligible voters, and only includes one
vote per voter .
Eligibility veriﬁability is crucial for any voting system, independent of being
based on paper ballots or operated electronically, since it assures the integrity of
the ﬁnal tally, making it veriﬁable that only eligible voters cast their vote once.
Deﬁnition 5 Administrative Veriﬁability (AV)
A voting system oﬀers AV, when election oﬃcials have means to protect against
certain kinds of errors and fraud, typically accomplished with tools like paper
audit trails that enable manual recounts and spot checks .
Deﬁnition 6 Public Veriﬁability (PV)
A voting system provides PV, when any individual can verify the accuracy of a
tally regardless of any conspiracies of any size .
Based on these deﬁnitions, AV includes various processes implemented by
trusted authorities, while PV requires cryptographic mechanisms to be deployed.
In other words, AV determines real-world processes in operation and PV is based
on an ideal, theoretical property and hard to deploy in practise.
2.3 Identity Management
Identity Management (IdM) determines a very active ﬁeld of research and an
economic sector. From a global perspective, a range of Single Sign-on (SSO)
solutions and underlying standards exists. The most common protocols include
OpenID and OpenID Connect (which extends OpenID with OAuth2 authoriza-
tion) , which deﬁne open and decentralized standards that let users choose
from a variety of contributing identity providers to use an account elsewhere
6 C. Killer et al.
for authentication and authorization purposes. The emergence of BCs initiated
alternative IdM approaches. For instance, Sovrin uses a public permissioned BC
to form a distributed identity network . Read access to Sovrin is public,
while running a so-called validating node within the network, which has to be
authorized by the Sovrin Foundation. The initial code base of the Sovrin project
originates from Hyperledger Indy, supervised by the Linux foundation . The
development of decentralized identity solutions addresses in new standards veri-
ﬁable credentials (VC)  overseen by the World Wide Web Consortium (W3C)
and the Decentralized Identity Foundation (DIF).
2.4 The Swiss Remote Postal Voting (RPV) System
The Swiss RPV is inherently built on External Service Providers (ESP) and
trusted relationships among all parties involved. For eligible voters, the cur-
rent process is hard to decipher and impossible to verify.  provides (i) an
overview of the Swiss RPV system, (ii) a detailed insight into the process ﬂow,
and (iii) a respective risk assessment. This analysis and risk assessment in 
provides critical Threat Events (TE) emerging during various stages of the vot-
ing process. The current RPV system oﬀers beneﬁts, too, such as its physical
decentralization and the distribution of trust. Due to Switzerland’s federal and
decentralized structure, each Canton and municipality manages their respective
jurisdictional electoral procedures autonomously. Cantons use centralized infor-
mation systems to administer or transfer crucial data, e.g., Electoral Registers
(ER) or Web-based assistance tools, to transmit intermediate results . The
deployment of a digitized REV potentially decreases the necessary amount of
trust placed in institutions and people, shifting trust to transparent and ver-
iﬁable processes instead . For instance, various cryptographic mechanisms
enable the electorate to verify diﬀerent steps of these processes (e.g., end-to-end
3 Proverum Architecture
As stated, the key goal of Proverum is to provide a feasible approach to pro-
vide Hybrid PV for voting and electoral processes, which allows the public to
verify data in a public environment, while maintaining a privacy-preserving and
veriﬁable audit-trail in the private environment.
Fig. 2: Proverum Architecture for Hybrid PV
Hybrid Public Veriﬁability and Decentralized Identity Management 7
Therefore, the Proverum architecture consists of a private and a public en-
vironment (cf. Figure 2). The private environment is formed by authorities col-
laborating as a private permissioned DL. Trusted authorities are authorized to
participate in the DL; thus, they can be governmental authorities or private com-
panies. Authorities execute a consensus protocol, validate transactions, group
them into blocks while exchanging data in a Peer-to-Peer (P2P) fashion. There-
fore, the private environment provides the distribution of the trust, including a
privacy-preserving, veriﬁable audit log. The deployment of the public environ-
ment depends on requirements of public veriﬁability, which is achieved by either
(i) publishing to a public BC, (ii) deploying a public permissioned BC, or (iii)
granting partial read access to a subset of the private environment.
The public and the private environment require an information exchange
interface. While the detailed interface speciﬁcation depends on the architec-
ture decisions taken, a fundamental requirement is that the private environment
oﬀers PKC capabilities; i.e., each authority acts as a CA, thus can sign and
thus authorize multiple keypairs for diﬀerent target uses. Given that the private
environment provides these capabilities (otherwise, the DL consensus and pri-
vate P2P data exchange are practically impossible), a secure exchange interface
can be implemented based on. Thus, cryptographic signatures and encryption
schemes are then to be used for secure and authentic intra- and inter-authority
Additionally, the interface can serve as a gatekeeper for private informa-
tion, performing either security or integrity checks on the data or proofs to be
published, hindering the leaks of private data. Depending on the use-case, the
publishing process could include air-gapped processes which require oﬄine sign-
3.1 Hybrid Public Veriﬁability
This work introduces a new deﬁnition of public veriﬁability: Hybrid Public Ver-
iﬁability (Hybrid PV), which combines AV and PV, and thus implicitly includes
the need for a private and public environment, i.e., the requirement for a combi-
nation of private permissioned DLs and public permissioned BCs, clearly dividing
the private audit trail (audit-trail for AV) from the veriﬁable public information
(audit-trial for PV).
Deﬁnition 7 Hybrid Public Veriﬁability (Hybrid PV)
A system oﬀers Hybrid PV, when any individual can publicly verify the accuracy
of all administrative procedures performed.
Since PV as of Deﬁnition 6 includes the resistance against conspiracies of
any size, such an assumption is practically infeasible in many practical cases
e.g., Proverum applied to the currently deployed Swiss RPV, since many Exter-
nal Suppliers are trusted, as well as municipal authorities, employees and citizens
counting paper ballots . On the one hand, the underlying trust model of DLs
and BCs depends on the consensus of these networks i.e., on the architectural
8 C. Killer et al.
choices made. I.e., given a network operating with the Proof-of-Authority (PoA)
consensus and nauthorities, a conspiracy of up to (n/2) + 1 authorities can be
tolerated. On the other hand, a Byzantine Fault Tolerance (BFT)-style consensus
merely tolerates up to 1/3 malicious nodes. Nevertheless, such an attack could
easily be detected by other network participants (i.e., other authorities). How-
ever, future approaches can surpass these limitations by using the Proverum
architecture, achieving resistance to conspiracies of any size. Such a security
property would require the deployment of additional cryptographic protocols
embedded in the Swiss RPV process.
3.2 Private Environment Architecture
The private environment of Proverum requires a high-level systems architecture,
depicting diﬀerent authorities and their access to various Smart Contracts (SC)
deployed on DLs. Since identities of authorities maintaining the private environ-
ment are known, there is no need for a probabilistic consensus algorithm, e.g.,
Proof-of-Work. Therefore, a suitable Byzantine Fault-Tolerant (BFT) consensus
can be selected. Depending on the trust model, a single authority or a set of
authorities is responsible for forming the consensus.
Network Architecture: Figure 3 depicts the overview of the network architec-
ture. Network participants are Cantons, municipalities, the Swiss confederation,
and External Service Providers (ESP), e.g., artifact manufacturers and the Swiss
Post. For fault-tolerance reasons, each participant hosts at least two peers and
acts as a Certiﬁcate Authority (CA) to issue certiﬁcates.
Fig. 3: Proverum Private Environment Architecture
Hybrid Public Veriﬁability and Decentralized Identity Management 9
Two purpose-speciﬁc SCs for (i) Citizen Management (CM) and (ii) Result
Publication (RP) allow keeping these SCs conﬁdential among those involved. For
instance, the ESP only has access to the (i) CM SC, while Swiss government
authorities have access to the (ii) RP SC. A consortium of all authorities forms
the consensus. ESPs are not part of that consortium but have read access to the
SCs and transactions are persisted on three diﬀerent DLs. To one instance
of a Federal Ledger, government entities are connected to. Cantonal Ledgers
include one corresponding Canton and its subordinate municipalities, including
the Swiss Confederation. In a country-wide deployment, 26 Cantonal Ledgers
exist. Electoral authorities join several External Ledgers of ESPs on a munici-
pal, Cantonal, and federal level. Since citizen data needs to be kept private at
all times, each municipality operates a private data collection maintaining the
Citizen Registry (CR) without exposing any details on a shared channel.
3.3 Public Environment Architecture
The public environment of Proverum can be supported by three diﬀerent designs
that are not mutually exclusive but can be combined to achieve public veriﬁabil-
ity. For the public environment a public permissioned DL can be applied using
a Proof-of-Authority (PoA) consensus mechanism since PoA reduces the proof
eﬀorts, meaning that only participants that have been given authorization can
produce blocks . As well, diﬀerent trust models apply to each design. Thus,
depending on the speciﬁc requirements to be met, the Proverum architecture
allows for all three options to be followed. Each design option (summarized as
of Table 1) achieves public veriﬁability, whereas (i) the publication to a public
BC mainly relies on the data to be authentic. For (ii), the deployment overhead
is large, but the environment achieves the best public veriﬁability, showing a
fully transparent audit trail that the public can audit and authorities can con-
trol. The option (iii) opens up the Application Programming Interface (API), is
easily implemented, but also achieves the weakest notion of public veriﬁability,
since a single trusted endpoint represents a single point of failure.
1. Publishing to a Public BC enables the publication of data and proofs
(e.g., cryptographic hashes of ERs, aggregated voting results, or Non-Interactive
Zero-Knowledge Proofs) by directly signing cryptographically a transaction
containing these data, and broadcasting them to the respective public BC.
This requires appropriate key management on the side of publishing au-
thorities since every public BC requires the management of public/private
keypairs to perform the transaction signature. Alternatively, one can rely
on  to send and retrieve data within a transaction to multiple BCs with-
out being locked into a single platform. With such a BC-agnostic platform,
the immutability of public BCs is exploited with less complex barriers. The
publication on a public permissionless BC, such as Bitcoin or Ethereum, of-
fers transparency and public veriﬁability. The trust model depends on the
speciﬁc public BC chosen since they vary in their selection of consensus
10 C. Killer et al.
Table 1: Comparison of Proverum’s Public Environments
Trust Model Key
Trust in (i)
public BC and
per authority in
Medium To query SC
High To query full BC
Low To query API
algorithms. However, since public permissionless BCs do not rely on any
Trusted Parties, the public can be assured that data retrieved was stored in
a censorship-resistant and tamper-proof manner .
2. The Deployment of a Public Permissioned DL requires additional
operations. This is similar to the approach used in , where a Public
Permissioned DL serves as a publicly readable PBB. Therefore, the trust
model is comparable to the private environment, since the DL is formed by
trusted authorities. The main diﬀerence compared with the publication on
a public BC is that authorities can censor transactions in a permissioned
setting and change the content of the DL. However, since the public can
read all data persisted on that DL, such changes could be observed and
audited by the public, which is allowed to participate as a full node, persisting
and duplicating the DL. From an economic perspective, the deployment of
a public permissioned DL requires an operational eﬀort to maintain and
3. Granting Partial Read Access to a subset of the private environment can
be oﬀered by providing a public interface, which can be queried by anyone.
However, providing a centralized point of failure to a distributed system
providing veriﬁability is not optimal, since it separates private transactions
from the public, e.g., by only giving access to a public interface that can be
queried. The trust model here resembles a central server, since no distribution
of trust is taking place towards the public. Economically, this option is most
Hybrid Public Veriﬁability and Decentralized Identity Management 11
Fig. 4: Overview of the Proverum Prototype
4 Prototypical Implementation of Proverum
For the instance of the private environment being prototyped HLF is applied.
Therefore, SCs are referred to as Chaincodes and DLs among a subset of au-
thorities are referred to as Channels . The current prototype focuses on the
implementation of the private environment. The source code is available in .
The prototype shows two components executed on the infrastructure of the
authority: (i) a frontend Web application implemented in Typescript, using An-
gular in a Model-View-Controller architecture . The frontend serves a dash-
board showing the current network status. It contains input forms and pop-up
dialogs to enable authorities to submit transactions easily and trigger chaincode
calls through the Client App (cf. Figure 4). Second, (ii) the Client App interacts
through the Fabric Node SDK with the BC infrastructure and encapsulates the
various chaincode calls within REST endpoints based on the ExpressJS Web
In HLF, the global state of the DL is separated based on the chaincode that
accesses it. Therefore, two world states are maintained, one for the CM and one
for the RP chaincode. The separation of states is required, since both chain-
codes are distinct and involve diﬀerent stakeholders. All chaincodes are written
Shim API to process DL states and communicate with other peers . The CM
chaincode contains Create, Update, Update, and Delete functionality to manage
CRs and the generation and sharing of the ERs. Additionally, the CM chaincode
allows for the generation of Non-Interactive Zero-Knowledge Proofs, proving the
eligibility of voters contained in the ER.
Prototype Network Setup: The prototype network is composed of the con-
federation, two Cantons, and two municipalities per Canton (cf. Figure 5). Ad-
ditionally, the Swiss Post and a single ESP (e.g., a voting artifact supplier)
serve as a provider for all municipalities. A total of 2,202 municipalities is served
in a country-wide deployment, split up among 26 Cantons, including diﬀerent
ESPs. Each stakeholder hosts two peers for fault tolerance purposes. HLF forms
consensus by using an Orderer, a dedicated node arranging transactions in a de-
terministic fashion . All authorities of the consortium are part of the Ordering
Service (cf. Figure 5). Hence they can serve as Orderer and create Channels.
12 C. Killer et al.
The CM chaincode is required on all peers, while the RP chaincode is only
maintained on government peers to keep it separated from any external channels.
Thus, four diﬀerent channels exist in the network. On the federal channel, where
government authorities are connected, Cantonal channels are occupied by the
Canton and its two subordinate municipalities. The municipalities 1 to 4 and
ESPs maintain private citizen data in an instance of a database.
Fig. 5: Prototype Network Architecture
Data Model: It is derived from the eCH eGovernment . Information is
encapsulated in a state object, which can be queried with a state key. Citizen
states are modelled according to eCH-0011. These ﬁelds contain basic personal
information encapsulated in data types deﬁned by, eCH-0044,eCH-0045, and
are depicted in Figure 6. The citizen state contains a method to invoke a vot-
ing restriction in case a person becomes non compos mentis. Citizen states may
have a corresponding voting citizen state counterpart, if the citizen is an eligible
voter, implying Swiss citizenship, adulthood, a main residency in the registered
municipality, and no voting restrictions. Therefore, eligible voters show an ag-
gregation relationship to the voting list state representing the ER. These states
are all private; thus, they are oﬀ-chain, persisted in the private data storage of
the municipality. Only the corresponding cryptographic hash digest of individual
eligible voters, the ER, and plain voting results are persisted on-chain.
5 Use Cases
Three Use Cases (UC) are deﬁned to evaluate the prototype of Proverum. Each
UC shows diﬀerent operations and actions being performed by those stakeholders
involved. UC1 focuses on the IdM of citizens, in detail, the relocation of citizens.
Hybrid Public Veriﬁability and Decentralized Identity Management 13
Fig. 6: Class Diagram
UC2 and UC3 focus on the support of voting and electoral processes in the Swiss
RPV, especially the generation and validation of ERs and the voting and election
result publication process, respectively.
UC1 Citizen Relocation: In the event of a citizen relocating from munici-
pality nto municipality n+ 1, citizen data needs to be (i) sent ﬁrst from nto
n+ 1. Then (ii) the original municipality ndeletes all records. Since citizen data
need to remain private to these municipalities, they are shared P2P via a gossip
protocol (cf. Figure 7). The Ordering Service is not involved and cannot access
private data; only peers of authorized municipalities have access. Thus, private
citizen data is not included in the transaction to the orderer . Only a cryp-
tographic hash digest of the private data is endorsed, ordered, and persisted on
DLs of peers on the Federal Channel. Finally, the hash serves as evidence of the
transaction and is used for state validation and can be used for audit purposes,
UC2 Generation and Validation of Electoral Registers: As depicted
within Figure 8, when a new vote is scheduled, municipalities generate the re-
spective ER and the subset of the CR containing all eligible voters. The CM
chaincode manages the generation of the ER. The CR is checked and excludes
all citizens that (i) do not possess Swiss citizenship, (ii) are not older than eigh-
teen, or (iii) do not have their primary residence within the given municipality.
14 C. Killer et al.
Fig. 7: UC1: Citizen Relocation
Fig. 8: UC2: Generation and Validation of Electoral Registers (ER)
The ER is exchanged to either one or multiple ESPs, which will prepare and
print physical voting artifacts (e.g., voting envelope, paper ballots, and paper
ballot envelope). Additionally, the municipality publishes cryptographic hashes
of the complete ER and hashes of each voter on the external channel, serving as
a time-stamped proof for veriﬁcation or audits. When the manufacturer receives
these private data, they will be checked against hashes published to ensure that
the data transmitted is correct. This allows the Swiss Post (SP) to verify artifacts
upon reception. In detail, as soon as the SP receives these artifacts, each envelope
is scanned to verify, whether the hash of each ballot is contained in the ER, also
verifying the completeness of the batch by computing the hash of the complete
list. This allows for the detection of loss, theft, or incomplete production of
voting artifacts. Voters can gain public veriﬁability by seeing a read operation
on the External Channel through personalized hyperlinks, e.g., being embedded
on the postal voting artifacts as a QR code (Quick Response).
UC3 Accumulation and Publication of Preliminary Results: Authorities
often use insecure communication channels (e.g., telephone, fax, or non-secured
electronic mail) to exchange preliminary results within Switzerland. From a lo-
cal and global perspective, election laws do not require any guarantee regarding
Hybrid Public Veriﬁability and Decentralized Identity Management 15
Fig. 9: UC3: Secured Accumulation and Publication of Preliminary Results
the integrity of electronically transmitted results, which bears the potential for
attacks . Thus, UC3 deﬁnes a secured process to assure integrity and au-
ditability for preliminary as well as ﬁnal election results.
Therefore, UC3 details the propagation of preliminary results from a munici-
pality to the Cantonal level by publishing results through Cantonal Channels (cf.
Figure 9). In turn, Cantons perform plausibility checks, and, if necessary, trig-
ger manual recounts. Furthermore, Cantons publish accumulated results from
all municipalities and publish these on the Federal Channel, which the federal
government will assemble to tally the preliminary results.
Municipalities, Cantons, and the confederation digitally sign ﬁnal prelimi-
nary results and publish the data in the public environment, especially to a
public permissioned BC or a public BC, which enables public veriﬁability. While
still relying on the integrity of these individual results published by the diﬀerent
authorities involved, UC3 reaches the veriﬁability for the preliminary tally pub-
lication. Instead of relying on insecure communication channels, the preliminary
results’ authenticity and integrity are cryptographically secured.
The evaluation of Proverum is grouped according to Threat Events (TE) of the
Swiss Postal Voting Process Flow (PVPF) as outlined in . Table 2 lists all
TEs, alongside the respective Mitigation (M) techniques, which are considered
relevant here. Fundamental elements contributing toward mitigation include: (i)
the Public-Key Infrastructure paired with (ii) the use of the private Proverum
environment as a distributed, immutable audit trail on a private permissioned
DL, (iii) the public environment for public veriﬁability, and (iv) the use of SCs
to automate veriﬁable and distributed workﬂows for a decentralized IdM.
TE1 refers to targeted cyberattacks on ESPs or municipal information systems
(e.g., in the form of Distributed Denial-of-Service attacks). There does not
exist a single explicit mitigation strategy, since cybersecurity best-practices
need to be applied across all processes and the entire infrastructure involved.
TE2 refers to tampering with CR master records. As of today, municipalities
and Cantons manage their CR in centralized information systems. In con-
trast, Proverum records every change in a CR master record in private DL’s
16 C. Killer et al.
Table 2: Threat Events and Mitigation Techniques of the Swiss RPV 
TE Description Mitigation
TE1 Delay production of physical artifacts no Mitigation
TE2 ER master records Immutable Audit Trail
TE3 ER data snapshot Cryptographically signed Tx
TE4 Forge physical artifacts Eligibility Veriﬁability Mechanism
TE5 Steal assembled VEs before dispatch Artifact Veriﬁcation Mechanism
TE6 Re-route VEs Immutable Audit Trail
TE7 Steal VEs from voter letterboxes Report, Blacklist and Re-Issuance
TE8 Steal VEs from municipal letterbox Report, Blacklist and Re-Issuance
TE9 Re-route VEs Immutable Audit Trail
TE10 Cast stolen or forged VEs Artifact Veriﬁability Mechanism
TE11 Access stored VEs Immutable Audit Trail
TE12 Manipulate tallying Smart Contract & Audit Trail
TE13 Manipulate ﬁnal tally Smart Contract & Audit Trail
TE14 Initiate premature destruction Cryptographically signed Tx
immutably records, which simpliﬁes the audit, detects errors, and an indica-
tion of fraudulent changes in the CR. Subsequently, in the ER.
TE3 describes the risk of tampering with ER snapshot data in transit from the
municipality to an ESP, e.g., to print VSCs, and assemble VEs. As outlined
for UC2, the ER is now persisted on the Cantonal Ledger in a digitally signed
transaction, which is persisted on the immutable, tamper-proof DL.
TE4 describes the forgery of physical voting artifacts, which requires speciﬁc
knowledge of the Swiss PVPF and access to various digital templates. With
Proverum the eligibility veriﬁability is assured, since each ballot cast is cross-
checked with the ER, which was published on the Cantonal Ledger (cf. UC2,
Figure 8). To consider an attack successful, the adversary requires access to
the authorities to create fake identities, which would need to be included
into the CR and ER, in order to pass veriﬁcation checks during tallying.
TE5 refers to the theft of assembled VEs before they are dispatched. As pro-
posed within UC2, the SP veriﬁes the receival of all VEs, which assures that
not a single VE is missing. In case of theft, the SP will realize misses and
reports the theft to Proverum, which automatically (i) triggers a re-issuance
of a new ER with newly salted hashes, so the hashes are diﬀerent from the
ones issued previously and (ii) all the stolen VEs are invalidated in an ex-
plicit blacklist transaction. These blacklists are checked during the tallying
TE6 describes the re-routing of VEs, which assumes an adversary to have access
to internal systems of the SP and may require co-conspiring postal employees.
Proverum oﬀers the immutable audit trail. Hence, the detection of such
attacks is eased, since irregularities in the delivery of VEs can be detected
by any member of the respective DL (e.g., the Cantonal Ledger).
Hybrid Public Veriﬁability and Decentralized Identity Management 17
TE7 describes the theft of yet unused VEs from voters’ letterboxes. Even if all
prior steps of the PVPF were executed correctly, the mitigation of this attack
depends on the voter to realize a theft and (i) report it to the municipality’s
election oﬃce, which can (ii) re-issue a second set of voting artifacts to be
used to cast a valid, eligible vote. The stolen VEs are (iii) invalidated in an
explicit blacklist transaction and newly created artifacts are registered on
the Cantonal Ledger.
TE8 describes the theft of VEs from the municipal letterbox, which can contain
(i) VEs returned by SP or (ii) manually returned by voters. This distinction
is essential, since manually returned VEs are not reported as returned in the
shared DL. Therefore, if a voter knows he/she returned the VE and wants
to verify the audit trail and the VE did not get registered (and reported
as received) by the election oﬃce. Similarly to TE7, this needs to be (i)
reported, (ii) old artifacts are blacklisted and (iii) artifacts are re-issued.
Proverum records all actions in transactions on the DL, thus creating an
TE9 refers to the re-routing of VEs as soon as they cast and return the VE via
SP. This is handled as for TE6.
TE10 refers to the casting of stolen or forged VEs. Similarly to TE4, an ad-
versary is required to refer to the casting of stolen or forged VEs and an
adversary would require access to the CR.
TE11 describes the threat of storage access to VEs cast within the respective
municipality and, thus, is not a threat that can be mitigated by purely digital
means since it requires trust in authorities. In contrast, Proverum addresses
the risk of theft of VEs by logging and publishing all incoming VEs on the
DL, thus, making a disappearance of any VE detectable.
TE12 refers to the risk of manipulation during tallying. Although the manual
counting mechanisms are out of scope of Proverum, the private environment
could be used to record either (i) individually counted tallies or, as imple-
mented in UC3, preliminary results. The SCs enforce the correct counting
of the results entered and allow all peers in the DL to verify the correct
execution, thus, distributing the trust among all authorities. Further, in-
stead of using insecure communication channels, cryptographically signed
and broadcast transactions are persisted on the DL.
TE13 describes the manipulation of the ﬁnal tally. Since most Cantons use
proprietary software to handle vote transmission for preliminary results ,
an adversary can tamper with these results. Similarly to TE12, the cryp-
tographically signed transaction assures that results can not be tampered
with, since they are included in the immutable and distributed DL.
TE14 describes the triggering of premature destruction. Municipalities await
a formal message over insecure communication channels to receive the ap-
proval to destroy all physical voting artifacts. For instance, a potential attack
could send e-mails to various municipalities, triggering premature destruc-
tion. Proverum mitigates this by using the DL to communicate only authen-
ticated, and veriﬁable destruction commands to municipalities.
18 C. Killer et al.
Thus, the Proverum architecture is generally an eﬀective combination of a
private and public environments to achieve Hybrid PV and serves as a highly
suitable approach for a decentralized Identity Management (IdM) of citizens,
including unforgeable states. The private environment is based on a private per-
missioned DL, which forms the immutable audit-trail, enables the decentralized
IdM, and allows for an automated process with SCs of otherwise manual and
error-prone analog processes. The public environment achieves transparency by
using public (permissioned DLs) to reach public veriﬁability.
The artifacts are veriﬁed again as soon as the votes were cast and returned to
the municipality. Forged voting artifacts can be easily detected since the cryp-
tographic hash digest generated in the ﬁrst step was published on the channel
and veriﬁed. However, it is still possible for an adversary to steal artifacts (and
then cast them) when they are in transit between the Swiss Post and the Eligible
Voter. Even in the case of theft, it would be possible to detect when many voters
suddenly ask for an additional set of voting material.
7 Summary and Conclusions
Since veriﬁability and trust are fundamental for transparency in voting processes,
the explicit application of the Swiss Remote Postal Voting (RPV) case serves
for Proverum as a real-world example with various trusted stakeholders inter-
acting via insecure communication channels . The exploitation of prior work
(analysis and a risk assessment leading to Threat Events, TE) lead to the new
design of Proverum and its prototypical implementation, which laid via three
Use Cases (UC) the technical basis to achieve public veriﬁability in the Swiss
Like PBBs in electronic voting, the Proverum architecture provides an im-
mutable audit trail with multiple permissioned DLs for a clear distinction of a
private environment and public BCs. The prototypical implementation highlights
the practical feasibility of using a Web-based frontend application, which can be
easily operated by the authorities, and which interacts with a Client App con-
necting to the permissioned DL. Note that the publication of veriﬁable informa-
tion (e.g., cryptographic hashes of Electoral Registers (ER) or Non-Interactive
Zero-Knowledge Proofs, proving the eligibility of voters listed) is crucial to build-
ing trust in any digital process. Thus, trust is not only distributed and enforced
by the DL, but Proverum serves as a comprehensive platform to enable trans-
parency as well as administrative and public veriﬁability. Likewise, the integrity
of any ﬁnal tally is only trusted, when public veriﬁability mechanisms are pro-
The application of the Proverum architecture in the Swiss RPV cases has
proven to serve as an eﬀective and technically feasible approach in a governmen-
tal setting to provide (i) trust, (ii) integrity, (iii) transparency, (iv) Hybrid PV,
and (v) an architecture for a decentralized IdM. In that sense, the exploitation
of public permissionless Blockchains (BC), as well as public permissioned Dis-
Hybrid Public Veriﬁability and Decentralized Identity Management 19
tributed Ledgers (DL), makes Proverum ready for other electoral processes as
well or a sharing of information in the health-care sector as stated.
8 Future Work
Future work has already started and focuses on (i) the proposal of novel crypto-
graphic protocols to be used in the Swiss RPV context, leveraging the Proverum
approach with immutable evidence storage. Further steps cover (ii) the formal
deﬁnition of the protocol used for enabling Hybrid PV in the Swiss RPV sys-
tem, and (iii) additional prototypical implementation steps and performance
evaluations concerning the scalability of those use-cases implemented.
This paper was supported partially by (a) the University of Z¨urich UZH, Switzer-
land and (b) the European Union’s Horizon 2020 Research and Innovation Pro-
gram under Grant Agreement No. 830927, the CONCORDIA Project.
1. Angular: Angular.io,https://https://angular.io/
2. J. Benaloh: Administrative and Public Veriﬁability: Can We Have Both? In: Con-
ference on Electronic Voting Technology (EVT 2008). USENIX Association, USA,
3. J. Benaloh, R. Rivest, P. Y. A. Ryan, P. Stark, V. Teague, P. Vora: End-to-end
Veriﬁability. CoRR abs/1504.0, 4 2015, http://arxiv.org/abs/1504.03778
4. T. Bocek, B. Stiller: Smart Contracts – Blockchains in the Wings. In: C. Linnhoﬀ-
Popien, R. Schneider, M. Zaddach (eds.) Digital Marketplaces Unleashed. Springer
Berlin Heidelberg, Berlin, Heidelberg, 2018, pp. 169–184
5. V. Cortier, D. Galindo, R. K¨usters, J. M¨uller, T. Truderung: Sok: Veriﬁability
notions for e-voting protocols. In: 2016 IEEE Symposium on Security and Privacy
(SP), 2016, pp. 779–798
6. e-Estonia Brieﬁng Centre: e-Identity - e-Estonia, http://pvpf.ch/estonia-eid
7. M. Hearn, R. Gendal Brown: Corda: A distributed Ledger. Whitepaper
8. Hyperledger: Fabric Wiki,http://bcbev.ch/hlfdocs
9. Hyperledger: Indy,http://bcbev.ch/hli
10. H. Jonker, S. Mauw, J. Pang: Privacy and Veriﬁability in Voting Systems: Methods,
Developments and Trends. Computer Science Review , 2013
11. C. Killer, B. Rodrigues, R. Matile, E. Scheid, B. Stiller: Design and Implementa-
tion of Cast-as-Intended Veriﬁability for a Blockchain-Based Voting System. In:
Proceedings of the 35th Annual ACM Symposium on Applied Computing. SAC
’20, Association for Computing Machinery, New York, NY, USA, 2020, p. 286–293
12. C. Killer, B. Stiller: The Swiss Postal Voting Process and Its System and Security
Analysis. In: R. Krimmer, M. Volkamer, V. Cortier, B. Beckert, R. K¨usters, U.
Serd¨ult, D. Duenas-Cid (eds.) Electronic Voting. Springer International Publishing,
Cham, 2019, pp. 134–149
20 C. Killer et al.
13. S. Kremer, M. Ryan, B. Smyth: Election veriﬁability in electronic voting protocols.
ESORICS’10, 15th European Symposium on Research in Computer Security 6345
LNCS, 389–404, 2010
14. S. Kremer, M. Ryan, B. Smyth: Election Veriﬁability in Electronic Voting Proto-
cols. In: Dimitris Gritzalis, Bart Preneel, Theoharidou Marianthi (eds.) Computer
Security – ESORICS 2010. Springer Berlin Heidelberg, 2010, pp. 389–404
15. OpenID Foundation: OpenID, https://openid.net/
16. Proverum: GitHub,http://pvpf.ch/proverum
17. K. Sako, J. Kilian: Receipt-Free Mix-Type Voting Scheme. pp. 393–403, 1995
18. Satoshi Nakamoto: Bitcoin: A Peer-to-Peer Electronic Cash System, 2008
19. E. J. Scheid, T. Hegnauer, B. Rodrigues, B. Stiller: Bifr¨ost: a Modular Blockchain
Interoperability API. In: IEEE Conference on Local Computer Networks (LCN
2019). Osnabr¨uck, Germany, October 2019, pp. 332–339
20. E. J. Scheid, B. B. Rodrigues, C. Killer, M. F. Franco, S. Rafati, B. Stiller:
Blockchains and Distributed Ledgers Uncovered: Clariﬁcation, Achievements, and
Open Issues. IFIP’s AICT 600 1(1), 1–29, 2020, Under preparation.
21. B. Smyth: A foundation for secret, veriﬁable elections, 2018
22. D. M. Sommer, M. Schneider, J. Gut, S. Capkun: Cyber-Risks in Paper Voting.
CoRR , 2019, http://arxiv.org/abs/1906.07532
23. M. Sporny, D. Longley, D. Chadwick: Veriﬁable Credentials Standard,https://
24. SwissSign Group AG: SuisseID – Digital passport and signature,https://www.
25. Verein eCH: eCH - E-Government Standards,http://ech.ch
26. M. Volkamer, O. Spycher, E. Dubuis: Measures to Establish Trust in Internet Vot-
ing. In: E. Estevez, M. Janssen (eds.) 5th International Conference on Theory and
Practice of Electronic Governance (ICEGOV 2011), Tallinn, Estonia. ACM, 2011,
27. P. Windley, D. Reed: Sovrin: A Protocol and Token for Self-Sovereign Identity and
Decentralized Trust. Whitepaper, The Sovrin Foundation, January 2018
All links were last followed on August 20, 2020.