Feature request: Use GPS as time service

[BlauerHunger]

As far as I know, updating the time on GrapheneOS works only by actively contacting an external service hosted by GrapheneOS over the internet to get the current time. While this is better than using a Google service, it's far from ideal.

With GPS, you can synchronize receivers extremely accurately to the satellites clock, which is one of the most accurate time sources there are. From a technical perspective, you don't need the almanach data that is required to get a position fix when you're only interested in synchronizing your system clock, and you don't need to send any signal from your device to accomplish any of this. It's also pretty hard to tamper with a GPS signal in a way that you can't even get an accurate timestamp from it or can't notice that it has been tampered with.

I don't know whether the APIs exposed by GPS module drivers used on phones supported by GrapheneOS support this, but if it is possible to implement, it would be a great feature, as you can now synchronize your time using only a completely passive receiver whenever you receive a single GPS satellite without letting the outside world know that there is a phone nearby (especially great from an opsec perspective, but also for applications where no internet connection is available).

If this is possible to do with the existing drivers on GrapheneOS, please implement it.

[thestinger]

As far as I know, updating the time on GrapheneOS works only by actively contacting an external service hosted by GrapheneOS over the internet to get the current time. While this is better than using a Google service, it's far from ideal.

Why is it far from ideal? It's a first party service and while it relies on TLS and WebPKI for security, that could be improved with DANE support. Android's time update system isn't really meant to be incredibly precise. We increased the granularity where it will update the clock from 2000ms to 50ms but it's not clear if making that 1ms or 0ms to have it update whenever it doesn't match would be a good idea. It's designed to support multiple sources (telephony, manual, network, gnss, external) with priorities and if there are multiple enabled but it only gets time from one since boot, it will use that one. We can't have GNSS as the only time source since it doesn't work everywhere, so we'd need to do something like [network, gnss] or the other way around, meaning that it's still only as precise as our network time in general, and more precision would require further increasing the permitted offset before updating the clock.

AOSP supports enabling GNSS as a time source but we don't know if it works with either the Qualcomm and Broadcom GNSS implementation. We also don't know which networks they'll use for time if it does work. They support multiple GNSS systems and it's not clear what they would do in a situation where some reported different values. The only configuration in AOSP is whether GNSS time suggestions are enabled and the priority of time suggestions which we change from [network, telephony] to [network]. Also not known exactly how it will work. It may only passively give time suggestions while using GNSS via location services. It may not ever proactively try to obtain time from GNSS.

It's also pretty hard to tamper with a GPS signal in a way that you can't even get an accurate timestamp from it or can't notice that it has been tampered with.

GPS has no authentication and is fairly easily spoofed. Galileo had authentication added to it retroactively but we don't know the details and it may not help much with this use case and it seems unlikely that any of the Qualcomm and Broadcom GNSS implementations support it. If we simply enabled GNSS as a time source, time could be easily spoofed with proximity to the phone. Not really something we want to do.

[thestinger]

while it relies on TLS and WebPKI for security, that could be improved with DANE support

In the meantime, we could add the same kind of static pinning permitting the Let's Encrypt roots/intermediates and our backup keys that we added for some of our other apps.

[BlauerHunger]

Why is it far from ideal?

The device still has to actively contact an external service, no matter how trustworthy it is, the device has to send a signal and that signal/connection may be monitored by entities that now know not only that there is a phone active, but also know that it uses GrapheneOS which may not be desirable in some places.

In addition, using that service needs an internet connection available, which isn't available everywhere. Imagine you're out in the wilderness and you'd like to have an accurate time source. Or you might not have a cellular data plan while travelling abroad and still need accurate timing. I get your point that GPS is not available all the time, but in most cases it's because you're inside a building, but then you're more likely to have an internet connection than out in the woods.

If we simply enabled GNSS as a time source, time could be easily spoofed with proximity to the phone.

Your point here is valid, but most of the time the receiver can detect it since it's hard to prevent reception of the valid satellites unless you're in a building, where we usually have a usable internet connection available.

Of course, this would need to be manually controllable by the user, the same way it should be manually controllable whether the device should actively try to obtain time information by initiating a connection through the internet.

[thestinger]

Our network time connections will go through the VPN, unlike standard Android NTP which avoids doing that likely because UDP often won't work via a VPN and time sync being off may break the VPN connection. It hurts accuracy somewhat but not a lot with a decent performing VPN and that doesn't really matter. Only connectivity checks need to be changed to the standard Google server to blend in on local networks when using a VPN.

Your point here is valid, but most of the time the receiver can detect it since it's hard to prevent reception of the valid satellites unless you're in a building, where we usually have a usable internet connection available.

I don't think we have any control over how it's going to obtain the time. It may simply take it from the first one.

I don't really want to change this. The stock OS and AOSP don't use GNSS time and it's not really within the scope of GrapheneOS to enable it, if that's even possible with the GNSS HALs, etc. used by the devices.