A Privacy-enabled Solution for Sharing Social Data in Ad-hoc
Mobile Networks
Slawomir Grzonkowski, and Peter M. Corcoran, Member, IEEE
Abstract—There is an enormous growth of the use of mobile
devices and the social Web. Thus the users want to exchange their
social data easily by using their phones or PDAs. We show that
existing solutions put the users at privacy lost and insecure
authentication risks. We describe our protocol for exchanging
users’ social data that offers increased security and privacy. Our
solution also causes lower data overhead for the coordinating
party in comparison to existing solutions.
I. INTRODUCTION
Over the last decade we have experienced an enormous
growth of the use of mobile phones. These devices have
become an important part of our lives and everyday’s
activities. The today’s mobile phones offer the possibility of
managing our social data such as social networks, photos,
professional and personal calendars. Thus, the requirement
that two users want to share or exchange this information has
become obvious. However, mobile phones are produced by
different vendors and they offer different hardware parameters
that support a number of incompatible data transmission
standards. This causes the interoperability problem that was
addressed by applications such as bu.mp™ [9]. The bu.mp
project enables users to share their social data using mobile
phones of different producers. In this paper, we show that this
solution solves the interoperability problem. However, it
introduces a number of privacy and security issues. We
describe them and we demonstrate how they can be effectively
solved using existing web standards and a secure
authentication service that we previously developed [8].
II. REVIEW OF EXISTING SOLUTION
To enable interoperability, in solutions such as [9], there is a
requirement of the Third Trusted Party (TTP). Its role is to
match two users and to route data between them. A typical
protocol works in the following way:
1. Two users requests the social data exchange
2. Each mobile phone sends its location, exact time and page
that is currently displayed to TTP
3. TTP uses its match algorithm to pair two mobile phones
4. TTP routes all the information between the phones
The work presented in this paper was supported (in part) by
the Lion project supported by Science Foundation Ireland
under Grant No. RSF0840 and Enterprise Ireland under Grant
No. REI 1005. A method and apparatus for authenticating a
user is a pending patent.
This approach causes the following security and privacy
problems: 1) it offers centralized architecture. Such solutions
suffer scalability issues. They also have single points of
failures; 2) TTP is able to collect all the routed information.
Some providers also explicitly inform users that they do it to
improve user’s experience. However, the user has no control
over the stored information, which contains contacts, private
pictures and data from social network portals; and 3) there is a
possibility that two users will be connected who did not intend
to. There is a random element in the match algorithm. The
possibility of this situation is small, but it can happen at
crowded places such as conferences. Such users would be able
to access the content that they are not supposed to preview.
III. IMPROVED PROTOCOL AND ITS ELEMENTS
A. Social web
In our solution we take advantage of the Friend-of-a-Friend
(FOAF) vocabulary [1]. FOAF was created to support the
publication of machine-readable user profile descriptions as
well as describing online social networks. The complete
vocabulary specifies about 60 elements that belong to several
categories: FOAF Basics, Personal Info, OnlineAccounts / IM,
Project and Groups, Documents and Images.
FOAF can be adopted to access control through the use of the
foaf:knows property, which specifies that a given individual
knows another one. However, the FOAF vocabulary does not
support trust levels, but such extensions were proposed in
various extensions, for example in the FOAFRealm project
[2].
Due to the lack of authentication information in the initial
vocabulary, FOAF cannot be used to provide authentication
services. For this reason, FOAF was extended with a
foaf:openid property containing information about users'
OpenID logins. Although this property can be used for
providing authentication, its usability is marginal: OpenID has
been perceived as a convenient, but insecure authentication
method. FOAFRealm [2], which provided a FOAF-based
authentication service, uses the foaf:mbox property as user
logins. To increase privacy, the system stores only
foaf:mbox_sha1sum. Therefore, the value of foaf:mbox is
never revealed to strangers.
The vocabulary also does not support any property for storing
passwords. This is a reason why FOAFRealm introduces
xfoaf:passowrd_sha1sum to the vocabulary. During the
authentication process, passwords provided by the users are
compared with the password SHA1 sum stored in the user's
profile at the server side.
This way of authentication does not provide strong security.
Someone who possesses the user's hash, may perform a
dictionary attack and also this method is prone to phishing [3].
To address those issues we implement our FOAF-based
authentication using a Zero-Knowledge Proof protocol [4].
B. Zero Knowledge Poof Authentication Protocol
The zero-knowledge proof (ZKP) term has been formalized by
Goldwasser, Micali, and Rackoff [4]. It describes a group of
challenge-response authentication protocols, in which parties
are required to prove the correctness of their secrets, without
revealing these secrets. Such protocols exist for any NP-set,
provided that one-way functions exist [4]. The use of zeroknowledge proofs as a mean of proving identity was first
proposed by Fiege et al. [5]. There are many modifications of
ZKP protocols. For example Guillou and Quisquater [6]
proposed how to lower the bandwidth and memory
requirements; Schnorr [7] described an alternative that uses the
discrete logarithm problem. Our implementation uses a
protocol based on isomorphic graphs [8].
C. Protocol Overview
We note that Step 5 of the presented protocol is based on our
previous work in the context of ZKP authentication for mobile
devices [8].
Due to the lack of space we will present more detailed results
and our implementation in the full version of this paper.
D. Security and other limitations
The main limitation of our architecture is that both devices
must have external IP addresses for the exchange. This
requirement is, however, satisfied if they use the 3G
technology. Also, there is still a need for TTP, but it does not
provide data routing. Thus, in our architecture, TTP causes a
lower data overhead than in other existing solutions [9]. We
also note that our protocol does not require users to expose
their privacy to the third parties, even TTP. The users, in their
FOAF profiles publish data that they want to become public.
Only these profiles are displayed to the both parties during the
initial authentication stage. Due to FOAF, the users can see
each other’s names and pictures. Thus both of them have the
possibility of approving or rejecting the other party before they
exchange more social data begins. Only if both of them
approve the other party, their public keys and IPs are
exchanged by the matching service.
IV. CONCLUSIONS
In this paper we presented a novel method of sharing social
data between two mobile phones of different manufactures.
Our method provides interoperability in a similar way to other
state-of-the-art solutions [9]. However, it offers increased
privacy and security of the exchanged data. Although in the
proposed protocol we used a Third Trusted Party, we achieved
better scalability than other existing solutions.
REFERENCES
Figure 1. The matching protocol
[1]
[2]
The proposed protocol consists of five general steps (see
Figure 1):
[3]
 Step 1: Two users request the exchange of social data. Their
mobile devices send information that contains their
location, time, the current page that is displayed, and their
FOAF profiles to the TTP service
 Step 2: Initial authentication in which the users confirm that
they want to communicate and exchange data with each
other.
 Step 3: IPs and public keys exchange. Once the users
approve each other, their public keys and IP addresses are
exchanged
 Step 4: ZKP authentication, in which both devices mutually
authenticate using the ZKP authentication protocol
 Step 5: Social data exchange, during this phase the devices
starts the actual data exchange process. The presence of
the TTP is no longer necessary.
[4]
[5]
[6]
[7]
[8]
[9]
Dan Brickley and Libby Miller. FOAF Vocabulary Specification, 2005.
Sebastian Ryszard Kruk, Slawomir Grzonkowski, Adam Gzella, Tomasz
Woroniecki and Hee-Chul Choi. D-FOAF: Distributed Identity
Management with Access Rights Delegation.In Procedings of Asian
Semantic Web Conference 2006,September2006.
Tom N. Jagatic, Nathaniel A. Johnson, Markus Jakobsson and Filippo
Menczer. Social phishing. Commun. ACM, vol. 50, no. 10, pages 94100, 2007.
Shafi Goldwasser, Silvio Micali and Charles Rackoff. The knowledge
complexity of interactive proof-systems. In STOC'85: Proceedings of
the seventeenth annual ACM symposium on Theory of computing,
pages 291-304, New York, NY, USA, 1985. ACM Press.
Uriel Feige, Amos Fiat and Adi Shamir. Zero-Knowledge Proofs of
Identity. J. Cryptology, vol. 1, no. 2, pages 77-94, 1988.
L. C. Guillou and J.-J. Quisquater. A practical zero-knowledge protocol
fitted to security microprocessor minimizing both transmission and
memory. In Lecture Notes in Computer Science on Advances in
Cryptology-EUROCRYPT'88,pages123-128, New York, NY, USA,
1988. Springer-Verlag New York, Inc.
Claus-Peter Schnorr. Efficient Identification and Signatures for Smart
Cards. In CRYPTO, pages 239-252, 1989.
Slawomir Grzonkowski and Peter M. Corcoran. A Secure and Efficient
Micropayment Solution for Online Gaming. In Proceedings of the
International IEEE Consumer Electronics Society's Games Innovations
Conference 2009 (ICE-GIC 09), 2009.
Jason Kincaid. Bump's Data Exchange API Goes Cross-Platform,
Launches
For
Android
And
iPad.
http://techcrunch.com/2010/04/06/bumps-data-exchange-api-goes-
cross-platform-launches-for-android-and-ipad/, last viewed on 8th of
August 2010