HAL Id: hal-01369572
https://hal.inria.fr/hal-01369572
Submitted on 21 Sep 2016
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Distributed under a Creative Commons Attribution| 4.0 International License
A Trustless Privacy-Preserving Reputation System
Alexander Schaub, Rémi Bazin, Omar Hasan, Lionel Brunie
To cite this version:
Alexander Schaub, Rémi Bazin, Omar Hasan, Lionel Brunie. A Trustless Privacy-Preserving Reputa-
tion System. 31st IFIP International Information Security and Privacy Conference (SEC), May 2016,
Ghent, Belgium. pp.398-411, �10.1007/978-3-319-33630-5_27�. �hal-01369572�
A trustless privacy-preserving reputation system
Alexander Schaub
1
, R´emi Bazin
1
, Omar Hasan
2
, and Lionel Brunie
2
1
Ecole polytechnique, 91128 Palaiseau, France
2
University of Lyon, CNRS, INSA-Lyon, LIRIS, UMR5205,
F-69621, France
Abstract. Reputation systems are crucial for distributed applications
in which users have to be made accountable for their actions, such as e-
commerce websites. However, existing systems often disclose the identity
of the raters, which might deter honest users from submitting reviews
out of fear of retaliation from the ratees. While many privacy-preserving
reputation systems have been proposed, we observe that none of them is
simultaneously truly decentralized, trustless, and suitable for real world
usage in, for example, e-commerce applications. In this paper, we present
a blockchain based decentralized privacy-preserving reputation system.
We demonstrate that our system provides correctness and security while
eliminating the need for users to trust any third parties or even fellow
users.
1 Introduction
These days, reputation systems are implemented in various websites, where they
are crucial for the customer experience. For instance, buyers are inclined to
pay more for goods if the seller has a good reputation [1]. One of the first
and best-studied systems in the e-commerce domain is the reputation system at
ebay.com [2]. Its main objective is to help prospective customers to determine
the trustworthiness of the sellers, and thus minimize the risk of fraud.
A study [2] showed that users may retaliate in case of negative feedback,
and thus raters are less likely to provide honest feedback. In order to avoid this
problem, several privacy preserving solutions have been proposed. Some of them
try to hide the identity of the ratee [3,4,5], while others try to hide the rating
[6,7,8] while making the aggregated reputation public.
While some of the existing privacy preserving reputation systems might be
suitable for e-commerce applications, we observe that each one of them comes
with its drawbacks. For example, Kerschbaum’s system [9] has been specifically
designed with e-commerce in mind. However, it is a centralized system, and thus
can potentially be abused by the central authority. Other schemes [8] achieve
anonymity even in this context, but are not trustless.
Given these considerations, we would like to achieve a trustless reputation
system, i.e. one that does not require the participants to trust other users or
entities to not disrupt the protocol or to breach their privacy. This privacy-
preserving reputation model should be suitable for e-commerce applications, and
we will therefore suppose that the identity of the customer is revealed during
the transactions that they can rate.
In order to achieve true trustlessness we also require our system to be de-
centralized. One way to obtain decentralization is to use a distributed database
in order to store the ratings submitted by the customers. We will achieve this
using blockchains.
The blockchain technology, which became popular thanks to the BitCoin
protocol [10], has been used in various applications. Among these applications,
we can count a domain name system (DNS) named Namecoin. The blockchain
can be more generally, as explained in [11], seen as a public distributed database,
with all the participants agreeing about its state in a secure manner. In BitCoin,
for example, this database serves to store a ledger of the coins that each user
owns, as well as the transactions between the users.
Anonymous reputation systems are a natural application for the blockchain
technology. There have already been some attempts at building such systems
[12], however, there seems to be no usable solution yet.
We will leverage this technology in order to achieve the objectives of our
reputation system. It will enable us to build a truly decentralized system, that
does not require the participants to trust other users, as the integrity of the
rating-history can be verified by every user.
We propose a truly trustless, decentralized, anonymity preserving reputation
system that is suitable for e-commerce applications. It is based on the blockchain
technology, and will induce low overhead for the processing of transactions, while
at the same time be robust and allow customers to submit ratings as well as tex-
tual reviews.
The rest of the paper is organized as follows. In Section 2, we will analyze
existing privacy-preserving systems and explain in further detail why they are
not suitable for e-commerce applications. In Section 3, we will explain the model
used for our system, and list the properties that we want to achieve. Then, in
Section 4, we will describe the necessary building blocks, and in Section 5, we
will present our system in detail. Finally, we will explain in Section 6, why this
system meets the expected goals. We conclude the paper in Section 7.
2 Related Work
Privacy preserving reputation systems have been studied in the literature for
a long time. One of the first proposed systems was designed by Pavlov et al.
[6] and uses primitives such as the secure sum and verifiable secret sharing. It
protects the confidentiality of the feedback by hiding the values of the submitted
ratings. Hasan et al. [8] later introduced a system based on additive homomor-
phic cryptography and Zero-Knowledge proofs where the privacy of a given user
can be preserved even in the presence of a large majority of malicious users. A
little later, Dimitriou et al. [7] proposed two protocols with a similar architec-
ture to the systems presented by Hasan et al., with slightly higher asymptotic
complexity, however, less demanding in terms of resources for the querier (he
has to relay less messages, verify less proofs, etc.).
Some protocols [6,8,7,13,14] are truly decentralized and the feedback is re-
trieved from the participants every time a querier wishes to learn the reputation
of another participant. Therefore, all the nodes have to stay online in order
to contribute to the reputation system, which is not suitable for e-commerce
applications, but might be useful in other contexts, such as P2P applications.
Hence, we will focus on privacy-preserving methods that completely hide the
identity of the raters. Protocols of such type do already exist, however each one of
them has its own weaknesses. The works of Androulaki et al. [13] and Petrlic et al.
[14], for example, are instances of pseudonym based schemes. Nonetheless, these
two require a Trusted Third Party (TTP), and are thus not truly decentralized.
As the TTP has to be completely trusted for certain operations, its misbehavior
could breach the privacy of the users or the correctness of the system.
Anceaume et al. [3,4] proposed slightly different solutions. Instead of all the
information about the reputation of the users being held by a single TTP, they
distribute the trust using a DHT-structure: every peer holds some part of the
information, which allows to compute the reputation of a service provider. More-
over, in their system, peers rate transactions between customers and service
providers, rather than directly rating service providers. This seems more suit-
able for e-commerce applications, as one would typically rate every transaction
made with a service provider, rather than periodically update their opinion on a
given service provider. It also allows to introduce proofs of transactions, which
guarantee (more or less) that only transactions that really took place can be
rated. However, as the service provider creates those proofs, it is complicated
to ensure that he doesn’t generate proofs for transactions that did not happen,
in order to submit positive reviews by himself and wrongfully increase his own
reputation. Anceaume’s and Lajoie-Mazenc’s systems only offer little protection
against these attacks. The system proposed in [4] also makes use of complicated
zero-knowledge proofs and is thus quite costly to perform (several seconds for
each participant, up to a minute in certain cases).
None of those protocols are trustless, and therefore need either the customers
or the service providers (or both) to trust some entities not to tamper with the
system or to break privacy, without being able to verify that there is no bad
behavior. We eliminate this weakness in the system that we present in this
paper.
3 Our model
3.1 Participants
For our system, we choose a model that is as close as possible to actual e-
commerce systems. As stated in Section 1, we will consider two types of users :
service providers (SP) who will sell goods or services, and customers who might
buy them. The most important part in e-commerce rating systems is the rating
of the service providers (as opposed to ratings from the seller about the buyer).
Therefore, we will only consider ratings from the customers about the SPs. Only
customers might be raters, and only SP will be ratees.
We will also suppose that the transaction will disclose the identity of the
customer : the SP will need the customer’s credentials, such as his credit card
number or address, in order to process the order. Even if the transaction is done
via an anonymous electronic currency such as Dashcoin or Zerocash, the service
provider will most certainly need the customer’s address in order to deliver the
good. We suppose that after every transaction between a customer and a SP,
the customer might rate the SP.
More formally, we will introduce the following notations :
S : The set of all the service providers (i.e. ratees)
C : The set of all the customers (i.e. raters)
P : The set of all the participants, P := S ∪ C. It is simply the set of all the
nodes participating in the network.
B : The blockchain.
As the blockchain defines an ordered set of blocks. A block is simply a set
of operations that are aggregated for maintenance reasons (it is more efficient
to store them this way). The blockchain can also be seen as a database whose
state will be the initial state (that is hard-coded) on which all the operations
contained in the subsequent blocks are applied.
Every time a new block is constituted, an award will be paid to the user that
constituted it. This works in a similar fashion as in the so-called “alt-coins”.
In our system, owning coins is mandatory in order to be allowed to receive
reputation. It also helps preventing spam and other kinds of attacks (as described
in section 6.2).
A : The set of all the addresses of the participants.
These addresses will be used for maintenance. Every service provider will
own one address. They will be used, in particular, to hold and spend the coins
generated by the blockchain, but also to identify the service providers.
Service providers will have a unique address, as issuing reputation tokens will
cost coins and owning an address is necessary in order to own and transfer them.
As a service provider will not gain anything from having more than one address
(see section 6.2 for more details), there is no need to try and enforce this policy.
Furthermore, it would be complex to enforce it in a decentralized fashion.
3.2 Operations
We will next describe the functions that are needed in our system. The protocols
that implement these functions will be described in the later sections. Most, if
