[atlas] Feature request for Validated Timestamps
- Previous message (by thread): [atlas] Feature request for Validated Timestamps
- Next message (by thread): [atlas] Feature request for Validated Timestamps
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Philip Homburg
philip.homburg at ripe.net
Thu Apr 15 12:16:25 CEST 2021
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
- Previous message (by thread): [atlas] Feature request for Validated Timestamps
- Next message (by thread): [atlas] Feature request for Validated Timestamps
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]