Content for  TS 33.401  Word version:  18.1.0

Requirements on EPC and E-UTRAN related to keys:

1. The EPC and E-UTRAN shall allow for use of encryption and integrity protection algorithms for AS and NAS protection having keys of length 128 bits and for future use the network interfaces shall be prepared to support 256 bit keys.
2. The keys used for UP, NAS and AS protection shall be dependent on the algorithm with which they are used.

The key hierarchy (see Figure 6.2-1) includes following keys: KeNB, KNASint, KNASenc, KUPenc, KRRCint, KRRCenc and KUPint

• KeNB is a key derived by ME and MME from KASME or by ME and target eNB.

Keys for NAS traffic:

• KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm This key is derived by ME and MME from KASME, as well as an identifier for the integrity algorithm using the KDF as specified in clause A.7.
• KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by ME and MME from KASME, as well as an identifier for the encryption algorithm using the KDF as specified in clause A.7.

Keys for UP traffic:

• KUPenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by ME and eNB from KeNB, as well as an identifier for the encryption algorithm using the KDF as specified in clause A.7.
• KUPint is a key, which shall only be used for the protection of UP traffic with a particular integrity algorithm. This key is derived by RN and DeNB and between ME and eNB, from KeNB, as well as an identifier for the integrity algorithm using the KDF as specified in clause A.7.

Keys for RRC traffic:

• KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm. KRRCint is derived by ME and eNB from KeNB, as well as an identifier for the integrity algorithm using the KDF as specified in clause A.7.
• KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption algorithm. KRRCenc is derived by ME and eNB from KeNB as well as an identifier for the encryption algorithm using the KDF as specified in clause A.7.

Intermediate keys:

• NH is a key derived by ME and MME to provide forward security as described in clause 7.2.8.
• KeNB* is a key derived by ME and eNB when performing an horizontal or vertical key derivation as specified in clause 7.2.8 using a KDF as specified in clause A.5.

Figure 6.2-2 shows the dependencies between the different keys, and how they are derived from the network nodes point of view. Figure 6.2-3 shows the corresponding relations and derivations as performed in the ME. Two dashed inputs to a KDF means one of the inputs is used depending on the circumstances of the key derivation.

As the Figure 6.2-2 and Figure 6.2-3 show, the length of KASME, KeNB and NH is 256 bits, 256-bit NAS, UP and RRC keys are always derived from KASME and KeNB respectively. In case the encryption or integrity algorithm used to protect NAS, UP or RRC requires a 128-bit key as input, the key is truncated and the 128 least significant bits are used. Figure 6.2-2 and Figure 6.2-3 illustrate the truncation to 128 bits keys. The function Trunc takes as input a 256-bit string, and returns a truncated output as defined in Annex A.7.

The key KASME shall be identified by the key set identifier eKSI. eKSI may be either of type KSIASME or of type KSISGSN. An eKSI shall be stored in the UE and the MME together with KASME and the temporary identifier GUTI, if available. The key set identifier KSIASME is a parameter which is associated with the KASME derived during EPS AKA authentication. The key set identifier KSIASME is allocated by the MME and sent with the authentication request message to the mobile station where it is stored together with the KASME. The purpose of the KSIASME is to make it possible for the UE and the MME to identify a native KASME without invoking the authentication procedure. This is used to allow re-use of the KASME during subsequent connection set-ups. The key set identifier KSISGSN is a parameter which is associated with the mapped KASME derived from UMTS keys during inter-RAT mobility, cf. clauses 9 and 10 of the present specification. The key set identifier KSISGSN is generated in both the UE and the MME respectively when deriving the mapped KASME during idle procedures in E-UTRAN and during handover from GERAN/UTRAN to E-UTRAN. The KSISGSN is stored together with the mapped KASME. The purpose of the KSISGSN is to make it possible for the UE and the MME to indicate the use of the mapped KASME in inter-RAT mobility procedures (for details cf. clauses 9 and 10). The format of eKSI shall allow a recipient of such a parameter to distinguish whether the parameter is of type 'KSIASME' or of type 'KSISGSN'. The format shall further contain a value field. KSIASME and KSISGSN have the same format. The value fields of KSIASME and KSISGSN are three bits each. Seven values are used to identify the key set. A value of '111' is used by the UE to indicate that a valid KASME is not available for use. Format of eKSI is described in [9]. The value '111' in the other direction from network to mobile station is reserved.

Any EPS security context shall be deleted from the ME if:

1. the UICC is removed from the ME when the ME is in power on state;
2. the ME is powered up and the ME discovers that a UICC different from the one which was used to create the EPS security context has been inserted to the ME;
3. the ME is powered up and the ME discovers that no UICC has been inserted to the ME.

KASME shall never be transferred from the EPC to an entity outside the EPC , with the exception of the following scenario(s):

• interworking from EPS to 5G as described in clause 8.2 and 8.4 of TS 33.501.

Both the ME and MME shall be capable of storing one non-current EPS security context and one current EPS security context in volatile memory. In addition, while connected to E-UTRAN the ME and MME shall be capable of storing in volatile memory the NCC, NH and the related KASME used to compute keying material for the current EPS AS security context. Any successful run of an EPS AKA creates, by the definition in clause 3, a partial native EPS security context. This context shall overwrite any existing non-current EPS security context. UE shall use its current EPS security context to protect the TAU Request or Attach Request. However, there may be cases in which this EPS security context is not the current one in the MME. In such cases, if the MME receives a TAU Request or Attach Request protected with a non-current full EPS security context, then this context becomes the current EPS security context and the MME shall delete any existing current EPS security context. After a successful run of a NAS SMC relating to the eKSI associated with an EPS security context, this context becomes the current EPS security context and shall overwrite any existing current EPS security context. The rules for handling security contexts after a handover to E-UTRAN are given in clause 9.2.2.1. The full native EPS NAS security context (except for KNASenc and KNASint) shall be stored on the USIM (if the USIM supports EMM parameters storage) or in the non-volatile memory of the ME (if the USIM does not support EMM parameters storage) only during the process of transitioning to EMM-DEREGISTERED state or when an attempt to transition away from EMM-DEREGISTERED state fails, as described in clause 7.2.5. The ME shall under no other circumstances store the EPS NAS security context parameters on the USIM or non-volatile ME memory.

Each separate KASME has a distinct pair of NAS COUNTs, one NAS COUNT for uplink and one NAS COUNT for downlink, associated with it. It is essential that the NAS COUNTs for a particular KASME are not reset to the start values (that is the NAS COUNTs only have their start value when a new KASME is created). This prevents the security issue of using the same NAS COUNTs with the same NAS keys, e.g. key stream re-use, in the case a UE moves back and forth between two MMEs and the same NAS keys are re-derived. The NAS COUNTs shall only be set to the start value in the following cases:

• for a partial native EPS NAS security context created by a successful AKA run,
• or for an EPS NAS security context created through a context mapping during a handover from UTRAN/GERAN to E-UTRAN,
• or for an EPS NAS security context created through a context mapping during idle mode mobility from UTRAN/GERAN to E-UTRAN.

The NAS COUNTs shall not be reset during idle mode mobility or handover for an already existing native EPS NAS security context. The start value of NAS COUNT shall be zero (0).