2.2 Segment Identifiers (HoHoDk) and Keys

  • Article

Cryptographic hashes are used to identify segments and blocks. The following describes the procedures to generate a segment secret, a segment hash of data, and a segment identifier (HoHoDk). These computations use the following inputs:

  • The content.

  • A hashing algorithm (configurable), used either directly or as part of the Keyed-Hashing for Message Authentication (HMAC) mechanism, see [RFC2104].  The hashing algorithm is assumed to take an arbitrary-length byte string as input, and to output a fixed-length binary string as output.  The list of possible hashing algorithms can be found in section 2.3.

  • A server-configured secret, in the form of a binary string.

The following diagram shows how the set of hashes is calculated:

Calculation of hashes

Figure 1: Calculation of hashes

Notation:

  • "+": concatenation

  • hash: The input hash function, which MUST be one of the hash functions listed in section 2.3.

  • HMAC: The HMAC function (defined in [RFC2104]), constructed using Hash as the hash function.

  • Ks: The server secret.

  • Kp (segment secret): A segment-specific hash that is sent to authorized clients along with the rest of the content information.

  • HoD (segment hash of data): The hash of the content block hashes of every block in the segment, as formulated later in this section.

  • HoHoDk (segment ID): A hash that represents the content-specific "label", or public identifier, that is used to discover content from other peers or from the hosted cache. HoHoDk is disclosed freely in Multicast messages, as specified in [MS-PCCRD]. Knowledge of the HoHoDk does not prove authorization to access the data.

  • Ke: Ke = Kp. A sending peer will encrypt data (using the mechanism described in [FIPS197]) with Ke, but Ke is never disclosed between peers. The receiving client MUST already have obtained Kp to compute the value of Ke from a server to decrypt the peer supplied data.

  • ContentInfo: The segment-specific data that is sent to authorized clients as part of the Content Information Data Structure (section 2.3) for each segment of content they access. ContentInfo includes only the list of block hashes, the HoD, and Kp. Ke and HoHoDk are not included in ContentInfo. A peer receiving the ContentInfo derives them from the available values according to the formulae later in this section. Ks is never disclosed by the server.

  • dataBlock: dataBlock and block are used interchangeably.

Formulae:

  • segment = dataBlock1 + dataBlock2 + … + dataBlockn (where the segment consists of n blocks; see section 2.1 for details.)

  • BlockHashi = Hash (dataBlocki) 1<= I <=n

  • BlockHashList = BlockHash1 + BlockHash2 + … + BlockHashN

  • HoD = Hash (BlockHashList)

  • Kp = HMAC (Ks, HoD)

  • Ke = Kp

  • HoHoDk = HMAC (Kp, HoD +C2) (where C2 is the null-terminated ASCII string constant "MS_P2P_CACHING"; string literals are all ASCII strings with NULL terminators unless otherwise noted.)

  • ContentInfo = HoD + Kp + BlockHashList

Before making any received blocks in a segment available to the higher layer, any peers or the hosted cache, a peer MUST verify that:

  • Each block hash matches the supplied HoD.

  • The hash of each dataBlock matches the corresponding supplied block hash.

For Content Information version 2.0, Kp, Ke, and HoHoDk are calculated in the same way as in Content Information version 1.0. However, there are no blocks or block hashes in Content Information version 2.0. The segment HoD is calculated as the hash of the content segment.