A Distributed Privacy-Preserving Scheme for Location-Based Queries

1. A Distributed Privacy-Preserving Schemefor Location-Based Queries Emmanouil Magkos, Panayiotis Kotzanikolaou, Spyros Sioutas, Konstantinos Oikonomou Dept. of Informatics, Ionian Unicersity, Greece Dept. of Informatics, University of Piraeus, Greece

2. Presentation Overview • Introduction • Our contribution • System model • Security and Privacy requirements • Our Protocol: A Privacy-preserving scheme for Location Based Services • Registration Phase • Service Access Phase • Analysis • Conclusions – Future work

3. IntroductionLocation Based Services (LBS) • Location Based Service (LBS): Applications based on (accurate) location samples of mobile users • Inherent trade-off between access control and user privacy in LBS applications • Privacy concerns are amplified in applications requiring real-time, accurate and continuous location updating • e.g. traffic monitoring • asset tracking • location-based advertising • location-based payments • routing directions, …

4. Introduction LBS Privacy • Privacy in sporadic queries: Protect the privacy of mobile users in LBS against sporadic (not continuous) queries • e.g., asking for the nearest restaurant or finding a nearby friend • Path privacy or historical privacy: Protect the privacy of mobile users in continuous LBS, against correlation attacks • . e.g., report the nearest restaurant while I move

5. Introduction LBS Privacy: Our view • We deal with identity privacy • Location information is kept as accurate as possible, but the link to the real identity of a user is protected • Anonymization of location information is related to untraceability • destroy the link between a service provision and a user identity • Sometimes privacy can be enhanced by establishing unlinkability • destroy the link between successive user positions • Unlinkability is a key issue for historical privacy • We deal with LBS applications where users submit independent, highly accurate location samples

6. Our Contribution • We propose a distributed privacy-preserving scheme, suitable for both sporadic and continuous LBS queries • We establish both untraceability and unlikability against correlation attacks • For message untraceability: a message is distributed among mobile peers who act like mixes and re-encrypt a message before sending it to the LBS provider via the cellular operator • We use homomorphic probabilistic public-key encryption ( e.g., ElGamal and Paillier encryption schemes). • For historical privacy (unlinkability): we adopt multiple pseudonyms that are changed frequently • We also discuss how the privacy homomorphism could also allow to aggregate independent data from different mobile peers before sending them to the LBS provider. • Suitable in applications where aggregate location data could be useful (e.g., traffic monitoring and control)

7. System model • Mobile users with handheld devices • We assume a client-based positioning system (GPS) • We assume a hybrid network: • (a) a cellular operator between LBS providers and users • (b) ad-hoc networking between peers (WLAN or Bluetooth)

8. Threat model • We consider a global passive adversary that eavesdrops on all communications between all system entities (both peers and authorities) • Our threat model considers as possible adversaries the network operator, the LBS provider and the other peers • The adversary can obtain the records of any party that receives or observes communication, in order to construct a location history for a mobile user • We do not deal with tracing/linking at the physical or MAC layers

9. Security and Privacy requirementsSecurity requirements • Communication messages between system entities should be authenticated • Message and entity authentication are needed in order to: • authorize access to a service • provide personalized, context-aware services

10. Security and Privacy requirementsPrivacy requirements (1/3) • Privacy requirements depend on the nature of the messages that are being sent to the Location Provider (LP). • We distinguish three kinds of interactions between a user and the LP • 1) Sporadic queries. e.g., “Find me the closest restaurant” • Sporadic queries should be untraceable and unlinkable. • They also require an anonymous response by the LP • Only the requesting user should be able to read the answer

11. Security and Privacy requirementsPrivacy requirements (2/3) • 2) Continuous queries with frequent location updates. e.g., “find me the closest point-of-interest (POI) while I move”. • Continuous queries should also be untraceable • Concerning unlinkability: • different continuous queries should not be linkable by the LP (e.g., “return the closest restaurant while I move” should not be linked with “return the closest clinic while I move”). • On the other hand, multiple location updates concerning a specific query may have to be linkable in order to provide the service (e.g., respond with a point of interest that corresponds to the user’s trajectory).

12. Security and Privacy requirementsPrivacy requirements (3/3) • 3) Group context information. Manage aggregate data about a set of mobile users, e.g. in traffic monitoring systems • Atomic location data should not be linked or traced to any specific user identity.

13. Our protocolAssumptions • Each user employs a list of short-lived, uncorrelated credentials for each LBS provider she communicates with • We also assume that a digital signature scheme (e.g. ECDSA ) and symmetric encryption (e.g., AES) systems are in place • We assume a homomorphic probabilistic public key encryption system that and allows for re-encryption of messages (e.g., ElGamal or the Paillier encryption scheme)

14. Our protocolRegistration phase • The list of credentials is generated during the user registration phase. For a specific service SID, a user U generates a list of credentials of the form {C1,C2, …, Cn}, for up to n service transactions. • These credentials are validated by the LP using a blind signature sub-protocol, where U proves her identity to the LP, and gets a signature on a list of “blinded” credentials.

15. Our protocolService access phase • Each message can be either a location query (sporadic or continuous), or a group context message • We distinguish between the two cases

16. Our protocol • Protocol I – Location queries • U builds an encrypted (ElGamal) message that is then broadcasted • The encryption function satisfies the multiplicative homomorphic property • Protocol II – Group context messages • We use the Paillier encryption scheme, which provides a trapdoor to efficiently compute the discrete logarithm. • Group context messages are aggregated

17. Protocol Analysis • Both protocols I & II satisfy unlinkability and untraceability • Protocol I also achieves message and user authentication • During registration, the LP blindly signs the credentials Cj of the user • Since for each user transaction a different user credential is used, the protocol achieves unlinkability of the users against the LP and the OP

18. Protocol Analysis • Protocol I: • It also achieves message and user authentication • Protocol II: • The adding of a group context message effectively re-encrypts the previous input from the point of view of an observer • The privacy homomorphism allows for strong privacy without degrading the high accuracy and utility of the location data • Computational security of the public-key encryption functions: • The semantic security of ElGamal encryption is based on the Decision Diffie-Hellman (DDH) problem • Paillier encryption is semantically Secure based on the Decisional Composite Residuosity Assumption (DCRA)

19. Computational Costs • Registration phase • One public key encryption plus one blind signature from the user, per each validate credential, during the registration phase. • Service access phase • The requesting user will be required to compute one public key encryption and one MAC operation during the construction of the service request. • However, since the peers will re-encrypt the message with a probability z, then the total expected number of encryptions will be l∙ z, where l is the number of peers.

20. Conclusions – Future work • We described a scheme for privacy-preserving access control in LBS applications • For unlinkability and untraceability, users obtain a list of uncorrelated pseudonymous credentials during registration • For privacy against traffic analysis, a message is not sent directly to the cellular operator, but it is distributed among mobile peers who act like mixes and re-encrypt a message before sending it to the LBS • As an extension, we also discuss how to aggregate independent data from different mobile peers before sending them to the LBS provider • The potential of aggregated-based data collection in location-based environments is yet to be explored by future research

21. Thank you!!!

22. Auxiliary Slides

23. Our protocolProtocol I - Location queries (1/3) • U builds a message of the form: mj = skj, Mj, {Cj}SKSID where: • skjis a fresh symmetric key that will be transferred to the LP for encrypting the anonymous response, • Mj is the location query message, and • Cj is the validated credential that is used as a temporary pseudonym for the specific transaction. • The message that is broadcasted is:

24. Our protocolProtocol I - Location queries (2/3) • For message secrecy, U encrypts and the corresponding MAC value with the public key of the LBS service, PKSID. • We consider the ElGamal encryption scheme.

25. Our protocolProtocol I - Location queries (3/3) • The encryption function satisfies the multiplicative homomorphic property • E(m; r) denotes probabilistic encryption of message m using the random number r. As a result, for re-encrypting E(m; r) it suffices to multiply with E(1; r’) • The encrypted query message of Eq. 3 is then distributed among the neighboring peers using random forwarding, who act like MIXes and re-encrypt the message before submitting it to the LP • If cid = 1 a receiving peer checks the identifier mid and if it is the first time it sees this message it will re-encrypt it and then forward it to the next peer (with probability z) or will send it directly to the LP (with probability 1-z).

26. Our protocolProtocol II – Group context messages • We use the Paillier encryption scheme, which provides a trapdoor to efficiently compute the discrete logarithm. • Group context messages are aggregated in • the following way. As an example, a node U1 encrypts a group context message m1 with the Paillier scheme, then appends cid = 1 and mid. The message is then distributed among the neighbor mobile peers