Enhancing the Privacy and Computability of Location-Sensitive Data for Context Authentication

by   Pradip Mainali, et al.

This paper proposes a new privacy-enhancing, context-aware user authentication system, ConSec, which uses a transformation of general location-sensitive data, such as GPS location, barometric altitude and noise levels, collected from the user's device, into a representation based on Locality-Sensitive-Hashing (LSH). This enables numerical computation on the hashed data, which is used by a machine learning classifier to model user behaviour for authentication. We present how ConSec supports learning from categorical as well as numerical data, while addressing a multitude of on-device and network-based threats. ConSec is implemented for the Android platform and an extensive evaluation is presented using data collected in the field from 35 users. Experimental results are promising, with a small equal error rate of 2.5 privacy analysis of the proposed scheme before, lastly, concluding with some future areas of research.



There are no comments yet.


page 9


Differentiated context-aware hook placement for different owners' smartphones

A hook is a piece of code. It checks user privacy policy before some sen...

Resilient Collaborative Privacy for Location-Based Services

Location-based Services (LBSs) provide valuable services, with convenien...

WristAuthen: A Dynamic Time Wrapping Approach for User Authentication by Hand-Interaction through Wrist-Worn Devices

The growing trend of using wearable devices for context-aware computing ...

Location-based Behavioral Authentication Using GPS Distance Coherence

Most of the current user authentication systems are based on PIN code, p...

Active Authentication on Mobile Devices via Stylometry, Application Usage, Web Browsing, and GPS Location

Active authentication is the problem of continuously verifying the ident...

Please Forget Where I Was Last Summer: The Privacy Risks of Public Location (Meta)Data

The exposure of location data constitutes a significant privacy risk to ...

Device-Free User Authentication, Activity Classification and Tracking using Passive Wi-Fi Sensing: A Deep Learning Based Approach

Privacy issues related to video camera feeds have led to a growing need ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Secure and usable mobile authentication mechanisms are critical to a multitude of applications, such as internet banking, email, and social media. Traditional knowledge-based authentication mechanisms, such as PINs, patterns and passwords, remain fraught with concerns surrounding memorability, re-use, sufficient entropy, and shoulder-surfing attacks (Pearman et al., 2017; Stajano, 2011). Meanwhile, token-based methods, e.g. one-time password (OTP) generators and key fobs, can be lost or stolen while remaining costly to produce, maintain and replace (O’Gorman, 2003). Biometrics, such as fingerprint and facial authentication, have become widely-deployed on modern mobile handsets; however, environmental factors, like moisture, injury, skin complexion, and lighting can significantly increase error rates (De Luca and Lindqvist, 2015). Traditional approaches also feature an overarching drawback: the user is authenticated only once, after which all access to assets and services and granted thereafter. Such all-or-nothing authentication has prompted both security and usability concerns in the literature (Hayashi et al., 2013; Riva et al., 2012; Harbach et al., 2014; Gupta et al., 2012).

Context authentication systems have arisen largely from these concerns, which transparently collect and compute an authentication score from mobile device data, such as time of access, location (latitude and longitude), nearby Wi-Fi access points (APs) and Bluetooth devices, and mobile network data (Shi et al., 2011; Hayashi et al., 2013; Gupta et al., 2012; Miettinen et al., 2014). Such systems may infer the user’s authentication status directly, i.e. accept/reject (Shi et al., 2011), or used to set access control policies or authentication challenge strength based on the location’s similarity with previously observed behaviour (Hayashi et al., 2013; Miettinen et al., 2014). Unfortunately, context authentication systems necessitate collecting swathes of privacy-sensitive information. This is especially problematic if the authentication procedure is performed remotely, say, in a cloud-based model, and data is subsequently exfiltrated and disclosed in a security breach, or misused for other purposes without users’ consent. Several surveys have already demonstrated users’ reticence in disclosing location data used in many context authentication schemes (Fisher et al., 2012; Danezis et al., 2005; Barkhuus and Dey, 2003). In particular, Fisher-Short et al. (Fisher et al., 2012) show that users tend to deny permission to applications to access location data from concerns of whether it is stored remotely and shared surreptitiously with third-parties.

In light of this, we present a novel context authentication system, ConSec, which protects the confidentiality of location-sensitive data using a transformation based on the Super-bit Location-Sensitive Hashing (LSH) proposal by Ji et al. (Ji et al., 2012). SB-LSH is a dimensionality reduction algorithm wherein resulting LSH values reveal only the relative distance between the user location values, without disclosing the exact distance in meters or their precise location on Earth. The advantage of using LSH values is that data computability is preserved and, hence, machine learning algorithms can be applied to model the user’s behaviour. However, LSH operates on only numerical information, such as GPS coordinates, nor has it been applied to user authentication. In this work, we demonstrate how ConSec enables computation over numerical and categorical data, e.g. Wi-Fi ESSIDs, to flexibly support a range of input modalities for privacy-enhancing contextual authentication. We also present the results of a trial of ConSec with 35 participants, during which we evaluated its effectiveness with respect to error rates and against a variety of attacks, such as triangulation.

The main contributions of this paper is a new approach to contextual authentication by protecting the confidentiality of numerical location-sensitive data, such as GPS coordinates, using SB-LSH (Ji et al., 2012). ConSec can learn user authentication models from protected numerical and categorical data using standard machine learning algorithms with low error rates. This paper begins with a review of existing contextual and privacy-enhancing continuous authentication schemes in Section 2. Section 3 then describes the architecture of the ConSec, including the threat model and the modalities used. Sections 4 and 5 describe the use of LSH and keyed HMACs for privacy-preserving behavioural modelling from numerical and categorical data respectively for contextual authentication. Next, an evaluation of the proposed scheme is presented from a user base of 35 users in Section 6, which is followed by a security and privacy analysis in Section 7. Lastly, Section 8 concludes this paper, including a discussion of future research directions.

2. Related Work

This section explores the state-of-the-art with respect to contextual authentication, focussed upon in this work, and privacy-enhancing continuous authentication generally. We summarise notable proposals and their contributions.

2.1. Contextual Authentication

The CASA system proposed by Hayashi et al. (Hayashi et al., 2013)

focuses on reducing the strength of user-authentication challenges based on the current location of the user and previously observed behaviour. The authentication strength is determined by the presence of the user in location of varying perceived risk, such as at home or at work. CASA applies a Naïve Bayes classifier to model user behaviour from GPS location, which produces a probability value based on their past behaviour in order to determine the authentication strength, e.g. password, PIN or even no challenge. The system is trialled with 32 users, where a location classification accuracy of 92% is reported with 68% of active authentication attempts being reduced.

SenGuard by Shi et al. (Shi et al., 2011) uses five modalities—location, cell tower ID, voice, touch, and motion-based activity recognition (cycling, walking, stationary, etc.)—from which a multitude of features are extracted, including touch gestures, GPS correlation, and Levenshtein distance of cell IDs in a sliding window. From this, the system computes an aggregated authentication decision from individual, modality-specific classifiers, which is used to authenticate the user in a binary fashion, i.e. accept or reject. SenGuard is evaluated with a user base of four participants, yielding a classification accuracy of 95.8–97.1% depending on the user.

Gupta et al. (Gupta et al., 2012) present the first proposal for setting mobile device access control policies based on users’ contexts. The authors use features based on Context of Interest (CoI), corresponding to locations a user visits frequently or spends significant amounts of time in. CoIs are generated from clusters of GPS coordinates, Wi-Fi access points (APs) and nearby Bluetooth devices, which are compared with past data using similarity metrics, such as set intersection, in conjunction with manually set thresholds. The generated CoIs are then divided into ‘safe’ and ‘unsafe’ locations, e.g. at home and out shopping respectively, which are used for dynamically setting access control policy profiles. An evaluation with 37 users resulted in average precisions of 0.854 (safe locations) and 0.311 (unsafe), and recalls of 0.917 (safe) and 0.341 (unsafe).

Miettenen et al. (Miettinen et al., 2014) present ConXsense that uses contextual data for risk-based device locks, similar to (Hayashi et al., 2013), and fine-tuning mobile device access control policies. The authors also generate CoI features, but, unlike (Gupta et al., 2012)

, these are inputted to a classifier with ground truth labels drawn from user input. The authors evaluate the system using data from 15 users and Random Forest, k-Nearest Neighbour (kNN), and Naïve Bayes classifiers, yielding an approximate 0.70 true positive rate (TPR) and 0.10 false positive rate (FPR).

Witte et al. (Witte et al., 2013) propose a system for scoring authentication behaviour based on the device’s GPS location, accelerometer, magnetic field, light, battery and sound measurements. Next, the raw sensor values are pre-processed before extracting features, such as the arithmetic mean, median, maximum and minimum values. These are aggregated with system-level features, such as screen status and boot and shutdown times—all of which are inputted to an SVM classifier trained on user data collected over a three-day period. An evaluation is performed using data from 15 participants, with an average reported F1-score of 0.85.

2.2. Privacy-Enhancing Continuous Authentication

Shahandashti et al. (Shahandashti et al., 2015)

propose a scheme for computing authentication decisions remotely from encrypted feature vectors using Paillier’s homomorphic encryption scheme 

(Paillier, 1999). An encrypted behavioural model is stored on a remote server and a decision is computed from encrypted feature vectors transmitted from the user’s device without revealing the underlying features to an honest-but-curious server. The decision is computed from the dissimilarity between incoming features and the stored user profile using the average absolute distance (AAD); the user is authenticated if the AAD similarity falls within a threshold determined by the service provider. While a security proof is provided, however, the scheme is neither implemented nor evaluated.

Domingo-Ferrer et al. (Domingo-Ferrer et al., 2015) develop the work from (Shahandashti et al., 2015) by presenting an additional approach based on the set intersection of homomorphically encrypted feature vectors to authenticate users. The set intersection is used to compute the dissimilarity function between the encrypted user profile and incoming feature vectors to support categorical features, beyond only numerical features supported in (Shahandashti et al., 2015). The authors provide a performance evaluation in which authentication takes 0.08–31.2 seconds depending on the number of input features (1–50 features respectively).

Sedenka et al. (Sedenka et al., 2015)

construct protocols for the outsourcing of the scaled Manhattan (L1) and Euclidean (L2) distances and principal component analysis (PCA) using garbled circuits and homomorphic encryption for use in continuous authentication. The work tackles their computation over an incoming feature vector and stored user model against an honest-but-curious server. The authors provide a security analysis and performance evaluation using a consumer laptop and smartphone, the results of which yield a communication and time penalty of 4–174MB and 0.85s–45.9s respectively based on the submitted data size.

Halunen and Vallivaara (Halunen and Vallivaara, 2016) present a privacy-enhancing authentication system based on keystroke dynamics with order-preserving symmetric encryption (OPSE) and, like (Shahandashti et al., 2015), Paillier’s partially homomorphic encryption (PHE) scheme (Paillier, 1999). The proposal extracts four features regarding the down-down, up-down and down-up times of each keystroke, along with the entered string itself. Next, PHE is used to compute the AAD between the sample and the stored template values, while OPSE is used to enable comparisons between the sample and various thresholds to fine-tune security and usability. An evaluation is conducted with 20 users, with a reported best-case accuracy of 91.5%.

2.3. Discussion

Many existing contextual authentication proposals, summarised in Table 1, operate upon data in unprotected form, which gives rise to privacy concerns especially when authentication decisions are outsourced to a remote server that may attempt to infer users’ behaviour (Shahandashti et al., 2015; Domingo-Ferrer et al., 2015; Sedenka et al., 2015). As noted previously, studies have already shown that users are generally reluctant towards disclosing, in particular, their GPS location to device applications (Fisher et al., 2012; Danezis et al., 2005; Barkhuus and Dey, 2003; Cvrcek et al., 2006). Users often toggle GPS location depending on the sensitivity the location they visit, irrespective of the application (Barkhuus and Dey, 2003). Fisher-Short et al. (Fisher et al., 2012) also showed that, when permission is denied to an application that accesses GPS location, it is principally from concerns relating to whether location data is stored securely (remotely or on the device) and whether it is shared to other parties without user consent.

Proposals Data Modalities Error Rates
CASA (Hayashi et al., 2013) GPS Location 92% Acc.
SenGuard (Shi et al., 2011)
GPS Location, Voice,
Touch, AR
95.8–97.1% Acc.
Gupta et al. (Gupta et al., 2012)
GPS Location, Wi-Fi APs,
Bluetooth Devices
0.311–0.854 Pr.,
0.341–0.917 Re.
ConXsense (Miettinen et al., 2014)
GPS Location, Wi-Fi APs,
Bluetooth Devices
70% TPR, 10% FPR
Witte et al. (Witte et al., 2013)
GPS Location, Sys., AC,
MF, Sound, Light
0.85 F1-score
  • AC: Accelerometer, MF: Magnetic Field, Sys.: System Data, Acc.: Classification Accuracy, FPR: False Positive Rate, TPR: True Positive Rate, AR: Activity Recognition, Pr.: Precision, Re.: Recall.

Table 1. Related contextual authentication schemes.

Existing work on privacy-enhancing continuous authentication tends to rely on PHE, e.g. Paillier (Paillier, 1999), and garbled circuits for two-party computation (2PC) (Halunen and Vallivaara, 2016; Shahandashti et al., 2015; Domingo-Ferrer et al., 2015; Sedenka et al., 2015). However, challenges still remain with respect computational complexity and storage overhead, exemplified by worst cases of 31.2s and 45.9s to compute authentication decisions for (Domingo-Ferrer et al., 2015) and (Sedenka et al., 2015) respectively. Storage complexity also remains problematic, with 4–175MB required for computing a single authentication decision in (Sedenka et al., 2015). PHE-based schemes also face inherent challenges regarding the supported arithmetic operations for learning from data, i.e. only additions for Paillier-based systems. Fully homomorphic encryption (FHE) (Gentry, 2009), meanwhile, has been deemed too cumbersome in existing work for high-frequency, high-dimensional classification tasks like continuous authentication (Sedenka et al., 2015; Shahandashti et al., 2015).

Lastly, we note that the work in (Halunen and Vallivaara, 2016) focuses on privacy-preserving keystroke-based authentication, which necessitates interaction with the user. Rather, the focus of this work is context authentication from device sensors without interaction from the user. Ultimately, we aim to demonstrate a simpler approach to privacy-enhancing, zero-interaction context authentication based on keyed HMACs and the Super-Bit Locality-Sensitive Hashing (SB-LASH) algorithm by Ji et al. (Ji et al., 2012), without resorting to the complexities of PHE, FHE and 2PC/MPC focussed upon in existing solutions.

3. ConSec Design

In this section, we present the design of the ConSec architecture for context authentication, beginning with a high-level overview before proceeding to an analysis of the threat model and the privacy-sensitive modalities considered in this work.

3.1. System Overview

Figure 1. High-level architecture: (a) ConSec context-aware authentication flow; (b) ConSec authentication algorithm.

Figure 1 illustrates the block diagram of the ConSec context-aware authentication system, comprising the ConSec-App on the smartphone for data collection and transmission, and the ConSec authentication algorithm (ConSec-Auth) executing on the authentication server. ConSec-App transforms categorical contextual data, such as nearby Wi-Fi ESSIDs and MAC addresses, using HMAC-SHA256 under a randomly generated, per-user key within the application, which we denote . Numerical location-sensitive data, such as the device’s GPS location and barometric altitude, is transformed using the Super-Bit LSH (SB-LSH) algorithm proposed in (Ji et al., 2012). The HMAC and SB-LSH transformed values are transmitted to ConSec-Auth, which computes the authentication score based on the user’s previously observed behaviour. We return to the complete set of contextual data collected by ConSec-App in Sections 3.3 and 5.

Figure 1(b) shows the block diagram of the ConSec-Auth algorithm, comprising enrollment and authentication phases. We build upon the principle that contextual data generally form clusters around locations frequently visited by the user, such as home, work, and so on, according to their day-to-day mobility patterns. The enrollment phase is used to construct the initial model that captures these mobility patterns; the model is used in the authentication phase to compute a real-valued authentication score, , of the user’s incoming behaviour that can be thresholded by the service provider according to their security requirements.

This work studies authentication under a service-based model, where features are computed locally on the device, i.e. the SB-LSH values for numerical data and HMAC values for categorical data, and transmitted to the ConSec server that computes a real-valued authentication score. This decision may be used to inform access to other services and assets held remotely, such as modulating the strength of active authentication required when synchronising corporate email and other documents between the server and device.

3.2. Assumptions and Threat Model

ConSec aims to provide lightweight, server-side context authentication for informing secure access to remote assets from mobile sensor data. The scheme is intended to allow a service provider to tailor access to sensitive assets based on the output probability without incurring the complexities of existing techniques, such as homomorphic encryption (Shahandashti et al., 2015; Domingo-Ferrer et al., 2015; Sedenka et al., 2015; Halunen and Vallivaara, 2016).

Server-side, we assume the existence of a service provider operating under the honest-but-curious model, which executes the scheme as intended but attempts to infer users’ behaviour based on the data samples it observes from their devices. The service provider may use any insights for unintended purposes, such as profiled advertising or selling the information to unauthorised third-parties without users’ consent. In other words, the goal is to provide context authentication for informing server-side access control while precluding the service provider’s ability to easily recover the actual measurements it receives. However, we note that, even under model whereby the server is wholly honest, the use of privacy-preserving context authentication also limits the impact of security breaches that lead to the unauthorised disclosure of plain-text measurements, and the publicity or legal repercussions that may follow. We also assume that the ConSec mobile application is available via a trusted application store.

On the device, we assume a trusted keystore and the ability to collect, transform and transmit sensor values securely. The keystore is used to hold certificates used to mutually authenticate the end-points for transmitting feature data across a standard network channel, e.g. Wi-Fi, securely using TLS. Both components may be instantiated using conventional security controls provided by modern mobile operating systems, such as application sandboxing, which we concentrate on this work. However, for further security assurances against kernel-mode (ring 0) adversaries, this may be realised using a trusted execution environment (TEE), as suggested in (Liu et al., 2012) and (Shepherd et al., 2017). We also consider a context-manipulating adversary (see Shrestha et al. (Shrestha et al., 2015)) that attempts to alter the conditions of the surrounding environment to control the measurements collected by the device. For example, the instantiation of rogue Wi-Fi APs with spoofed ESSIDs and MAC addresses to maliciously influence the authentication scoring algorithm. This forms the basis of the evaluation described later in Section 6.

3.3. Contextual Data

Modern mobile devices contain a varieties of sensors, such as GPS chips, magnetometers, accelerometers and pressure sensors, and related modules, e.g. Wi-Fi and Bluetooth, that can be used for collecting contextual data. The data types used by ConSec are described in the following subsections.

3.3.1. Geographic Location

The geographic location of the user is collected from the device’s GPS module or, if it is unavailable, using Android’s Network Location111Android Location Strategies: https://developer.android.com/guide/topics/location/strategies that returns recently observed GPS coordinates, or coordinates based on the Cell ID or Wi-Fi network location (in that order). The geodetic latitude () and longitude () values are first transformed to the Earth-Centre-Earth-Fixed (ECEF) Cartesian coordinate system accounting for the Earth’s ellipsoidal shape using the WGS84 model (—–, 2000). Equation 1 was used to transform the geodetic latitude , longitude and altitude cordinates to the ECEF coordinate system. The coordinates of a point in Cartesian coordinates on Earth’s surface are given by:




and the squared first-eccentricity (), the semi-major axis () and the semi-minor axis () are taken from WGS84: , m and m.

3.3.2. Barometric Altitude

Barometric pressure provides information regarding the height of the device from the sea level as atmospheric pressure is proportional to altitude; it is also measurable within enclosed spaces, e.g. buildings, where GPS coordinates may not be ascertained. The barometric altitude is calculated from the measured pressure, , reference pressure, , and temperature, , using the following formula from (Wallace and Hobbs, 1977):


ConSec-App uses data from the METAR (METeorological Aerodrome Reports)222METAR: https://www.aviationweather.gov/dataserver weather station for the reference pressure () and temperature ().

3.3.3. Noise Level

The average amplitude of the background noise is estimated from a three-second recording from the device’s microphone. This provides additional contextual information regarding the user’s location, which is also used in 

(Witte et al., 2013) for authentication. As an example, a quiet office environment will result in lower background noise collected by the device than a supermarket or similar retail environment.

3.3.4. Magnetic Fingerprint

The magnetic fingerprint at the user’s location consists of the geomagnetic field strength and the geomagnetic inclination angle computed from the device’s magnetometer and accelerometer sensors. Magnetic field data varies on the Earth’s surface, hence providing information about the user’s location: it is strongest at the poles and weakest at the equator. The magnetic inclination angle is the angle at which the magnetic field lines intersects with the surface of the Earth; it ranges from zero degrees at the equator to 90 degrees at the poles. The accelerometer data is used to find the orientation of the device with respect to the world coordinate system. The field data read from the magnetometer sensor is transformed to align with respect to the world coordinate system from which the magnetic inclination angle is computed.

3.3.5. Wi-Fi

The contextual data collected from Wi-Fi networks include the name and the MAC address of the router to which the phone is connected, the primary and secondary DNS settings of the router, the received signal strength indication (RSSI), and the list of Wi-Fi names and MAC addresses of nearby access points (APs).

3.3.6. Mobile Network

The data collected from a mobile network comprises the mobile network type (e.g. 2G, 3G etc.), RSSI, operator name, mobile network code (MNC), mobile network country code (MCC), location area code (LAC), and mobile network cell ID.

3.3.7. Bluetooth

The contextual data collected from the Bluetooth module includes the list of Bluetooth device names and MAC addresses detected within the vicinity of the device.

4. Enhancing the Privacy of Contextual Data

Evidently, location-sensitive data carries private information regarding the user’s whereabouts that could be exploited (e.g., via unauthorised profiling and reselling), particularly if authentication decisions are computed remotely. This is a major shortcoming of many existing contextual authentication schemes identified in Section 2. As such, to enhance the privacy of the location-sensitive information listed previously, numerical contextual data is subject to the SB-LSH algorithm by Ji et al. (Ji et al., 2012), while keyed HMACs are used for categorical data. The following sections describe these procedures in further detail.

4.1. Numerical Data

The SB-LSH algorithm (Ji et al., 2012) is computed from seven location-sensitive features: the geographic location ; the barometric altitude; the noise level; the magnetic field strength; and the magnetic inclination angle. This information is salted with randomly generated data, , to create an eight-dimensional vector. SB-LSH is initialised by generating eight-dimensional vectors

sampled from the normal distribution

and orthogonalized in blocks of eight vectors with the Gram-Schmidt process. The data is then projected onto those LSH vectors to compute the location-sensitive hash:

, where is defined as:


This results in a -bit hash code . It is also shown in (Ji et al., 2012) that the Hamming distance between the two hash values of locations and is proportional to the true angular distance between the two locations:


Where is constant; hence, the cosine distance or similarity between the hash values can be computed from the location-hash itself. The randomly initialized LSH vectors are used to compute the location-hash. An issue then arises pertaining to setting the value of , which depends on the security strength and the accuracy that is needed in computing the distance from the location-hash. In both cases, a large value of is desired; however, on the other hand, a large increases the amount of data needed to be transmitted and stored on the server. A value of that gives a reasonable error on computing the distance without compromising security is thus needed.

128 41.908 65.709
256 35.132 44.051
512 26.654 32.236
1024 17.655 23.181
2048 13.355 17.049
4096 9.785 12.648
8192 7.568 9.722
16384 6.160 7.874
Table 2. Accuracy variation for bits in LSH.

Experiments were performed to test statistically the error on computing the distance from the location-hash for different values of

. One thousand different location (i.e. latitude and longitude) pairs were generated randomly, where the first location data in the pair was generated randomly and the second data in the pair was generated to be km away from the first one. A location pair with a small distance was generated because the mobility of users is generally limited to geographically small regions. The true and approximate central angles between the locations in the pair were computed from the actual location values and the location-hashes respectively. The experiment was repeated for ten thousand different instances of the SB-LSH algorithm. Table 2 shows the mean absolute error (MAE) and root-mean-square error (RMSE) for different values. Since the central angle between the locations is known, the error in computing the distance between the locations can be computed. For example, using the great circle distance formula, the distance () between the locations is given by:


where is the central angle between the locations in radians computed from actual location values and km is the mean radius of Earth. The error in computing the distance from location-hashes is given by:


where is approximate central angle between the locations in radians computed from the location-hashes and is true central angle computed from actual location values. Table 2 shows that both the MAE and RMSE reduces with larger values. The error is larger than the actual distance of km for smaller than 2048. In this paper, we used for our experiments.

4.2. Categorical Data

HMAC-SHA256 is computed upon the categorical data types, which is keyed under a randomly generated, 128-bit long-lived key, , within the ConSec mobile application. is unique to each application and should, ideally, be generated and stored securely in the device’s keystore. The following section describes how HMAC and SB-LSH protected data is used by the ConSec authentication algorithm.

5. Authentication Algorithm

This section details how users’ authentication models are learned from SB-LSH and HMAC-applied contextual data. Broadly, this process comprises two stages involving feature extraction and the learning algorithm to compute the user models.

5.1. Feature Extraction

Contextual Modality Feature Type Data Type
Location-hash N
Wi-Fi state OHE C
Wi-Fi router MAC OHE C
Wi-Fi network ID OHE C
Wi-Fi frequency OHE C
Wi-Fi router IP OHE C
Wi-Fi router DNS-1 OHE C
Wi-Fi router DNS-2 OHE C
List of Wi-Fi names OHE C
List of Wi-Fi MACs OHE C
List of Wi-Fi frequencies OHE C
SIM state OHE C
Network data state OHE C
Network data type OHE C
Network RSSI V N
Network operator name OHE C
Network LAC OHE C
Network Cell ID OHE C
Bluetooth device names OHE C
Bluetooth device MACs OHE C
Day index OHE C
Time V N
Table 3. Location-based contextual data.

Table 3 lists the 32 contextual data types employed by ConSec. The LSH data is pre-processed to compute the feature wherein the cosine similarity values are computed with respect to a reference value collected during the enrollment phase. The modal, i.e. most occurring, LSH value from the enrollment samples is used as this reference. For categorical data, one-hot-encoded (OHE) features (Pedregosa et al., 2011) are created to map categorical values to numerical representations to enable computation. OHE results in a sparse matrix as an output, where each column corresponds to one possible value of the data. The feature type indicated by V in Table 3

uses the value from the contextual data modality directly. The feature vectors are standardised to zero mean and unit variance once computed.

5.2. Learning User Authentication Models

Computed features are subsequently inputted to a k-means clustering algorithm, which is used with the initialization technique proposed in 

(Arthur and Vassilvitskii, 2007). Clustering was employed from the assumption, based from related work (Hayashi et al., 2013; Miettinen et al., 2014; Gupta et al., 2012), that users’ contextual data has a tendency to form clusters according to the mobility of the user. We are interested in detecting the centroid of these clusters, thus k-means clustering was used; however, this necessitates the number of clusters, , to be specified. As such, the algorithm is executed for different values of , and stops for a value of , if the rate of the clustering error falls below a threshold, . In the experiments, a threshold of (5%) was used. Additionally, we only keep clusters with the population density higher than some threshold. We used in our experiment so that the clusters that are less visited by the user are removed from the user models.

5.3. Authentication Procedure

ConSec-Auth is ready to enter the authentication phase once the user models are computed, as shown previously in Figure 1b. This comprises an eight stage process illustrated in Figure 2 and described as follows:

Figure 2. Information flow for user authentication.
  1. Data Collection. Data is sampled by ConSec-App at 10 minute intervals from the modalities listed in Table 3.

  2. Device Pre-Processing. Next, ConSec-App applies SB-LSHs and HMACs to numerical and contextual modalities respectively, as described in Sections 4.1 and 4.2.

  3. Data Transmission. The SB-LSH and HMAC values are transmitted over a secure channel between ConSec-App and ConSec-Auth using TLS.

  4. Verification and Decryption. The server decrypts using its private portion, and uses to verify the authentication tag of the the encrypted data before decrypting the feature vector contained therein.

  5. Feature Extraction. This follows the same procedure a described in Section 5.1 to produce a feature value .

  6. Feature Matching. ConSec-Auth computes the Euclidean (L2) distance between and the cluster centroids of the user’s model. The smallest distance () is selected.

  7. Normalisation. The smallest distance is normalized as , where is a normalizing constant. The score is computed as (), providing the score in the range [0, 1].

  8. Score Output. The authentication score in the range [0, 1] is generated as output.

5.4. Model Refreshing

Some contextual data may change over time due to behavioural shifts in the users’ mobility patterns; for example, after joining a new workplace or moving house in a new town/city where the old locations no longer apply. This applies, not only to changes in the users’ GPS locations, but also the lists of detected Wi-Fi APs, nearby Bluetooth devices, and background noise. Consequently, users’ authentication data models should be updated regularly to reflect such changes. In this work, a weekly interval was chosen as a default to re-evaluate behavioural shifts; the model of the previous week is retained if 33.3% of the contextual data is predicted with higher accuracy (assuming the user spends at least 8 out of 24 hours at home or office).

6. Experimental Results

In this section, experimented are presenting for evaluating the effectiveness of ConSec for user authentication. The experiments were conducted using contextual data collected from 35 participants.

6.1. Data Collection

Participation emails were sent to 250 employees within a European-based US technology company, resulting in 35 users who enrolled in the trial; no incentives were offered for participation. Participants were requested to install and launch the ConSec application on their primary smartphone, after which no further interaction was required; users were able to start/stop data collection at will and withdraw at any time by uninstalling the application. Prior to this, participants were informed about types of data collected; that it would be stored alongside an anonymous, randomly-generated user ID; and an explanation of how the collected data itself was protected on the server. Supplementary material was also distributed via email. The data collection period lasted five weeks.

Upon installation, the application randomly generated unique SB-LSH parameters and for the keying HMACs, which were held only on the device. The application collected contextual data at 10 minute intervals, which is encrypted under AES in GCM mode using a key, , generated randomly for each message. is then encrypted using asymmetric encryption (RSA-2048) using the ConSec certified public-key, , contained within the application, and transmitted to the server which possesses the private portion. Both the data and the encrypted are transmitted as a single message, , over TLS to the authentication server. This is listed in Equations 8 and 9.


To minimise battery consumption, the application placed sensors into the low-power mode immediately after collecting the contextual data because of the low sampling frequency (once every 10 minutes). Preliminary experiments on a single device showed that ConSec-App consumes a negligible (1%) amount of power, indicated by the power management metrics provided by the Android OS. The encrypted contextual data was uploaded to a server on a weekly basis over TLS with an anonymous user ID generated by ConSec-App. The encrypted data was stored on a private corporate machine, with access granted only to the authors of this work.

6.2. Sensitivity to Inaccurate Inputs

Figure 3. ROC curves for (a) 3, (b) 5, (c) 7 and (d) 9 numbers of the modified contextual data modalities (averaged across all participants).

Unlike previous approaches that rely upon supervised learning, e.g. CASA (Hayashi et al., 2013), ConXsense (Miettinen et al., 2014) and SenGuard (Shi et al., 2011), whereby the algorithm is trained using labels collected from user input, ConSec is underpinned by clustering, i.e. unsupervised learning. Evaluating the performance of clustering algorithms is non-trivial compared with computing the precision, recall, or similar metric drawn from counting the number of true/false positives/negatives in a similar fashion (Pedregosa et al., 2011).

In this work, we conducted an evaluation of the proposed algorithm to measure the sensitivity of ConSec to inaccurate values from varying numbers of contextual modalities. This is to evaluate the algorithm’s robustness to values modified by the adversary listed in Section 3.2. For each sample vector of contextual data, randomly selected modalities were modified with the aim of determining the effect on ConSec’s error rates. To this end, Receiver Operating Characteristic (ROC) curves were plotted for the True Positive Rate (TPR) and False Positive Rate (FPR) to assess the effect of compromised samples on generating malicious acceptances/positives and reducing legitimate user acceptances.

For the evaluation, we selected a subset of samples corresponding to top 100 closest to the cluster centroids from the training and testing sets using the L2-distance. These samples are labelled as positive samples that should be accepted by the system. Then, some -number of data fields in these samples are modified—using the procedure described below—and labelled as negative samples that should be rejected by the system. Our main aim is to find the robustness of the system to number of data fields that needs to be predicted correctly by the adversary to be authenticated by the system. This process was repeated for distinct trails for different combinations of data fields for three, five, seven and nine modified fields. The process was repeated across all users.

To modify the categorical data fields, e.g. Wi-Fi ESSIDs, the HMAC values were modified to a random base 64-encoded string. For numerical data, the SB-LSH values were modified to a random binary string. Figure 3 shows the ROC curve using inaccurate data from three, five, seven and nine contextual modalities. Evidently, as the number of contaminated fields increases, the detection is reflected by increasing TPR values approaching an ideal system of TPR=1.0, where modified data was detected correctly as false access. For seven contaminated contextual data fields, the performance of TPR of 97.5% and FPR of 2.5% (peak on the top left corner of the graph) or equal error rate (EER) of 2.5% is achieved. In essence, the results suggest that approximately 19 of 26, i.e. 73%, contextual data fields must be accurate in order to be authenticated positively by the system.

7. Privacy and Security Analysis

In this section, we present an analysis of the privacy and security properties offered by ConSec.

7.1. Privacy Analysis

For categorical data modalities, ConSec uses HMACs directly in order to model user behaviour, which is keyed under a randomly generated, application-specific key, , assumed to be stored securely on the device. Assuming the use of a secure cryptographic hash function, e.g. SHA-256, this avoids disclosing the actual underlying values to an observant server; moreover, the server does not possess , thus precluding the use of dictionary attacks.

Regarding the use of SB-LSH for numerical data, we note that some information could be leaked based on SB-LSH hashes leaked previously in conjunction with knowledge of their distances in reality. SB-LSH reveals the angular distance between location vectors; the actual locations on Earth’s surface are masked. As such, assuming the SB-LSH outputs at night and midday correspond to home and office locations respectively, and these locations are learned from a third source, e.g. social media profiles, can we infer other locations via triangulation, as shown in Figure 4?

Figure 4. Triangulation to derive unknown location, , from two known locations, and . Only distances from SB-LSH values and are known for with respect to and .

Suppose locations and correspond to the user’s home and office locations respectively, and the actual GPS coordinates of these locations are known. The issue pertains to the accuracy with which the latitude and longitude values of unknown location can be triangulated. From location-hashes of , and , we can compute distances (between and ) and (between and ) and solve for the latitude and longitude values for unknown location . This can result in locations either or . We used the chord distance given in Eq. 6 to compute the distance between the locations, where the approximate angle can be computed from the location-hashes and, , the mean value of the radius of the Earth. The accuracy with which can be localised depends on how accurately and can be computed from the location-hashes. Consequently, may be computed with some accuracy, to be determined by the confusion regions indicated with dotted circles of some radius value . The larger error in computing and , the larger ; thus, the unknown location cannot be localised precisely, hence offering greater privacy to the user.

distance (km)
MAE RMSE Mean Std. Dev.
5 2.826 3.266 -1.109 3.804
10 3.908 4.776 -1.645 4.616
25 9.785 12.648 -2.643 12.344
50 14.779 18.819 -4.683 18.588
100 26.258 33.389 -9.417 29.975
500 100.980 124.377 -51.619 113.846
1000 181.192 230.074 -96.341 212.993
Table 4.

Mean Absolute Error (MAE), Root-Mean-Square-Error (RMSE), Mean, and Standard Deviation of errors in computing distances from SB-LSH hashes for varying actual distances in kilometers.

We show that the errors in computing distances, e.g. , from the location-hashes are non-uniform and increase for larger actual distances. To show this, we perform simulations using randomly generated pairs of latitude and longitude values with a fixed distance between them. The SB-LSH hashes are computed for the pair values, and the distance between the locations is computed from the location-hashes. The errors in distances are computed using Eq. 7. Table 4 shows the MAE (Mean Absolute Error), RMSE (Root Mean Square Error), Mean and standard deviation of the errors in computing distances for the differing distances between the pairs of , , , , and kilometers. We used for the LSH algorithm as suggested in Section 4. The table shows the error is larger when the location to be estimated is at a larger distance. For example, when is at and kilometers from or , the error in computing the distances from the location-hashes have MAE of and kilometers respectively. Hence, if the unknown location is at a larger distance, it can be localised with a lower accuracy. This is because, if the angles between the unknown and known locations are greater, the number of bits to be matched when computing the Hamming distance between the SB-LSH values is greater as compared to the smaller angle between them. Hence, the error is accumulated over the bins represented by the corresponding bits, resulting in a larger error in computing the angle and hence the distance between the locations. While the distance of an unknown location is small, there is also a minimum error on computing the actual location, which is determined by the value of chosen for the LSH algorithm. For , the MAE is kilometers, hence locations that are closer than kilometers cannot be localised with greater accuracy.

Besides the MAE, the actual distribution of the distance errors is also important; uniformly distributed error is desirable such that any an unknown location cannot be localised with varying probability. Figures 

5 and 6 show the histogram of distance errors for actual distance of and kilometers respectively with the bin size of meters. The histogram of the distance error is approximately Gaussian, with a flat peak and wide variance; the highest distances fall at the tails of the distributions. That is, unknown locations that are far away cannot be localised with low error.

Figure 5. Histogram of errors in computing SB-LSH distances using a  km actual distance.
Figure 6. Histogram of errors in computing SB-LSH distances using an actual distance of 50km.

From the above, we can conclude that the location privacy of the user is largely preserved by SB-LSH, even if some information is leaked about the user with the assistance of supplementary knowledge about the users’ actual locations in reality. This uncertainty is determined primarily by the largest distance of the two nearest leaked locations. The largest distance determines the error ( in Figure 4) in estimating the unknown locations from SB-LSH hashes. Moreover, the error increases dramatically and proportionally to larger actual distances in reality. Therefore, the exact location is difficult to ascertain with reasonable error from SB-LSH values, even via triangulation.

7.2. Security Analysis

We now describe how ConSec thwarts a variety of security threats drawn from the threat model in Section 3.2.

7.2.1. Modified Input Modalities

One attack pertains to modifying the SB-LSH and HMAC values produced by ConSec-App with the aim of poisoning the model to deny future legitimate accesses or facilitate illegitimate accesses. While data is secured within transit using TLS, as described in Section 5, this does not preclude an adversary with the ability to alter some number of SB-LSH and HMAC values within ConSec-App itself. Our experimental results in Section 6.2 show that seven (27%) contextual modalities (of 26 in total) must be compromised simultaneously in order to significantly affect error rates.

7.2.2. Server-side Privacy

Evidently, using raw contextual values gives rise to privacy risks against honest-but-curious, server-side adversaries who aim to utilise users’ behavioural data for ulterior purposes, e.g. profiled advertising and re-selling. This extends to unauthorised disclosure if an attacker successfully exfiltrates data from the server and releases it publicly after exploiting some vulnerability. We signficantly reduce the impact of these cases as ConSec models and authenticates users’ behaviour directly from keyed HMAC and SB-LSH values rather than raw, unprotected values.

7.2.3. Replay Attack

Another threat to contextual authentication systems is where a network adversary re-sends previously observed messages containing the feature vectors (whether protected or not) to the server, with the aim of poisoning the behavioural model and influencing the authentication algorithm. This attack is protected through the use of a secure channel (TLS) between the application and authentication server with replay protection. Moreover, the contextual data vector includes a timestamp to ensure its recentness against replay attacks.

7.2.4. Lost or Stolen Device

Both lost and stolen smartphone scenarios are easily detected by ConSec as long as the stolen device does not come close to the user’s home, office or the places the user usually visits. For other locations, contextual data is different or invalid, hence the access is denied.

8. Conclusion

In this work, we presented ConSec—a privacy-enhancing, context-aware authentication system based on locality-sensitive hashing for retaining the privacy and computability of the underlying data. ConSec learns, models and authenticates users’ behaviour directly from protected values in an outsourced fashion without disclosing raw sensor measurements to the authentication server. We began with a detailed review of existing contextual authentication schemes and methods for preserving the privacy of sensitive input modalities for continuous authentication generally. We then showed how ConSec supports learning from both numerical and categorical data in a flexible manner using the SB-LSH algorithm by Ji et al. (Ji et al., 2012) and keyed HMACs, without incurring the potential complexities and restrictions of existing approaches to privacy-preserving methods, e.g. PHE, FHE and MPC. After describing the data types and authentication algorithms used by ConSec, experimental results were presented using data collected from 35 users in the field. This was followed by a series of analyses showing its effectiveness with respect to its error and resilience against a variety of attacks.


  • (1)
  • —– (2000) —–. 2000. Department of Defense World Geodetic System 1984: its definition and relationships with local geodetic systems. TR8350.2 (2000), 4:4.
  • Arthur and Vassilvitskii (2007) David Arthur and Sergei Vassilvitskii. 2007. K-means++: The Advantages of Careful Seeding. In Proceedings of the Eighteenth Annual ACM-SIAM Symposium on Discrete Algorithms (SODA ’07). 1027–1035.
  • Barkhuus and Dey (2003) Louise Barkhuus and Anind K. Dey. 2003. Location-Based Services for Mobile Telephony: a Study of Users’ Privacy Concerns.. In Interact, Vol. 3. 702–712.
  • Cvrcek et al. (2006) Dan Cvrcek, Marek Kumpost, Vashek Matyas, and George Danezis. 2006. A study on the value of location privacy. In Proceedings of the 5th ACM Workshop on Privacy in Electronic Society. ACM, 109–118.
  • Danezis et al. (2005) George Danezis, Stephen Lewis, and Ross J. Anderson. 2005. How much is location privacy worth?. In WEIS, Vol. 5. Citeseer.
  • De Luca and Lindqvist (2015) Alexander De Luca and Janne Lindqvist. 2015. Is secure and usable smartphone authentication asking too much? Computer 48, 5 (2015), 64–68.
  • Domingo-Ferrer et al. (2015) Josep Domingo-Ferrer, Qianhong Wu, and Alberto Blanco-Justicia. 2015. Flexible and robust privacy-preserving implicit authentication. In IFIP International Information Security Conference. Springer, 18–34.
  • Fisher et al. (2012) Drew Fisher, Leah Dorner, and David Wagner. 2012. Short paper: location privacy: user behavior in the field. In Proceedings of the second ACM workshop on Security and privacy in smartphones and mobile devices. ACM, 51–56.
  • Gentry (2009) Craig Gentry. 2009. A fully homomorphic encryption scheme. Vol. 20. Stanford University.
  • Gupta et al. (2012) Aditi Gupta, Markus Miettinen, N Asokan, and Marcin Nagy. 2012. Intuitive security policy configuration in mobile devices using context profiling. In International Conference on Privacy, Security, Risk and Trust. IEEE, 471–480.
  • Halunen and Vallivaara (2016) Kimmo Halunen and Visa Vallivaara. 2016. Secure, usable and privacy-friendly user authentication from keystroke dynamics. In Nordic Conference on Secure IT Systems. Springer, 256–268.
  • Harbach et al. (2014) Marian Harbach, Emanuel Von Zezschwitz, Andreas Fichtner, Alexander De Luca, and Matthew Smith. 2014. It’s a hard lock life: A field study of smartphone (un) locking behavior and risk perception. In Symposium on Usable Privacy and Security. ACM, 213–230.
  • Hayashi et al. (2013) Eiji Hayashi, Sauvik Das, and Shahriyar Amini. 2013. CASA: Context-Aware Scalable Authentication. In Proceedings of the Ninth Symposium on Usable Privacy and Security. 3:1–3:10.
  • Ji et al. (2012) Jianqiu Ji, Jianmin Li, Shuicheng Yan, Bo Zhang, and Qi Tian. 2012. Super-bit locality-sensitive hashing. In Advances in Neural Information Processing Systems. 108–116.
  • Liu et al. (2012) He Liu, Stefan Saroiu, Alec Wolman, and Himanshu Raj. 2012. Software abstractions for trusted sensors. In Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services. ACM, 365–378.
  • Miettinen et al. (2014) Markus Miettinen, Stephan Heuser, Wiebke Kronz, Ahmad-Reza Sadeghi, and N. Asokan. 2014. ConXsense: Automated Context Classification for Context-aware Access Control. In Proceedings of the 9th ACM Symposium on Information, Computer and Communications Security. 293–304.
  • O’Gorman (2003) Lawrence O’Gorman. 2003. Comparing passwords, tokens, and biometrics for user authentication. Proc. IEEE 91, 12 (2003), 2021–2040.
  • Paillier (1999) Pascal Paillier. 1999. Public-key Cryptosystems Based on Composite Degree Residuosity Classes. In Proceedings of the 17th International Conference on Theory and Application of Cryptographic Techniques. 223–238.
  • Pearman et al. (2017) Sarah Pearman, Jeremy Thomas, Pardis Emami Naeini, Hana Habib, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, Serge Egelman, and Alain Forget. 2017. Let’s Go in for a Closer Look: Observing Passwords in Their Natural Habitat. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. ACM, 295–310.
  • Pedregosa et al. (2011) F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. Grisel, M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg, J. Vanderplas, A. Passos, D. Cournapeau, M. Brucher, M. Perrot, and E. Duchesnay. 2011. Scikit-learn: Machine Learning in Python. Journal of Machine Learning Research 12 (2011), 2825–2830. http://scikit-learn.org/stable/index.html
  • Riva et al. (2012) Oriana Riva, Chuan Qin, Karin Strauss, and Dimitrios Lymberopoulos. 2012. Progressive Authentication: Deciding When to Authenticate on Mobile Phones.. In USENIX Security Symposium. 301–316.
  • Sedenka et al. (2015) Jaroslav Sedenka, Sathya Govindarajan, Paolo Gasti, and Kiran S Balagani. 2015. Secure Outsourced Biometric Authentication With Performance Evaluation on Smartphones. IEEE Transactions on Information Forensics and Security (TIFS) 10, 2 (2015), 384–396.
  • Shahandashti et al. (2015) Siamak F Shahandashti, Reihaneh Safavi-Naini, and Nashad Ahmed Safa. 2015. Reconciling user privacy and implicit authentication for mobile devices. Computers & Security 53 (2015), 215–233.
  • Shepherd et al. (2017) Carlton Shepherd, Raja Naeem Akram, and Konstantinos Markantonakis. 2017. Towards trusted execution of multi-modal continuous authentication schemes. In Proceedings of the 32nd ACM Symposium on Applied Computing. ACM, 1444–1451.
  • Shi et al. (2011) Weidong Shi, Jun Yang, Yifei Jiang, Feng Yang, and Yingen Xiong. 2011. Senguard: Passive user identification on smartphones using multiple sensors. In Wireless and Mobile Computing, Networking and Communications (WiMob), 2011 IEEE 7th International Conference on. IEEE, 141–148.
  • Shrestha et al. (2015) Babins Shrestha, Nitesh Saxena, Hien Thi Thu Truong, and N Asokan. 2015. Contextual proximity detection in the face of context-manipulating adversaries. arXiv preprint arXiv:1511.00905 (2015).
  • Stajano (2011) Frank Stajano. 2011. Pico: No more passwords!. In International Workshop on Security Protocols. Springer, 49–81.
  • Wallace and Hobbs (1977) J.M. Wallace and P.V. Hobbs. 1977. Atmospheric Science: An Introductory Survey. (1977), 103–104.
  • Witte et al. (2013) H. Witte, C. Rathgeb, and C. Busch. 2013.

    Context-Aware Mobile Biometric Authentication based on Support Vector Machines. In

    Emerging Security Technologies (EST), 2013 Fourth International Conference on. 29–32.