Content for TS 33.401 Word version: 18.1.0

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…

5.1 User-to-Network security 5.1.0 General 5.1.1 User identity and device confidentiality 5.1.2 Entity authentication 5.1.3 User data and signalling data confidentiality 5.1.4 User data and signalling data integrity 5.2 Security visibility and configurability 5.3 Security requirements on eNodeB 5.3.1 General 5.3.2 Requirements for eNB setup and configuration 5.3.3 Requirements for key management inside eNB 5.3.4 Requirements for handling User plane data for the eNB 5.3.4a Requirements for handling Control plane data for the eNB 5.3.5 Requirements for secure environment of the eNB
...

5 Security Features p. 18

5.1 User-to-Network security p. 18

5.1.0 General |R10| p. 18

The statements relating to eNBs in clause 5.1 apply also to RNs regarding the security between a UE and a relay node.

The statements relating to UEs in clause 5.1 apply also to RNs regarding the security between a relay node and a Donor eNB and between a relay node and its MME unless stated otherwise.

5.1.1 User identity and device confidentiality p. 18

User identity confidentiality is as defined by clause 5.1.1 of TS 33.102

From subscriber's privacy point of view, the MSIN, the IMEI, and the IMEISV should be confidentiality protected.

The UE shall provide its equipment identifier IMEI or IMEISV to the network, if the network asks for it in an integrity-protected request.

The IMEI and IMEISV shall be securely stored in the terminal.

The UE shall not send IMEI or IMEISV to the network on a network request before the NAS security has been activated.

The IMEI or IMEISV shall be sent in the NAS protocol.

5.1.2 Entity authentication p. 18

Entity authentication is as defined by clause 5.1.2 of TS 33.102

5.1.3 User data and signalling data confidentiality p. 18

5.1.3.1 Ciphering requirements p. 18

Ciphering may be provided to RRC-signalling to prevent UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining. RRC signalling confidentiality is an operator option.

All S1 and X2 messages carried between RN and DeNB shall be confidentiality-protected.

Synchronization of the input parameters for ciphering shall be ensured for the protocols involved in the ciphering.

The NAS signalling may be confidentiality protected. NAS signalling confidentiality is an operator option.

When authentication of the credentials on the UICC during Emergency Calling in Limited Service Mode, as defined in the TS 23.401, can not be successfully performed, the confidentiality protection of the RRC and NAS signaling, and user plane shall be omitted (see clause 15). This shall be accomplished by the network by selecting EEA0 for confidentiality protection of NAS, RRC and user plane.

User plane confidentiality protection over the access stratum shall be done at PDCP layer and is an operator option.

User data sent via MME may be confidentiality protected

5.1.3.2 Algorithm Identifier Values p. 19

All algorithms specified in this clause are algorithms with a 128-bit input key except Null ciphering algorithm.

Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:

"0000₂"	EEA0	Null ciphering algorithm
"0001₂"	128-EEA1	SNOW 3G based algorithm
"0010₂"	128-EEA2	AES based algorithm
"0011₂"	128-EEA3	ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2 for both RRC signalling ciphering and UP ciphering. UEs and eNBs may implement 128-EEA3 for both RRC signalling ciphering and UP ciphering.

UEs and MMEs shall implement EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering. UEs and MMEs may implement 128-EEA3 for NAS signalling ciphering.

5.1.4 User data and signalling data integrity p. 19

5.1.4.1 Integrity requirements p. 19

Synchronization of the input parameters for integrity protection shall be ensured for the protocols involved in the integrity protection.

Integrity protection, and replay protection, shall be provided to NAS and RRC-signalling.

All NAS signaling messages except those explicitly listed in TS 24.301 as exceptions shall be integrity-protected. All RRC signaling messages except those explicitly listed in TS 36.331 as exceptions shall be integrity-protected.

When authentication of the credentials on the UICC during Emergency Calling in Limited Service Mode, as defined in the TS 23.401, can not be successfully performed, the integrity and replay protection of the RRC and NAS signaling shall be omitted (see clause 15). This shall be accomplished by the network by selecting EIA0 for integrity protection of NAS and RRC. EIA0 shall only be used for unauthenticated emergency calls.

User plane packets between the eNB and the UE may be integrity protected on the Uu interface. User plane packets between the RN and the UE may be integrity protected. All user plane packets carrying S1 and X2 messages between RN and DeNB shall be integrity-protected. Integrity protection for all other user plane packets between RN and DeNB may be supported.

All user data packets sent via the MME shall be integrity protected.

5.1.4.2 Algorithm Identifier Values p. 20

All algorithms specified in this clause are algorithms with a 128-bit input key.

Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier. Currently, the following values have been defined:

"0000₂"	EIA0	Null Integrity Protection algorithm
"0001₂"	128-EIA1	SNOW 3G based algorithm
"0010₂"	128-EIA2	AES based algorithm
"0011₂"	128-EIA3	ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling integrity protection. UEs and eNBs may implement 128-EIA3 for RRC signalling integrity protection.

UEs shall and eNBs may implement 128-EIA1 and 128-EIA2 for the user plane integrity protection. UEs and eNBs may implement 128-EIA3 for the user plane integrity protection.

UEs and MMEs shall implement 128-EIA1 and 128-EIA2 for NAS signalling integrity protection. UEs and MMEs may implement 128-EIA3 for NAS signalling integrity protection.

UEs shall implement EIA0 for integrity protection of NAS and RRC signalling. As specified in clause 5.1.4.1 of this specification, EIA0 is only allowed for unauthenticated emergency calls. EIA0 shall not be used for integrity protection between RN and DeNB.

Implementation of EIA0 in MMEs, RNs and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs, RNs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

5.2 Security visibility and configurability p. 20

Although in general the security features should be transparent to the user, for certain events and according to the user's concern, greater user visibility of the operation of following security feature shall be provided:

indication of access network encryption: the property that the user is informed whether the confidentiality of user data is protected on the radio access link, in particular when non-ciphered calls are set-up;

The ciphering indicator feature is specified in TS 22.101.

Configurability is the property that the user can configure whether the use or the provision of a service should depend on whether a security feature is in operation. A service can only be used if all security features, which are relevant to that service and which are required by the configurations of the user, are in operation. The following configurability features are suggested:

enabling/disabling user-USIM authentication: the user should be able to control the operation of user-USIM authentication, e.g., for some events, services or use.

5.3 Security requirements on eNodeB p. 20

5.3.1 General p. 20

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

5.3.2 Requirements for eNB setup and configuration p. 21

Setting up and configuring eNBs shall be authenticated and authorized so that attackers shall not be able to modify the eNB settings and software configurations via local or remote access.

The support of security associations is required between the Evolved Packet Core (EPC) and the eNB and between adjacent eNBs, connected via X2. These security association establishments shall be mutually authenticated and used for user and control plane communication between the entities. However, in cases when a DeNB acts as proxy for control or user plane messages to and from a RN, hop-by-hop security associations shall be used for user and control plane. The security associations shall be realized according to clause 11 and clause 12 of the present document except for the Un interface between RN and DeNB. The decision on whether or not to use the certificate enrolment mechanism specified in TS 33.310 for eNB is left to operators.
Communication between the O&M systems and the eNB shall be confidentiality, integrity and replay protected from unauthorized parties. The support of security associations is required between the eNB and an entity in the Evolved Packet Core (EPC) or in an O&M domain trusted by the operator. These security association establishments shall be mutually authenticated. The security associations shall be realized according to clause 13 for eNBs and clause D.2.5 for RNs.
The eNB shall be able to ensure that software/data change attempts are authorized.
The eNB 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 eNB shall be ensured.
Integrity protection of software transfer towards the eNB shall be ensured.

5.3.3 Requirements for key management inside eNB p. 21

TheEPC provides subscriber specific session keying material for the eNBs, which also hold long term keys used for authentication and security association setup purposes. Protecting all these keys is important.

Keys stored inside eNBs shall never leave a secure environment within the eNB except when done in accordance with this or other 3GPP specifications.

5.3.4 Requirements for handling User plane data for the eNB p. 21

It is eNB's task to cipher and decipher user plane packets between the Uu reference point and the S1/X2 reference points and to handle integrity protection for user plane packets for the S1/X2 reference points.

User plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.
The transport of user data over S1-U and X2-U shall be integrity, confidentially and replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, clause 12 shall be applied except for the Un interface between RN and DeNB.

5.3.4a Requirements for handling Control plane data for the eNB p. 21

It is eNB's task to provide confidentiality and integrity protection for control plane packets on the S1/X2 reference points.

Control plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.
The transport of control plane data over S1-MME, E1 and X2-C shall be integrity-, confidentiality- and replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, clause 11 shall be applied except for the Un interface between RN and DeNB.

5.3.5 Requirements for secure environment of the eNB p. 22

The secure environment is logically defined within the eNB and is a composition of functions for the support of sensitive operations.

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).
Sensitive data used within the secure environment shall not be exposed to external entities.
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, and to functions executed within.