Content for  TS 33.501  Word version:  19.0.0

The security requirements given in this clause apply to all types of gNBs. More stringent requirements for specific types of gNBs may be defined in other 3GPP specifications.

The gNB shall support ciphering of user data between the UE and the gNB. The gNB shall activate ciphering of user data based on the security policy sent by the SMF. The gNB shall support ciphering of RRC-signalling. The gNB shall implement the following ciphering algorithms: The gNB may implement the following ciphering algorithm: Confidentiality protection of user data between the UE and the gNB is optional to use. Confidentiality protection of the RRC-signalling is optional to use. Confidentiality protection should be used whenever regulations permit.

The gNB shall support integrity protection and replay protection of user data between the UE and the gNB. The gNB shall activate integrity protection of user data based on the security policy sent by the SMF. The gNB shall support integrity protection and replay protection of RRC-signalling. The gNB shall support the following integrity protection algorithms: The gNB may support the following integrity protection algorithm: Integrity protection of the user data between the UE and the gNB is optional to use, and shall not use NIA0. All RRC signalling messages except those explicitly listed in TS 38.331 as exceptions shall be integrity-protected with an integrity protection algorithm different from NIA0, except for unauthenticated emergency calls. NIA0 shall be disabled in gNB in the deployments where support of unauthenticated emergency session is not a regulatory requirement.

Setting up and configuring gNBs by O&M systems shall be authenticated and authorized by gNB so that attackers shall not be able to modify the gNB settings and software configurations via local or remote access.

• The certificate enrolment mechanism specified in TS 33.310 for base station should be supported for gNBs. The decision on whether to use the enrolment mechanism is left to operators.
• Communication between the O&M systems and the gNB shall be confidentiality, integrity and replay protected from unauthorized parties. The security associations between the gNB and an entity in the 5G Core or in an O&M domain trusted by the operator shall be supported. These security association establishments shall be mutually authenticated. The security associations shall be realized according to TS 33.210 and TS 33.310.
• The gNB shall be able to ensure that software/data change attempts are authorized.
• The gNB shall use authorized data/software.
• Sensitive parts of the boot-up process shall be executed with the help of the secure environment.
• Confidentiality of software transfer towards the gNB shall be ensured.
• Integrity protection of software transfer towards the gNB shall be ensured.
• The gNB software update shall be verified before its installation (cf. subclause 4.2.3.3.5 of TS 33.117).

The 5GC provides subscription specific session keying material for the gNBs, which also hold long term keys used for authentication and security association setup purposes. Protecting all these keys is important. The following requirements apply:

• Any part of a gNB deployment that stores or processes keys in cleartext shall be protected from physical attacks. If not, the whole entity is placed in a physically secure location, then keys in cleartext shall be stored and processed in a secure environment. Keys stored inside a secure environment in any part of the gNB shall never leave the secure environment except when done in accordance with this or other 3GPP specifications.

The following requirements apply:

• Any part of a gNB deployment that stores or processes user plane data in cleartext shall be protected from physical attacks. If not, the whole entity is placed in a physically secure location, then user plane data in cleartext shall be stored and processed in a secure environment.

The following requirements apply:

• Any part of a gNB deployment that stores or processes control plane data in cleartext shall be protected from physical attacks. If not, the whole entity is placed in a physically secure location, then control plane data in cleartext shall be stored and processed in a secure environment.

The secure environment is logically defined within the gNB. It ensures protection and secrecy of all sensitive information and operations from any unauthorized access or exposure. The following list defines the requirements of the secure environment:

• The secure environment shall support secure storage of sensitive data, e.g. long-term cryptographic secrets and vital configuration data.
• The secure environment shall support the execution of sensitive functions, e.g. en-/decryption of user data and the basic steps within protocols which use long term secrets (e.g. in authentication protocols).
• The secure environment shall support the execution of sensitive parts of the boot process.
• The secure environment's integrity shall be assured.
• Only authorised access shall be granted to the secure environment, i.e. to data stored and used within it, and to functions executed within it.

Requirements given below apply to gNBs with split DU-CU implementations using F1 interface defined in TS 38.470. Signalling traffic (i.e. both F1-C interface management traffic defined in TS 38.470 and F1-C signalling bearer defined in TS 38.472) and user plane data can be sent on the F1 interface between a given DU and its CU.

• F1-C interface shall support confidentiality, integrity and replay protection.
• All management traffic carried over the CU-DU link shall be integrity, confidentiality and replay protected.
• The gNB shall support confidentiality, integrity and replay protection on the gNB DU-CU F1-U interface [33] for user plane.
• F1-C and management traffic carried over the CU-DU link shall be protected independently from F1-U traffic.

Requirements given below apply to gNBs with split DU-CU implementations, particularly with an open interface between CU-CP and CU-UP using the E1 interface defined in TS 38.460.

• The E1 interface between CU-CP and CU-UP shall be confidentiality, integrity and replay protected.

The AMF shall support ciphering of NAS-signalling. The AMF shall support the following ciphering algorithms: The AMF may support the following ciphering algorithm: Confidentiality protection NAS-signalling is optional to use. Confidentiality protection should be used whenever regulations permit.

The AMF shall support integrity protection and replay protection of NAS-signalling. The AMF shall support the following integrity protection algorithms: The AMF may support the following integrity protection algorithm: NIA0 shall be disabled in AMF in the deployments where support of unauthenticated emergency session is not a regulatory requirement. All NAS signalling messages except those explicitly listed in TS 24.501 as exceptions shall be integrity-protected with an algorithm different to NIA-0 except for emergency calls.

The AMF shall support to trigger primary authentication using the SUCI. The AMF shall support assigning 5G-GUTI to the UE. The AMF shall support reallocating 5G-GUTI to UE. The AMF shall be able to confirm SUPI from UE and from home network. The AMF shall deny service to the UE if this confirmation fails.

The long-term key(s) used for authentication and security association setup purposes shall be protected from physical attacks and shall never leave the secure environment of the UDM/ARPF unprotected.

The SIDF is responsible for de-concealment of the SUCI and shall fulfil the following requirements:

• The SIDF shall be a service offered by UDM.
• The SIDF shall resolve the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

The Home Network Private Key used for subscriber privacy shall be protected from physical attacks in the UDM. The UDM shall hold the Home Network Public Key Identifier(s) for the private/public key pair(s) used for subscriber privacy. The algorithm used for subscriber privacy shall be executed in the secure environment of the UDM.