Location Attestation: Jitter Based Attestation
IP Available
Code: Working code implemented natively in Android and iOS and tested on a wide variety of devices. Server-side implementation in Node.js.
Background
Determining the location of a device on which a capture application (or any other application for that matter) is running is a surprisingly complex problem. While mobile operating systems provide an application access to a device’s location (pending a user’s permission to do so), the location itself can be altered by either physically spoofing the location signal received by the device or, a far more prevalent approach, by circumventing the operating system’s software. While root-detection measures can be taken, we have to assume these are imperfect. For the purposes of the methods in this section, we assume a device has been rooted or jail-broken successfully, and in a way, which bypasses all known detection mechanisms.
A primer on GPS readings and coordinates
A GPS sensor cannot guarantee a precise location, and as such provide a number of reading pertaining to its confidence of the location. These measurements include the horizontal and vertical accuracies in metres.
At the start of measurement (when an app with location is first opened), the accuracy is generally great, and it improves with time. As the correct location is honed in on, the reported location as well as the reported accuracy differ. That is, the reported location moves between readings.
The locations are provided are latitude and longitude, which are measurements in degrees, between -180 and 180. As such, they are not units of length, but are coordinates pinpointing a location on a sphere.
In Figure 27, it can be seen that moving west by one unit of latitude in Africa would constitute further distance measured in kilometres than by moving one unit of latitude in North Europe.
Real distance moved across the surface of the sphere – the path that you would take if driving from A to B – can be calculated with the Haversine formula https://en.wikipedia.org/wiki/Haversine_formula.
Using the haversine formula, we define the distances as
For example, in the above diagram we have d1_2 = haversine(Reading 1, Reading 2). We then use the standard formulas for finding the mean movement, and variance of the movements:
Sample mean movement between readings
And the sample variance
Using jitter for attestation
We have found that an algorithm applied to jitter data can consistently differentiate between real and mocked location readings. The full algorithm and its implementation are available for review under NDA.
Performance
How the algorithm performs under some edge-cases
Scenario A: on a train/other mode of transport
The algorithm will correctly identify that the GPS readings are genuine, since there will be a lot of movement.
Scenario B: in a field – where exact GPS lock may be likely
We have tested the algorithm under these circumstances and discovered that there is still suitable variation in the reported locations for the location to be identified as genuine. We are aware that further research or tweaking may be required here.
Scenario C: in a built-up area
This is the one of the perfect scenarios for the algorithm – GPS signals bounce off buildings and so an accurate location lock is difficult to attain. Therefore, a lot of movement and uncertainty of location will arise.
Scenario D: in a building
Similar to scenario C.
Scenario E: in a cave
One of two things will happen here: a device will attempt to report a location, in which case it’ll be wildly inaccurate, and hence move around a lot between readings. The second option is that the device will report that it does not have location information, in which case, by definition, it is not being mocked.