NAS Integrity is a mechanism that can let you (UE or Network) know if a NAS message is modified or corrupted in some way (See Confidentiality and Integrity pagefor the details of the concept of Integrity).

The NAS Integrity Algorithm is a vital mechanism within LTE networks designed to ensure the integrity of NAS  messages exchanged between the UE and the network. This mechanism enables both the UE and the network to detect if a NAS message has been tampered with, modified, or corrupted during transmission. By implementing integrity protection, the NAS Integrity Algorithm provides a cryptographic safeguard that verifies the authenticity and reliability of signaling messages. Through the use of cryptographic algorithms such as EIA (EPS Integrity Algorithms), the system computes a Message Authentication Code (MAC) that is appended to the message before it is transmitted. When the message is received, the MAC is recalculated and compared to ensure the message has not been altered. This process not only protects the communication from malicious attacks but also ensures the system's robustness and security, playing a critical role in maintaining trust and reliability in LTE communications.

• Overall Key Flows
• What does NAS Integrity Algorithm do ?
• How MAC is integrated into PDCP ?
• Key Generation Details
• Decoding the Example Message
• Reference :

Overall Key Flows

Where does the key for NAS integrity come from? It is never sent over the air. The UE and the network each derive it from the same root key K, through the key hierarchy of 33.401 Figure 6.2-1. The diagrams below follow that chain down to the integrity algorithm.

Overall flow from Key Generations and final output for NAS Integrity can be illustrated as follows : The key points of this diagrams are

• The hierarchical derivation of keys used in LTE for NAS integrity protection.
• How a NAS message is securely protected using these keys, ensuring its authenticity and preventing tampering or replay attacks.

The key hierarchy of 33.401 Figure 6.2-1 on top of the EIA block of Figure B.2-1. The same EIA output is called MAC-I in PDCP and NAS-MAC in a NAS message. The red path is the NAS one: K_NASint produces the message authentication code 205A8923 of the NAS message at the bottom.

Followings are breakdown of the illustration and brief descriptions of each step.

Key Derivation Process:

The first three levels of the hierarchy sit in the USIM, the HSS and the MME. The NAS keys come from K_ASME, so the eNB never holds them.

• The root key K is stored in the USIM/AuC (Authentication Center).
• Using the CK (Ciphering Key) and IK (Integrity Key) derived during the authentication process, the HSS (Home Subscriber Server) generates the intermediate key K_ASME.
• The MME (Mobility Management Entity) derives two keys from K_ASME:
• K_NASenc: Used for NAS message encryption.
• K_NASint: Used for NAS message integrity protection.

eNB (eNodeB) Key Derivation:

The AS keys form a separate branch under K_eNB. They protect RRC signalling and user data between the UE and the eNB, and they play no part in NAS integrity.

• Upon initial attach or service request, the MME provides the eNB with K_eNB. At handover, the target eNB gets K_eNB* from the source eNB, or NH from the MME.
• From K_eNB, the eNB derives the following keys:
• K_UPenc: For user plane encryption.
• K_RRCenc: For RRC (Radio Resource Control) encryption.
• K_RRCint: For RRC integrity protection.

Integrity Protection:

K_NASint is specifically used in this diagram to protect the integrity of NAS signaling messages. A cryptographic algorithm (EIA - EPS Integrity Algorithm) ensures that the NAS message is not tampered with during transmission by calculating a Message Authentication Code (MAC).

• Protected NAS Message Format:
• The NAS message is encapsulated in a security header.
• Fields include:
• Protocol Discriminator: Identifies the type of NAS message.
• Sequence Number: Helps maintain synchronization and detect replay attacks.
• MAC (Message Authentication Code): Calculated using K_NASint, the sequence number, and the NAS message.
• Message Authentication Code (MAC):
• The sender computes the MAC using the key K_NASint, along with message-specific inputs such as COUNT (NAS overflow and sequence number), DIRECTION, message contents, and bearer information.
• This MAC ensures the integrity of the NAS message.
• Receiver Validation:
• The receiver calculates its own MAC using the same algorithm and key.
• It compares the computed MAC with the received MAC to verify the message’s integrity.
• If the MACs match, the message is accepted; otherwise, it is discarded as corrupted or tampered with.

The steps above give the full path from the root key K to a protected NAS message. The next section looks at the last step alone: which values go into the algorithm, and where its output goes.

What does NAS Integrity Algorithm do ?

Simply put, NAS Integrity (in LTE) is to calculate the Message Authentication Code (MAC, shown in Red) using various inputs (shown in Blue and Green) and to fill the MAC field of the security protected NAS message as illustrated below.

The sequence number 0 and the NAS message 075D010002F070C1 go into the algorithm, and its output 205A8923 fills the message authentication code field of the same message.

The NAS Integrity Algorithm ensures the integrity of NAS (Non-Access Stratum) messages by:

• Calculating a Message Authentication Code (MAC).
• Using specific inputs (marked in green and violet) to verify that the NAS message has not been tampered with during transmission.

Followings are breakdown of the diagram above

• Inputs to the NAS Integrity Algorithm
• Sequence Number (Violet):
• Ensures that each NAS message is unique and can be correctly identified.
• Prevents replay attacks by maintaining message order.
• NAS Message (Green):
• The actual data or signaling message being sent, e.g., an attach request or authentication response.
• Additional Inputs (Violet):
• Includes other critical parameters like:
• COUNT: 0x00 || NAS OVERFLOW || NAS SQN (33.401 clause 8.1.1). The direction is a separate input, not part of COUNT.
• Bearer: Always the constant 0 for NAS (33.401 clause 8.1.1).
• Direction: Differentiates between uplink (UE to network) and downlink (network to UE).
• Calculation Process
• NAS Integrity Algorithm:
• Takes the sequence number, NAS message, and additional inputs.
• Processes them using the selected EPS Integrity Algorithm (EIA), such as EIA1 (based on SNOW 3G) or EIA2 (based on AES).
• Generates the Message Authentication Code (MAC) as the output.
• Message Authentication Code (Red):
• The MAC (e.g., 205A8923) is carried in the security header, ahead of the sequence number and the NAS message.
• It serves as a cryptographic fingerprint for the message.
• Purpose of the MAC
• The MAC allows the receiver to:
• Verify the authenticity and integrity of the NAS message.
• Ensure the message has not been altered or tampered with during transmission.
• Discard the message if the computed MAC does not match the received MAC.

How MAC is integrated into PDCP ?

The PDCP PDU (Protocol Data Unit) is a key component in LTE communication, responsible for carrying data such as NAS messages, user data, or control plane signaling, and it includes the PDCP Sequence Number (PDCP SN) to maintain order and synchronization. Integrity protection in the PDCP PDU ensures that the transmitted data remains authentic and free from tampering. This is achieved through the use of a cryptographic code known as MAC-I (Message Authentication Code - Integrity), which is calculated by the same EIA algorithm as the NAS MAC. It uses the RRC integrity key K_RRCint and the PDCP COUNT instead of K_NASint and the NAS COUNT. MAC-I serves as a safeguard to verify the integrity of the PDCP PDU, ensuring that it has not been altered during transmission. Once computed, the MAC-I is appended to the PDCP PDU, allowing the receiver to validate the authenticity of the message upon reception.

The red arrow draws the NAS algorithm output into the PDCP MAC-I field. In the specifications the two are separate: 205A8923 stays in the NAS message, and PDCP computes its own MAC-I over the whole PDCP PDU with K_RRCint.

A protected NAS message carries two MACs on its way to the UE, one inside the other. The NAS-MAC travels inside the NAS message, in the security header at the bottom of the diagram. The NAS message then rides as dedicatedInfoNAS inside an RRC message such as DLInformationTransfer. PDCP adds its own MAC-I over that RRC PDU, calculated with K_RRCint and the PDCP COUNT (33.401 clause 7.4.1 and 36.323 clause 5.7).

The two MACs are not always active at the same time. During attach, the NAS security mode procedure runs before the AS security mode procedure. At that point the PDCP MAC-I of the SRB is still present but padded with zeros (36.323 clause 6.3.4), while the NAS message already carries a real NAS-MAC such as 205A8923.

This is breakdown of the diagram shown above :

• Input Preparation:
• The NAS message (075D010002F070C1 in this example) and additional inputs (e.g., sequence number, COUNT, bearer ID) are fed into the NAS Integrity Algorithm.
• The sequence number ( 0 in this example).
• MAC-I Calculation:
• The NAS Integrity Algorithm processes these inputs and computes the NAS-MAC value (205A8923 in this case), which fills the message authentication code field of the NAS message.
• This value serves as the integrity check code.
• Integration into PDCP PDU:
• The PDCP MAC-I is a separate 32-bit field at the end of each PDCP PDU of an SRB, calculated by PDCP with K_RRCint over the PDCP header and data.
• The four MAC-I rows in the diagram are the four octets of that single 32-bit field, not parts spread over several PDUs.
• Transmission:
• The integrity-protected PDCP PDU, now containing the MAC-I, is sent to the receiver.
• Verification at Receiver:
• The receiver calculates the MAC-I using the same algorithm and inputs.
• It compares the calculated MAC-I with the received MAC-I to verify the integrity of the message.
• If the MAC-I matches, the message is considered authentic; otherwise, it is discarded as tampered or corrupted.

• NAS-MAC : calculated with K_NASint and the NAS COUNT, carried in the NAS security header.
• PDCP MAC-I : calculated with K_RRCint and the PDCP COUNT, carried at the end of the PDCP PDU.
• Before AS security starts : the PDCP MAC-I is all zeros while the NAS-MAC is already real.

Key Generation Details

What exactly goes into the integrity algorithm? 33.401 Annex B defines one EIA interface for NAS, RRC and user plane alike. Only the values fed into it change from one layer to the next.

The NAS Integrity Algorithm used in LTE is called EIA(EPS Integrity Algorithm). High level functionality of EIA can be illustrated as below.

This section explains the key generation process for the NAS Integrity Algorithm (EIA) used in LTE, highlighting how integrity protection for NAS messages is achieved. It provides a detailed view of how the required inputs, such as the sequence number, direction, bearer, and message, contribute to generating the Message Authentication Code (MAC).

It highlights the systematic approach to generating and verifying message integrity in LTE using the NAS Integrity Algorithm. By utilizing the COUNT, Direction, Bearer, and Message as inputs, along with a cryptographic key, the system ensures that messages are secure and have not been tampered with during transmission. This process is vital for maintaining the integrity and security of NAS signaling in LTE networks.

33.401 Figure B.2-1 with the NAS values filled in. COUNT is 0x00 || NAS OVERFLOW || NAS SQN, DIRECTION is 1 bit and BEARER is 5 bits. The MESSAGE input covers the sequence number and the NAS message, and EIA is one of EIA0 to EIA3.

As shown above, there are several different EIA that can be used for LTE and you need to go through a lot of other documents to understand the details of these algorithm.  For EIA1 as an example, refer to SNOW3G page.

Key Components in the Process

Each input has a fixed size and a fixed source. For NAS, 33.401 clause 8.1.1 builds COUNT from two counters and fixes BEARER to 0, as the diagram above shows.

• NAS Sequence Number (NAS SQN):
• The NAS SQN is an 8-bit sequence number included in each NAS message to ensure unique identification of messages and prevent replay attacks.
• When the NAS SQN reaches its maximum value, an additional NAS Overflow counter (16 bits) is incremented to maintain continuity.
• Together, the NAS Overflow and the NAS SQN form the COUNT, a 32-bit value used in the integrity algorithm.
• COUNT:
• The COUNT value is constructed by combining:
• NAS Overflow (16 bits).
• NAS SQN (8 bits).
• Spare bits or padding to make it a 32-bit field.
• This COUNT serves as a unique identifier for the message.
• Direction:
• Indicates whether the message is uplink (0) or downlink (1).
• This ensures that the algorithm can differentiate between messages sent by the UE and those sent by the network.
• Bearer:
• A 5-bit field. For NAS it is the constant value 0 (33.401 clause 8.1.1), because there is only one NAS signalling connection between the UE and the MME.
• 33.401 keeps it only so that the NAS and AS algorithms take inputs of the same form.
• Message:
• The actual NAS message being transmitted, including its content, protocol discriminator, and other signaling information.
• 24.301 clause 4.4.3.3 makes it octets 6 to n of the protected message, so the sequence number is covered as well as the NAS message.

EIA (EPS Integrity Algorithm)

The same function runs at both ends. The receiver repeats the calculation with its own copy of the inputs, so a single changed bit in the message or a stale COUNT gives a different result.

• At the Sender:
• Inputs (COUNT, Direction, Bearer, and Message) are processed by the NAS Integrity Algorithm, which uses a cryptographic key to generate the MAC. 33.401 calls it MAC-I in RRC and user plane, and NAS-MAC in NAS.
• For NAS, the NAS-MAC is placed in the security header of the message, ahead of the sequence number.
• At the Receiver:
• The receiver computes a new MAC (XMAC) using the same algorithm and inputs (including COUNT, Direction, Bearer, and the received message).
• The calculated XMAC is compared with the received MAC to verify the message's integrity.
• If the MACs match, the message is considered authentic; otherwise, it is discarded as corrupted or tampered with.

Decoding the Example Message

Which message does the example on this page protect? The capture shows only the hex string 075D010002F070C1. Decoded against 24.301 v20.0.0, it turns out to be the downlink SECURITY MODE COMMAND that starts NAS security. The table below lists every octet of the protected message.

The decode explains the other values of the example. The MME resets the downlink NAS COUNT for the initial SECURITY MODE COMMAND, so the sequence number is 0 (24.301 clause 5.4.3.2). The MME also sends this message unciphered, which is why the security header type is integrity protected only. The selected algorithms octet shows that 128-EIA1, the SNOW 3G algorithm, produced 205A8923.

To recompute 205A8923, the inputs would be K_NASint as KEY, COUNT = 0x00000000, BEARER = 0 and DIRECTION = 1, because the message goes downlink. The MESSAGE input is octets 6 to 14, the sequence number 00 followed by 075D010002F070C1. The key itself comes from the authentication run before this message, so the capture alone does not allow a check.

• 075D010002F070C1 : a downlink SECURITY MODE COMMAND.
• Sequence number 0 : the downlink NAS COUNT is reset for this message.
• 205A8923 : the 128-EIA1 output over octets 6 to 14.

Reference :

• CryptoMobile (GitHub)
• 3GPP confidentiality and integrity algorithms
• LTE Security I: Concept and Authentication
• 3GPP TS 33.401 v19.2.0 - clause 6.2 key hierarchy, clause 8.1.1 NAS input parameters, Annex B.2 integrity algorithms
• 3GPP TS 24.301 v20.0.0 - clause 4.4.3 NAS COUNT and integrity protection, clause 9.3.1 security header type
• 3GPP TS 36.323 v19.0.0 - clause 5.7 integrity protection, clause 6.3.4 MAC-I
• Overview of ZUC Algorithm and its Contributions on the Security Success and Vulnerabilities of 4G Mobile Communication