6.2 Key hierarchy, key derivation, and distribution scheme

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

6.2.1 Key hierarchy

Requirements on 5GC and NG-RAN related to keys are described in clause 5.1.3. The following describes the keys of the key hierarchy generation in a 5GS in detail.:

Figure 6.2.1-1: Key hierarchy generation in 5GS

The keys related to authentication (see Figure 6.2.1-1) include the following keys: K, CK/IK. In case of EAP-AKA’, the keys CK’, IK’ are derived from CK, IK as specified in clause 6.1.3.1.

The key hierarchy (see Figure 6.2.1-1) includes the following keys: K_AUSF, K_SEAF, K_AMF, K_NASint, K_NASenc, K_N3IWF, K_gNB, K_RRCint, K_RRCenc, K_UPint and K_UPenc.

Keys for AUSF in home network:

– K_AUSF is a key derived

– by ME and AUSF from CK’, IK’ in case of EAP-AKA’, CK’ and IK’ is received by AUSF as a part of transformed AV from ARPF; or,

– by ME and ARPF from CK, IK in case of 5G AKA, K_AUSF is received by AUSF as a part of the 5G HE AV from ARPF.

– K_SEAF is an anchor key derived by ME and AUSF from K_AUSF. K_SEAF is provided by AUSF to the SEAF in the serving network.

Key for AMF in serving network:

– K_AMF is a key derived by ME and SEAF from K_SEAF. K_AMF is further derived by ME and source AMF when performing horizontal key derivation.

Keys for NAS signalling:

– K_NASint is a key derived by ME and AMF from K_AMF, which shall only be used for the protection of NAS signalling with a particular integrity algorithm.

– K_NASenc is a key derived by ME and AMF from K_AMF, which shall only be used for the protection of NAS signalling with a particular encryption algorithm.

Key for NG-RAN:

– K_gNB is a key derived by ME and AMF from K_AMF. K_gNB is further derived by ME and source gNB when performing horizontal or vertical key derivation. The K_gNB is used as K_eNB between ME and ng-eNB.

Keys for UP traffic:

– K_UPenc is a key derived by ME and gNB from K_gNB, which shall only be used for the protection of UP traffic with a particular encryption algorithm.

– K_UPint is a key derived by ME and gNB from K_gNB, which shall only be used for the protection of UP traffic between ME and gNB with a particular integrity algorithm.

Keys for RRC signalling:

– K_RRCint is a key derived by ME and gNB from K_gNB, which shall only be used for the protection of RRC signalling with a particular integrity algorithm.

– K_RRCenc is a key derived by ME and gNB from K_gNB, which shall only be used for the protection of RRC signalling with a particular encryption algorithm.

Intermediate keys:

– NH is a key derived by ME and AMF to provide forward security as described in Clause A.10.

– K_NG-RAN * is a key derived by ME and NG-RAN (i.e., gNB or ng-eNB) when performing a horizontal or vertical key derivation as specified in Clause 6.9. 2.1.1 using a KDF as specified in Clause A.11/A.12.

– K_AMF‘ is a key that can be derived by ME and AMF when the UE moves from one AMF to another during inter-AMF mobility as specified in Clause 6.9.3 using a KDF as specified in Annex A.13.

Key for the non-3GPP access:

– K_N3IWF is a key derived by ME and AMF from K_AMF for the non-3GPP access. K_N3IWF is not forwarded between N3IWFs.

NOTE 1: The key hierarchy for standalone non-public networks when an authentication method other than 5G AKA or EAP-AKA’ is used is given in Annex I.2.3.

6.2.2 Key derivation and distribution scheme

6.2.2.1 Keys in network entities

Keys in the ARPF

The ARPF shall process the long-term key K and any other sensitive data only in its secure environment. The key K shall be 128 bits or 256 bits long.

During an authentication and key agreement procedure, the ARPF shall derive CK’ and IK’ from K in case EAP-AKA’ is used and derive K_AUSF from K in case 5G AKA is used. The ARPF shall forward the derived keys to the AUSF.

The ARPF holds the Home Network Private Key that is used by the SIDF to deconceal the SUCI and reconstruct the SUPI. The generation and storage of this key material is out of scope of the present document.

Keys in the AUSF

In case EAP-AKA’ is used as authentication method, the AUSF shall derive a key K_AUSF from CK’ and IK’ for EAP-AKA’ as specified in clause 6.1.3.1. In case that 5G AKA is used as authentication method, the UDM/ARPF shall generate the KAUSF as specified in clause 6.1.3.2.

The K_AUSF may be stored in the AUSF between two subsequent authentication and key agreement procedures.

When the AUSF stores the K_AUSF, the AUSF shall store the latest K_AUSF generated after successful completion of the latest primary authentication. The authentication is considered as successful and the AUSF shall store the latest K_AUSF or replace the old K_AUSF with the new K_AUSF (if the AMF(s) end up selecting the same AUSF instance for (re)authentication of the UE):

– in case 5G AKA is used as authentication method, when the RES* and the XRES* are equal (see clause 6.1.3.2.0, Step 11).

– in case EAP-AKA’ is used as authentication method, when the AUSF sends an EAP-Success message to the SEAF (see clause 6.1.3.1, Step 10).

The AUSF shall generate the anchor key, also called K_SEAF, from the authentication key material received from the ARPF during an authentication and key agreement procedure.

Keys in the SEAF

The SEAF receives the anchor key, K_SEAF, from the AUSF upon a successful primary authentication procedure in each serving network.

The SEAF shall never transfer K_SEAF to an entity outside the SEAF. Once K_AMF is derived K_SEAF shall be deleted.

The SEAF shall generate K_AMF from K_SEAF immediately following the authentication and key agreement procedure and hands it to the AMF.

NOTE 1: This implies that a new K_AMF, along with a new K_SEAF, is generated for each run of the authentication and key agreement procedure.

NOTE 2: The SEAF is co-located with the AMF.

Keys in the AMF

The AMF receives K_AMF from the SEAF or from another AMF.

The AMF shall, based on policy, derive a key K_AMF‘ from K_AMF for transfer to another AMF in inter-AMF mobility. The receiving AMF shall use K’_AMF as its key K_AMF.

NOTE 3: The precise rules for key handling in inter-AMF mobility can be found in clause 6.9.3.

The AMF shall generate keys K_NASint and K_NASenc dedicated to protecting the NAS layer.

The AMF shall generate access network specific keys from K_AMF. In particular,

– the AMF shall generate K_gNB and transfer it to the gNB.

– the AMF shall generate NH and transfer it to the gNB, together with the corresponding NCC value.
The AMF may also transfer an NH key, together with the corresponding NCC value, to another AMF, cf. clause 6.9.

– the AMF shall generate K_N3IWF and transfer it to the N3IWF when K_AMF is received from SEAF, or when K_AMF‘ is received from another AMF.

Keys in the NG-RAN

The NG-RAN (i.e., gNB or ng-eNB) receives K_gNB and NH from the AMF. The ng-eNB uses K_gNB as K_eNB.

The NG-RAN (i.e., gNB or ng-eNB) shall generate all further access stratum (AS) keys from K_gNB and /or NH.

Keys in the N3IWF

The N3IWF receives K_N3IWF from the AMF.

The N3IWF shall use K_N3IWF as the key MSK for IKEv2 between UE and N3IWF in the procedures for untrusted non-3GPP access, cf. clause 11.

Figure 6.2.2-1 shows the dependencies between the different keys, and how they are derived from the network nodes point of view.

Figure 6.2.2-1: Key distribution and key derivation scheme for 5G for network nodes

NOTE 4: The key derivation and distribution scheme for standalone non-public networks, when an authentication method other than 5G AKA or EAP-AKA’ is used, is given in Annex I.2.3.

6.2.2.2 Keys in the UE

For every key in a network entity, there is a corresponding key in the UE.

Figure 6.2.2-2 shows the corresponding relations and derivations as performed in the UE.

Figure 6.2.2-2: Key distribution and key derivation scheme for 5G for the UE

Keys in the USIM

The USIM shall store the same long-term key K that is stored in the ARPF.

During an authentication and key agreement procedure, the USIM shall generate key material from K that it forwards to the ME.

If provisioned by the home operator, the USIM shall store the Home Network Public Key used for concealing the SUPI.

Keys in the ME

The ME shall generate the K_AUSF from the CK, IK received from the USIM. The generation of this key material is specific to the authentication method and is specified in clause 6.1.3.

When 5G AKA is used, the generation of RES* from RES shall be performed by the ME.

The UE shall store the latest K_AUSF or replace the old K_AUSF with the latest K_AUSF, after successful completion of the latest primary authentication . If the USIM supports 5G parameters storage, K_AUSF shall be stored in the USIM. Otherwise, K_AUSF shall be stored in the non-volatile memory of the ME.

In case 5G AKA is used as an authentication method, upon receiving the valid NAS Security Mode Command message from the AMF (to take the corresponding partial context derived from the newly generated K_AUSF into use), the UE shall consider the performed primary authentication as successful and the UE shall store the newly generated K_AUSF as the latest K_AUSF or replace the old K_AUSF with the latest K_AUSF.

In case of any key generating EAP method in the present document (EAP-AKA’, EAP-TLS in Annex B, EAP methods in Annex I) is used as the authentication method for the primary (re)authentication, upon receiving the EAP-Success message, the primary authentication shall be considered as successful and the UE shall store the newly generated K_AUSF as the latest K_AUSF or replace the old K_AUSF with the latest K_AUSF.

The ME shall perform the generation of K_SEAF from the K_AUSF. If the USIM supports 5G parameters storage, K_SEAF shall be stored in the USIM. Otherwise, K_SEAF shall be stored in the non-volatile memory of the ME.

The ME shall perform the generation of K_AMF. If the USIM supports 5G parameters storage, K_AMF shall be stored in the USIM. Otherwise, K_AMF shall be stored in the non-volatile memory of the ME.

The ME shall perform the generation of all other subsequent keys that are derived from the K_AMF.

Any 5G security context, K_AUSF and K_SEAF that are stored at the ME shall be deleted from the ME if:

a) the USIM is removed from the ME when the ME is in power on state;

b) the ME is powered up and the ME discovers that the USIM is different from the one which was used to create the 5G security context;

c) the ME is powered up and the ME discovers that there is no USIM is present at the ME.

NOTE 1: The key derivation and distribution scheme for standalone non-public networks, when an authentication method other than 5G AKA or EAP-AKA’ is used, is given in Annex I.2.3.

6.2.3 Handling of user-related keys

6.2.3.1 Key setting

Key setting happens at the end of successful authentication procedure. Authentication and key setting may be initiated by the network as often as the network operator wishes when an active NAS connection exists. Key setting can occur as soon as the identity of the mobile subscriber (i.e. 5G-GUTI or SUPI) is known by the AMF. A successful run of 5G AKA or EAP AKA’ results in a new K_AMF that is stored in the UE and the AMF with a new partial, non-current security context.

NAS keys (i.e. K_NASint and K_NASenc) and AS keys (i.e. K_gNB, K_RRCenc, K_RRCint, K_UPenc, K_UPint) are derived from K_AMF using the KDFs specified in Annex A. The NAS keys derived from the new K_AMF are taken in use in the AMF and the UE by means of the NAS security mode command procedure (see sub-clause 6.7.2). The AS keys are taken into use with the AS security mode command procedure (see sub-clause 6.7.4) or with the key change on the fly procedure (see sub-clause 6.9.6).

For the non-3GPP access, the key K_N3IWF is derived from the K_AMF. K_N3IWF is stored in the UE and the N3IWF as specified in subclause 7.2.1. This key K_N3IWF and the IPsec SA cryptographic keys are taken into use with the establishment of IPsec Security Association (SA) between the UE and the N3IWF.

NOTE: For mapped security contexts, the K_AMF is derived from EPS keys during interworking with EPS (see clause 8).

6.2.3.2 Key identification

The key K_AMF shall be identified by the key set identifier ngKSI. ngKSI may be either of type native or of type mapped. An ngKSI shall be stored in the UE and the AMF together with K_AMF and the temporary identifier 5G-GUTI, if available.

NOTE 1: The 5G-GUTI points to the AMF where the K_AMF is stored.

A native ngKSI is associated with the K_SEAF and K_AMF derived during primary authentication. It is allocated by the SEAF and sent with the authentication request message to the UE where it is stored together with the K_AMF. The purpose of the ngKSI is to make it possible for the UE and the AMF to identify a native security context without invoking the authentication procedure. This is used to allow re-use of the native security context during subsequent connection set-ups.

A mapped ngKSI is associated with the K_AMF derived from EPS keys during interworking, cf. clause 8 of the present document. It is generated in both the UE and the AMF respectively when deriving the mapped K_AMF when moving from EPS to 5GS. The mapped ngKSI is stored together with the mapped K_AMF.

The purpose of the mapped ngKSI is to make it possible for the UE and the AMF to indicate the use of the mapped K_AMF in interworking procedures (for details cf. clause 8).

The format of ngKSI shall allow a recipient of such a parameter to distinguish whether the parameter is of type native or of type mapped. The format shall contain a type field and a value field. The type field indicates the type of the key set. The value field consists of three bits where seven values, excluding the value ‘111’, are used to identify the key set. The value ‘111’ is reserved to be used by the UE to indicate that a valid K_AMF is not available for use. The format of ngKSI is described in [35]

K_NASenc and K_NASint in the key hierarchy specified in clause 6.2.1, which are derived from K_AMF, can be uniquely identified by ngKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier}, which are used to derive these keys from K_AMF.

The K_N3IWF can be uniquely determined by ngKSI together with the uplink NAS COUNT are used to derive it according to clause A.9.

The initial K_gNB can be uniquely determined by ngKSI, together with the uplink NAS COUNT are used to derive it according to clause A.9.

The intermediate key NH as defined in clause 6.9.2.1.1 can be uniquely determined by ngKSI, together with the initial K_gNB derived from the current 5G NAS security context for use during the ongoing CM-CONNECTED state and a counter counting how many NH-derivations have already been performed from this initial K_gNB according to clause A.10. The next hop chaining counter, NCC, represents the 3 least significant bits of this counter.

Intermediate key K_NG-RAN*, as well as non-initial K_gNB, defined in clause 6.9.2.1.1 can be uniquely identified by ngKSI together with those parameters from the set {K_gNB or NH, sequence of PCIs and ARFCN-DLs}, which are used to derive these keys from K_gNB or NH.

K_RRCint, K_RRCenc, K_UPint, and K_UPenc in the key hierarchy specified in clause 6.2.1 can be uniquely identified by ngKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier}, which are used to derive these keys from K_gNB.

NOTE 2: In addition to 5G security contexts, the UE may also cache EPS security contexts. These EPS security contexts are identified by the eKSI, as defined in TS 33.401 [10].

6.2.3.3 Key lifetimes

K_AUSF, and K_SEAF shall be created when running a successful primary authentication as described in clause 6.1.3.

K_AMF shall be created in the following cases:

1. Primary authentication

2. NAS key re-keying as described in clause 6.9.4.2

3. NAS key refresh as described in clause 6.9.4.3

4. Interworking procedures with EPS (cf. clauses 8 and 10)

In case the UE does not have a valid K_AMF, an ngKSI with value "111" shall be sent by the UE to the network, which can initiate (re)authentication procedure to get a new K_AMF based on a successful primary authentication.

K_NASint and K_NASenc are derived based on a K_AMF when running a successful NAS SMC procedure as described in clause 6.7.2.

K_N3IWF is derived from K_AMF and remains valid as long as the UE is connected to the 5GC over non- 3gpp access or until the UE is reauthenticated.

K_gNB and NH are derived based on K_AMF or K_gNB or NH in the following cases:

1. Inter-gNB-CU-handover as described in clause 6.9.2.3.1

2. State transitions as described in clause 6.8

3. AS key re-keying as described in clause 6.9.4.4

4. AS key refresh as described in clause 6.9.4.5

The K_RRCint, K_RRCenc, K_UPint and K_UPenc are derived based on K_gNB after a new K_gNB is derived.