7.3.4 PDCP integrity protection

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

7.3.4.1 Integrity protection / Correct functionality of EPS AS integrity algorithms / SNOW3G

7.3.4.1.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state }

ensure that {
when { Functionality of EPS AS integrity algorithms with SNOW3G is taken into use }

then { UE performs the integrity protection function in PDCP entities associated with SRBs. }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {
when { SecurityModeCommand fails the integrity protection check }

then { UE transmits SecurityModeFailure message and continues using the configuration used prior to the reception of the SecurityModeCommand message }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {
when { UE has AS security activated and integrity check fails }

then { UE initiates RRC connection re-establishment procedure }

}

7.3.4.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clauses 5.7, clause 5.1.2.2, TS 33.401 clause 5.1.4.2 and TS 36.331 clause 6.3.3.

[TS 36.323, clause 5.7]

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

The integrity protection algorithm and key to be used by the PDCP entities are configured by upper layers [3] and the integrity protection method shall be applied as specified in [6].

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the downlink and the uplink, respectively.

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

The parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specification in [6]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (K_RRCint).

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

[TS 36.323, clause 5.1.2.2]

– if integrity verification is not applicable:

– if received PDCP SN < Next_PDCP_RX_SN:

– increment RX_HFN by one;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN > Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– deliver the resulting PDCP SDU to upper layer;

– else, if integrity verification is applicable and the integrity verification fails:

– discard the received PDCP Data PDU;

– indicate the integrity verification failure to upper layer.

[TS 33.401, clause 5.1.4.2]

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

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

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

…

"0001₂" 128-EIA1 SNOW 3G

…

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 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 and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

[TS 36.331, clause 6.3.3]

The IE SecurityAlgorithmConfig is used to configure AS integrity protection algorithm (SRBs) and AS ciphering algorithm (SRBs and DRBs). For RNs, the IE SecurityAlgorithmConfig is also used to configure AS integrity protection algorithm for DRBs between the RN and the E-UTRAN.

…

SecurityAlgorithmConfig field descriptions
cipheringAlgorithm Indicates the ciphering algorithm to be used for SRBs and DRBs, as specified in TS 33.401 [32, 5.1.3.2].
integrityProtAlgorithm Indicates the integrity protection algorithm to be used for SRBs, as specified in TS 33.401 [32, 5.1.4.2]. For RNs, also indicates the integrity protection algorithm to be used for integrity protection-enabled DRB(s).

7.3.4.1.3 Test description

7.3.4.1.3.1 Pre-test conditions

System Simulator:

– Cell 1

UE:

None.

Preamble:

– The UE is in state Registered, Idle Mode (State 2) according to [18].

7.3.4.1.3.2 Test procedure sequence

Table 7.3.4.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The SS sends a Paging message to the UE on the appropriate paging block, and including the UE identity in one entry of the IE pagingRecordLists.	–	Paging (PCCH)	–	–
2	The UE transmit a RRCConnectionRequest message .	–>	RRCConnectionRequest	–	–
3	The SS transmits an RRCConnectionSetup message.	<–	RRCConnectionSetup	–	–
4	Does: The UE transmit a RRCConnectionSetupComplete message to confirm the successful completion of the connection establishment and to initiate the session management procedure by including the SERVICE REQUEST message without related PDCP Data PDU being integrity protected?	–>	RRCConnectionSetupComplete	1	P
5	The SS transmits a SecurityModeCommand message to activate AS security with SNOW3G integrity algorithms protected.	<–	SecurityModeCommand	–	–
6	Check: Does the UE transmit a SecurityModeComplete message with SNOW3G integrity algorithms and RRC integrity key protected and establish the initial security configuration.	–>	SecurityModeComplete	1	P
7	Check: Does the SecurityModeComplete message from the UE pass the SS’ integrity protection check.	–	–	1	P
8	The SS transmits an RRCConnectionRelease message.	<–	RRCConnectionRelease	–	–
9	Wait for 5 s for the UE to enter E-UTRA RRC_IDLE state.			–	–
10	The SS transmits a Paging message including a matched identity.	<–	Paging	–	–
11	The UE transmit an RRCConnectionRequest message.	–>	RRCConnectionRequest	–	–
12	The SS transmits an RRCConnectionSetup message.	<–	RRCConnectionSetup	–	–
13	The UE transmits an RRCConnectionSetupComplete message. This message includes a SERVICE REQUEST message.	–>	RRCConnectionSetupComplete	–	–
14	The SS transmits a SecurityModeCommand message. MAC-I is calculated in such way, it will result in integrity check failure on UE side.	<–	SecurityModeCommand	–	–
15	Check: Does the UE transmit a SecurityModeFailure message without integrity protection nor ciphering?	–>	SecurityModeFailure	2	P
16	The SS transmits a SecurityModeCommand message to activate AS security with SNOW3G integrity algorithms protected.	<–	SecurityModeCommand	–	–
17	The UE transmits a SecurityModeComplete message. The message related PDCP Data PDU should be integrity protected but not ciphered.	–>	SecurityModeComplete	–	–
18	The SS transmits an UECapabilityEnquiry message to initiate the UE radio access capability transfer procedure. MAC-I is calculated in such way, it will result in integrity check failure on UE side.	<–	UECapabilityEnquiry	–	–
19	Check: Does the UE transmit a RRCConnectionReestablishmentRequest message on Cell 1?	–>	RRCConnectionReestablishmentRequest	3	P
20	The SS transmits a RRCConnectionReestablishment message	<–	RRCConnectionReestablishment	–	–
21	The UE transmits RRCConnectionReestablishmentComplete message.	–>	RRCConnectionReestablishmentComplete	–	–
21A	The SS transmits an RRCConnectionReconfiguration message.	<–	RRCConnectionReconfiguration	–	–
21B	The UE transmits an RRCConnectionReconfigurationComplete message.	–>	RRCConnectionReconfigurationComplete	–	–
22	Check: Does the test result of generic test procedure in TS 36.508 subclause 6.4.2.3 indicate that the UE is in E-UTRA RRC_CONNECTED state on Cell 1?	–	–	–	–

7.3.4.1.3.3 Specific message contents

Table 7.3.4.1.3.3-1: SecurityModeCommand message (steps 5, 14 and 16, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508 Table 4.6.1-19
Information Element		Value/remark	Comment	Condition
SecurityModeCommand ::= SEQUENCE {
rrc-TransactionIdentifier		RRC-TransactionIdentifier-DL
criticalExtensions CHOICE {
c1 CHOICE{
securityModeCommand-r8 SEQUENCE {
securityConfigSMC SEQUENCE {
securityAlgorithmConfig SEQUENCE {
integrityProtAlgorithm		eia1	128-EIA1 SNOW 3G
}
}
}
}
}
}

Table 7.3.4.1.3.3-2: RRCConnectionReestablishmentRequest (step 19, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508, Table 4.6.1-13
Information Element	Value/remark	Comment	Condition
RRCConnectionReestablishmentRequest ::= SEQUENCE {
criticalExtensions CHOICE {
rrcConnectionReestablishmentRequest-r8 SEQUENCE {
ue-Identity SEQUENCE {
c-RNTI	the value of the C-RNTI of the UE
physCellId	PhysicalCellIdentity of Cell 1
shortMAC-I	The same value as the 16 least significant bits of the XMAC-I value calculated by SS
}
reestablishmentCause	otherFailure
}
}
}

Table 7.3.4.1.3.3-3: RRCConnectionReconfiguration (step 21A, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508 table 4.6.1-8, condition SRB2-DRB(1, 0)

7.3.4.2 Integrity protection / Correct functionality of EPS AS integrity algorithms / AES

7.3.4.2.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state }

ensure that {
when { Functionality of EPS AS integrity algorithms with AES is taken into use }

then { UE performs the integrity protection function in PDCP entities associated with SRBs. }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {
when { SecurityModeCommand fails the integrity protection check }

then { UE transmits SecurityModeFailure message and continues using the configuration used prior to the reception of the SecurityModeCommand message }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {
when { UE has AS security activated and integrity check fails }

then { UE initiates RRC connection re-establishment procedure }

}

7.3.4.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clauses 5.7, clause 5.1.2.2, TS 33.401 clause 5.1.4.2 and TS 36.331 clause 6.3.3.

[TS 36.323, clause 5.7]

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

The integrity protection algorithm and key to be used by the PDCP entities are configured by upper layers [3] and the integrity protection method shall be applied as specified in [6].

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the downlink and the uplink, respectively.

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

The parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specification in [6]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (K_RRCint).

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

[TS 36.323, clause 5.1.2.2]

– if integrity verification is not applicable:

– if received PDCP SN < Next_PDCP_RX_SN:

– increment RX_HFN by one;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN > Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– deliver the resulting PDCP SDU to upper layer;

– else, if integrity verification is applicable and the integrity verification fails:

– discard the received PDCP Data PDU;

– indicate the integrity verification failure to upper layer.

[TS 33.401, clause 5.1.4.2]

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

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

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

…

"0010₂" 128-EIA2 AES

…

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 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 and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

[TS 36.331, clause 6.3.3]

The IE SecurityAlgorithmConfig is used to configure AS integrity protection algorithm (SRBs) and AS ciphering algorithm (SRBs and DRBs). For RNs, the IE SecurityAlgorithmConfig is also used to configure AS integrity protection algorithm for DRBs between the RN and the E-UTRAN.

…

SecurityAlgorithmConfig field descriptions
cipheringAlgorithm Indicates the ciphering algorithm to be used for SRBs and DRBs, as specified in TS 33.401 [32, 5.1.3.2].
integrityProtAlgorithm Indicates the integrity protection algorithm to be used for SRBs, as specified in TS 33.401 [32, 5.1.4.2]. For RNs, also indicates the integrity protection algorithm to be used for integrity protection-enabled DRB(s).

7.3.4.2.3 Test description

7.3.4.2.3.1 Pre-test conditions

Same Pre-test conditions as in clause 7.3.4.1.3.1.

7.3.4.2.3.2 Test procedure sequence

Same Test procedure sequence as in table 7.3.4.1.3.2-1, except the integrity protection algorithm is AES.

7.3.4.2.3.3 Specific message contents

Table 7.3.4.2.3.3-1: SecurityModeCommand message (step 5, 14 and 16, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508 Table 4.6.1-19
Information Element		Value/remark	Comment	Condition
SecurityModeCommand ::= SEQUENCE {
rrc-TransactionIdentifier		RRC-TransactionIdentifier-DL
criticalExtensions CHOICE {
c1 CHOICE{
securityModeCommand-r8 SEQUENCE {
securityConfigSMC SEQUENCE {
securityAlgorithmConfig SEQUENCE {
integrityProtAlgorithm		eia2	128-EIA2 AES
}
}
}
}
}
}

Table 7.3.4.2.3.3-2: RRCConnectionReestablishmentRequest (step 19, Table 7.3.4.2.3.2-1)

Derivation Path: 36.508, Table 4.6.1-13
Information Element	Value/remark	Comment	Condition
RRCConnectionReestablishmentRequest ::= SEQUENCE {
criticalExtensions CHOICE {
rrcConnectionReestablishmentRequest-r8 SEQUENCE {
ue-Identity SEQUENCE {
c-RNTI	the value of the C-RNTI of the UE
physCellId	PhysicalCellIdentity of Cell 1
shortMAC-I	The same value as the 16 least significant bits of the XMAC-I value calculated by SS
}
reestablishmentCause	otherFailure
}
}
}

7.3.4.3 Integrity protection / Correct functionality of EPS AS integrity algorithms / ZUC

7.3.4.3.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state }

ensure that {
when { Functionality of EPS AS integrity algorithms with ZUC is taken into use }

then { UE performs the integrity protection function in PDCP entities associated with SRBs. }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {
when { SecurityModeCommand fails the integrity protection check }

then { UE transmits SecurityModeFailure message and continues using the configuration used prior to the reception of the SecurityModeCommand message }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {
when { UE has AS security activated and integrity check fails }

then { UE initiates RRC connection re-establishment procedure }

}

7.3.4.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clause 5.7, clause 5.1.2.2, TS 33.401 clause 5.1.4.2 and TS 36.331 clause 6.3.3

[TS 36.323, clause 5.7]

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

For RNs, the integrity protection function is performed also for PDCP entities associated with DRBs if integrity protection is configured.

The integrity protection algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the integrity protection method shall be applied as specified in [6].

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the downlink and the uplink, respectively.

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

The parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (K_RRCint).

– for RNs, KEY (K_UPint)

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

[TS 36.323, clause 5.1.2.2]

if integrity verification is not applicable:

– if received PDCP SN < Next_PDCP_RX_SN:

– increment RX_HFN by one;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN > Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– deliver the resulting PDCP SDU to upper layer;

– else, if integrity verification is applicable and the integrity verification fails:

– discard the received PDCP Data PDU;

– indicate the integrity verification failure to upper layer

[TS 33.401, clause 5.1.4.2]

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

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

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

…

"0011₂" 128-EIA3 ZUC

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 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 and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

[TS 36.331, clause 6.3.3]

The IE SecurityAlgorithmConfig is used to configure AS integrity protection algorithm (SRBs) and AS ciphering algorithm (SRBs and DRBs). For RNs, the IE SecurityAlgorithmConfig is also used to configure AS integrity protection algorithm for DRBs between the RN and the E-UTRAN.

…

SecurityAlgorithmConfig field descriptions
cipheringAlgorithm Indicates the ciphering algorithm to be used for SRBs and DRBs, as specified in TS 33.401 [32, 5.1.3.2].
integrityProtAlgorithm Indicates the integrity protection algorithm to be used for SRBs, as specified in TS 33.401 [32, 5.1.4.2]. For RNs, also indicates the integrity protection algorithm to be used for integrity protection-enabled DRB(s).

7.3.4.3.3 Test description

7.3.4.3.3.1 Pre-test conditions

Same Pre-test conditions as in clause 7.3.4.1.3.1.

7.3.4.3.3.2 Test procedure sequence

Same Test procedure sequence as in table 7.3.4.1.3.2-1, except the integrity protection algorithm is ZUC.

7.3.4.3.3.3 Specific message contents

Table 7.3.4.3.3.3-1: SecurityModeCommand message (step 5, 14 and 16, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508 Table 4.6.1-19
Information Element		Value/remark	Comment	Condition
SecurityModeCommand ::= SEQUENCE {
rrc-TransactionIdentifier		RRC-TransactionIdentifier-DL
criticalExtensions CHOICE {
c1 CHOICE{
securityModeCommand-r8 SEQUENCE {
securityConfigSMC SEQUENCE {
securityAlgorithmConfig SEQUENCE {
integrityProtAlgorithm		eia3-v11xy	128-EIA3 ZUC
}
}
}
}
}
}

Table 7.3.4.3.3.3-2: RRCConnectionReestablishmentRequest (step 19, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508, Table 4.6.1-13
Information Element	Value/remark	Comment	Condition
RRCConnectionReestablishmentRequest ::= SEQUENCE {
criticalExtensions CHOICE {
rrcConnectionReestablishmentRequest-r8 SEQUENCE {
ue-Identity SEQUENCE {
c-RNTI	the value of the C-RNTI of the UE
physCellId	PhysicalCellIdentity of Cell 1
shortMAC-I	The same value as the 16 least significant bits of the XMAC-I value calculated by SS
}
reestablishmentCause	otherFailure
}
}
}

Table 7.3.4.3.3.3-3: RRCConnectionReconfiguration (step 21A, Table 7.3.4.1.3.2-1)

Derivation Path: 36.508 table 4.6.1-8, condition SRB2-DRB(1, 0)