• Aucun résultat trouvé

AS Signalling and User Data Protection .1 AS Security Mode Command Procedure

Dans le document LTE SECURITY (Page 152-155)

EPS Protection for Signalling and User Data

8.3 AS Signalling and User Data Protection .1 AS Security Mode Command Procedure

The base station indicates the selected algorithms and start of security in the AS Security Mode Command procedure. The base station sends the integrity-protected AS Security Command Message to the UE, which then verifies the MAC. Then, if the code is correct, the UE starts control plane signalling integrity and replay protection and prepares to receive ciphered downlink control and user plane messages. The UE does not start uplink ciphering before it has sent the AS Security Mode Complete message to the base station.

This is different from the NAS Security Mode Complete, which is ciphered to allow the UE to send the device identifier, IMEISV, to the network confidentiality-protected. There is no need to provide confidential data to the network in the AS Security Mode Command message. Also, error handling is easier if the base station can activate uplink ciphering after receiving the AS Security Mode Complete message, as then the AS Security Mode Command procedure is successful. If there have been any errors in the procedure on the UE side, it sends a failure message instead (see [TS36.331] for more details). The AS security mode set-up procedure is described in Figure 8.2.

8.3.2 RRC Signalling and User Plane Protection

The AS-level signalling protocol is called Radio Resource Control (RRC) protocol [TS36.331]. Both the user plane data and the RRC signalling are carried over the Packet Data Convergence Protocol (PDCP) [TS36.323]. Furthermore, the security is implemented on the PDCP layer and not on the RRC layer itself nor on the user plane above PDCP. In this way both the signalling protection and user plane data protection

EPS Protection for Signalling and User Data 139

E-UTRAN UE

AS Security Mode Complete (MAC-I)

AS Security Mode Command (integrity alg., ciphering alg., MAC-I)

AS Security Mode Reject

Figure 8.2 AS Security Mode Command procedure.

can use the same constructs on the PDCP level. This differs from the NAS signalling protection, which is part of the NAS protocol itself. However, note here that on the NAS level no user plane data protection is needed.

For AS-level integrity and replay protection a 128-bit integrity algorithm is used with the following input parameters: a 128-bit key KRRCint, a 32-bit COUNT, a 5-bit BEARER identity and a DIRECTION bit that indicates upstream or downstream. For the case of integrity protection of user plane data on the Un interface between a relay node and a Donor eNB, the key KUPint is used instead of KRRCint while the other input parameters remain the same, cf. Section 7.3.2 and Chapter 14. There can be multiple radio bearers on the AS level – the possible values are described in [TS36.323]. The different bearers may have different service characteristics. The 32-bit COUNT value input parameter cor-responds to the 32-bit PDCP protocol SQN PDCP COUNT. The RRC integrity protection checksum (the MAC-I) is 32 bits long [TS36.323].

The 5-bit BEARER identity is mapped from the RRC bearer identity or, in the case of the Un interface, the data radio bearer (DRB) identity. RRC has three signalling radio bearers (SRBs), two for RRC control messages (SRB0 and SRB1) and one for carrying NAS messages (SRB2). Prior to the establishment of SRB2, NAS messages are sent over SRB1. SRB2 is always protected. Messages are sent over SRB1 unprotected before security activation, and protected thereafter. SRB0 is not protected. RRC can configure multiple DRBs, which are all ciphered but not integrity-protected, except for the case of the Un interface. NAS signalling is also carried over the PDCP protocol between the UE and the base station, so both the AS-level and NAS-level protection is applied after the activation of AS and NAS-level security to the NAS messages. NAS messages that do not have a valid integrity protection checksum on the AS level after the activation of security are not forwarded to the MME.

Every radio bearer has an independent COUNT variable for both uplink and downlink directions. For SRBs and DRBs the same COUNT variable is used as input for ciphering, replay protection and integrity protection. The base station must take care that the same COUNT value is not used twice with a given security key and radio bearer identity to avoid keystream repetition. To avoid this reuse in large data transfer cases, for example the base station can trigger an intracell handover to get fresh keys and thus also fresh keystream.

To reduce the signalling message size, the 32-bit COUNT variable is formed based on the PDCP SQN and an overflow counter called Hyperframe Number (HFN) [TS36.323].

Only the SQN is sent in the messages and the HFN is increased every time the SQN overflows. The length of the SQN can be configured and the length of the HFN is 32 bits minus the length of the SQN (i.e. 5 bits for SRBs and 7 bits with short PDCP SQN or 12 bits with long PDCP SQN for DRBs).

AS-level integrity and replay protection is verified both in the UE and in the base station. If the verification fails, the message is discarded. However, on the UE side a specific recovery procedure is triggered (discussed in this chapter; see also [TS36.331]) to allow coping with context mismatches between the UE and the base station that cause the integrity protection to fail. The procedure used for the recovery is called RRC connection re-establishment. This opens a Denial of Service (DoS) attack possibility for the attacker, as it can send messages to the UE that contain false integrity checksums in order to trigger the (in this case unnecessary) recovery procedure. However, this attack is nonpersistent, and no worse than jamming (refer to the discussion in Section 6.2.1 on when a potential DoS attack requires specific countermeasure). Thus 3GPP gave higher priority to the possibility to recover from this context mismatch deadlock situation.

Similar to NAS signalling, certain RRC messages have to be accepted before the AS security has been activated. But, for example, setting up bearers carrying user plane data never happens before security is activated. Moreover, the UE accepts handover messages only after security has been activated. Replay protection ensures that the receiver accepts messages with a particular incoming PDCP COUNT value only once using the same AS security context.

AS-level ciphering algorithms use the same input parameters as AS-level integrity algo-rithms, except that the ciphering keys KRRCencand KUPencare used instead of the integrity protection key and the keystream LENGTH input parameter is required. LENGTH indi-cates how many keystream blocks need to be generated.

8.3.3 RRC Connection Re-establishment

The RRC connection re-establishment (Figures 8.3 and 8.4) is initiated by the UE when there are multiple physical layer problems, handover failures or possibly integrity check-sum errors. The purpose of this procedure is to recheck-sume the SRB1 operation and to reactivate the security but without changing security algorithms.

The RRC Connection Re-establishment Request message from UE to the base sta-tion includes a security token parameter called shortMAC-I. This is generated by taking

E-UTRAN UE

RRC Connection Reestablishment Request

RRC Connection Reestablishment Complete RRC Connection Reestablishment

Figure 8.3 RRC connection re-establishment success. (Adapted with permission from 2010, 3GPP.)

EPS Protection for Signalling and User Data 141

E-UTRAN UE

RRC Connection Reestablishment Request RRC Connection Reestablishment Reject

Figure 8.4 RRC connection re-establishment reject. (Adapted with permission from 2010, 3GPP.)

the 16 least significant bits of the integrity checksum (i.e. MAC-I) calculated with the RRC integrity protection key used in the source cell in case of handovers or in the cell that triggered the re-establishment procedure. The input bits of COUNT, BEARER and DIRECTION are all set to binary ones. The integrity checksum is calculated over the cell identity of the target cell, the physical cell identity of the cell the UE was connected prior to the failure, and the link layer identity of the UE called Cell Radio Network Temporary Identity (C-RNTI) [TS36.331, TS33.401]. The integrity algorithm used is the same as in the source cell.

The base station sends a RRC Connection Re-establishment message including a Next Hop Chaining Count (NCC) parameter to the UE. The UE uses the NCC to synchronize the current KeNB key and further to derive the signalling and user plane (data) protection keys based on the previously allocated security algorithms. At this point the UE starts integrity and replay protection and ciphering for both sent and received messages.

This procedure requires that the source base station prepared the target cell in the target base station (see Figure 9.5). Both the RRC Connection Re-establishment Request and RRC Connection Re-establishment messages are sent over SRB0 (SRB0), but the RRC Connection Re-establishment Complete message is sent over SRB1 integrity-protected with the same algorithms as in the source cell.

Upon failure of the RRC connection re-establishment procedure, the UE moves to idle state and may come back to connected state. This procedure includes also allocating a new C-RNTI link layer identity. Going to idle state and back to connected state involves NAS-level signalling with the MME and fresh key delivery from the MME to the base station.

8.4 Security on Network Interfaces

Dans le document LTE SECURITY (Page 152-155)