Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.503  Word version:  18.3.0

Top   Top   Up   Prev   None
1…   4…   5…   6…   6.1.3.2…   6.1.3.2.2.2   6.1.3.2.3   6.1.3.3…   6.2…   6.3…   6.3.3.2…   6.3.3.3…   6.3.4…   6.4…   7…   A… 
A Key derivation functions  A.1 KDF interface and input parameter construction  A.2 CP-PRUK derivation function  A.3 Derivation of CP-PRUK ID*  A.4 KNR_ProSe derivation function  A.5 Calculation of DCR confidentiality keystream  A.6 Calculation of MIC value for discovery message  A.7 Message-specific confidentiality mechanisms for discovery  A.8 Calculation of KNRP for UE-to-Network relays  A.9 Calculation of MIC value for Direct Communication Request  B Source authenticity of discovery messages  $ Change history 

 

A (Normative)  Key derivation functions  p. 58

A.1  KDF interface and input parameter construction  p. 58

A.1.1  General  p. 58

All key derivations for 5G ProSe shall be performed using the Key Derivation Function (KDF) specified in clause B.2.2 of TS 33.220.
This clause specifies how to construct the input string, S, and the input key, KEY, for each distinct use of the KDF. Note that "KEY" is denoted "Key" in TS 33.220.
Up

A.1.2  FC value allocations  p. 58

The FC number space used is controlled by TS 33.220, FC values allocated for the present document are: 0x85, 0x86, 0x87, 0x88, 0x89, 0x8A, 0x8B.

A.2  CP-PRUK derivation function  p. 58

When deriving a CP-PRUK from KAUSF_P, the following parameters shall be used to form the input S to the KDF:
  • FC = 0x85;
  • P0 = SUPI;
  • L0 = length of SUPI;
  • P1 = relay service code;
  • L1 = length of relay service code.
The input key KEY is KAUSF_P.
SUPI shall have the same value as parameter P0 in clause A.7.0 of TS 33.501.
Up

A.3  Derivation of CP-PRUK ID*  p. 58

When deriving the CP-PRUK ID* from KAUSF_P, the following parameters are used to form the input S to the KDF:
  • FC = 0x86;
  • P0 = "PRUK-ID";
  • L0 = length of "PRUK-ID";
  • P1 = relay service code;
  • L1 = length of relay service code;
  • P2 = SUPI;
  • L2 = length of SUPI.
The input key KEY is KAUSF_P.

A.4  KNR_ProSe derivation function  p. 59

When deriving the KNR_ProSe from CP-PRUK key, the following parameters shall be used to form the input S to the KDF:
  • FC = 0x87;
  • P0 = Nonce_2;
  • L0 = length of Nonce_2;
  • P1 = Nonce_1;
  • L1 = length of Nonce_1.
The input key KEY shall be CP-PRUK key.

A.5  Calculation of DCR confidentiality keystream  p. 59

When calculating the message-specific confidentiality keystream, the following parameters shall be used to form the input S to the KDF that is specified in Annex B of TS 33.220:
  • FC = 0x88
  • P0 = UTC-based counter
  • L0 = length of UTC-based counter (i.e. 0x00 0x04)
  • P1 = RSC
  • L1 = length of RSC (i.e. 0x00 0x03).
The input key shall be the 256-bit selected key in Step 1 of clause 6.3.5.2.
The DCR confidentiality keystream is set to L least significant bits of the output of the KDF, where L = the length of the RSC + the length of the UP-PRUK ID.
Up

A.6  Calculation of MIC value for discovery message  p. 59

When calculating a MIC using the Discovery Key for open discovery or the DUIK for restricted discovery, the following parameters shall be used to form the input S to the KDF that is specified in Annex B of TS 33.220:
  • FC = 0x89.
  • P0 = UTC-based counter associated with the discovery slot.
  • L0 = length of above (i.e. 0x00 0x04).
  • P1 = discovery message with the MIC value field set to all zeros.
  • L1 = length of above.
The MIC is set to the 32 least significant bits of the output of the KDF.
The Discovery Key, DUIK, Time parameter and discovery message follow the encoding also specified in Annex B of TS 33.220.
Up

A.7  Message-specific confidentiality mechanisms for discovery  p. 60

Message-specific confidentiality protection is provided by ProSe layer between ProSe UEs.
The use and mode of operation of the ciphering algorithms are specified in Annex D in TS 33.501.
The input parameters to the ciphering algorithms as described in Annex D in TS 33.501 are:
  • KEY: 128 least significant bits of the output of the KDF (DUCK, UTC-based counter, MIC)
  • COUNT: UTC-based counter
  • BEARER: 0x00
  • DIRECTION: 0x00
  • LENGTH: LEN(discovery message) - (LEN(Message Type) + LEN(UTC-based counter LSB) + LEN(MIC)), where LEN(x) is the length of x in number of bits
KEY is set to as such to generate message-specific keystream as in TS 33.303.
The output keystream of the ciphering algorithm (output_keystream) is then masked with the Encrytped_bits_mask to produce the final keystream for the message-specific confidentiality protection (KEYSTREAM):
KEYSTREAM = output_keystream AND (Encrypted_bits_mask || 0xFF..FF)
The KEYSTREAM is XORed with the discovery message for message-specific confidentiality protection excluding Message Type, UTC-based counter LSB and MIC.
Up

A.8  Calculation of KNRP for UE-to-Network relays  p. 60

When calculating KNRP from UP-PRUK, the following parameters shall be used to form the input S to the KDF that is specified in Annex B of TS 33.220:
  • FC = 0x8A
  • P0 = Relay Service Code
  • L0 = length of Relay Service Code (i.e. 0x00 0x03)
  • P1 = KNRP freshness parameter 1
  • L1 = length of KNRP freshness parameter 1 (i.e. 0x00 0x10)
  • P2 = KNRP freshness parameter 2
  • L2 = length of KNRP freshness parameter 2 (i.e. 0x00 0x10)
The input key shall be the 256-bit UP-PRUK.
Up

A.9  Calculation of MIC value for Direct Communication Request  p. 60

When calculating a MIC using the DUIK to integrity protect Direct Communication Request (DCR) message, the following parameters shall be used to form the input S to the KDF that is specified in Annex B of TS 33.220:
  • FC = 0x8B.
  • P0 = UTC-based counter.
  • L0 = length of above (i.e. 0x00 0x04).
  • P1 = DCR message with the MIC value field set to all zeros.
  • L1 = length of above.
The MIC is set to the 32 least significant bits of the output of the KDF.
The DUIK, UTC-based counter and DCR message follow the encoding also specified in Annex B of TS 33.220.
Up

B  Source authenticity of discovery messages  p. 62

To achieve source authenticity of discovery messages, the third security requirement in clause 6.1.2, a UE receiving a discovery message can verify the source authenticity of the received discovery message by using the provisioned DUIK under the assumption that the UEs provisioned with the same DUIK are trusted.
Alternatively, if receiving UEs are not provisioned with the DUIK, the network can verify the source authenticity of discovery messages via match report procedure.
Up

$  Change history  p. 63

Up   Top