To Rick's point: Providing a signed timestamp could be done on Atlas Anchors, and perhaps that's a better place to start than the software probes.
To Philip's point, the basic protocol I am hoping to enable looks as follows:
(I'll describe the roughtime variant)
* A machine wants to attest that it is in (e.g. Seattle). It picks a set of machines that are believed to be in Seattle (perhaps atlas machines, or more generally machines that the measurement system has agreed on locations of in advance.)
* It generates a statement saying "i am doing a measurement", and signs it.
* It then immediately req-requests the time, using the signature it received as the nonce this time, and receives a second timestamp, uncertainty, signature.
The combination of this data can then be provided to any other machine to place a bound on the RTT between the machine and the chosen measurement machine (the difference between the two timestamps). This can be validated without trusting the machine claiming it's latency bound, since the results are signed by the anchor.
There are some complexities - e.g could the machine attesting it's location delegate the request to a different machine closer to the anchor? Depending on the situation there are mitigations for this, like asking that some piece of data the machine that's attesting it's location be hashed into the nonce, in a way that's difficult for the attesting machine to predict ahead of time (so that it would need to move all of its data to the delegate machine at which point it's already in a sense also in that secondary location at that time.) But the ability to locate client software deployment via latency with some guarantee that someone running it isn't spoofing their location is useful.
An equivalent to this protocol can be used against tls1.2 servers that include the timestamp in their server randomness, with the caveat that those timestamps are only at second granularity. To compensate, the client will repeat the hashing RTT process for 1 second, so that the validatable data that is presented shows that the client was able to do 'n' RTT's with the server within one second.
--Will
Couldn't this functionality be extended to the Atlas Anchors?
Rick
-----Original Message-----
From: ripe-atlas <ripe-atlas-bounces@ripe.net> On Behalf Of Philip Homburg
Sent: 07 April 2021 10:27
To: ripe-atlas@ripe.net
Subject: Re: [atlas] Feature request for Validated Timestamps
On 2021/04/06 17:04 , Will wrote:
> I'm not sure if there's a process for this sort of feature request
> beyond this mailing list. Would it help if I propose a more concrete
> PR against https://github.com/RIPE-NCC/ripe-atlas-software-probe
> <https://github.com/RIPE-NCC/ripe-atlas-software-probe>
To the extend that you would like secure geolocation in presence of a
malicious probe, it would make sense to me to start with documenting the
protocol you would like to use.
The current way of geolocating probes works by having to probe report round
trip times to a number locations. Obviously, a malicious probe could report
any rtt value.
I'm sure we can come up with a protocol if we have a sufficient number of
trusted servers. However, such a protocol would need to be documented and
deployed on those servers.
Philip