Add GNSS spoofing & jamming detection feature

[barbeau]

Summary:

As spoofing GNSS signals becomes an increasing area of concern, I’d like to add a new features to GPSTest that includes various metrics that may give some indication that a GNSS signal is being spoofed. This will be implemented by comparing GNSS data attributes against other source of data that provide similar attributes.

Possible names for new feature/fragment in navigation drawer (other proposals welcome):

• Health
• Security
• Protect
• Integrity
• Interference
• Spoofing

I’m leaning towards “Health” "Integrity" because given my past experience with sensor data quality on Android, I’m expecting that there will be a reasonable number of devices that have questionable sensor data, and as a result we don’t want to definitively say that a GNSS signal is spoofed (unless we have very high confidence that this is the case).

Ceccato et al has a good description of some of the possible mitigations against spoofing that can be implemented at the application level in this 2018 ION GNSS+ paper, which also shows how existing Android and iOS devices are currently vulnerable to spoofing time and position without giving any warning to the user.

EDIT 2024 - more references to detecting spoofing, from #667

"Detecting GNSS Jamming and Spoofing on Android Devices" DOI: https://doi.org/10.33012/navi.537 https://navi.ion.org/content/69/3/navi.537

"Improving GNSS Spoofing Awareness in Smartphones via Statistical Processing of Raw Measurements" DOI: 10.1109/OJCOMS.2023.3260905 https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10081330

Here are the various features we could implement and show in a new fragment. Most of them involve comparing the computed GNSS location or received GNSS data against other sources to see if they align within a reasonable degree.

We could compare...

[Location.getTime()](https://developer.android.com/reference/android/location/Location.html#getTime()) to:

• System.currentTimeMillis() (System clock, which may or may not be influenced by GNSS signal depending on device/network - see paper)
• NTP server (for possible OSS client library see https://github.com/instacart/truetime-android)
• NETWORK LocationProvider Location.getTime()
• Android API NavigationMessage time - Requires API 24 or higher and device support (NM isn’t supported on all API 24 and higher devices). For details see https://www.slideshare.net/EU_GNSS/introducing-the-galileo-pvt-appfrom-assisted-gnss-to-nequick-model-in-android. However, if this is decoded over the air then it could have also been spoofed...
  • Google has implemented code to parse the navigation message as part of their GNSSLogger app - or https://github.com/google/gps-measurement-tools/blob/master/GNSSLogger/pseudorange/src/main/java/com/google/location/lbs/gnss/gps/pseudorange/GpsNavigationMessageStore.java. In particular, gpsEphemerisProto.week looks useful as the GPS week.. To convert to GPS time see https://github.com/google/gps-measurement-tools/blob/master/GNSSLogger/pseudorange/src/main/java/com/google/location/lbs/gnss/gps/pseudorange/GpsTime.java#L112.
• External SUPL server - https://android.googlesource.com/platform/cts/+/master/tests/tests/location/src/android/location/cts/suplClient/

  [Location.getElapsedRealtimeNanos](https://developer.android.com/reference/android/location/Location.html#getElapsedRealtimeNanos()) to:

• https://developer.android.com/reference/android/os/SystemClock#elapsedRealtimeNanos() for API 17 and higher, https://developer.android.com/reference/java/lang/System.html#nanoTime() for API 16 and lower
• https://developer.android.com/reference/android/telephony/CellInfo.html#getTimeStamp() for API 17 and higher
• Wi-Fi RTT (https://developer.android.com/guide/topics/connectivity/wifi-rtt) https://developer.android.com/reference/android/net/wifi/rtt/RangingResult.html#getRangingTimestampMillis(). Requires API 28 or higher.
• Note that elapsed nanos is not an absolute time and can only be compared against another elapsed nanos value (see below). So, we could log elapsed nanos from the system on startup and see if this changed significantly and if the difference didn’t match the difference in system clock. It's not currently clear to me if this is impacted at all by GPS spoofing, though - it could just be a hardware clock that always ticks and doesn't use an external time reference. NETWORK LocationProvider Location.getElapsedRealtimeNanos()

  Location.getLatitude() and Location.getLongitude() to:

• https://developer.android.com/reference/android/telephony/CellIdentityCdma get latitude and longitude
• NETWORK LocationProvider Location.getLatitude() and Location.getLongitude()

  Location.getSpeed() and getBearing() to:

• Accelerometer and gyroscope (already being monitored as rotation vector sensor for Map and Sky fragments)
• Google build flavor only - Activity recognition from Google Play Services

  Location.getAltitude() to:

• Barometric pressure sensor for altitude - https://developer.android.com/reference/android/hardware/SensorManager#getAltitude%28float,%20float%29

Cc’ing @caparrag, one of the co-authors on the paper, to see if he has any more comments or wants to contribute :)

Steps to reproduce:

Look for method to determine health of GNSS signal, compared to data from other sources (e.g., device sensors)

Expected behavior:

Give me such a feature

Observed behavior:

No such feature exists

[goldfndr]

If the scope of this feature/fragment is limited/confined to spoofing then I suggest a name of "Spoof check" or "Spoofing diagnosis" or "Spoofed?" or similar. I think it'd be preferable to encourage use of the conventional terminology.

[ndoggac]

Would recommend against using the term "health", as it may be misconstrued as GNSS broadcast satellite health (ie. almanac/ephemeris health bits).

This a fairly lofty goal. It's pretty cool, but it's going to be pretty difficult with uncertain returns. I think section 3 in the paper lays out the options nearly in order of difficulty from least to most.

3-A would be relatively easy to implement, log position every 'n' seconds and sanity check the diff from previous position.

3-B you could utilize cellular time, or ntp time via internet compared to time calculated from your GNSS solution. For position you could perform an independent position estimate using OTDOA and make sure your GNSS position is within a certain vicinity of the independent position calculation. Not sure if OTDOA is available in the Android API though, and it has errors on the order of several hundred meters.

3-C I'm uncertain how much this would buy you as there are already validity checks built into the GPS broadcast frames, which the chipset implements. However, ICDs can be found here.

You may want to consider implementing a RAIM algorithm as well, and have a fault detection (FD) flag.

[barbeau]

A recent publication using raw measurements: https://www.ion.org/publications/abstract.cfm?articleID=15883

Same paper - https://www.researchgate.net/publication/329575474_Android_Raw_GNSS_Measurements_as_the_New_Anti-Spoofing_and_Anti-Jamming_Solution

[barbeau]

It would be great to include Galileo OS-NMA info for spoofing detection too - https://gssc.esa.int/navipedia/index.php/Galileo_Open_Service_Navigation_Message_Authentication.

One challenge, though, is navigation message access directly from the Android APIs is not widely deployed at the moment. See column "Navigation Messages" (O) in the GPSTest Database: https://bit.ly/gpstest-device-database

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

[stale[bot]]

Closing this. Please reopen if you believe it should be addressed. Thank you for your contribution.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

[stale[bot]]

Closing this. Please reopen if you believe it should be addressed. Thank you for your contribution.

[barbeau]

Not stale