DefendingagainstSybilDevicesinCrowdsourcedMappingServicesGangWangyBolu - PDF document

1 DefendingagainstSybilDevicesinCrowdsourc
DefendingagainstSybilDevicesinCrowdsourcedMappingServicesGangWangy,BolunWangy,TianyiWangyz,AnaNikay,HaitaoZhengy,BenY.ZhaoyyDepartmentofComputerScience,UCSantaBarbarazDepartmentofElectronicEngineering,TsinghuaUniversity{gangw,bolunwang,tianyi,anika,htzheng,ravenben}@cs.ucsb.eduABSTRACTReal-timecrowdsourcedmapssuchasWazeprovidetimelyup-datesontrafc,congestion,accidentsandpointsofinterest.Inthispaper,wedemonstratehowlackofstronglocationauthenti-cationallowscreationofsoftware-basedSybildevicesthatexposecrowdsourcedmapsystemstoavarietyofsecurityandprivacyat-tacks.OurexperimentsshowthatasingleSybildevicewithlim-itedresourcescancausehavoconWaze,reportingfalsecongestionandaccidentsandautomaticallyreroutingusertrafc.Moreim-portantly,wedescribetechniquestogenerateSybildevicesatscale,creatingarmiesofvirtualvehiclescapableofremotelytrackingpre-cisemovementsforlargeuserpopulationswhileavoidingdetec-tion.WeproposeanewapproachtodefendagainstSybildevicesbasedonco-locationedges,authenticatedrecordsthatattesttotheone-timephysicalco-locationofapairofdevices.Overtime,co-locationedgescombinetoformlargeproximitygraphsthatattesttophysicalinteractionsbetweendevices,allowingscalabledetectionofvirtualvehicles.Wedemonstratetheefcacyofthisapproachusinglarge-scalesimulations,anddiscusshowtheycanbeusedtodramaticallyreducetheimpactofattacksagainstcrowdsourcedmappingservices.1.INTRODUCTIONCrowdsourcingisindispensableasareal-timedatagatheringtoolfortoday'sonlineservices.Takeforexamplemapandnavigationservices.BothGoogleMapsandWazeuseperiodicGPSreadingsfrommobiledevicestoinfertrafcspeedandcongestionlevelsonstreetsandhighways.Waze,themostpopularcrowdsourcedmapservice,offersusersmorewaystoactivelyshareinformationonaccidents,policecars,andevencontributecontentlikeeditingroads,landmarks,andlocalfuelprices.Thisandtheabilitytoin-teractwithnearbyusersmadeWazeextremelypopular,withanestimated50millionuserswhenitwasacquiredbyGoogleforareported$1.3BillionUSDinJune2013.Today,Googleintegratesselectedcrowdsourceddata(e.g.accidents)fromWazeintoitsownMapsapplication.Unfortunately,systemsthatrelyoncrowdsourceddataarein-herentlyvulnerabletomischievousormalicioususersseekingtoPermissiontomakedigitalorhardcopiesofallorpartofthisworkforpersonalorclassroomuseisgrantedwithoutfeeprovidedthatcopiesarenotmadeordistributedforprotorcommercialadvantageandthatcopiesbearthisnoticeandthefullcita-tionontherstpage.CopyrightsforcomponentsofthisworkownedbyothersthanACMmustbehonored.Abstractingwithcreditispermitted.Tocopyotherwise,orre-publish,topostonserversortoredistributetolists,requirespriorspecicpermissionand/orafee.Requestpermissionsfrompermissions@acm.org.MobiSys'16,June25-30,2016,Singapore,Singapore\r2016ACM.ISBN978-1-4503-4269-8/16/06...$15.00DOI:http://dx.doi.org/10.1145/2906388.2906420disruptorgamethesystem[41].Forexample,businessownerscanbadmouthcompetitorsbyfalsifyingnegativereviewsonYelporTripAdvisor,andFourSquareuserscanforgetheirphysicallo-cationsfordiscounts[11,54].Forlocation-basedservices,theseattacksarepossiblebecausetherearenowidelydeployedtoolstoauthenticatethelocationofmobiledevices.Infact,therearefeweffectivetoolstodaytoidentifywhethertheoriginoftrafcrequestsarerealmobiledevicesorsoftwarescripts.Thegoalofourworkistoexplorethevulnerabilityoftoday'scrowdsourcedmobileappsagainstSybildevices,softwarescriptsthatappeartoapplicationserversas“virtualmobiledevices.”1WhileasingleSybildevicecandamagemobileappsthroughmisbehav-ior,largergroupsofSybildevicescanoverwhelmnormalusersandsignicantlydisruptanycrowdsourcedmobileapp.Inthispaper,weidentifytechniquesthatallowmaliciousattackerstoreliablycreatelargepopulationsofSybildevicesusingsoftware.UsingthecontextoftheWazecrowdsourcedmapservice,weillustratethepowerfulSybildeviceattack,andthendevelopandevaluaterobustdefensesagainstthem.WhileourexperimentsanddefensesaredesignedwithWaze(andcrowdsourcedmaps)inmind,ourresultsgeneralizetoawiderangeofmobileapps.Withminimalmodications,ourtechniquescanbeappliedtoservicesrangingfromFoursquareandYelptoUberandYikYak,allowingattackerstocheaplyemulatenumerousvirtualdeviceswithforgedlocationstooverwhelmthesesystemsviamisbehavior.MisbehaviorcanrangefromfalselyobtainingcouponsonFourSquare/Yelp,gamingthenewusercouponsys-teminUber,toimposingcensorshiponYikYak.Webelieveourproposeddefensescanbeextendedtotheseservicesaswell.WediscussbroaderimplicationsofourworkinSection8.SybilattacksinWaze.InthecontextofWaze,ourexperi-mentsrevealanumberofpotentialattacksbySybildevices.Firstissimpleeventforgery,wheredevicescangeneratefakeeventstotheWazeserver,includingcongestion,accidentsorpoliceactivitythatmightaffectuserroutes.Second,wedescribetechniquestoreverseengineermobileappAPIs,thusallowingattackerstocre-atelightweightscriptsthateffectivelyemulatealargenumberofvirtualvehiclesthatcolludeunderthecontrolofasingleattacker.WecallSybildevicesinWaze“ghostriders.”TheseSybilscaneffectivelymagnifytheefcacyofanyattack,andoverwhelmcon-tributionsfromanylegitimateusers.Finally,wediscoverasig-nicantprivacyattackwhereghostriderscansilentlyandinvisibly“follow”andpreciselytrackindividualWazeusersthroughouttheirday,preciselymappingouttheirmovementtowork,stores,hotels,gasstation,andhome.Weexperimentallyconrmedtheaccuracy 1WerefertothesescriptsasSy

2 bildevices,sincetheyaretheman-ifestation
bildevices,sincetheyaretheman-ifestationsofSybilattacks[16]inthecontextofmobilenetworks. ofthisattackagainstourownvehicles,quantifyingtheaccuracyoftheattackagainstGPScoordinates.Magniedbyanarmyofghostriders,anattackercanpotentiallytracktheconstantwhereaboutsofmillionsofusers,allwithoutanyriskofdetection.Defenses.Priorproposalstoaddressthelocationauthenticationproblemhavelimitedappeal,becauseofrelianceonwidespreadde-ploymentofspecializedhardware,eitheraspartofphysicalinfras-tructure,i.e.,cellularbasestations,orasmodicationstomobiledevicesthemselves.Instead,weproposeapracticalsolutionthatlimitstheabilityofSybildevicestoamplifythepotentialdamageincurredbyanysingleattacker.Weintroducecollocationedges,authenticatedrecordsthatattesttotheone-timephysicalproxim-ityofapairofmobiledevices.Thecreationofcollocationedgescanbetriggeredopportunisticallybythemappingservice,e.g.,Waze.Overtime,collocationedgescombinetoformlargeprox-imitygraphs,networkstructuresthatattesttophysicalinteractionsbetweendevices.Sinceghostriderscannotphysicallyinteractwithrealdevices,theycannotformdirectedgeswithrealdevices,onlyindirectlythroughasmallnumberofrealdevicesoperatedbytheattacker.Thus,theedgesbetweenanattackerandtherestofthenetworkarelimitedbythenumberofrealphysicaldevicesshehas,regardlessofhowmanyghostridersareunderhercontrol.Thisreducestheproblemofdetectingghostriderstoacommunityde-tectionproblemontheproximitygraph(Thegraphisseededbyasmallnumberoftrustedinfrastructurelocations).Ourpaperincludesthesekeycontributions:WeexplorelimitsandimpactsofsingledeviceattacksonWaze,e.g.,articialcongestionandevents.Wedescribetechniquestocreatelight-weightghostriders,virtualvehiclesemulatedbyclient-sidescripts,throughre-verseengineeringoftheWazeapp'scommunicationprotocolwiththeserver.WeidentifyanewprivacyattackthatallowsghostriderstovirtuallyfollowandtrackindividualWazeusersinreal-time,anddescribetechniquestoproduceprecise,robustlocationupdates.Weproposeandevaluatedefensesagainstghostriders,us-ingproximitygraphsconstructedwithedgesrepresentingau-thenticatedcollocationeventsbetweenpairsofdevices.Sincecollocationcanonlyoccurbetweenpairsofphysicaldevices,proximitygraphslimitthenumberofedgesbetweenrealde-vicesandghostriders,thusisolatinggroupsofghostridersandmakingthemdetectableusingcommunitydetectional-gorithms.2.WAZEBACKGROUNDWazeisthemostpopularcrowdsourcednavigationapponsmart-phones,withmorethan50millionuserswhenitwasacquiredbyGoogleinJune2013[19].WazecollectsGPSvaluesofusers'de-vicestoestimatereal-timetrafc.Italsoallowsuserstoreporton-roadeventssuchasaccidents,roadclosuresandpolicevehicles,aswellascuratingpointsofinterest,editingroads,andevenupdatinglocalfuelprices.Somefeatures,e.g.,userreportedaccidents,havebeenintegratedintoGoogleMaps[20].Here,webrieydescribethekeyfunctionalityinWazeascontextforourwork.TripNavigation.Waze'smainfeatureisassistuserstondthebestroutetotheirdestinationandturn-by-turnnavigation.Wazegeneratesaggregatedreal-timetrafcupdatesusingGPSdatafromitsusers,andoptimizesuserroutesbothduringtripplanningandduringnavigation.Ifandwhentrafccongestionsisdetected,Wazeautomaticallyre-routesuserstowardsanalternative. Figure1:Beforetheattack(left),Wazeshowsthefastestroutefortheuser.Aftertheattack(right),theusergetsautomaticallyre-routedbythefaketrafcjam.CrowdsourcedUserReports.Wazeuserscangeneratereal-timeeventreportsontheirroutestoinformothersaboutongoingincidents.Eventsrangefromaccidentstoroadclosures,hazards,andevenpolicespeedtraps.Eachreportcanincludeashortnotewithaphoto.Theeventshowsuponthemapofusersdrivingtowardsthereportedlocation.Asusersgetclose,Wazepopsupawindowtolettheuser“saythanks,”orreporttheeventis“notthere.”Ifmultipleuserschoose“notthere”,theeventwillbere-moved.Wazealsomergesmultiplereportsofthesameeventtypeatthesamelocationintoasingleevent.SocialFunction.Toincreaseuserengagement,Wazesup-portssimplesocialinteractions.Userscanseeavatarsandloca-tionsofnearbyusers.Clickingonauser'savatarshowsmorede-taileduserinformation,includingnickname,ranking,andtravelingspeed.Also,userscansendmessagesandchatwithnearbyusers.Thissocialfunctiongivesusersthesenseofalargecommunity.Userscanelevatetheirrankingsinthecommunitybycontributingandreceiving“thanks”fromothers.3.ATTACKINGCROWDSOURCEDMAPSInthissection,wedescribebasicattackstomanipulateWazebygeneratingfalseroadeventsandfaketrafccongestion.SinceWazereliesonreal-timedatafortripplanningandrouteselec-tion,theseattackscaninuenceuser'sroutingdecisions.Attackerscanattackspecicusersbyforgingcongestiontoforceautomaticreroutingontheirtrips.TheattackispossiblebecauseWazehasnoreliableauthenticationonuserreporteddata,suchastheirdeviceGPS.Werstdiscussexperimentalethicsandstepswetooktolimitimpactonrealusers.Then,wedescribebasicmechanismsandresourcesneededtolaunchattacks,andusecontrolledexperimentsontwoattackstounderstandtheirfeasibilityandlimits.Oneattackcreatesfakeroadeventsatarbitrarylocations,andtheotherseekstogeneratearticialtrafchotspotstoinuenceuserrouting.3.1EthicsOurexperimentsseektounderstandthefeasibilityandlimitsofpracticalattacksoncrowdsourcingmapslikeWaze.WeareveryawareofthepotentialimpacttorealWazeusersfromanyexper-iments.WeconsultedourlocalIRBandhavetakenallpossibleprecautionstoensurethatourexperimentsdonotnega

3 tivelyim-pactrealWazeusers.Inparticular,
tivelyim-pactrealWazeusers.Inparticular,wechooseexperimentlocations 0 5 10 15 20 25 30 1:4 1:3 1:2 1:1 2:1 3:1 4:1 Traffic Speed (mph)Ratio of Slow Cars to Fast CarsAverage Predicted Waze (a)Highway 0 4 8 12 16 1:4 1:3 1:2 1:1 2:1 3:1 4:1 Traffic Speed (mph)Ratio of Slow Cars to Fast CarsAverage Predicted Waze (b)LocalRoad 0 3 6 9 12 1:4 1:3 1:2 1:1 2:1 3:1 4:1 Traffic Speed (mph)Ratio of Slow Cars to Fast CarsAverage Predicted Waze (c)ResidentialFigure2:Thetrafcspeedoftheroadwithrespecttodifferentcombinationsofnumberofslowcarsandfastcars.WeshowthatWazeisnotusingtheaveragespeedofallcars,andourinferredfunctioncancorrectlypredictthetrafcspeeddisplayedonWaze.whereuserpopulationdensityisextremelylow(unoccupiedroads),andonlyperformexperimentsatlow-trafchours,e.g.,between2amand5am.Duringtheexperiments,wecontinuouslyscantheentireexperimentregionandneighboringareas,toensurenootherWazeusers(exceptourownaccounts)arewithinmilesofthetestarea.IfanyWazeusersaredetected,weimmediatelyterminateallrunningexperiments.OurstudyreceivedtheIRBapprovalunderprotocol#COMS-ZH-YA-010-7N.Ourworkisfurthermotivatedbyourviewoftherisksofinac-tionversusrisksposedtousersbyourstudy.Ononehand,wecanandhaveminimizedrisktoWazeusersduringourstudy,andwebelieveourexperimentshavenotaffectedanyWazeusers.Ontheotherhand,webelievetherisktomillionsofWazeusersfrompervasivelocationtracking(describedinSection5)isrealisticandpotentiallyverydamaging.Wefeelthatinvestigatingtheseattacksandidentifyingtheseriskstothebroadcommunityatlargewastheethicallycorrectcourseofaction.Furthermore,fullunderstandingoftheattackswasnecessarytodesignaneffectiveandpracticaldefense.PleaseseeAppendixAformoredetailedinformationonourIRBapprovalandstepstakentowardsresponsibledisclosure.3.2BasicAttack:GeneratingFakeEventsLaunchingattacksagainstcrowdsourcedmapslikeWazerequiresthreesteps:automateinputtomobiledevicesthatruntheWazeapp;controlthedeviceGPSandsimulatedevicemovements(e.g.,cardriving);obtainaccesstomultipledevices.Allthreeareeasilyachievedusingwidelyavailablemobiledeviceemulators.MostmobileemulatorsrunafullOS(e.g.,Android,iOS)downtothekernellevel,andsimulatehardwarefeaturessuchascam-era,SDCardandGPS.WechoosetheGenyMotionAndroidem-ulator[3]foritsperformanceandreliability.Attackerscanau-tomaticallycontroltheGenyMotionemulatorviaMonkeyrunnerscripts[4].Theycangenerateuseractionssuchasclickingbut-tonsandtypingtext,andfeedpre-designedGPSsequencestotheemulator(throughacommandlineinterface)tosimulatelocationpositioninganddevicemovement.BycontrollingthetimingoftheGPSupdates,theycansimulateany“movementspeed”ofthesim-ulateddevices.Usingthesetools,attackerscangeneratefakeevents(oralerts)atagivenlocationbysettingfakeGPSontheirvirtualdevices.ThisincludesanyeventssupportedbyWaze,includingaccidents,po-lice,hazards,androadclosures.Wendthatasingleemulatorcangenerateanyeventatarbitrarylocationsonthemap.Wevalidatethisusingexperimentsonavarietyofunoccupiedroads,includ-inghighways,localandruralroads(50+locations,3repeatedtestseach).NotethatourexperimentsonlyinvolvedataintheWazesystem,anddonotaffectrealroadvehiclesnotrunningtheWazeapp.Thus“unoccupied”meansnovehiclesontheroadwithmo-biledevicesactivelyrunningtheWazeapp.Aftercreation,thefakeeventstaysonthemapforabout30minutes.AnyWazeusercanreportthataneventwas“notthere.”Wendittakestwoconsec-utive“nottheres”(withoutany“thanks”inbetween)todeletetheevent.Thusanattackercanensureaneventpersistsbyoccasion-ally“driving”othervirtualdevicestotheregionand“thanking”theoriginalattackerfortheeventreport.3.3CongestionandTrafcRoutingAmoreseriousattacktargetsWaze'sreal-timetriproutingfunc-tion.SincerouteselectioninWazereliesonpredictedtriptime,attackerscaninuenceroutesbycreating“fake”trafchotspotsatspeciclocations.Thiscanbedonebyconguringagroupofvir-tualvehiclestotravelslowlyonachosenroadsegment.Weusecontrolledexperimentstoanswertwoquestions.First,underwhatconditionscanattackerssuccessfullycreatetrafchotspots?Second,howlongcananarticialtrafchotspotlast?Weselectthreelow-trafcroadsinthestateofTexasthatarerepresentativeofthreepopularroadtypesbasedontheirspeedlimit—Highway(65mph),Local(45mph)andResidential(25mph).Toavoidrealusers,wechooseroadsinlowpopulationruralareas,andruntestsathourswiththelowesttrafcvolumes(usually3-5AM).Wecon-stantlyscanforrealusersinornearbytheexperimentalregion,andreset/terminateexperimentsifuserscomeclosetoanareawithon-goingexperiments.Acrossallourexperiments,only2testswereterminatedduetodetectedpresenceofrealusersnearby.Finally,wehaveexamineddifferentroadtypesandhoursofthedaytoen-suretheydonotintroducebiasintoourresults.CreatingTrafcHotspots.Ourexperimentshowsthatitonlytakesoneslowmovingcartocreateatrafccongestion,whentherearenorealWazeusersaround.Wazedisplaysaredoverlayontheroadtoindicatetrafccongestion(Figure1,right).Differentroadtypeshavedifferentcongestionthresholds,withthresholdsstronglycorrelatedtothespeedlimit.ThecongestionthresholdsforHigh-way,LocalandResidentialroadsare40mph,20mphand15mph,respectively.Tounderstandifthisisgeneralizable,werepeatourtestsonotherunoccupiedroadsindifferentstatesandcountries.Wepicked18roadsinvestatesintheUS(CO,MO,NM,UT,MS)andBritishColumbia,Canada.Ineachregion,weselectthreeroadswithdif-ferentspeedlimits(highway,lo

4 calandresidential).Wendcon-sistentresul
calandresidential).Wendcon-sistentresults:asinglevirtualvehiclecanalwaysgenerateatrafchotspot;andthecongestionthresholdswereconsistentacrossdif-ferentroadsofthesamespeedlimit.OutvotingRealUsers.GeneratingtrafchotspotinpracticalscenariosfacesachallengefromrealWazeuserswhodriveatnor-mal(non-congested)speeds:attacker'svirtualvehiclesmust“con-vince”theserverthere'sastreamofslowspeedtrafcontheroad 0 10 20 30 40 50 60 0 10 20 30 40 50 Traffic Speed (mph)Time (minute)Highway Local Residential Figure3:Long-lasttrafcjamcreatedbyslowcarsdriving-by.evenasrealuserstelltheserverotherwise.WeneedtounderstandhowWazeaggregatedmultipleinputstoestimatetrafcspeed.WeperformanexperimenttoinferthisaggregationfunctionusedbyWaze.Wecreatetwogroupsofvirtualvehicles:Nsslow-drivingcarswithspeedSs,andNffast-drivingcarswithspeedSf;andtheyallpassthetargetlocationatthesametime.WestudythecongestionreportedbyWazetoinfertheaggregationfunction.Notethattheserver-estimatedtrafcspeedisvisibleonthemaponlyifweformedatrafchotspot.Weachievethisbysettingthespeedtuple(Ss,Sf)to(10mph,30mph)forHighway,(5,15)forLocaland(5,10)forResidential.AsshowninFigure2,whenwevarytheratioofslowcarsoverfastcars(NsNf),theWazeserverproducesdifferentnaltrafcspeeds.WeobservethatWazedoesnotsimplycomputean“av-erage”speedoverallthecars.Instead,itusesaweightedaveragewithhigherweightonthemajoritycars'speed.Weinferanaggre-gationfunctionasfollows:SwazeSmax
max(Ns;Nf)+Savg
min(Ns;Nf) NsNfwhereSavgSsNsSfNf NsNf,andSmaxisthespeedofthegroupwithNmaxcars.AsshowninFigure2,ourfunctioncanpredictWaze'saggregatetrafcspeedaccurately,foralldifferenttypesofroadsinourtest.Forvalidationpurposes,werunanothersetofexperimentsbyraisingSfabovethehotspotthresholds(65mph,30mphand20mphrespectivelyforthethreeroads).Wecanstillformtrafchotspotsbyusingmoreslow-drivingcars(Ns�Nf),andourfunctioncanstillpredictthetrafcspeedonWazeaccu-rately.Long-LastingTrafcCongestion.Atrafchotspotwilllastfor25-30minutesifnoothercarsdriveby.Onceaggregatespeednor-malizes,thecongestioneventisdismissedwithin2-5minutes.Tocreatealong-lastingvirtualtrafcjam,attackerscansimplykeepsendingslow-drivingcarstothecongestionareatoresisttheinputfromrealusers.Wevalidatethisusingasimple,50-minutelongexperimentwhere3virtualvehiclescreateapersistentcongestionbydrivingslowlythroughanarea,andthenloopingbackevery10minutes.Meanwhile,2othervirtualcarsemulatelegitimatedriversthatpassbyathighspeedevery10minutes.AsshowninFigure3,thetrafchotspotpersistsfortheentireexperimentperiod.ImpactonEndUsers.Wazeusesreal-timetrafcdatatoop-timizeroutesduringtripplanning.Wazeestimatestheend-to-endtriptimeandrecommendsthefastestroute.Onceontheroad,Wazecontinuouslyestimatesthetraveltime,andautomaticallyreroutesifthecurrentroutebecomescongested.Anattackercanlaunchphysicalattacksbyplacingfaketrafchotspotsontheuser'sorigi-nalroute.Whilecongestionalonedoesnottriggerrerouting,Wazereroutestheusertoadetourwhentheestimatedtraveltimethroughthedetourisshorterthanthecurrentcongestedroute(seeFigure1). HTTPS Plain Text Waze ClientHTTPS ProxyWaze Server HTTPS Controlled By Attacker Figure4:UsingaHTTPSproxyasman-in-the-middletointer-cepttrafcbetweenWazeclientandserver.WealsonotethatWazedataisusedbyGoogleMaps,andthere-forecanpotentiallyimpacttheir1+billionusers[36].Ourex-perimentshowsthatarticialcongestiondonotappearonGoogleMaps,butfakeeventsgeneratedonWazearedisplayedonGoogleMapswithoutverication,including“accidents”,“construction”and“objectsonroad”.Finally,eventupdatesaresynchronizedonbothservices,witha2-minutedelayandpersistforasimilarperiodoftime(e.g.,30minutes).4.SYBILATTACKSSofar,wehaveshownthatattackersusingemulatorscancre-ate“virtualvehicles”thatmanipulatetheWazemap.Anattackercangeneratemuchhigherimpactusingalargegroupofvirtualve-hicles(orSybils[16])undercontrol.Inthissection,wedescribetechniquestoproducelight-weightvirtualvehiclesinWaze,andexplorethescalabilityofthegroup-basedattacks.Werefertolargegroupsofvirtualvehiclesas“ghostriders”fortworeasons.First,theyareeasytocreateenmasse,andcantravelinpackstooutvoterealuserstogeneratemorecomplexevents,e.g.,persistenttrafccongestion.Second,asweshowin§5,theycanmakethemselvesinvisibletonearbyvehicles.FactorsLimitingSybilCreation.Westartbylookingatthelimitsofthelarge-scaleSybilattacksonWaze.First,wenoteuseraccountsdonotposeachallengetoattackers,sinceaccountregis-trationcanbefullyautomated.Wefoundthatasingle-threadedMonkeyrunnerscriptcouldautomaticallyregister1000newac-countsinaday.EventhoughthelatestversionofWazeappre-quiresSMSvericationtoregisteraccounts,attackerscanuseolderversionsofAPIstocreateaccountswithoutverication.Alterna-tively,accountscanbeveriedthroughdisposablephone/SMSser-vices[44].Thelimitingfactoristhescalabilityofvehicleemulation.EventhoughemulatorslikeGenyMotionarerelativelylightweight,eachinstancestilltakessignicantcomputationalresources.Forexam-ple,aMacBookProwith8GofRAMsupportsonly10simulta-neousemulatorinstances.Forthis,weexploreamorescalableapproachtoclientemulationthatcanincreasethenumberofsup-portedvirtualvehiclesbyordersofmagnitude.Specically,wereverseengineerthecommunicationAPIsusedbytheapp,andre-placeemulatorswithsimplePythonscriptsthatmimicAPIcalls.ReverseEngineeringWazeAPIs.TheWazeappusesHTTPStoc

5 ommunicatewiththeserver,soAPIdetailscann
ommunicatewiththeserver,soAPIdetailscannotbedirectlyobservedbycapturingnetworktrafc(TLS/SSLencrypted).How-ever,anattackercanstillinterceptHTTPStrafc,bysettingupaproxy[2]betweenherphoneandWazeserverasaman-in-the-middleattack[40,9].AsshowninFigure4,anattackerneedstopre-installtheproxyserver'srootCerticateAuthorities(CA)toherownphoneasa“trustedCA.”Thisallowstheproxytopresentself-signedcerticatestothephoneclaimingtobetheWazeserver.TheWazeapponthephonewilltrusttheproxy(sincethecerticate issignedbya“trustedCA”),andestablishHTTPSconnectionswiththeproxyusingproxy'spublickey.Ontheproxyside,theattackercandecryptthetrafcusingproxy'sprivatekey,andthenforwardtrafcfromthephonetoWazeserverthroughaseparateTLS/SSLchannel.TheproxythenobservestrafctotheWazeserversandextractstheAPIcallsfromplaintexttrafc.HidingAPIcallsusingtrafcencryptionisfundamentallychal-lenging,becausetheattackerhascontrolovermostofthecom-ponentsinthecommunicationprocess,includingphone,theappbinary,andtheproxy.Aknowncountermeasureiscerticatepin-ning[18],whichembedsacopyoftheservercerticatewithintheapp.WhentheappmakesHTTPSrequests,itvalidatestheserver-providedcerticatewithitsknowncopybeforeestablishingcon-nections.However,dedicatedattackerscanextractandreplacetheembeddedcerticatebydisassemblingtheappbinaryorattachingtheapptoadebugger[35,17].ScalabilityofGhostRiders.WiththeknowledgeofWazeAPIs,webuildextremelylightweightWazeclientsusingpythonscripts,allocatingonethreadforeachclient.Withineachthread,welogintotheappusingaseparateaccount,andmaintainalivesessionbysendingperiodicGPScoordinatestotheWazeserver.ThePythonclientisafullWazeclient,andcanreportfakeeventsusingtheAPI.Scriptedemulationishighlyscalable.Werun1000virtualvehiclesonasingleLinuxDellPowerEdgeServer(QuadCore,2GBRAM),andndthatatsteadystate,1000virtualdevicesonlyintroducesasmalloverhead:11%ofmemoryusage,2%ofCPUand420Kbpsbandwidth.Inpractice,attackerscaneasilyruntensofthousandsofvirtualdevicesonacommodityserver.Finally,weexperimentallyconrmthepracticalefcacyandscal-abilityofghostriders.WechoseasecludedhighwayinruralTexas,andused1000virtualvehicles(hostedonasingleserverandsingleIP)togenerateahighlycongestedtrafchotspot.WeperformourexperimentinthemiddleofthenightafterrepeatedscansshowednoWazeuserswithinmilesofourtestarea.Wepositioned1000ghostridersoneafteranother,anddrovethemslowlyat15mphalongthehighway,loopingthembackevery15minutesforanen-tirehour.ThecongestionshowsuponWaze5minutesafterourtestbegan,andstayedonthemapduringtheentiretestperiod.Noproblemswereobservedduringourtest,andteststogeneratefakeevents(accidentsetc.)alsosucceeded.5.USERTRACKINGATTACKNext,wedescribeapowerfulnewattackonuserprivacy,wherevirtualvehiclescantrackWazeuserscontinuouslywithoutrisk-ingdetectionthemselves.ByexploitingakeysocialfunctionalityinWaze,attackerscanremotelyfollow(orstalk)anyindividualuserinrealtime.Thisispossiblewithsingledeviceemulation,butgreatlyampliedwiththehelpoflargegroupsofghostriders,possiblytrackinglargeuserpopulationssimultaneouslyandputtinguser(location)privacyatgreatrisk.Westartbyexaminingthefea-sibility(andkeyenablers)ofthisattack.Wethenpresentasimplebuthighlyeffectivetrackingalgorithmthatfollowsindividualusersinrealtime,whichwehavevalidatedusingreallifeexperiments(withourselvesasthetargets).TheonlywayforWazeuserstoavoidtrackingistogo“invisible”inWaze.However,doingsoforfeitstheabilitytogeneratereportsormessageotherusers.Usersarealsoresetto“visible”eachtimetheWazeappopens.5.1FeasibilityofUserTrackingAkeyfeatureinWazeallowsuserstosocializewithothersontheroad.Eachuserseesonherscreeniconsrepresentingtheloca- 0 500 1000 1500 2000 2500 3000 0 100 200 300 400 Total # of Unique Users# of Queries24x32 mile2 12x16 mile2 6x8 mile2 3x4 mile2 Figure5:#ofqueriesvs.uniquereturnedusersinthearea. 0 10 20 30 40 50 10 20 30 40 50 User Count# of Times for a User being ReturnedServer-1 Server-2 Server-3 Server-4 Figure6:User'snumberofappearancesinthereturnedresults(68mile2area).tionsofnearbyusers,andcanchatormessagewiththemthroughtheapp.Leveragingthisfeature,anattackercanpinpointanytar-getwhohastheWazeapprunningonherphone.Byconstantly“refreshing”theappscreen(issuinganupdatequerytotheserver),anattackercanquerythevictim'sGPSlocationfromWazeinrealtime.Tounderstandthiscapability,weperformdetailedmeasure-mentsonWazetoevaluatetheefciencyandprecisionofusertracking.TrackingviaUserQueries.AWazeclientperiodicallyre-questsupdatesinhernearbyarea,byissuinganupdatequerywithitsGPScoordinatesandarectangular“searcharea.”Thissearchareacanbesettoanylocationonthemap,anddoesnotdependontherequester'sownlocation.Theserverreturnsalistofuserslocatedinthearea,includinguserID,nickname,accountcreationtime,GPScoordinatesandtheGPStimestamp.Thusanattackercanndand“follow”atargetuserbyrstlocatingthematanygivenlocation(work,home)andthencontinuouslyfollowingthembyissuingupdatequeriescenteredonthetargetvehiclelocation,allautomatedbyscripts.OvercomingDownsampling.Theuserqueryapproachfacesadownsamplingchallenge,becauseWazerespondstoeachquerywithan“incomplete”setofusers,i.e.,upto20usersperqueryregardlessofthesearchareasize.Thisdownsampledresultisnec-essarytopreventoodingtheappscreenwithtoomanyusericons,butitalsolimitsanattacker'sabilitytofollowamovingtarg

6 et.Thisdownsamplingcanbeovercomebysimply
et.Thisdownsamplingcanbeovercomebysimplyrepeatedlyquery-ingthesystemuntilthetargetisfound.Weperformquerymea-surementsonfourtestareas(ofdifferentsizesbetween34mile2and2432mile2)inthedowntownareaofLosAngeles(CityA,with10millionresidentsasof2015).Foreacharea,weissue400querieswithin10seconds,andexaminethenumberofuniqueusersreturnedbyallthequeries.ResultsinFigure5showthatthenumberofuniqueusersreportedconvergesafter150-250queriesforthethreesmallsearchareas(1216mile2).Fortheareaofsize2432mile2,morethan400queriesarerequiredtoreachconvergence.Weconrmthis“downsampling”isuniformlyrandom,bycom-paringourmeasurementresultstoamathematicalmodelthatprojectsthestatisticsofqueryresultsassuminguniform-randomsampling. Location RouteLength(Mile) TravelTime(Minute) GPSSentByVictim GPSCapturedbyAttacker FollowedtoDestination? Avg.TrackDelay(Second) WazeUserDensity(#ofUsers/mile2) CityA 12.8 35 18 16 Yes 43.79 56.6 HighwayB 36.6 40 20 19 Yes 9.24 2.8 Table1:TrackingExperimentResults.ConsidertotalMusersinthesearcharea.Theprobabilityofauserxgettingsampledinasingleroundofquery(20usersperquery)isP(x)=20 M.OverNqueries,thenumberofappearancesperusershouldfollowaBinomialDistribution[25]withmeanN
20 M.Figure6plotsthemeasureduserappearancesforthefourserversonthe68mile2areawithN=100.Themeasuredstatisticsfol-lowtheprojectedBinomialDistribution(themeasuredmeanvaluescloselymatchthetheoreticalexpectation).Thisconrmsthatthedownsamplingisindeedrandom,andthusanattackercanrecovera(near)completesetofWazeuserswithrepeatedqueries.Whilethenumberofqueriesrequiredincreasessuperlinearlywithareasize,acomplementarytechniqueistodivideanareaintosmaller,xedsizepartitionsandqueryeachpartition'susersinparallel.WealsoobservethatuserlistsreturnedbydifferentWazeservershadonlyapartialoverlap(roughly20%ofusersfromeachserverwereuniquetothatserver).This“inconsistency”acrossserversiscausedbysynchronizationdelayamongtheservers.EachuseronlysendsitsGPScoordinatestoasingleserverwhichtakes2-5minutestopropagatetootherservers.Therefore,acompleteusersetrequiresqueriestocoverallWazeservers.Atthetimeofourexperiments,thenumberofWazeserverscouldbetracedthroughapptrafcandcouldbecoveredbyamoderatenumberofqueryingaccounts.TrackingUsersoverTime.OuranalysisfoundthateachactiveWazeappupdatesitsGPScoordinatestotheserverevery2min-utes,regardlessofwhethertheuserismobileorstationary.Evenwhenrunninginthebackground,theWazeappreportsGPSvaluesevery5minutes.AslongastheWazeappisopen(evenrunninginthebackground),theuser'slocationiscontinuouslyreportedtoWazeandpotentialattackers.Clearly,amoreconservativeap-proachtomanaginglocationdatawouldbeextremelyhelpfulhere.Wenotethatattackerscanperformlong-termtrackingonatargetuser(e.g.,overmonths).TheattackerneedsapersistentIDassoci-atedtothetarget.The“userID”eldinthemetadataisinsufcient,becauseitisarandom“session”IDassigneduponuserloginandisreleasedwhentheuserkillstheapp.However,the“accountcre-ationtime”canserveasapersistentID,becausea)itremainsthesameacrosstheuser'sdifferentloginsessions,andb)itisprecisedowntothesecond,andissufcientlytouniquelyidentifysingleusersinthesamegeographicarea.WhileWazecanremovethe“ac-countcreationtime”eldfrommetadata,apersistentattackercanovercomethisbyanalyzingthevictim'smobilitypattern.Forex-ample,theattackercanidentifyasetoflocationswherethevictimhasvisitedfrequentlyorstayedduringthepastsession,mappingtohomeorworkplace.Thentheattackercanassignaghostridertoconstantlymonitorthoseareas,andre-identifythetargetoncehericonshowsupinamonitoredlocation,e.g.,home.StealthMode.Wenotethatattackersremaininvisibletotheirtargets,becausequeriesonanyspecicgeographicareacanbedonebySybilsoperating“remotely,”i.e.claimingtobeinadif-ferentcity,stateorcountry.Attackerscanenabletheir“invisible”optiontohidefromothernearbyusers.Finally,disablingthesefeaturesstilldoesnotmaketheattackervisible.Wazeonlyupdateseachuser's“nearby”screenevery2minutes(whilesendingitsown Start End Missed by Attacker Figure7:AgraphicalviewofthetrackingresultinLosAngelesdowntown(CityA).BluedotsareGPSpointscapturedbytheattackerandthereddotsarethosemissedbytheattacker.GPSupdatetotheservers).Thusatrackercan“popinto”thetar-get'sregion,queryforthetarget,andthenmoveoutofthetarget'sobservablerange,allbeforethetargetcanupdateanddetectit.5.2Real-timeIndividualUserTrackingTobuildadetailedtraceofatargetuser'smovements,anattackerrstbootstrapsbyidentifyingthetarget'sicononthemap.Thiscanbedonebyidentifyingthetarget'siconwhileconrmingherphysicalpresenceatatimeandlocation.Theattackercentersitssearchareaonthevictim'slocation,andissuesalargenumberofqueries(usingSybilaccounts)untilitcapturesthenextGPSreportfromthetarget.Ifthetargetismoving,theattackermovesthesearchareaalongthetarget'sdirectionofmovementandrepeatstheprocesstogetupdates.Experiments.Toevaluateitseffectiveness,weperformedex-perimentsbytrackingoneofourownAndroidsmartphonesandoneofourvirtualdevices.Trackingwaseffectiveinbothcases,butweexperimentedmorewithtrackingourvirtualdevice,sincewecouldhaveittraveltoanylocation.UsingtheOSRMtool[5],wegeneratedetailedGPStracesoftwodrivingtrips,oneindowntownareaofLosAngeles(CityA),andonealongtheinterstatehighway-101(HighwayB).ThetargetdeviceusesarealisticdrivingspeedbasedonaveragetrafcspeedsestimatedbyGoogleMapsduringtheexperiment.

7 Theattackerused20virtualdevicestoqueryWa
Theattackerused20virtualdevicestoqueryWazesimultaneouslyinarectangularsearchareaofsize68mile2.ThisshouldbesufcienttotracktheGPSupdateofafast-drivingcar(upto160mph).Bothexperimentswereduringmorninghours,andweloggedboththenetworktrafcofthetargetphoneandquerydataretrievedbytheattacker.Notethatwedidnotgen-erateany“events”orotherwiseaffecttheWazesysteminthisex-periment.Results.Table1liststheresultsoftrackingourvirtualdevice,andFigure7presentsagraphicalviewoftheCityAresult.Forbothroutes,theattackercanconsistentlyfollowthevictimtoherdestination,thoughtheattackerfailstocapture1-2GPSpointsoutofthe18-20reported.ForCityA,thetrackingdelay,i.e.,thetimespenttocapturethesubsequentGPSofthevictim,islarger(aver-aging43sratherthan9s).ThisisbecausethedowntownareahasahigherWazeuserdensity,andrequiredmoreroundsofqueriestolocatethetarget.Ourexperimentsrepresenttwohighlychallenging(i.e.,worstcase)scenariosfortheattacker.ThehighdensityofWazeusers inCityAdowntownismakesitchallengingtolocateatargetinrealtimewithdownsampling.OnHighwayB,thetargettravelsatahighspeed(60mph),puttingastringenttimelimitonthetrackinglatency,i.e.,theattackermustcapturethetargetbeforeheleavesthesearcharea.Thesuccessofbothexperimentsconrmstheeffectivenessandpracticalityoftheproposedattack.6.DEFENSESInthissection,weproposedefensemechanismstosignicantlylimitthemagnitudeandimpactoftheseattacks.Whileindividualdevicescaninictlimiteddamage,anattacker'sabilitytocontrolalargenumberofvirtualvehiclesatlowcostelevatestheseverityoftheattackinbothquantityandquality.Ourpriority,then,istorestrictthenumberofghostridersavailabletoeachattacker,thusincreasingthecostper“vehicle”andreducingpotentialdamage.Themostintuitiveapproachisperformstronglocationauthen-tication,sothatattackersmustuserealdevicesphysicallylocatedattheactuallocationsreported.Thiswouldmakeghostridersasexpensivetooperateasrealdevices.Unfortunately,existingmeth-odsforlocationauthenticationdonotextendwelltoourcontext.Someproposalssolelyrelyontrustedinfrastructures(e.g.,wirelessaccesspoints)toverifythephysicalpresenceofdevicesincloseproximity[30,37].However,thisrequireslargescaleretrottingofcellularcelltowersorinstallationofnewhardware,neitherofwhichispracticalatlargegeographicscales.Othersproposetoembedtamperprooflocationhardwareonmobiledevices[32,38],whichincurshighcostperuser,andisonlyeffectiveifenforcedacrossalldevices.Forourpurposes,weneedascalableapproachthatworkswithcurrenthardware,withoutincurringcostsonmo-bileusersorthemapservice(Waze).6.1SybilDetectionviaProximityGraphInsteadofoptimizingper-devicelocationauthentication,ourpro-poseddefenseisaSybildetectionmechanismbasedonthenovelconceptofproximitygraph.Specically,weleveragephysicalprox-imitybetweenrealdevicestocreatecollocationedges,whichactassecureattestationsofsharedphysicalpresence.Inaproximitygraph,nodesareWazedevices(uniquelyidentiedbyanaccountusernameandpasswordontheserverside).Theyperformsecurepeer-to-peerlocationauthenticationwiththeWazeapprunninginthebackground.Anedgeisestablishediftheproximityauthenti-cationissuccessful.BecauseSybildevicesarescriptedsoftware,theyarehighlyun-likelytocomeintophysicalproximitywithrealdevices.ASybildevicecanonlyformcollocationedgeswithotherSybildevices(withcoordinationbytheattacker)ortheattacker'sownphysi-caldevices.Theresultinggraphshouldhaveonlyveryfew(orno)edgesbetweenvirtualdevicesandrealusers(otherthantheattacker).LeveragingpriorworkonSybildetectioninsocialnet-works,groupsofSybilscanbecharacterizedbythefew“attackedges”connectingthemtotherestofthegraph,makingthemiden-tiablethroughcommunity-detectionalgorithms[47].Weuseaverysmallnumberoftrustednodesonlytobootstraptrustinthegraph.Weassumeasmallnumberofinfrastructureac-cesspointsareknowntoWazeservers,e.g.,hotelsandpublicWiFinetworksassociatedwithphysicallocationsstoredinIP-locationdatabases(usedforgeolocationbyAppleandGoogle).WazealsocanworkwithmerchantsthatownpublicWiFiaccesspoints(e.g.,Starbucks).Theseinfrastructuresaretrustednodes(weassumetrustednodesdon'tcolludewithattackers).AnyWazedevicethatcommunicateswiththeWazeserverundertheirIPs(andreportsaGPSlocationconsistentwiththeIP)automaticallycreatesanewcollocationedgetothetrustednode.OurSybildefensecontainstwokeysteps.First,webuildaprox-imitygraphbasedonthe“encounters”betweenWazeusers(§6.2).Second,wedetectSybilsbasedonthetrustpropagationinproxim-itygraph(§6.3).6.2Peer-basedProximityAuthenticationTobuildtheproximitygraph,werstneedareliablemethodtoverifythephysicalcollocationofmobiledevices.WecannotrelyonGPSreportssinceattackerscanforgearbitraryGPScoordinates,orBluetoothbaseddeviceranging[55]becausethecoverageistooshort(10meters)forvehicles.Instead,weconsiderachallenge-basedproximityauthenticationmethod,whichleveragesthelim-itedtransmissionrangeofWiFiradios.WiFiTetheringChallenge.Weusethesmartphone'sWiFiradiotoimplementaproximitychallengebetweentwoWazede-vices.BecauseWiFiradioshavelimitedranges(250metersfor802.11n[45])),twoWazedevicesmustbeinphysicalproximitytocompletethechallenge.Specically,we(ortheWazeserver)in-structonedevicetoenableWiFitetheringandbroadcastbeaconswithanSSIDprovidedbytheWazeserver,i.e.,arandomlygen-erated,time-varyingbitstring.Thisbitstringcannotbeforgedbyotherusersorusedtore-identifyaparticularuser.Thesecondde-viceprovesit

8 sproximitytotherstdevicebyreturningtheS
sproximitytotherstdevicebyreturningtheSSIDvalueheardovertheairtotheWazeserver.ThekeyconcernsofthisapproacharewhethertheWiFilinkbetweentwovehiclesisstable/strongenoughtocompletethechal-lenge,andwhethertheseparationdistanceislongenoughforourneeds.Thisconcernisvalidgiventhehighmovingspeed,poten-tialsignalblockagefromvehicles'metalcomponents,andthelowtransmitpowerofsmartphones.Weexploretheseissueswithde-tailedmeasurementsonrealmobiledevices.First,weperformmeasurementsonstationaryvehiclestostudythejointeffectofblockageandlimitedmobiletransmitpower.WeputtwoAndroidphonesintotwocars(withwindowsanddoorsclosed),onerunningWiFitetheringtobroadcastbeaconsandtheotherscanningforbeacons.Figure8plotstheWiFibeaconstrengthatdifferentseparationdistances.Weseethattheaboveartifactsmakethesignalstrengthdropto-100dBmbeforethedistancereaches250meters.Inthesamegure,wealsoplottheprobabilityofsuccessfulbeacondecoding(thuschallengecompletion)across400attemptswithin2minutes.Itremains100%whenthetwocarsareseparatedby80meters,anddropstozeroat160meters.Next,weperformdrivingexperimentsonahighwayatnormaltrafchoursinthepresenceofothervehicles.Thevehiclestravelatspeedsaveraging65mph.Duringdriving,weareabletovarythedistancebetweenthetwocars,anduserecordedGPSlogstocalculatetheseparationdistance.Figure9showsthatwhileWiFisignalstrengthuctuatesduringourexperiments,theprobabilityofbeacondecodingremainsveryhighat98%whentheseparationislessthan80metersbutdropsto10%oncethetwocarsaremorethan140metersapart.Overall,theresultssuggesttheproposedWiFitetheringchal-lengeisareliablemethodforproximityauthenticationforoursys-tem.Inpractice,Wazecanstartthechallengewhendetectingthetwovehiclesarewithintheeffectiverange,e.g.,80meters.SincetheWiFichannelscanisfast,e.g.,1-2secondstodoafullchan-nelscaninourexperiments,thischallengecanbeaccomplishedquicklywithminimumenergycostonmobiledevices.ItiseasytoimplementthisschemeusingexistingAPIstocontrolWiFiradiotoopentethering(setWifiApEnabledAPIinAndroid).ConstructingProximityGraphs.Inaproximitygraph,eachnodeisaWazedevice,andanedgeindicatesthetwouserscome -100 -90 -80 -70 -60 -50 0 20 40 60 80 100 120 140 160 180 200 0 0.2 0.4 0.6 0.8 1 Signal Strength (dBm)Scan Success RateDistance between Two Devices (m)Scan Success RateSignal Strength Figure8:WiFisignalstrengthandscansuccessratewithre-specttocardistanceinstaticscenarios. -100 -90 -80 -70 -60 -50 0 20 40 60 80 100 120 140 160 180 200 0 0.2 0.4 0.6 0.8 1 Signal Strength (dBm)Scan Success RateDistance between Two Devices (m)Scan Success RateSignal Strength Figure9:WiFisignalstrengthandscansuccessratewithre-specttocardistanceindrivingscenarios.intophysicalproximity,e.g.,80meters,withinapredenedtimewindow.Theresultinggraphisundirectedbutweightedbasedonthenumberoftimesthetwousershaveencountered.UsingweightedgraphmakesitharderforSybilstoblendintothenormaluserregion.Intuitively,realuserswillgetmoreweightsontheiredgesastheyuseWazeovertime.Forattackers,inordertoblendinthegraph,theyneedtobuildmoreweightedattackedgestorealusers(highercosts).Thisapproachshouldnotintroducemuchenergyconsumptiontousers'phones.First,Wazeserverdoesnotneedtotriggercollo-cationauthenticationeverytimetwousersareincloseproximity.Instead,theproximitygraphwillbebuiltupovertime.Auseronlyneedtoauthenticatewithotherusersoccasionally,sincewecanrequirethatdeviceauthenticationexpiresafteramoderatetimeperiod(e.g.,months)toreducethenetimpactonwirelessperfor-manceandenergyusage.Second,sincetheprocessistriggeredbytheWazeserver,WazecancanuseWiFisensingfromdevicestond“opportunistic”authenticationtimesthatminimizeimpactonperformanceandenergy.Wazecanalsouseonetethertosimultane-ouslyauthenticatemultiplecolocateddeviceswithinanarea.Thisfurtherreducesauthenticationoverhead,andavoidsperformanceissueslikewirelessinterferenceinareaswithhighuserdensity.6.3Graph-basedSybilDetectionWeapplygraph-basedSybildetectionalgorithmstodetectSybilsinWazeproximitygraph.Graph-basedSybildetectors[53,52,47,14,10]wereoriginallyproposedinsocialnetworks.TheyallrelyonthekeyassumptionthatSybilshavedifcultytoformedgeswithrealusers,whichresultsinasparsecutbetweentheSybilandnon-Sybilregionsinthesocialgraph.Becauseofthelimitednumberof“attackedges”betweenSybilsandnon-Sybils,arandomwalkfromnon-Sybilregionhasahigherlandingprobabilitytolandonanon-SybilnodethanaSybilnode.Ourproximitygraphholdsthesameassumptionthatthesealgorithmsrequire—withtheWiFiproximityauthentication,it'sdifcultforSybildevices(ghostriders)tobuildattackedgestorealWazeusers.SybilRank.Amongavailablealgorithms,weuseSybilRank[10].Comparedtoitscounterparts(SybilGuard[53],SybilLimit[52]andSybilInfer[14]),SybilRankachieveshigheraccuracyatalowercomputationalcost.Atthehigh-level,itscounterpartsneedtoper-formactualrandomwalks,whichisverycostlyandyetoftengivesincompleteviewsofthegraph.Instead,SybilRankusespoweriter-ation[28]tocomputetherandomwalklandingprobabilityforallnodes.Thissignicantlybooststhealgorithmaccuracyandspeed.Furthermore,SybilRankhasabettertoleranceoncommunitystruc-turesinthenon-Sybilregion(forusingmultipletrustednodes),makingitmoresuitableforreal-worldgraphs.Ascontext,webrieydescribehowSybilRankworksandreferreadersto[10]formoredetails.SybilRankranksthenodesbasedonhowlikelytheyareSybils

9 .Thealgorithmstartswithmulti-pletrustedn
.Thealgorithmstartswithmulti-pletrustednodesinthegraph.Ititerativelycomputesthelandingprobabilityforshortrandomwalks(originatedfromtrustednodes)tolandonallothernodes.Thelandingprobabilityisnormalizedbythenode'sdegree,whichactsasthetrustscoreforranking.Intu-itively,shortrandomwalksfromtrustednodesareveryunlikelytotraversethefewattackedgestoreachSybilnodes,thustherankingscoresofSybilsshouldbelower.ForSybildetection,Wazecansetacutoffthresholdonthetrustscore,andlabelthetailoftherankedlistasSybils.TheoriginalSybilRankworksonunweightedsocialgraphs.Wemodiedittoworkonourweightedproximitygraph:whenanodepropagatestrust(orperformsrandomwalks)toitsneighbors,insteadofsplittingthetrustequally,itdistributesproportionallybasedontheedgeweights.ThisactuallymakesitharderforSybilstoevadeSybilRank—theywillneedtobuildmorehigh-weightat-tackedgestorealuserstoreceivetrust.7.COUNTERMEASUREEVALUATIONWeusesimulationstoevaluatetheeffectivenessofourproposeddefense.Wefocusonevaluatingthefeasibilityandcostforattack-erstomaintainalargenumberofSybilsaftertheSybildetectionisinplace.WequantifythecostbythenumberofattackedgesaSybilmustestablishwithrealusers.Inpractice,thistranslatesintotheefforttakentophysicallydrivearoundandusephysicaldevices(withWiFiradios)perSybiltocompleteproximityauthentication.Inthefollowing,werstdescribeoursimulationsetup,andthenpresentthekeyndingsandtheirimplicationsonWaze.7.1EvaluationSetupWerstdiscusshowweconstructasyntheticproximitygraphforourevaluation,followedbythecounterstrategiestakenbyattackerstoevadedetection.Finally,wedescribetheevaluationmetricsforSybildetection.SimulatingProximityGraphs.Weusewell-knownmodelsonhumanencounteringtocreatesyntheticproximitygraphs.Thisisbecause,tothebestofourknowledge,thereisnopublicper-usermobilitydatasetwithsufcientscaleandtemporalcoveragetosup-portourevaluation.Also,directlycrawlinglarge-scale,per-usermobilitytracefromWazecanleadtoquestionableprivacyimplica-tions,andthusweexcludethisoption.Existingliteratures[33,13,43,23,29]allsuggestthathuman(andvehicle)encounterpatternsdisplaystrongscale-freeand“small-world”properties[6].Thuswefollowthemethodologyof[33]tosimulateapower-lawbasedencounterprocessamongWazeusers.GivenauserpopulationN,werstassigneachuseranencounterprobabilityfollowingapower-lawdistribution(2basedontheempiricalvalues[33,12]).Wethensimulateuserencounterover 0 0.2 0.4 0.6 0.8 1 0 10k 20k 30k 40k 50k Area under ROC Curve# of Total Attack EdgesGateway=1 Gateway=100 Gateway=500 Gateway=1000 (a)Sybilinnerconnectionavg.degree=5 0 0.2 0.4 0.6 0.8 1 0 10k 20k 30k 40k 50k Area under ROC Curve# of Total Attack EdgesGateway=1 Gateway=100 Gateway=500 Gateway=1000 (b)Sybilinnerconnectionavg.degree=10Figure10:AUCwithrespecttonumberofattackedges,whereSybilsformpower-lawinnerconnections. 0 0.2 0.4 0.6 0.8 1 1 10 20 30 40 50 Area under ROC Curve# of Trusted NodesGateway=1 Gateway=100 Gateway=500 Gateway=1000 Figure11:Impactof#oftrustednodes(averagedegree=10forSybilregion;5Kattackedges).time,byaddingedgestothegraphbasedonthejointprobabilityofthetwonodes.Forourevaluation,weproduceaproximitygraphforN10000normalusersandusethesnapshotwhen99.9%ofnodesareconnected.Notethatasthegraphgetsdenserovertime,itisharderforSybilstoblendintonormaluserregions.Weusethisgraphtosimulatethelower-boundperformanceofSybildetection.2Asapotentiallimitation,thesimulatedgraphparametersmightbedif-ferentfordifferentcitiesofWaze.Thuswedon'tclaimourreportednumberswillexactlymatchwhatWazeproduces.TheideaisthatWazecanfollowourmethodologytorunthesameexperimentsontheirrealgraphs.AttackerModels.InthepresenceofSybildetection,anattackerwilltrymixingtheirSybilsintotheproximitygraph.Weconsiderthefollowingstrategies:1.Single-Gateway–AnattackerrsttakesoneSybilaccount(asthegateway)tobuildattackedgestonormalusers.ThentheattackerconnectstheremainingSybilstothisgateway.Inpractice,thismeanstheattackeronlyneedstotakeonephysicalphonetogooutandencounternormalusers.2.Multi-Gateways–Anattackerdistributestheattackedgestomultiplegateways,andthenevenlyspreadstheotherSybilsacrossthegateways.ThishelpstheSybilstoblendinwithnormalusers.Theattackerpaysanextracostintermsofusingmultiplerealdevicestobuildattackedges.TheattackeralsobuildsedgesamongitsownSybils.ThisincursnoadditionalcostsinceSybilscaneasilycolludetopassproximityauthentication,butintroduceskeybenets.First,itmakesSybils'degreedistributionappearmorelegitimate.Second,itcanpoten-tiallyincreaseSybils'trustscore:whenarandomwalkreachesoneSybilnode,itsedgestothefellowSybilshelptosustaintheran-domwalkwithintheSybilregion.Inoursimulation,wefollowthescale-freedistributiontoaddedgesamongSybilsmimickingnor-maluserregion(wedidnotuseafullyconnectednetworkbetweenSybilssinceitismoreeasilydetectable).EvaluationMetrics.ToevaluateSybildetectionefcacy,weusethestandardfalsepositive(negative)rate,andtheAreaundertheReceiverOperatingCharacteristiccurve(AUC)usedbySybil-Rank[10].AUCrepresentstheprobabilitythatSybilRankranksarandomSybilnodelowerthanarandomnon-Sybilnode.Itsvaluerangesfrom0to1,where1meanstherankingisperfect(allSybilsarerankedlowerthannon-Sybils),0meanstherankingisalwaysipped,and0.5matchestheresultofrandomguessing.Comparedtofalsepositive(negative)rates,AUCisindependentofthecutoffthreshold,andthuscomp

10 arableacrossexperimentsettings. 2Validat
arableacrossexperimentsettings. 2Validatedbyexperiments:adenser,99.99%connectedgraphcanuniformlyimproveSybildetectionaccuracy.7.2ResultsAccuracyofSybilDetection.Weassumetheattackerseekstoembed1000Sybilsintotheproximitygraph.Weuseeithersingle-ormulti-gatewayapproachestobuildattackedgesontheproxim-itygraphbyconnectingSybilstorandomlychosennormalusers.WethenaddedgesbetweenSybilnodes,followingthepower-lawdistributionandproducinganaverageweighteddegreeofeither5or10(toemulatedifferentSybilsubgraphdensity).Werandomlyselect10trustednodestobootstraptrustforSybilRankandrunitontheproximitygraph.Werepeateachexperiment50times.Figure10showsthattheSybildetectionmechanismishighlyef-fective.Forattackersofthesingle-gatewaymodel,theAUCisverycloseto1(0:983),indicatingWazecanidentifyalmostallSybilsevenaftertheattackerestablishedalargenumberofattackedges,e.g.,50000.Meanwhile,themulti-gatewaymethodhelpsattackersadd“undetected”Sybils,butthenumberofgatewaysrequiredissignicant.Forexample,tomaintain1000Sybils,i.e.,bybringingdownAUCto0.5,theattackerneedsatleast500asgateways.Inpractice,thismeanswardrivingwith500+physicaldevicestomeetrealusers,whichisasignicantoverhead.Interestingly,the1000-gatewayresult(whereeverySybilisagateway)showsthat,atcertainpoint,addingmoreattackedgescanactuallyhurtSybils.ThisispotentiallyduetothefactthatSybilRankusesnodedegreetonormalizetrustscore.ForgatewaysthatconnecttobothnormalusersandotherSybils,theadditional“trust”receivedbyaddingmoreattackedgescannotcompensatethepenaltyofdegreenormalization.Forabetterlookatthedetectionaccuracy,weconverttheAUCinFigure10(b)tofalsepositives(classifyingrealusersasSybils)andfalsenegatives(classifyingSybilsasrealusers).Forsimplicity,wesetacutoffvaluetomarkthebottom10%oftherankednodesasSybils.3AsshowninFigure12,SybilRankishighlyaccuratetodetectSybilswhenthenumberofgatewaysislessthan100.Again100gatewaysincurshighcostinpractice.NextwequicklyexaminetheimpactoftrustednodestoSybilde-tection.Figure11showsasmallnumberoftrustednodeisenoughtorunSybilRank.Interestingly,addingmoretrustednodescanslightlyhurtSybildetection,possiblybecauseitgivestheattacker(gateways)ahigherchancetoreceivetrust.Inpractice,multipletrustednodescanhelpSybilRankovercomepotentialcommunitystructuresinproximitygraph(e.g.,usersofthesamecityformacluster).SoWazeshouldplacetrustednodesaccordinglytocovergeographicclusters.CostofSybilAttacks.Next,weinfertheroughcostofattack-ersonimplementingsuccessfulSybilattacks.Forthiswelookat 3Thiscutoffvalueisonlytoconverttheerrorrate.Inpractice,Wazecanoptimizethisvaluebasedonthetrustscoreormanualexamination. 0 0.04 0.08 0.12 0.16 0.2 0 10k 20k 30k 40k 50k False Positive Rate# of Total Attack EdgesGateway=1000 Gateway=500 Gateway=100 Gateway=1 (a)FalsePositiveRate 0 0.2 0.4 0.6 0.8 1 0 10k 20k 30k 40k 50k False Negative Rate# of Total Attack EdgesGateway=1000 Gateway=500 Gateway=100 Gateway=1 (b)FalseNegativeRateFigure12:Detectionerrorrateswithrespecttonumberofattackedges.Wesetaver-agedegree=10forSybils'power-lawinnerconnections. 0 20k 40k 60k 80k 100k 120k 1000 2000 3000 4000 5000 # of Attack Edges# of SybilsAUC=0.75 AUC=0.80 AUC=0.85 AUC=0.90 AUC=0.95 Figure13:#ofattackedgesneededtomaintainxSybildeviceswithrespecttodifferentAUClevel.thenumberofattackedgesrequiredtosuccessfullyembedagivennumberofSybils.Ourexperimentassumestheattackeruses500gatewaysandbuildspower-lawdistributedinnerconnectionswithaveragedegree10.Figure13showsthenumberofattackedgesrequiredtoachieveaspecicAUCunderSybilRankasafunctionofthetargetnumberofSybils.WeseethattheattackedgecountincreaseslinearlywiththeSybilcount.ThecostofSybilattackishigh:tomaintain3000Sybils,theattackermustmake60,000at-tackedgestokeepAUCbelow0.75,andspreadtheseattackedgesacross500high-costgateways.SmallerSybilGroups.Finally,weexaminehoweffectiveoursystemisindetectingmuchsmallerSybilgroups.WetestSybilgroupswithsizeof20,50and100usingasingle-gatewayap-proach.Wecongure50KattackingedgesforSybilswithinnerdegree=10.TheresultingAUCofSybildetectionis0.90,0.95and0.99respectively.ThisconrmsoursystemcaneffectivelyidentifysmallSybilgroupsaswell.7.3ImplicationsonWazeTheseresultsshowthatourSybildetectionmethodishighlyef-fective.Itsignicantlyincreasesthecost(inpurchasingphysicaldevicesandtimespentactuallydrivingontheroad)tolaunchSybilattacks.Also,SybilRankisscalableenoughforlargesystemslikeWaze.AsocialnetworkwithtensofmillionsofusershasbeenrunningSybilRankonHadoopservers[10].InadditiontoSybildetection,Wazecanincorporateothermech-anismstoprotectitsusers.Webrieydescribeafewkeyideas,butleavetheintegrationwithourapproachtofuturework.First,IPverication:whenauserclaimssheisdriving,WazecanexaminewhetherherIPisamobileIPthatbelongstoavalidcellularcarrierorasuspiciouswebproxy.However,thisapproachisineffectiveifdedicatedattackersroutetheattacktrafcthroughacellulardataplan.Second,strictratelimit:withthat,attackerswillneedtorunmoreSybildevicestoimplementthesameattack.Third,veri-cationsonaccountregistration:thisneedstobehandledcarefullysinceemail/SMSbasedvericationcanbebypassedusingdispos-ableemailorphonenumbers[44].Finally,detectingextremelyinconsistentGPS/eventreports.Thechallenge,however,istodis-tinguishhonestreportsfromthefakeonessinceattackercaneasilyoutvoterealusers.IfWazechoos

11 estoignorealltheinconsistentre-ports,itw
estoignorealltheinconsistentre-ports,itwillleadtoDOSattackwhereattackersdisabletheservicewithinconsistentdata.8.BROADERIMPLICATIONSWhileourexperimentsanddefenseshavefocusedstrictlyonWaze,ourresultsareapplicabletoawiderrangeofmobileap-plicationsthatrelyongeolocationforuser-contributedcontentandmetadata.Examplesincludelocationbasedcheck-inandreviewservices(Foursquare,Yelp),crowdsourcednavigationsystems(Waze,Moovit),crowdsourcedtaxiservices(Uber,Lyft),mobiledatingapps(Tinder,Bumble)andanonymousmobilecommunities(YikYak,Whisper).Thesesystemsfacetwocommonchallengesexposingthemtopotentialattacks.First,oureffortsshowthatitisdifcultforappdeveloperstobuildatrulysecurechannelbetweentheappandtheserver.Therearenumerousavenuesforanattackertoreverse-engineerandmimicanapp'sAPIcalls,therebycreating“cheap”virtualdevicesandlaunchingSybilattack[16].Second,therearenodeployedmechanismstoauthenticatelocationdata(e.g.,GPSreport).Withoutasecurechanneltotheserverandauthenticatedlocation,thesemobileappsarevulnerabletoautomatedattacksrangingfromnuisance(prankcallstoUber)tomaliciouscontentattacks(large-scaleratingmanipulationonYelp).Tovalidateourpoint,werunaquickempiricalanalysisonabroadclassofmobileappstounderstandhoweasyitistoreverse-engineertheirAPIsandinjectfalsieddataintothesystem.WepickoneappfromeachcategoryincludingFoursquare,Uber,Tin-derandYikYak(anincompletelist).Wendthat,althoughallthelistedappsuseTLS/SSLtoencrypttheirnetworktrafc,theirAPIscanbefullyexposedbythemethodin§4.Foreachapp,wewereabletobuildalight-weightclientusingpythonscript,andfeedar-bitraryGPStotheirkeyfunctioncalls.Forexample,withforgedGPS,agroupofFoursquareclientscandeliverlargevolumesofcheck-instoagivenvenuewithoutphysicallyvisitingit;OnUber,onecandistributemanyvirtualdevicesassensors,andpassivelymonitorandtrackalldrivers(andtheirpassengers)withinalargearea(see§5).SimilarlyforYikYakandTinder,thevirtualdevicesmakeitpossibletoperformwardrivinginagivenlocationareatopostandcollectanonymousYikYakmessagesorTinderproles.Inaddition,appslikeTinderalsodisplaythegeographicaldistancetoanearbyuser(e.g.,1mile).Attackercanusemultiplevirtualdevicestomeasurethedistancetothetargetuser,and“triangulate”thatuser'sexactlocation[50].Therearepossibleapp-specicde-fenses,andweleavetheirdesignandevaluationtofuturework.9.DISCLOSUREANDIMPACTBeforetherstwriteupofourwork,wesoughttoinformtheGoogleWazeteamofourresults.WerstusedmultipleexistingGooglecontactsonthesecurityandAndroidteams.WhenthatfailedtoreachtheWazeteam,wegotintouchwithNielsProvos,whothenrelayedinformationaboutourprojecttotheWazeteam.ThroughourperiodictestsoftheWazeapp,wenoticedrecentupdatesmadesignicantchangestohowtheappreportsuserloca-tiondatatotheserver(andotherusers).InthenewWazeupdate(v4.4.0,releasedinApril2016),theapponlyreportsuserGPSval-ueswhentheuserisactivelydriving(movingatamoderate/fastrateofspeed).GPStrackingstopswhenauseriswalkingorstandingstill.Inaddition,Wazeautomaticallyshutsdowniftheuserputsit inthebackground,andhasnotdrivenforawhile.Toresumeusertracking(GPSreporting),usersmustmanuallybringtheapptotheforeground.Finally,Wazenowhideusers'startinganddestinationlocationsoftheirtrips.WhileonlinedocumentationclaimsthattheseoptimizationsaretoreduceenergyusagefortheWazeapp,wearegratiedbythedramaticstepstakentolimitusertrackingandimproveuserpri-vacy.ThesechangesdramaticallyreducetheamountofGPSdatasenttotheserver(andmadeavailabletopotentialattackersthroughtheAPI).Byourestimates,theupdatereducestheamountofGPStrackingdataforatypicaluserbynearlyafactorof10x.Inaddi-tion,removingtherstandlastGPSvaluesofatripmeansthatitissignicantlyhardertotrackauserthroughmultipletrips.Pre-viously,userscouldbetrackedacrossnewWazesessions,despitenewper-sessionidentiers,bymatchingthedestinationpointofonetripwiththestartingpointofthenext.WenotethatwhileWazehastakensignicantlystepstoimproveuserprivacy,userscanstillbetrackedwhiletheyareactivelyusingtheapp.Moreimportantly,theattackweidentiedherecanstillwreakhavocwithawiderangeofmobileapps,andSybildevicesarearealchallengestillinneedofpracticalsolutions.Wehopeourworkspursfutureworktoaddressthisproblem.10.RELATEDWORKSecurityinLocation-basedServices.Location-basedser-vicesfacevariousthreats,rangingfromrogueusersreportingfakeGPS[11,22],tomaliciouspartiescompromisinguserprivacy[15,26,27].ArelatedstudyonWaze[39]demonstratedthatsmall-scaleattackscancreatetrafcjamsortrackusericons,withupto15mobileemulators.Ourworkdiffersintwokeyaspects.First,weshowthatit'spossibletoreverseengineeritsAPIs,enablinglight-weightSybildevices(simplescripts)toreplacefull-stackemula-tors.Thisincreasethescaleofpotentialattacksbyordersofmagni-tude,tothousandsofWazeclientspercommoditylaptop.Theim-pactofthousandsofvirtualvehiclesisqualitativelydifferentfrom10-15mobilesimulators.Second,aspossibledefenses,[39]citesknowntoolssuchasphonenumber/IPverication,orlocationau-thenticationwithcellulartowers,whichhavelimitedapplicability(see§6).Incontrast,weproposeanovelproximitygraphapproachtodetectandconstraintheimpactofvirtualdevices.ResearchershaveproposedtopreserveuserlocationprivacyagainstmapservicessuchasWazeandGoogle.Earlierstudiesapplylo-cationcloakingbyaddingnoisetotheGPSreports[21].Recentworkusezero-knowledge[24]anddifferentialprivacy[8]topre-servethelocat

12 ionprivacyofindividualusers,whilemaintai
ionprivacyofindividualusers,whilemaintaininguseraccountabilityandtheaccuracyofaggregatedstatistics.Ourworkdiffersbyfocusingontheattacksagainstthemapservices.MobileLocationAuthentication.DefendingagainstforgedGPSischallenging.Onedirectionistoauthenticateuserlocationsusingwirelessinfrastructures:WiFiAPs[30,37],cellularbasesta-tions[30,37]andfemtocells[7].Devicesmustcomeintophys-icalproximitytotheseinfrastructurestobeauthenticated.Butitrequirescooperationamongawiderangeofinfrastructures(alsomodicationstotheirsoftware/hardware),whichisimpracticalforlarge-scaleserviceslikeWaze.Ourworkonlyusesasmallnum-beroftrustedinfrastructurestobootstrap,andreliesonpeer-basedtrustpropagationtoachievecoverage.Otherresearchershavepro-posed“peer-based”methodstoauthenticatecollocatedmobilede-vices[42,51,55,31,34].Differentfromexistingwork,weusepeer-basedcollocationauthenticationtobuildproximitygraphsforSybildetection,insteadofdirectlyauthenticatingadevice'sphysi-callocation.SybilDetection.SybildetectionhasbeenstudiedinP2Pnetworks[16]andonlinesocialnetworks[47,49,48].Themostpopularapproachisgraph-basedwherethekeyassumptionisthatSybilshavedifcultytoconnecttorealusers[10,14,46,52,53].ThusSybilswouldformawell-connectedsubgraphthathasasmallquotient-cutfromthenon-Sybilregion.Ourworkconstructsaproximitygraphthatholdsthesameassumption,andappliesSybildetectionalgorithmtolocateghostridersinWaze.Wedifferfrom[10]inthegraphusedandtheattackmodels.11.CONCLUSIONWedescribeoureffortstoidentifyandstudyarangeofattacksoncrowdsourcedmapservices.Weidentifyarangeofsingleandmulti-userattacks,anddescribetechniquestobuildandcontrolgroupsofvirtualvehicles(ghostriders)toamplifytheseattacks.Ourworkshowsthattoday'smappingservicesarehighlyvulnera-bletosoftwareagentscontrolledbymalicioususers,andboththestabilityoftheseservicesandtheprivacyofmillionsofusersareatstake.WhileourstudyandexperimentsfocusontheWazesystem,webelievethelargemajorityofourresultscanbegeneralizedtocrowdsourcedappsasagroup.WeproposeandvalidateasuiteoftechniquesthathelpservicesbuildproximitygraphsandusethemtoeffectivelydetectSybildevices.Throughoutthiswork,wehavetakenactivestepstoisolateourexperimentsandpreventanynegativeconsequenceonrealWazeusers.WealsousedourexistingGoogle/WazecontactstoinformWazeteamofourresults.MoredetailsonIRB,ethicsanddisclo-surearecontainedinAppendixA.AcknowledgmentsWewouldliketothankourshepherdZ.MorleyMaoandtheanony-mousreviewersfortheircomments.ThisprojectwassupportedbyNSFgrantsCNS-1527939andCNS-1224100.Anyopinions,nd-ings,andconclusionsorrecommendationsexpressedinthismate-rialarethoseoftheauthorsanddonotnecessarilyreecttheviewsofanyfundingagencies.AppendixA—IRB,EthicsOurstudywasreviewedandapprovedbyourlocalIRB.Priortodoinganyrealmeasurementsonthesystem,wesubmittedahumansubjectprotocolforapprovalbyourinstitutionalIRB.Theprotocolwasfullyreviewedforethicsandprivacyrisks,andtheresponsewasourstudycanbeexempt.WeputtherequestintoourIRBsystemandbeganourwork.ThentheconrmationofexemptionarrivedandourstudyreceivedtheIRBapprovalunderprotocol#COMS-ZH-YA-010-7N.Asdescribedinthepaper,weareveryawareofthepotentialim-pactonrealWazeusersfromanyexperiments.Wetookverycare-fulprecautionstoensurethatourexperimentswillnotnegativelyimpactWazeserversorWazeusers.Inparticular,weconductednumerousmeasurementsofdiversetrafcregions(read-only)tolocateareasofextremelylowtrafcdensity.Wechoseexperimentlocationswhereuserpopulationdensityisextremelylow(unoccu-piedroads),andonlyperformexperimentsatlow-trafchours,e.g.between3amand5am.Duringexperiments,wecontinuouslyscantheentireregionincludingourexperimentalareaandneighboringregions,toensurenootherWazeusers(exceptourownaccounts)arewithinmilesofthetestarea.IfanyWazeusersaredetected,weimmediatelyterminateanyrunningexperiments.Wetookcaretolimitcongestionteststoareaswithlotsoflocalrouteredun-dancy,thuswewouldnotaffecttheroutingofanylongdistance trips(e.g.takinghighway80becausethe101wascongested).Fi-nally,whilewecannotdetectinvisibleusersinourtestarea,wehavetakeneveryprecautiontoonlytestonroadsandtimesthatshowverylittletrafc,e.g.lowpopulationareasat4amlocaltime.Webelieveinpractice,invisibleusersmakeupasmallsubsetoftheWazepopulation,becausetheycannotsendreportsormessageotherusers(effectivelyremovingmost/allofthesocialfunctional-ityinWaze),andWazeresetstheinvisiblesettingeverytimetheappisopened[1].12.REFERENCES[1]AboutWaze:Privacy.https://support.google.com/waze/answer/6071193?hl=en.[2]CharlesProxy.http://www.charlesproxy.com.[3]GenyMotionEmulator.http://www.genymotion.com.[4]Monkeyrunner.http://developer.android.com/tools/help/monkeyrunner_concepts.html.[5]OpenSourceRoutingMachine(OSRM).http://map.project-osrm.org.[6]A.-L.BarabasiandR.Albert.Emergenceofscalinginrandomnetworks.Science,286,1999.[7]J.Brassil,P.K.Manadhata,andR.Netravali.Trafcsignature-basedmobiledevicelocationauthentication.IEEETransactionsonMobileComputing,13(9):2156–2169,2014.[8]J.W.S.Brown,O.Ohrimenko,andR.Tamassia.Haze:Privacy-preservingreal-timetrafcstatistics.InProc.ofSIGSPATIAL,2013.[9]C.Brubaker,S.Jana,B.Ray,S.Khurshid,andV.Shmatikov.Usingfrankencertsforautomatedadversarialtestingofcerticatevalidationinssl/tlsimplementations.InProc.ofIEEES&P,2014.[10]Q.Cao,M.Sirivianos,X.Yang,andT.Pregueiro.Aidingthedetectionoffakea

13 ccountsinlargescalesocialonlineservices.
ccountsinlargescalesocialonlineservices.InProc.ofNSDI,2012.[11]B.CarbunarandR.Potharaju.Youunlockedthemt.everestbadgeonfoursquare!counteringlocationfraudingeosocialnetworks.InProc.ofMASS,2012.[12]A.Clauset,C.R.Shalizi,andM.E.Newman.Power-lawdistributionsinempiricaldata.SIAMreview,51(4):661–703,2009.[13]F.Cunha,A.C.Viana,R.A.F.Mini,andA.A.F.Loureiro.Isitpossibletondsocialpropertiesinvehicularnetworks?InProc.ofISCC,2014.[14]G.DanezisandP.Mittal.Sybilinfer:Detectingsybilnodesusingsocialnetworks.InProcofNDSS,2009.[15]Y.-A.deMontjoye,M.Verleysen,andV.D.Blondel.Uniqueinthecrowd:Theprivacyboundsofhumanmobility.ScienticReports,3,2013.[16]J.R.Douceur.TheSybilattack.InProc.ofIPTPS,2002.[17]W.Enck,D.Octeau,P.McDaniel,andS.Chaudhuri.Astudyofandroidapplicationsecurity.InProc.ofUSENIXSecurity,2011.[18]S.Fahl,M.Harbach,H.Perl,M.Koetter,andM.Smith.Rethinkingssldevelopmentinanappiedworld.InProc.ofCCS,2013.[19]V.Goel.Mapsthatliveandbreathewithdata.TheNewYorkTimes,June2013.[20]Google.Googlemapsandwaze,outsmartingtrafctogether.GoogleOfcialBlog,June2013.[21]M.GruteserandD.Grunwald.Anonymoususageoflocation-basedservicesthroughspatialandtemporalcloaking.InProc.ofMobiSys,2003.[22]W.He,X.Liu,andM.Ren.Locationcheating:Asecuritychallengetolocation-basedsocialnetworkservices.InProc.ofICDCS,2011.[23]T.Hossmann,T.Spyropoulos,andF.Legendre.Knowthyneighbor:Towardsoptimalmappingofcontactstosocialgraphsfordtnrouting.InProc.ofINFOCOM,2010.[24]T.Jeske.Floatingcardatafromsmartphones:Whatgoogleandwazeknowaboutyouandhowhackerscancontroltrafc.BlackHat,2013.[25]V.KachitvichyanukulandB.W.Schmeiser.Binomialrandomvariategeneration.Commun.ACM,31(2):216–222,1988.[26]J.Krumm.Inferenceattacksonlocationtracks.InPervasiveComputing.2007.[27]J.Krumm.Asurveyofcomputationallocationprivacy.PersonalandUbiquitousComputing,2009.[28]A.LangvilleandC.Meyer.Deeperinsidepagerank.InternetMathematics,1(3):335–380,2004.[29]X.Liu,Z.Li,W.Li,S.Lu,X.Wang,andD.Chen.Exploringsocialpropertiesinvehicularadhocnetworks.InProc.ofInternetware,2012.[30]W.LuoandU.Hengartner.Provingyourlocationwithoutgivingupyourprivacy.InProc.ofHotMobile,2010.[31]J.Manweiler,R.Scudellari,andL.P.Cox.Smile:Encounter-basedtrustformobilesocialservices.InProc.ofCCS,2009.[32]C.Marforio,N.Karapanos,C.Soriente,andK.Capkun.Smartphonesaspracticalandsecurelocationvericationtokensforpayments.InProc.ofNDSS,2014.[33]A.G.Miklas,K.K.Gollu,K.K.W.Chan,S.Saroiu,K.P.Gummadi,andE.deLara.Exploitingsocialinteractionsinmobilesystems.InProc.ofUbicomp,2007.[34]A.Narayanan,N.Thiagarajan,M.Lakhani,M.Hamburg,andD.Boneh.LocationPrivacyviaPrivateProximityTesting.InProc.ofNDSS,2011.[35]J.OsborneandA.Diquet.Whensecuritygetsintheway:Pentestingmobileappsthatusecerticatepinning.BlackHat,2012.[36]B.Reed.Googlemapsbecomesgoogle'ssecond1billion-downloadhit.Yahoo!News,June2014.[37]S.SaroiuandA.Wolman.Enablingnewmobileapplicationswithlocationproofs.InProc.ofHotMobile,2009.[38]S.SaroiuandA.Wolman.Iamasensor,andiapprovethismessage.InProc.ofHotMobile,2010.[39]M.B.Sinai,N.Partush,S.Yadid,andE.Yahav.Exploitingsocialnavigation.BlackHatAsia,CoRR:abs/1410.0151,2015.[40]D.Sounthiraraj,J.Sahs,G.Greenwood,Z.Lin,andL.Khan.Smv-hunter:Largescale,automateddetectionofssl/tlsman-in-the-middlevulnerabilitiesinandroidapps.InProc.ofNDSS,2014.[41]N.Stefanovitch,A.Alshamsi,M.Cebrian,andI.Rahwan.Errorandattacktoleranceofcollectiveproblemsolving:Thedarpashredderchallenge.EPJDataScience,3(1):1–27,2014.[42]M.Talasila,R.Curtmola,andC.Borcea.LINK:locationvericationthroughimmediateneighborsknowledge.InProc.ofMobiQuitous,2010.[43]F.Tan,Y.Borghol,andS.Ardon.Emo:Astatisticalencounter-basedmobilitymodelforsimulatingdelaytolerantnetworks.InProc.ofWOWMOM,2008. [44]K.Thomas,D.Iatskiv,E.Bursztein,T.Pietraszek,C.Grier,andD.McCoy.Dialingbackabuseonphoneveriedaccounts.InProc.ofCCS,2014.[45]J.M.Tjensvold.ComparisonoftheIEEE802.11,802.15.1,802.15.4and802.15.6wirelessstandards.http://janmagnet.les.wordpress.com/2008/07/comparison-ieee-802-standards.pdf,2007.[46]N.Tran,B.Min,J.Li,andL.Subramanian.Sybil-resilientonlinecontentvoting.InProc.ofNSDI,2009.[47]B.Viswanath,A.Post,K.P.Gummadi,andA.Mislove.Ananalysisofsocialnetwork-basedsybildefenses.InProc.ofSIGCOMM,2010.[48]G.Wang,T.Konolige,C.Wilson,X.Wang,H.Zheng,andB.Y.Zhao.Youarehowyouclick:Clickstreamanalysisforsybildetection.InProc.ofUSENIXSecurity,2013.[49]G.Wang,M.Mohanlal,C.Wilson,X.Wang,M.Metzger,H.Zheng,andB.Y.Zhao.Socialturingtests:Crowdsourcingsybildetection.InProc.ofNDSS,2013.[50]G.Wang,B.Wang,T.Wang,A.Nika,H.Zheng,andB.Y.Zhao.Whispersinthedark:Analysisofananonymoussocialnetwork.InProc.ofIMC,2014.[51]X.Wang,J.Zhu,A.Pande,A.Raghuramu,P.Mohapatra,T.Abdelzaher,andR.Ganti.STAMP:Adhocspatial-temporalprovenanceassuranceformobileusers.InProc.ofICNP,2013.[52]H.Yu,P.B.Gibbons,M.Kaminsky,andF.Xiao.Sybillimit:Anear-optimalsocialnetworkdefenseagainstsybilattacks.InProc.ofIEEES&P,2008.[53]H.Yu,M.Kaminsky,P.B.Gibbons,andA.Flaxman.Sybilguard:defendingagainstsybilattacksviasocialnetworks.InProc.ofSIGCOMM,2006.[54]Z.Zhang,L.Zhou,X.Zhao,G.Wang,Y.Su,M.Metzger,H.Zheng,andB.Y.Zhao.Onthevalidityofgeosocialmobilitytraces.InProc.ofHotNets,2013.[55]Z.ZhuandG.Cao.Towardprivacypreservingandcollusionresistanceinalocationproofupdatingsystem.IEEETransactionsonMobileComputing,12(1):51