Security Header

The Security Header is a field used in LTE's NAS signaling messages to indicate the type of security protection applied to the message. This field is part of the NAS protocol header and plays a critical role in ensuring the confidentiality and integrity of signaling messages exchanged between the UEand the Core Network (MME/AMF).

• Security Header Type
• What are the Roles of the Security Header Type ?
• What does it mean by the value of each security header type ?
• Security Header Type in Action - LTE

Security Header Type

The Security Header Type in LTE NAS signaling plays a crucial role in identifying the level and type of security protection applied to a specific NAS message. It is an integral part of the Security Header field and helps both the User Equipment (UE) and the Mobility Management Entity (MME) (or AMF in 5G) understand how to process and validate a NAS message.

< 24.301 -  Table 9.3.1: Security header type : LTE>

< 24.501 -  Table 9.3.1: Security header type : NR>

What are the Roles of the Security Header Type ?

Security Header Type acts as a key indicator of the security state applied to NAS messages, specifying whether they are unprotected, protected with integrity only, or both integrity-protected and encrypted. By doing so, the Security Header Type facilitates secure communication, differentiates between message types, supports smooth transitions between security states, and maintains synchronization of the security context. These functions collectively safeguard sensitive signaling information and ensure seamless network operations.

• Indicating the Security State: The Security Header Type informs whether the message is:
• Unprotected (Plaintext)
• Protected with integrity only
• Protected with integrity and encryption
• Ensuring Secure Communication: By specifying the type of security applied, it ensures that sensitive information is either encrypted, integrity-protected, or both, based on the current security context.
• Message Differentiation: It allows the network and UE to differentiate between messages that need further processing (e.g., decryption or integrity verification) and messages that are sent without security for specific reasons (e.g., initial signaling).
• Support for Transition States: It supports transitions between unprotected and protected states, such as during the establishment of the NAS security context. For example:
• Plain NAS messages are used before the security context is set up.
• Protected NAS messages are used after the security context is established.
• Maintaining Context Synchronization: It ensures that both the UE and the network operate on the same security context by signaling whether the current or a new security context applies.

What does it mean by the value of each security header type ?

Followings are the descriptions of each security header type value.

• 0x0: Plain NAS Message (No Security Applied)
• Purpose:
• Used for NAS messages that are not protected by any security mechanisms (neither integrity-protected nor ciphered).
• Examples:
• Initial NAS messages such as Attach Request or Identity Request.
• Reason:
• At this stage, no security context has been established between the UE and the network, so the message must remain plaintext.
• 0x1: Integrity Protected
• Purpose:
• NAS messages are protected using integrity protection to ensure the authenticity of the message and prevent tampering.
• No encryption is applied; the content of the message remains readable.
• Examples:
• Some messages after security mode is established but do not require confidentiality, such as Identity Response or Detach Request.
• Reason:
• Suitable for messages that are not highly sensitive but require protection against tampering.
• 0x2: Integrity Protected and Ciphered
• Purpose:
• Ensures that NAS messages are both integrity-protected (to verify authenticity) and encrypted (to protect confidentiality).
• Examples:
• Attach Complete, Authentication Response, or Bearer Resource Command.
• Reason:
• Used after a security context is established to protect sensitive signaling information.
• 0x3: Integrity Protected and Ciphered with New EPS Security Context
• Purpose:
• Applies integrity protection and encryption to NAS messages, using a newly established EPS (Evolved Packet System) security context.
• Examples:
• NAS messages after a new security context has been activated through Security Mode Command/Complete.
• Reason:
• Indicates that the current message is the first to use the new security context, ensuring a secure transition.
• 0x4: Integrity Protected and Ciphered with New EPS Security Context for Security Mode Command
• Purpose:
• Specific to the Security Mode Command message, which initializes the new EPS security context.
• Integrity protection is applied to confirm the authenticity of the command, but ciphering may also be applied.
• Examples:
• Security Mode Command message.
• Reason:
• Used only during the exchange that establishes a secure context.
• 0x5: Integrity Protected and Ciphered with New EPS Security Context for Security Mode Complete
• Purpose:
• Specific to the Security Mode Complete message, confirming that the UE has successfully applied the new EPS security context.
• Examples:
• Security Mode Complete message.
• Reason:
• Used to ensure that the new security context has been correctly established and agreed upon.
• 0x8: Security Header for Service Request
• Purpose:
• Indicates a Control Plane Service Request message with integrity protection.
• Examples:
• Service Request message during idle-to-connected state transitions.
• Reason:
• Protects the Service Request message to ensure it is legitimate and tamper-proof.

Security Header Type in Action - LTE

Security Header Types in the context of initial attach process in LTE can be illustrated as follows.

For messages such as the Attach Request and Authentication Request/Response, no security is applied initially, and the security header is set to 0x0 (Plain NAS message). During the Security Mode Command procedure, the NAS message is protected with an outer security header (0x3 or 0x4) indicating integrity and optional ciphering with a new EPS security context, while the inner message remains unprotected (0x0).

Similarly, the Security Mode Complete message follows the same format with integrity protection in the outer layer and plaintext in the inner layer. Once security is fully established, subsequent messages like Attach Accept, Attach Complete, and EMM Information are protected with both integrity and ciphering (0x2). This table highlights how LTE manages security in NAS signaling based on the context and the state of the session.

The flow shown above can be represented as a table as shown in the following example.

This table provides an example of the Security Header Type in LTE NAS signaling and how it is used in various message exchanges between the UE (User Equipment) and the Network (NW) during initial attach procedure in LTE.

NOTE : This is based on the log between Amarisoft Callbox and SamSung Galaxy 24

It outlines the direction, type of NAS message, and the corresponding security header applied to those messages.

NOTE : What do you mean by Outer and Inner ?

The term 'Outer', 'Inner' is indicated in the following example

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered) <== Outer

Auth code = 0x6bb083ed

Sequence number = 0x02

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x0 (Plain NAS message, not security protected) <== Inner (Always Plain)

Message type = 0x42 (Attach accept)

EPS attach result = 2 (combined EPS/IMSI attach)

T3412 value:

  Value = 30

  Unit = 1 (1 minute)

TAI list:

  Length = 6

  Data = 00 00 f1 10 00 01

NOTE : Message stucture defined by 24.301

The message structure defined by 24.301 - 9.1 is as follows. Outer and Inner marked as below.

1) if the message is a plain NAS message:

a) protocol discriminator;

b) EPS bearer identity or security header type;

c) procedure transaction identity;

d) message type;

e) other information elements, as required.

2) if the message is a security protected NAS message:

a) protocol discriminator;

b) security header type; <== Outer

c) message authentication code;

d) sequence number;

e) plain NAS message, as defined in item 1. <== Inner

< 24.301 - Figure 9.1.1: General message organization example for a plain NAS message >

< 24.301 - Figure 9.1.2: General message organization example for a security protected NAS message >

Reference :

• 24.301 - LTE;5G;Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);
• 24.501-5G;Non-Access-Stratum (NAS) protocol for 5G System (5GS);