3.1.5.2.7 Signature Processing

  • Article

All frames that are associated with a signed connection MUST have an ullSignature field present, and it MUST be validated. The method of validation depends on the signing mode that was agreed upon when the connection was established.

For fast-signed connections, the 64-bit signature MUST match exactly the secret that was associated with the remote partner when the connection was set up; otherwise, the packet MUST be discarded.

For full-signed connections, the 64-bit signature MUST match exactly the first 64 bits of the expected SHA-1 signature digest or else the packet MUST be discarded. The digest MUST be calculated from the following data, in sequence:

  1. The entire received packet, extending from the beginning of the command frame (CFRAME) or data frame (DFRAME) header and concluding with the final byte of the final mask, payload, or coalesced payload, as appropriate, except with the CFRAME or DFRAME ullSignature bytes set to 0.

  2. The 64-bit current or previous remote secret, in little-endian byte order. The remote secret to use when validating MUST be selected according to the following logic:

    1. If the next expected receive sequence ID is greater than or equal to 192, use the previous remote secret.

    2. If the next expected receive sequence ID is less than 64 and the received bSeq value is greater than or equal to 192, use the previous remote secret.

    3. Otherwise, use the current remote secret.

For full-signed connections, remote secrets are also modified once each time the 8-bit sequence space wraps to avoid signing all data with the same value. The modification is performed using a modifier value derived from the lowest sequenced reliable payload received with a sequence ID of less than 192 that is not a KeepAlive. If the lowest sequenced packet using the PACKET_COMMAND_RELIABLE flag contains coalesced payload, the first subpayload that is marked PACKET_COMMAND_RELIABLE is used to generate the modifier. If no non-KeepAlive reliable payload is received with a sequence ID between 0 and 191 inclusive, the previous remote secret modifier value is reused. The remote secret modifier value is initialized to the secret associated with the sender when the connection was established; that is, it begins with the same value as the CONNECTED_SIGNED frame's ullSenderSecret field if the local computer system received an inbound connection, and it begins with the same value as the CONNECTED_SIGNED frame's ullReceiverSecret field if the local computer system performed an outbound connection.

Upon receiving the packet with sequence ID 192 on a full-signed connection, and there are no missing sequence IDs, the receiver MUST advance the secret by making the current remote secret become the previous remote secret, and then setting the new current remote secret to the first 64 bits of a SHA-1 digest of the following data, in sequence:

  1. The previous 64-bit remote secret, in little-endian byte order.

  2. The 64-bit remote secret modifier value, in little-endian byte order.