Description
The Integrity Key (IK) is a fundamental security element within the 3GPP authentication and key agreement (AKA) framework. It is a 128-bit cryptographic key derived, alongside the Ciphering Key (CK), from the long-term secret key (K) shared between the Universal Subscriber Identity Module (USIM) and the Authentication Centre (AuC) in the home network. The derivation occurs during the AKA procedure, which can be the UMTS AKA, EPS AKA, or 5G AKA. The IK is specifically generated to provide integrity protection for signaling messages exchanged between the User Equipment (UE) and the network, and in some cases, for user plane data.
The IK is used as an input to integrity algorithms (e.g., UIA algorithms in UMTS, EIA algorithms in LTE, NIA algorithms in 5G NR). These algorithms, such as 128-EIA1 (SNOW 3G), 128-EIA2 (AES), and 128-EIA3 (ZUC), generate a Message Authentication Code (MAC) for each integrity-protected protocol data unit (PDU). The receiving entity (UE or network node) recalculates the MAC using the same IK and algorithm. If the calculated MAC matches the received MAC, the message's integrity and authenticity are verified, confirming it has not been altered in transit and originated from the legitimate peer. The IK is typically stored in the UE's non-volatile memory and in the relevant network nodes (e.g., MME in LTE, AMF in 5GC) for the duration of a security context.
In the overall security architecture, the IK works in tandem with the CK. While the CK is used for confidentiality (encryption), the IK is dedicated to integrity and data origin authentication. The separation of duties between CK and IK is a key security principle, limiting the impact of a potential compromise of one key. The IK is also used in the derivation of further keys within the key hierarchy, such as the Kenb in LTE or the KgNB in 5G, which are used for integrity protection on subsequent network interfaces (e.g., between eNB and UE). The strength of the integrity protection directly depends on the secrecy of the IK and the cryptographic robustness of the selected integrity algorithm.
Purpose & Motivation
The Integrity Key exists to address critical security threats in wireless communication, specifically message modification, injection, and replay attacks. Without integrity protection, an attacker could alter signaling messages (e.g., handover commands, session management messages) to disrupt service, redirect traffic, or impersonate the network or user. Prior to the standardized use of IK in 3GPP systems (from GSM onwards), security mechanisms were weaker; GSM, for example, provided only optional and weaker encryption for confidentiality and had no standardized integrity protection for signaling, making it vulnerable to certain active attacks.
The creation of the IK was motivated by the need for a stronger, mandatory security framework for 3G (UMTS) and beyond. The 3GPP security group designed a new, robust AKA protocol that explicitly separated integrity and confidentiality functions. This was a direct response to the limitations of GSM security and the evolving threat landscape. The IK provides assurance that critical control-plane signaling has not been tampered with, which is foundational for network access control, mobility management, and session management. Its derivation from a long-term secret via a secure one-way function ensures it is fresh for each session and cryptographically tied to the subscriber's identity, solving the problem of ensuring message authenticity in an untrusted radio environment.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (30 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-2, normative work from Rel-15.
In Release 15, the Integrity Key (IK) function was enhanced to support User Plane Integrity Protection for EDT (Early Data Transmission). Furthermore, updates to USIM management procedures for 5GS were introduced, aligning with the requirement that the IK, used with the 3GPP Integrity Algorithm, is stored on the USIM and set by the authentication procedure.
- Introduce an EF that contains keys generated by ME from CK and IK. TS 31.102CR0774
- USIM Service Table update for PDU session call control support TS 31.102CR0786
- Allow configuration of MCS (Access Identity 2) via USIM. TS 31.102CR0794
- Mission Critical Services configuration data update to USIM TS 31.102CR0808
- Enhance USIM OPL configuration to support 3 bytes TAC when in NG-RAN. TS 31.102CR0818
- Updates to USIM management procedures for 5GS TS 31.102CR0806
+ 2 more changes
In Release 16, the specification for the Integrity Key (IK) function itself was not changed, as the IK's role in the integrity algorithm and its storage on the USIM remained as defined. The release instead introduced new USIM configuration and storage capabilities, such as lists for URSP, RLOS PLMN, Trusted non-3GPP networks, and a separate KSEAF for non-3GPP access. These additions expanded the USIM's role in managing network access policies and security parameters beyond the core authentication and IK procedures.
- Support for USIM configuration of RLOS PLMN list TS 31.102CR0847
- URSP storage in USIM TS 31.102CR0861
- Specify storage for a potentially separate KSEAF for non-3gpp access on the USIM TS 31.102CR0864
- USIM configuration of RLOS allowed MCC list TS 31.102CR0881
- Support for Trusted non-3GPP access networks list by USIM TS 31.102CR0891
- Dedicated AID for USIM Applications with non-IMSI based SUPI Types TS 31.102CR0897
+ 3 more changes
In Release 17, the primary update related to the Integrity Key (IK) function was the specification of a mapping procedure from EPS integrity algorithms to NR integrity algorithms for User Plane integrity protection (UP IP). This enhancement, as indicated by the CR title "UP IP: mapping of EPS integrity algorithm to NR integrity algorithm," provided a defined method for deriving the appropriate NR algorithm when EPS security contexts are used, ensuring continuity and integrity of user plane data. The IK itself, as established in earlier releases, continues to be stored on the USIM and is set by the authentication procedure.
- Introduce a USIM file to store pre-configured CAG information list TS 31.102CR0904
- SOR-CMCI storage in USIM TS 31.102CR0917
- Addition of USIM files for the indication of whether disaster roaming is enabled in the UE, disaster roaming wait range, disaster return wait range and applicability indicator for disaster roaming PLMNs list provided by VPLMN. TS 31.102CR0938
- Adding eDRX parameters in the USIM for NG-RAN TS 31.102CR0943
- 5G NSWO (Non-Seamless WLAN Offload) configuration support in the USIM compromised proposal. TS 31.102CR0946
- Support of 'No E-UTRA Disabling In 5GS' in USIM TS 31.102CR0947
+ 3 more changes
In Release 18, the IK (Integrity Key) function itself was not directly modified, but the storage of associated 5G security parameters on the USIM was enhanced by mandating that a specific storage service be enabled. Furthermore, new Elementary Files (EFs) were added to the USIM for Access Control to GBA_U_APIs and for IMS Data Channel configuration, expanding the secure data management capabilities of the module.
In Release 19, a key update for the Integrity Key (IK) function involved ensuring backward compatibility for USIMs that lack extended storage for 5G authentication keys. Specifically, the enhancement addresses the handling of USIMs without the necessary storage for extended security parameters in the EF_5GAuthKeys file. This ensures that the IK, which is stored on the USIM and used for integrity protection, can be properly managed even with legacy USIM capabilities.
- Backward compatibility handling of USIM without extended security parameter storage in EF_5GAuthKeys - Rel19 TS 31.102CR1074
Explore further
Broader topics and technologies where IK plays a role.
Defining Specifications
3GPP specifications that define or reference IK, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 21.111 vj00 | USIM and UICC Requirements for 3G | Rel-19 |
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 23.060 vj00 | GPRS Service Description Stage 2 | Rel-19 |
| TS 24.109 vj00 | HTTP Digest AKA & GAA Stage 3 | Rel-19 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 29.109 vj00 | GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) | Rel-19 |
| TS 31.102 vj40 | USIM Application Specification | Rel-19 |
| TS 31.103 vj00 | ISIM Application Specification | Rel-19 |
| TS 31.121 vi50 | UICC-terminal interface test specification | Rel-18 |
| TR 31.900 vj00 | 3GPP TS 31.900: Security Interworking Guidance | Rel-19 |
| TS 33.102 vj10 | 3G Security Architecture Specification | Rel-19 |
| TS 33.105 vj00 | 3G Security: Cryptographic Algorithm Requirements | Rel-19 |
| TS 33.220 vj00 | Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) | Rel-19 |
| TS 33.221 vj00 | Subscriber Certificate Distribution via GBA | Rel-19 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 33.835 vg10 | Study on authentication and key management for apps | Rel-16 |
| TS 33.859 vb10 | UTRAN Key Hierarchy Enhancement Study | Rel-11 |
| TS 33.863 ve20 | Security for Battery-Efficient IoT Device to Enterprise | Rel-14 |
| TS 35.205 vj00 | MILENAGE Algorithm Set: General Overview | Rel-19 |
| TR 35.909 vj00 | 3GPP MILENAGE Algorithm Design Report | Rel-19 |
| TR 35.934 vj00 | Tuak algorithm set for 3GPP auth & key gen | Rel-19 |