[atlas] Feature request for Validated Timestamps

On 2021/04/14 6:00 , Will wrote:
> 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 requests the time with it's own signature as a nonce and receives a 
> (timestamp, uncertainty, signature) from the server, per 
> https://blog.cloudflare.com/roughtime/ 
> <https://blog.cloudflare.com/roughtime/>
> * It then immediately req-requests the time, using the signature it 
> received as the nonce this time, and receives a second timestamp, 
> uncertainty, signature.

It seems to me that this can be simplified a bit, the first step can be 
just a nonce. Basically:
- The client generates a random nonce
- The client uses to nonce to obtain the time from a server using the 
nonce and the roughtime protocol
- The client generates a new nonce from the reply by hashing the reply
- The client uses the second nonce to once again obtain the time.
- The client packs the two nonces and the two replies and reports it as 
measurement result.

Later, a verifier can check the signatures in the two replies to verify 
that responses came from the right server. Then a check is made that the 
second nonce is derived from the first reply. Finally a check is made 
that the replies correspond to the nonces. Note that the first nonce 
serves no value, so could be omitted from the measurement result and 
verification.

Open issue: key management. How to store all public keys of all servers 
for ever.

This seems fine, however...

> 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.

If we assume that the client is malicous, what prevents the client from 
using a collaborating machine to execute the protocol, proving the 
location of the collaborating machine. The client just submits the 
results as its own?

Philip