RouteDetector: Sensor-based Positioning Systemthat Exploits Spatio-Temporal Regularity of Human Mobilty

Takuya WatanabeWaseda University

Mitsuaki AkiyamaNTT Secure Platform Labs

Tatsuya MoriWaseda University

AbstractWe developed a novel, proof-of-concept side-channel at-tack framework called RouteDetector, which identifies aroute for a train trip by simply reading smart device sen-sors: an accelerometer, magnetometer, and gyroscope.All these sensors are commonly used by many apps with-out requiring any permissions. The key technical compo-nents of RouteDetector can be summarized as follows.First, by applying a machine-learning technique to thedata collected from sensors, RouteDetector detects theactivity of a user, i.e., “walking,” “in moving vehicle,”or “other.” Next, it extracts departure/arrival times of ve-hicles from the sequence of the detected human activi-ties. Finally, by correlating the detected departure/arrivaltimes of the vehicle with timetables/route maps collectedfrom all the railway companies in the rider’s country,it identifies potential routes that can be used for a trip.We demonstrate that the strategy is feasible through fieldexperiments and extensive simulation experiments usingtimetables and route maps for 9,090 railway stations of172 railway companies.

1 Introduction

Modern smart devices, such as smartphones, smartwatches, and smart glasses, have powerful embeddedsensors such as accelerometers, magnetometers, gyro-scopes, ambient light sensors, and heart rate monitors.While these sensors are used to provide new user expe-riences, they also bring the new line of side-channel at-tacks [1, 2, 3, 4, 5, 6, 7, 8].

Let us consider a new side-channel attack called SPS(sensor-based positioning system), which also exploitssensors of smart devices. The ultimate goal of an SPSattack is to estimate the location of a user by reading sen-sors but without using conventional geolocation method-ologies such as GPS, cell tower signals, or WiFi. Clearly,achieving the goal is difficult, primarily due to the highdegree of freedom of user mobility.

The goal of this work is to make the SPS attack fea-sible. To this end, we exploit the spatio-temporal regu-larity of human mobility patterns [9]; e.g., a person mayuse a fixed route on a transportation system for her/hiscommuting. Also, vehicles of transportation systems aregenerally expected to exhibit a temporal regularity un-less they encounter operation problems such as naturaldisasters or rail accidents. We expect that exploiting theregularity enables us to reduce the degree of freedom ofhuman mobility.

With this approach in mind, we develop a novelproof-of-concept attack framework called RouteDetec-tor, which targets the location of passengers of transportservice. It aims to identify the route of your train trip(i.e., the sequence of train stations) by simply readingthree hardware sensors – accelerometer, magnetometer,and gyroscope – which are all accessible from any appswithout requiring any permissions. A unique technicalconcept of RouteDetector is that it makes use of not onlydata collected from multiple sensors embedded in a smartdevice, but it also leverages external data that can extractprivacy information by correlating with collected sensordata.

The key technical components of RouteDetector canbe summarized as follows: First, by applying a machine-learning technique to the data collected from sensors,RouteDetector classifies the activity of a user, e.g., walk-ing, riding on a moving vehicle, or other status suchas still. Next, using the sequences of the detected ac-tivities, RouteDetector extracts departure/arrival timesof vehicle(s). Finally, RouteDetector correlates the ex-tracted departure/arrival times of vehicle(s) with timeta-bles/route maps of all vehicles and searches the potentialmobility paths.

The key findings of this work are summarized as fol-lows:

• Our field experiments using smart devices demon-strate that the RouteDetector framework can de-

1

tect departure/arrival times of vehicles with errorssmaller than six seconds on average.

• Our extensive simulation experiments using timeta-bles and route maps for 9,090 railway stations of172 railway companies demonstrate that given asequence of departure/arrival times, RouteDetectorcan identify routes used for a trip by train, and theaverage number of identified routes becomes closeto one if the number of stations used on a trip ismore than six.

These findings support that the attack is feasible.The rest of this paper is organized as follows. Sec-

tion 2 describes the threat models we assume for Rout-eDetector In section 3, we present the details of the Rout-eDetector framework. Section 4 shows the results of per-formance evaluation. Section 6 discusses the limitationsof RouteDetector and future research directions. We alsodiscuss the possible counter measures against RouteDe-tector. Section 7 summarizes the related work. We con-clude our work in section 8.

2 Threat models

Our threat model assumes that a malicious software,which requires only a permission of Internet connection,is installed on the victim’s device. The software keepscollecting sensor values and estimating the activities ofthe owner of the device; i.e., walking (running), movingon a vehicle, or other. Sequences of detected activitiesare periodically sent to the adversary’s computer. The ad-versary’s computer estimates the route of transportationby analyzing the sequences. Note that it is also possiblethat the user device computes the estimation of routesand sends the estimated results to the adversary. It iseasy for an adversary to know the hardware model of thesmart device; for instance, in the Android platform, byaccessing the fields of Android.os.Build class, he/shecan obtain the hardware information, such as brand, man-ufacturer, and/or model. He/she can also know whether asmart device is being held in someone’s hand or is insidea bag by reading the ambient light sensor or proximitysensor. Because the threat model targets passengers onpublic transportation systems, it is not useful where nopublic transportation system is available. We also as-sume that the adversary knows the list of public trans-portation systems that would likely be used by the victim.For instance, if a victim lives in a particular country, theadversary assumes that the victim may use any of rail-ways available in that country. We also need to assumethat the transportation system operates punctually; other-wise, RouteDetector’s estimation may be inaccurate. Wewill study the issue in Sec. 4. Other limitations will bediscussed in Sec. 6.

Sensor data(Sec. 3.2)

Candidate routes

(Sec. 3.5)

User activity(Sec. 3.3)

still

walk / run

vehicle

Tokyo Kanda Akihabara Okachimachi

Ikeshita Imaike Chigusa Shin-

Sakaecho

Sapporo Kita 13 Jo

Higashi Higashi

Kuyakusho Mae

DPT. 8:31

ARR. 8:34

DPT. 8:34

Yamanote Line (Tokyo)

Higashiyama Line (Nagoya)

Toho Line (Hokkaido)

ARR. 8:33

DPT. 8:33

ARR. 8:36

vehicle still vehicle still vehicle

Kanjo DoriHigashi

Vehicle DPT./ARR.sequence(Sec. 3.4)

Figure 1: High-level overview of the RouteDetectorframework.

3 RouteDetector Framework

In this section, we present an overview of the RouteDe-tector framework (Sec. 3.1). Then, we describe the sen-sors we used for our analysis (Sec. 3.2). We then de-scribe the key technical components of the RouteDetec-tor framework; the detection of user activities in Sec. 3.3,detection of departure/arrive time sequences of vehiclesin Sec. 3.4, and the extraction of candidate routes inSec. 3.5.

3.1 Goal and Overview

The goal of the RouteDetector framework is to identifythe route of a vehicle used by an owner of a smart de-vice by reading the device’s sensors. If a vehicle is apassenger train, a route is defined as a set of stationsalong a path. Figure 1 depicts the high-level overviewthat achieves the goal, together with the number of corre-sponding subsections that describe the technical details.

First, it reads values from sensors. As sensors, wepicked up accelerometer, linear acceleration, magne-tometer, and rotation vector, which are all accessiblefrom any app without requiring any permissions. Detailsof data collection are described in Sec. 3.2. Next, we ex-

2

Table 1: Summary of sensors.

Sensor Type unit Permission Description

accelerometer physical m/s2 Not required Acceleration applied to a device including the gravity.linear acceleration virtual m/s2 Not required Acceleration applied to a device excluding the gravity.magnetometer physical µT Not required Strength of geomagnetic field.gyroscope physical rad/s Not required A device’s rate of rotation.

tract user activities from the collected sensor data. Theuser activities are defined as a set of three classes, walk-ing, riding on a moving vehicle (vehicle in short), andothers, which includes various activities such as stand-ing, sitting, or sleeping. To this end, we pre-process rawsensor data so that we can apply a supervised machine-learning (ML) approach. As a supervised ML algorithm,we adopt random forest, which is known to achieve ro-bust and good performance for multi-class classificationtasks. Details of data pre-processing and ML applica-tion are described in Sec. 3.3. From the extracted useractivities, we can identify sequences of vehicle depar-ture/arrival times. For instance, if we find a consecu-tive pairs of vehicle and others, it is likely that a userwas on a vehicle. We can also consider cases in whicha user made a transit. Details of detecting vehicle de-parture/arrival time sequence are described in Sec. 3.4.Finally, from an extracted vehicle departure/arrival timesequence, we search candidate routes, using timetablesand railway route maps that cover the potential residen-tial area of the victim, e.g., a country. We develop afast algorithm that works in a breadth-first search man-ner. Details of extracting departure/arrival time sequenceare described in Sec. 3.4.

3.2 Sensor DataOf the available sensors embedded into a smart device,we adopt four sensors; accelerometer, linear accelera-tion, magnetometer, and rotation vector. Table 1 sum-marizes the sensors we used. Although we tested othersensors, such as an ambient light sensor, the data wasnot effective in detecting user activities. Note that thefour sensors can be divided into two classes: physicalsensors and virtual sensors. While the accelerometer,magnetometer, and gyroscope are physical sensors thatread raw values, the remaining sensor, linear accelera-tion, is a virtual sensor whose values are computed basedon physical sensors. We note that the sensors are acces-sible from any app without requiring any permissions;therefore, they are prone to be covertly abused by a ma-licious developer.

We developed an Android app that collects the sensordata. All the values are collected at a rate of 10 Hz, i.e.,read 10 values per second. The app also has a function

Rawsensor data

Feature extraction

Featurevector Scalarization

Pre-processing

Figure 2: Overview of data pre-processing.

to generate labels that are used for supervised ML.

3.3 Detection of User Activities

Using the collected sensor data, we classify user activ-ities into three distinct classes, walk, vehicle, and oth-ers. Note that vehicle refers to the status when a useris on a moving vehicle. If n user is standing on a vehi-cle, which is stopping at a station, his/her status is likelyclassified as others. We first pre-process raw sensor datain Sec. 3.3.1. Next, we apply a supervised machine-learning (ML) approach to the pre-processed data to de-tect user activities in Sec. 3.3.2.

3.3.1 Data Pre-processing

We apply several data pre-processing techniques to theraw sensor data. Figure 2 summarizes the data pre-processing scheme. First, to eliminate the effect of differ-ences in the directions in 3D space, we compute a norm

for each 3D vector; i.e., a =√

a2x +a2

y +a2z . Figures 3 (a)

and (b) are examples of scalarized data. We then dividetime series data into a set of blocks. A block consists ofN samples for each sensor data; i.e., for each sensor data,a block bi has data: D(i)(a)= {a(i)

1 ,a(i)2 , . . . ,a

(i)N }. We exper-

imentally set N as N = 20, which corresponds to 2 sec-onds length with the 10-Hz rate of sensor data sampling.For each block, we extract features that can be used tocharacterize the patterns of temporal variability for thethree classes. To this end, we adopted simple metrics;i.e., mean, standard deviation, minimum, and maximum.Finally, we normalize the data by subtracting means anddividing by standard deviations. In summary, the timeseries data is divided into blocks, and each block con-sists of four features for four sensors, resulting in featurevectors with 4×4 = 16 dimensions.

3

3.3.2 Classifying User Activities

Using the pre-processed sensor data, we classify activ-ities into three classes; walk, vehicle, and others. As aclassification scheme, we adopt the Random forest al-gorithm, which is an ensemble learning algorithm usedfor classification or regression. In the training phase, theRandom forest algorithm constructs multiple decisiontrees using randomly sampled data. In the classificationphase, it predicts the most plausible class by taking themajority votes of the multiple decision trees. The goodfeature of Random forest is that it naturally achievesmulti-class classification with a measure of score. Wenote that we also tested other supervised machine learn-ing algorithms, such as SVM or logistic regression. Itturned out that the differences in performance among thealgorithms were not significant, but the Random forestalgorithm worked best.

3.4 Detection of Departure/Arrival TimeSequences of Vehicles

Using the detected user activities, we extract sequencesof vehicle departure/arrival times. Among the user activ-ities, we are most interested in vehicle activity becausethe start/end of the activity corresponds with the depar-ture/arrival, respectively. However, as shown in Fig. 3(c), the predicted activities include some noise due to theinevitable classification errors. To reduce the effect ofclassification errors, we leverage the temporal correla-tion of the activities; i.e., once a user gets on a vehicle, itis likely that he/she stays on the vehicle for several min-utes. Namely, we use the exponentially weighted movingaverage (EWMA) to account for temporal correlation ofdata.

Let An be the classified activity at block n, and W,V, and O be the set of blocks that are classified as walk,vehicle, and others, respectively. We define Wn, Vn, andOn as

Wn = 1W(An)Vn = 1V(An)On = 1O(An),

where 1Y (x) is an indicator function that is defined as

1Y (x) =

1 if x ∈ Y0 if x < Y.

First, we compute the EWMA of Vn; i.e.,

Vn = λVn+ (1−λ)Vn−1,

where Vn is EWMA and 0 ≤ λ ≤ 1 is a constant param-eter that determines the smoothing factor. If λ is close

(a) pre-processed sensor data (scalarized)

A

L

M

10:55 11:00 11:05 11:10 11:15 11:20 11:25

G

(b) magnification of (a)

A

L

M

10:55 11:00 11:05 11:10 11:15 11:20 11:25

G

(c) predicted user activities

On

Wn

10:55 11:00 11:05 11:10 11:15 11:20 11:25

Vn

(d) smoothened user activities

On

Wn

10:55 11:00 11:05 11:10 11:15 11:20 11:25

Vn

escalator

(e) corrected activities and DPT./ARR. detection

On

Wntransfer

10:55 11:00 11:05 11:10 11:15 11:20 11:25

Vn

d a

Figure 3: (a): pre-processed sensor data, (b) magnification of (a)in Y-axis, (c) predicted user activities, (d) smoothened user activities,and (e) corrected user activities and departure/arrival times. In pan-els (a) and (b), A, L, M, and G represents accelerometer, linear ac-celeration, magnetometer, and gyroscope, respectively. In panel (e),circles/squares are detected departure/arrival times, respectively.

to one/zero, the EWMA has a larger weight on the lastobservation/past observations. The parameter λ is em-pirically configured, as we will show later. Although theEWMA introduces a certain time lag to the original data,the size of the lag was negligible, as we will show later.Using the EWMA, the classified activities are corrected,as

Vn =

1 if Vn ≥ 0.50 if Vn < 0.5.

Figure 3 (d) shows smoothened user activities with theEWMA.

4

Q1:  (*,  *,  Td1,  Ta1,  *)

S1

S2

S4

S5

S6

S8

S3 S7

S9

S11 l(S1,S4,Td1,Ta1,L1)

S10 S12

l(S1,S5,Td1,Ta1,L2)

l(S2,S6,Td1,Ta1,L3)

l(S2,S6,Td1,Ta1,L4)

l(S4,S8,Td2,Ta2,L1) l(S8,S11,Td3,Ta3,L1)

None

None l(S5,S9,Td2,Ta2,L2)

l(S10,S12,Td3,Ta3,L4) l(S7,S10,Td2,Ta2,L2)

Q2:  (S4,  *,  Td2,  Ta2,  L1) Q3:  (S8,  *,  Td3,  Ta3,  L1)

Q6:  (S6,  *,  Td2,  Ta2,  L3)

Q4:  (S5,  *,  Td2,  Ta2,  L2)

Q7:  (S7,  *,  Td2,  Ta2,  L4)

Q5:  (S9,  *,  Td3,Ta3,  L2)

Q8:  (S10,  *,  d3,  a3,  L4)

Input:  dpt./arr.  Time  sequences  {Td1,Ta1},  {Td2,Ta2},  {Td3,Ta3}

Output:  candidate  routes  Route1:  {S1,S4,S8,S11}  Route2:  {S3,S7,S10,S12}

Figure 4: Diagram of the route detection algorithm.

Next, using the corrected activities Vn, we extract de-parture/arrival time sequences using the following algo-rithm, where τ is a threshold that determines the mini-mum length of time for a trip between two stations. Inthis calculation, we set τ = 60 (seconds).

Algorithm 1 Vehicle DEP./ARR. time sequences detec-tion algorithm.1: D =false ▷ Initial state2: for all n = 1,2, . . . do3: if Vn = 0 AND Vn+1 = 1 then4: Td = tn+1 ▷ tn is time at block n.5: D =true ▷ A vehicle has been departured.6: if Vn = 1 AND Vn+1 = 0 AND D = 1 then7: Ta = tn+18: D =false9: if Ta −Td > τ then

10: return Ta,Td

We note that using blocks that were not classified as ve-hicles, i.e., {n; Vn = 0}, Wn and On can be corrected usingthe similar procedure. Tracking Wn and On is useful fordetecting transferring lines; i.e., if we observe a sequenceof classified activities such as vehicle (3 mins), walk (2mins), others (4 mins), and vehicle (5 mins), it is likelythat a person changed lines. Figure 3 (e) shows such anexample. The victim first got on a train and got off thetrain after three stations. He/she then changed lines (seethe area “transfer” shown in the graph of Wn), and got onthe next train.

As we shall see later, the activity of riding an escala-tor could be misclassified as being on a vehicle, althougha person may be using it for transferring lines. Such amisclassification can be safely removed with this heuris-tic. Figure 3 (d) and (e) show such an example where allthe ground-truth escalator points, which were misclassi-fied as “vehicle” by random forest, are successfully elim-inated in the corrected user activities. The heuristics arealso useful for eliminating other errors regarding activity

detection.

3.5 Extracting Candidate Routes

Finally, using the extracted sequences of depar-ture/arrival times, we estimate candidate routes. We for-mulate the estimation task as follows. Using railwayroute maps, we first create a single graph that consists ofnodes (stations) connected by links (railroads). Next, us-ing timetables corresponding to the railway route maps,we extend the graph so that it expresses temporal struc-ture. Let us call the extended graph a “train graph.” Ina train graph, a link l(A,B,Td,Ta,L) expresses a vehiclethat departures station A at time Td and arrives at sta-tion B at time Ta; A and B are adjacent stations on lineL. Note that we do not need to build/keep an entire traingraph beforehand. Instead, we compile a set of all linksand dynamically build subgraphs by applying our searchalgorithm to the set of links.

We use Fig. 4 to demonstrate how the algorithmof searching candidate routes works. In the exam-ple, we have the input departure/arrival time sequenceof {Td j,Ta j} ( j = 1,2,3). Given the input, we firstextract a set of links that satisfies l(∗,∗,Td1,Ta1,∗)(Q1: query 1). In the example, we foundfour links; (S 1,S 4,Td1,Ta1,L1), (S 1,S 5,Td1,Ta1,L2),(S 2,S 6,Td1,Ta1,L3), and (S 3,S 7,Td1,Ta1,L4). Foreach link above, we recursively search the succeedinglinks. For instance, to find a link (vehicle) that de-parts station S 4 at time Td2 and arrives at station Xat time Ta2 on line L1, we search a link that satisfiesl(S 4,∗,Td1,Ta1,L1) (see Q2) and found S 8 is the des-tination station. If we do not find any links that sat-isfy the given condition, we remove the paths from thesearch (see Q5, Q6). By continuing the above proce-dure, we can enumerate paths that satisfy the input depar-ture/arrival time sequences; i.e., routes {S 1,S 4,S 8,S 11}

5

Table 2: Smart devices used for our analysis.

Device name (abbreviation) Type OSHTC J Butterfly (HTC) Smartphone Android 4.1.1Nexus 7 (Nexus) Smart Tablet Android 4.4.4

and {S 3,S 7,S 10,S 12} in the example.Finally, when we get multiple routes for a given time

sequence, it is useful that we can sort them according tosome metrics. To this end, we compute the popularityof routes, as follows: For each link consisting of a route,we compute the number of other links that share the samepair of origin/destination stations with that link. We thensum up the numbers along the links of a route and definethe result as a score. If a route has a larger score, it meansthat a larger number of trains run on that route. We adoptthis score as a metric that expresses the popularity of aroute.

4 Evaluation

In this section, we evaluate the performance of the Rout-eDetector framework. We first summarize the datasetswe used for our analysis. Second, we evaluate the ac-curacy of the user activities detection scheme. We thenevaluate the accuracy of departure/arrival time sequencedetection. Finally, we evaluate the effectiveness of thecandidate routes detection scheme.

4.1 DataThe data we collected for evaluation is broadly classifiedinto two datasets. The first set consists of sensor dataused for detecting departure/arrival time sequences. Thesecond set consists of timetables and railway route mapsthat are used for building a train map, which is then usedto search candidate routes for a given time sequence.

4.1.1 Sensor Data

Table 2 presents the two smart devices used for our anal-ysis. As we shall see later, different hardware sensorsgenerally exhibit different values when given the sameinput. Therefore, we need to train each classificationmodel for each device. Details regarding to the differ-ences in device hardware will be discussed in Section 6.

Table 3 summarizes the sensor data we collected.These data were measured across seven lines, operatedby two railway companies. Four lines, Yamanote Line,Chuo Line, Keihin-Tohoku Line, and Saikyo Line, areoperated by East Japan railway company. Three subwaylines, Fukutoshin Line, Marunouchi Line, and Nanboku

Table 3: Sensor data collected for our analysis.

Data name Device Type # stations # lines # blocksHTC H HTC H 57 5 12,007HTC B HTC B 29 1 2,561Nexus H Nexus H 29 1 2,543Nexus B Nexus B 54 5 8,576

Table 4: Statistics of the train map built from railwayroute maps and timetables. Number of links is takenfrom timetables for weekdays.

# railway companies # lines # stations # links172 597 9,090 2,277,397

Line are operated by Tokyo Metro. Of these lines, Ya-manote Line is one of the busiest and most importantlines that connect major stations in Tokyo. As shownin the table, we distinguish between two measurementtypes: a device held by hand (H) or located inside a stillbag (B), which could be placed on the knee or on a rack.As we mentioned in Section 2, an adversary can distin-guish the hardware of devices. He/she can also knowwhether a smart device is being held in someone’s handor is inside a bag by reading the ambient light sensor orproximity sensor.

4.1.2 Railway Route Maps and Timetables

While the coverage of collected sensor data is limited toa certain location, we use entire train services operatedin Japan for building a train map. Table 4 summarizesthe data we collected. Note that a link l(A,B,Td,Ta,L)is defined in Section 3.5. We also note that if we canfurther specify the residential location of a victime, e.g.,Kyoto area, the amount of data and candidate routes canbe further reduced.

4.2 User activities detectionWe applied our user activities detection scheme to thedata shown in Table 5. The parameters of random forestwere empirically optimized as n = 50 and m = 4, wheren is the number of trees and m is the number of featuresused for each tree. To assess the generalization of theresult, we employed 10-times, 10-fold cross-validationtests. We focused on the accuracy of detecting vehiclesbecause it plays a crucial role in determining the depar-ture/arrival time sequence. If a block of vehicle was in-correctly classified as walk or others, we defined it as afalse negative. If a block of walk or others was classifiedas vehicle, we define it was false positive.

6

Table 5: Numbers of labeled blocks used for evaluatingperformance of activity detection. All the labeled blocksare collected at the stations of Yamanote Line.

Data vehicle walk othersHTC H 609 1,327 510HTC B 691 1,360 510Nexus H 686 1,352 505Nexus B 602 1,304 505

Table 6: Performance of detecting vehicle activity. ACC,FNR, and FPR are accuracy, false negative rate, and falsepositive rate, respectively.

Data ACC (mean/std) FNR (mean/std) FPR (mean/std)HTC H 0.941/0.011 0.042/0.022 0.078/0.013HTC B 0.965/0.009 0.024/0.012 0.047/0.014Nexus H 0.943/0.013 0.041/0.014 0.074/0.021Nexus B 0.969/0.009 0.023/0.012 0.041/0.016

Table 6 summarizes the results. We noticed that clas-sification accuracies are generally good in all the cases.We also noticed that measurement types of H, i.e., a de-vice was inside a still bag, gave better accuracies. Theresult is intuitively natural because holding a smart de-vice by hand may introduce motion noise.

4.3 Departure/Arrival Time Sequences De-tection

Next, we applied our departure/arrival time sequence de-tection algorithm to the extracted user activities. Foreach dataset, we picked up departure/arrival time se-quences of 30 stations. The 30 samples are divided intoa training set and a test set. Using the training set, theparameter of EWMA, λ, was optimized so that the differ-ence between the detected departure/arrival time and ob-served departure/arrival time is minimized. To evaluatethe performance, we employed 10-times, 3-fold cross-validation tests; i.e., 30 samples are randomly dividedinto 20 samples for a training set and 10 samples for atesting set, using different random seeds. Table 7 sum-marizes the absolute errors between detected and ob-served departure/arrival times. Note that observed depar-ture/arrival times are not necessarily the scheduled timeslisted in timetables. The difference between the observedand scheduled times is shown in Fig. 5.

As we see, the detected departure/arrival times areclose to the observed departure/arrival times. Maximaltime differences are less than 3-11 seconds. Time dif-ferences are within 3-7 seconds. Note that all the de-parture/arrival events are perfectly detected. In addi-

Table 7: Absolute errors between detected times and ob-served (ground truth) times; departure (top) and arrival(bottom). m and σ are mean and standard deviation, re-spectively.

absolute errors of detected departure times.Data min (sec) max (sec) m (sec) σ

HTC H 1.97 3.54 2.79 0.46HTC B 2.04 3.06 2.53 0.23Nexus H 2.33 7.94 4.60 1.84Nexus B 1.55 2.76 2.17 0.24

absolute errors of detected arrival times.Data min (sec) max (sec) m (sec) σ

HTC H 2.52 6.75 4.13 1.18HTC B 1.71 4.63 3.21 0.77Nexus H 3.07 10.78 6.03 2.22Nexus B 2.22 5.16 3.43 0.80

120 90 60 30 0 30 60 90 120time difference (sec)

0.0

0.2

0.4

0.6

0.8

1.0

CDF

departurearrival

Figure 5: Distributions of difference between observedand scheduled times. Departure times (top) and arrivaltimes (bottom).

tion, the observed departure/arrival times are also closeto the scheduled times. Roughly 85% of trains departwithin 60 seconds after the scheduled time has passed.Roughly 75% of trains arrived within 30 seconds aroundthe scheduled time.

In summary, the detected departure/arrival times bythe RouteDetector framework are close to the observeddeparture/arrival times, which are close to the sched-uled times. In the next subsection, we show how wesearch routes given the detected departure/arrival timesequences. We also present several case studies in Sec. 5.

4.4 Candidate Routes Detection

While the evaluation of departure/arrival time detectionscheme required empirical data, the evaluation of thecandidate routes detection algorithm can be generalizedby exploring paths on a train graph1. Using the train

1Because enumerating all the possible paths on a train graph couldcause an explosion of states, we limit our search to the paths withlengths less than 15 stations.

7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15# of links

100

101

102

103#

of ca

ndida

te ro

utes

meanmedianmax, mean

Figure 6: Number of links vs. number of candidateroutes.

graph constructed from the data shown in Table 4, westudy the relationship between the number of links andthe number of corresponding candidate routes. Figure 6shows the results. We can see that average number ofidentified routes becomes close to one if the number ofstations used on a trip is more than six; i.e., if we observemore stations, the sequence of departure/arrival times be-come more unique. Even if the number of links is one,roughly 50% of time sequences Td,Ta have less than fourcandidate routes.

Next, we study how quickly the search algorithmworks. From the entire train graph, we first enumeratethe routes whose lengths are less than 15 links, wherewe allowed, at most, two line changes. The number ofenumerated routes was 6,404,455,757. Using the C++implementation of the algorithm that runs on a commod-ity PC, all these routes were searched within 74 mins. Onaverage, a route was searched within 7.1 microseconds.Thus, the candidate routes detection worked quickly eventhough the scale of the train graph was huge.

5 Case study

In this section, we demonstrate the feasibility of theRouteDetector framework through the field experiments.Using sensor data collected from smartphone or tablet,we try to identify a route used for a trip. For brevity,we present three typical cases below. Figure 7 presents amap of lines used for the case study.

Case 1 In this case, the train trip involved two lines,Yamanote line and Marunouchi line as shown in Fig. 7.Figure 3 presents the measured/derived data for the case1. From Fig. 3 (e), we detected departure/arrival timesequence. The results are summarized in Table 8. Aswe see, all the detected departure/arrival times were cor-rectly detected. Note that “detected” times are derivedfrom sensors, “observed” times are manually labeled

Akihabara

Kokkai  Gijido-­‐mae Shibuya

Nishi  Waseda

Kanda

Tabata

Tokyo

Case 1

Case 2

Case 3

Yamanote Line

Fuku

tosh

in L

ine

Marunouchi Line

Figure 7: Map of lines used for case study analysis.

Table 8: Detected/observed/scheduled times for case 1.Detected and observed times are rounded.

activities detected observed scheduledwalking etc. –departure 10:56 10:56 10:56arrival 10:58 10:58 10:58departure 10:58 10:58 10:58arrival 11:00 11:00 11:00departure 11:00 11:00 11:00arrival 11:03 11:03 11:03walking etc. –departure 11:10 11:10 11:10arrival 11:12 11:12 11:12departure 11:12 11:12 11:12arrival 11:14 11:14 11:14walking etc. –

ones, and “scheduled” times are derived from a timetablecorresponding to a train. Next, given this time sequence,we search the corresponding routes. The result is shownin Table 9, which shows two routes are identified. Of theidentified two routes, the route #1 had higher score andwas identical to the ground truth. Thus, the RouteDetec-tor successfully detected a route used for a train trip fromsensor data.

Case 2 The case 2 was measured at Yamanote line.There was no transferring lines. The origin/destinationstations were Tabata station and Kanda station, respec-tively. The trip involved 8 stations. Figure 8 presents thedetected activities and departure/arrival time sequence.In this case, the detected departure/arrival times werecorrectly detected. Given the time sequence, a uniqueroute was identified. The identified route was identicalto the ground truth.

Case 3 The case 3 was measured at Fukutoshin Line.Again, there was no transferring lines. The ori-

8

Table 9: Two identified routes for case 1.

No. ground truth route #1 route #21 Kokkai-gijido-mae Kokkai-gijido Edogawabashi2 Kasumigaseki Kasumigaseki Gokokuji3 Ginza Ginza Higashi Ikebukuro4 Tokyo Tokyo Ikebukuro

transfer4 Tokyo Tokyo Ikebukuro5 Kanda Kanda Kanamecho6 Akihabara Akihabara Sengawa

score – 2,664 2,277

On

Wn

00:10 00:15 00:20

Vn

d a

Figure 8: Detected activities of the case 2.

gin/destination stations were Nishi Waseda station andShibuya station, respectively. In this case, while the de-tected departure/arrival times were identical to the ob-served times, they were slightly different from the sched-uled time; i.e., the train was delayed at the time of mea-surement. We will discuss the issue of train operation inthe next section. Given the detected time sequence, notrain route was identified from the train graph.

6 Discussion

In this section, we discuss several limitations of the Rout-eDetector framework. We also discuss countermeasuresagainst the new threat brought by the RouteDetectorframework.

6.1 LimitationsCross-Device Differences Our thread model assumesthat an adversary knows the type of hardware to be at-

On

Wn

21:20 21:25 21:30 21:35 21:40 21:45

Vn

d a

Figure 9: Detected activities of the case 3.

Table 10: Detected/observed/scheduled times for case 3.

activities detected observed scheduledwalking etc. –departure 21:27 21:27 21:26arrival 21:29 21:29 21:28departure 21:30 21:30 21:28arrival 21:32 21:32 21:32departure 21:33 21:33 21:32arrival 21:35 21:35 21:35departure 21:35 21:35 21:35arrival 21:37 21:37 21:37departure 21:37 21:37 21:37arrival 21:39 21:39 21:39walking etc. –

tacked; i.e., he/she needs to have training data for de-tecting user activities for each device. In fact, we foundthat a random forest classifier trained to work with smart-phone data did not work well for detecting the activitiesof tablet users. This observation suggests that a differ-ence in hardware sensors is sensitive to the user activ-ity detection scheme. One approach to this problem isto prepare training models for various devices. Anotherpossible approach is to apply some data-processing tech-niques that can absorb the differences in the measure-ments of sensor values. We leave the issue for our futurework.

Types of Vehicles While the target of this work waspassenger trains, there are other types of transportationservices, such as monorails or airplanes. If we can as-sume that vehicles are operated accurately according totimetable schedules, we may have a good chance to de-tect a route used for a trip. We conjecture that the Rout-eDetector will not work well for automobile transportservices such as public bus transportation because oflarge deviations in operation timeline.

Train Operation Clearly, the success of the RouteDe-tector framework relies on the accuracy of the train op-eration. The detection may not work in an environmentwhere many trains tend to be delayed. To increase thesuccess rate of attacks, an adversary needs to target a vic-tim who lives in a location in which trains are accuratelyoperated. We conjecture that further adoption of auto-matic train operation will work to increase the accuracyof train operations.

We also note that by continuously targeting a victim,an adversary can obtain multiple observations, whichlikely include the correct estimations; e.g., commutingroutes. Thus, by collecting many candidate routes usedby a target, an adversary can figure out locations fre-quently visited by the target in a statistical way.

9

6.2 CountermeasuresLet us discuss some ways to mitigate or eliminate the riskcaused by the attacks using the RouteDetector frame-work. Michalevsky et al., presented Gyrophone [6],which is an attack that recognizes speech by reading gy-roscope. They mentioned countermeasures in their paperthat apply low-pass filtering to the raw samples providedby sensors. If certain pass frequencies are enough formost of the applications, the filtering can be done with-out negative effects. In addition, they mentioned that itshould be controlled by permission mechanisms or cer-tain explicit authorization by the user when certain ap-plications require an unusually high sampling rate. In thesame way, restricting access to raw sensor data and build-ing some filtration mechanism that can remove sensitiveinformation without sacrificing other functions would bepromising approaches as countermeasures against the at-tack with RouteDetector. For instance, to build a pe-dometer app, a developer can use a specific API that canretrieve step counts, instead of reading row sensor valuesof accelerometer. Thus, building wrapper APIs that pro-vide many useful functions, while hiding raw data, is apromising approach to thwart sensor-based side-channelattacks.

7 Related work

Techniques of sensor data analysis on mobile devices aremainly used for extending the range of application ofmobile services, e.g., activity recognition and location-based services. On the contrary, attackers can exposeuser’s privacy by using above similar techniques analyz-ing sensor data. We introduce techniques for both benignand malicious uses.

Positioning without GPS An indoor positioning sys-tem (IPS) is presented as a solution to detect/navigateobjects or people inside a building [10]. Instead of us-ing GPS, IPS techniques make use of other informationsources such as radio wave, acoustic signals, and opticalsignals. As an example of malicious use of the position-ing technique, Michalevsky et al. demonstrated that theirdeveloped PowerSpy application enables the attacker toinfer the target device’s location over those routes or ar-eas by simply analyzing the target device’s power con-sumption [8].

Device fingerprinting A device fingerprinting is otherpositive usage of sensors to identify and authenticatephysical devices. Many studies reported that various IDson a smartphone, e.g., IMEI (device ID), are easily stolenby malicious apps. To thwart ID-theft, Dey presented Ac-celPrint, which is a system that fingerprints based on theaccelerometer, in order to identify devices without any

specific ID or cookie [5]. Das et al. also discussed thefeasibility of using sensors embedded in smartphones,i.e., microphones and speakers, to uniquely identify in-dividual devices [7].

Activity Recognition The CenceMe system developedby Miluzzo et al. [11] combines the inference of individ-uals’ activity using sensors’ information with sharing ofit through social networking services. To classify activ-ities (sitting, standing, walking, running) of individuals,the preprocessor of CenceMe calculates the mean, stan-dard deviation, and number of peaks of the accelerometerreadings along the three axes of the accelerometer. Rout-eDetector’s activity detection scheme is similar to thisone, but it is extended to capture the motion of vehicles.RouteDetector also uses other hardware sensors, such asa magnetometer and gyroscope, which also play a keyrole in improving detection accuracy.

The accelerometer sensor provides an attacker withother opportunities to build new attacks. Many attackstargeting motion sensors, i.e., accelerometers and gyro-scopes, that are embedded in smartphones are inferringuser inputs, e.g., passwords on touch-screens by monitor-ing readings collected from motion sensors [1, 2, 3, 4].

Sensor Access Control Although various kinds of sen-sor information contribute to extend and improve mobilecomputing and services, privacy issues have already beenexposed as mentioned above. One of the most practicaldefenses is access control to sensor data. Unnecessaryaccess by apps to sensor data should be controlled byOS or middleware on a device. FlaskDroid [12] and ip-Shield [13] are implemented as middleware on AndroidOS and provide fine-grain access control mechanism toresources including sensor information.

8 Conclusion

A novel, proof-of-concept side-channel attack frame-work called RouteDetector was introduced. The key ideabehind the framework is to leverage spatio-temporal reg-ularity of human mobility; i.e., we targeted passengers oftrain systems. Our field experiments demonstrated thatthe RouteDetector framework detected departure/arrivaltimes of vehicles with errors less than 6 seconds on aver-age. Our extensive simulation experiments using timeta-bles and route maps for 9,090 railway stations of 172railway companies demonstrated that the RouteDetectorsuccessfully identified routes used for a trip by train, andthe average number of identified routes became close toone if the number of stations used on a trip was more thansix. These results quantitatively support that the attack isfeasible.

10

Acknowledgements

A part of this work was supported by JSPS Grant-in-Aid for Challenging Exploratory Research (KAKENHI),Grant number 15K12038.

References

[1] L. Cai and H. Chen, “TouchLogger: InferringKeystrokes On Touch Screen From SmartphoneMotion,” in The 6th USENIX Workshop on Hot Top-ics in Security (HotSec), 2011.

[2] E. Owusu, J. Han, S. Das, A. Perrig, andJ. Zhang, “ACCessory: Password Inference usingAccelerometers on Smartphones,” in The TwelfthWorkshop on Mobile Computing Systems and Ap-plications (HotMobile), 2012.

[3] Z. Xu, K. Bai, and S. Zhu, “TapLogger: Infer-ring User Inputs on Smartphone Touchscreens Us-ing On-board Motion Sensors,” in The fifth ACMconference on Security and Privacy in Wireless andMobile Networks, 2012.

[4] E. Miluzzo, A. Varshavsky, S. Balakrishnan, andR. R. Choudhury, “TapPrints: Your Finger TapsHave Fingerprints,” in The 10th International Con-ference on Mobile Systems, Applications, and Ser-vices (MobiSys), 2012.

[5] S. Dey, N. Roy, W. Xu, R. R. Choudhury, andS. Nelakuditi, “AccelPrint: Imperfections of Ac-celerometers Make Smartphones Trackable,” inThe 2014 Network and Distributed System Security(NDSS) Symposium, 2014.

[6] Y. Michalevsky, D. Boneh, and G. Nakibly, “Gyro-phone: Recognizing Speech from Gyroscope Sig-nals,” in The 23rd USENIX Security Symposium,2014.

[7] A. Das, N. Borisov, and M. Caesar, “Do YouHear What I Hear?: Fingerprinting Smart DevicesThrough Embedded Acoustic Components,” in The2014 ACM SIGSAC Conference on Computer andCommunications Security (CCS), 2014.

[8] Y. Michalevsky, G. Nakibly, A. Schulman,and D. Boneh, “Powerspy: Location trackingusing mobile device power analysis,” CoRR,vol. abs/1502.03182, 2015.

[9] M. C. Gonzalez, C. A. Hidalgo, and A.-L. Barabasi,“Understanding individual human mobility pat-terns,” Nature, vol. 453, pp. 779–782, June 2008.

[10] Y. Gu, A. Lo, and I. Niemegeers, “A Survey ofIndoor Positioning Systems for Wireless PersonalNetworks,” in IEEE Communications Surveys &Tutorials, 2009.

[11] E. Miluzzo, N. D. Lane, K. Fodor, R. Peterson,H. Lu, M. Musolesi, S. B. Eisenman, X. Zheng,and A. T. Campbell, “Sensing Meets Mobile SocialNetworks: The Design, Implementation and Evalu-ation of the CenceMe Application,” in The 6th ACMconference on Embedded network sensor systems(SenSys), 2008.

[12] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexi-ble and Fine-Grained Mandatory Access Control onAndroid for Diverse Security and Privacy Policies,”in The 22nd USENIX Security Symposium, 2013.

[13] S. Chakraborty, C. Shen, K. R. Raghavan,Y. Shoukry, M. Millar, and M. Srivastava, “ip-Shield: A Framework For Enforcing Context-Aware Privacy,” in The 11th USENIX Symposiumon Networked Systems Design and Implementation(NSDI), 2014.

11