roughtime.googlesource.com/roughtime.git@v0.0.0-20201210012726-dd529367052d/PROTOCOL.md (about)

     1  # Roughtime protocol
     2  
     3  ## Messages
     4  
     5  Roughtime messages are a map from uint32s to byte-strings. The number of elements in the map and the sum of the lengths of all the byte-strings are, at most, 2\*\*32-1. All the byte strings must have lengths that are a multiple of four.
     6  
     7  All values are encoded in little-endian form because every platform that Google software runs on is little-endian.
     8  
     9  The header of a message looks like:
    10  
    11  ```
    12  uint32 num_tags
    13  uint32 offsets[max(0, num_tags-1)]
    14  uint32 tags[num_tags]
    15  ```
    16  
    17  Following the header are the contents of the byte-strings. The first byte after the header is considered be offset zero and is the start of the value for the first tag. The `offsets` array gives the offset of the value for all tags after the first.
    18  
    19  Tags must be in strictly ascending order and offsets must be a multiple of four. Parsers must require this.
    20  
    21  Here are some example messages, given in hex:
    22  
    23  The empty message consists of four, zero bytes:
    24  
    25  ```
    26  00000000  # num_tags = 0
    27  ```
    28  
    29  A message with a single tag (0x1020304) with value 80808080:
    30  
    31  ```
    32  01000000  # num_tags = 1
    33  # No offsets
    34  04030201  # tag 0x1020304
    35  80808080  # value starts immediately after the header
    36  ```
    37  
    38  A message with two tags:
    39  
    40  ```
    41  02000000  # num_tags = 2
    42  04000000  # offset 4 for the value of the second tag
    43  05030200  # tag 0x020305
    44  04030201  # tag 0x1020304
    45  00000000  # value for 0x020305 starts immediately after the header
    46  80808080  # value for 0x1020304 starts at offset four
    47  ```
    48  
    49  Note that the ordering of the tags is based on their numerical order, not on the lexicographic order of their encodings.
    50  
    51  When processing messages, unknown tags are ignored.
    52  
    53  ## Tag values
    54  
    55  Tags can be arbitrary 32-bit values but in this document they will often be written as three or four capital letters, e.g. `NONC`. In these cases, the numeric value of the tag is such that the little-endian encoding of it causes that string to be written out. So the numeric value of `NONC` is 0x434e4f4e. For three-letter tags, the last byte will be given explicitly, e.g. `SIG\x00`.
    56  
    57  ## Requests
    58  
    59  A Roughtime request is a message with at least the tag `NONC`. The value of `NONC` is 64, arbitrary bytes that form a nonce in the protocol. Other tags must be ignored.
    60  
    61  (The simplest clients can just generate random values for the nonce. Clients that participate in the [wider ecosystem](/ECOSYSTEM.md) generate nonces in a different way.)
    62  
    63  Request messages sent over UDP must be at least 1024 bytes long in order to ensure that a Roughtime server cannot act as an amplifier. The canonical way to ensure this is to include a `PAD\xff` tag, whose value is an arbitrary number of zero bytes. It's expected that a UDP request contain exactly 1024 bytes as there's no point padding the request to more than the minimum.
    64  
    65  ## Responses
    66  
    67  Responses are messages that contain at least the following tags:
    68    * `SREP`: signed response bytes, the value of which is itself a message.
    69    * `SIG\x00`: the signature, an opaque byte-string that authenticates the value of `SREP`. At the moment, Ed25519 is the only supported signature algorithm and so this will be a 64-byte value.
    70    * `CERT`: the server's certificate, which contains a time-limited online key authenticated by the server's long-term key.
    71    * `INDX` and `PATH`: the position and upwards path for this response in a Merkle tree. See the section on signatures, below.
    72  
    73  ### The signed response and Roughtime UTC.
    74  
    75  The signed portion of a response is a message that contains the timestamp from the server as well as the root of a Merkle tree for authenticating it. It's contained in the value of the `SREP` tag.
    76  
    77  The timestamp is expressed in two tags: `MIDP` and `RADI`. The `MIDP` tag contains a uint64 which is the midpoint, in microseconds, of a span of time, while the `RADI` tag contains the radius of that span in microseconds, expressed as a uint32. The server asserts that the true time, at the point of processing, lies within that span.
    78  
    79  The “true time” for Roughtime is defined as being UTC with a 24-hour linear leap-second smear. That is, when a leap-second is added or removed from UTC it is smeared out over the course of a day. So UTC noon to noon on the date in question will consist of 86,399 or 86,401 SI seconds, with all the smeared seconds being the same length.
    80  
    81  As noted, the signed response message also includes the root of a Merkle tree in a `ROOT` tag. The semantics of this are detailed in the next section.
    82  
    83  ### Authenticating replies
    84  
    85  In order to authenticate the response and ensure freshness, the nonce provided in a request must be bound into the signed response. In order to allow a server to sign a batch of responses the nonces are built into a tree and only the root of the tree is included in the signed message.
    86  
    87  A signature of the encoded, signed response message is included as the value of the top-level `SIG\x00` tag. This signature must be checked with respect to the online key that's included in the certificate. (See next section.)
    88  
    89  Additionally, a client must ensure that their nonce is included the tree. To do so, the values of the `INDX` and `PATH` tags from the top-level response are needed, as well as the value of the `ROOT` tag from the signed response message.
    90  
    91  The value of the `INDX` tag is a uint32 and specifies the position of the client's nonce in the tree. The value of the `PATH` tag is a series of hashes on the path from the client's nonce to the root of the tree. The value of the `ROOT` tag is the claimed root of the tree. The hash function used throughout is SHA-512 so the length of the root is 64 bytes and the length of the path is a multiple of 64 bytes.
    92  
    93  A client can verify that its nonce is included in a tree using the following pseudo code:
    94  
    95  ```
    96  index = top-level-response.getU32("INDX")
    97  path = top-level-response.getMultipleOf64Bytes("PATH")
    98  hash = hashLeaf(nonce-from-request)
    99  
   100  while len(path) > 0 {
   101    if index&1 == 0 {
   102      hash = hashNode(hash, path[:64])
   103    } else {
   104      hash = hashNode(path[:64], hash)
   105    }
   106  
   107    index >>= 1
   108    path = path[64:]
   109  }
   110  
   111  if hash != signed-response-message.Get64Bytes("ROOT") {
   112    return error;
   113  }
   114  
   115  function hashLeaf(leaf) {
   116    return SHA-512("\x00" + leaf)
   117  }
   118  
   119  function hashNode(left, right) {
   120    return SHA-512("\x01" + left + right)
   121  }
   122  ```
   123  
   124  ### Certificates
   125  
   126  In order to allow a server to keep its long-term identity key offline, a response includes a ‘certificate’, which is a limited delegation from the long-term key to an online key. This certificate is contained in a message which is the value of the `CERT` tag in a response.
   127  
   128  The certificate message contains two tags: `SIG\x00` and `DELE`. The value of the `SIG\x00` tag is a signature of the value of the `DELE` tag, made by the server's long-term key. (Clients must know the server's public key a priori.) Since Ed25519 is currently the only supported signature algorithm, this value will be 64 bytes long.
   129  
   130  The contents of the value of the `DELE` tag are a message containing:
   131    * `PUBK`: the online public key. This key is used to produce the signature of the signed response message in the top-level of the response.
   132    * `MINT` and `MAXT`: these uint64s limit the times that the online key can authenticate. The midpoint of any time span using that key must be greater than (or equal to) the value of `MINT` and less than (or equal to) the value of `MAXT`.
   133  
   134  ### Processing a response
   135  
   136  To summarise the above, the full structure of a response (when considering nested messages) looks like this:
   137  
   138    * `SREP`
   139      * `ROOT`
   140      * `MIDP`
   141      * `RADI`
   142    * `SIG\x00`
   143    * `INDX`
   144    * `PATH`
   145    * `CERT`
   146      * `SIG\x00`
   147      * `DELE`
   148        * `MINT`
   149        * `MAXT`
   150        * `PUBK`
   151  
   152  The procedure to fully process a response results in an authenticated midpoint and radius and contains roughly these steps:
   153    1. Verify the signature in the certificate of the delegation message.
   154    1. Verify the top-level signature of the signed response message using the public key from the delegation.
   155    1. Verify that the nonce from the request is included in the Merkle tree.
   156    1. Verify that the midpoint is within the valid bounds of the delegation.
   157    1. Return the midpoint and radius.