14 Security

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

14.1 Overview and Principles

The following principles apply to E-UTRAN security:

– The keys used for NAS and AS protection shall be dependent on the algorithm with which they are used.

– The eNB keys are cryptographically separated from the EPC keys used for NAS protection (making it impossible to use the eNB key to figure out an EPC key).

– For SCG bearers in DC, the SeNB keys are cryptographically separated from the eNB keys.

– The AS (RRC and UP) and NAS keys are derived in the EPC/UE from key material that was generated by a NAS (EPC/UE) level AKA procedure (K_ASME) and identified with a key identifier (KSI_ASME).

– For SCG bearers in DC, the AS (UP) keys are derived in the SeNB/UE from key material that was generated in the MeNB/UE.

– The eNB key (K_eNB) is sent from the EPC to the eNB when the UE is entering ECM-CONNECTED state (i.e. during RRC connection or S1 context setup).

– For SCG bearers in DC, the SeNB key (S-K_eNB) is sent from the MeNB to the SeNB when adding an SCG.

– For LWA bearers, the WT Counter, if included in LWA Configuration, is used when computing the S-K_WT (as specified in TS 33.401 [22], clause G and TS 36.331 [16], clause 5.6.14.2). If WT Counter is not signalled to the UE, the UE uses authentication methods specified in TS 33.402 [70], clause 6, as described in 22A.1.8.

– For LWIP, the LWIP Counter in the LWIP Configuration is used when computing the LWIP-PSK (as specified in TS 33.401 [13], clause A.13, and TS 36.331 [16], subcause 5.6.17.2).

– Separate AS and NAS level security mode command procedures are used. AS level security mode command procedure configures AS security (RRC and user plane) and NAS level security mode command procedure configures NAS security. Both integrity protection and ciphering for RRC are activated within the same AS SMC procedure. User plane ciphering is activated at the same time as RRC ciphering. An EN-DC capable UE supporting user plane integrity protection (see TS 24.301 [20]) when connected to E-UTRA/EPC (as specified in TS 33.401 [22]) shall support integrity protection for all DRBs (MN and SN terminated) at any data rate, up to and including the highest data rate supported by the UE for both UL and DL. When supported, user plane integrity protection with NR PDCP can be activated (on a per radio bearer basis) upon DRB addition.

– Keys stored inside eNBs shall never leave a secure environment within the eNB (except when done in accordance with this or other 3GPP specifications), and user plane data ciphering/deciphering shall take place inside the secure environment where the related keys are stored.

– Key material for the eNB keys is sent between the eNBs during ECM-CONNECTED intra-E-UTRAN mobility and from the MeNB to the SeNB in DC for SCG bearer during SCG addition and SCG change.

– A sequence number (COUNT) is used as input to the ciphering and integrity protection. A given sequence number must only be used once for a given eNB key (except for identical re-transmission) on the same radio bearer in the same direction. The same sequence number can be used for both ciphering and integrity protection.

– A hyper frame number (HFN) (i.e. an overflow counter mechanism) is used in the eNB and UE in order to limit the actual number of sequence number bits that is needed to be sent over the radio. The HFN needs to be synchronized between the UE and eNB.

– No integrity protection initialisation number (FRESH).

– Since SIM access is not granted in E-UTRAN TS 33.401 [22] except for making IMS Emergency calls, idle mode UE not equipped with USIM shall not attempt to reselect to E-UTRAN unless it is originating an IMS Emergency call. The RNC may try to prevent handover to E-UTRAN for example by identifying a SIM based UE from the security keys provided by the CN.

A simplified key derivation is depicted on Figure 14.1-1 below, where:

– K_NASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm This key is derived by UE and MME from K_{ASME ,}as well as an identifier for the integrity algorithm.

– K_NASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by UE and MME from K_ASME,as well as an identifier for the encryption algorithm.

– K_eNBis a key derived by UE and MME from K_ASME. K_eNB may also be derived by the target eNB from NH at handover. K_eNB shall be used for the derivation of K_RRCint, K_RRCenc and K_UPenc, and for the derivation of K_eNB_* upon handover.

– K_eNB* is a key derived by UE and source eNB from either K_eNB or from a fresh NH. K_eNB* shall be used by UE and target eNB as a new K_eNB for RRC and UP traffic.

– K_UPint is a key, which shall only be used for the protection of UP traffic with a particular integrity algorithm. This key is derived by UE and eNB from K_eNB, as well as an identifier for the integrity algorithm.

– K_UPencis a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by UE and eNB from K_eNB, as well as an identifier for the encryption algorithm.

– K_RRCintis a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm. K_RRCint is derived by UE and eNB from K_eNB, as well as an identifier for the integrity algorithm.

– K_RRCencis a key, which shall only be used for the protection of RRC traffic with a particular encryption algorithm. K_RRCenc is derived by UE and eNB from K_eNB as well as an identifier for the encryption algorithm.

– Next Hop (NH) is used by UE and eNB in the derivation of K_eNB* for the provision of "forward security", as specified in TS 33.401 [22]. NH is derived by UE and MME from K_ASME and K_eNB when the security context is established, or from K_ASME and previous NH, otherwise.

– Next Hop Chaining Count (NCC) is a counter related to NH (i.e. the amount of Key chaining that has been performed) which allow the UE to be synchronised with the eNB and to determine whether the next K_eNB* needs to be based on the current K_eNB or a fresh NH.

Figure 14.1-1: Key Derivation

Key derivation for SCG bearers in DC is depicted on Figure 14.1-2 below, where:

– SCG Counter is a counter used as freshness input into S-K_eNB derivations (see TS 33.401 [22], Annex E.2.4).

Figure 14.1-2: DC Key Derivation

The MME invokes the AKA procedures by requesting authentication vectors to the HE (Home environment) if no unused EPS authentication vectors have been stored. The HE sends an authentication response back to the MME that contains a fresh authentication vector, including a base-key named K_ASME. Thus, as a result of an AKA run, the EPC and the UE share K_ASME. From K_ASME, the NAS keys, (and indirectly) K_eNB keys and NH are derived. The K_ASME is never transported to an entity outside of the EPC, but K_eNB and NH are transported to the eNB from the EPC when the UE transitions to ECM-CONNECTED. From the K_eNB, the eNB and UE can derive the UP and RRC keys.

RRC and UP keys are refreshed at handover. K_eNB* is derived by UE and source eNB from target PCI, target frequency and K_eNB (this is referred to as a horizontal key derivation and is indicated to UE with an NCC that does not increase) or from target PCI, target frequency and NH (this is referred to as a vertical key derivation and is indicated to UE with an NCC increase). K_eNB* is then used as new K_eNB for RRC and UP traffic at the target. When the UE goes into ECM-IDLE all keys are deleted from the eNB except for the UE which was enabled to use User Plane CIoT EPS Optimisation.

For SCG Bearers in DC, UP keys are updated at SCG change by indicating in RRC signalling to the UE the value of the SCG Counter to be used in key derivation. When K_eNB is refreshed, SCG Counter shall be reset and S-K_eNB shall be newly derived from the K_eNB.

COUNT reusing avoidance for the same radio bearer identity in RRC_CONNECTED mode without K_eNB change is left to eNB implementation e.g. by using intra-cell handover, smart management of radio bearer identities or triggering a transition to RRC_IDLE.

SCG bearers in DC share a common pool of radio bearer identities (DRB IDs) together with the MCG bearers and when no new DRB ID can be allocated for an SCG bearer without guaranteeing COUNT reuse avoidance, the MeNB shall derive a new S-K_eNB. SeNB indicates to MeNB when uplink or downlink PDCP COUNTs are about to wrap around and MeNB shall update the S-K_eNB. To update the S-K_eNB, the MeNB increases the SCG Counter and uses it to derive a new S-K_eNB from the currently active KeNB in the MeNB. The MeNB sends the newly derived S-K_eNB to the SeNB. The newly derived S-K_eNB is then used by the SeNB in computing a new encryption key K_UPenc which is used with all DRBs in the SeNB for this UE. Furthermore, when the SCG Counter approaches its maximum value, the MeNB refreshes the currently active KeNB, before any further S-K_eNB is derived.

In case of HFN de-synchronisation in RRC_CONNECTED mode between the UE and eNB, the UE is pushed to IDLE.

When AS security context is to be established in the eNB, the MME sends the complete UE security capabilities to the eNB (i.e. all bits for every EPS or NR security capability defined in TS 24.301 [20] and received in NAS signaling). At handover (or during Dual Connectivity or at UE Context retrieval), the complete UE security capabilities are also sent by the source eNB to the target eNB (or by the old eNB to the new eNB or by the MeNB to the SeNB respectively).

14.2 Security termination points

The table below describes the security termination points.

Table 14.2-1 Security Termination Points

	Ciphering	Integrity Protection
NAS Signalling	Required and terminated in MME	Required and terminated in MME
U-Plane Data	Required and terminated in eNB	Terminated in eNB (NOTE 1)
RRC Signalling (AS)	Required and terminated in eNB	Required and terminated in eNB
MAC Signalling (AS)	Not required	Not required
NOTE 1: User Plane Integrity Protection may be supported by UEs capable of EN-DC operation. This version of the specifications does not provide UPIP support for other UEs when using E-UTRA.

The table below describes the security termination points for DC with SCG bearers and split bearers.

Table 14.2-2 Security Termination Points in DC

	Ciphering	Integrity Protection
NAS Signalling	Required and terminated in MME	Required and terminated in MME
U-Plane Data for MCG bearers	Required and terminated in MeNB	Not Required
U-Plane Data for SCG bearers	Required and terminated in SeNB	Not Required
U-Plane Data for split bearers	Required and terminated in MeNB	Not Required
RRC Signalling (AS)	Required and terminated in MeNB	Required and terminated in MeNB

14.3 State Transitions and Mobility

14.3.1 RRC_IDLE to RRC_CONNECTED

As a general principle, on RRC_IDLE to RRC_CONNECTED transitions, RRC protection keys and UP protection keys shall be generated while keys for NAS protection as well as higher layer keys are assumed to be already available in the MME. These higher layer keys may have been established in the MME as a result of an AKA run, or as a result of a transfer from another MME during handover or idle mode mobility, as specified in TS 33.401 [22].

14.3.2 RRC_CONNECTED to RRC_IDLE

Except for the UE which was enabled to use User Plane CIoT EPS Optimisation, on RRC_CONNECTED to RRC_IDLE transitions, eNBs shall delete the keys they store such that state for idle mode UEs only has to be maintained in MME. It is also assumed that eNB does no longer store state information about the corresponding UE and deletes the current keys from its memory. In particular, on connected to idle transitions:

– The eNB and UE deletes NH, K_eNB , K_RRCenc , K_RRCint and K_UPenc and related NCC.

– MME and UE keeps K_ASME, K_NASint and K_NASenc stored.

On RRC_CONNECTED to RRC_IDLE transitions for the UE which was enabled to use User Plane CIoT EPS Optimisation, the eNBs, the UE and MME shall maintain the keys they store.

14.3.3 Intra E-UTRAN Mobility

The key hierarchy does not allow, as is, explicit RRC and UP key updates, but RRC and UP keys are derived based on the algorithm identifiers and K_eNB which results with new RRC and UP keys at every handover:

– Source eNB and UE independently create K_eNB* with the input parameters as described in TS 33.401 [22];

– K_eNB* is given to Target eNB during the HO preparation phase;

– Both Target eNB and UE considers the new K_eNB equal to the received K_eNB*.

The handling of HFN and PDCP SN at handover depends on the type of radio bearer:

– SRB: HFN and PDCP SN are reset.

– RLC-UM bearers: HFN and PDCP SN are reset.

– RLC-AM bearers: PDCP SN and HFN are maintained (10.1.2.3).

NOTE: COUNT reusing avoidance is left to network implementation.

For LWA, eNB may not trigger the S-K_WT update during handover without WT change. In such a case, the eNB sends the WT counter to the UE after handover via a separate RRC reconfiguration procedure. The UE does not need to perform reauthentication with WLAN immediately even though the KeNB is updated but shall use the updated WT counter the next time the UE does re-association with WLAN. As the PDCP PDUs may continue to be transmitted over WLAN during handover without WT change, the transmitter uses an end-marker PDCP control PDU to inform the receiver of the last PDCP PDU encrypted with source K_eNB, as described in 10.1.2.9.

14.3.4 SeNB Removal

For SCG bearers in DC, at SeNB removal, the SeNB shall delete the keys it stores. It is also assumed that SeNB does no longer store state information about the corresponding UE and deletes the current keys from its memory. In particular, at SeNB removal:

– The SeNB and UE delete S-K_eNB and K_UPenc.

– The MeNB and UE keep K_eNB.

14.4 AS Key Change in RRC_CONNECTED

If AS Keys (K_UPenc,K_RRCint, K_RRCenc, K_UPint) need to be changed in RRC_CONNECTED, an intra-cell handover shall be used.

For SCG bearers in DC, if AS Key (K_UPenc) needs to be changed, the SCG change shall be performed.

14.5 Security Interworking

Inter-RAT handover from UTRAN to E-UTRAN is only supported after activation of integrity protection in UTRAN. Security may be activated in the target RAN using null ciphering algorithms. If ciphering was not running in UTRAN, it will be activated at handover to E-UTRAN. Integrity protection shall be activated in E-UTRAN on handover from UTRAN/GERAN.

For E-UTRAN to UTRAN/GERAN mobility, the MME shall derive and transfer to the SGSN a confidentially key and an integrity key derived from K_ASME and other input parameters as specified in TS 33.401 [22]. Based on this information, the SGSN can in turn derive appropriate keys to be used in the target RAN.

Similarly for UTRAN/GERAN to E-UTRAN mobility, the SGSN shall derive and transfer to the MME a confidentially key and an integrity key CK and IK. Based on this information and other input parameters as specified in TS 33.401 [22], the MME and UE can in turn derive K_ASME.

14.6 RN integrity protection for DRB(s)

Between the DeNB and the RN, integrity protection is required for the DRB(s) carrying S1AP and/or X2AP signalling and optional for other DRB(s).

K_UPint, used for the integrity protection of the DRBs, is derived by the RN and the DeNB from KeNB, as well as an identifier for the integrity algorithm used as specified in TS 33.401 [22]. K_UPint is generated, changed or deleted when other AS keys are generated, changed or deleted.