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.401  Word version:  17.3.0

Top   Top   Up   Prev   Next
1…   4   5…   6…   6.2…   7…   7.2.5…   7.2.8   7.2.9…   7.3…   8…   9…   10…   11…   15…   A…   B…   C…   C.1.6   C.2…   C.2.7   C.2.8   C.3…   C.4.7   D…   E…   E.2…   E.3…   F…   G…   H…   I…   K… 
A Key derivation functions  A.1 KDF interface and input parameter construction  A.2 KASME derivation function  A.3 KeNB derivation function  A.4 NH derivation function  A.5 KeNB* derivation function  A.7 Algorithm key derivation functions  A.8 KASME to CK', IK' derivation at handover  A.9 NAS token derivation for inter-RAT mobility  A.10 K'ASME from CK, IK derivation during handover  A.11 K'ASME from CK, IK derivation during idle mode mobility  A.12 KASME(_SRVCC) to CKSRVCC, IKSRVCC derivation  A.13 KASME to CK', IK' derivation at idle mobility  A.15 Derivation of S-KeNB or S-KgNB for dual connectivity  A.16 Derivation of LWIP-PSK  A.17 Derivation of K_n for IOPS subscriber key separation  A.18 Derivation of S-KWT for LWA  A.19 Key derivation function for key used in algorithms between UE and SgNB 
...

 

A (Normative)  Key derivation functions  p. 83

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

A.1.1  General  p. 83

All key derivations (including input parameter encoding) for EPS shall be performed using the key derivation function (KDF) specified in TS 33.220. This clause specifies how to construct the input string, S, to the KDF (which is input together with the relevant key). For each of the distinct usages of the KDF, the input parameters S are specified below.

A.1.2  FC value allocations  p. 83

The FC number space used is controlled by TS 33.220, FC values allocated for this specification are in range of 0x10 - 0x1F.

A.2  KASME derivation function  p. 83

When deriving a KASME from CK, IK and SN id when producing authentication vectors, and when the UE computes KASME during AKA, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x10,
  • P0 = SN id,
  • L0 = length of SN id (i.e. 0x00 0x03),
  • P1 = SQN ⊕ AK
  • L1 = length of SQN ⊕ AK (i.e. 0x00 0x06)
The exclusive or of the Sequence Number (SQN) and the Anonymity Key (AK) is sent to the UE as a part of the Authentication Token (AUTN), see TS 33.102. If AK is not used, AK shall be treated in accordance with TS 33.102, i.e. as 000…0.
The SN id consists of MCC and MNC, and shall be encoded as an octet string according to Figure A.2-1.
Copy of original 3GPP image for 3GPP TS 33.401, Fig. A.2-1: Encoding of SN id as an octet string
Figure A.2-1: Encoding of SN id as an octet string
(⇒ copy of original 3GPP image)
Up
The coding of the digits of MCC and MNC shall be done according to TS 24.301.
The input key Key shall be equal to the concatenation CK || IK of CK and IK.

A.3  KeNB derivation function  p. 84

When deriving a KeNB from KASME and the uplink NAS COUNT in the UE and the MME the following parameters shall be used to form the input S to the KDF.
  • FC = 0x11,
  • P0 = Uplink NAS COUNT,
  • L0 = length of uplink NAS COUNT (i.e. 0x00 0x04)
The input key shall be the 256-bit KASME.
This function is applied when cryptographically protected E-UTRAN radio bearers are established and when a key change on-the-fly is performed.
Up

A.4  NH derivation function  p. 84

    When deriving a NH from KASME the following parameters shall be used to form the input S to the KDF.
  • FC = 0x12
  • P0 = SYNC-input
  • L0 = length of SYNC-input (i.e. 0x00 0x20)
The SYNC-input parameter shall be the newly derived KeNB for the initial NH derivation, and the previous NH for all subsequent derivations. This results in a NH chain, where the next NH is always fresh and derived from the previous NH.
The input key shall be the 256-bit KASME.
Up

A.5  KeNB* derivation function  p. 84

When deriving a KeNB* from current KeNB or from fresh NH and the target physical cell ID in the UE and eNB as specified in clause 7.2.8 for handover purposes the following parameters shall be used to form the input S to the KDF.
  • FC = 0x13
  • P0 = PCI (target physical cell id)
  • L0 = length of PCI (i.e. 0x00 0x02)
  • P1 = EARFCN-DL (target physical cell downlink frequency)
  • L1 length of EARFCN-DL (i.e. L1 = 0x00 0x02 if EARFCN-DL is between 0 and 65535, and L1 = 0x00 0x03 if EARFCN-DL is between 65536 and 262143)
The input key shall be the 256-bit NH when the index in the handover increases, otherwise the current 256-bit KeNB.
Up

A.6  Void

A.7  Algorithm key derivation functions  p. 85

When deriving keys for NAS integrity and NAS encryption algorithms from KASME and algorithm types and algorithm IDs, and keys for RRC integrity, UP integrity, and RRC/UP encryption algorithms from KeNB, in the UE, MME and eNB the following parameters shall be used to form the string S.
  • FC = 0x15
  • P0 = algorithm type distinguisher
  • L0 = length of algorithm type distinguisher (i.e. 0x00 0x01)
  • P1 = algorithm identity
  • L1 = length of algorithm identity (i.e. 0x00 0x01)
The algorithm type distinguisher shall be NAS-enc-alg for NAS encryption algorithms and NAS-int-alg for NAS integrity protection algorithms. The algorithm type distinguisher shall be RRC-enc-alg for RRC encryption algorithms, RRC-int-alg for RRC integrity protection algorithms, UP-enc-alg for UP encryption algorithms and UP-int-alg for UP integrity protection algorithms (see Table A.7-1). The values 0x07 to 0xf0 are reserved for future use, and the values 0xf1 to 0xff are reserved for private use.
Algorithm distinguisher Value
NAS-enc-alg0x01
NAS-int-alg0x02
RRC-enc-alg0x03
RRC-int-alg0x04
UP-enc-alg0x05
UP-int-alg0x06
The algorithm identity (as specified in clause 5) shall be put in the four least significant bits of the octet. The two least significant bits of the four most significant bits are reserved for future use, and the two most significant bits of the most significant nibble are reserved for private use. The entire four most significant bits shall be set to all zeros.
For NAS algorithm key derivations, the input key shall be the 256-bit KASME, and for UP and RRC algorithm key derivations, the input key shall be the 256-bit KeNB.
For an algorithm key of length n bits, where n is less or equal to 256, the n least significant bits of the 256 bits of the KDF output shall be used as the algorithm key.
Up

A.8  KASME to CK', IK' derivation at handover  p. 85

This input string is used when there is a need to derive CK' || IK' from KASME during mapping of security contexts from E-UTRAN to GERAN/UTRAN at handover. KASME is a 256-bit entity, and so is the concatenation of CK and IK (which are 128 bits each). The following input parameters shall be used.
  • FC = 0x16
  • P0 = NAS downlink COUNT value
  • L0 = length of NAS downlink COUNT value (i.e. 0x00 0x04)
The input key shall be KASME.
Up

A.9  NAS token derivation for inter-RAT mobility  p. 86

The NAS-token used to ensure that a RAU is originating from the correct UE during IDLE mode mobility from E-UTRAN to UTRAN and GERAN, shall use the following input parameters.
  • FC = 0x17
  • P0 = Uplink NAS COUNT
  • L0 = length of uplink NAS COUNT (i.e. 0x00 0x04)
The input key shall be the 256-bit KASME.

A.10  K'ASME from CK, IK derivation during handover  p. 86

This input string is used when there is a need to derive a K'ASME from concatenation of CK and IK and a NONCEMME during mapping of security contexts between GERAN/UTRAN and E-UTRAN during handover to E-UTRAN.
K'ASME is a 256-bit value. The NONCEMME is a 32-bit value. The following input parameters shall be used.
  • FC = 0x18
  • P0 = NONCEMME
  • L0 = length of NONCEMME (i.e. 0x00 0x04)
The input key shall be the concatenation of CK || IK.
The generation of NONCEMME shall be sufficiently random such that both the probability of the MME generating equal values of NONCEMME and the probability of an attacker being able to predict future values of NONCEMME over the duration of practical eavesdropping attacks on a particular user are extremely low.
Up

A.11  K'ASME from CK, IK derivation during idle mode mobility  p. 86

This input string is used when there is a need to derive a K'ASME from CK || IK, NONCEUE, and NONCEMME during mapping of security contexts from GERAN/UTRAN to E-UTRAN. K'ASME is a 256-bit entity, and so is the concatenation of CK and IK (which are 128 bits each). The following input parameters shall be used, where NONCEs are 32 bits long.
  • FC = 0x19,
  • P0 = NONCEUE
  • L0 = length of the NONCEUE (i.e. 0x00 0x04)
  • P1 = NONCEMME
  • L1 = length of the NONCEMME (i.e. 0x00 0x04)
The input key shall be the concatenation of CK || IK.
The generation of NONCEUE shall be sufficiently random such that both the probability of the UE generating equal values of NONCEUE and the probability of an attacker being able to predict future values of NONCEUE over the duration of practical eavesdropping attacks on a particular user are extremely low.
The generation of NONCEMME shall be as defined in clause A.10.
Up

A.12  KASME(_SRVCC) to CKSRVCC, IKSRVCC derivation  p. 87

This input string is used when there is a need to derive CKSRVCC|| IKSRVCC used in CS domain either from KASME during mapping of security contexts between E-UTRAN and GERAN/UTRAN or from KASME_SRVCC at SRVCC from 5G to UTRAN CS (see Annex J of TS 33.501). KASME and KASME_SRVCC are 256-bit elements, and so is the concatenation of CKSRVCC and IKSRVCC (which are 128 bits each).
  • FC = 0x1A
  • P0 = NAS downlink COUNT value
  • L0 = length of NAS downlink COUNT value (i.e. 0x00 0x04)
The input key shall be KASME or KASME_SRVCC.
Up

A.13  KASME to CK', IK' derivation at idle mobility  p. 87

This input string is used when there is a need to derive CK' || IK' from KASME during mapping of security contexts from E-UTRAN to GERAN/UTRAN at idle mobility. KASME is a 256-bit entity, and so is the concatenation of CK and IK (which are 128 bits each). The following input parameters shall be used.
  • FC = 0x1B
  • P0 = NAS uplink COUNT value
  • L0 = length of NAS uplink COUNT value (i.e. 0x00 0x04)
The input key shall be KASME.
Up

A.14  Void

A.15  Derivation of S-KeNB or S-KgNB for dual connectivity |R12|  p. 87

This input string is used when the MeNB and UE derive S-KeNB or S-KgNB from KeNB during dual connectivity. The following input parameters shall be used:
  • FC = 0x1C
  • P0 = Value of the SCG Counter as a non-negative integer
  • L0 = length of the SCG Counter value (i.e. 0x00 0x02)
The input key shall be KeNB of the MeNB.
Up

A.16  Derivation of LWIP-PSK |R13|  p. 87

This input string is used when the eNB and UE derive LWIP-PSK from KeNB during LTE WLAN integration using IPSec. The following input parameters shall be used:
  • FC = 0x1E
  • P0 = Value of the LWIP Counter as a non-negative integer
  • L0 = length of the LWIP Counter value (i.e. 0x00 0x02)
The input key shall be KeNB of the eNB.

A.17  Derivation of K_n for IOPS subscriber key separation |R13|  p. 88

This key derivation is for use with the IOPS subscriber key separation mechanism described in Annex F of the present specification.
The input key 'Key' is equal to MK. The following parameters are used to form the input S to the KDF:
  • FC = 0x1D
  • P0 = f(n)
  • L0 = length of f(n)
  • P1 = IMSI
  • L1 = length of IMSI
Here f(n) is proprietary, cf. Annex F of the present specification.
Up

A.18  Derivation of S-KWT for LWA |R13|  p. 88

This input string is used when the eNB and UE derive S-KWT from KeNB during LTE WLAN Aggregation. The following input parameters shall be used:
  • FC = 0x1F
  • P0 = Value of the WT Counter as a non-negative integer
  • L0 = length of the WT Counter value (i.e. 0x00 0x02)
The input key shall be KeNB of the eNB.

A.19  Key derivation function for key used in algorithms between UE and SgNB |R15|  p. 88

When deriving ciphering and integrity keys from S-KgNB in the SgNB and UE, the UE and SgNB shall use the KDF given in Annex A.8 of TS 33.501 with S-KgNB as the input key.f

Up   Top   ToC