Content for  TS 33.180  Word version:  17.8.0

The security mechanism described in this clause extends that defined in clause 5.2.2 to provide end-point key diversity. The mechanism is identical to that described in clause 5.2.2, except for the distribution of K-ID. Contrary to clause 5.2.2, the key is distributed with an end-point-specific key identity (UK-ID) (e.g. a GUK-ID) derived from the key id (K-ID). This allows the receiving entity of the key distribution to diversify the shared key for end-point-specific use. Specific types of key require use of end-point key diversity. The type of key is defined by the 'purpose tag' within the key identifier stored in the CSB-ID field of the MIKEY payload. Hence on receipt of a key, the contents of the CSB-ID field instruct the receiving entity whether end-point diversity should be applied to the key. The key, K, is distributed encrypted specifically to the receiving entity and signed by the initiating entity as described in clause 5.2.2. The key is distributed with a 32-bit entity-specific Key Identifier (UK-ID) derived from a common key id (K-ID) and a salt (which is derived from the receiving entity's MCX URI). The security domain parameters are provided in the public values in the certificate received from the KMS. The payload includes the entity-specific Key Identifier (UK-ID) within the CSB-ID field. The key, K, is identified by a Key Identifier (K-ID) from which the UK-ID is derived. On creating the key, K, the initiating entity generates a K-ID as follows. The 4 most significant bits of the K-ID is the 'purpose tag' which defines the purpose of the key. The 28 least significant bits of the K-ID is a 28-bit randomly-generated value. For each receiving entity, the initiating entity creates a 28-bit Salt by hashing the receiving entity's URI through a KDF using the key, K, as the key (as defined in Annex F.1.3). The Salt is xor'd with the 28 least-significant bits of the K-ID to create the 32-bit UK-ID. The process for generating the UK-ID is summarized in Figure 5.2.3-1.

The UK-ID is placed in the CSB ID field within the header of the I_MESSAGE. The security processes are summarized in Figure 5.2.3-2.

At the receiving MCX entity, the initiating entity's URI is extracted from the initiator field (IDRi) of the message. Along with the time, this is used to check the signature on the payload. If valid, the receiving entity extracts and decrypts the encapsulated key, K, using the (KMS-provisioned) entity's UID key. The receiving MCX entity also extracts UK-ID from the CSB-ID field of the I_MESSAGE. If the 'purpose tag' of the UK-ID indicates that end-point diversity is applied, the receiving entity generates the Salt using its URI and the decrypted key, K. The receiving entity xors the UK-ID and Salt together to obtain the K-ID. The K-ID and UK-ID are stored. The extraction procedure is described in Figure 5.2.3-3.