Integrity protection answers one question. Did this message arrive the way it was sent, and did it come from the node that claims to have sent it? Encryption answers a different one, and the two are configured separately in LTE.

The answer is a short code attached to each message. Both ends compute it from the same inputs, and the receiver compares its own result with the one that arrived. Everything on this page is either about where those inputs come from, or about what happens to the code afterwards.

• Integrity Protection Process
• The Key Hierarchy
• Computing the MAC
• Where the MAC Travels
• Reference

Integrity Protection Process

My perception of any process is "a black box that convert a set of inputs into a set of output". So for any process, I usually tries to define what is the inputs and out is the final outputs.. and then try to find the all of the steps one by one to convert the input into the outputs.

If I define LTE Integrity Protection Procedure with this logic, it would be "a process that convert 'K' value from USIM into PDCP MAC-I and NAS MAC(Message Authentication Code)". Describing this process with illustration would be as follows. Just try to go through this illustration whenever you have chance and try to have your own idea first.

The process described here apply only to C-Plane data. (Refer to 33.401 for the detailed description of each of the steps).

Four pictures in one. The key hierarchy at the top feeds the two EIA blocks in the middle, and the two corners at the bottom show where the result ends up.

• The top box is the key hierarchy, with four rows down the left naming who holds what: USIM / AuC, UE / HSS, UE / MME and UE / eNB. K sits at the top and the arrows below it are derivations.
• The middle pair is the integrity algorithm drawn twice. The left block is labelled Sender and outputs MAC-I/NAS-MAC, and the right block is labelled Receiver and outputs XMAC-I/XNAS-MAC.
• A vertical dotted line runs between the two blocks. That line is the air interface, and nothing crosses it except the message and the code.
• The blue dashed route carries a key down to the sender’s KEY input, and the green dashed route carries one to the receiver’s. Both start at integrity keys in the hierarchy above.
• The lower left corner is a PDCP PDU with MAC-I at the end of it. The lower right is a decoded NAS message with its Message authentication code highlighted. Those are the two places the code is actually carried.

• The drawing is a pipeline, not a block diagram : it runs from a key on the USIM down to a field on the air. Every stage in between is a derivation or a computation.
• Both ends compute, and only one end sends : the two EIA blocks are the same algorithm, and the X in XMAC-I stands for expected.
• The code is appended, never mixed in : the MAC sits beside the message rather than inside it, so the receiver can recompute over the same bytes.

The Key Hierarchy

Integrity protection needs a key, and it is not the one on the USIM. The top of the drawing above is a derivation chain, and every arrow in it runs one way only. What comes out at the bottom is a set of keys with one job each.

K is the permanent key. It lives in the USIM and in the AuC, and it never travels. CK and IK are derived from it, K_ASME is derived from those, and the MME derives K_NASenc, K_NASint and K_eNB from K_ASME. The eNB then derives four more from K_eNB / NH.

The four labels down the left edge are the point of drawing it this way. Each row names the two places that hold the key on that row. The pairing changes as the chain descends: USIM and AuC at the top, then UE and HSS, then UE and MME, then UE and eNB. A key is derived independently at both ends and never sent between them.

36.331 and 33.401 name seven keys below K_ASME, and only three of them protect integrity. K_NASint protects NAS signalling and is derived by the ME and the MME. K_RRCint protects RRC signalling and is derived by the ME and the eNB. K_UPint protects user plane traffic.

K_UPint is the one drawn with a dashed border, and that is worth reading as a statement. 33.401 says NAS and RRC signalling shall be integrity protected, while user plane packets between the eNB and the UE may be. The paragraph introducing the drawing says the process applies only to C-Plane data, and the dashed box is the same statement drawn rather than written.

• Nothing on the chain is ever transmitted : both ends run the same derivation from a key they already share, which is why the row labels name two holders each.
• Three keys of the seven are integrity keys : K_NASint, K_RRCint and K_UPint, and the other four are for ciphering.
• Separate keys mean separate scope : a compromised K_RRCint says nothing about NAS, because the two descend from K_ASME by different derivations.
• The dashed box is the C-plane restriction : K_UPint exists in the hierarchy but sits outside what this page covers.

Computing the MAC

The two blocks in the middle of the drawing are the same block twice. One sits at each end of the air interface, and the reason there are two is that nobody trusts a code they did not compute themselves. The receiver repeats the sender’s work and compares.

33.401 v19.2.0 (Release 19) Annex B.2.1 lists what goes in. The inputs are a 128 bit integrity key called KEY, a 32 bit COUNT, a 5 bit bearer identity called BEARER, a 1 bit DIRECTION, and the MESSAGE itself. DIRECTION is 0 for uplink and 1 for downlink.

Four of those five are in the drawing above the EIA box, and KEY arrives from the left. The output at the bottom is a 32 bit message authentication code, written MAC-I/NAS-MAC because the name depends on which protocol is being protected. 36.323 calls it MAC-I and 24.301 calls it MAC.

The three small inputs are what stop a replay. The same message sent twice has a different COUNT each time, so it produces a different code. A message replayed in the other direction has a different DIRECTION bit, and one replayed on another radio bearer has a different BEARER. None of the three is secret, and none of them needs to be.

The receiver computes XMAC-I/XNAS-MAC from the message it actually got, using its own copy of the key, and compares. A single flipped bit anywhere in MESSAGE changes the result, so the comparison either matches exactly or fails. There is no partial answer.

EIA is a family rather than one algorithm. 33.401 assigns each member a 4 bit identifier: EIA0 is null integrity protection, 128-EIA1 is based on SNOW 3G, 128-EIA2 on AES and 128-EIA3 on ZUC. UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling and may implement 128-EIA3, and the same pattern holds between UEs and MMEs for NAS.

• Five inputs, one of them secret : KEY is the only one an attacker cannot see. The other four make the code specific to this message at this moment.
• The output is 32 bits whatever the message length : the code does not grow with the message, so the overhead is fixed.
• XMAC-I is computed, not received : the X stands for expected, and the receiver builds it from the message in front of it.
• EIA0 is a real code point : it is null integrity protection, and 33.401 allows it only for unauthenticated emergency calls.

Where the MAC Travels

A code is no use if nobody can find it, so the last question is where the 32 bits actually sit. The two corners at the bottom of the drawing answer it twice, because RRC and NAS carry the code in different places.

The lower left corner is a PDCP PDU. The first octet holds three R bits and the PDCP SN, the Data follows, and then four more rows are labelled MAC-I, MAC-I (cont.), MAC-I (cont.) and MAC-I (cont.). Four octets is 32 bits, which is the length Annex B.2.1 gives.

The lower right corner is a decoded NAS message rather than a format drawing, and its values come from one capture. Security header type reads Integrity protected, Protocol discriminator reads 7, Sequence number reads 5, and the highlighted Message authentication code reads 7709702D. That is eight hex digits, so 32 bits again.

Reading the two corners together settles one thing about the format. The code always follows the data it protects rather than sitting inside it. A receiver can therefore strip the last four octets, run EIA over what is left, and compare, without needing to know anything about the message content.

The NAS capture also shows why the sequence number is in the picture at all. It reads 5 here, and it is one of the inputs that feeds COUNT. Two identical NAS messages sent at different sequence numbers therefore carry different authentication codes, which is the replay protection described in the section above.

• Four octets, both times : the PDCP drawing spends four rows on MAC-I and the NAS capture shows eight hex digits, and both are the 32 bits the specification fixes.
• The code trails the message : it is appended in both carriers, so verification never has to parse the message to find it.
• The NAS values are a capture : 7709702D and the sequence number 5 come from one recorded message, and they are not defaults to compare a live trace against.
• Header type is the switch to look at first : Security header type reading Integrity protected is what says the code in this message means anything.

Reference

• TS 33.401 v19.2.0 (Release 19) - 3GPP System Architecture Evolution (SAE); Security architecture. Clause 6.2 for the key hierarchy, clause 5.1.4 for the EIA identifiers, and Annex B.2.1 for the algorithm inputs and the 32 bit output.
• TS 36.323 - E-UTRA Packet Data Convergence Protocol (PDCP) specification, which defines the PDU format carrying MAC-I and the bearer identity used as BEARER.
• TS 24.301 - Non-Access-Stratum (NAS) protocol for EPS, which defines the security protected NAS message header and calls the code MAC.