Livrable AMORES - LAASprojects.laas.fr/AMORES/doc/AMORES-L0.1.pdfLabels et correspondants des p les...

ARCHITECTURE FOR MOBIQUITOUS RESILIENT SYSTEMSamores

Livrable AMORES

AMORES L0.1 - Compte-rendu intermediaireT0+6

Date : 4 mai 2012Auteurs : Marc-Olivier Killijian

Titre : AMORES L0.1 - Compte-rendu intermediaire T0+6

Rapport No. / Version : 0.1/ v1.0

Statut : Final

LAAS-CNRS7 avenue du Colonel Roche

31077 Toulouse cedex 4, Francehttp://www.laas.fr/

Supelec - RennesAvenue de la Boulaie, BP 81127,35511 Cesson-Sevignee, Francehttp://www.supelec.fr/

IRISACNRS, INRIA, Universite de Rennes 1,263, Avenue du General Leclerc, Bat12

35042 Rennes Cedex, Francehttp://www.irisa.fr/

MobiGISRue de l’Autan

31330 Grenade, Francehttp://www.mobigis.fr/

Tisseo7, esplanade Compans-Caffarelli

31902 Toulouse CEDEX 9http://www.tisseo.fr/

Resume : Ce document est un rapport administratif concernant ledemarrage du projet a T0+6.

Redacteurs :

Contributeur Organisme RoleMarc-OlivierKillijian

TSF LAAS Responsable de fourniture

SebastienGambs

U. Rennes 1 Contributeur

NicolasPrigent

- Supelec Contributeur

FredericSchettini

- MobiGIS Contributeur

Compte-rendu intermédiaire T0+6

Référence du formulaire : ANR-FORM-090601-03-02

Projet ANR- 11-INSE-010

AMORES Programme INS 2011

A IDENTIFICATION ............................................................... 1 B DEMARRAGE DU PROJET ...................................................... 2

B.1 Moyens mis en place ............................................................. 2 B.2 Difficultés rencontrées ou attendues ........................................ 3 B.3 Commentaires libres ............................................................. 4

C ANNEXES EVENTUELLES ...................................................... 4 Ce document est à remplir par le coordinateur en collaboration avec les partenaires du projet. Il doit être transmis par le coordinateur 6 mois après la date de démarrage du projet indiquée dans les actes attributifs : 1. à l’ANR 2. aux pôles de compétitivité ayant accordé leur label au projet. Il doit être accompagné d’un résumé public du projet mis à jour, conformément au modèle associé à ce document. L’ensemble des partenaires doit avoir une copie de la version transmise à l’ANR. Ce modèle doit être utilisé uniquement pour le compte-‐‑rendu du démarrage du projet, transmis à T0+6.

A IDENTIFICATION Acronyme du projet AMORES Titre du projet Architecture for MObiquitous REsilient

Systems Coordinateur du projet (société/organisme)

Marc-Olivier Killijian – LAAS-CNRS

Date de début du projet Date de fin du projet (conventions)

01/10/2011 31/03/2015

Labels et correspondants des pôles de compétitivité (pôle, nom et courriel du corresp.)

Aerospace Valley , Stéphanie Almarcha, [email protected]. Pole Images & Réseaux, Jean-Yves Savary [email protected]

Site web du projet, le cas échéant www.amores-project.org Rédacteur de ce rapport Civilité, prénom, nom Mr Marc-Olivier Killijian Téléphone 05-61-33-62-41 Courriel [email protected] Date de rédaction 11/04/2012

Référence du formulaire : ANR-FORM-090601-03-02 2/4

B DEMARRAGE DU PROJET Si le projet a tenu une réunion de démarrage, cette partie peut être remplacée par le compte-‐‑rendu de cette réunion, en le complétant éventuellement de façon à ce qu’il contienne les informations demandées ci-‐‑dessous.

B.1 MOYENS MIS EN PLACE

Indiquer en une page maximum les moyens humains, organisationnels et matériels mis en place pour assurer le fonctionnement du projet.

Ressources Humaines : LAAS-‐‑CNRS

• Permanents : Christian Artigues, Yves Deswarte, Jérémie Guiochet, Marie-‐‑José Huguet, Marc-‐‑Olivier Killijian, David Powell, Matthieu Roy, Gilles Trédan

• Doctorants : Moussa Traore (bourse MESR), Ngoc Tran (financement AMORES) • Stagiaires : Jordy Barrier (M1), Assia Kamal Idrissi (M2), Lucian Petcana (M1)

MobiGIS • Permanents : Cyrille Boitel, Sylvain Gaudan, Frédéric Schettini • Stagiaire : Julie Jannequin (M2)

Supélec • Permanents : Christophe Bidan, Nicolas Prigent • Stagiaire : Simon Boche (M2)

Université de Rennes 1 • Permanents : Emmanuelle Anceaume, Sébastien Gambs, Gilles Guette, Michel Hurfin • Stagiaires : Paul Lajoie-‐‑Mazenc (M2)

Moyens Organisationnels • Mise en place de réunions de travail régulières dans chacun des sites (Grenade, Rennes,

Toulouse). • Audio/Visio-‐‑conférences régulières entre les différents partenaires (moyens fournis par

l’IN2P3).

Autre

• Site web du projet : nom de domaine déposé (amores-‐‑project.org), version préliminaire du site en place, une version plus léchée et plus complète est en cours de mise en place.

• Un accord de consortium est en cours de discussion.


Réunions du consortium (projets collaboratifs) Indiquer les dates lieux, thèmes abordés, partenaires et correspondants de l’ANR éventuellement présents.

Date Lieu Partenaires présents Thème de la réunion 16-17/11/2011 LAAS LAAS, U.Rennes1, Supélec Kickoff 8/02/2012 LAAS +

Visio LAAS, U.Rennes1, Supélec, MobiGIS

Tâche 1.1, spécification des use-cases

16/03/2012 LAAS + Visio

LAAS, U.Rennes1, Supélec, MobiGIS


26/04/2012 LAAS + Visio

LAAS, U.Rennes1, Supélec, MobiGIS


Autres moyens nécessaires au projet (le cas échéant) Indiquer le résultat des demandes d’autorisations administratives ou de moyens techniques ou expérimentaux éventuellement nécessaires au projet. Autorisation du fonctionnaire défense pour le recrutement d’un doctorant à Supélec refusé. Implications sur la faisabilité du recrutement, cf. B3.

B.2 POLES DE COMPETITIVITE (PROJET LABELLISES)

Pour les projets labellisés par un ou plusieurs pôles de compétitivité, Quelles collaborations avez-‐‑vous mis en place entre votre projet et le(s) pôle(s) de compétitivité l’ayant labellisé ? RAS

B.3 DIFFICULTES RENCONTREES OU ATTENDUES

Éventuellement, indiquer les difficultés rencontrées ou attendues (recrutement, disponibilité de moyens techniques ou d’équipements, disponibilité de l’aide ANR, etc. ).

1. Les aller-‐‑retours de l’ANR sur la participation ou non du partenaire MobiGIS ont été sources de perte de temps et d’énergie en début de projet. Ces difficultés sont maintenant levées mais le travail concret a subi du retard de ce fait.

2. Un thésard (co-‐‑supervisé entre l'ʹuniversité de Rennes 1 et Supélec) avait été identifié et le processus de recrutement avait été initialisé comme précisé dans la proposition du projet avec arrivée prévue pour début février. Cependant, le haut fonctionnaire sécurité défense a rejeté sa candidature ce qui à mis fin à son recrutement. Nous souhaitons donc à la place recruter un des étudiants de master qui fait actuellement son stage avec nous à Supélec ou l'ʹuniversité de Rennes 1. Le recrutement de cette thèse devrait avoir lieu pour début octobre 2012 au plus tard. Il semble que cela pose problème car le contrat irait au delà de la durée officielle du projet. Nous souhaiterions dores et déjà étendre cette dernière afin de lever ce problème administratif.


B.4 COMMENTAIRES LIBRES Commentaire du coordinateur Commentaire général à l’appréciation du coordinateur, sur l’état d’avancement du projet, les interactions entre les différents partenaires… RAS Commentaire des autres partenaires Éventuellement, commentaires libres des autres partenaires RAS Question(s) posée(s) à l’ANR Éventuellement, question(s) posée(s) à l’ANR… En conséquence des difficultés évoquées en B3, est-‐‑il possible d’étendre la durée du projet ?

C ANNEXES EVENTUELLES Le projet AMORES a donné lieu à 3 publications dont voici les références bibliographiques et qui sont jointes en annexes.

1. S. Gambs, M.-‐‑O. Killijian, M. Roy, M. Traore. Locanyms: Towards Privacy-‐‑Preserving Location-‐‑Based Services. EDCC'ʹ ARMOR 2012, 6 pages.

2. C. Artigues, Y. Deswarte, J. Guiochet, M.-‐‑J. Huguet, M.-‐‑O. Killijian, D. Powell, M. Roy, C. Bidan, N. Prigent, E. Anceaume, S. Gambs, G. Guette, M. Hurfin, F. Schettini. AMORES: an Architecture for MObiquitous REsilient Systems. EDCC'ʹ ARMOR 2012, 6 pages.

3. F. Schettini. S. Gaudain, F. Decavele, M.-‐‑O. Killijian, M. Roy, AMORES: an Architecture for MObiquitous REsilient Systems, Toulouse Space Show, juin 2012, 1 page.

Locanyms:Towards Privacy-Preserving Location-Based Services ∗

Sebastien GambsUniv. de Rennes 1 - INRIA

IRISA

Marc-Olivier KillijianUniversité de Toulouse

LAAS-CNRS

Matthieu RoyUniversité de Toulouse

LAAS-CNRS

Moussa Traore†

Université de ToulouseLAAS-CNRS

ABSTRACTRecent advances in geolocated capacities, secure and veri-fied positioning techniques, ubiquitous connectivity, as wellas mobile and embedded systems, have led to the develop-ment of a plethora of Location-Based Services (LBS), per-sonalizing the services they deliver according to the locationof the user querying the service. However, the widespreaduse of mobile equipments, with ever increasing availability,precision, performance and connectivity have introduced thecreepy feeling of being continuously monitored, in particularby the providers of the LBS. Thus, beyond the benefits theyprovide, users have started to be worried about the privacybreaches caused by such systems. The main objective ofthis paper is to discuss the privacy issues raised by LBS andthe challenges of implementing privacy-preserving location-aware systems. Moreover, we also give a brief overview ofpositioning techniques used by LBS and we introduce thenovel concept of locanym, which corresponds to a pseudonymlinked to a particular location that could be used as a basisfor developing privacy-preserving LBS.

KeywordsPrivacy, Location-based services, Ubiquitous computing.

1. INTRODUCTIONDue to the rapid advances in positioning technologies

such as Global Positioning System (GPS), Global System forMobile Communication (GSM), Radio Frequency IDentifi-cation (RFID), and WiFi (802.11b/g/n) and the widespread∗This work is partially supported by LAAS, CNRS and ANRFrench national program for Security and Informatics (grant#ANR-11-INSE-010, project AMORES[1]).†Corresponding author, email: [email protected]

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ARMOR ’12 May 08 - 11 2012, Sibiu, RomaniaCopyright 2012 ACM 978-1-4503-1150-2/12/05 ...$10.00.

deployment of wireless local area networks, mobiles devicesare often equipped with geolocated and wireless communi-cation capacities. These recent development of ubiquitousdevices have lead to the development of a new class of ser-vices known as Location-Based Services (LBS), that are tai-lored to the current location of the individual querying theservice. LBS can access, combine, and transform contextualinformation, and more specifically location information, inorder to personalize the service provided to the user. For in-stance, a LBS can be used for resource discovery (e.g., find-ing the closest restroom from my position1), path-finding(e.g., computing the shortest route to a gas station), real-time social applications (e.g., informing me about the pres-ence of my friends in the vicinity2) or location-based gaming(e.g., playing with the nearest challenger).

When people use LBS to support them in their dailytasks, their position is usually acquire automatically throughmobile equipments they carry with them. Thus, these sys-tems continuously monitor and reveal information about thelocation of their users as the position of these mobile sys-tems is essentially the same as the users of such system (e.g.,which could be a single individual or a small group of personssuch as a family). In most of the cases, the collected locationdata is transmitted to another system (typically a central-ized server or another mobile equipment), which needs thisinformation to provide the LBS (e.g., to generate the listof nearby restaurants3) or to participate to its computation(e.g., to help two people to meet at the optimal rendezvouspoint4). However, the collection and transmission of suchdata can also be used against the privacy of a user, either atthe time of transmission (e.g., to send unwanted advertise-ment), or later in the future (e.g., to detect that the user hasviolated the speed limit while driving his car [8]). Moreover,inference attacks [9] can be used to extract personal infor-mation from the observed mobility travels of an individualsuch as the Points Of Interests (POIs) characterizing his mo-bility (e.g., home, place of work or even the hospital that heoften visits), to build mobility models that can predict withan high accuracy his past, current and future locations, aswell as to deduce a part of his social graph by inferring that1www.have2p.com2www.loopt.com3www.have2eat.com4www.rendevousSpot.com

he has a social relationship with the individuals with whomhe shares often the same physical location.

In order to address and mitigate these privacy issues, re-cently there has been a huge interest in the design of privacy-preserving versions of LBSs providing high quality of servicewhile preserving the privacy of their users. In this paper, weelaborate on how privacy can be integrated in location-awaresystems through a few examples highlighting the complexityof addressing such issues. We also argue that privacy needsto be taken into account in LBS by grounding in fundamen-tal privacy principles capturing the privacy needs of users ofsuch systems. Additionally, we believe that addressing pri-vacy in LBS should embed privacy protection and controlmechanisms as fundamental requirements on all the levelsof the system. The outline of this paper is the following.First in Section 2, we review the concepts of location-basedservices and secure positioning. Afterwards, in Section 3, weconduct a privacy analysis of some existing LBS. Finally, inSection 4 we define some desirable properties that any LBSshould fulfill to protect the privacy of their users. We alsointroduce the notion of locanyms, which captures most ofthese privacy requirements, before concluding through anillustration on how these properties apply to a specific LBS.

2. LOCATION-BASED SERVICES AND SE-CURE POSITIONING

A LBS can be defined as a service that takes as inputthe current location of a user (generally acquired througha mobile device carried by this user) and tailors its outputdepending on the acquired location data. For instance, auser visiting a shopping mall may call a LBS to locate theclosest shop that matches his budget and its clothing pref-erences. Therefore, location data are usually augmentedwith complementary information related to the user, thusfurther increasing the privacy risks. The ability to providethe user with a customized service depending on his locationcould also be used by companies to send targeted advertisingand for billing purposes, by banks to perform authenticationbased on the location, and by restaurant owners to proposediscount to users passing nearby. The above list is far frombeing exhaustive, as one could think about position-basedaccess control in which the access to a particular resource isgranted only to persons that are physically located inside apredefined perimeter. For instance, a printer or fax machinecould be accessible only to persons located within a set ofoffices, or a pizza delivery service might first verify if theperson placing the order is indeed located at the specifieddelivery address.

One of the first question that naturally arises when deal-ing with LBS is how a particular user can convince othersabout the validity of its current position. More precisely, theuser can be viewed as a prover, who claims to be currentlyat a particular location, and which wants to convince a setof remote verifiers that he is indeed at the claimed position.Thereafter, we will refer to this problem as Secure Position-ing or sometimes as Secure Position Verification. SecurePositioning is a fundamental problem that has to be tack-led when designing a secure LBS and that can be addressedby designing a technique enabling the prover (i.e., the user)to prove its position through interactions with a group ofverifiers. In the following, we review the two main familiesof approaches that have been proposed to tackle this prob-

lem (i.e., distance-bounding protocols and received signalstrength), and we briefly discuss their pros and cons.

2.1 Distance-bounding ProtocolThe approach based onDistance-Bounding Protocol (DBP)

[3] (sometimes also called Time-of-Flight (TOF), Round-Trip Time (RTT) or Round Time-of-Flight (RToF)) aimsat measuring the relative proximity of two devices usingphysical limits on information propagation speeds. A DBPprotocol involves generally two participants, a prover and averifier, and enables the verifier to place an upper bound onthe physical distance separating him from the prover with-out requiring the assistance of a third party. The generalschema of a DBP is the following: first, the verifier sendsa challenge to the prover and starts his own timer. Uponreception of the challenge, the prover performs some com-putation (in some scheme, the computation simply consistsin sending back the message [17]) in order to construct theresponse to the received challenge and then sends it to theverifier, which stops his timer upon reception of the answer.By multiplying the elapsed time with the propagation speedof the signal (e.g., ultrasound or electromagnetic signals),the verifier can deduce an upper bound on his distance tothe prover. Moreover, in addition to the DBP, it is possibleto add a layer of authentication by having the prover au-thenticate himself to the verifier by using some secret sharedbetween the prover and the verifier, thus proving that theentity responding to the challenge is indeed the prover thathas initiated the DBP.

The security of DBP is based on the assumption thatit should be impossible for the prover to send the responsebefore receiving the challenge [3]. In addition, it is assumedthat the processing time needed to compute the responseupon reception of the challenge should be negligible com-pared to the propagation time of the message in order toestimate an accurate upper bound on the location of theprover. This requirement can be easily met for DBP basedon ultrasounds in which the processing time of the proverneeds to be in the order of microseconds to attain reasonableprecision [16]. However, in this context some security prob-lems arise since (ultra-)sounds are not resistant to activeattackers that can physically alter the signals. For instance,such an attacker can modify the medium (e.g., sound travelsfaster through metal than through the air) or use Radio Fre-quency (RF) wormholes (e.g., by retransmitting the signalusing electromagnetic waves) to claim that it is closer fromthe verifier than he really is. Current knowledge of physicsensures that nothing can travel faster than light, and henceRF-based DBP (whose travel speed is very close to that oflight) seems more robust, at least in the sense that they for-bid such wormhole attacks. In this situation, the only threatleft is that the attacker can claim to be further away than hereally is by delaying his response. This does not contradictthe main objective of the DBP that is to derive an upper(and not a lower) bound on the distance from the prover tothe verifier. However, with RF-based DBP, the prover’s pro-cessing time needs to be in the order of nanoseconds, whichin the worst case allows a malicious prover to pretend becloser to the verifier by approximatively 15 centimeters (as-suming that the malicious prover is able to process signalsinstantaneously).

Brands and Chaum [3] were the first to introduce theconcept of DBP that can be used to verify the proximity of

a device in a cryptographic manner. This seminal work haslead to the design of a following DBP from Hancke and Kuhnmore appropriate for RFID tags and dealing with noisy en-vironments [11], and a plethora of other protocols [2, 18,20, 21]. Despite their accuracy and well-founded securitymodels, most DBP suffer from location privacy leakage [15].More precisely, they always leak some information about thelocation and distance of the different communicating part-ners even to passive attackers that only eavesdroppes thecommunications.

2.2 Received Signal Strength IndicatorAn approach used by several Wifi-based localization sys-

tem is to measure the Received Signal Strength Indicator(RSSI) of the radio signals used. The RSSI approach isbased on two observations: RF signal strength decreases 1)when the transmitter and the receiver are further apart and2) when there are obstacles between the transmitter and thereceiver. Based on these two observations, different read-ings of the signal strength are measured on different pointsof the location site and then recorded in a database. Whenthe system receives a location query from a user, the systemcompares the user’s current signal strength values with thevalues stored in the database. Based on this comparison,the system is able to deduce the most probable location ofthe user and returns it. In [14], the authors have proposeda RF-based indoor location tracking system that processesthe signal strength information at multiple base stations.Another localization system, WHAM! (Where AM I!) [12],continuously records signal strengths received by a user’sdevice, and disambiguates the current location of the userby backtracking to the user’s previous locations in the floormodel, eliminating candidate locations that are not likelyto be reachable from its previous known locations. In [10],the authors describe a practical robust Bayesian method fortopological localization that reduces the time required totrain the localizer while keeping the localization accuracygood enough so that it can be used by an LBS. Many otherRSSI schemes exist in the literature and we refer the readerto the following survey for more details [13].

Most RSSI schemes implicitly assume that the proveruses a standard and unmodified wireless card. However, itis not very difficult for an attacker to build a directionalantenna that can largely increase the sending or receiv-ing range, and therefore in this case measuring the signalstrength does not lead to a good level of security. In ad-dition, by jamming and replaying localization signals, anattacker can convince a device to be in a location differentfrom its actual physical position [19]. As a countermeasure,it was proposed to design a system based on collaborativelocalization in order to enhance the accuracy of the positionestimation by leveraging and combining on the informationgathered by neighboring nodes [4]. However, anonymizationis a challenging task for the design of Wifi-based localizationsystems. Indeed, users are primarily authenticated throughtheir MAC address in order to avoid undesirable deliveries ofmessages to unappropriate nodes. Instead of using the trueMAC address, some systems [7] frequently and randomlychange the MAC address of the node (which can be seen aspseudonym) to reduce the linkability risks.

3. PRIVACY ANALYSIS OF EXISTINGLOCATION-BASED SERVICES

Currently, there is no universal metric to quantify loca-tion privacy that reached a consensus in the privacy com-munity. Hence, it is sometimes difficult to compare differentapproaches aiming at building privacy-preserving LBS. Gen-erally, each approach adopts its own definition of locationprivacy and defines its own adversary model. Figure 1 pro-vides an overview of several protocols and compares themaccording to different criteria. In this section, we brieflyreview their main features and how they address privacy.Thereafter, we assume that the main objective of the at-tacker is to track the location of a mobile node and thisattacker is equipped with eavesdropping capacities.

A Duress Alarm Location System (DALS) [5] was pro-posed in the early nineties for the sole purpose of deter-mining users location, and therefore does not provide anydata networking services or privacy protection. DALS usesRF-signal strengths to determine the location of a user sim-ilarly to RSSI localization techniques. Furthermore, DALSmakes use of specialized and costly hardware, and thereforethe trade-off between the deployment cost and the perceivedvalue of this system is not compelling enough for large-scaleadoption. RADAR [14] was designed to overcome the limi-tations of DALS and can be deployed off-the-shelf over anywireless LAN technology. More precisely, RADAR used aRSSI localization technique and relies on a Viterbi-like al-gorithm for continuous tracking of users’ location and dis-ambiguation of candidate user locations with a precision ofa few meters (2 − 3 meters). With respect to privacy, con-tinuous user tracking is a major threat as users may feelthat “Big Brothers is continuously watching them”. Further-more, the communications exchanged can be eavesdroppedas their content is not encrypted by default for these proto-cols. Another system, called WHAM! [12], works similarlyto RADAR, with the exception of the backtracking tech-nique used, which improves the accuracy of the localizationresults but causes the same security and privacy problems asprevious protocols. SkyHook [19] differs from the previouslydescribed systems in the sense that the messages exchangedare encrypted. Therefore, location information can normallyonly be accessed by authorized entities. However, even if theuser knows which entity should in principle be responsiblefor keeping his data private, he has no guarantee other thanthe promises of this entity that his location data will notbe disclosed to other entities (e.g., for instance to a market-ing company for a profiling purpose or to nearby shops fortargeted advertising).

Recently, a distributed cooperative scheme for NeighborPosition Verification (NPV) [7] was proposed. It enables anode playing the role of the verifier to discover and ascer-tain the position of nearby nodes. The verifier can initiatethe protocol at any time, by triggering interactive proto-col within his 1-hop neighborhood that consists in 4 roundsof communication. The main objective of this protocol isto let the verifier collect enough information so that he cancompute by himself the distances between any pair of neigh-boring nodes. In this protocol, the messages exchanged aremade anonymous by taking advantage of the broadcast na-ture of the wireless medium, thus enabling nodes to recordreciprocal timing information without disclosing their iden-tities. Afterwards, following a revelation message broad-

DALS 5 RADAR 15 WHAM ! 13 Swiss-Knife 12 Skyhook’s 20 APPLAUS 23 Fiore and al 7

Un-linkability ! ! ! ! ! " "Arc

hitec

ture

Anchor based " " " ! " ! !Cooperative (User side) ! ! ! ! ! " "Centralized " " " " " " !

Tec

hniq

ues

Time of Flight ! ! ! " ! ! "RSSI " " " ! " ! !GPS ! ! ! ! " " !PKI ! ! ! " " " "Location proofs ! ! ! ! ! " !Mutual Authentication ! ! ! ! ! ! "Privacy-aware Low Low Low Medium Low High HighPrecision (cm) 300-600 200-300 # # 100 # #

1. Chong Hee Kim, Gildas Avoine, François Koeune, François-Xavier Standaert et Olivier Pereira, « The Swiss-Knife RFID Distance Bounding Protocol ». Dans Information Security and Cryptology (ICISC)

2008, 2008, p. 98-115 (ISBN 978-3-642-00729-3).

2. Marco Fiore, Claudio Casetti, Carla-Fabiana Chiasserini, Panagiotis Papadimitratos, "Discovery and Verification of Neighbor Positions in Mobile Ad Hoc Networks". In IEEE

Transactions on Mobile Computing, 08 Dec. 2011. IEEE computer Society Digital Library. IEEE Computer Society.

3. Paramvir Bahl and Venkata N. Padmanabhan, « RADAR : An in-building rf-based user location and tracking system ». In IEEE Infocom 2000, Tel-Aviv, Israël, Volume 2, March 2000.

4. Dik Lun Lee, Qiuxia Chen, « A model-based WiFi localization method». In “Proceedings of the 2nd international conference on Scalable information systems (InfoScale '07)”, ICST

(Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), Brussels, Belgium, 2007, Article 40 , 7 pages.

5. Thomas W. C H R I S T, Philip A. Godwin, Robert E. Lavigne, « A prison guard duress alarm location system ». In IEEE International Carnahan on Securiry Technoloby, pages 106–116, October 1993, (ISBN 0-7803-

1479-4).6. Nils Ole Tippenhauer!"#$%&'(" )*++'",$%-.%%'+!"/0(1%21+$" 34&&'(!" $+5"6(57$+"8$&9.+:" ;<<=:"« Attacks on public WLAN-based positioning systems». In Proceedings of the 7th

international conference on Mobile systems, applications, and services (MobiSys '09). ACM, New York, NY, USA, 29-40. DOI=10.1145/1555816.1555820.

7. Zhichao Zhu, Guohong Cao, "Towards Privacy-Preserving and Colluding-Resistance in Location Proof Updating System," IEEE Transactions on Mobile Computing, 03 Nov.

2011. IEEE computer Society Digital Library. IEEE Computer Society, <http://doi.ieeecomputersociety.org/10.1109/TMC.2011.237>

Figure 1: Comparison of different localization protocols

casted by the verifier, nodes disclose their identities onlyto him through secure and authenticated messages, whichalso contain the anonymous timing information they havecollected. Finally, the verifier uses this data to match thedifferent timings and identities and then performs a ToF-based ranging to compute the distances between all pairs ofcommunicating nodes in its neighborhood. From the pointof view of privacy, this protocol ensures the anonymity ofcommunication by relying on a generator of MAC addressduring the discovery phase in order to obfuscate the identityof the prover. However, this protocol assumes that the ver-ifier is trusted (i.e., honest). Indeed, the verifier is grantedthe privilege to decide which entities are really in his proxim-ity without requiring the help of an external trusted entityto verify the correctness of this proximity map.

In general, a system that can be used to generate a certi-fied proof of the location of a node is called a location proofsystem. Zhu and Goa have proposed a privacy-preservinglocation proof system called APPLAUS [22], which is com-posed of the following elements:

1. A prover is a node collecting location proofs by broad-casting when needed a location proof request to itsneighboring nodes through Bluetooth communications.

2. A witness is a node that accepts to generate a locationproof upon request and sends it back to the prover.

3. A location proof server is required for storing the his-tory of location proofs. It communicates directly withthe provers when they submit their location proofs.

4. A certification authority (CA) is run by an indepen-dent trusted third party. Upon joining the locationproof system, each mobile node registers with the CAand pre-loads a set of public/private key pairs beforeentering the network. The CA is the only entity thatknows the correspondence between the real identity ofa node and the pseudonyms (public keys) used by thisnode.

5. A verifier is another node or an application that is au-thorized to verify a prover’s location within a specificperiod of time.

When a prover needs to generate a location proof at particu-lar time, it broadcasts a location proof request to its neigh-boring nodes through Bluetooth communications. Once aneighboring node agrees to provide a location proof for theprover, this node (now acting as a witness) generates a lo-cation proof and sends it back to the prover. The proveris responsible for forwarding this location proof to the loca-tion proof server. Finally, an authorized verifier can senda query that contains the real identity of the prover and atime interval. The CA first authenticates the verifier, andthen converts the real identity contained in the query to itscorresponding pseudonyms during that time period and re-trieves their location proofs for this particular time periodfrom the server. Changing pseudonyms on a regular basisprovides two benefits. First, it protects the location privacyof each node by enhancing their unlinkability. Second, if thelocation proof server is compromised or monitored, it will beimpossible for the attacker to identify the real source of thelocation proof. More precisely, the privacy of APPLAUS isensured by the separation of trust: (1) the location proofserver knows only pseudonyms and their associated loca-tions, (2) the CA knows only the mapping between the realidentity and its pseudonyms, and finally (3) the verifier onlysees the authorized locations visited by a node for which heknows the real identity. The separation of trust ensures thatas long as the attacker does not control more than one of theentity involved in the location proof system, it is impossiblefor him to learn a user’s location because he does not haveaccess to enough knowledge.

4. TOWARDS PRIVACY-PRESERVINGLOCATION-BASED SERVICES

Location privacy can be broadly defined as the abilityto prevent an unauthorized entity from learning the past,current or future locations of an individual. Based on thisdefinition, most of LBS mentioned previously do not ensurelocation privacy. In order to reach this goal, we describethereafter the desirable properties that we believe that aprivacy-preserving LBS should fulfill:

1. Unlinkability and unforgeability. It should notbe possible to trace and link different locations visitedby a user. For instance, even if the user proves hislocations at different occasions, it should be impossibleto link the different location proofs being made by thesame user. Similarly, a user should not be able to foolthe system by forging a fake location proof.

2. Accountability and non-repudiation. The loca-tion information collected by the mobile device of auser should serve as a basis for deriving location proofsthat are verifiable in order to ensure the validity of theuser’s position over an elapsed time.

3. Sovereignty. The LBS should empower the user withthe control on how his location information is usedand disseminated in the system. More precisely, usersshould be able to decide who can access their locationinformation and under which restrictions.

Additionally, we think that it is important to use a dis-tributed architecture, rather than a centralized server, inorder to implement the LBS. Most of the systems describedpreviously make use of the past location of user to increasethe accuracy when predicting the current location or contin-uously monitor their positions. Such information is usuallycentralized by the LBS on a remote database server. How-ever, if the security of this server is damaged, the privacybreach that can occur can be very important. Moreover,the computation of the positions by a central entity raisesthe possibility of continuously tracking users, which couldalso lead to a detailed profiling of the user. Therefore, toaddress this privacy concern, we recommend to build LBSby relying on a distributed architecture. In such an archi-tecture, it is more difficult for an attacker to find the infor-mation about the location of a particular user since he doesnot have a single point of failure to attack to retrieve thisinformation, which is scattered around the network. More-over, a distributed architecture also preserves the privacy ofusers from being exposed to large companies, thus avoidingthe “Big brother is watching you” syndrome. Finally, wealso think that a privacy-preserving LBS should involve thedevices present within the current neighborhood of a userto verify his position (collaborative behavior), in order to in-crease the resilience of the system against an active attacker.To encapsulate all these properties, we introduce the con-cept of locanym, which summarize the fundamental privacyrequirements required to build a privacy-preserving LBS.

Definition 1 (Locanym) A locanym is a geolocated ver-sion of a pseudonym tied to a particular geographical area.More precisely, it aims at deriving, from an accurate andverified positioning, a specific form of pseudonym provid-ing the following properties: unlinkability, unforgeability, ac-countability, non-repudiation and sovereignty.

In order to illustrate the importance of the privacy desider-ata defined previously for the design of LBS, we will considera dynamic carpooling scenario based on locanyms. Dynamiccarpooling is an urban service in which drivers are dynami-cally match with passengers from sub-urban to urban jour-neys or intra-urban journeys. Privacy is of paramount im-portance in such a setting as users move between places buttheir mobility patterns should be kept private from other

entities (even from other mobile users that they periodicallymeet and cooperate with) as they generally do not knowthem and therefore cannot blindly trust them with their lo-cation data. Consider for instance the scenario in which Bobwishes to drive to a shop situated in the town’s outskirts.Before starting his journey, Bob decides to switch on thecarpooling application to gain some experiences points (andpossibly some money). Approximately at the same period,Alice wants to go to a shopping mall located somewhere onBob’s path.

Unlinkability and unforgeability. After starting her car-pool engine by activating the passenger mode, Alice coop-erates with the neighboring nodes (e.g, bus or other movingnodes) to create her locanym data. By drawing on this lo-canym, the carpooling application will be able to connectBob to Alice without disclosing her real identity since thelocanym is derived only from her location data. In partic-ular, the request of Alice cannot be linked to her identitybefore she meets physically with Bob (and vice-versa), whichensures the anonymity of the users of the carpooling system.Another issue is for Bob is to be sure of the truthfulness ofthe location claimed by his potential carpoolmate. Indeed,as the position of Alice is certified by her neighbors, shecannot fool the system by forging a false location proof ex-cept if a majority of her neighbors are colluding with her,which should be sufficiently difficult to achieve in a realis-tic mobile environment in order to ensure the security ofthe application. Therefore, Bob can trust the carpooling re-quest and decided whether or not to carpool with Alice. Inthis situation, locanyms seem sufficient to ensure the mutualauthentication between Alice and Bob when they establishtheir first relationship in a privacy-preserving manner.

Accountability and non-repudiation. Once the relation-ship is established and the two participants physically meet,the anonymity can be lifted and their identities revealed.Moreover suppose that during the carpooling trip, some-thing bad happens to Alice because of Bob. During a policeinvestigation if Bob denies having carpooled with her, Alicecan nonetheless prove that she was with Bob during a cer-tain period. Indeed, the location proofs collected by Alicemobile device can be used as an evidence. The account-ability property can be important to prove to a third party(such as the administration of the city) that another entity(e.g., Bob) has actually participated in a carpooling activ-ity. Moreover, the non-repudiation property, which can beobtained through a combination of locanyms and digital sig-natures, will also ensure that an entity cannot deny havingparticipated to a carpooling trip to which he has previouslygiven his explicit consent. The combination of accountabil-ity and non-repudiation can also be used by the carpoolingservice provider to offer some discounts to their regular users(e.g., such as a discount on their transport subscription).

Sovereignty. Continuing on the carpooling scenario, sup-pose that Alice does not want to carpool with Bob becauseon some problems during previous trips. However, as lo-canymity hides the identity of Bob, if such a concern is notmanaged by the carpool system, Alice may have a bad sur-prise when she arrives at the meeting place. Ideally it shouldbe possible for Alice to express in her carpooling request (forinstance in the form of a blacklist) that she does not wantto carpool with Bob. This property is a form a sovereigntyin the sense that Alice can decide with whom she wants (ornot) to share her location. Therefore, locanyms must take

into account privacy policies defined on location data by aparticular node. These privacy policies should be customiz-able by the user depending of the privacy level needed inthe spirit of Platform for Privacy Preferences (P3P) [6].

5. REFERENCES[1] E. Anceaume, C. Artigues, C. Bidan, Y. Deswarte,

S. Gambs, G. Guette, J. Guiochet, M.-J. Huguet,M. Hurfin, M.-O. Killijian, D. Powell, N. Prigent,M. Roy, and F. Schettini. AMORES: an Architecturefor MObiquitous REsilient Systems. TR 12031,LAAS-CNRS, 2012.

[2] G. Avoine and A. Tchamkerten. An efficient distancebounding RFID authentication protocol: Balancingfalse-acceptance rate and memory requirement. InP. Samarati, M. Yung, F. Martinelli, and C. Ardagna,editors, Information Security, volume 5735 of LectureNotes in Computer Science, pages 250–261.Springer-Verlag, 2009.

[3] S. Brands and D. Chaum. Distance-boundingprotocols. In T. Helleseth, editor, Proceedings ofEUROCRYPT ’93, volume 765 of Lecture Notes inComputer Science, pages 344–359. Springer-Verlag,1994.

[4] L.-W. Chan, J.-R. Chiang, Y.-C. Chen, C.-N. Ke,J. Hsu, and H.-H. Chu. Collaborative localization:Enhancing WiFi-based position estimation withneighborhood links in clusters. In K. Fishkin,B. Schiele, P. Nixon, and A. Quigley, editors,Pervasive Computing, volume 3968 of Lecture Notes inComputer Science, pages 50–66. Springer-Verlag, 2006.

[5] T. Christ, P. Godwin, and R. Lavigne. A prison guardduress alarm location system. In Proceedings ofSecurity Technology, pages 106 –116, oct 1993.

[6] Y. Deswarte and M. Roy. Privacy-enhancing accesscontrol enforcement. In Proceedings of the W3CWorkshop on Languages for Privacy PolicyNegotiation and Semantics-Driven Enforcement, 2006.

[7] M. Fiore, C. Casetti, C.-F. Chiasserini, andP. Papadimitratos. Discovery and verification ofneighbor positions in mobile ad hoc networks. IEEETransactions on Mobile Computing, 99 2011.

[8] J.-C. Freytag. Context quality and privacy - friends orrivals? In K. Rothermel, D. Fritsch, W. Blochinger,and F. Dürr, editors, Quality of Context, volume 5786of Lecture Notes in Computer Science, pages 25–40.Springer-Verlag, 2009.

[9] S. Gambs, M.-O. Killijian, and M. N. delPrado Cortez. Show me how you move and I will tellyou who you are. In Proceedings of the 3rd ACMSIGSPATIAL International Workshop on Security andPrivacy in GIS and LBS (SPRINGL’10), pages 34–41,New York, NY, USA, 2010.

[10] A. Haeberlen, E. Flannery, A. M. Ladd, A. Rudys,D. S. Wallach, and L. E. Kavraki. Practical robustlocalization over large-scale 802.11 wireless networks.In Proceedings of MobiCom’04, pages 70–84, NewYork, NY, USA, 2004.

[11] G. Hancke and M. Kuhn. An rfid distance boundingprotocol. In Proceedings of SecureComm’05, pages 67– 73, sept. 2005.

[12] D. L. Lee and Q. Chen. A model-based wifi

localization method. In Proceedings of the 2ndinternational conference on Scalable informationsystems (InfoScale’07), pages 40:1–40:7, ICST,Brussels, Belgium, Belgium, 2007.

[13] H. Liu, H. Darabi, P. Banerjee, and J. Liu. Survey ofwireless indoor positioning techniques and systems.Systems, Man, and Cybernetics, Part C: Applicationsand Reviews, IEEE Transactions on, 37(6):1067–1080, November 2007.

[14] B. Paramvir, P. Venkata, N., and B. Anand.Enhancements to the radar user location and trackingsystem. Technical report, Microsoft Research,University of California at San Diego, 2000.

[15] K. B. Rasmussen and S. Čapkun. Location privacy ofdistance bounding protocols. In Proceedings of the15th ACM conference on Computer andcommunications security (CCS’08), pages 149–160,New York, NY, USA, 2008.

[16] K. B. Rasmussen and S. Čapkun. Realization of rfdistance bounding. In Proceedings of the USENIXSecurity Symposium, 2010.

[17] N. Sastry, U. Shankar, and D. Wagner. Secureverification of location claims. In Proceedings of the2nd ACM workshop on Wireless security (WiSe’03)pages 1–10, New York, NY, USA, 2003.

[18] D. Singelee and B. Preneel. Distance bounding innoisy environments. In F. Stajano, C. Meadows,S. Capkun, and T. Moore, editors, Security andPrivacy in Ad-hoc and Sensor Networks, volume 4572of LNCS, pages 101–115. Springer-Verlag, 2007.

[19] N. O. Tippenhauer, K. B. Rasmussen, C. Pöpper, andS. Čapkun. Attacks on public wlan-based positioningsystems. In Proceedings of the 7th InternationalConference on Mobile Systems, Applications, andServices (MobiSys’09), pages 29–40, New York, NY,USA, 2009.

[20] R. Trujillo-Rasua, B. Martin, and G. Avoine. ThePoulidor distance-bounding protocol. In S. Ors Yalcin,editor, Radio Frequency Identification: Security andPrivacy Issues, volume 6370 of Lecture Notes inComputer Science, pages 239–257. Springer-Verlag2010.

[21] S. Čapkun, L. Buttyán, and J.-P. Hubaux. Sector:secure tracking of node encounters in multi-hopwireless networks. In Proceedings of the 1st ACMworkshop on Security of Ad Hoc and Sensor Networks(SASN’03), pages 21–32, New York, NY, USA, 2003.

[22] Z. Zhu and G. Cao. Towards privacy-preserving andcolluding-resistance in location proof updating system.IEEE Transactions on Mobile Computing,99(PrePrints), 2011.

AMORES:an Architecture for MObiquitous REsilient Systems

Christian Artigues, Yves DeswarteJérémie Guiochet, Marie-José Huguet

Marc-Olivier Killijian, David PowellMatthieu Roy

LAAS-CNRS, FranceUniversité de Toulouse, France

{firstname.name}@laas.fr

Emmanuelle AnceaumeSébastien Gambs

Gilles GuetteMichel HurfinIRISA - INRIA

France{firstname.name}@irisa.fr

Christophe Bidan, Nicolas PrigentSupelecFrance

{firstname.name}@supelec.fr

Frédéric SchettiniMobiGISFrance

{name}@mobigis.fr

ABSTRACTWe present the AMORES project, which aims to providean architecture for the provision of privacy preserving andresilient collaborative services in “mobiquitous” (i.e., mobileand ubiquitous) systems. The project is built around threeuse-cases from the area of public transportation: (1) dy-namic carpooling, (2) real-time computation of multimodaltransportation itineraries and (3) mobile social networking.Four main research tasks are presented in this paper. Thefirst task deals with use-cases, prototypes and privacy as-sessment. The second task addresses geo-communicationprimitives: verified positioning, locanyms and geo-services.The third task deals with privacy-preserving communicationmeans such as anonymous routing and geo-cryptography.Finally, the last task is devoted to collaborative behaviors.

KeywordsMobiquitous, Mobility, Privacy, Geo-privacy

1. INTRODUCTIONThe ubiquitous world in which we live is characterized by

a high mobility of individuals, most of them wearing devicescapable of geo-localization (smartphones or GPS-equippedcars). However, most of the current transportation systemshave not yet really used the facilities o↵ered by these geo-located devices to improve the mobility of their users or topropose new transportation means. Situated in this “mobiq-uitous” context, the AMORES project is built around threeuse-cases related to mobility, namely (1) dynamic carpool-ing, (2) real-time computation of multimodal transportation

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ARMOR ’12 May 08 - 11 2012, Sibiu, RomaniaCopyright 2012 ACM 978-1-4503-1150-2/12/05 ...$10.00.

itineraries and (3) mobile social networking. For these threeuse cases, the AMORES project focusses on the definitionand the development of geo-communication primitives at themiddleware level that can o↵er the required geo-located ser-vices, while at the same time preserving the privacy of users,in particular with respect to their location (notion of geo-privacy). The geo-primitives refer to the set of services usedfor data exchange between applications, which are aware oftheir location and can explicitly take into the geographicalcontext. We focus on the study of geo-located services suchas geo-casting, geo-registers, geo-queries and geo-computing.Moreover, to guarantee the authenticity of the location in-formation, we are studying techniques that can be used toverify the positions claimed by the entities. To o↵er privacyguarantees, we propose an anonymization method based onlocation data that we refer to as “locanyms”. To o↵er suchfeatures, the geo-communication primitives require some ba-sic functions, such as routing, cryptographics, cryptographickey distribution and management, and location recognition.Thus, privacy must also be considered at the level of thesebasic functions in order to control the digital traces gener-ated by their use. It is thus also necessary to study theproblem of anonymous routing and key generation takinggeo-awareness explicitly into account. Each of these ser-vices can only work through cooperation between the di↵er-ent entities composing the mobile network. Therefore, weare developing mechanisms to encourage entities to cooper-ate with each other in a privacy-preserving manner, and toprovide services that can detect entities that behave mali-ciously, such as by deliberately providing fake information.

For each of the previously mentioned use cases, we aim toimplement proof-of-concept prototypes based on the prim-itives developed at the middleware level. Thus, to provethe applicability of our approach, we plan to implementreal-time computation of multimodal itineraries and mo-bile social networking. The underlying middleware will bedistributed as open source. The third use case, i.e., dy-namic carpooling, will be integrated within the product lineof one of the partners. Another important contribution ofthe project will be the demonstration and delimitation of thereal possibilities o↵ered by the proposed approach. A gen-

eralization of the expected results in the Toulouse area, incollaboration with Tisseo (the Toulouse public transit com-pany), will nourish our reflection about the future of urbantransport systems and the practical applicability of such anapproach.

To summarize, the outputs of the project are both concep-tual and practical: definition of innovative privacy-preservinggeo-communication primitives for mobiquitous systems, im-plementation of a middleware and some proof-of-conceptprototypes and, finally, an impact on next generation publictransportation.

2. OBJECTIVESThe AMORES project has two main high-level objectives:

1) Leverage the existence of ubiquitous computing, commu-nication and positioning via small and mobile devices, suchas smartphones, in order to provide high-level mobility ser-vices targeted at increasing the use of public transportationand reducing CO2 emissions;2) Provide a privacy-conscious, geo-aware middleware forthe provision of cooperative services in the emerging mobiq-uitous era of computing.

To the best of our knowledge, no such geo-communicationoriented middleware yet exists. We strongly believe that,in a mobiquitous setting, with numerous interacting mo-bile nodes, mobility and geographical distribution should beexplicitly taken into account. Indeed, centralized architec-tures cannot scale to the situation where billions of mobilenodes need to interact with each other, looking for local ser-vices. We believe that the highly innovative geo-primitivesthat we envision will help application designers to imple-ment geo-aware services for the mobiquitous setting. Theseprimitives include: (1) verified positioning, which can ver-ify the location claimed by a node, (2) locanyms, whichcan be used to address a node by its location and not byits identifier while still providing strong properties like ac-countability and non-repudiation, and (3) higher-level geo-services for communication (geo-casting), data storage (geo-registers, geo-btrees, etc.), search (geo-queries) and compu-tation (geo-measurements).

The mobiquitous environment, in which devices are mo-bile and geo-located and where services are location-based,raises several privacy issues due to the fact that geo-locateddevices usually belong to an individual (or a group of per-sons such as a family) and as such their locations corre-spond to the locations of their owner(s). Among the variousitems of Personal Identifiable Information (PII) that may berevealed, the location of an individual is one of the great-est threats against his privacy. For instance, the spatio-temporal data of an individual can be used to infer the loca-tion of his home and workplace, to trace his movements andhabits, to learn information about his center of interests oreven to detect a change from his usual behavior. Therefore,the preservation of location privacy is a major concern whenleveraging the possibilities o↵ered by the mobiquitous set-ting to provide e�cient and trusted geo-services. We intendto assess the privacy risks of each use case and then fol-low the privacy-by-design principle to develop a geo-servicemiddleware that is publicly (and politically) acceptable andtrustworthy.

Being able to communicate anonymously is a necessary(but not su�cient) condition for preserving privacy. It im-plies the ability to perform anonymous routing, which con-stitutes a di�cult research challenge. Existing approacheseither require, for two nodes that wish to communicate, toknow their respective location [11, 12], or deeply rely ona trusted authority. These two limitations prevent the useof their solutions in the applications envisioned within theAMORES project, especially for mobile social networking.To avoid the need for a trusted central authority, we willtherefore study distributed mechanisms to generate cryp-tographic keys that are tied to a specific location (we callthem “geo-keys”). Once the geo-keys have been generated,they can be used for authentication purposes as well as forensuring the confidentiality of communications. Finally, toencourage nodes to cooperate in a trustable and privatemanner, we intend to use digital reputation. Digital reputa-tion has been proven e�cient to handle the first challenge.However, because it demands a certain measure of controlover the revelation of personal information and its distri-bution across networks, digital reputation seems to conflictwith values of free expression and many business models.On the other hand, if, as for anonymous voting in elections,the feedback collected by reputation mechanisms is anony-mous, we might be confident that it should potentially en-courage trustfulness by guaranteeing secrecy and freedomfrom any influence (fears of retaliation or reciprocation). Al-though such anonymous feedbacks can be exploited by un-trustworthy feedback providers (through ballot stu�ng andbad mouthing strategies), we are convinced that the benefitbrought for honest parties would be considerable: their pri-vacy would be respected and thus they would be protectedfrom any strategic manipulation.

3. PROJECT STRUCTUREThe AMORES project aims to develop privacy-preserving

middleware for cooperative mobiquitous systems. The de-velopment of the project is guided by a top-down approachwithin the area of public transportation.

3.1 Use-cases and privacy risksThis task forms the substrate of all the other technical

tasks. It will investigate concrete application scenarios thatwill serve for defining security and privacy requirements ofthe project, as well as for identifying the technical chal-lenges, and threats to these requirements. First, we willstudy a set of three use-cases that are relevant to AMORESand identify for each of them the fundamental primitivesthat are needed and the main challenges to be addressed.Then, we will define and analyze the high-level privacy andsecurity requirements linked to the mobiquitous setting. Thefinal subtask is devoted to prototyping activities, dissemi-nation of the developed middleware, production of proof-of-concept prototypes, and integration of prototypes on realplatforms.

3.1.1 Use-casesThe chosen application domain is public transportation,

which, in our opinion, is a good setting for providing location-based services on top of mobile ad hoc networks. We chosethis application domain for several reasons. First, in a pub-lic transportation system, the architecture is hybrid sincemost entities (users, buses, cars, trains, etc.) are mobile

but some are fixed (train/bus/bicycle stations, highway tollstations) and can be used as gateways to an infrastructureor as anchors for positioning purposes. Second, the appli-cation domain itself is by essence concerned with mobility,proximity and similar notions. It should thus benefit greatlyfrom the geo-aware middleware that we want to build withinAMORES. Finally, privacy is of paramount importance insuch a setting as users move between places but their mo-bility patterns should be kept private from other entities(even from other mobile users that they periodically meetand cooperate with) as they generally do not know themand therefore cannot blindly trust them. The three candi-date use-cases that we have identified are:

• Dynamic carpooling : this service dynamically matchestogether car drivers with passengers from suburban to urbanjourneys or intra-urban journeys. The dynamic carpoolingservice needs to implement algorithms for dynamic vehiclerouting problems, where multiple vehicles may candidate topick up passengers that are themselves potentially movingon a network. To implement this functionality, we intendto leverage both the mobile social network and the availableinfrastructure.

• Multi-modal itineraries in real-time: this service com-putes in real-time the optimal multimodal (bus, subway,train but also bicycle, walking or carpooling) itinerary bytaking into account the up-to-date spatial and temporal in-formation of the various entities. If multimodal shortestpath algorithms are now well studied in static networks,they remain challenging in a dynamic network. For instance,given two passengers moving on a network, finding opti-mal meeting points according to various criteria (e.g., cost,time or preferred locations) and the associated multimodalitineraries is a complex and di�cult issue.

• Mobile social networking : all mobile users using the pub-lic transportation system form a mobile social network at thescale of a city. In the AMORES project, we envision to useexplicitly the mobile social network to implement servicessuch as discovering if a friend is located in one’s vicinity(e.g., in the same train) or is currently moving towards thearea where one is staying and could potentially pick one upon his way. Apart from these social functionalities, we alsowant to rely on the possibilities o↵ered by this mobile adhoc network to develop trust mechanisms giving for instancemore important roles to close friends.

3.1.2 High-level privacy concernsThe objective of this subtask is to evaluate and assess the

privacy risks incurred for the di↵erent use-cases, and to showhow these risks are dealt with by the mechanisms developedin AMORES. In this subtask, we will:1) Apply a classic risk assessment process starting from adefinition of system usage based on UML interaction modelsfor the three use-cases.2) Identify relevant incident scenarios, including identifi-cation of threats, vulnerabilities, a↵ected assets, and con-sequences to assets. This work will be carried out usingcollaborative methods commonly used in the safety domain(such as preliminary hazard analysis). A scale describing themagnitude of potential consequences and their likelihood ofoccurrence (for instance depending on potential benefits orease of attack) will be proposed. This scale will be used toquantify the risks of the previously identified hazards.3) Evaluate the risk acceptability (based on the previous

estimation) to decide if a reduction of this risk is needed.In particular, the impact of/on geo-primitives developed inother tasks, which can be viewed as risk reduction strategies,will be investigated.

3.1.3 PrototypingVarious prototypes will be developed, which will have dif-

ferent levels of maturity. First, a proof-of-concept prototypeof use-cases 2 and 3 will be developed, on top of the ARUMmobile robot platform previously developed at LAAS [21], toevaluate whether the middleware geo-primitives (and theirassociated properties) are adequate or not. Then, at a laterstage, the middleware will be integrated in the MobiGIS in-tegration platform and use-case 1 will be developed on top ofit. We are also planning to have on the MobiGIS platform ahybrid dynamic/static carpooling prototype. For instance,when a user is planning a journey, he will first search locallyusing the dynamic version of the tool; if he fails to find acarpool partner, he will switch to the static (and alreadyexisting) version of carpooling.

3.2 Geo-communication PrimitivesThis task will provide geo-communication primitives en-

abling geo-aware design of the use-cases while preserving pri-vacy (for instance, by limiting the dissemination of location)through architectural and algorithmic solutions. Withinthe course of the project, we want to study specifically thefollowing three geo-primitives (it is worth noting that theformer two, Verified Positioning and Locanyms are the de-scribed in details in [16]):

• Verified positioning. A fundamental geo-primitive wewant to provide is verified positioning through which a mo-bile node can prove its current location to other nodes ina secure and distributed manner. This primitive is neces-sary to build other more advanced building blocks such aslocanyms and geo-services. More precisely, we will (1) ex-plore how the use of mobile base stations (such as buses orother itinerant nodes) [6] can be used to implement morerobust mechanisms for location verification, (2) pursue theline of research recently introduced by [7], which adopts anon-standard cryptographic model called bounded retrievalin order to solve the verified positioning problem which theyproved to be impossible to solve in the general model, (3) in-vestigate how “collusion attacks” may be mitigated throughmobile social network information [26] and related trust mech-anisms.

• Locanyms. As a second middleware geo-primitive, weplan to develop the concept of locanyms, a geo-located ver-sion of pseudonym that is tied to a particular geographicalarea. We believe that it is possible to define locanyms thatprovide advanced properties such as accountability and non-repudiation. For instance, in the carpooling use-case, theuse of locanyms seems su�cient to authenticate the variousparties while trying to establish a relationship (e.g., look-ing for potential candidates to connect for a trip). Once arelationship is established and the parties physically meet,locanymity (location anonymity) can be lifted and identitiesexchanged as the users meet face-to-face anyway. The ac-countability property can be important to prove to a thirdparty (such as the administration of the city) that an entityhas e↵ectively participated in a carpooling activity, in orderto get a discount on his or her public transport subscrip-tion for instance. The non-repudiation property, which can

be obtained through a combination of locanyms and digi-tal signatures, will ensure that an entity cannot deny hav-ing participated in a geo-service to which he had previouslygiven his explicit consent. This property can be essential forbilling purposes or to provide cooperation incentives.

• Geo-services. Both verified positioning and locanymsare geo-primitives focusing on providing individual proper-ties and services (such as the verified positioning of one en-tity or a locanym). Beyond these, broader geo-primitivesaimed at providing fundamental distributed services such ascommunication, storage, search and computation need to bedeveloped. Regarding geo-communication, we will design ageo-located variant of group communication, which is a fun-damental mechanism in classical distributed systems. Oneof the challenges of group communication deals with the con-sistency of the group membership views (i.e., who currentlybelongs to the group), and how nodes join and leave thegroup. We want to create a service such that, at the mo-ment of the group creation, nodes geo-located in the samevicinity or within a particular delimited area communicatewith one another to create the original group structure [20].We believe that a privacy-aware notion of geo-groups (orgeo-cast) can be a very useful building block for higher-levelgeo-primitives. Moreover, we also want to develop an anony-mous variant of geo-cast. Concerning geo-storage, we plan tointroduce an abstract object, called a geo-register that canassociate a value to a geographical location. A geo-registeris defined by a geographic area; nodes located within thisarea participate in the maintenance of the geo-register andcan use it (i.e., by read and write operations). We believethat such a basic geo-primitive can be further extended toprovide richer primitives such as geo-counters or more ad-vanced structures such as geo-binary trees that could help tospeed up other functionalities (e.g., searching). Geo-searchdeals with queries that are bound to a specific geographicalarea, such as finding the nearest pizzeria for example. Anaive implementation of a geo-search could be built on topof locanyms, geo-casting, and anonymous routing. For in-stance, the requesting node, authenticated by its locanym,issues a search by geo-casting its query (e.g., where is thenearest bus stop); an answering node will then reply usinganonymous point-to-point communication. Better strategieswill be investigated to optimize the communication resourcesneeded and to obtain better privacy guarantees. Finally, ageo-computing primitive could be used to evaluate in real-time some node-dependent property of the zone, such as thedensity of nodes, or the mean waiting time of users presentat a given bus stop.

3.3 Basic communication componentsThis task will focus on the necessary basic privacy-preserving

communication components for the provision of the geo-primitives. Many of these basic components will come di-rectly from the state-of-the-art, such as positioning tech-niques, anonymous Medium Access Control or standard cryp-tographic techniques. In AMORES, we will specifically workon the following two basic privacy-preserving components:a privacy preserving routing layer and geo-cryptographicprimitives for generating and managing cryptographic keyslinked to a geographical place.

Ad hoc routing is particularly suitable for handling com-munication in mobiquitous networks because of their evolv-ing and dynamic aspect. Many ad hoc routing protocols

have been proposed to establish communication betweennodes without the support of any fixed infrastructure orcentral administration. Unfortunatly, the information thatis used to build the routing tables and that each node is sup-posed to disclose (e.g., the MAC and/or IP addresses) gener-ally allows unambiguous identification of the nodes, makinganyone able to identify and track any node that collaboratesin the routing service. Moreover, by looking for transientlynearby nodes, an attacker can guess which users were locatedin the same area and can deduce potential social interactionsfrom this physical proximity. Furthermore, if the attackerknows the geographical position of certain nodes, it becomespossible for him or her to track the time-varying relative po-sitions of the other nodes. Finally, an attacker can also quiteeasily track the occurrence of communications between anypair of nodes.

3.4 Cooperation incitationThis task will address the di↵erent aspects needed to pro-

mote cooperation among unknown users and devices. Oneaspect relates to the quality of service observed during inter-actions between nodes. Another aspect is how to e�ciently,securely and anonymously collect observations of these in-teractions over the hybrid network. The last aspect is theevaluation of a reputation score according to the collectedobservations and their credibility.

4. RELATED WORKIn this section, we briefly describe the current state of the

art in the main scientific themes addressed by the AMORESproject: privacy-preserving geo-aware middleware, anony-mous routing and communication in MANETs, and cooper-ation incitation.

4.1 Privacy-preserving geo-aware middlewareThe field of middleware for mobile/mobiquitous systems

is by itself relatively recent [2, 33, 21]. One essential fea-ture in these settings is context awareness, and more par-ticularly geo-location awareness. Early works try to addressnew primitives for data-sharing or communication on topof mobile systems, see, e.g., geo-registers [27], asynchronousshared memory [24], or tuple-spaces [32, 14]. Other researchhas focused on online reconciliation of o✏ine transactionsbased on partial representations [23, 29]. Peer-to-peer isone of the most used paradigms when researchers try to dealwith the mobility aspect. This is quite relevant since, whenconsidering information flow from the low layers (routing) tothe upper layers (application), access to classic servers cannever be guaranteed when a node is mobile [18, 9].

To the best of our knowledge, there has been no previouswork specifically targeting the issue of privacy in middle-ware for mobiquitous systems. Geo-privacy seeks to preventan unauthorized entity from learning the past, current andfuture locations of an individual [3]. Indeed, learning the lo-cation of an individual is one of the greatest threats againsthis privacy [15]. An adversary can combine some auxiliaryknowledge with this location information to gain additionalknowledge. For example, if the adversary has access to thesocial network of an individual, he can determine when theperson is visiting a given friend.

In a mobiquitous setting, the identity of an entity is not(only) defined in the usual sense by its name, its physicalcharacteristics or its public key but rather according to its

location and mobility behavior. One fundamental issue istherefore to be able to verify the location claimed by anentity in a secure manner. Indeed, if a location is used asa form of credential and a malicious entity can cheat withits location, this opens the way to a panoply of attacks onthe geolocated services that could go as far as creating mul-tiple identities, each claiming to be at a di↵erent location(this corresponds to a geolocated variant of the Sybil at-tack [10]). Brands and Chaum [4] were among the first onesto design a distance-bounding protocol using the notion oftime-of-response to verify the location. For an entity, prov-ing its location generally requires interactions with severalverifiers. The verifiers send challenges (i.e., messages) tothe prover, using for instance a medium such as radio waves(which travel at the speed of light), and measure the timetaken to receive a response. Depending on the time taken,the verifiers can identify and certify collectively the locationof the entity. Several protocols found in the literature [28,5] are based on this cooperative approach between verifiersfor ensuring secure positioning. However, a recent work [7]has shown that these techniques are sensitive to a “collusionattack” (in such attacks, several provers collude together toconvince the verifiers that they are talking to a single proverlocated at a fake location). Providing a geo-aware communi-cation middleware with verifiable locations while preservinggeo-privacy is one of the challenges addressed by AMORES.

4.2 Anonymous routing and communicationIn MANETs, routing protocols can be broadly classified

as proactive (e.g. OLSR [8]) or reactive (e.g. AODV [25]).In proactive routing protocols, nodes update their routingtables periodically by exchanging information about the net-work’s topology and connectivity, while in reactive routingprotocols (also called on-demand), the source searches forthe route only when it has to send a message. During thedesign of all these protocols, the focus has been so far onperformance, scalability, energy consumption and some se-curity issues (mainly confidentiality, authenticity, integrityand availability) whereas privacy seems at first glance tobe antagonistic with the very principles of ad hoc rout-ing. To address this problem, some seminal works have pro-posed privacy-preserving variants of ad hoc routing proto-cols. Most of these protocols (e.g., MASK [34], ARM [30])are reactive and consist in (1) using cryptographic primi-tives to generate pseudonyms during route requests and (2)by hiding communication between two nodes through anony-mous communication networks such as mixnets or non-routingrelays. Recently, Al Defrawy and Tsudik have proposed twolocation-based ad hoc routing protocols ([11, 12]) that ad-dress partially privacy issues. In these protocols, a node Adecides to communicate with another node B depending onwhere B is located at the present time.

4.3 Cooperation incitationMost of the services addressed by AMORES critically de-

pend on cooperation to be e↵ective. This raises new con-cerns related to the willingness of parties to collaborate,the establishment of trust among parties, and incentivesfor fair participation. These concerns are exacerbated bythe fact that all these services propose to take advantage ofboth autonomous rational parties (users/humans) and deter-ministic altruistic ones (buses, trams, subway trains). Twomain approaches exist to enforce fair cooperation among al-

most or completely unknown parties: currency-based andreputation-based mechanisms. Currency-based mechanismseither rely on the presence of a centralized entity in chargeof trading credits [35] or on the propensity of participantsto exchange currency (usually a virtual one). This central-ized approach is incompatible with the very nature of theapplications we consider, the underlying networks, as wellas with the preservation of privacy. Moreover, paying nodesfor their willingness to collaborate may not be tractable atall levels of our architecture [19]. The recent emergenceof e-commerce in open large-scale distributed marketplaceshas shown that digital reputation systems stimulate inter-actions among strangers and encourage them to behave in atrustworthy manner, while discouraging them in presenceof deviant parties. Similarly to real world reputation, adigital reputation mechanism expresses a collective opin-ion about some target entity by collecting and aggregatingfeedback about the past behavior of that entity [22]. Be-cause of their strong impact on reducing the risks of collab-orating with strangers, these mechanisms have been studiedfrom the viewpoint of them being e�cient, scalable, accurateand robust against undesirable behaviors ([1, 13]). On theother hand, none of the current distributed implementationsof reputation mechanisms have addressed privacy concerns.Deducing user profiles (i.e., combining all the contexts inwhich a user has been involved in, such as the communi-ties or people with whom that user has recently interacted,the frequency of these interactions, his satisfaction, his irri-tation) may be of high interest and a promising target forcollectors of private data [17], or worse for retaliation argu-ments. In any case, this is clearly in contradiction with theuser’s right to privacy [31].

5. CONCLUSIONIn this paper, we presented the AMORES project, which

aims to provide an architecture for the provision of privacy-preserving and resilient collaborative services in mobiquitoussystems. The project, started in October 2011 and runningfor 42 months, is built around four tasks and three use-casesin the area of public transportation. The first task deals withthe use-cases, the prototypes and privacy assessment. Thesecond task addresses geo-communication primitives: veri-fied positioning, locanyms and geo-services. The third taskdeals with privacy-preserving communication means suchas anonymous routing and geo-cryptography. Finally, thefourth task is devoted to cooperation incentives.

6. ACKNOWLEDGMENTSThis work was partially supported by LAAS, CNRS, Aerospace

Valley and ANR French national program for Security andInformatics (grant #ANR-11-INSE-010).

7. REFERENCES[1] E. Anceaume and A. Ravoaja. STORM: A secure

overlay for p2p reputation management. In IEEEInternational Conference on Self-Adaptive andSelf-Organizing Systems (SASO 2007), 2007.

[2] P. Bellavista and A. Corradi. The Handbook of MobileMiddleware. Auerbach Publications, 2006.

[3] A. R. Beresford and F. Stajano. Location privacy inpervasive computing. IEEE Pervasive Computing,3(1):46–55, 2003.

[4] S. Brands and D. Chaum. Distance-bounded protocols(extended abstract). In EUROCRYPT’93, pages244–359, 1993.

[5] L. Bussard. Trust establishment protocols forcommunicating devices. PhD thesis, Eurecom, 2004.

[6] S. Capkun, M. Cagalj, and S. M. Secure localizationwith hidden and mobile base stations. In Proc. ofIEEE INFOCOM, 2006, 2006.

[7] N. Chandran, V. Goyal, R. Moriarty, andR. Ostrovsky. Position based cryptography. InCRYPTO’09, pages 391–407, 2009.

[8] T. Clausen and P. Jacquet. Optimized link staterouting protocol (OLSR). IETF mobile ad hocnetworking Working Group, RCF 3626, 2003.

[9] L. Courtes, O. Hamouda, M. Kaaniche, M. Killijian,and D. Powell. Dependability evaluation ofcooperative backup strategies for mobile devices. In13th IEEE Pacific Rim International Symposium onDependable Computing (PRDC’07), 2007.

[10] J. Douceur. The sybil attack. Peer-to-peer Systems,pages 251–260, 2002.

[11] K. El Defrawy and G. Tsudik. Alarm: Anonymouslocation aided routing in suspicious manets. In Proc.of the 2007 IEEE International Conference of NetworkProtocols (ICNP’07), 2007.

[12] K. El Defrawy and G. Tsudik. Prism: Privacy-friendlyrouting in suspicious manets (and vanets). In Proc. ofthe 2008 IEEE International Conference of NetworkProtocols (ICNP’08), October 2008.

[13] M. S. Fallah and M. Mouzarani. A game-basedsybil-resistant strategy for reputation systems inself-organizing MANETs. The Computer Journal,2011.

[14] E. Freeman, S. Hupfer, and K. Arnold. JavaSpaces:Principles, Patterns, and Practice. Addison-Wesley,1999.

[15] S. Gambs, M. Killijian, and M. Prado Cortez. Showme how you move and i will tell you who you are. InACM SIGSPATIAL International Workshop onSecurity and Privacy in GIS and LBS, 2010.

[16] S. Gambs, M.-O. Killijian, M. Roy, and M. Traore.Locanyms: Towards privacy-preserving location-basedservices. Technical Report 12032, LAAS-CNRS, 2012.

[17] E. Gudes, N. Gal-Oz, and A. Grubshtein. Methods forcomputing trust and reputation while preservingprivacy. In Proceedings of the 23rd Annual IFIP WG11.3 Working Conference on Data and ApplicationsSecurity XXIII, pages 291–298, 2009.

[18] H. Hsieh and R. Sivakumar. On using peer-to-peercommunication in cellular wireless data networks.IEEE Trans. Mobile Comput., 3(1):57–72

”2004.

[19] S. Kamvar, M. Schlosser, and H. Garcia-Molina. Theeigentrust algorithm for reputation management inp2p networks. In Proc. of the Int’l Conference onWorld Wide Web (WWW), 2003.

[20] M.-O. Killijian, R. Cunningham, R. Meier, L. Mazare,and V. Cahill. Towards group communication formobile participants. In Proc. of Principles of MobileComputing, POMC-2001, page 8, 2001.

[21] M.-O. Killijian and M. Roy. Data backup for mobilenodes : a cooperative middleware and anexperimentation platform. Architecting DependableSystems, 7, 2009.

[22] S. Marti and H. Garcia-Molina. Taxomany of trust:Categorizing p2p reputation systems. ComputerNetworks Journal, 50(4):472–484, 2006.

[23] C. Mascolo, L. Capra, S. Zachariadis, andW. Emmerich. Xmiddle: a data-sharing middlewarefor mobile computing. Int. Journal on WirelessPersonal Communication, 21(1):77–103, 2002.

[24] B. Nitzberg and V. Lo. Distributed shared memory: asurvey of issues and algorithms. IEEE Computer,24:52–60, 1991.

[25] C. Perkins, E. Belding-Royer, and S. Das. Ad hocon-demand distance vector (AODV) routing. IETFmobile ad hoc networking WG, RFC 3561, 2003.

[26] D. Quercia and S. Hailes. Sybil attacks against mobileusers: friends and foes to the rescue. In Proc. of IEEEINFOCOM, 2010, pages 336–340, 2010.

[27] M. Roy, F. Bonnet, L. Querzoni, S. Bonomi,M. Killijian, and D. Powell. Geo-registers : anabstraction for spatial-based distributed computing. InOPODIS’08, 2008.

[28] N. Sastry, U. Shankar, and D. Wagner. Secureverification of location claims. In WiSe03, pages 1–10,2003.

[29] M. Satyanarayanan, J. Kistler, P. Kumar, M. Okasaki,E. Siegel, and D. Steere. CODA: a highly available filesystem for a distributed work- station environment.IEEE Trans. Comput., 39(4):447–459, 1990.

[30] S. Seys and B. Preneel. ARM: Anonymous routingprotocol for mobile ad hoc networks. In 20thInternational Conference on Advanced InformationNetworking and Applications, 2006.

[31] S. Steinbrecher. Enhancing multilateral security inand by reputation systems. IFIP InternationalFederation for Information Processing, 298, 2009.

[32] P. Wycko↵, S. Mclaughry, T. Lehman, and F. D.TSpaces. IBM Syst. J., 37:454–474, 1998.

[33] Y. Yu, B. Krishnamachari, and V. Prasanna. Issues indesigning middleware for wireless sensor networks.IEEE Network, 1:15–21, 2004.

[34] Y. Zhang, W. Liu, W. Lou, and Y. Fang. MASK:Anonymous on-demand routing in mobile ad hocnetworks. IEEE Transactions on WirelessCommunications, 5(9), 2006.

[35] S. Zhong, J. Chen, and Y. R. Yang. Sprite: A simple,cheat-proof, credit-based system for mobile ad-hocnetworks. In INFOCOM, 2003.

AMORES1: an Architecture for MObiquitous REsilient Systems

Frédéric Schettini*, Sylvain Gaudan, Florian Decavele

MobiGIS ZAC Grenade Sud – PALEGRIL – Rue de l'Autan – 31330 Grenade, France

[email protected], +33 (0) 581 608 081

Marc-Olivier Killijian*, Matthieu Roy*

CNRS-LAAS - 7, avenue du Colonel Roche - 31077 Toulouse Cedex 4, France

[email protected] , +33 (0) 561 336 241 / [email protected] , +33 (0) 561 336 200

Collaboration:

The AMORES project is organized around four partners and one associated member, which are

respectively LAAS-CNRS (Christian Artigues, Yves Deswarte, Jérémie Guiochet, Marie-José

Huguet, Marc-Olivier Killijian, David Powel, Matthieu Roy), MobiGIS (Frédéric Schettini, Laurent

Dezou), Université de Rennes 1 (Emmanuelle Anceaume, Sébastien Gambs, Gilles Guette, Michel

Hurfin), Supélec (Christophe Bidan, Nicolas Prigent) and Tisséo.

Context

Today, an expanding number of people are using geo-localized devices such as smartphones or GPS to

travel or simply commute. However, most of the current transportation systems do not exploit to the

full opportunities offered by these geo-located devices to improve mobility or to propose new

transportation solutions. At the same time, mobile technologies users are feeling increasingly tracked

and preserving their privacy is a key issue to them.

Keywords: Mobiquitous, Geo-privacy, Carpooling, Real Time Routing, Mobile Social network.

Main goals & use cases

The AMORES project aims to provide an architecture for the

provision of privacy preserving and resilient collaborative

services in “mobiquitous" (i.e., mobile and ubiquitous) systems.

This project is built around three use-cases from the area of

public transportation:

- dynamic carpooling

- real-time computation of multimodal transportation

itineraries

- mobile social networking

This project will focus on the provision of geo-located services

such as geo-casting, geo-storage, geo-queries and, more

generally, geo-computing.

Research tasks

AMORES is architectured around four main tasks. The first task

deals with use-cases, prototypes and privacy assessment. The second task addresses geo-

communication primitives: verified positioning localized psudonyms (locanyms) and geo-services.

The third task deals with privacy-preserving communication means such as anonymous routing and

geo-cryptography. Finally, the last task is devoted to collaborative mechanisms.

Summary

The outputs of the project are both conceptual and practical: 1) innovative privacy preserving geo-

communication primitives for “mobiquitous” systems, and 2) middleware and some prototypes.

Project results are expected to impact next generation public transportation systems.

1This work is partially supported by LAAS, CNRS, Aerospace Valley and ANR French national

program for Security and Informatics (grant #ANR-11-INSE-010).

Livrable AMORES - LAASprojects.laas.fr/AMORES/doc/AMORES-L0.1.pdfLabels et correspondants des p les...

Documents

Transcript of Livrable AMORES - LAASprojects.laas.fr/AMORES/doc/AMORES-L0.1.pdfLabels et correspondants des p les...