An RRC message travels over the air, and anyone in range can try to change it or replay it. The MAC-I lets the receiver detect that. It is a 32-bit code that the sender computes from the message and a secret key, and the receiver computes it again and compares.

Followings are the topics to be covered in this page.

• MAC-I in the PDCP Data PDU
• Calculating and Verifying the MAC-I
• When the MAC-I is Checked
• Reference

MAC-I in the PDCP Data PDU

Where does the MAC-I sit, and what does it cover? It is not part of the RRC message itself. PDCP appends it to every PDCP Data PDU on an SRB, so RRC never sees the field.

It is a special field added by the Packet Data Convergence Protocol (PDCP) layer to each RRC message for the purpose of integrity protection. The location of MAC-I field (4 bytes) in PDCP Data PDU is shown as follows.

36.323 Figure 6.2.2.1, PDCP Data PDU format for SRBs. Octet 1 carries three R bits and the PDCP SN, the data follows, and the MAC-I takes the last four octets.

The figure shows the whole SRB format. Octet 1 holds three reserved bits and a 5-bit PDCP SN, the RRC message fills the Data field, and the MAC-I fills octets N-3 to N. The MAC-I is always the last 32 bits, so the receiver finds it without any length field.

The integrity protection covers the PDU header and the data part before ciphering (36.323 clause 5.7). Ciphering then covers the data part and the MAC-I (36.323 clause 5.6). So the MAC-I itself travels ciphered, and the receiver deciphers it before the check. DRBs carry no MAC-I in LTE, except for a relay node, where 36.323 allows integrity protection on DRBs as well.

• 32 bits in the last four octets : of every PDCP Data PDU on an SRB.
• Computed over the header and the data : before ciphering.
• Ciphered together with the data : the receiver deciphers first, then checks.

Calculating and Verifying the MAC-I

Both ends must compute exactly the same code from the same inputs. The inputs therefore include values that both sides track separately, such as the COUNT, and a key that never goes over the air.

When a UE transmit a message, the UE computes the value of the MAC-I field and fill in the MAC-I field of PDCP PDU. When  a UE receives a message, it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters (Bearer ID, Direction, AS Key, Message itself etc) . If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

33.401 v19.2.0 clause B.2.1 lists the inputs of the integrity algorithm. The table below gives each input and where PDCP takes its value from.

The COUNT changes with every PDU, so the same RRC message sent twice gives two different MAC-I values. That is also why the receiver keeps replay protection: 33.401 clause 7.4.1 requires it to accept each COUNT value only once with the same AS security context. The DIRECTION bit keeps an uplink PDU from being reflected back as a valid downlink PDU.

The algorithm is one of the EIA set in 33.401 clause 5.1.4.2. 128-EIA1 is based on SNOW 3G, 128-EIA2 on AES in CMAC mode, and 128-EIA3 on ZUC. For 128-EIA2, the CMAC input starts with 64 bits built from COUNT, BEARER, DIRECTION and 26 zero bits, followed by the message. The 32-bit output is the MAC-I.

• Five inputs : KEY, COUNT, BEARER, DIRECTION and MESSAGE.
• COUNT changes per PDU : the same message never gives the same MAC-I twice.
• X-MAC equal to MAC-I : integrity verified.
• 128-EIA1 and 128-EIA2 are mandatory : for RRC in UEs and eNBs, 128-EIA3 is optional.

When the MAC-I is Checked

The MAC-I field is present from the first SRB1 message, but it only carries a real code once AS security is active. This section covers what the field holds before that point, and what happens when a check fails.

For control plane data that are not integrity protected, the MAC-I field is still present and should be padded with padding bits set to 0.

Before the SecurityModeCommand, messages such as RRCConnectionSetupComplete carry this zero MAC-I. The SecurityModeCommand is the first protected message, and it is protected with the algorithm it announces. So the UE first decodes it and then verifies it, as the note in 36.323 clause 5.7 describes. From that point, 36.331 applies integrity protection to all subsequent messages, including the SecurityModeComplete. SRB0 messages go on CCCH without a PDCP header, so they never carry a MAC-I.

EIA0 is a special case. It produces a MAC-I of all zeros, and the receiver does not check it. 33.401 allows EIA0 only for unauthenticated emergency calls, and replay protection stays off with it.

When a check fails on SRB1 or SRB2, PDCP reports an integrity check failure to RRC. 36.331 clause 5.3.7.2 then makes the UE start RRC connection re-establishment. The re-establishment request itself carries a related field, the shortMAC-I. This is the 16 least significant bits of a MAC-I computed over VarShortMAC-Input with the old key, with COUNT, BEARER and DIRECTION all set to ones (36.331 clause 5.3.7.4).

• MAC-I of zeros : before AS security or with EIA0.
• SecurityModeCommand : the first message with a real MAC-I.
• Integrity check failure on SRB1 or SRB2 : triggers RRC connection re-establishment.
• shortMAC-I : 16 bits of a MAC-I, used to identify the UE at re-establishment.

Reference

Refer to the following specification for further details :

i) 36.323 - 5.7 Integrity Protection and Verification

ii) 36.323 - 6.3.4 MAC-I

iii) 33.401 - 3GPP System Architecture Evolution (SAE); Security architecture

[1] 3GPP TS 36.323 v19.0.0 - clause 5.7, Integrity Protection and Verification, and clause 6.3.4, MAC-I

[2] 3GPP TS 33.401 v19.2.0 - clause 5.1.4.2, Algorithm Identifier Values, clause 7.4.1, RRC integrity mechanisms, and clause B.2, 128-bit integrity algorithm

[3] 3GPP TS 36.331 v19.3.0 - clause 5.3.4, Initial security activation, and clause 5.3.7, RRC connection re-establishment