1 Introduction

We live in a post-privacy world where our opinions are controlled by a few big players in the market. The business models of companies like Facebook or Google rely on analyzing user opinions and behaviors and trade this valuable information with advertisers. Furthermore, a flourishing market of data brokers [4] is emerging to analyze consumer’s data to create consumer’s profiles which may contain sensitive user information. Every time you like a post in Facebook, every time you like or dislike something in Google or Youtube, every time you rate something in Amazon, or every time you participate in a poll, you are giving away valuable information about yourself.

Following the claim of edge-centric computing, we believe that key personal and social communication services should be decentralized and human-driven. In this article, we introduce TallyNetworks, an edge-centric distributed architecture designed to preserve your opinions/votes’s privacy in large online communities. The core idea of our system is to move opinion counting and storage to the edges of the network. A key assumption is that we cannot trust a single centralized entity to store and count our opinions. Instead, we will rely on a decentralized overlay of TallyBoxes controlled by users.

Our model is inspired in the remote voting paradigm where participants receive blindly signed voting credentials that permit them to vote anonymously. Like remote voting systems, we provide: 1. Privacy: the identity of a voter cannot be linked to his vote; 2. Integrity: the result of the election cannot be altered in any way; 3. Robustness: the tolerance to the misbehavior of users or external parties; and 4. End-to-end verifiability: the check that the reception and tallying of the votes is correct.

The key insight behind our approach is to leverage the services provided by a decentralized, one-hop overlay of Tallyboxes and combine it with cryptographic techniques such as blind signatures, pseudonyms and anonymous channels. The stability and capacity of edge nodes, mainly, stable home devices, datacenter edge services and nanodatacenters, permits the management of a global routing table and the one-hop abstraction.

As a proof-of-concept of TallyNetworks, we implemented a global membership service based on a robust and reliable broadcast and synchronization algorithm for Kademlia. Our algorithm permits to set the targeted robustness to attacks and churn by tuning redundancy across both the broadcast and synchronization phases.

2 Related Work

Edge-centric computing has been recently proposed as the natural evolution of peer-to-peer (P2P) systems. One of the major claims of this new paradigm is to move the control to the edges of the system (human-controlled) in order to preserve user’s privacy. Edge-centric systems may combine centralized and decentralized components in order to overcome the limitations of P2P systems.

In this new paradigm, TallyNetworks is one of the first Internet distributed services following the edge-centric paradigm. TallyNetworks combines centralized (Authenticator) and decentralized (TallyBox one-hop overlay) components to avoid security problems (like the Sybil attack) and to simplify architecture services (opinion voting and opinion retrieval, user membership, global knowledge of the routing table).

TallyNetworks cannot be directly compared with traditional e-voting systems as used in public elections. Such systems are normally based on centralized trusted components [5] managed by a public institution. The security requirements in these systems are extremely high; for example, voting from mobile devices cannot be considered without secure hardware devices.

More specifically, our proposal is more related with previous approaches of remote voting [7] or [8] using blind signatures [10]. In our case, the Authenticator component uses blind signatures to create an anonymous pseudonym (public key) that can later be used for voting or for participating in the network. By combining blind signatures and anonymous channels, we provide a level of pseudoanonimity that is by far sufficient for the problem of distributed management of personal opinions.

Another relevant related work is the literature on one-hop structured overlays [11]. Such overlays are highly suitable in networks of relatively stable peers like the ones proposed by edge-centric computing. In this case, the widespread adoption of stable home appliances (storage and compute sticks, media centers, nanodatacenters) and the improvements in residential bandwidth can create very efficient Internet services like the one proposed in this paper.

An important difference with previous related works on one-hop overlays is the algorithm employed for the efficient management of a huge up-to-date routing table. Previous works [11] aim to reduce the bandwidth imposed to nodes due to the event dissemination of active peers in the routing table. In our case, our global membership service will only send events about permanent joins or leaves from the network, and not about transient churn. Our novel approach efficiently combines a redundant broadcast algorithm for Kademlia with a syncing protocol.

Finally, previous works like [9] have linked networks of edge web servers using structured overlays. Interconnecting stable web servers using HTTP in structured overlays offer interesting value-added services to applications such as indexing or efficient content dissemination. Like in [9], our implementation also interconnects edge servers in a structured overlay. But in this case, our efficient one-hop overlay considerably reduces the communication overhead for the servers thanks to the adaptive broadcast/sync membership model.

3 Background: Blind Signatures

In this section, we revisit the concept of blind signature. A blind signature [6] allows a user to get a signature on a hidden message without the signer learning the message in question. A secure blind signature scheme ensures that nobody can fake a new signature for a new message (unforgettably) and that the signer will never be able to learn the message he is signing nor be able to link a signature to the protocol run where it was obtained (blindness).

We can define an analogy in order to make things clearer. Consider Alice has a letter which should be signed by an authority, Bob. But, Alice does not want Bob can read the letter. So, she finds a clever solution, she can place the letter in an envelope lined with carbon paper and ask Bob to sign it. Bob will sign the outside of the carbon envelope without being able to open it, so when he sends it back to Alice, she will be able to open the envelope and find the letter signed by Bob, without him seeing the contents.

We distinguish two operations: blinding \(\mathcal B(m)\), the process to put the letter m into the envelope to avoid Bob seeing the content, and the unblinding \(\mathcal {UB}(m)\), the process to taking out the signed letter m from the envelope.

4 TallyNetworks

In this section, we explain the key insights of our idea and the overall architecture of our solution, the life-cycle of the system and our novel global membership protocol based on Kademlia.

4.1 Main Idea

We aim to build a system that allows people to participate in any kind of poll or rating without disclosure of their real identities. But we want also to ensure the integrity of the result of any poll in the presence of malicious behavior. And very importantly, we want to provide end-to-end verifiability, i.e., the property that both the reception and tallying of votes is correct.

Instead of pure cryptographic solution, we propose TallyNetworks, a system that meets this challenge through a novel integration of cryptographic techniques with a one-hop Distributed Hash Table (DHT). For a given poll, the basic idea is to leverage the underlying one-hop DHT to assign the task of tallying to a subset of TallyBoxes with enough redundancy to ensure the correctness of the result. To guarantee the correct delivery of the votes to the responsible TallyBoxes, we will combine a broadcast algorithm with a pull based approach, recasting our problem as a secure distribution of votes.

4.2 Entities

The entities involved in our proposal are the following:

  • Participant: A registered user who can emit opinions (like/dislike) or participate in public polls anonymously from a mobile terminal. It can also query the system about the current state (votes, opinions) of specific polls or items.

  • TallyBox edge server: It is a node of the TallyNetworks overlay. It can cast votes but also retrieve and query them using the one-hop DHT. It receives votes from participants and redirects them to the appropriate TallyBoxes using the opinion identifier. The responsible nodes will then count and store the votes if they are valid according to their credentials.

  • Authenticator server: It authenticates participants and TallyBoxes based on an admission policy and blindly signs their credentials. For participants, it can check whether they are members of the community or real authenticated users. When a TallyBox edge server is accepted, then the Authenticator server will assign a unique identifier to it, in order to avoid Sybil attacks.

4.3 Security Threats

We assume that the goal of a malicious participant is to try to tamper with the poll results, for instance, by emitting multiple votes to favor some option, or even by emitting contradictory votes for the same poll. Our system will have to handle these situations in order to ensure one vote per user and that all participants have seen the same vote counting result.

Further, we assume that a malicious TallyBox can drop messages, flood the network with fake messages or try to disconnect other TallyBox servers from the network. Our system must mainly prevent the loss of votes in addition to thwart DoS attacks and overlay partitions.

4.4 Protocol Steps

We can distinguish different steps for participants and for TallyBoxes.

A TallyBox follows these protocol steps depicted in Fig. 1:

  • Obtaining the node identifier: To register a new TallyBox in the network, the first step is to contact the Authenticator server and request a node credential. If accepted, it will receive a signed credential including the node identifier and URL.

  • Entering the network: Since the network of TallyBoxes is a one-hop overlay, a joining node only needs to contact a group of TallyBoxes in the system, and then broadcast its signed join request to the rest of them. The joining node will also retrieve the one-hop routing table of the contacted TallyBoxes and the information for the active polls it is responsible for. This is transparently handled by the underlying DHT itself.

  • Participating in the network: Every TallyBox can fine tune its activity in the broadcast and synchronization protocols depending upon its resources. For example, a weak node might decide to avoid participating in the broadcast algorithm, and only periodically synchronize on a per-day or per-week basis.

Fig. 1.
figure 1

TallyBox protocol

Full size image

A participant follows these protocol steps shown in Fig. 2:

  • Obtaining a user credential: For a participant to register in the system, the first step is to contact the Authenticator server to request a user credential. To do so, the joining participant sends his public key PK in blinded form \(\mathcal B(PK)\). If admitted, he will receive a blindly signed credential \(\{\mathcal B(PK)\}_{sign}\) from the Authenticator to participate in TallyNetworks. Upon reception, the joining participant will unblind the signature to get \(\{PK\}_{sign}\).

  • Voting process: The participant can now use an anonymous channel (e.g., Tor) to cast a vote in any TallyBox using his public key PK as pseudonym. For robustness, the vote is cast to more than one TallyBox. To actually cast a vote v, the vote itself, its signature \(\{v\}_{SK, sign}\) with the participant’s private key SK, and the authentication credential \((PK, \{PK\}_{sign})\) must be sent via the one-hop overlay to the TallyBoxes responsible for the poll. For example, if a participants wants to add a Like to “Hans”, this Like vote will be addressed to the TallyBoxes responsible for the key “Hans”. The number of nodes responsible for each key can be configured to ensure the robustness of the voting process.

  • Tallying: Unlike traditional voting systems, the voting period can be always open and a participant can retrieve the current state at any time. Tallyboxes will receive votes for the polls they manage. For each vote, they will verify that the signature comes from a valid participant. Then, they will check that the vote is not a duplicate one. For keeping the vote counting up to date, the TallyBoxes responsible for the same key will also be “in sync” so that vote counting will eventually converge.

Fig. 2.
figure 2

Participant protocol

Full size image

4.5 One-Hop Architecture: Membership

To build a system capable of satisfying all of the goals listed in the introduction of this paper, it is necessary to implement an efficient DHT of stable TallyBox edge servers. Since servers do not maintain active connections (HTTP) and they have enough resources, they can maintain in disk a huge amount of contacts in the network. This is clearly in line with previous one-hop or two-hop overlays that maintain big routing tables.

The fundamental difference of our approach is that we only handle permanent joins or leaves (and not transient churn), avoiding active checks or keep-alives to detect and propagate the availability of nodes in the system. As explained below, our network is designed with sufficient redundancy to overcome transient churn and malicious participants.

We chose Kademlia as the structured overlay, mainly for its resilient design and ability to issue parallel queries. To maintain the routing tables up to date, we propose a novel Kademlia CAST & SYNC algorithm that leverages an existing broadcast algorithm over the Kademlia tree overlay. Our algorithm is adaptive to the size of the network and capabilities of each TallyBox. It also permits the configuration of the redundancy level across the broadcast and synchronization phases.

4.6 Kademlia CAST and SYNC

Our membership protocol aims to be adaptive to the size and persistent churn of the network. In a very small network, the broadcast (CAST) algorithm may become a star topology. In fast-growing networks, the broadcast traffic might be very costly, so the synchronization (SYNC) phase should prevail.

The combination of CAST & SYNC algorithms is ideal for large steady-state networks. In this case, the broadcast algorithm will accelerate convergence time and interactivity, and the SYNC phase will guarantee \(100\%\) coverage.

Broadcast. We build upon a previous Kademlia broadcast algorithm [2, 3]. This algorithm divides the key space using the Kademlia k-bucket routing tables. The initiator of the broadcast will send a message to a contact in each bucket. Then, recipients will forward it to their contacts in their buckets but only to those within their own region. This solution is the most natural and reliable way of dividing the key space in Kademlia for broadcasting. And it has been widely proven by the referred authors.

However, a simple Kademlia broadcast cannot assure the total coverage of the network, because messages can be lost due to churn and malicious participants. In our case, because malicious and offline TallyBoxes have the same effect on the network, we will treat them equally.

To overcome message losses, one typical solution is to increase the redundancy of the broadcast algorithm. This can be simply achieved by choosing more than one representative contact in each bucket. This really improves the reliability of the broadcast, but its communication cost quickly increases. As redundancy increases, the traffic grows with it, compromising scalability. Moreover, a network that is handling popular opinions is very susceptible to be attacked. So high packet loss ratios should be tolerated.

To give some simple numbers: If each node had 160 buckets, the initiator of the broadcast would send \(n*160\) messages, where n is the redundancy level. In our case, the messages size would be: TallyBox server ID (160 bits) + IP address (32 bits) + port number (16 bits) + signature of the server ID (2048 bits), the latter depending on the chosen cryptographic system. With \(n=3\), only the initiator of the broadcast would send around 1 MB. If this number is ported to huge networks, it is obvious that scalability will be severely undermined.

We must then disseminate information efficiently and with high resiliency to packet losses, but also minimizing the communication traffic in the network. In order to reduce redundancy, we will complement this protocol with a SYNC phase.

Redundancy Analysis. Let us first study the analytical model presented and validated by [2]. Later, we will extend it with the SYNC protocol. Now, let B be the number of nodes receiving the message over all nodes in the overlay. The expected coverage of the broadcast depending on packet loss ratio is then:

$$\begin{aligned} B = (1+P)^d, \end{aligned}$$
(1)

where P is the probability of correct delivery of a message and d is the length of the message path, which can be estimated as \(\log _{2} N\) (height of the broadcast tree), where N is the total number of nodes.

By dividing the above expression by the number of nodes \(2^d\), in order to get the ratio of nodes receiving the message m, we get:

$$\begin{aligned} m = \left( \frac{1+P}{2}\right) ^d \end{aligned}$$
(2)

In order to add redundancy, we will consider P as \(1-P_{l}^{k_d}\), where \(P_{l}\) is the packet loss ratio and \(k_{d}\) is the level of redundancy. Substituting it into the previous expression, we get:

$$\begin{aligned} \left( \frac{2-P_{l}^{k_d}}{2}\right) ^d \end{aligned}$$
(3)

These equations were validated by their authors, getting even better results in the experimentation when using the redundant algorithm, among other things because when messages are duplicated, each node can receive the message from multiple paths, which can be shorter than the estimated.

Broadcast + SYNC. Broadcast alone cannot make sure that every TallyBox maintains a perfect membership of system, even with high redundancy. For this reason, we propose a solution that uses less redundancy without (negligible) loss of robustness based on periodic reconciliation or anti-entropy. More concretely, the SYNC phase contacts periodically a number of random TallyBox servers and ask them for the last received updates. In this way, if a membership message is lost during the broadcast phase, it will be recovered from the nodes that received it. The synchronization period can be adapted depending on the network activity and the desired refresh rate.

We assume that malicious TallyBoxes will be evenly distributed as their IDs are assigned by the Authenticator server. So now, we analyze not only the reliability of the broadcast, but the reliability of combining the CAST with the SYNC phase.

Obviously the SYNC phase will depend directly on the redundant broadcast, so we will use its equation. There are two possible situations to fail when syncing. The first one is that the packet gets lost with probability \(P_{l}\) as before. The second one is that the packet arrives to a node that will respond, but the contacted node does not have the message because it got lost in the broadcast phase. Taking both situations into account, we defined the reliability S of the SYNC phase as:

$$\begin{aligned} S = 1-(P_{l}+(1-m)(1-P_{l})) \end{aligned}$$
(4)

But, as above, sending a single SYNC message is clearly insufficient to re-synchronize correctly, so redundancy, \(k_{s}\), is added to the equation which yields

$$\begin{aligned} S = 1-\left( 1+m*(P_{l}-1)\right) ^{k_s} \end{aligned}$$
(5)

In summary, a message can be received in two ways in our proposal, through the broadcast or if it was not received, it will be obtained it in the SYNC phase. So, the total system reliability M is given by:

$$\begin{aligned} M = m + (1-m)*S \end{aligned}$$
(6)

5 Analysis

5.1 Security Analysis

Now we analyze how our proposed protocol maintains the four security requirements:

  • Privacy: This property guarantees that the relation between a vote and the identity of the person who cast it cannot be discovered. We ensure this property thanks to the untraceability of the blind signature scheme and the use of an anonymous bidirectional channel between participants and TallyBoxes. Our model only provides pseudoanonimity since the entire voting history of a given pseudonym is stored in the network. If the participant is identified in any of the communications with a TallyBox, the whole voting history will be linked to his real identity.

  • Integrity: This property guarantees that the result of the election cannot be altered in any way. This includes: (1) allowing only registered users to cast votes; (2) allowing users only to vote once; and (3) making sure that votes are correctly tallied. The first property is ensured thanks to the Authenticator’s signature of the pseudonym. If the pseudonym is not signed, the vote will not be propagated into the network. The second property is ensured thanks to the user’s signature of each vote. If a vote signed with an already used key is emitted, it will be discarded. And the third property is ensured thanks to the redundancy of TallyBoxes that cover each key. This allows TallyBoxes to wait for a minimum number of messages before considering the vote as valid. If two different votes signed with the same key are received at the same time, both are discarded.

  • Robustness: This property guarantees that the protocol is robust against external attacks or malicious nodes that try to disrupt the overall process. In our case, our distributed overlay is designed with sufficient redundancy and communication to overcome such attacks. The most vulnerable part of our architecture is the centralized Authenticator component. If this component is not working due to attacks, the entrance of new nodes and users to the network is compromised, but in any case, the distributed TallyNetwork can continue working independently from the Authenticator.

  • Verifiablity: Our system provides individual verifiability, since a user can recover (via a GET request for a key) the votes of a poll from different TallyBoxes (key managers), and check if his vote is present and counted. A user can also check if all votes in a poll are correct according to their signatures and if the global count is consistent in the different TallyBoxes.

5.2 Experimental Analysis

Broadcast + Sync Simulation. As shown in Fig. 3, it can be easily seen how synchronization improves the overall system reliability M, according to the redundancy level determined by our equations. We simulated a network of 10, 000 TallyBoxes with Peersim.

Fig. 3.
figure 3

Broadcast + Sync evaluation

Full size image

As shown in Fig. 3, the obtained results (crosses) faithfully follow our analytical model (lines). However, our evaluation is rather pessimistic, as our equations capture only the worst-case scenario when all out-of-sync TallyBoxes try to re-sync at the same time, just after a broadcast. However, in a real situation, all nodes will not sync at the same time, which means that the probability of re-synchronizing increases after any other node has already synced. Therefore, a better reliability M will be achieved in practice.

The initial reliability of the broadcast is the one that corresponds to the value 0 of the x axis (sync redundancy).

Analyzing Fig. 1(a), the most relevant result obtained is that with \(P_l = 10\%\) of loss ratio and no redundancy, reliability improves from \(50\%\) to \(100\%\) by just contacting 8 nodes. In order to achieve the same result with just broadcasting, a minimum of 3 levels of redundancy would be required as shown in [2].

Figure 1(b) illustrates that with redundancy 2, we only need to contact 2 nodes when \(P_l = 10\%\) to achieve \(100\%\) reliability, and only 4 nodes to obtain \(100\%\) reliability with \(P_l = 20\%\). Even \(30\%\) of losses can be overcome by simply contacting 10 nodes, improving from \(50\%\) to \(100\%\) the level of reliability. To achieve this with just broadcasting, at least a redundancy level of 4 would be required.

Finally, compared with the previous figure, Fig. 1(c) shows that the number of nodes required to ask for synchronization is smaller up to \(P_l = 30\%\). But it also shows that a reliability of \(100\%\) can be achieved with a loss ratio of \(40\%\) by only contacting 10 nodes. Furthermore, even a loss ratio of \(50\%\) could be supported by just contacting 20 nodes or even less.

Those results clearly show that our network is more tolerant to failures with less resources, thus saving significant amounts of bandwidth. Moreover, the syncing phase makes our network much less fragile in front any attack that wants to silence the public opinion, thanks to a our greater reliability.

Notice that both the broadcast redundancy and the syncing redundancy are not static parameters and can evolve with the network, i.e., increasing or decreasing their values according to the network state. The state of the network and its loss ratio can be estimated by the nodes themselves by calculating the ratio of their unanswered requests sent to other TallyBoxes. So the algorithm can be adaptive to optimize system resources.

Protocol Cryptographic Operations Validation. We evaluated the cost of each protocol operation. We implemented them in Python using the Pycrypto library. We ran more than 10, 000 tests in an Intel Core i5-3470@3.20GHz with Debian 7.8. The obtained results are shown in the table below.

Table 1. Protocol simulation
Full size table

As showed in Table 1, the most limiting operations are signing and key generation. The latter is not a problem, as it is performed only once by each participant when joining. Consequently, the Authenticator is the only limiting entity. But because it is a trusted and controlled entity, it can be easily scaled to perform much more operations per second. Also, the Authenticator can rate limit the joining process to the network in order to reduce pronounced joining peaks.

Membership Storage Cost Evaluation. We also evaluated the space cost of storing the membership info. We assume a 160-bit TallyBox server ID, an IP address of 32 bits, a port of 16 bits and a signature of variable size. A TallyBox stores this information for each TallyBox in the network. As it can be seen in the following results Table 2 in MB and assuming 4096-bit signatures, it would take only around 513 MB of disk space, so space is not a problem.

Our combined SYNC & CAST algorithm is adaptive and resilient and can scale to big networks. Furthermore, thanks to full membership, we know the size of the network and depth of the tree, so that the aforementioned broadcast algorithm is efficient and feasible to implement in real networks.

Table 2. Storage cost evaluation (MB)
Full size table

6 Conclusion

In this paper we have presented TallyNetworks, an edge-centric distributed overlay for protecting the privacy of your online opinions. It is aimed for typical user online participation tools like open polls or item rating (stars, like/dislike).

A TallyNetwork must count opinions but also assure their correct retrieval under attacks or censorship attempts. We show in this work how it is possible to provide privacy, integrity, robustness, and end-to-end verifiability through the combination of secure technologies (blind signatures, anonymous channels) with a one-hop DHT of edge servers.