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 Dynamics : Blank Start vs Stored Security Context

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.

NOTE : This diagram is based on the assumption that UE does not have any pre-stored security context (e.g, this is what would happened when you power on the UE right after the purchase). This is based on the this log from Amarisoft Callbox and Amarisoft UEsim.

NOTE : If UE has any pre-stored security context, it may try with Security Protected header from the beginning (i.e, Attach Request) as you can see in this log from Amarisoft Callbox and a commercial UE.

NOTE : How to force UE to do 'blank initiation' is up to UE implmentation. I see some UE tries blank start after power-off / power on, but some UE tend to use the stored security context even after the power cycle.

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 >

Security Header Dynamics : Blank Start vs Stored Security Context

The differences in the Security Header between the first Attach (e.g., after powering on a device for the first time after purchase) and a subsequent Attach (e.g., after a radio on-off cycle) stem from the security context establishment and reuse.

Main difference between these two states in terms of Security Process are :

• During the first Attach, no prior security context exists, so the UE and network must establish one via the Authentication and Key Agreement (AKA) procedure.
• In subsequent Attaches, an existing security context may be reused if it’s still valid, affecting how security headers are applied.

Blank Start 

This refers to the case where UE does not have any valid security context stored in it. This happens when you power on the UE for the first time after the purchase. Or after replacing UEsim.

Context

• The UE has no prior security context with the network because it’s the first time it’s connecting.
• The USIM (Universal Subscriber Identity Module) contains the permanent key (K), but no derived keys (e.g., K_ASME in LTE or K_AMF in 5G) or security context exist yet.

Procedure and Security Header

• Attach Request (UE → Network):
• Security Header Type: 0000 (Plain NAS message).
• Reason: No security context exists yet, so the initial Attach Request is sent unprotected. It includes the IMSI (or GUTI if somehow available) and other parameters.
• Integrity/Ciphering: None applied.
• Authentication (Network ↔ UE):
• After receiving the Attach Request, the network (HSS/HLR in LTE or AUSF/UDM in 5G) triggers the AKA procedure.
• Authentication vectors are exchanged, and the UE and network derive session keys (e.g., K_ASME or K_AMF).
• These messages are typically at the lower layer (e.g., RRC) or unprotected NAS until security is established.
• Security Mode Command (Network → UE):
• Security Header Type: 0011 (Integrity-protected with new security context).
• Reason: The network sends this to activate NAS security, specifying the algorithms for integrity (e.g., EIA1) and ciphering (e.g., EEA1). It’s integrity-protected using the newly derived keys but not yet ciphered.
• Integrity: Yes (first use of integrity protection).
• Ciphering: No (not yet activated).
• Security Mode Complete (UE → Network):
• Security Header Type: 0010 (Integrity-protected and ciphered).
• Reason: The UE confirms security activation, and from this point, both integrity and ciphering are applied using the agreed algorithms.
• Integrity: Yes.
• Ciphering: Yes.
• Attach Accept (Network → UE):
• Security Header Type: 0010 (Integrity-protected and ciphered).
• Reason: With security fully established, the network sends the Attach Accept, which is both integrity-protected and ciphered.
• Integrity: Yes.
• Ciphering: Yes.

Context Reuse

This is the cases where UE has some stored Security context from previous attach. This usually happens when you airplane mode on / off in not too long interval.

Context

• The UE has previously attached to the network and established a security context.
• After a radio off-on cycle (e.g., toggling airplane mode or rebooting), the UE may retain a stored security context (e.g., K_ASME, NAS keys, and GUTI) if it hasn’t expired or been deleted.
• The network (MME/AMF) may also retain this context, depending on its policies and the time elapsed.

Procedure and Security Header

• Attach Request (UE → Network):
• Security Header Type: 0000 (Plain NAS message) or 0010 (Integrity-protected and ciphered), depending on context reuse.
• Scenario 1: No Context Reuse:
• If the security context is no longer valid (e.g., expired, deleted, or network doesn’t recognize the GUTI), the Attach Request is sent as plain (0000), similar to the first Attach.
• The process then mirrors the first Attach: AKA, Security Mode Command, etc.
• Scenario 2: Context Reuse:
• If the UE and network still share a valid security context (e.g., GUTI and NAS keys are intact), the Attach Request can be sent as 0010 (integrity-protected and ciphered) using the existing keys.
• Integrity: Yes.
• Ciphering: Yes.
• Reason: The UE uses the stored NAS security context to protect the message, avoiding the need for full re-authentication.
• Authentication (Optional):
• If the network accepts the reused context, authentication may be skipped.
• If the context is invalid or the network requires fresh authentication (e.g., for security policy), AKA is performed, and the Security Mode Command sequence follows (0011 → 0010).
• Attach Accept (Network → UE):
• Security Header Type: 0010 (Integrity-protected and ciphered).
• Reason: Whether reusing an old context or establishing a new one, the Attach Accept is sent with full security once the context is confirmed or re-established.
• Integrity: Yes.
• Ciphering: Yes.

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);